public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: Jason Merrill <jason@redhat.com>
Cc: Richard Henderson <rth@redhat.com>,
	Alan Modra <amodra@bigpond.net.au>,
	Mark Mitchell <mark@codesourcery.com>,
	gcc@gcc.gnu.org
Subject: Re: GCC 3.1 Prerelease
Date: Wed, 24 Apr 2002 12:04:00 -0000	[thread overview]
Message-ID: <200204242101.39393@enzo.bigblue.local> (raw)
In-Reply-To: <wvlr8l5vw8q.fsf@prospero.cambridge.redhat.com>

On Wednesday 24 April 2002 19:31, Jason Merrill wrote:
> While I was looking at this bug earlier (before I saw that you were working
> on it), I made this change.  Checking TREE_SYMBOL_REFERENCED makes more
> sense than TREE_USED anyway, since it's the symbol we care about.

Hmm, it seems to make more sense for the warning check too, with TREE_USED 
changed to TREE_SYMBOL_REFERENCED the c++ regression 
g++.old-deja/g++.jason/template39.C went away along with a bunch of 
regressions in the libstdc++ testsuite, except one:

FAIL: 26_numerics/complex_inserters_extractors.cc (test for excess errors)
Excess errors:
/home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h: 
In instantiation of `const size_t std::basic_string<char, gnu_cha
r_traits, std::allocator<char> >::npos':
/home/fsirl/TC/gcc/BUILD/gcc-3.1/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc:109:   
instantiated from here
/home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h:217: 
warning: weak declaration of `const size_t std::basic_string<
char, gnu_char_traits, std::allocator<char> >::npos' after first use may 
result in unspecified behaviour

Can a c++ expert tell me if this warning makes sense in this testcase or does 
the warning check need still more refinement?

Hmm, Jason, I'm just noticing the purpose of the test in weak_finish. This 
seems to be a behaviour change compared to earlier gcc releases. A simple 
file like that:

#pragma weak foo1
extern int foo2 __attribute__((weak));

will now result in this assembly file:

        .file   "weak-pragma.c"
        .ident  "GCC: (GNU) 3.1 20020423 (prerelease)"

But upto 3.0.x we got:

        .file   "weak-pragma.c"
        .weak   foo2
        .weak   foo1
        .ident  "GCC: (GNU) 3.0.3 20011213 (prerelease)"

Are we sure there is no code out there relying on these lonely .weak 
statements? Was this change intended?

