--- Comment #4 from gdr at gcc dot gnu dot org 2006-05-11 16:33 ---
See
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#488
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1945.pdf
The later paper is under active consideration.
The PR should be suspended
--- Comment #26 from gdr at gcc dot gnu dot org 2005-11-16 18:40 ---
(In reply to comment #17)
> (In reply to comment #13)
> > It's nice to see that PR bouncing between you all. Although I don't know
> > anything about C++, I want to add my non-con
--- Comment #27 from gdr at gcc dot gnu dot org 2005-11-16 18:44 ---
(In reply to comment #19)
> There are only two choices: either __imag__ is an lvalue, and the code in
> Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should
> issue an error.
>
>
--- Comment #28 from gdr at gcc dot gnu dot org 2005-11-16 18:47 ---
(In reply to comment #25)
> Subject: Re: [4.1 regression] Bogus 'is used uninitialized...'
> warning about std::complex
>
> schwab at suse dot de wrote:
> > --- Comment #23 from schwa
--- Comment #6 from gdr at gcc dot gnu dot org 2005-11-21 02:09 ---
(In reply to comment #5)
> I've made a small amount of headway on this.
>
> Labels L22 and L21 were (when created) the addresses of objects in the code.
> However, they are deleted (presumably as unre
--- Comment #7 from gdr at gcc dot gnu dot org 2005-11-21 02:11 ---
Postponed until GCC 3.4.6
(this bug has been there for more than a here; nobody seems to feel
strong about it)
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from gdr at gcc dot gnu dot org 2005-11-21 02:12 ---
(In reply to comment #13)
> It also works if NS is nested within std, as in the example in the GCC
> documentation.
>
So, Jason, do you want to close this as WONTFIX for 3.4.x?
--
gdr at gcc dot gn
--- Comment #7 from gdr at gcc dot gnu dot org 2005-11-21 02:14 ---
Postponed untill GCC 3.4.6
(this bug has been there for more than a year and there does not seem to be
excitment about it)
--
gdr at gcc dot gnu dot org changed:
What|Removed
--- Comment #37 from gdr at gcc dot gnu dot org 2005-11-21 02:21 ---
(In reply to comment #36)
> New patch at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00864.html
>
Eric, do you still consider this problem important to be solved for 3.4.x?
Do you have a new version of your pr
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-21 02:22 ---
Postponed until 3.4.6.
Not release critical.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-21 02:23 ---
(In reply to comment #2)
> This has been fixed on mainline. Note that you need a recent (2004-09)
> binutils
> with support for new dot-symbol conventions when you configure and build GCC.
>
> I c
--- Comment #19 from gdr at gcc dot gnu dot org 2005-11-21 02:26 ---
Fixed for 4.0.x and higher.
Won't fix in 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- Comment #12 from gdr at gcc dot gnu dot org 2005-11-21 02:28 ---
Appears to be fixed in 4.0.3 and higher.
Won't fix for 3.4.x.
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-21 02:29 ---
Is there any hppa maintainer lookin at this?
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-21 02:30 ---
Postponed untill GCC 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-21 02:31 ---
Postponed untill GCC 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #8 from gdr at gcc dot gnu dot org 2005-11-21 02:33 ---
Postponed untill GCC 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from gdr at gcc dot gnu dot org 2005-11-21 02:34 ---
Postponed until GCC 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-21 02:38 ---
RTH,
do you believe your patch (mentioned in Comment #0) is good for GCC-3.4.x?
-- Gaby
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-21 02:39 ---
(In reply to comment #3)
> It looks like it was fixed on mainline by this patch from mmitchel:
>
> http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01218.html
>
> It's hard to be sure because there a
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-21 02:40 ---
Not release critical.
Postponed until GCC 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-21 02:42 ---
If I recall correctly, this involves rewriting how we handle the built-ins
by Roger Sayle.
At this stage, won't fix for 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Re
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-21 02:43 ---
Postponed until GCC 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-21 02:44 ---
Not release critical.
Postponed until GCC 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #39 from gdr at gcc dot gnu dot org 2005-11-21 10:41 ---
Fixed in 4.0.0 and higher.
Won't fix for 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- Comment #8 from gdr at gcc dot gnu dot org 2005-11-22 17:04 ---
Subject: Bug 22238
Author: gdr
Date: Tue Nov 22 17:04:12 2005
New Revision: 107366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107366
Log:
PR c++/22238
*
--- Comment #9 from gdr at gcc dot gnu dot org 2005-11-22 18:08 ---
Subject: Bug 22238
Author: gdr
Date: Tue Nov 22 18:08:17 2005
New Revision: 107367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107367
Log:
PR c++/22238
*
--- Comment #10 from gdr at gcc dot gnu dot org 2005-11-22 22:27 ---
Subject: Bug 22238
Author: gdr
Date: Tue Nov 22 22:27:52 2005
New Revision: 107376
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107376
Log:
PR c++/22238
*
--- Comment #11 from gdr at gcc dot gnu dot org 2005-11-22 23:20 ---
No longer a regression.
Set bug back at "normal" state -- no milestone.
--
gdr at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-23 07:07 ---
Subject: Bug 21668
Author: gdr
Date: Wed Nov 23 07:07:33 2005
New Revision: 107401
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107401
Log:
PR c/21668
* c-decl.c (grokdeclarator): Do
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-23 07:12 ---
Fixed on mainline.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-24 02:02 ---
Subject: Bug 21667
Author: gdr
Date: Thu Nov 24 02:02:26 2005
New Revision: 107448
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107448
Log:
2005-11-23 Gabriel Dos Reis <[EMAIL PROTECTED]>
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-24 02:10 ---
Fixed on mainline.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-24 02:23 ---
Agreed with the reporter's analysis
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-24 02:25 ---
(In reply to comment #2)
> This is how C++ is done, maybe a warning can be emitted but it seems like it
> will emitt too much for
> valid C++ code.
>
I don't know; the code shown is very cont
--- Comment #12 from gdr at gcc dot gnu dot org 2005-11-24 02:35 ---
Mainline already has Richard's suggestion.
Closing.
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-24 02:42 ---
(In reply to comment #2)
> IMO, saying "`bar()::X' uses local type `bar()::X'" makes no sense.
Agreed. Working a patch.
--
gdr at gcc dot gnu dot org changed:
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-24 03:39 ---
Fixed on mainline
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-24 03:40 ---
still does not work with bubblestrap and friends
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-26 07:19 ---
(In reply to comment #1)
> I can reproduce this 3.3.3 and 3.4.3. However, 4.0.0 doesn't have the
> problem.
Are you working on this? It lools like the bug has been there for a while.
I'm inclined to
--- Comment #6 from gdr at gcc dot gnu dot org 2005-11-26 07:28 ---
Fixed in 4.1 and higher. Will not fix in 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from gdr at gcc dot gnu dot org 2005-11-26 07:35 ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > There should be a "defined but not used" warning.
> >
> > Why, this is a constant array
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-26 07:44 ---
(In reply to comment #2)
> Hmm, sort of. The call of g(i) also warns with "is used", although I
> think it might deserve only a "may be used". But anyway I think that
> this nevertheles
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-26 07:47 ---
With mailine compiler (GCC-4.2.x), I cannot reproduce the reported behaviour.
-- Gaby
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||gdr at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-26 07:54 ---
(In reply to comment #2)
> Indeed, in gcc-4.0.1, the previous code chunk does not elicit a warning.
> However, a slightly modified version still gets a warning (tested
> on RHEL-4, with ).
I can repr
--- Comment #5 from gdr at gcc dot gnu dot org 2005-11-26 08:04 ---
The PR should be reported to the translation project which
operates independently of GCC.
-- Gaby
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org
|dot org
--- Comment #11 from gdr at gcc dot gnu dot org 2005-11-26 08:10 ---
This is reject-valid.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #4 from gdr at gcc dot gnu dot org 2005-11-26 08:57 ---
(In reply to comment #1)
> I can confirm the behavior, though I'm not sure whether we really
> need to change the error message. Gaby -- you're the diagnostics
> maintainer, so it's your call.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||gdr at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot gnu
--- Comment #6 from gdr at gcc dot gnu dot org 2005-11-26 09:08 ---
(In reply to comment #0)
> Some warning options trigger warnings in standard C++ headers, rendering
> -Werror
> unusable. This can be seen with a simple example:
>
> #include
> int main()
>
--- Comment #10 from gdr at gcc dot gnu dot org 2005-11-26 09:12 ---
(In reply to comment #8)
> So, I put the c++ "enhancement" requests as blockers to this bug.
>
> I think -Weffc++ is now usable on mainline, but before I do any more work on
> this stuff, I'
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org
|dot org
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||gdr at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot gnu
--- Comment #6 from gdr at gcc dot gnu dot org 2005-11-27 21:18 ---
this is accept-invalid, no diagnostic
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from gdr at gcc dot gnu dot org 2005-11-28 10:19 ---
(In reply to comment #4)
> Subject: Re: [3.4 only] [hppa] 'bus error' at runtime while passing a special
> struct to a C++ member function
>
> > Are you working on this? It lools like the
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-28 10:20 ---
Postpone until 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone
--- Comment #7 from gdr at gcc dot gnu dot org 2005-11-28 10:22 ---
Postpone until 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone
--- Comment #5 from gdr at gcc dot gnu dot org 2005-11-29 20:37 ---
(In reply to comment #4)
> | instead of the FUNCTION_TYPE's type which has the correct type, I might fix
> | this later tonight.
>
> Try this
this patch is incomplete.
--
gdr at gcc dot gn
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-30 17:43 ---
(In reply to comment #2)
> Absolutely not! There is no "best" way: sometimes it is better to go through
> the typedef, sometimes it is better to print the typedef.
>
> To tell you the truth, I
--- Comment #8 from gdr at gcc dot gnu dot org 2005-11-30 17:47 ---
(In reply to comment #7)
> diagnostic.c gets #include stack information from input_file_stack. cpplib
> gets it from source_locations. With --enable-mapped-location, this regression
> could be fixed by dia
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-30 19:15 ---
(In reply to comment #2)
> On the mainline (20030526), I only get one warning:
>
> pr5310.cc: In function `void bar()':
> pr5310.cc:9: warning: passing NULL used for non-pointer argument 1 of `v
--- Comment #12 from gdr at gcc dot gnu dot org 2005-11-30 23:27 ---
(In reply to comment #11)
> *** Bug 24291 has been marked as a duplicate of this bug. ***
>
Is thi PR really about "diagnostic"? I don't see what is "wrong" and
what is not.
-- Gab
--- Comment #8 from gdr at gcc dot gnu dot org 2005-12-01 08:33 ---
Moved to 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|3.4.5
--- Comment #5 from gdr at gcc dot gnu dot org 2005-12-01 12:00 ---
Subject: Bug 13384
Author: gdr
Date: Thu Dec 1 12:00:17 2005
New Revision: 107816
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107816
Log:
PR c/13384
* c-common.c (lvalue_error): Fix
--- Comment #6 from gdr at gcc dot gnu dot org 2005-12-01 12:01 ---
Fixed in 4.2.x (mainline).
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gdr at gcc dot gnu dot org
GCC host triplet: platform independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
--- Comment #6 from gdr at gcc dot gnu dot org 2005-12-04 05:00 ---
Working on a patch.
Fixing this issue has a deep "type" implications on the way we currently
hand inputs with erronous types whereas trying to progress as much as possible.
--
gdr at gcc dot gnu dot o
--- Comment #8 from gdr at gcc dot gnu dot org 2005-12-04 05:04 ---
(In reply to comment #0)
> The following code:
>
> struct S
> { int x[3]; };
>
> void f()
> { S s = {1,2,3};}
>
> With -Wmissing-braces (which is implied by -Wall, among others) gives:
&
--- Comment #4 from gdr at gcc dot gnu dot org 2005-12-04 05:09 ---
this issue should be resolved one way of the other based on the
core issue about argument dependent lookup specification, when a
non-function is found. The "obvious" solution would be to do overload
resolutio
--- Comment #2 from gdr at gcc dot gnu dot org 2005-12-04 05:14 ---
The behaviour is what Standard C++ mandates. Explicit qualification in
the template instructs the compiler to consider only the overload set
avaliable at the definition context, not instantiation context,
-- Gaby
--- Comment #7 from gdr at gcc dot gnu dot org 2005-12-04 05:17 ---
(In reply to comment #3)
> right now if we don't gimplify with -fsyntax-only, we would not be able to
> diagnostic the following:
> void f(void)
> {
> break;
> }
If that is true, then it should
--- Comment #4 from gdr at gcc dot gnu dot org 2005-12-21 17:21 ---
(In reply to comment #3)
> Invalid as of 6.5.6/8
>
I don't think that paragraph explains why this is an
invalid PR.
--
gdr at gcc dot gnu dot org changed:
What|Removed
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gdr at gcc dot gnu dot org
GCC build triplet: native
GCC host triplet: i686-pc-
--- Comment #4 from gdr at gcc dot gnu dot org 2005-12-31 01:13 ---
(In reply to comment #0)
> g++ from mainline (and 4.1.x) miscompilers gcjx from gcjx-branch.
>
> How to repeat:
>
> (1) check out gcjx-branch
> (2) configure and build gcjx (make all-gcjx, make
--- Comment #5 from gdr at gcc dot gnu dot org 2005-12-31 04:12 ---
Created an attachment (id=10572)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10572&action=view)
translation unit of format.cc
GDB session indicate the stall happens in the call to
format_repr::get_
--- Comment #7 from gdr at gcc dot gnu dot org 2005-12-31 04:20 ---
(In reply to comment #6)
> This sounds more like a libstdc++ issue rather than a front-end or optimizer
> issue.
Before reclassifying, it would useful to provide data. If you cannot,
please move on somethin
--- Comment #9 from gdr at gcc dot gnu dot org 2006-01-19 07:48 ---
Fixed in 4.0.3 and higher. Won't fix in 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- Comment #10 from gdr at gcc dot gnu dot org 2006-08-11 11:03 ---
the behaviour is conformant to the documentation
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from gdr at gcc dot gnu dot org 2007-01-25 14:14 ---
Won't be fixed in GCC-4.0.4. So closing, sorry.
The code appears to work in recent versions of GCC.
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- Comment #50 from gdr at gcc dot gnu dot org 2007-01-25 15:51 ---
This is not going to be fixed for GCC-4.0.4, so adjusting milestone.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from gdr at gcc dot gnu dot org 2007-01-25 15:54 ---
Fixed in GCC-4.1.2 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from gdr at gcc dot gnu dot org 2007-01-25 15:58 ---
This PR will not be fixed in GCC-4.0.4, so adjusting
the milestone.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from gdr at gcc dot gnu dot org 2007-01-25 16:04 ---
Adjusting milestone
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone
--- Comment #8 from gdr at gcc dot gnu dot org 2007-02-03 15:31 ---
won't fix in GCC-4.0.4
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #2 from gdr at gcc dot gnu dot org 2007-02-03 15:32 ---
Fixed in GCC-4.1.1 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from gdr at gcc dot gnu dot org 2007-02-03 15:32 ---
Fixed in GCC-4.1.1 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from gdr at gcc dot gnu dot org 2007-02-03 15:33 ---
Fixed in GCC-4.1.0 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from gdr at gcc dot gnu dot org 2007-02-03 15:34 ---
won't fix in GCC-4.0.x. Adjusting milestone
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- Comment #10 from gdr at gcc dot gnu dot org 2007-02-03 15:35 ---
Fixed in GCC-4.1.0 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 15:35 ---
Fixed in GCC-4.1.0 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from gdr at gcc dot gnu dot org 2007-02-03 15:36 ---
Fixed in GCC-4.1.1 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from gdr at gcc dot gnu dot org 2007-02-03 15:37 ---
Fixed in GCC-4.1.0 and higher
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gdr at gcc dot gnu dot org 2007-02-03 15:37 ---
Fixed in GCC-4.1.0 and higher
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 15:38 ---
Fixed in GCC-4.1.0 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 683 matches
Mail list logo
