--- Comment #4 from gdr at integrable-solutions dot net 2006-10-28 03:19
---
Subject: Re: argument dependent lookup: what about built-in types?
"v dot vasaitis at sms dot ed dot ac dot uk" <[EMAIL PROTECTED]> writes:
| Interesting analysis. However, wouldn'
--- Comment #8 from gdr at integrable-solutions dot net 2006-12-23 11:17
---
Subject: Re: SIGSEGV on operator==(valarray, bool)
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| What target is this one, all I get is:
| t.cc:8: error: cannot con
--- Comment #13 from gdr at integrable-solutions dot net 2006-12-24 05:23
---
Subject: Re: SIGSEGV on operator==(valarray, bool)
"pinskia at gmail dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #9 from pinskia at gmail dot com 2006-12-23 18:50 -
--- Comment #2 from gdr at integrable-solutions dot net 2006-12-30 11:21
---
Subject: Re: New: a const member function can call a non_const member
function without const_cast
"hongleij at 126 dot com" <[EMAIL PROTECTED]> writes:
| //const_test.cpp
| struct A
| {
|
--- Comment #5 from gdr at integrable-solutions dot net 2006-12-30 17:51
---
Subject: Re: a const member function can call a non_const member function
without const_cast
"hongleij at 126 dot com" <[EMAIL PROTECTED]> writes:
| the question is : if a const member fun
--- Comment #5 from gdr at integrable-solutions dot net 2007-01-01 09:47
---
Subject: Re: pure virtual function called on const & declared with previous
declaration without a definition, const & assigned by temporary
"pinskia at gcc dot gnu dot org" <[EMAIL PROTE
--- Comment #9 from gdr at integrable-solutions dot net 2007-01-02 11:49
---
Subject: Re: pure virtual function called on const & declared with previous
declaration without a definition, const & assigned by temporary
"mjtruog at fastmail dot ca" <[EMAIL PROTECT
--- Comment #5 from gdr at integrable-solutions dot net 2007-01-02 12:02
---
Subject: Re: New: '#define false FALSE' undefines '#define FALSE false'
"h8_spam at sonic dot net" <[EMAIL PROTECTED]> writes:
| I ran into an issue where doing #de
--- Comment #6 from gdr at integrable-solutions dot net 2007-01-02 12:05
---
Subject: Re: '#define false FALSE' undefines '#define FALSE false'
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #1 from pinskia at g
--- Comment #7 from gdr at integrable-solutions dot net 2007-01-02 12:06
---
Subject: Re: '#define false FALSE' undefines '#define FALSE false'
"h8_spam at sonic dot net" <[EMAIL PROTECTED]> writes:
| Right, but since true and false are keywo
--- Comment #8 from gdr at integrable-solutions dot net 2007-01-02 12:08
---
Subject: Re: '#define false FALSE' undefines '#define FALSE false'
"pinskia at gmail dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: '#define false FALSE&
--- Comment #7 from gdr at integrable-solutions dot net 2007-01-02 23:33
---
Subject: Re: Failure to diagnose overflow in constant expression
"andrew dot stubbs at st dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #6 from andrew dot stubbs at st dot com
--- Comment #26 from gdr at integrable-solutions dot net 2007-01-05 07:02
---
Subject: Re: No possibility to disable large file support (LFS)
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I really don't think turning off LFS and using lib
--- Comment #8 from gdr at integrable-solutions dot net 2007-01-05 21:06
---
Subject: Re: [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant
folding
"jakub at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Do the parenthesis matter in C?
Yes, se
--- Comment #9 from gdr at integrable-solutions dot net 2007-01-05 21:09
---
Subject: Re: [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant
folding
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
[...]
| That is most explict thing ab
--- Comment #4 from gdr at integrable-solutions dot net 2007-01-05 21:11
---
Subject: Re: wrong result
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| > anther, consider an example definite[2] of 'offsetof', if you think
| > that is u
--- Comment #9 from gdr at integrable-solutions dot net 2007-01-09 05:28
---
Subject: Re: [hppa64-hp-hpux11.11] libstdc++-v3 fails to build with HP
assembler
"jbuck at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| We might just document that it doesn't wo
--- Comment #4 from gdr at integrable-solutions dot net 2007-01-09 18:41
---
Subject: Re: missed warnings about comparisons which are always true/false.
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Wextra warns for this, what is the bug?
I bel
--- Comment #5 from gdr at integrable-solutions dot net 2007-01-09 18:43
---
Subject: Re: warning for comparison of different enum types impossible to
control/is undocumented
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| What name do you want for th
--- Comment #6 from gdr at integrable-solutions dot net 2007-01-09 18:44
---
Subject: Re: warning for comparison of different enum types impossible to
control/is undocumented
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I could also add it to the
--- Comment #2 from gdr at integrable-solutions dot net 2007-01-09 22:05
---
Subject: Re: New: SIGSEGV in valarray::cshift(n) on empty array
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| AFAIK, the program below should have well-defined behavior bu
--- Comment #6 from gdr at integrable-solutions dot net 2007-01-10 03:32
---
Subject: Re: SIGSEGV in valarray::cshift(n) on empty array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| The standard refers to "(l+n)%size()", so if size()=0, th
--- Comment #7 from gdr at integrable-solutions dot net 2007-01-10 03:33
---
Subject: Re: SIGSEGV in valarray::cshift(n) on empty array
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| (In reply to comment #3)
| > The standard refers to "(l+n)%size(
--- Comment #8 from gdr at integrable-solutions dot net 2007-01-10 03:37
---
Subject: Re: SIGSEGV in valarray::cshift(n) on empty array
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Well, IMHO, avoiding this SIGSEGV is so easy, I would change anyway both
sh
--- Comment #12 from gdr at integrable-solutions dot net 2007-01-10 23:27
---
Subject: Re: SIGSEGV in valarray::cshift(n) on empty array
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Forgot: assuming we imagine the standard clarified per your proposal
| on
--- Comment #15 from gdr at integrable-solutions dot net 2007-01-12 13:06
---
Subject: Re: SIGSEGV in valarray::cshift(n) on empty array
"paolo at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Subject: Bug 30416
|
| Author: paolo
| Date: Fri Jan 12 11:09:26 200
--- 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 #8 from gdr at cs dot tamu dot edu 2006-05-23 21:58 ---
Subject: Re: __builtin_nanf("") doesn't return a _quiet_ nan on parisc
"dave at hiauly1 dot hia dot nrc dot ca" <[EMAIL PROTECTED]> writes:
| --- Comment #7 from dave at hiauly1 dot
--- 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
401 - 500 of 1275 matches
Mail list logo
