--- 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-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) || (retval INT_MAX) || (errno != 0))
return
--- 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 #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 before people start
--- 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
--- 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.
I think this is covered
--- 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 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 #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 #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 are defined
with 'const' or 'volatile
--- 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 dot org changed
--- 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
all the syntactic semantic analysis that a code
--- 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 #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 #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 #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 #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 #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 any side-effects
--- 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 should open a different bug
--- 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 bug report
--- 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 involved and existing bugs
--- 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 different story.
I mean
--- 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 English-speakers, so we
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 changed
--- 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
--- 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=gccview=revrev=161805
Log:
2010-07-04 Manuel López-Ibáñez m...@gcc.gnu.org
PR c
--- 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 #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
--- 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).
--
manu
--- 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 #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 #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 #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
starts with -W. I want
--- 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 #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 #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 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 (code
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
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
--- 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
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 #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 staticPrintdouble,
text()
pr40793.C:2:18: note: candidate is: templateclass T, T t void staticPrint()
but I am not sure
--- 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
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 #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 forms
--- 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 #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-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 extensions, you
--- 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
de#64257;nition can specify a brace-or-equal-initializer ... The member shall
still
--- 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 time that there's no definition
--- 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=gccview=revrev=161380
Log:
2010-06-25 Manuel López-Ibáñez m...@gcc.gnu.org
PR
--- 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 #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 what did your patch do exactly
--- 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
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build
--- 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 column
--- 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 #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 #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 #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 character
--- 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% sure the problem
--- 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 #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 at gcc dot gnu dot org changed
--- 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 with warnings enabled it doesn't!
Sorry,
g++ -O3
--- 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 #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 #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 #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 #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 #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 #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
--- 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=gccview=revrev=160877
Log:
2010-06-17 Manuel López-Ibáñez m...@gcc.gnu.org
PR c
--- 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 #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, which seems telling. My
--- 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-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
declarations; never definitions
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
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
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
--- 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
gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44516
: 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
: 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
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
: 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
--- 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 for functions
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
ReportedBy: manu at gcc dot gnu dot org
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
: 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
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
--- 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
--- 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 list of the diagnostic
1 - 100 of 1559 matches
Mail list logo
