--- Comment #9 from manu at gcc dot gnu dot org 2010-09-23 15:53 ---
(In reply to comment #1)
> Well - obviously global typedefs keep their BLKmode. The target attribute
> can't work this way - it's broken by design.
If it is broken by design, why not remove it bef
--- Comment #6 from manu at gcc dot gnu dot org 2010-09-23 08:24 ---
I don't get a warning in trunk r159764. I think I fixed a similar bug during
4.6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #5 from manu at gcc dot gnu dot org 2010-09-23 08:13 ---
(In reply to comment #4)
> "Me too". This is real code, from xdgmime library (errno doesn't matter)
>
> long retval = -1;
> ...
> if ((retval < INT_MIN) ||
--- Comment #9 from manu at gcc dot gnu dot org 2010-09-23 07:54 ---
Why is this waiting? It only requires a fix.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2010-09-17 08:54 ---
I have seen this question/bug reported a couple of times in bugzilla and a few
more in gcc-help, so I added a FAQ:
http://gcc.gnu.org/wiki/FAQ#cpp_continuation_discarded
I suggest that it is rather more useful to
--- Comment #7 from manu at gcc dot gnu dot org 2010-09-16 17:04 ---
(In reply to comment #4)
> (In reply to comment #2)
> > http://gcc.gnu.org/bugs/#need
>
> Since this is a bug in the preprocessor it is hard to get a preprocessed
> source
> that causes a bug
--- Comment #2 from manu at gcc dot gnu dot org 2010-09-14 09:32 ---
http://gcc.gnu.org/bugs/#need
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2010-09-09 13:15 ---
We need a testcase
http://gcc.gnu.org/bugs/minimize.html
but I am pretty sure this is not warned anymore in GCC 4.6 (and probably GCC
4.4 and 4.5)
--
manu at gcc dot gnu dot org changed:
What
--- Comment #2 from manu at gcc dot gnu dot org 2010-09-09 08:00 ---
In any case, this is a clear regression of the pretty printer.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2010-09-08 23:33 ---
(In reply to comment #5)
> The changes done in pp_c_cv_qualifiers print "�__attribute__((const))�"
> or
> '"__attribute__((noreturn))"' for function pointer even if they
--- Comment #20 from manu at gcc dot gnu dot org 2010-09-07 06:38 ---
(In reply to comment #19)
> Manu, did you mean to change Severity back to 'critical' ?
No, that was a mistake. In any case, this is INVALID for the reasons discussed
above.
--
manu at gcc dot gnu do
--- Comment #22 from manu at gcc dot gnu dot org 2010-09-03 14:06 ---
(In reply to comment #21)
> (In reply to comment #8)
> > Is 'coverity' a compiler? I don't think so.
> >
>
> Coverity is not a tool that generates code, but it does perform
>
--- Comment #41 from manu at gcc dot gnu dot org 2010-09-02 23:10 ---
*** Bug 42884 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from manu at gcc dot gnu dot org 2010-09-02 23:10 ---
The first testcase and the second are different issues. Both of them are old,
known and reported in bugzilla. None of them are trivial to fix.
GCC developers would wish to make our compiler as powerful as to solve
--- Comment #7 from manu at gcc dot gnu dot org 2010-09-02 22:59 ---
WAITING is for waiting for submitters information.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #40 from manu at gcc dot gnu dot org 2010-09-02 22:50 ---
*** Bug 45493 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2010-09-02 22:50 ---
CCP is responsible for this.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from manu at gcc dot gnu dot org 2010-08-31 22:44 ---
(In reply to comment #17)
> Manuel, can you back up your claims about the C FE being slow with some
> numbers? I don't remember the C FE ever being a time issue recently, of
> course
> C++ is a di
--- Comment #15 from manu at gcc dot gnu dot org 2010-08-31 21:34 ---
(In reply to comment #14)
> > depend on which optimization passes are run (and their order). See
> > http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings for more background on
> > the issues inv
--- Comment #13 from manu at gcc dot gnu dot org 2010-08-31 21:07 ---
(In reply to comment #12)
> Sorry Andrew, misinterpreted some things you said. I understand now that you
> meant that normally everything should work as expected.
>
> @Manuel,
> So, perhaps then this b
--- Comment #11 from manu at gcc dot gnu dot org 2010-08-31 20:53 ---
(In reply to comment #8)
> (In reply to comment #7)
> > I am pointing out a case where it does not warn (and it seems to me that it
> > should); what is your point?
>
> My point is that you sh
--- Comment #8 from manu at gcc dot gnu dot org 2010-08-31 20:37 ---
(In reply to comment #7)
> Updated code snippet, GCC doesn't warn here either if we leave `#if 0' as-is,
> even though the function foo() may have side-effects.
No, the function below does not have
--- Comment #11 from manu at gcc dot gnu dot org 2010-07-21 19:40 ---
(In reply to comment #8)
> Despite your remarkably rude response, I've mailed a fix:
> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01665.html
Don't take it personally. Some of us are not native Engl
--- Comment #15 from manu at gcc dot gnu dot org 2010-07-13 15:22 ---
Before closing this, please check all testcases provided and add at least one
of them to the testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-06 17:41 ---
Too large testcase, no feedback in 3 years, no clear report. Closing...
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2010-07-06 17:39 ---
No duplicates in 3 years, no new feedback, closing this. Please reopen if
necessary.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2010-07-06 17:35 ---
No feedback, unconfirmed, unreproducible, thus closing.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2010-07-06 17:34 ---
3 years in waiting... I am closing this, we have too many real bugs open to
worry about.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from manu at gcc dot gnu dot org 2010-07-06 17:28 ---
The way Clang gets this right is to perform some very-fast bitmap common
constant propagation in the FE. I personally think this would be helpful if
implemented correctly, even if it slows down the FE a little. But do
--- Comment #21 from manu at gcc dot gnu dot org 2010-07-06 17:24 ---
*** Bug 44842 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-06 17:24 ---
*** This bug has been marked as a duplicate of 4210 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from manu at gcc dot gnu dot org 2010-07-04 18:19 ---
Testcase added. Closing as FIXED.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2010-07-04 18:17 ---
Subject: Bug 16630
Author: manu
Date: Sun Jul 4 18:16:59 2010
New Revision: 161805
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161805
Log:
2010-07-04 Manuel López-Ibáñez
PR c
--- Comment #10 from manu at gcc dot gnu dot org 2010-07-04 08:34 ---
(In reply to comment #8)
>
> After the bug has been closed. i has posted the question to gcc-help, thanks
>
>
> ( i has reported as bug because , i has thinked it was a bug )
I personally think that
--- Comment #12 from manu at gcc dot gnu dot org 2010-07-04 08:27 ---
(In reply to comment #11)
>
> I do not object to -Wpedantic.
Ah, ok! Then, I will start with this and worry about the other warnings when
their time comes. Thanks!
--
manu at gcc dot gnu dot org c
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-03 20:10 ---
We should collect individual Wc++-compat issues here.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2010-07-03 20:08 ---
Isn't this a duplicate of PR37041? That PR is more complete than this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759
--- Comment #18 from manu at gcc dot gnu dot org 2010-07-03 19:59 ---
I think this bug is not actually assigned to anybody. Anyone feel free to take
it.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-03 19:01 ---
Shouldn't Apple have their own bugurl?
Perhaps we should add some short sentence in bugs.html about NOT reporting
Apple bugs to us (anyway their compiler version is too old to be interesting
for us).
--
ma
--- Comment #6 from manu at gcc dot gnu dot org 2010-07-03 18:58 ---
Pietro,
Please explain what is happening and what do you expect to happen, and why do
you expect that. If you are having troubles about using gcc, please ask in
gcc-help first.
--
manu at gcc dot gnu dot org
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #9 from manu at gcc dot gnu dot org 2010-07-02 14:24 ---
(In reply to comment #8)
> By the way, the subject should read -Werror=pedantic, right?
>
Well, it depends. We actually print -Werror=edantic. ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44783
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla
--- Comment #7 from manu at gcc dot gnu dot org 2010-07-02 10:56 ---
Why? All of them do, except -pedantic. I don't see any reason for -pedantic
being exceptional. Or can I start proposing warnings options that do not start
with -W?
Should we introduce a special case for pedantic
--- Comment #9 from manu at gcc dot gnu dot org 2010-07-02 09:15 ---
Thanks Pawel,
which diagnostic do you prefer?
I would favor clang's but I would still keep the note that points to the class
definition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
--- Comment #7 from manu at gcc dot gnu dot org 2010-07-02 08:09 ---
Could someone test what clang says here? Their diagnostics are generally better
than g++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
--- Comment #5 from manu at gcc dot gnu dot org 2010-07-02 08:07 ---
Related PR 37187
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-02 06:58 ---
I knew this couldn't be easy ;-)
Let's restrict to -pedantic first. It is the only warning flag that doesn't
start with "-W". This breaks some code that expects that every warning flag
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-01 22:52 ---
I know, I wrote that code but missed the -pedantic case. I opened PR 44774
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44752
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-01 21:53 ---
man...@gcc11:~$ ~/test2/161617M/build/gcc/cc1 empty2.c -pedantic-errors
empty2.c:1:1: error: struct has no members [-pedantic]
empty2.c:2:1: error: unnamed struct/union that defines no instances
man...@gcc11
--- Comment #1 from manu at gcc dot gnu dot org 2010-07-01 21:42 ---
I will propose to introduce -Wpedantic as the canonical name of pedantic. This
will also make -Werror=pedantic work. I don't see any reason why -pedantic has
to be special except historical. We can keep the old
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-01 21:36 ---
Is that really printing -Werror=edantic or a problem copy+pasting?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from manu at gcc dot gnu dot org 2010-07-01 21:31 ---
With the patch below, we print this:
pr40793.C:5:31: error: no matching function for call to staticPrint()
pr40793.C:2:18: note: candidate is: template void staticPrint()
but I am not sure if it is possible to
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-29 23:46 ---
I have another troublesome testcase:
/* { dg-do compile } */
/* { dg-options "-Wall -Wextra -Wc++compat" } */
#error \
In order for the format checking to accept the C front end diagnostic \
framework exten
--- Comment #14 from manu at gcc dot gnu dot org 2010-06-26 10:53 ---
> (In reply to comment #12)
> > So is g++ accepting invalid code?
>
> Yes, but it's a violation of the ODR, no diagnostic is required (it's not
> possible to tell until link tim
--- Comment #12 from manu at gcc dot gnu dot org 2010-06-26 10:35 ---
(In reply to comment #11)
> [class.static.data]/3
> If a static data member is of const literal type, its declaration in the class
> definition can specify a brace-or-equal-initializer ... The member shall
&
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build
--- Comment #9 from manu at gcc dot gnu dot org 2010-06-26 00:30 ---
Then, I reopen this as an enhancement request. If you ever find/redo the patch
or someone else decides to fix this in the same way, it would a nice
improvement for usability.
--
manu at gcc dot gnu dot org changed
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-26 00:18 ---
(In reply to comment #4)
> In the case of if, the value was "inlined" and in the case of ?:, it is not.
> I
> had a patch which changed the behavior but lost it when I moved companies.
And wha
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-25 13:14 ---
FIXED in trunk.
Such fixes are considered obvious, so feel free to commit patches to fix them.
Fixing changelogs and svn logs for typos falls also into the obvious category.
If you do not have write access, just send
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-25 13:09 ---
Subject: Bug 44665
Author: manu
Date: Fri Jun 25 13:09:28 2010
New Revision: 161380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161380
Log:
2010-06-25 Manuel López-Ibáñez
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-24 17:56 ---
Nice! But to get anything merged to GCC you need first a copyright assignment.
Otherwise, we cannot even look at your code.
http://gcc.gnu.org/contribute.html#legal
For implementing this as a plugin, you do not need
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-24 12:03 ---
(In reply to comment #3)
> I think column 0 is correct for the start of all preprocessor directives.
But the #include does not start at column 0, so there is something wrong there.
We know that libcpp col
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-22 09:27 ---
It would be more correct to say that it doesn't ICE on g++ 4.4.3, but still
error-recovery is awful:
pr44623.ii:3:137: warning: missing terminating " character
pr44623.ii:3: error: missing terminating &
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-22 09:25 ---
Confirmed in trunk.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-22 09:21 ---
Confirmed in trunk. A reduce testcase would be helpful:
http://gcc.gnu.org/bugs/minimize.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 16:51 ---
(In reply to comment #3)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > The following program compiles with g++ -O3 without errors or warnings
> >
> > Not wi
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-21 16:45 ---
(In reply to comment #1)
> (In reply to comment #0)
> > The following program compiles with g++ -O3 without errors or warnings
>
> Not with warnings enabled it doesn't!
>
???
--
manu
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 14:03 ---
And what is the difference between an ICE and an infinite loop? Both seem to be
internal errors of the compiler.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 14:00 ---
(In reply to comment #2)
> You can also use the online Comeau compiler at
> http://www.comeaucomputing.com/tryitout/ to test your assumptions. If Comeau
> and GCC both give an error then you can be 99.9%
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-20 22:25 ---
OK. So I would say confirmed, but still I am not sure how I would implement
this. So patches welcome.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-20 21:41 ---
Joseph, what do you think? Any suggestions where this may be catched? wording?
option?
I have wished for some time to create a -Wundefined option anyway.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-20 21:35 ---
I appreciate your effort reporting this but, why should we care about wrong
warnings from very very old compilers? And initializing the variables has a
cost, because optimizations cannot just assume any value
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-20 21:30 ---
I think we do not warn on purpose because unused global static const strings
are used often for storing version, metadata and stuff that may only be
conditionally compiled after preprocessing. I would argue we should
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-20 21:25 ---
Patches should be sent to gcc-patches. You may CC the libgomp maintainer
ja...@redhat.com. See also http://gcc.gnu.org/contribute.html
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-20 21:20 ---
I think this is pretty much confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-17 08:37 ---
(In reply to comment #4)
> It seems that optimizing is what's causing the problem: the example compiles
> fine with -O0, but not -On>=1. It also compiles fine when the case values are
> consecutive, wh
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-17 07:29 ---
FIXED in GCC 4.6. Thanks for the report.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-17 07:28 ---
Subject: Bug 44486
Author: manu
Date: Thu Jun 17 07:28:21 2010
New Revision: 160877
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160877
Log:
2010-06-17 Manuel López-Ibáñez
PR c++/
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-17 07:18 ---
You are right. The issue occurs in VRP but not because of the disjoint ranges.
Pass vrp1 is able to optimize your first example (nested if) but not the second
(nested switch). I think this is a missed optimization. Not
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-16 11:58 ---
(In reply to comment #3)
> > but it is an explicit specialization of the *definition* of the variable
>
> No it is a specialization of the declaration. There are only specialization
> of
> d
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-16 11:54 ---
Value range-propagation (VRP) does not work on disjoint ranges, so the compiler
does not actually know that argc can only be 1, 2 or 4. I think there is
already a PR about this but I cannot find it right now
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-13 19:33 ---
Perhaps, but the location should be at the end of the expression, where most
programmers would put the ';'. Then, mentioning '}', which may be in a totally
different line with a lot comments
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-13 17:33 ---
(In reply to comment #1)
> Actually before is more correct than saying after bar(). Because expressions
> don't need to end on the same line.
I wonder why people tend to write:
bar();
rather than
;}
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-13 17:30 ---
This column information:
t.c:2:11: note: generated from here
__asm__ ("frob%0" : "+r" (X));
^
I am not going to get into a reopen war with you anyway. I am just trying to
make a li
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-13 16:59 ---
The column information is wrong.
The diagnostic markers are inconsistent (Error versus error).
This depends on the gnu assembler, which is not the default in many places.
--
manu at gcc dot gnu dot org changed
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44527
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44524
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44523
Summary: improve diagnostic for :: vs : typo
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-13 13:49 ---
(In reply to comment #1)
>
> instead. So the warning you see is really warning about no return statement,
> not about control reaching the end of a non-void function. And it does so
> by design just f
sion: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44521
prove diagnostic for ambiguous lookup
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44519
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44517
o: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44516
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-13 12:46 ---
I don't care as long as there is a testcase that tests for this bug. Bugs
shouldn't be closed if a testcase has not been committed that prevents
regressing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16630
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugz
1 - 100 of 1573 matches
Mail list logo
