[Bug tree-optimization/86925] [9 Regression] ICE in get_predictor_value, at predict.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86925 --- Comment #4 from Martin Liška --- Author: marxin Date: Wed Aug 15 08:55:15 2018 New Revision: 263552 URL: https://gcc.gnu.org/viewcvs?rev=263552&root=gcc&view=rev Log: Fix merging of 2 predictors (PR tree-optimization/86925). 2018-08-15 Martin Liska PR tree-optimization/86925 * predict.c (expr_expected_value_1): When taking later predictor, assign also probability. Use fold_build2_initializer_loc in order to fold the expression in -frounding-math. 2018-08-15 Martin Liska PR tree-optimization/86925 * gcc.dg/predict-20.c: New test. * gcc.dg/predict-21.c: New test. Added: trunk/gcc/testsuite/gcc.dg/predict-20.c trunk/gcc/testsuite/gcc.dg/predict-21.c Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86925] [9 Regression] ICE in get_predictor_value, at predict.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86925 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed now.
[Bug target/81685] [7/8/9 Regression] FAIL: g++.dg/debug/dwarf2/inline-ns-2.C -std=gnu++* (internal compiler error) on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81685 --- Comment #6 from Iain Sandoe --- Author: iains Date: Wed Aug 15 09:19:39 2018 New Revision: 263553 URL: https://gcc.gnu.org/viewcvs?rev=263553&root=gcc&view=rev Log: Update Darwin section names for DWARF5 gcc/ 2018-08-15 Iain Sandoe PR target/81685 * config/darwin.h: (DEBUG_STR_OFFSETS_SECTION, DEBUG_LOCLISTS_SECTION, DEBUG_RNGLISTS_SECTION) new macros. (DEBUG_PUBNAMES_SECTION, DEBUG_PUBTYPES_SECTION) update to include GNU variant. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h
[Bug sanitizer/86962] New: [9 Regression] ICE in sanitize_rewrite_addressable_params, at sanopt.c:1173 with nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86962 Bug ID: 86962 Summary: [9 Regression] ICE in sanitize_rewrite_addressable_params, at sanopt.c:1173 with nested functions Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, ebotcazou at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Following causes ICE starting from r261687: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030418-1.c -fsanitize=address -c during GIMPLE pass: sanopt /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030418-1.c: In function ‘foo’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030418-1.c:9:6: internal compiler error: in sanitize_rewrite_addressable_params, at sanopt.c:1173 9 | void foo(int i) | ^~~ 0x67de04 sanitize_rewrite_addressable_params /home/marxin/Programming/gcc/gcc/sanopt.c:1173 0xcf5411 execute /home/marxin/Programming/gcc/gcc/sanopt.c:1287 Issues is that there's a param with DECL_HAS_VALUE_EXPR_P which is addressable. We can probably skip these, but I'm curious Eric how that changed in your commit?
[Bug sanitizer/86962] [9 Regression] ICE in sanitize_rewrite_addressable_params, at sanopt.c:1173 with nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86962 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-15 Known to work||8.2.0 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug sanitizer/86962] [9 Regression] ICE in sanitize_rewrite_addressable_params, at sanopt.c:1173 with nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86962 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug fortran/80931] ICE on move_alloc in gimplify_expr, at gimplify.c:11335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80931 Arjen Markus changed: What|Removed |Added CC||arjen.markus895 at gmail dot com --- Comment #4 from Arjen Markus --- I ran into the same ICE, except that gfortran now reports that it happens at line 11329 of gimplify.c and the program (module defining a simple class actually) in which this happens is 168 lines long. I have tried to reduce it, but anything I have tried leads to a disappearance of the fatal error. This was with versions 6.2.0 (MinGW-w64/MSYS2) and 7.3.0 (Cygwin), should that matter.
[Bug fortran/83196] ICE in gfc_build_compare_string, at fortran/trans-expr.c:3609 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83196 Arjen Markus changed: What|Removed |Added CC||arjen.markus895 at gmail dot com --- Comment #4 from Arjen Markus --- Created attachment 44543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44543&action=edit Sample module exhibiting the problem ICE at line 11329 - any reduction seems to make the problem go away (but also the functionality)
[Bug fortran/83196] ICE in gfc_build_compare_string, at fortran/trans-expr.c:3609 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83196 --- Comment #5 from Arjen Markus --- (In reply to Arjen Markus from comment #4) > Created attachment 44543 [details] > Sample module exhibiting the problem > > ICE at line 11329 - any reduction seems to make the problem go away (but > also the functionality) Please ignore this - it is meant for a different issue. Somehow it ended up on the wrong issue.
[Bug c++/70693] valgrind error in get_visual_column
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70693 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- I'm starting to see in more often on periodic openSUSE package builds. David any estimation about when you get to it?
[Bug target/86777] Bfin port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86777 --- Comment #2 from Richard Earnshaw --- I don't think you could do that through the API provided by this patch set; but it's not really appropriate for this case. I'm not familiar with the bfin architecture so cannot comment on what the best approach is, but it seems to me you have several options. Use the speculation barrier not needed hook - this might apply if the speculation is so limited that the CPU is not vulnerable to Spectre style attacks. Use the barrier anyway - this might apply if the processor vendor has defined a barrier operation for this architecture, even if current implementations do not need it (it might anticipate a new implementation that does need it). Write a custom pass to handle it - from your description it looks like emitting a NOP after every conditional branch may be sufficient to completely eliminate the problem. I created this PR because only the port maintainers (perhaps in discussion with the manufacturers) can really decide what the best approach to handling this issue must be.
[Bug target/86856] Format warnings building all-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856 --- Comment #10 from jon_y --- I noticed there are some casting from gcall to gimple, not being familiar with gcc internals, is it the correct way to suppress the warnings?
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #7 from David Binderman --- Still seeing this one in revision 263512, dated 20180813.
[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
--- Comment #14 from Jason Vas Dias ---
RE: Comment #13:
> You said that Andi Kleen had a comment. Can you point me to it?
Here is a quote, from LKML message :
Subject: Re: [PATCH v4.16-rc5 2/2] x86/vdso: \
VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) \
without syscall Kernel
From: Andi Kleen
Date: 17 March 2018 at 23:00
To: jason.vas.d...@gmail.com
Cc: linux-ker...@vger.kernel.org, x...@kernel.org, t...@linutronix.de,
mi...@kernel.org, pet...@infradead.org, a...@firstfloor.org
>On Sat, Mar 17, 2018 at 02:29:34PM +, jason.vas.d...@gmail.com wrote:
>> This patch allows compilation to succeed with compilers that
>> support -DRETPOLINE -
>> it was kindly contributed by H.J. Liu in GCC Bugzilla: 84908 :
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
>>
>> Apparently the GCC retpoline implementation has a limitation
>> that it cannot handle switch statements with more than 5 clauses,
>> which vclock_gettime.c's
>> __vdso_clock_gettime function now conts.
>
>That's quite a mischaracterization of the issue. gcc works as intended,
>but the kernel did not correctly supply a indirect call retpoline thunk
>to the vdso, and it just happened to work by accident with the old
>vdso.
>
>>
>> The automated test builds should now succeed with this patch.
>
>How about just adding the thunk function to the vdso object instead of
>this cheap hack?
>
>The other option would be to build vdso with inline thunks.
>
>But just disabling is completely the wrong action.
>
>-Andi
So, in their wisdom, the kernel developers have decided it is
best to compile the VDSO with indirect-branch("thunk-extern,register"),
and we need to work around the limitations this imposes.
RE: Comment #13:
> I also think that static inlines have anything to do with it.
> Nor so I see why any function attributes make any sense.
On the contrary, I think function attributes and static inline-ness
have ALOT to do with it - the problem does not occur if the
called functions have the SAME indirect-branch attributes as
the caller function, or if the called function is not static inline.
It definitely appears to be something to do with GCC having to
instantiate a callable version of a static inline, when that
inline has different indirect-branch attributes than its caller.
The '-mindirect-branch=thunk-extern -mindirect-branch-register -DRETPOLINE'
flags should have the effect of making the default function attributes to be
'__attribute__((indirect-branch("thunk-extern,register"))'
for any function that does not specify other indirect-branch attributes,
so when instantiating this callable version of the inline GCC needs to
generate a thunk-extern relocation. The code which produces the special
stripped & augmented version of the VDSO object does not include support for
such relocations and complains about them, failing the builds.
I also have many unanswered questions about this bug, mentioned above -
perhaps H.J. could clarify ? :
o why exactly is it that the 6-clause switch in the first post triggers
the relocation, and the 5-clause switch does not?
why cannot this limitation be removed from GCC?
o why should GCC be trying to generate an extern thunk for
an indirect branch to a static inline function anyway ?
I think static-inlineness should always trump
indirect-branch("thunk-extern").
o GCC appears to provide no way for users to construct their own jump tables
without relocations - why does every reference to a PC-relative label
produce a relocation?
I do believe this
[Bug bootstrap/86872] [9 Regression] LTO bootstrap failed with profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86872 --- Comment #5 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00866.html
[Bug libstdc++/86963] New: std::tuple incorrectly assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86963
Bug ID: 86963
Summary: std::tuple incorrectly assigned
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: denin at mail dot ru
Target Milestone: ---
$ cat meow.cpp
#include
#include
struct S {
S &operator=(S const &) = delete;
S &operator=(S &&) = delete;
};
static_assert(!std::is_move_assignable_v>);
$ g++ meow.cpp
meow.cpp:8:15: error: static assertion failed
static_assert(!std::is_move_assignable_v>);
^~~~
Despite tuple's elements being not assignable at all, tuple itself is
incorrectly considered assignable, due to non-SFINAE protected operator= in
class definition. Thus, the following code breaks on 'f = std::move(g);':
template void mv_assign(T &left, T &&right) {
if constexpr(std::is_move_assignable_v>) left =
std::move(right);
}
int main() {
std::tuple f, g;
mv_assign(f, std::move(g));
}
ENVIRONMENT
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.1.1 20180531 (GCC)
$ uname -a
Linux home 4.17.10-1-ARCH #1 SMP PREEMPT Wed Jul 25 11:23:00 UTC 2018 x86_64
GNU/Linux
[Bug c/19315] document undocumented extension that allows code where variable is not emitted in the asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19315 --- Comment #10 from Iain Sandoe --- Author: iains Date: Wed Aug 15 11:45:44 2018 New Revision: 263556 URL: https://gcc.gnu.org/viewcvs?rev=263556&root=gcc&view=rev Log: Don't make unsized objects into extern. 2018-08-15 Iain Sandoe gcc/c: PR c/19315 * c-decl.c (finish_decl): Don't add the 'extern' storage class to objects of unknown size. gcc/testsuite: PR c/19315 gcc.dg/graphite/pr82451.c: Make array 'a' an extern. gcc.dg/redecl-10.c: Expect warnings for the static vars with unknown size. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/pr82451.c trunk/gcc/testsuite/gcc.dg/redecl-10.c
[Bug libstdc++/86963] std::tuple incorrectly assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86963 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-15 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is a new requirement in C++17, since https://wg21.link/lwg2729 Previous standards did not require the assignment to be deleted or removed from overload resolution.
[Bug libstdc++/86963] std::tuple incorrectly assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86963 --- Comment #2 from Jonathan Wakely --- I think we want a similar solution as for PR 86751 i.e. r263185
[Bug gcov-profile/86957] gcc should warn about missing profiles for a compilation unit or a new function with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-15 Component|middle-end |gcov-profile Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I welcome that attempt.
[Bug debug/86964] New: Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 Bug ID: 86964 Summary: Too many debug symbols included, especially for extern globals Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: znerol at gmail dot com Target Milestone: --- Created attachment 44544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44544&action=edit Sample code When compiling with gcc -g using gcc 4.9, the debug symbols included, especially for externally declared global variables, is at an expected and familiar amount. When switching to gcc 6.3, the amount of debug symbols included seems excessive and superfluous. Attempts at using flags such as: -feliminate-unused-debug-symbols -feliminate-unused-debug-types -femit-struct-debug-baseonly have yielded no difference. This creates a problem when working with a very large codebase that yields large library archives that end up being several orders of magnitude larger (file size) with the newer compiler vs. the older one. I've attached sources and test Makefile for a small program to illustrate what I'm talking about. Below I include the difference in output between the 2 versions. In both cases, the symbols included in the final prog executable are a summation of those in each of the object files - as expected - so I don't think that behavior is wrong. But the key difference is in each of the object files. With the older version, you only have symbols included that are relevant to the module. With the newer version, you get every symbol for every variable externally declared, even if it's not used or referenced in that module. This has a multiplicative effect in the final executable's amount of debug info. The attached sample program is mimicking source code structure seen in a very large 3rd party SDK being worked with. The net effect of this problem results in library archive files that are several orders of magnitude larger than before. What used to be a few MB are now a few GB. What I'm looking for is a flag or option that will make the newer version behave like the older version with regard to the included debug info. Result with gcc 4.9 $ make gcc -g -feliminate-unused-debug-symbols -c -o a.o a.c gcc -g -feliminate-unused-debug-symbols -c -o b.o b.c gcc -g -feliminate-unused-debug-symbols -c -o c.o c.c gcc -g -feliminate-unused-debug-symbols -o prog a.o b.o c.o a.o DW_AT_name: (indirect string, offset: 0xb4): big_time 0x00b0 696e7400 6269675f 74696d65 00756e73 int.big_time.uns b.o <1e> DW_AT_name: (indirect string, offset: 0x9): big_time <40> DW_AT_name: (indirect string, offset: 0x0): big_mama 0x 6269675f 6d616d61 00626967 5f74696d big_mama.big_tim c.o <1e> DW_AT_name: (indirect string, offset: 0x9): big_stuf <40> DW_AT_name: (indirect string, offset: 0x0): big_leee 0x 6269675f 6c656565 00626967 5f737475 big_leee.big_stu prog DW_AT_name: (indirect string, offset: 0x95): big_time DW_AT_name: (indirect string, offset: 0x95): big_time DW_AT_name: (indirect string, offset: 0xd7): big_mama <123> DW_AT_name: (indirect string, offset: 0xe9): big_stuf <145> DW_AT_name: (indirect string, offset: 0xe0): big_leee 0x0090 20696e74 00626967 5f74696d 6500756e int.big_time.un 0x00d0 7a657479 70650062 69675f6d 616d6100 zetype.big_mama. 0x00e0 6269675f 6c656565 00626967 5f737475 big_leee.big_stu - Result with gcc 6.3 $ make gcc -g -feliminate-unused-debug-symbols -c -o a.o a.c gcc -g -feliminate-unused-debug-symbols -c -o b.o b.c gcc -g -feliminate-unused-debug-symbols -c -o c.o c.c gcc -g -feliminate-unused-debug-symbols -o prog a.o b.o c.o a.o <312> DW_AT_name: (indirect string, offset: 0x20e): big_time <31d> DW_AT_name: (indirect string, offset: 0x1eb): big_mama <328> DW_AT_name: (indirect string, offset: 0x286): big_stuf <333> DW_AT_name: (indirect string, offset: 0x90): big_leee 0x0090 6269675f 6c656565 006c6f6e 6720696e big_leee.long in 0x01e0 74005f49 4f5f4649 4c450062 69675f6d t._IO_FILE.big_m 0x0280 6636345f 74006269 675f7374 7566005f f64_t.big_stuf._ b.o <1e> DW_AT_name: (indirect string, offset: 0x9): big_time <36> DW_AT_name: (indirect string, offset: 0x0): big_mama <41> DW_AT_name: (indirect string, offset: 0x12): big_stuf <4c> DW_AT_name: (indirect string, offset: 0x1b): big_leee 0x 6269675f 6d616d61 00626967 5f74696d big_mama.big_tim 0x0010 65006269 675f7374 75660062 69675f6c e.big_stuf.big_l c.o <1e> DW_AT_name: (indirect string, offset: 0x
[Bug libgcc/86512] Incorrect sub result for float subnormal inputs in armv7(with -msoft-float).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #3 from Wilco --- We should still add a test for this case and backport.
[Bug tree-optimization/71625] missing strlen optimization on different array initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625 --- Comment #18 from Martin Sebor --- Author: msebor Date: Wed Aug 15 15:25:46 2018 New Revision: 263561 URL: https://gcc.gnu.org/viewcvs?rev=263561&root=gcc&view=rev Log: PR tree-optimization/71625 - missing strlen optimization on different array initialization style (avoid compilation errors on aarch64) gcc/ChangeLog: * config/aarch64/aarch64-builtins.c (aarch64_init_simd_builtin_types): Clear Poly8_t's TYPE_STRING_FLAG. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-builtins.c
[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment #5 from Sergei Trofimovich ---
Slightly shorter reproduced (shrunk with creduce):
// a.c
int a, b, c;
int e(int h) {
double d;
int f = 1;
while (b < 1) {
c = d + f;
if (b)
a /= h;
else {
long unsigned g;
f = 0;
d = h / g + h;
}
b = a / 3;
}
}
// command:
// x86_64-pc-linux-gnu-gcc-8.2.0 -c a.c -march=haswell -O2
-fselective-scheduling2 -fsel-sched-pipelining -fno-tree-ch -fno-tree-loop-im
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #17 from qinzhao at gcc dot gnu.org --- the patch has been committed as: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563
[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412 --- Comment #6 from Jason Duerstock --- The fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 wouldn't happen to have caused this, would it?
[Bug target/86965] New: nios2 optimizer forgets about known upper bits of register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86965 Bug ID: 86965 Summary: nios2 optimizer forgets about known upper bits of register Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: already5chosen at yahoo dot com Target Milestone: --- Created attachment 44545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44545&action=edit source code that demonstrates my case Target: nios2-elf Configured with: ../gcc-8.2.0/configure \ --target=nios2-elf \ --prefix=/home/m/opt/cross \ --disable-nls \ --enable-languages=c,c++ \ --without-headers \ --enable-multiarch Thread model: single gcc version 8.2.0 (GCC) I am not sure if two cases in my report are related to each other. To me it looks like they are since both cases appear related to optimizer losing track of known state of upper 24 bits of register. I know that bug writing guidelines discourage inclusion of the content of the object file, but I made an effort to make it as short as possible. It really looks like the only sane way to report. : 0: 20c7ldb r3,0(r4) 4: 18bff404addir2,r3,-48 8: 28800015stw r2,0(r5) c: 18801960cmpeqi r2,r3,101 10: 18c01120cmpeqi r3,r3,68 14: 10c4b03aor r2,r2,r3 18: f800283aret 001c : 1c: 2083ldbur2,0(r4) 20: 10c03fccandir3,r2,255 24: 18c0201cxorir3,r3,128 28: 18ffe004addir3,r3,-128 2c: 18fff404addir3,r3,-48 30: 108037ccandir2,r2,223 34: 28c00015stw r3,0(r5) 38: 10801160cmpeqi r2,r2,69 3c: f800283aret #-- comments: bad1 should generate approximately the same code as good1. 7 instructions instead of 9 Or, if compiler really wants to be smart, it can generate 6 instructions: ldbr2,0(r4) addi r3,r2,-48 stwr3,0(r5) andi r2,r2,223 ; sign extension in bits[31..24] does not matter! cmpeqi r2,r2,69 ret #-- end of comments: 0040 : 40: 2187ldb r6,0(r4) 44: 30c00b60cmpeqi r3,r6,45 48: 31800ae0cmpeqi r6,r6,43 4c: 28c00015stw r3,0(r5) 50: 1986b03aor r3,r3,r6 54: 20c5883aadd r2,r4,r3 58: f800283aret 005c : 5c: 2187ldb r6,0(r4) 60: 30c00b60cmpeqi r3,r6,45 64: 31800ae0cmpeqi r6,r6,43 68: 18803fccandir2,r3,255 # this instruction serves no purpose 6c: 1986b03aor r3,r3,r6 70: 28800115stw r2,4(r5) 74: 28800015stw r2,0(r5) 78: 20c5883aadd r2,r4,r3 7c: f800283aret #-- comments: bad2 should be identical to good2 except of addition of the second store. #-- end of comments:
[Bug c++/70693] valgrind error in get_visual_column
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70693 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #8 from David Malcolm --- Working on a fix; sorry for the delay.
[Bug c++/67012] decltype(auto) with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67012 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/86966] New: ICE (Segmentation fault) for an explicit specialization of a member class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86966
Bug ID: 86966
Summary: ICE (Segmentation fault) for an explicit
specialization of a member class template
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.reshetnikov at gmail dot com
Target Milestone: ---
/* SOURCE */
template
struct S {
template
struct X { };
};
template<>
template<>
struct S<>::X { };
S<>::X<> x;
/*** END SOURCE ***/
/* OUTPUT */
:11:8: internal compiler error: Segmentation fault
11 | S<>::X<> x;
|^
Compiler returned: 1
/*** END OUTPUT ***/
[Bug c++/86966] ICE (Segmentation fault) for an explicit specialization of a member class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86966 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-15 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed (but invalid?).
[Bug c++/86966] ICE (Segmentation fault) for an explicit specialization of a member class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86966
--- Comment #2 from Vladimir Reshetnikov ---
I believe the code is valid. We explicitly specialize the member class template
X of S for S<> (i.e. the parameter pack T is empty). T is expanded into a list
of zero non-type template parameters of S<>::X.
Here is a similar code where we specialize for S, i.e. provide one
template argument bool for the pack T:
template
struct S {
template
struct X { };
};
template<>
template
struct S::X { };
Here T is expanded into a list of one non-type template parameter of type bool.
This code compiles successfully.
[Bug sanitizer/86962] [9 Regression] ICE in sanitize_rewrite_addressable_params, at sanopt.c:1173 with nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86962 --- Comment #1 from Eric Botcazou --- > Issues is that there's a param with DECL_HAS_VALUE_EXPR_P which is > addressable. We can probably skip these, but I'm curious Eric how that > changed in your commit? It's a new object, i.e. a PARM_DECL with DECL_HAS_VALUE_EXPR_P. Before we would create a VAR_DECL and leave the PARM_DECL orphaned.
[Bug c++/86942] A trailing-return-type is allowed when the return type is not 'auto' for using declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86942
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
Tweaked example that is accepted:
using T = void() -> int;
void f ();
int
main ()
{
T *t = f;
}
[Bug c++/70693] valgrind error in get_visual_column
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70693
--- Comment #9 from David Malcolm ---
The issue occurs due to a stray carriage return aka '\r' aka ^M, occurring
towards the end of line 35 of attachment 38289 - but not at the end itself.
This carriage return confuses our line numbering.
When lexing attachment 38289, the "break" token is recorded as being
at line 55 column 8:
(gdb) p next_tinfo
$1 = (const token_indent_info &) @0x7fffd3d0: {location = 382052, type =
CPP_KEYWORD, keyword = RID_BREAK}
...but input.c (and thus diagnostic-show-locus) are accessing the line beyond
for "line 55":
(gdb) call inform (382052, "'break' token is here")
../../src/attachment-38289.cc: In member function ‘bool
{anonymous}::SgmlFilter::process_char(FilterChar::Chr)’:
../../src/attachment-38289.cc:55:8: note: 'break' token is here
55 |
|^
"cat -n" and emacs both agree with this latter numbering, showing the "break;"
as being on line 54, and with line 55 as that blank line.
This discrepancy between the lexer's line numbering and input.c's line
numbering leads to an out-of-range read in get_visual_column (trying to read
column 8, to locate the "break;", but finding the next line, which is only 4
characters long).
[Bug c++/86966] ICE (Segmentation fault) for an explicit specialization of a member class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86966 --- Comment #3 from Vladimir Reshetnikov --- Might be related to Bug 86960 and Bug 86918.
[Bug c++/86942] A trailing-return-type is allowed when the return type is not 'auto' for using declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86942 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug fortran/86945] BUG with optimisation of select case statement in gfortran v8.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945 --- Comment #4 from Harald Anlauf --- (In reply to Harald Anlauf from comment #3) > Self contained alternative testcase: > With -Og, -O1 and higher: > > id= 1 > ierr1, OK =0 T > ierr2, OK =1 F The magic option is -fwrapv / -fno-wrapv. With -Og -fwrapv: ierr1, OK =0 T ierr2, OK =0 T With -Og -fno-wrapv: ierr1, OK =0 T ierr2, OK =1 F Middle-end bug.
[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412
Sergei Trofimovich changed:
What|Removed |Added
CC||abel at ispras dot ru
--- Comment #7 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #5)
> Slightly shorter reproduced (shrunk with creduce):
>
> // a.c
> int a, b, c;
> int e(int h) {
> double d;
> int f = 1;
> while (b < 1) {
> c = d + f;
> if (b)
> a /= h;
> else {
> long unsigned g;
> f = 0;
> d = h / g + h;
> }
> b = a / 3;
> }
> }
>
> // command:
> // x86_64-pc-linux-gnu-gcc-8.2.0 -c a.c -march=haswell -O2
> -fselective-scheduling2 -fsel-sched-pipelining -fno-tree-ch -fno-tree-loop-im
Bisected this down from gcc-7.3.0 (did not ICE) to gcc-8.
Looks reasonable?
91d7a2f98a6846d6a4ac215abbbcf8e6154b9984 is the first bad commit
commit 91d7a2f98a6846d6a4ac215abbbcf8e6154b9984
Author: abel
Date: Mon Apr 9 09:08:28 2018 +
PR rtl-optimization/83530
* sel-sched.c (force_next_insn): New global variable.
(remove_insn_for_debug): When force_next_insn is true, also leave
only
next insn in the ready list.
(sel_sched_region): When the region wasn't scheduled, make another
pass
over it with force_next_insn set to 1.
* gcc.dg/pr83530.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@259228
138bc75d-0d04-0410-961f-82ee72b054a4
:04 04 11825cae45f4d9839c242188123117a0a9f96803
87391fd9d4f97ee6fe456d1630f37801dc0bf8cc M gcc
[Bug debug/86941] ICE in i386/winnt.c:1258 in i386_pe_seh_unwind_emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86941 nightstrike changed: What|Removed |Added CC||uros at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67967 --- Comment #1 from nightstrike --- Related to PR 67967
[Bug translation/79997] simple-ssa-sprintf i18n: wrong plural form in maybe_warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79997 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Known to work||8.1.0 Resolution|--- |FIXED Known to fail||7.3.0 --- Comment #3 from Martin Sebor --- I believe these issues were fixed in r258154.
[Bug c/80076] -Wmisleading-indentation doesn't trigger when macro is misindented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80076 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-15 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.3.0, 8.2.0, 9.0 --- Comment #1 from Martin Sebor --- Confirmed with GCC 7, 8, and trunk (9).
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Eric Gallager changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-08/msg00798.ht ||ml --- Comment #43 from Eric Gallager --- (In reply to Iain Sandoe from comment #42) > (In reply to Elliot Saba from comment #41) > > Has there been any progress on this? We are running into this while trying > > to cross-compile GCC for Darwin. Has this been fixed in 8.3.0? > > I will be posting two patches (one just posted today) that are my proposed > solution - basically, v2 above plus removing a target hook. One is here: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00798.html
[Bug c++/83428] Static initialization and struct with constexpr ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83428 Matt Morehouse changed: What|Removed |Added CC||mascasa at google dot com --- Comment #2 from Matt Morehouse --- This also reproduces for me on x86_64 at ToT.
[Bug libstdc++/86967] New: time_get fails to parse abbreviated weekday with %A format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86967 Bug ID: 86967 Summary: time_get fails to parse abbreviated weekday with %A format string Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mark.melton at notlem dot com Target Milestone: --- Created attachment 44546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44546&action=edit Small test case showing the bug. The std::time_get::get(...) function fails to parse an abbreviated weekday name when using the "%A" format specifier. It works corrected for the "%a" format specifier where the two specifiers are simply synonyms of one another. Using both "%A" and "%a", the function successfully parses the unabbreviated weekday name. See the attached short test case. I have tested under both 8.2.0 and 7.3.0. cheers, mark
[Bug c++/86966] ICE (Segmentation fault) for an explicit specialization of a member class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86966 --- Comment #4 from Vladimir Reshetnikov --- Also, might be related to Bug 84796.
[Bug c++/86960] [Regression] internal compiler error: in coerce_template_parms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86960 --- Comment #2 from Vladimir Reshetnikov --- Also, might be related to Bug 84796 and Bug 86961.
[Bug c++/86961] ICE in finish_member_declaration when an alias template is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86961 --- Comment #1 from Vladimir Reshetnikov --- Might be related to Bug 86956 and Bug 86959.
[Bug gcov-profile/85367] [GCOV] A call to the _subborrow_u64 builtin-function is wrongly marked as executed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85367 Yibiao Yang changed: What|Removed |Added Resolution|INVALID |WORKSFORME --- Comment #2 from Yibiao Yang --- As you mentioned that it works in gcc 8.1.1 while this bug exist in gcc 8.0.0. Therefore, I change the bug status into worksforme.
[Bug c/86968] New: Unaligned big-endian access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Bug ID: 86968 Summary: Unaligned big-endian access on armv7-a yields 4 ldrb instructions rather than ldr+rev Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sven.koehler at gmail dot com Target Milestone: --- Created attachment 44547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44547&action=edit C source code illustrating the problem armv7-a support unaligned memory access. In case of unaligned little-endian access, gcc generates a single ldr instrction. Also, for aligned big-endian access, gcc generates an ldr followed by a rev instruction (reverses byte order). However, when big-endian access is not aligned, gcc does not use ldr+rev. Instead, it generates 4 ldrb instructions plus the code to move the 4 bytes into a single register. Find the source and generated assembler code attached. My compiler command was arm-none-eabi-gcc -O3 -mthumb -S -o - -march=armv7-a endian.c The version of gcc is 8.2.0
[Bug c/86968] Unaligned big-endian access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 --- Comment #1 from Sven --- Created attachment 44548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44548&action=edit the generated assembler code
[Bug middle-end/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Andrew Pinski changed: What|Removed |Added Summary|Unaligned big-endian access |Unaligned big-endian |on armv7-a yields 4 ldrb|(scalar_storage_order) |instructions rather than|access on armv7-a yields 4 |ldr+rev |ldrb instructions rather ||than ldr+rev --- Comment #2 from Andrew Pinski --- One comment about scalar_storage_order, it is not lowered until RTL time so it never gets optimized by the tree level. I found scalar_storage_order almost never to be very optimial at being optimized.
[Bug c++/86969] New: [Regression] ICE (in tsubst_copy) for a generic recursive lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86969
Bug ID: 86969
Summary: [Regression] ICE (in tsubst_copy) for a generic
recursive lambda
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.reshetnikov at gmail dot com
Target Milestone: ---
/* BEGIN SOURCE */
auto compose = [](auto... fs) {
if constexpr (sizeof...(fs) == 0) {
return [](auto x) { return x; };
} else {
auto fn = [](auto self, auto f, auto... fs) {
if constexpr (sizeof...(fs) == 0) return f;
else return [=](auto x) {
return f(self(self, fs...)(x));
};
};
return fn(fn, fs...);
}
};
static_assert(compose(
[](auto x) { return x * 3; },
[](auto x) { return x + 1; },
[](auto x) { return x / 2; }
)(6) == 12);
/** END SOURCE **/
EXPECTED: no errors.
ACTUAL:
: In instantiation of ' [with auto:1 =
{, , }]:: [with auto:3 = [with auto:1 =
{, , }]::; auto:4 = ; auto:5 = {,
}]':
:11:18: required from ' [with auto:1 =
{, , }]'
:19:5: required from here
:8:30: internal compiler error: in tsubst_copy, at cp/pt.c:15348
8 | return f(self(self, fs...)(x));
| ^
Compiles successfully with 7.3, fails with 8.1 and newer. Compiles successfully
with Clang. Looks similar to Bug 86926, but ICE location is different.
[Bug c++/83428] Static initialization and struct with constexpr ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83428 Aliaksei Kandratsenka changed: What|Removed |Added CC||alkondratenko at gmail dot com --- Comment #3 from Aliaksei Kandratsenka --- constructor is defined after variable in this example. I am not sure this real bug.
[Bug c++/86970] New: Rejected constexpr expression involving lambdas and inheritance, "use of this in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86970
Bug ID: 86970
Summary: Rejected constexpr expression involving lambdas and
inheritance, "use of this in a constant expression"
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jbassett271 at gmail dot com
Target Milestone: ---
Created attachment 44549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44549&action=edit
The .ii file from -save-temps
The following code fails to compile under g++-8:
Command: g++-8 -Wall -Wextra -std=c++17 min.cpp
Compiler Explorer link: https://godbolt.org/g/iByFDC
#include
#include
namespace ns {
template
class Foo : private A
{
public:
template
explicit constexpr Foo(FA&& a)
: A{std::forward(a)}
{}
};
template
Foo(A)->Foo;
template
constexpr auto frobnicate(T&& val)
{
return [val = std::forward(val)] {};
}
template
class Bar
{
A a;
std::tuple b;
public:
template
explicit constexpr Bar(FA&& a, FB&& b)
: a{a}
, b{b}
{}
};
template
Bar(A, B)->Bar;
constexpr auto Baz = ns::Foo{ns::frobnicate(ns::Bar{[] {}, [](int) {}})};
}
Compiler diagnostics:
min.cpp:41:76: error: ‘constexpr ns::Foo::Foo(FA&&) [with FA =
ns::frobnicate(T&&) [with T = ns::Bar, ns::
>]::; A = ns::frobnicate(T&&) [with T = ns::Bar,
ns:: >]::]’ called in a constant expression
constexpr auto Baz = ns::Foo{ns::frobnicate(ns::Bar{[] {}, [](int) {}})};
^
min.cpp:10:28: note: ‘constexpr ns::Foo::Foo(FA&&) [with FA =
ns::frobnicate(T&&) [with T = ns::Bar, ns::
>]::; A = ns::frobnicate(T&&) [with T = ns::Bar,
ns:: >]::]’ is not usable as a ‘constexpr’ function
because:
explicit constexpr Foo(FA&& a)
^~~
min.cpp:11:36: error: call to non-‘constexpr’ function ‘ns::frobnicate(T&&)
[with T = ns::Bar, ns::
>](ns::frobnicate(T&&) [with T = ns::Bar,
ns:: >]::&&)’
: A{std::forward(a)}
^
min.cpp:21:46: note: ‘ns::frobnicate(T&&) [with T = ns::Bar,
ns:: >](ns::frobnicate(T&&) [with T =
ns::Bar, ns:: >]::&&)’ is not usable as a
‘constexpr’ function because:
return [val = std::forward(val)] {};
^
min.cpp:21:46: error: use of ‘this’ in a constant expression
System info (from running `g++-8 -v`):
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.1.0-5ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.1.0 (Ubuntu 8.1.0-5ubuntu1~16.04)
If this is not a bug in GCC, but the code is invalid, perhaps the diagnostic
could be improved. The diagnostics end in a lambda, saying "use of this in a
constant expression", which is confusing, considering that the lambda is not in
a context where `this` is valid and `this` does not appear to be used there.
[Bug c++/86971] New: -Wabi warns it will not warn about anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86971 Bug ID: 86971 Summary: -Wabi warns it will not warn about anything. Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: r030t1 at gmail dot com Target Milestone: --- Noticed while compiling GCC 8.2.0: cc1plus: warning: -Wabi won't warn about anything [-Wabi] This isn't the most pressing issue, but I think the wording should be modified; perhaps: cc1plus: warning: -Wabi won't warn about anything else [-Wabi]
[Bug c/86972] New: Incorrect array-bounds warning with -O2 when creating pointer from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86972
Bug ID: 86972
Summary: Incorrect array-bounds warning with -O2 when creating
pointer from array
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: aes368 at cornell dot edu
Target Milestone: ---
int *p;
int main() {
int a[1];
p = a - 1;
}
The above code raises the warning:
warning: array subscript -1 is below array bounds of ‘int [1]’ [-Warray-bounds]
p = a - 1;
~~^~~
when compiled with
gcc -O2 -Wall
I see this both on 7.3.0 and 8.2.0.
The subscript detected seems to always be the term added to a, though it does
not raise a warning with 0 or +1.
