https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67854
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #3 from Manuel López-Ibáñez ---
Dup of PR10138, but probably need to fix PR33086 first.
*** This bug has been marked as a duplicate of bug 10138 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Manuel López-Ibáñez changed:
What|Removed |Added
CC||developm...@faf-ltd.com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
Manuel López-Ibáñez changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #12 from Manuel Ló
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Markus Trippelsdorf from comment #0)
> If I move the cmds-check.i file to a different directory gcc no longer ICEs,
> so reducing is impossible.
What is the complete path to cmds-check.i ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Markus Trippelsdorf from comment #0)
> If I move the cmds-check.i file to a different directory gcc no longer ICEs,
> so reducing is impossible.
One idea. Do you still have cmds-check.c in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #8)
> Note that this first started to ICE with r223470, which is also the first
> revision where it starts opening cmds-check.c (which also premature to me,
> bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #8)
> Note that this first started to ICE with r223470, which is also the first
> revision where it starts opening cmds-check.c (which also premature to me,
> be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #11 from Manuel López-Ibáñez ---
(In reply to Markus Trippelsdorf from comment #6)
> Bingo! With both files present I can even reproduce it on my x86_64 machine.
Unfortunately, I cannot reproduce it with r230753, so it seems quite a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69993
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #18 from Manuel López-Ibáñez ---
I think the heuristic I implemented to figure out on which map we can encode
the new location does not work.
The heuristic assumes that if map[0].start_location <= loc + offset <
map[1].start_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #18)
> I don't really understand why this is the case: we seem to waste a lot of
> location numbers that do not point to anything. If there is a way to tel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #11 from Manuel López-Ibáñez ---
The policy of GNU software is to avoid arbitrary implementation limits whenever
possible.
(In reply to Marcel Böhme from comment #4)
> with n=2*(length of decl + length of arg) characters. Since n is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2014-11-12 00:00:00 |2016-3-3
--- Comment #7 from Manue
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
CC: bernds at gcc dot gnu.org, mpolacek at gcc dot gnu.org,
msebor at gcc dot gnu.org, unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69972
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70057
--- Comment #1 from Manuel López-Ibáñez ---
(In reply to Bernd Schmidt from comment #3)
> The C++ errors become even more entertaining when you add -fpermissive:
>
> 69972-b.cc:2:16: warning: integer overflow in expression [-Woverflow]
> 69972-b
||2016-03-03
CC||manu at gcc dot gnu.org
Summary|repetitive -Wvla warning|wrong column and repetitive
|for each non-constant |-Wvla warning for each
|dimension of a VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Leon Winter from comment #7)
> Maybe a better solution is to hint the compiler that the loop body will be
> run at least once. A do-while seems to imply that (and the compiler does not
> pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70057
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #1)
> The C++ FE has the tendency to give diagnostics very deep in the call stack,
> where there is little knowledge of the context. It would be much better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Leon Winter from comment #9)
> > If you declare it outside the loop body, gcc generates exactly the same code
> > for a 'for' and a 'do-while'.
>
> You are right. When I did the testing,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Manuel López-Ibáñez ---
Yes, we want this.
*** This bug has been marked as a duplicate of bug 44677 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
Manuel López-Ibáñez changed:
What|Removed |Added
CC||hadrien-gcc at psydk dot org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #40 from Manuel López-Ibáñez ---
(In reply to Matthew Woehlke from comment #39)
> So? People have been asking for it for at least *13+ years* (this report was
> opened in August 2002). Compared to clang which has had this feature for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178
--- Comment #15 from Manuel López-Ibáñez ---
(In reply to Leon Winter from comment #14)
> I am not sure how smart he diagnostic of GCC is supposed to be it seems that
> the source base of GCC itself has fallen victim to the false warning.
-Wmayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70181
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #11 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #10)
> maybe this location isn't supposed to be expanded?
>
> Or nothing is ever supposed to get this location?
>
> For example changing the testcase to (inva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #10)
> Not sure who's familiar with the C/C++ FE interfacing to libcpp and if
> those "bogus" locations should simply never be assigned to input_location...
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #14 from Manuel López-Ibáñez ---
(In reply to rguent...@suse.de from comment #12)
> > This is an invalid linemarker. libcpp should ignore it completely and
> > behave as
> > if it was not present. It seems it is not doing that for so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #15 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #14)
> (In reply to rguent...@suse.de from comment #12)
> > > This is an invalid linemarker. libcpp should ignore it completely and
> > > behave as
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #17)
> "caused" by r44789 which introduced this path (initially with error ||
> to_file == NULL) with a description of just
>
>(add_line_map): Return p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #20 from Manuel López-Ibáñez ---
(In reply to David Malcolm from comment #18)
> FWIW Bernd posted a different patch for this, here:
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00598.html
FWIW, if that works for all testcases he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #23 from Manuel López-Ibáñez ---
(In reply to rguent...@suse.de from comment #22)
> Maybe we can put the error under some new flag though.
Does Bernd's patch still work if we just warn instead of error? I still think
doing this in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #28 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #25)
> Yes, Bernd's patch still works then. I'd prefer this at this stage.
> There doesn't seem to be any CPP_W_* that fits though.
Do you need one? Perhaps -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #29 from Manuel López-Ibáñez ---
(In reply to Bernd Schmidt from comment #26)
> Also, let's keep in mind the issue David found - "left but not entered"
> seems like a misleading message, something like "unexpectedly reentered"
> seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #32 from Manuel López-Ibáñez ---
(In reply to David Malcolm from comment #31)
> I may have been wrong in my earlier question on the mailing list; doesn't
> the flag value of 2 mean "LC_LEAVE"? (is the filename meant to refer to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #34 from Manuel López-Ibáñez ---
(In reply to Bernd Schmidt from comment #33)
> It does mean LC_LEAVE, but AFAICT the filename is the file being returned to.
>
> Including a file called "t.h" from "v.c" gives this after -E:
>
> # 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #36 from Manuel López-Ibáñez ---
(In reply to Bernd Schmidt from comment #35)
> I don't think guesswork will be very helpful in practice with a corrupted
> #line structure, and errors of this nature shouldn't really occur anyway
> out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70275
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||manu at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Manuel López-Ibáñez ---
(In reply to Isabella from comment #0)
> This is more of a question than a bug report: does that code need a default
> case? I think it sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70275
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Kevin Tucker from comment #3)
> I'm new to this. How is is determined if this is a desired change or not?
Suggestion #10 applies also to non-patches: https://gcc.gnu.org/wiki/Community
I
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
According to the manual, -Werror=foo implies -Wfoo, however, these two
command-lines:
$ gcc -std=c89 -c -Werror=return-type -Wreturn-type -Wno-all test.c
$ gcc -std=c89 -c -Werror=return-type
|UNCONFIRMED |NEW
Last reconfirmed||2016-04-02
CC||manu at gcc dot gnu.org
Target Milestone|--- |5.4
Summary|Incorrect Wconversion |[5/6 regression] Incorrect
|NEW
Version|unknown |6.0
Keywords||diagnostic
Last reconfirmed||2016-04-02
CC||manu at gcc dot gnu.org
Host|x86_64-w64
||2016-04-02
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Manuel López-Ibáñez ---
I don't see this any longer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70514
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70518
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70514
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Chris Warrick from comment #5)
> Thanks for debugging my code, and sorry for wasting time.
No problem. It is a pity that GCC static analysis capabilities are not powerful
enough to catch t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70173
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
|UNCONFIRMED |NEW
Last reconfirmed||2016-04-03
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from Manuel L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68845
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35587
Manuel López-Ibáñez changed:
What|Removed |Added
CC||Gildos at gmail dot com
--- Commen
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #8 from Manuel López-Ibáñez ---
A variant that is not optimized out, yet not warned until -O2:
void foo(int *p);
void warning(void)
{
int pippo[100];
pippo[1] = 0;
pippo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70336
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 38172 [details]
> gcc6-pr70336.patch
>
> IMNSHO -Wconversion is totally useless warning, and one where if you want to
> avoid "false pos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70378
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #2)
> Simpler testcase:
>
> typedef unsigned int uint32_t;
> void foo(char a, uint32_t b)
> {
> b = (uint32_t)((b * 10) + (uint32_t)a);
> }
>
> Somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70524
--- Comment #1 from Manuel López-Ibáñez ---
What is the gfc_warning* call that produces the ICE? Backtrace?
It seems gfortran is generating a NULL loc or loc->lb, or it is keeping an
invalid value of loc->nextc or loc->lb->line. This might be du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70336
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 38173 [details]
> gcc6-pr70336.patch
>
> Patch to revert (for GENERIC only) the match.pd change that causes this
> regression.
Does it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70336
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #8)
> Here -Wconversion will warn for many casesm even in 4.9, eventhough one
> could argue that say in the f4 case nothing is lost during conversion, or
There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70475
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||manu at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #6 from Manuel López-Ibáñez ---
It seems this was fixed a long time ago. Oldest ICE-on-valid!
||2016-04-05
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8960
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords|ice-on-valid-code |
Last reconfirmed|2008-12-06 09:3
:00:00 |2016-4-5
CC||manu at gcc dot gnu.org
Summary|ICE in tsubst with |accepts invalid duplicate
|declaring then defining a |definition of member
|member template |template
||2016-04-05
CC||manu at gcc dot gnu.org
Version|4.4.2 |6.0
Ever confirmed|0 |1
--- Comment #4 from Manuel López-Ibáñez ---
Still fails with 6.0
||manu at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #6 from Manuel López-Ibáñez ---
No answer in years, closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #42 from Manuel López-Ibáñez ---
(In reply to Roger Orr from comment #41)
> I have seen the message before: for example from a build with revision
>
> line-map.c: file "/usr/include/asm/sockios.h" left but not entered
You can also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70518
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to jos...@codesourcery.com from comment #4)
> On Tue, 5 Apr 2016, manu at gcc dot gnu.org wrote:
>
> > According to the manual, if an extension is not incompatible with the base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #6)
> But that wouldn't make any difference between 0x123p-2 and 0x123p - 2
> (or some of them coming from macro, other not etc.).
> So perhaps you want to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Axel Naumann from comment #2)
> You asked for it, so here is my wish list:
> - for C++ < 1z, do not support hexfloats, neither with "unsigned" not
> negative exponents.
Since "unsigned" ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Manuel López-Ibáñez changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Commen
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Manuel López-Ibáñez ---
(In reply to Matt Godbolt from comment #0)
> In the move case, there's no such warning. I appreciate this is probably
> diffic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29280
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #5)
> It seems like it should be trivial to enhance the warning by adding a note
> with the suggestion(s) mentioned in the request.
Given all the cases mentioned
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-04-19
CC||manu at gcc dot gnu.org
Depends on||43486
Ever confirmed|0 |1
--- Comment #1 from
||manu at gcc dot gnu.org
--- Comment #20 from Manuel López-Ibáñez ---
(In reply to Bernhard Reutner-Fischer from comment #19)
> (In reply to Denis Vlasenko from comment #17)
> > Any chance of this being finally done?
> >
> > I proposed a simple, workin
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Manuel López-Ibáñez ---
This is a well-known problem with the pragmas for C++ diagnostics in libcpp. I
tried to find a solution, but there were some issues I could not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
Manuel López-Ibáñez changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comm
||2016-05-01
CC||manu at gcc dot gnu.org
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to Andrew Pinski from comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Andrew Pinski from comment #3)
> There is no internals of GCC here. Rather the user specified all warnings
> at link time. If the user did not want that then they did not need to
> supply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70859
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #15 from Manuel López-Ibáñez ---
Indeed, we also warn for
void bar(int x)
{
if (x)
for (int i = x; i < 5; i++)
if (i != 0)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #17 from Manuel López-Ibáñez ---
(In reply to Pedro Alves from comment #16)
>
> This could also be sorted out with indentation level tracking -- the if
> binds to the else in the macro, but it is not indented as one would expect
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #16 from Manuel López-Ibáñez ---
(In reply to Eric Gallager from comment #15)
> That has since been closed as fixed. So are the chances of this one being
> fixed next somewhat better now?
Not really. PR23608 fixes the case where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70987
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71010
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
--- Comment #16 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #1)
> which is probably an artifact of fully delayed folding.
Do you mean "early folding"? Because "delayed" folding should not apply any
optimizations and not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71108
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71115
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71115
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #7)
> Thanks, Manuel. That does the trick. Let me put a patch together.
Note also that the extra:
uu.c:3:26: note: (near initialization for ‘a’)
is just a rel
1101 - 1200 of 2545 matches
Mail list logo
