[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=93910,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=92900,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=68160,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=60972
--- Comment #12 from Eric Gallager ---
(In reply to Rene Rahn from comment #10)
> I know this is quite old now. But can someone explain me why using `#pragma
> pack(push, 1)` does work then? I couldn't find enough resources on that. The
> only thing I found is, that it does literally the same. But wouldn't then
> the references/pointers still not be valid?
>
> So if I change the code to:
>
> ```
> #pragma pack(push, 1)
> struct Squeeze
> {
> short s;
> };
> #pragma pack(pop)
> ```
>
> Then it works on godbolt with gcc-trunk.
There are several bugs open about inconsistencies between
__attribute__((packed)) and #pragma pack; see for example: bug 93910, bug
92900, bug 68160, and bug 60972
[Bug c/84919] [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #22 from Eric Gallager --- (In reply to Martin Sebor from comment #20) > Fixed on trunk (GCC 10). The fix cannot be backported on its own without > introducing false negatives. so... if it can't be backported... then does this bug need to stay open?
[Bug translation/90119] Merge translation msgids that only differ in placeholders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- I think Roland has another bug open that is similar to this one, but I forget the number...
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Bug 84774 depends on bug 84919, which changed state. Bug 84919 Summary: [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/84919] [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 Eric Gallager changed: What|Removed |Added Known to work||10.0 Known to fail||9.3.0 Target Milestone|9.4 |10.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #24 from Eric Gallager --- (In reply to Martin Sebor from comment #23) > I think that's a question for the release managers. I thought they like to > keep regressions open until all the affected branches have closed, but I > could be wrong. One way to find out is to close it and let them reopen it :) ok, I'll do that
[Bug c++/67960] [8/9 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #10 from Eric Gallager --- (In reply to Patrick Palka from comment #8) > Fixed on trunk by r10-7159. so... keeping open for backports, I take it?
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #27 from Eric Gallager --- (In reply to r...@cebitec.uni-bielefeld.de from comment #26) > > --- Comment #25 from Iain Sandoe --- > > (In reply to r...@cebitec.uni-bielefeld.de from comment #24) > >> > --- Comment #23 from Iain Sandoe --- > >> > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any > >> > SDK >= > >> > Xcode commandline tools 11.3b. > >> > >> I've recently tried both building gcc 8.3.0 (build only) and master > >> (full bootstrap and test) on macOS 10.14.6 and 10.15.3, each with Xcode > >> 11.3.1. Both worked *provided the build and target compilers were > >> configured with the approriate --with-sysroot to account for the lack of > >> /usr/include and startup objects in /usr/lib*. > > > > That's not going to change, I think (at least, the underlying behaviour). > > Indeed, we'll have to live with that. > > > We could entertain and implement a change to Darwin's configuration that > > automatically discovers the /Library/Developer/CommandLineTools .. or > > /Applications/Xcode... for Darwin versions >= X and complains of fails to > > configure if those can't be seen (asking for a --with-sysroot=). > > That's one option, certainly easier for the users. At the least, the > issue should be documented in install.texi so they can add > --with-sysroot manually if need be. I just noticed that the install > docs only have a small section on PowerPC Darwin, nothing else... > > > We can already invoke GCC like "xcrun /path/to/gcc-exe" provided that is not > > called "gcc" or "g++" it will work to set the SDKROOT which gcc honours from > > 7.5+. > > > > The only irritation is that we can't use 'gcc' or 'g++' in that position, > > because xcrun places the clang/++ aliases ahead of the GCC in the PATH > > (even if > > the GCC install is first) [last time I tried]. > > Sounds like a bad mess and totally unexpected. Besides, the additional > exec will have some cost. No idea how measurable it would be for a > bootstrap, though. > > > There's also an API to obtain the info - but only on 10.15+ and it forces > > one > > to install XCode I suspect to use it, I'm not keen on making new > > dependencies > > on things outside our control - I'd rather make use of OSS equivalents. > > Understood. In particular when Xcode.app can be installed anywhere, not > just in /Applications. Maybe something to talk about with Jeremy > Sequoia, perhaps it can be provided from some stable location? I think it has come up in some other bug...
[Bug web/94349] Bugzilla user preferences are blank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94349 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- hm, maybe this is why bugzilla has been acting strangely for me lately? (forgetting my "last visited" date on bugs, randomly un-cc-ing me without it showing up in the bug history...)
[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||egallager at gcc dot gnu.org --- Comment #25 from Eric Gallager --- (In reply to Nathan Sidwell from comment #23) > Fixed trunk and gcc-9 And 8 now too: (In reply to CVS Commits from comment #24) > The releases/gcc-8 branch has been updated by Nathan Sidwell > : > > https://gcc.gnu.org/g:4c36b54de7ddbcb580f4b99936af4a0195db9d2f > > commit r8-10145-g4c36b54de7ddbcb580f4b99936af4a0195db9d2f > Author: Nathan Sidwell > Date: Fri Mar 27 13:24:27 2020 -0700 > > c++: Fix ICE on popping local scope [pr84733] > > PR c++/84733 > * name-lookup.c (do_pushdecl): Look through cleanp levels. So, FIXED.
[Bug middle-end/81172] Expected new warning option -Warray-bounds-pointer-arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81172
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #7 from Eric Gallager ---
(In reply to Martin Sebor from comment #6)
> For the slightly modified test case GCC 10 issues the expected warnings in
> the expected cases (i.e., unless the code is removed as unused, etc.) So I
> think this can be resolved as fixed. (There are plenty of other cases that
> still aren't diagnosed; please open new bugs for those if they aren't
> already being tracked under pr56456).
>
> $ cat pr81172.c && gcc -O2 -S -Wall pr81172.c
>
> int a[] = {1,2,3,4};
>
> int* f (void)
> {
> int *p = a + 5;
> return p;
> }
>
> const char s[] = "aaa", t[] = "b";
>
> const char* g (void)
> {
> const char *p = s + __builtin_strlen (t);
> return p;
> }
>
> const char* h (void)
> {
> return s + 'c';
> }
> pr81172.c: In function ‘f’:
> pr81172.c:5:8: warning: array subscript 5 is outside array bounds of
> ‘int[4]’ [-Warray-bounds]
> 5 | int *p = a + 5;
> |^
> pr81172.c:1:5: note: while referencing ‘a’
> 1 | int a[] = {1,2,3,4};
> | ^
> pr81172.c: In function ‘g’:
> pr81172.c:13:15: warning: array subscript 5 is outside array bounds of
> ‘const char[4]’ [-Warray-bounds]
>13 | const char *p = s + __builtin_strlen (t);
> | ^
> pr81172.c:9:12: note: while referencing ‘s’
> 9 | const char s[] = "aaa", t[] = "b";
> |^
> pr81172.c: In function ‘h’:
> pr81172.c:19:12: warning: array subscript 99 is outside array bounds of
> ‘const char[4]’ [-Warray-bounds]
>19 | return s + 'c';
> | ~~^
> pr81172.c:9:12: note: while referencing ‘s’
> 9 | const char s[] = "aaa", t[] = "b";
> |^
I'd think breaking this into a separate sub-option as previously suggested
would still be useful; I can see people wanting other -Warray-bounds warnings
but not these, and vice versa
[Bug tree-optimization/30334] [meta-bug] Request for -Wundefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #18 from Eric Gallager --- (In reply to Martin Sebor from comment #17) > I agree with the goal of detecting undefined behavior but I don't think a > catchall warning option like -Wundefined would be very helpful. Not all > kinds of undefined behavior are of the same severity so providing a single > option for all of it would make it hard to clean up code with more than just > a handful of instances of it. Especially for late warnings that are > susceptible to false positives, being able to control them in a targeted way > is important. > > The trend over the last years has been toward providing granular warning > options to control the detection of specific/related kinds of problems, like > -Warray-bounds, or -Wuninitialized. and even those could be more granular; for -Warray-bounds clang has a separate -Warray-bounds-pointer-arithmetic (bug 81172), while for -Wuninitialized, gcc has a separate -Wmaybe-uninitialized (and, with the static analyzer, -Wanalyzer-use-of-uninitialized-value), while clang has a separate -Wsometimes-uninitialized and -Wconditional-uninitialized
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Eric Gallager changed: What|Removed |Added Summary|[meta-bug] Issues that |[meta-bug] Issues in gcc |static analyzers (cppcheck, |that other static analyzers |clang-static-analyzer) find |(cppcheck, |that gcc misses |clang-static-analyzer, ||PVS-studio) find that gcc ||misses --- Comment #8 from Eric Gallager --- updating title to include PVS studio bugs
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 --- Comment #9 from Eric Gallager --- (In reply to Eric Gallager from comment #8) > updating title to include PVS studio bugs actually it looks like there was already a previous meta-bug for PVS-Studio, bug 77421, but it's closed already... do we want to reopen that one, or use this one for PVS-Studio bugs as well?
[Bug objc/94637] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #2 from Eric Gallager --- cc-ing Objective C maintainers
[Bug ipa/94693] IPA SRA should elide unused out parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94693 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=68230 CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- is there an opportunity to extend -Wunused-parameter here, too? I don't get anything from it currently... (see also bug 68230 for another case where IPA SRA could help extend -Wunused-parameter)
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 Eric Gallager changed: What|Removed |Added Blocks||89863 See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=89863 | CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- moving the cppcheck meta-bug from the "See Also" field to the "Blocks" field Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 [Bug 89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
[Bug preprocessor/94657] [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94657 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- please submit the patch to the gcc-patches mailing list for review
[Bug preprocessor/94657] [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94657 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-April/5 ||44379.html Keywords||patch --- Comment #3 from Eric Gallager --- (In reply to Sergei Trofimovich from comment #2) > Sent as https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544379.html thanks, adding the "patch" keyword
[Bug middle-end/4210] should not warn in dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #40 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #39) > I think these questions are more appropriate for the mailing list, since > few people are subscribed to this bug. There were more previously, but a lot of people got dropped from cc lists all throughout bugzilla in the process of transferring servers... I was on this one previously, for example, but now I'm having to re-subscribe... > > You can easily find which pass does something by dumping (-ftree-dump-*) > all of them and comparing them. > > On Wed, 6 May 2020, 09:11 nisse at lysator dot liu.se, < > gcc-bugzi...@gcc.gnu.org> wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 > > > > --- Comment #38 from Niels Möller --- > > Just a brief update. > > > > 1. Tried adding fprintf warnings to c_gimplify_expr (btw, what's the right > > way > > to display a pretty warning with line numbers etc in later passes?). But it > > seems that's too early, I still get warnings for dead code. > > > > 2. The pass_remove_useless_stmts, mentioned in the docs, was deleted in > > 2009 > > (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41573), and I take it > > it was > > obsoleted earlier, since there's no mention of a replacement. So what pass > > should I look at that is related to basic control flow analysis, and > > discarding > > unreachable statements? > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug.
[Bug bootstrap/84257] Extremely slow compilation from gcc source code under macOS 10.13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to 191919 from comment #2) > I tried with the combination of the following settings under macOS 10.13.3: > > internal SSD / external HD > HFS+ / APFS > SIP enabled / SIP disabled > > The only factor that affects is SIP status. Once I disable it, > DYLD_LIBRARY_PATH will be exported, then the scripts run slowly. > > I have reported the problem to Apple, but since turning off SIP is not > recommended, I don't think they are going to fix it in short future. This is a great example of why it'd be so good to have a fully-FOSS fork of Darwin that can make different recommendations about things like that.
[Bug target/91520] AVX512 target assembler fails for x86_64 Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91520 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Iain Sandoe from comment #1) > > I plan on publishing an update to my alternate assembler/linker pair that > incorporates the changes from LLVM-9 and isn't dependent on the release > schedule for Xcode. Have you published this update yet?
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #34 from Eric Gallager --- (In reply to Giuliano Belinassi from comment #32) > (In reply to Eric Gallager from comment #31) > > I think this came up at Cauldron, but I forget what exactly people said > > about it... > > Actually this PR comes before Cauldron 2019. By "came up" I meant simply that it was mentioned, not that that was where it originated...
[Bug other/84889] Ideas on revamping how we format diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|WAITING CC||egallager at gcc dot gnu.org --- Comment #21 from Eric Gallager --- (In reply to Eric Gallager from comment #19) > (In reply to Martin Liška from comment #18) > > @David: Can we close this now? > > I'm guessing he's probably waiting for his static analyzer to be merged; > that patch series looked like it had some stuff relevant to this bug in it ok, the static analyzer has been merged... so, David, can we close this now?
[Bug objc++/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #1 from Eric Gallager --- cc-ing objc++ maintainers
[Bug libbacktrace/88745] Darwin lacks an implementation for libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745 --- Comment #13 from Eric Gallager --- (In reply to Ian Lance Taylor from comment #12) > Fixed. Thanks, I backported the changeset to the (old) copy of libbacktrace I keep in my fork of gdb and it only took a few tweaks to get it to compile. Now to see if it actually works once I update gcc...
[Bug analyzer/95007] RFE: -fanalyzer should complain about writes to string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95007 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95000, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=61579 Keywords||diagnostic CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- You don't even need the analyzer for this; -Wwrite-strings already catches it: $ /usr/local/bin/gcc -c -Wall -Wextra -Wwrite-strings 95007.c 95007.c: In function 'test': 95007.c:3:12: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 3 | char *s = "foo"; |^ $ If you edit the source code to make 's' const to fix the -Wdiscarded-qualifiers warning, you then get this error instead: $ /usr/local/bin/gcc -c -Wall -Wextra -Wwrite-strings 95007.c 95007.c: In function 'test': 95007.c:4:7: error: assignment of read-only location '*s' 4 | s[0] = 'g'; | ^ $ Although, I guess it is true that there are some drawbacks to using -Wwrite-strings, for example those described in bug 61579, so maybe having a separate analyzer warning for this could still be useful...
[Bug tree-optimization/94086] Missed optimization when converting a bitfield to an integer on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94086 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- Possibly related to and/or a dup of bug 83784?
[Bug middle-end/66364] poor optimization of packed structs containing bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- there are some other bugs open that are similar to this; I am tired though so I'll pull their numbers back up later...
[Bug tree-optimization/95097] Missed optimization with bitfield value ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95097 Eric Gallager changed: What|Removed |Added Last reconfirmed||2020-05-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Blocks||85316 Keywords||missed-optimization CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Confirmed via godbolt: https://godbolt.org/z/FexRgJ Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78352 Blocks||54367 CC||egallager at gcc dot gnu.org --- Comment #24 from Eric Gallager --- (In reply to Iain Sandoe from comment #6) > > We (at least several of us) agree that this is a source of easy programming > errors - and I expect there to be some revisiting in c++23. That's a > considerable challenge in the face of a mutable lambda - maybe (thinking > aloud) needs something like Apple blocks, but with an automatic promotion of > the closure to a heap object if it escapes the creating scope. ...(Apple blocks support is bug 78352, for reference)... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 [Bug 54367] [meta-bug] lambda expressions
[Bug other/94182] Improve -Wchar-subscripts documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org Summary|Document -Wchar-subscripts |Improve -Wchar-subscripts ||documentation Ever confirmed|0 |1 Last reconfirmed||2020-05-19 Status|UNCONFIRMED |NEW --- Comment #4 from Eric Gallager --- retitling to clarify what exactly the issue is, and confirming
[Bug libfortran/95177] error: array subscript has type char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||build, diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94182 --- Comment #3 from Eric Gallager --- (In reply to Roland Illig from comment #2) > >--- Comment #1 from kargl at gcc dot gnu.org --- > >Why cast to unsigned char? The prototypes for tolower(), toupper(), > >isdigit(), etc show that the type of the argument is int. > > See https://stackoverflow.com/a/60696378 for a detailed explanation. ...which in turn led to bug 94182
[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170 Eric Gallager changed: What|Removed |Added CC||in-gcc at baka dot org --- Comment #22 from Eric Gallager --- *** Bug 95213 has been marked as a duplicate of this bug. ***
[Bug c/95213] GCC -Werror=conversion error when assigning to a bitfield (when mixing constants and variables)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95213 Eric Gallager changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- dup of bug 39170 *** This bug has been marked as a duplicate of bug 39170 ***
[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-May/546 ||179.html Keywords||patch --- Comment #8 from Eric Gallager --- (In reply to Michael Kuhn from comment #7) > Took me a while, sorry. I have just sent the patch to the list. for reference, that patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546179.html
[Bug c++/79627] Ice with type of VLA in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79627 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||16994, 54367 --- Comment #5 from Eric Gallager --- (In reply to Martin Liška from comment #4) > (In reply to Arseny Solokha from comment #3) > > It is fixed for gcc 10, probably by > > g:00a49cd840f60774b0e9e0109fb10559bc9a9194. > > Yes, it's fixed with this commit. So... is there a reason to leave this bug open then? Backports? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 [Bug 16994] [meta-bug] VLA and C++ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 [Bug 54367] [meta-bug] lambda expressions
[Bug other/87695] Arduino: ICE with avr and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||eweddington at gcc dot gnu.org, ||senthil.thecoder at gmail dot com --- Comment #19 from Eric Gallager --- cc-ing Senthil Kumar since apparently he's at Microchip and still working on AVR stuff: https://gcc.gnu.org/pipermail/gcc/2020-April/000412.html
[Bug c/95280] poor warning for attribute used on a function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95280 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=37874 CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- While touching the code affecting attributes on function arguments, it might also be worth taking a look at bug 37874
[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #9 from Eric Gallager --- This came up on the mailing lists; see the "performance of exception handling" / "size of exception handling" thread in this month's archive of the gcc mailing list (I forget the exact message)
[Bug c/72783] Fortify scanf %s, %[ conversion specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72783 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- Related discussion on handling issues like this in glibc: https://sourceware.org/pipermail/libc-alpha/2020-May/114269.html
[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #19 from Eric Gallager --- (In reply to Martin Liška from comment #18) > @egallager: Why did you add 'deferred' keyword? I sent a patch for it to GCC > patches mailing list. because: (In reply to Richard Biener from comment #16) > Re-target to GCC 10, definitely not material for backporting unless we > discover critical issues (that should be individually backported). > Eventually fully fixed only for GCC 11.
[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #21 from Eric Gallager --- (In reply to Segher Boessenkool from comment #20) > We are in stage 1 now (for GCC 11), so nothing should be deferred now. I thought the "deferred" keyword was a backward-looking one, meant to mark bugs that had been deferred from previous releases and thus deserve a higher priority now, not ones that are currently being deferred to something in the future (that's what the SUSPENDED status is for). cc-ing David Malcolm who originally came up with the keyword
[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||m...@3am-software.com --- Comment #1 from Eric Gallager --- cc-ing vax maintainer listed in MAINTAINERS
[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to Eric Gallager from comment #10) > (In reply to Arseny Solokha from comment #9) > > Yes, but AFAIK none of the PRs specific to powerpcspe have been closed so > > far. And, personally, I'd like them to stay open for another release cycle > > in the hope Andrew would actually revive the target this year. But it's up > > to gcc maintainers to decide, of course. > > OK, leaving this open then... The consensus here seemed to be to close them: https://gcc.gnu.org/pipermail/gcc/2020-May/232591.html So, I'm closing this.
[Bug target/49854] Clean up SPE/e500 option handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #5 from Eric Gallager --- consensus here seemed to be to close the SPE bugs: https://gcc.gnu.org/pipermail/gcc/2020-May/232591.html Thus, closing.
[Bug middle-end/95485] missing warning writing into function text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95485
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #2 from Eric Gallager ---
-Wpedantic catches it:
$ /usr/local/bin/gcc -c -O2 -S -Wall -Wextra -pedantic
-fdump-tree-optimized=/dev/stdout 95485.c
95485.c: In function 'f':
95485.c:6:20: warning: ISO C forbids passing argument 1 of '__builtin_memset'
between function pointer and 'void *' [-Wpedantic]
6 | __builtin_memset (p, 0, 32); // zero out -- whoops! -- writing to a
function
|^
95485.c:6:20: note: expected 'void *' but argument is of type 'void * (*)(int)'
;; Function f (f, funcdef_no=0, decl_uid=1910, cgraph_uid=1, symbol_order=0)
f (void * (*) (int) p)
{
void * q;
[local count: 1073741824]:
q_4 = p_2(D) (32);
__builtin_memset (p_2(D), 0, 32);
return q_4;
}
$
[Bug c/65213] Extend -Wmissing-declarations to variables [i.e. add -Wmissing-variable-declarations]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65213 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Now that -fno-common is the default, having this flag would make it easier to catch mis-declared variables that will turn into link errors at link time by catching them at compile time instead, so I'd think it's a bit more important now.
[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972 --- Comment #5 from Eric Gallager --- (In reply to Alexander Monakov from comment #4) > > Why is it missing the static keyword then? (Or alternatively, why isn't it > > in an anonymous namespace?) > > Huh? Without the warning developers may simply forget to put the 'static' > keyword. With the warning they would be reminded when bootstrapping the > patch. > > > > Ah, I like the namespace thing for target hooks (possibly langhooks as > > well). > > Sure, it's nice to have sensible namespace rules for future additions, but > hopefully that's not a reason/excuse to never re-enable the warning. Agreed; I think I tried enabling the warning once while bootstrapping myself, but I forget what the results were...
[Bug c/95588] No warning in -Wformat for narrowing formats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95588
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=67479
--- Comment #2 from Eric Gallager ---
(In reply to Nick Desaulniers from comment #1)
> In https://bugs.llvm.org/show_bug.cgi?id=41467#c4, the code owner for Clang
> seems to indicate that we could move the warnings for narrowing prints (ie.
> printing an `int` with `%hh`) to a new warning flag within the -Wformat
> group (ie. -Wformat-pedantic).
The bug for adding -Wformat-pedantic is bug 67479
>
> I'm mostly concerned with the case where the value being printed is either
> obviously or possibly too large for the print format specifier, ex.
>
> ```
> #include
> #include
> void foo(void) {
> printf("%hd\n", INT_MAX);
> }
> ```
> built with -Wformat.
>
> I'm curious if this is indeed something GCC should warn about, and if so,
> should it be part of -Wformat? (I suspect yes for both, or would prefer it
> to be yes for both, and then to fix all instances in the Linux kernel caught
> by this, but would prefer to collaborate on this).
I think there was a separate bug for the specific case of "%hhd"/"%hd" but I
can't find it right now...
[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #5 from Eric Gallager --- I asked about this on the mailing lists here: https://gcc.gnu.org/pipermail/gcc/2020-June/232922.html Iain Sandoe and Mike Stump had some hints about how to proceed; cc-ing them
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Jonny Grant from comment #2) > Thank you. Saw there is -Wdangling-else already as well -Wdangling-else is something different; it's more of a split-off from -Wparentheses, i.e. missing braces
[Bug c/96284] Outdated C features should be made errors with newer standards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||fw at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to David Brown from comment #0) > While C has tried to remain backwards compatible with each new standards > revision, some changes have been made so that particularly unsafe features > from old code are no longer supported. gcc has (reasonably enough) tried to > keep support for old features, but when something has been deprecated for > decades, perhaps it is time for it to be treated as an error by default and > require an explicit flag. (This is in the same style as bug 85678 making > "-fno-common" the default.) > > For example, implicit function declarations from K&R C were made obsolescent > in C90, and removed from the language in C99. But by default, they still > only cause a warning (-Wimplicit-function-declaration) in gcc, no matter > what standard is picked. > > Could this be made an error by default > (-Werror=implicit-function-declarations) ? Let those who want to compile > old code with implicit function declarations, do so with an explicit flag. I think Florian Weimer tried this and it broke the majority of configure scripts in existence...
[Bug c++/96310] Ignoring Wnonnull via pragma gcc diagnostics still produces a unwanted note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96310 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- These types of bugs seem kind of common; I keep thinking there should be some way of automatically checking that call to inform() only come after warning() or warning_at() if their return values got checked... I was thinking adding __attribute__((warn_unused_result)) on warning() and warning_at() at first, but that would also trigger in cases in which there's no following inform() call, in which it's ok to ignore the return value... maybe some magic could happen via David Malcolm's auto_diagnostic_group class?
[Bug c/96468] Warn when an empty while loop could have been a do-while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96468 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- Huh, I thought it might have been possible to get a warning from -Wempty-body for this code with some other version of gcc or clang, but I can't seem to find which one at the moment...
[Bug c/96460] Warn about signed modulo that is converted to unsigned value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96460 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Summary|Warn about signed module|Warn about signed modulo |that is converted to|that is converted to |unsigned value |unsigned value --- Comment #3 from Eric Gallager --- There already is a warning from -Wsign-conversion for it: $ /usr/local/bin/gcc -c -Wall -Wextra -Wconversion 96460.c 96460.c: In function 'f2': 96460.c:4:12: warning: conversion to 'long unsigned int' from 'int' may change the sign of the result [-Wsign-conversion] 4 | return i % 16; | ~~^~~~ $
[Bug c++/96570] Warnings desired for time_t to int coversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to M Welinder from comment #2) > > Why? If somebody wants to be explicitly stupid, that's their prerogative. > > I agree with the second sentence. > > However, casts are not a clear indication that somebody wants to be > explicitly stupid, at least not in C++. If you were looking for such an > indication, my int(int64_t(...)) suggestion is probably closer. > > Casts occur also in (e.g.) overload resolution and entirely too often in > template soup. And in macros too, I guess. > This reminds me of bug 69818
[Bug middle-end/96838] missing warning on integer overflow in calls to allocation functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96838
Eric Gallager changed:
What|Removed |Added
Last reconfirmed||2020-08-30
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||egallager at gcc dot gnu.org
--- Comment #1 from Eric Gallager ---
Hm, I thought by enabling more warning options I could get a warning from one
of the other ones, but, I guess not:
$ /usr/local/bin/gcc -O2 -S -Wall -Wextra -pedantic -Wlarger-than=12345
-Walloc-size-larger-than=12345 -Wformat-overflow=2 -Wstringop-overflow=4
-Wshift-overflow=2 -Wstrict-overflow=5 -fdump-tree-optimized=/dev/stdout
96838.c
;; Function f (f, funcdef_no=0, decl_uid=1913, cgraph_uid=1, symbol_order=0)
f (size_t n)
{
void * p;
int _1;
[local count: 1073741824]:
n_3 = MAX_EXPR ;
_1 = (int) n_3;
p_6 = salloc (_1);
__builtin_memset (p_6, 0, n_3);
return p_6;
}
;; Function g (g, funcdef_no=1, decl_uid=1917, cgraph_uid=2, symbol_order=1)
g (size_t n)
{
void * p;
unsigned int _1;
[local count: 1073741824]:
n_3 = MAX_EXPR ;
_1 = (unsigned int) n_3;
p_6 = ualloc (_1);
__builtin_memset (p_6, 0, n_3);
return p_6;
}
$
So, confirmed.
[Bug c/96842] enhancement: copy clang Wheader-guard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96842 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Blocks||87403 Last reconfirmed||2020-08-30 CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- confirmed that this warning would be nice to have. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c++/59994] [meta-bug] thread_local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994 Bug 59994 depends on bug 67135, which changed state. Bug 67135 Summary: [thread_local] heap-use-after-free (OS X 10.10.4) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/67135] [thread_local] heap-use-after-free (OS X 10.10.4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eric Gallager --- (In reply to Toby Brull from comment #1) > This seems to be fixed from version 5.3 on. > > Was able to confirm the bug in gcc 5.2 via wandbox.org (although it failed > there with a different ASAN error). > > Testing on wandbox.org, this worked for gcc version: > 5.3, > 6.1, 6.2, 6.3, > 7.1, 7.3, > 8.1, 8.3, > 9.3, > 10.1 > > Also worked on my local ubuntu gcc installs (6.5, 7.5, 8.4, 10.1). > > So should probably be closed? Pretty sure my last compile of gcc was without sanitizer support, so I can't confirm for myself, but I'll take your word for it and close it anyways.
[Bug c++/66360] thread_local variable needs copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66360 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > This has nothing to do with thread_local. That is removing static > thread_local still causes it to produce an error. > OK so how would you suggest retitling this, then?
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- Any reason to keep this in WAITING?
[Bug c++/87729] Please include -Woverloaded-virtual in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to xantares09 from comment #5) > still there with 10.1, see attached patch Please submit your patch to the gcc-patches mailing list for review
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 Eric Gallager changed: What|Removed |Added Keywords||documentation --- Comment #28 from Eric Gallager --- (In reply to r...@cebitec.uni-bielefeld.de from comment #26) > > --- Comment #25 from Iain Sandoe --- > > We could entertain and implement a change to Darwin's configuration that > > automatically discovers the /Library/Developer/CommandLineTools .. or > > /Applications/Xcode... for Darwin versions >= X and complains of fails to > > configure if those can't be seen (asking for a --with-sysroot=). > > That's one option, certainly easier for the users. At the least, the > issue should be documented in install.texi so they can add > --with-sysroot manually if need be. I just noticed that the install > docs only have a small section on PowerPC Darwin, nothing else... > Adding "documentation" keyword for this part at least (I recently got a new laptop and am now on Catalina and ran into this bug, so that's why I'm coming back to it)
[Bug target/92137] [ia32] Missing documentation for ia32 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92137 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Jakub Jelinek from comment #3) > Those are intrinsics and most of them are documented in the Intel > architecture manuals, or various web sites. Not sure it is a good idea to > duplicate that documentation. Might be worthwhile to at least provide a link to the manuals or websites then, if we're not going to duplicate the info contained in them...
[Bug c++/87628] Redundant check of pointer when operator delete is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87628 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > Confirmed. IIRC there are duplicates of this bug. Well related bugs for the plain-C equivalent with free() at least
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #40 from Eric Gallager --- Josef Wolf mentioned that he ran into this on the gcc-help mailing list here: https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #42 from Eric Gallager --- (In reply to Rich Felker from comment #41) > > Josef Wolf mentioned that he ran into this on the gcc-help mailing list > > here: https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html > > I don't think that's an instance of this issue. Well ok, maybe not THAT message specifically; see the rest of the thread though. > It's normal/expected that __builtin_foo compiles to a call to foo in the > absence of factors that lead to it being optimized to something simpler. > The idiom of using __builtin_foo to get the compiler to emit an optimized > implementation of foo for you, to serve as the public definition of foo, is > simply not valid. That's kinda a shame because it would be nice to be able to > do it for lots of math library functions, but of course in order for this to > be > able to work gcc would have to promise it can generate code for the operation > for all targets, which is unlikely to be reasonable.
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 --- Comment #12 from Eric Gallager --- (In reply to Jonathan Wakely from comment #11) > (In reply to Eric Gallager from comment #10) > > If this is becoming the meta-bug for all warnings that affect codegen, then > > I'd like to add bug 61579 (-Wwrite-strings) as at least semi-related... (not > > sure if toggling it causes miscompares though) > > That one is *supposed* to affect codegen (so maybe it should be a -f option > instead). hm, I could've sworn there was already an -f option with a similar name, but after checking the manual I can't seem to find it after all, so... I guess making it an -f option could work.
[Bug target/82240] i386.md & -Wlogical-op in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82240 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-19 Ever confirmed|0 |1 --- Comment #12 from Eric Gallager --- (In reply to Eric Gallager from comment #10) > *** Bug 83863 has been marked as a duplicate of this bug. *** Taking the dup as confirmation
[Bug objc/77404] Add Wobjc-root-class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77404 Eric Gallager changed: What|Removed |Added CC||mikestump at comcast dot net --- Comment #5 from Eric Gallager --- cc-ing other objc maintainer
[Bug c/7654] warn if an enum is being assigned a non enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7654
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #12 from Eric Gallager ---
(In reply to Martin Sebor from comment #11)
> I'll confirm this ancient request.
>
> Bug 78736 asks for something similar, and I'm working on enhancing the
> solution there even further (to diagnose assigning constants that don't have
> a corresponding enumerator in the destination type). I'll add that on the
> following slightly modified test case Clang issues the warnings below:
>
> $ cat t.C && clang -S -Wall -Wextra -Weverything -xc t.C
> void f (int i)
> {
> enum e1 { e1a, e1b };
> enum e1 e1v;
> enum e2 { e2a, e2b };
> enum e2 e2v;
>
> e1v = 1; // no warning
> e1v = 3; // warning
> e1v = e1a; // ok
> e2v = e1v; // warning
> i = e1v; // ok I guess
> e2v = i; // warning
> }
> t.C:9:9: warning: integer constant not in range of enumerated type 'enum e1'
> [-Wassign-enum]
> e1v = 3; // warning
> ^
> t.C:11:9: warning: implicit conversion from enumeration type 'enum e1' to
> different enumeration type 'enum e2' [-Wenum-conversion]
> e2v = e1v; // warning
> ~ ^~~
> t.C:13:9: warning: implicit conversion changes signedness: 'int' to 'enum e2'
> [-Wsign-conversion]
> e2v = i; // warning
> ~ ^
> t.C:1:6: warning: no previous prototype for function 'f'
> [-Wmissing-prototypes]
> void f (int i)
> ^
> 4 warnings
gcc now prints:
$ /usr/local/bin/gcc -c -S -Wall -Wextra -Wconversion -Wsign-conversion
-Wmissing-prototypes -pedantic -xc 7654.c
7654.c:1:6: warning: no previous prototype for 'f' [-Wmissing-prototypes]
1 | void f (int i)
| ^
7654.c: In function 'f':
7654.c:11:6: warning: implicit conversion from 'enum e1' to 'enum e2'
[-Wenum-conversion]
11 | e2v = e1v; // warning
| ^
7654.c:6:10: warning: variable 'e2v' set but not used
[-Wunused-but-set-variable]
6 | enum e2 e2v;
| ^~~
$
so, gcc has -Wenum-conversion now, but it is still missing warnings from
-Wassign-enum and -Wsign-conversion on this testcase.
[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #18 from Eric Gallager ---
(In reply to Jonny Grant from comment #17)
> Hello Joseph
>
> This was the test case I created. There isn't any warning output when 'a_t'
> is converted to 'int'. Or even if it was converted to an 'unsigned int'
>
> https://gcc.gnu.org/ml/gcc-help/2019-07/msg00014.html
>
>
> //-O2 -Wall -Wextra -Wconversion -Werror
>
> #include
> typedef enum
> {
> a = -1
> } a_t;
>
> a_t f()
> {
> return a;
> }
>
> int main()
> {
> int b = f();
> return b;
> }
While it's true that g++ prints no warnings for that testcase, I think that's
material for a separate bug. The original bug here was just to add
-Wenum-conversion for the C front-end, which has now been done, so I'm closing
this. Feel free to open new bugs for any missed cases.
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 78736, which changed state. Bug 78736 Summary: enum warnings in GCC (request for -Wenum-conversion to be added) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/52763] Warning if compare between enum and non-enum type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-10-19
Ever confirmed|0 |1
--- Comment #11 from Eric Gallager ---
(In reply to Martin Sebor from comment #8)
> Clang warns when an enum object is compared to a constant that's out of the
> most restricted range of the enum's type. The warning is in -Wall. It
> doesn't warn when the object is compared to a constant that doesn't
> correspond to any of the type's enumerators. I can see that being useful to
> some (carefully written) projects but suspect it could be quite noisy for
> many others.
>
> $ cat t.C && clang++ -S -Wall -Wextra t.C
> enum E { NONE = 0, ONE = 1, TWO = 2 };
>
> bool f (E e)
> {
> return e == 3; // no warning here
> }
>
> bool g (E e)
> {
> return e == 4;
> }
>
>
> t.C:10:12: warning: comparison of constant 4 with expression of type 'E' is
> always false [-Wtautological-constant-out-of-range-compare]
> return e == 4;
> ~ ^ ~
> 1 warning generated.
I combined this testcase with the testcase in the original report and can
confirm that there is still no warning even after the addition of
-Wenum-conversion in bug 78736 (when compiling with either the C or C++
frontends)
$ cat 52763.cc
#ifdef __cplusplus
# include
#else
# include
#endif /* __cplusplus */
typedef enum {
NONE = 0, ONE = 1, TWO = 2
} tEnumType;
bool f(tEnumType e)
{
return (e == 3); // no warning here
}
bool g(tEnumType e)
{
return (e == 4);
}
int main(void)
{
tEnumType var1 = TWO;
//Warn here, because we compare an enum to a non-enum type (1)
//should be 'if (var1 == ONE)'
if (var1 == 1)
return f(NONE);
else
return g(ONE);
}
$ /usr/local/bin/g++ -c -S -Wall -Wextra -Wconversion -pedantic 52763.cc
$ /usr/local/bin/gcc -c -S -Wall -Wextra -Wconversion -pedantic
-Wenum-conversion -Wc++-compat -x c 52763.cc
$
(no output)
[Bug c/60591] Report enum conversions as part of Wconversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591 --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > There are several other bugs open like this one, such as bug 78736 This is fixed now. It's probably still worth checking some of the other bugs under its "See Also" section though.
[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593 --- Comment #8 from Eric Gallager --- (In reply to Jerry DeLisle from comment #7) > Author: jvdelisle > Date: Wed Oct 2 02:35:14 2019 > New Revision: 276439 > > URL: https://gcc.gnu.org/viewcvs?rev=276439&root=gcc&view=rev > Log: > 2019-10-01 Jerry DeLisle > > PR libfortran/91593 > * io/read.c (read_decimal): Cast constant to size_t to turn off > a bogus warning. > * io/write.c (btoa_big): Use memset in lieu of setting the null > byte in a string buffer to turn off a bogus warning. > > Modified: > trunk/libgfortran/ChangeLog > trunk/libgfortran/io/read.c > trunk/libgfortran/io/write.c Did this fix it?
[Bug middle-end/86575] [7/8 Regression] -Wimplicit-fallthrough affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575 --- Comment #8 from Eric Gallager --- (In reply to Michael Matz from comment #7) > As I stated, it's only fixed in trunk, so it's still a regression in 7 and 8, > as marked in the summary. But you also said you weren't planning on backporting though: (In reply to Michael Matz from comment #5) > Fixed in trunk. Not planning backporting, it's not a very important problem. So, if you're not going to backport to 7 or 8, then, does this bug really need to stay open?
[Bug c++/90159] Poor warning for an ambiguous reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90159 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-20 Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Confirmed.
[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045 Eric Gallager changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #7 from Eric Gallager --- hm, MAINTAINERS says Alexandre Oliva is an SH maintainer, too? cc-ing him
[Bug c/87038] diagnostics: Have -Wjump-misses-init be enabled by -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #24 from Eric Gallager --- (In reply to Harald van Dijk from comment #23) > (In reply to Eric Gallager from comment #22) > > (In reply to Harald van Dijk from comment #21) > > > Since -Wjump-misses-init triggers too often for commonly used C patterns, > > > I do not think it is appropriate to include it in -Wall. > > > > OK, so what about -Wextra then? > > My personal feeling as a user is that clang's warning is useful enough that > if GCC were to implement that, that one could be included in -Wall. It > avoids warning for the common cases where code works as intended, and still > manages to warn for the OP's code. I do not know how much work it would be > to implement that; if it would be too much work, then including > -Wjump-misses-init in -Wextra makes sense to me. Well, since no one's done it yet, I'm guessing it's probably too much work, so... can we just go with the latter?
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 49574, which changed state. Bug 49574 Summary: Give a warning for insane overloading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug c++/49574] Give a warning for insane overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #7)
> OK here's the documentation patch:
>
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -3383,6 +3383,11 @@ object to the same type, to a base class of that
> type, or to void; such
> a conversion function will never be called.
> @end table
>
> +@item -Winsane-overloading @r{(C++ and Objective-C++ only)}
> +@opindex Winsane-overloading
> +@opindex Wno-insane-overloading
> +Warn about whatever was agreed to in Bugzilla.
> +
> @node Objective-C and Objective-C++ Dialect Options
> @section Options Controlling Objective-C and Objective-C++ Dialects
>
>
> The rest should be a simple matter of programming.
>
> More seriously, I'm not the one asking for the warning, so it's not up to me
> to describe what's wanted.
All right fine; I guess I'll close this then...
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205 --- Comment #9 from Eric Gallager --- (In reply to Tavian Barnes from comment #8) > Maybe "argument 2 has type 'double' (promoted from 'float')"? Yes, that seems better to me, at least...
[Bug c++/92194] maybe-uninitialized false positive with c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92194 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80635 --- Comment #3 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > Possible duplicate of pr80635. Well, related at least...
[Bug c++/87768] [8 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19002 when using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87768 --- Comment #7 from Eric Gallager --- (In reply to gcc-bugs from comment #6) > I can confirm that this works from 9 and up. Is there any chance to backport > it to 8? That's why this bug is still open. > > In the ticket it says `Target Milestone: 8.4`, does that mean there will be > a 8.4 release that fixes this? Yes, there will be a release for 8.4, the intent is that 8.4 will fix this, but the backport hasn't actually happened yet
[Bug c/85678] -fno-common should be default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 --- Comment #4 from Eric Gallager --- This keeps getting brought up in bug 91766 (already added as related from the other end)
[Bug c/44515] improve message for missing ";"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44515 --- Comment #10 from Eric Gallager --- (In reply to David Malcolm from comment #9) > Trunk now emits: > > t.c: In function ‘foo’: > t.c:4:8: error: expected ‘;’ before ‘}’ token >bar() > ^ > ; > t.c:7:1: > } > ~ > > (as of r253690, I believe). > > This improves the location for the diagnostic (and adds a fix-it hint), but > it doesn't address the wording of the message, hence I'm keeping this PR > open. I think the improvement of the location and the addition of the fix-it is enough, personally, but maybe others have different opinions...
[Bug c/58884] OPTIONAL warning when a temprary value is created and not used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58884 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||87403 --- Comment #5 from Eric Gallager --- making this block the "new-warning" meta-bug Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c/23577] spurious warnings about unhandled cases in switches (need VRP and control flow in front-end)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23577 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > The warning is done without flow control. > > The optmization needs a "full" VRP which keeps of track of discontinuous > ranges which is too expensive > really. ...maybe once Project Ranger is merged and we have that info available on-demand it'll be easier?
[Bug c/42579] [PATCH] support for obtaining file basename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579 Eric Gallager changed: What|Removed |Added CC||fuchedzhy at google dot com --- Comment #8 from Eric Gallager --- *** Bug 91998 has been marked as a duplicate of this bug. ***
[Bug c/91998] Add a __FILE_NAME__ macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91998 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82176 --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > dup of bug 82176 > > *** This bug has been marked as a duplicate of bug 82176 *** Actually wrong one; I guess it's more of a dup of bug 42579 instead, meaning 82176 is just related... *** This bug has been marked as a duplicate of bug 42579 ***
[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176 --- Comment #6 from Eric Gallager --- (In reply to Gregory Fuchedzhy from comment #5) > (In reply to Eric Gallager from comment #3) > > *** Bug 91998 has been marked as a duplicate of this bug. *** > > Not exactly a duplicate, but related. > Clang implemented an additional __FILE_NAME__ macro. > > See: > https://reviews.llvm.org/D61756 > https://reviews.llvm.org/D17741 oh ok, I guess that's actually a dup of bug 42579 instead, then...
[Bug c/45821] Missed -Wreturn-local-addr when local variable address comes from within a statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45821
Eric Gallager changed:
What|Removed |Added
Blocks||90556
Summary|no warning when returning a |Missed -Wreturn-local-addr
|local variable address |when local variable address
|within a statement |comes from within a
|expression |statement expression
--- Comment #6 from Eric Gallager ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Andrew Gaul from comment #3)
> > int *function_return_local(void)
> > {
> > int x = 0;
> > return &x;
> > }
> >
> > int *statement_expression_return_local(void)
> > {
> > int *y = ({
> > int x = 0;
> > &x;
> > });
> > return y;
> > }
>
> We now warn at -O2:
>
> test.c:14:10: warning: function returns address of local variable
> [-Wreturn-local-addr]
>return y;
> ^
> test.c:11:11: note: declared here
>int x = 0;
>^
>
> but only because we return y. For this testcase,
>
> int statement_expression_return_local(void)
> {
> int *y = ({
> int x = 0;
> &x;
> });
> return *y;
> }
>
> we get:
>
> test.c:14:10: warning: ‘x’ is used uninitialized in this function
> [-Wuninitialized]
>return *y;
> ^
>
> which is a bit confusing (and not the same warning).
It'd be good to get it from the same warning, so I'm making this block the
-Wreturn-local-addr meta-bug
>
> Possibly related to 60517.
> it would be good to add the testcase
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
[Bug 90556] [meta-bug] bogus/missing -Wreturn-local-addr
[Bug libobjc/67455] Inheriting from Object (with GNU runtime) doesn't provide alloc, init, or new, rendering methods useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67455 --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Eric Gallager from comment #4) > > 67455.m:21:2: warning: (Messages without a matching method signature > > 67455.m:21:2: warning: will be assumed to return ‘id’ and accept > > 67455.m:21:2: warning: ‘...’ as arguments.) > > Also this message should probably be a single note rather than warnings, so > I guess this is a diagnostics issue too. actually that should probably be split off into a separate issue instead of including it as part of this one, but I don't feel like doing that now...
[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #10 from Eric Gallager --- cc-ing objc[++] maintainers
[Bug lto/41526] gimple bytecode streams are not portable between different hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41526 --- Comment #4 from Eric Gallager --- (In reply to Joseph S. Myers from comment #3) > The handling of target options (the patch for bug 45475) is another > host-dependency in the bytecode stream. That has been closed as fixed... which parts of this issue still remain?
[Bug demangler/67299] demangler mishandles complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67299 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Eric Gallager --- Update: Jeff has fixed this in r277535: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01982.html
[Bug c/60523] Warning flag for octal literals [-Woctal-literals]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #9 from Eric Gallager --- (In reply to Eric Gallager from comment #8) > *** Bug 70952 has been marked as a duplicate of this bug. *** While this was a mistake, it still might be worth grouping the flag proposed in that bug, -Woctal-escapes, and the flag proposed in this bug, -Woctal-literals, under an umbrella flag called just -Woctal
[Bug c++/83806] [7 Regression] Spurious -Wunused-but-set-parameter with nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83806 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Known to work||8.3.0, 9.2.1 Blocks||89180 --- Comment #8 from Eric Gallager --- (In reply to Matthias Noack from comment #7) > Can confirm, that it is fixed in 8.3.0 and 9.2.1. Yup, the reason this bug is still open is in case backports to the branch for 7 are desired. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 [Bug 89180] [meta-bug] bogus/missing -Wunused warnings