Franz.

  reply	other threads:[~2002-04-24 19:03 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-23  2:12 Mark Mitchell
2002-04-23  3:53 ` Alan Modra
2002-04-23  4:13   ` Franz Sirl
2002-04-23  4:32     ` Alan Modra
2002-04-23 10:40       ` Franz Sirl
2002-04-23 11:42         ` Richard Henderson
2002-04-23 15:08           ` Franz Sirl
2002-04-23 15:10             ` Richard Henderson
2002-04-24 10:56             ` Jason Merrill
2002-04-24 12:04               ` Franz Sirl [this message]
2002-04-24 13:03                 ` Richard Henderson
2002-04-24 13:14                 ` Jason Merrill
2002-04-25 12:57                   ` [PATCH] Fix PR c/6343 (was: Re: GCC 3.1 Prerelease) Franz Sirl
2002-04-25 12:59                     ` Jason Merrill
2002-04-28  8:44                       ` Franz Sirl
2002-04-28 11:59                         ` Mark Mitchell
2002-04-28 15:00                         ` Jason Merrill
2002-04-28 16:36                           ` Mark Mitchell
2002-04-29 11:36                           ` Franz Sirl
2002-04-30  6:20                             ` Jason Merrill
2002-04-30  9:40                               ` Mark Mitchell
2002-04-23 12:22         ` GCC 3.1 Prerelease Jason Merrill
2002-04-23  9:08 ` Per Bothner
2002-04-23  9:30   ` Mark Mitchell
2002-04-23 10:12     ` Per Bothner
2002-04-23 13:25       ` Mark Mitchell
2002-04-23 14:52       ` Tom Tromey
2002-04-23 15:02         ` Per Bothner
2002-04-23 16:11           ` Tom Tromey
2002-04-24 10:14             ` Alexandre Petit-Bianco
2002-04-24 10:30               ` Tom Tromey
2002-04-24 10:32                 ` Mark Mitchell
2002-04-23 13:19 ` Richard Henderson
2002-04-23 13:28   ` Mark Mitchell
2002-04-23 13:35     ` Richard Henderson
2002-04-23 13:50       ` Mark Mitchell
2002-04-23 13:52         ` Richard Henderson
2002-04-23 16:30         ` mips n64 eh failures Richard Henderson
2002-04-23 16:53           ` Mark Mitchell
2002-04-23 16:59             ` Richard Henderson
2002-04-23 18:00               ` Richard Henderson
2002-04-23 18:20                 ` Richard Henderson
2002-04-23 19:35                   ` Richard Henderson
2002-04-24  9:08                     ` Mark Mitchell
  -- strict thread matches above, loose matches on Subject: below --
2002-04-23 14:56 GCC 3.1 Prerelease Tom Tromey
2002-04-23 13:38 GCC 3.1 prerelease Mark Mitchell
2002-04-23 18:37 ` Kurt Wall
2002-04-23 19:23   ` Phil Edwards
2002-04-24  9:49   ` Mark Mitchell
2002-04-24 11:03     ` Joseph S. Myers
2002-04-24 19:03       ` Kurt Wall
2002-04-23 10:46 GCC 3.1 Prerelease Paolo Carlini
2002-04-22 20:00 Billinghurst, David (CRTS)
2002-04-22  4:07 Wolfgang Bangerth
2002-04-22  0:07 Toon Moene
2002-04-20 20:09 John David Anglin
2002-04-20 21:44 ` Mark Mitchell
2002-04-23 12:19   ` John David Anglin
2002-04-21  7:06 ` Toon Moene
2002-04-21 12:57   ` Mark Mitchell
2002-04-21 13:50     ` Franz Sirl
2002-04-22  3:20       ` Gerald Pfeifer
2002-04-22 10:50       ` Franz Sirl
2002-04-22 10:56         ` Mark Mitchell
2002-04-21 20:54     ` John David Anglin
2002-04-22  0:13     ` Richard Henderson
2002-04-22  7:48       ` Mark Mitchell
     [not found] <FAC87D7C874EAB46A847604DA4FD5A640346FC@crtsmail.corp.riotinto.o rg>
2002-04-20 20:05 ` Billinghurst, David (CRTS)
2002-04-20 20:16   ` Mark Mitchell
     [not found] <Pine.LNX.4.30.0204210235010.13395-100000@snake.iap.physik.tu-da rmstadt.de>
2002-04-20 17:16 ` Peter Schmid
2002-04-20 17:57   ` Mark Mitchell
2002-04-21 14:16     ` Richard Henderson
2002-04-21 16:54       ` Mark Mitchell
2002-04-23  5:46         ` Jason Merrill
2002-04-23  9:12           ` Mark Mitchell
2002-04-20 13:08 Mark Mitchell
2002-04-20 13:51 ` Stan Shebs
2002-04-20 14:07   ` Mark Mitchell
2002-04-20 16:10   ` Joel Sherrill
2002-04-20 13:56 ` Joseph S. Myers
2002-04-20 13:59   ` Mark Mitchell
2002-04-20 14:36 ` Jakub Jelinek
2002-04-20 17:17   ` Mark Mitchell
2002-04-23  9:49     ` Jakub Jelinek
2002-04-24 10:07       ` Mark Mitchell
2002-04-20 16:35 ` Tom Tromey
2002-04-20 17:28   ` Mark Mitchell
2002-04-20 19:04 ` David S. Miller
2002-04-20 20:08   ` Mark Mitchell
2002-04-20 20:13     ` David S. Miller
2002-04-20 20:18       ` Per Bothner
2002-04-21 11:27         ` Tom Tromey
2002-04-20 20:45       ` Mark Mitchell
2002-04-20 22:09 ` Alan Modra
2002-04-21  3:47 ` Gerald Pfeifer
2002-04-23  8:24   ` Gerald Pfeifer
2002-04-23  9:13     ` Mark Mitchell
2002-04-23  9:36       ` Joe Buck
2002-04-23 14:21         ` Gerald Pfeifer
2002-04-21  8:16 ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200204242101.39393@enzo.bigblue.local \
    --to=franz.sirl-kernel@lauterbach.com \
    --cc=amodra@bigpond.net.au \
    --cc=gcc@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=mark@codesourcery.com \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).