https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #35 from Manuel López-Ibáñez ---
(In reply to Niels Möller from comment #32)
> 1. There's similar code in c_fully_fold_internal, in gcc/c/c-fold.c, close
> to line 400. But that code does *not* emit any warning for the example
> above,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||manu at gcc dot gnu.org
Keywords||easyhack
--- Comment #6 from Manuel López-Ibáñez ---
Probably a dup of bug 19808. There is an unfinished patch there that does the
check in the FE. That would side-step issues with A being empty (you just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||easyhack
--- Comment #5 from Manue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
Manuel López-Ibáñez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to David Brown from comment #7)
> Could "-Wwrite-strings" be split into two options? The warning could remain
> (and become part of -Wall for C as well as C++) if the compiler can spot and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Manuel López-Ibáñez changed:
What|Removed |Added
CC||felix at piedallu dot me
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 96368, which changed state.
Bug 96368 Summary: False negative with maybe-uninitialized with goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96368
What|Removed |Added
--
|--- |DUPLICATE
CC||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez ---
I'm pretty sure this is PR18501.
pktio_read() creates a PHI node and prevents CCP deleting the undefined value.
*** This bug has been mark
||manu at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-07-29
--- Comment #2 from Manuel López-Ibáñez ---
This seems some kind of weird missed optimization because this variant does
warn:
struct S { int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96368
Manuel López-Ibáñez changed:
What|Removed |Added
Status|VERIFIED|RESOLVED
--- Comment #3 from Manue
|variable warning with |uninitialized variable
|branches at -O1 and higher |warning with difficult
||control-flow analysis
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95848
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=94905
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=94905
Manuel López-Ibáñez changed:
What|Removed |Added
Summary|Bogus warning |[10 Regression] Bogus
|--- |FIXED
CC||manu at gcc dot gnu.org
--- Comment #4 from Manuel López-Ibáñez ---
Seems fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 94774, which changed state.
Bug 94774 Summary: Uninitialized variable retval in function
try_substitute_return_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94774
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Tony E Lewis from comment #7)
> Manuel López-Ibáñez: are you happy that all underlying issues are resolved
> and this can be closed?
Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66099
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
CC: msebor at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
According to GCC 8, Wstrict-overflow is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2013-01-07 00:00:00 |2019-11-2
--- Comment #8 from Manu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
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=92330
--- Comment #1 from Manuel López-Ibáñez ---
Actually, it is not even deprecated. There are still a bunch of
Wstrict-overflow warnings, just some of them got removed.
Is there a way to tell which ones are still active and update the
documentati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
--- Comment #4 from Manuel López-Ibáñez ---
I'm 100% convinced this has nothing to do with locations and all to do with how
-Warray-bounds and -Wstringop-overflow= interact.
Change the ignored for error,
char one[50];
char two[50];
void
test_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
--- Comment #5 from Manuel López-Ibáñez ---
333 Warray-bounds
334 LangEnabledBy(C ObjC C++ LTO ObjC++)
335 ; in common.opt
This seems wrong, the second argument ", Wall" is missing. Moreover, this
probably should be an Alias for some -Warray-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90058
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||2019-11-02
CC||manu at gcc dot gnu.org
Depends on||49754, 79658
Summary|missing uninitialized |missing uninitialized
|warning: laundering via |warning for
||2019-11-02
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez ---
For the Wuninit, this is PR18501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 89192, which changed state.
Bug 89192 Summary: -Wuninitialized doesn't warn about a vector initialization
with uninitialized field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89192
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Manuel López-Ibáñez changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
--- Comm
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #4 from Manuel López-Ibáñez ---
Duplicated
*** This bug has been marked as a duplicate of bug 19808 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
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 #6 from Manuel López-Ibáñez ---
Not a bug per comment #5
||manu at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to tangyixuan from comment #3)
> Error handler should not stop at the first error and report the errors as
> many as possible.
This
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Manuel López-Ibáñez ---
When reporting a Wuninitialized bug please check PR24639. 99% of the cases are
duplicated of an existing report.
*** This bug has been marked as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43361
Manuel López-Ibáñez changed:
What|Removed |Added
CC||tangyixuan at mail dot
dlut.edu.cn
|UNCONFIRMED |NEW
Last reconfirmed||2019-12-16
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez ---
This one would be useful to have and
|UNCONFIRMED |NEW
Last reconfirmed||2019-12-16
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez ---
The key here is to add the fix-hit hint
CC||manu at gcc dot gnu.org
Summary|-Wignored-qualifiers points |-Wignored-qualifiers points
|to diff location|to wrong location and
||doesn't mention
||2019-12-16
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Manuel López-Ibáñez ---
This should be suspended until someone comes up with a proposal for reviving
-Wunreachable
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-16
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #6 from Manuel López-Ibáñez ---
The fact that GCC points to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92826
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to kim.walisch from comment #0)
> GCC should definitely not warn when using constants from . GCC
> should also provide an option to disable these warnings (e.g.
> -Wno-non-standard-suffix). Pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #34 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #15)
> I think the following smaller test case independent of libstdc++ captures
> the same issue as the bigger test case in comment #4. Again, declaring f()
> n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #35 from Manuel López-Ibáñez ---
In any case, looking at the uninit dump with -fdump-tree-all-all-lineno it
appears that GCC knows the block where the warning is triggered is never
executed:
;; basic block 13, loop depth 0, count 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #216 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #215)
> According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
> the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202
--- Comment #7 from Manuel López-Ibáñez 2013-02-04
17:29:41 UTC ---
I don't understand the check for __e.
If you continue, then neither __t nor __x change, the only difference is that
you sample a new __e. But __e doesn't have any effect in th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202
--- Comment #8 from Manuel López-Ibáñez 2013-02-04
17:35:00 UTC ---
I would understand something like:
const double __e = -std::log(1.0 - __aurng());
if (__t == __x)
{
return __x;
}
el
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202
--- Comment #10 from Manuel López-Ibáñez 2013-02-04
18:58:18 UTC ---
(In reply to comment #9)
> You are right, but then I don't understand why we should compute __e *before*
> checking __t == __x, per your first patch (I think I managed to confu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202
--- Comment #11 from Manuel López-Ibáñez 2013-02-04
19:00:22 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > You are right, but then I don't understand why we should compute __e
> > *before*
> > checking __t == __x, per your fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54582
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54582
--- Comment #8 from Manuel López-Ibáñez 2013-02-06
13:39:32 UTC ---
(In reply to comment #7)
> Because object sizes are finalized only during the objsz pass, after lots of
> optimization passes. Note, as I said earlier, what matters most is tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56418
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
--- Comment #10 from Manuel López-Ibáñez 2013-02-26
11:19:34 UTC ---
(In reply to comment #9)
> Clang accepts the old name silently.
> I am not sure about "forever",
> clang will probably start printing a "deprecated" warning at some point.
W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56497
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56589
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265
--- Comment #12 from Manuel López-Ibáñez 2013-03-11
16:49:25 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> > Not sure about the warning wording
>
> What about (... "iteration %E invokes undefined behavior", max)?
>
> > plus no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56599
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||manu at gcc dot gnu.org
--- Comment #12 from Manuel López-Ibáñez 2013-03-14
15:43:28 UTC ---
(In reply to comment #11)
> I'm not familiar with gcc's backport process; is there anything I can do to
> help that along? Is it already in-queue?
I guess Jakub i
||2013-03-25
CC||manu at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez 2013-03-25
22:55:48 UTC ---
This is because the second error is not an error but a note clarifying with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #3 from Manuel López-Ibáñez 2013-03-25
23:07:00 UTC ---
BTW, in this case, I find the output of g++ much better than that of clang++
test.cc:7:10: error: no matching function for call to 'callf'
return callf (23, 72,
^~~~
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #2 from Manuel López-Ibáñez 2013-03-25
23:03:42 UTC ---
Note that there are a fair amount of calls like these in the C++ FE, and the
use is inconsistent. I guess the indentation predates the use of inform, and
this is why there are s
||2013-03-26
CC||manu at gcc dot gnu.org
Summary|C++ compiler produces |Improve message and add an
|warning for an unnamed |option for warning for an
|struct member: TYPE has a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
--- Comment #18 from Manuel López-Ibáñez 2013-03-27
00:59:43 UTC ---
(In reply to comment #17)
> (In reply to comment #16)
> >
> > If you have some developer power to spare, it may be worthwhile to try to
> > tackle this yourself. Otherwise I a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #5 from Manuel López-Ibáñez 2013-03-27
17:43:02 UTC ---
(In reply to comment #4)
> Hi Manuel. I wanted to actually handle this per your indications and move on,
> but I don't understand why you check the return value of permerror: sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #7 from Manuel López-Ibáñez 2013-03-27
19:46:57 UTC ---
(In reply to comment #6)
> I haven't tested anything so far, but stared a bit at the comment before
> permerror and figured tgat in case of plain error (vs warning) the function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #8 from Manuel López-Ibáñez 2013-03-27
19:48:21 UTC ---
(In reply to comment #7)
> manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive
> test.cc:4:5: note: initializing argument 3 of ‘int callf(int, int, int
> (*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #10 from Manuel López-Ibáñez 2013-03-27
20:24:47 UTC ---
No, true means something was reported (error or warning), false means that
nothing was reported. The same as for pedwarn and warning. pedwarn also returns
true for --pedantic-e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #12 from Manuel López-Ibáñez 2013-03-27
20:37:05 UTC ---
That was the intention, if the comment or the behaviour does not match this,
then I did a mistake implementing it, and it is a bug in my opinion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #15 from Manuel López-Ibáñez 2013-03-30
12:32:08 UTC ---
(In reply to comment #13)
> I guess the C/C++ FEs could for non-trivial string literals put into a hash
> table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the fir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #16 from Manuel López-Ibáñez 2013-03-30
12:32:57 UTC ---
Created attachment 29753
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29753
loc_token_hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Manuel López-Ibáñez changed:
What|Removed |Added
CC||joseph at codesourcery dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #19 from Manuel López-Ibáñez 2013-03-30
13:26:19 UTC ---
Unfortunately, there are some stuff like this:
BLK
size
unit size
align 8 symtab 0 alias set -1 canonical type 0x770945
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #20 from Manuel López-Ibáñez 2013-03-30
15:02:11 UTC ---
(In reply to comment #18)
> > * It would be extremely nice to update the testsuite to check the locations
> > are
> > correct. This is unfortunately a lot of boring work, so i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #21 from Manuel López-Ibáñez 2013-03-30
15:03:14 UTC ---
Created attachment 29755
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29755
add locations and offsets to format warnings
My current patch, untested except for a few tes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #22 from Manuel López-Ibáñez 2013-04-01
14:17:45 UTC ---
(In reply to comment #13)
> and didn't need to be translated. So, printf ("%.*d"); (the common case)
> wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d")
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Manuel López-Ibáñez changed:
What|Removed |Added
Attachment #29753|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
--- Comment #8 from Manuel López-Ibáñez 2013-04-03
09:40:30 UTC ---
(In reply to comment #7)
> In practice the warning (a pedwarn) is emitted by code shared with the C
> front-end, the error (a permerror, thus with -fpermissive it can be demoted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
--- Comment #13 from Manuel López-Ibáñez 2013-04-03
11:53:23 UTC ---
(In reply to comment #9)
> Ok Manuel, thanks. I'm not completely convinced by the
>
> else if ((pedantic || warn_pointer_arith)
>
> which is protecting the permerrors (a -W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
Manuel López-Ibáñez changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
--- Comment #16 from Manuel López-Ibáñez 2013-04-03
12:12:15 UTC ---
BTW, I also see that in c-family/c.opt -Wpointer-arith is not LangEnabledBy(C
ObjC C++ ObjC++,Wpedantic). If it was, then -Werror=pedantic will automatically
handle -Werror=poi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
--- Comment #22 from Manuel López-Ibáñez 2013-04-04
10:38:06 UTC ---
(In reply to comment #21)
> Manuel, I'm adding the LangEnabledBy, to match the documentation. Thanks.
>
> Now, I'm not sure to understand the existing lines (many):
>
> ped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #25 from Manuel López-Ibáñez 2013-04-05
22:02:26 UTC ---
I am currently stuck on the three problems I described above and I cannot
figure out a way to fix any of them:
* How to reprocess tokens that need to be translated/have prefix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856
Bug #: 56856
Summary: the location of -Wformat warnings point *after* the
format string
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
--- Comment #16 from Manuel López-Ibáñez 2013-04-09
18:04:14 UTC ---
(In reply to comment #15)
> Manuel, compile_file changed with this commit:
>
> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=118362
>
> I seem to remember that anoth
||2013-04-10
CC||manu at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from Manuel López-Ibáñez 2013-04-10
18:32:00 UTC ---
I think the problem is the continue, which moves to the next i--:
Index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56824
--- Comment #5 from Manuel López-Ibáñez 2013-04-12
09:12:32 UTC ---
Probably the while loop is looping forever in the continue. I don't have time
to investigate this, but I am pretty sure that the bug is somewhere there. If
you use gdb to invest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
Manuel López-Ibáñez changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #16 from Manuel
||manu at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #1 from Manuel López-Ibáñez 2013-04-15
18:46:59 UTC ---
Infamous PR18501. With:
~/test1/197214/build/gcc/cc1 -Wall -Wextra -O1 pr56972.c -fdump-tree-all-lineno
you can see that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Manuel López-Ibáñez changed:
What|Removed |Added
CC||ppluzhnikov at google dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980
--- Comment #1 from Manuel López-Ibáñez 2013-04-16
15:24:46 UTC ---
Confirmed, but I seriously doubt it has anything to do with my patch. At the
moment of warning we get:
(gdb) p debug_tree(type)
unit size
align 32 symtab 0 a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Man
1 - 100 of 2542 matches
Mail list logo
