[Bug target/88640] ICE in mark_reachable_handlers, at tree-eh.c:3926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88640
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-12-31
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
I get this, on a Power8 with checking enabled:
88640.cc: In function 'void c()':
88640.cc:2:6: error: statement marked for throw, but doesn't
void c() try { a = 1.0 / __builtin_sqrt(b) * a; } catch (...) {
^
_7 = _2;
during GIMPLE pass: recip
88640.cc:2:6: internal compiler error: verify_gimple failed
0x10c7772b verify_gimple_in_cfg(function*, bool)
/home/segher/src/gcc/gcc/tree-cfg.c:5425
0x10ae1f03 execute_function_todo
/home/segher/src/gcc/gcc/passes.c:1943
0x10ae359b do_per_function
/home/segher/src/gcc/gcc/passes.c:1621
0x10ae37bb execute_todo
/home/segher/src/gcc/gcc/passes.c:1997
[Bug target/88616] [9 Regression] ICE in gimplify_expr at gcc/gimplify.c:13363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88616 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2018-12-28 00:00:00 |2018-12-31 CC||jason at gcc dot gnu.org Known to work||8.2.0 Summary|ICE in gimplify_expr at |[9 Regression] ICE in |gcc/gimplify.c:13363|gimplify_expr at ||gcc/gimplify.c:13363 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #2 from Martin Liška --- If I see correctly, started with r265788.
[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88430 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- Jakub: can it be closed as resolved?
[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 --- Comment #10 from Martin Liška --- H.J. : Can you please run updated benchmark on a recent machine and provide slow down numbers for that?
[Bug libgcc/88641] New: crtstuff.c ctors/dtors list breaks with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88641
Bug ID: 88641
Summary: crtstuff.c ctors/dtors list breaks with
-fdata-sections
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ambrop7 at gmail dot com
Target Milestone: ---
Created attachment 45309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45309&action=edit
Patch to compile crtstuff.c with -fno-function-sections and -fno-data-sections.
Breakage of ctors/dtors lists in crtbegin.o/crtend.o may occur when
CFLAGS_FOR_TARGET contains -fdata-sections, leading to a crash at program
startup.
The issue is in libgcc/crtstuff.c where __LIBGCC_CTORS_SECTION_ASM_OP__ is
used. I have experienced this with the MicroBlaze architecture, but any
architecture where this code path is used has to be affected. Specifically, the
problem is in the following code:
static func_ptr force_to_data[1] __attribute__ ((__used__)) = { };
asm (__LIBGCC_CTORS_SECTION_ASM_OP__);
STATIC func_ptr __CTOR_LIST__[1]
__attribute__ ((__used__, aligned(sizeof(func_ptr
= { (func_ptr) (-1) };
Here asm is used to make the variable go into a specific section, usually
".ctors" or ".dtors". However, with -fdata-sections, gcc will anyway put it
into its own section such as ".data.__CTOR_LIST__", and the asm will have no
effect. The result is that these variables will not be found by the linker
script using expressions like "KEEP (*crtbegin.o(.ctors))", which will cause a
runtime failure in __do_global_ctors_aux as the ctors list will have no
terminator.
I believe that -ffunction-section could also cause problems in the crtstuff
code, in particular where __LIBGCC_TEXT_SECTION_ASM_OP__ is used; there seems
to be an assumption that all functions are by default placed in the ".text"
section, which is not true with -ffunction-sections.
I suggest fixing these issues by ensuring that crtstuff.c is compiled with
-fno-function-sections and -fno-data-sections. I am attaching a patch that I
have verified fixes the ctors/dtors section problem.
[Bug c/88642] New: Accepts ill-formed program with invalid scalar initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88642
Bug ID: 88642
Summary: Accepts ill-formed program with invalid scalar
initialization syntax.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test program (test.c):
int main()
{
int x = { { 0 } };
}
Compilation command line:
clang prog.c -Wall -Wextra -std=c11 -pedantic-errors
Observed behaviour:
No error message outputed. Only warning messages outputed.
Expected behaviour:
An error message outputed.
The initalizer 0 or { 0 } is valid according to 6.7.9/11, but not
{ { 0 } } .
Note:
Clang gives the expected error message for the program.
[Bug c/88582] GCC does not unqualify return types in the case of _Atomic qualified return type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88582 Anders Granlund changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Anders Granlund --- Probably a defect in the standard. The behaviour seems reasonable since the _Atomic type qualifier is different from the other type qualifiers in that it may change the size, represenation and alignment of a type.
[Bug lto/88643] New: -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643
Bug ID: 88643
Summary: -Wl,--wrap not supported with LTO
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Seen in cmocka package:
$ cat foo.h
int cook(void);
$ cat foo.c
#include "foo.h"
int __wrap_cook(void)
{
return 0;
}
$ cat bar.c
int cook(void)
{
return -1;
}
$ cat main.c
#include "foo.h"
int main()
{
if (cook () == -1)
__builtin_abort ();
return 0;
}
$ gcc main.c foo.c bar.c -Wl,--wrap=cook && ./a.out
(ok)
$ gcc main.c foo.c bar.c -Wl,--wrap=cook -flto && ./a.out
Aborted (core dumped)
$ cat main.res
3
main.o 2
198 afba4c81ec45b173 PREVAILING_DEF main
215 afba4c81ec45b173 RESOLVED_IR cook
foo.o 1
197 34da4dbae42a1068 PREVAILING_DEF_IRONLY __wrap_cook
bar.o 1
197 d2fb0e1d62586272 PREVAILING_DEF_IRONLY cook
I'm not sure there's an API for linker plugin to resolve a symbol with a
deferent one. Honza?
[Bug target/88644] New: Unexpected pub type info eliminated after r 246973 (causes pubtypes-*.c to regress).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88644 Bug ID: 88644 Summary: Unexpected pub type info eliminated after r 246973 (causes pubtypes-*.c to regress). Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- r246973 addresses PR debug/80263 with : * dwarf2out.c (modified_type_die): Try harder not to emit internal sizetype type into debug info. This appears to do the expected thing for debug_info on Darwin (i.e. same as Linux): .byte 0x7 # DW_AT_encoding - .ascii "sizetype\0" # DW_AT_name - .byte 0x2 # uleb128 0x2; (DIE (0x18c) DW_TAG_base_type) + .ascii "long unsigned int\0"# DW_AT_name + .byte 0x2 # uleb128 0x2; (DIE (0x1a4) DW_TAG_base_type) and.. .byte 0x8 # DW_AT_byte_size - .byte 0x7 # DW_AT_encoding - .ascii "long unsigned int\0"# DW_AT_name - .byte 0x5 # uleb128 0x5; (DIE (0x1ae) DW_TAG_pointer_type) - .byte 0x8 # DW_AT_byte_size - .byte 0x4 # uleb128 0x4; (DIE (0x1b0) DW_TAG_typedef) + .byte 0x4 # uleb128 0x4; (DIE (0x1b3) DW_TAG_typedef) but it has an unexpected effect on pubtypes .ascii "sizetype\0" # external name - .long 0x18c # DIE offset + .long 0x1a4 # DIE offset + .byte 0x90# GDB-index flags .ascii "char\0" # external name - .long 0x199 # DIE offset - .ascii "long unsigned int\0"# external name - .long 0x1b0 # DIE offset + .long 0x1b3 # DIE offset + .byte 0x90# GDB-index flags So .. here the sizetype is still emitted (not intended) and the underlying type is not. Linux does the expected thing. AFAICT, the only difference appears to be that "long unsigned int" appears *after* "sizetype" on Darwin but *before* it on Linux.
[Bug target/88644] Unexpected pub type info eliminated after r 246973 (causes pubtypes-*.c to regress).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88644 Iain Sandoe changed: What|Removed |Added Target||*-*-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-31 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.5 Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe --- note that if we try -ggnu-pubnames, the effect is still present.
[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995 --- Comment #12 from Thomas Koenig --- Author: tkoenig Date: Mon Dec 31 14:59:46 2018 New Revision: 267487 URL: https://gcc.gnu.org/viewcvs?rev=267487&root=gcc&view=rev Log: 2018-12-31 Thomas Koenig PR fortran/82995 * trans-expr.c (gfc_conv_procedure_call): Pass NULL pointer for missing optional dummy arguments for library routines. * trans-intinsic.c (conv_mask_condition): New function. (gfc_conv_intrinsic_arith): Detect and handle optional mask. (gfc_conv_intrinsic_minmaxloc): Likewise. (gfc_conv_intrinsic_findloc): Likewise. (gfc_conv_intrinsic_minmaxval): Likewise. (gfc_inline_intrinsic_function_p): Do not inline for rank > 1 if an optional mask is present. 2018-12-31 Thomas Koenig PR fortran/82995 * m4/ifindloc0.m4: Handle case of absend optional argument, passed as a NULL pointer. Correct allocation of retarray->base_addr. * m4/ifindloc1.m4: Likewise. * m4/ifindloc2.m4: Handle case of absend optional argument, passed as a NULL pointer. * m4/iforeach-s.m4: Likewise. * m4/iforeach-s2.m4: Likewise. * m4/iforeach.m4: Likewise. * m4/ifunction-s.m4: Likewise. * m4/ifunction-s2.m4: Likewise. * m4/ifunction.m4: Likewise. * generated/findloc0_c16.c: Regenerated. * generated/findloc0_c4.c: Regenerated. * generated/findloc0_c8.c: Regenerated. * generated/findloc0_i1.c: Regenerated. * generated/findloc0_i16.c: Regenerated. * generated/findloc0_i2.c: Regenerated. * generated/findloc0_i4.c: Regenerated. * generated/findloc0_i8.c: Regenerated. * generated/findloc0_r16.c: Regenerated. * generated/findloc0_r4.c: Regenerated. * generated/findloc0_r8.c: Regenerated. * generated/findloc0_s1.c: Regenerated. * generated/findloc0_s4.c: Regenerated. * generated/findloc1_c16.c: Regenerated. * generated/findloc1_c4.c: Regenerated. * generated/findloc1_c8.c: Regenerated. * generated/findloc1_i1.c: Regenerated. * generated/findloc1_i16.c: Regenerated. * generated/findloc1_i2.c: Regenerated. * generated/findloc1_i4.c: Regenerated. * generated/findloc1_i8.c: Regenerated. * generated/findloc1_r16.c: Regenerated. * generated/findloc1_r4.c: Regenerated. * generated/findloc1_r8.c: Regenerated. * generated/findloc1_s1.c: Regenerated. * generated/findloc1_s4.c: Regenerated. * generated/findloc2_s1.c: Regenerated. * generated/findloc2_s4.c: Regenerated. * generated/iall_i1.c: Regenerated. * generated/iall_i16.c: Regenerated. * generated/iall_i2.c: Regenerated. * generated/iall_i4.c: Regenerated. * generated/iall_i8.c: Regenerated. * generated/iany_i1.c: Regenerated. * generated/iany_i16.c: Regenerated. * generated/iany_i2.c: Regenerated. * generated/iany_i4.c: Regenerated. * generated/iany_i8.c: Regenerated. * generated/iparity_i1.c: Regenerated. * generated/iparity_i16.c: Regenerated. * generated/iparity_i2.c: Regenerated. * generated/iparity_i4.c: Regenerated. * generated/iparity_i8.c: Regenerated. * generated/maxloc0_16_i1.c: Regenerated. * generated/maxloc0_16_i16.c: Regenerated. * generated/maxloc0_16_i2.c: Regenerated. * generated/maxloc0_16_i4.c: Regenerated. * generated/maxloc0_16_i8.c: Regenerated. * generated/maxloc0_16_r10.c: Regenerated. * generated/maxloc0_16_r16.c: Regenerated. * generated/maxloc0_16_r4.c: Regenerated. * generated/maxloc0_16_r8.c: Regenerated. * generated/maxloc0_16_s1.c: Regenerated. * generated/maxloc0_16_s4.c: Regenerated. * generated/maxloc0_4_i1.c: Regenerated. * generated/maxloc0_4_i16.c: Regenerated. * generated/maxloc0_4_i2.c: Regenerated. * generated/maxloc0_4_i4.c: Regenerated. * generated/maxloc0_4_i8.c: Regenerated. * generated/maxloc0_4_r10.c: Regenerated. * generated/maxloc0_4_r16.c: Regenerated. * generated/maxloc0_4_r4.c: Regenerated. * generated/maxloc0_4_r8.c: Regenerated. * generated/maxloc0_4_s1.c: Regenerated. * generated/maxloc0_4_s4.c: Regenerated. * generated/maxloc0_8_i1.c: Regenerated. * generated/maxloc0_8_i16.c: Regenerated. * generated/maxloc0_8_i2.c: Regenerated. * generated/maxloc0_8_i4.c: Regenerated. * generated/maxloc0_8_i8.c: Regenerated. * generated/maxloc0_8_r10.c: Regenerated. * generated/maxloc0_8_r16.c: Regenerated. * generated/maxloc0_8_r4.c: Regenerated. * generated/maxloc0_8_r8.c: Regenerated. * generated/maxloc0_8_s1.c: Regenerated.
[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Thomas Koenig --- This one is fixed. The only (minor) thing is that, if the function result for SUM or PRODUCT has rank >= 1, we fall back to the library version if the MASK is passed as an absent optional argument. Why? Well, the scalarized loop took its bounds from the last argument pushed to the scalarizer, which was the mask. If that mask was absent, it used uninitialized variables. For the one-dimensional code, I was able to handle this by reversing the order with this part of the patch: - gfc_add_ss_to_loop (&loop, arrayss); + + /* We add the mask first because the number of iterations is +taken from the last ss, and this breaks if an absent +optional argument is used for mask. */ + if (maskexpr && maskexpr->rank > 0) gfc_add_ss_to_loop (&loop, maskss); + gfc_add_ss_to_loop (&loop, arrayss); For the multi-dimensional case, I tried to do so, but failed. OTOH, the code is correct, and I doubt that generating inlined code for this corner case is actually worth putting in the time. So, closing.
[Bug web/86315] Bugzilla: add "cc count" and "duplicate count" columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86315 Frédéric Buclin changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Frédéric Buclin --- (In reply to Martin Liška from comment #16) > Thank you Frédéric for the changes. Can you please also include changes > suggested in: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86315#c4 I don't think it should be a column in buglists, but rather be implemented as I commented in the upstream bug. Please file a separate bug for this.
[Bug fortran/82313] Rejects-valid for sum(minloc(...))) as array dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82313 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Thomas Koenig --- So, resolved as invalid.
[Bug target/86814] xtensa port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86814 --- Comment #1 from jcmvbkbc at gcc dot gnu.org --- Author: jcmvbkbc Date: Mon Dec 31 16:51:36 2018 New Revision: 267488 URL: https://gcc.gnu.org/viewcvs?rev=267488&root=gcc&view=rev Log: PR target/86814 Xtensa architecture is not affected by speculation. gcc/ 2018-12-31 Max Filippov * config/xtensa/xtensa.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/xtensa/xtensa.c
[Bug target/86814] xtensa port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86814 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jcmvbkbc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- Fixed in the trunk
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86814, which changed state. Bug 86814 Summary: xtensa port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86814 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/84072] [meta-bug] -mindirect-branch=thunk issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84072 Bug 84072 depends on bug 86952, which changed state. Bug 86952 Summary: Avoid jump table for switch statement with -mindirect-branch=thunk https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX
[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #11 from H.J. Lu --- (In reply to Martin Liška from comment #10) > H.J. : Can you please run updated benchmark on a recent machine and provide > slow down numbers for that? The numbers aren't stable: [hjl@gnu-cfl-1 microbenchmark]$ make ./test 3 loops: global: 21, total: 625 no jump table: 178424 global: 21, total: 625 jump table : 266792 (149.53%) [hjl@gnu-cfl-1 microbenchmark]$ make ./test 3 loops: global: 21, total: 625 no jump table: 185068 global: 21, total: 625 jump table : 266678 (144.10%) [hjl@gnu-cfl-1 microbenchmark]$ make ./test 3 loops: global: 21, total: 625 no jump table: 292810 global: 21, total: 625 jump table : 214840 (73.37%) [hjl@gnu-cfl-1 microbenchmark]$ Close it for now.
[Bug c/88645] New: Don't assume functions are always nonnull if there's __attribute__((weak_import)), similar to __attribute__((weak))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88645
Bug ID: 88645
Summary: Don't assume functions are always nonnull if there's
__attribute__((weak_import)), similar to
__attribute__((weak))
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
OS: Darwin/macOS
Test vector:
extern void a (void) __attribute__((weak_import));
int main(void) {
return !!a;
}
It shouldn't print a warning **iff** on macOS.
This warning:
warning: the address of 'void a()' will never be NULL [-Waddress]
The test would pass if it was __attribute__((weak)) instead of
__attribute__((weak_import))
The fix can be added to the `warn_for_null_address` function in gcc/cp/typeck.c
Aside from the warning, the assembly generation behavior is correct.
[Bug c/88645] Don't assume functions are always nonnull if there's __attribute__((weak_import)), similar to __attribute__((weak))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88645 --- Comment #1 from MCCCS --- Typo: fix can be added to "decl_with_nonnull_addr_p" of "/c-family/c-common.c" if anyone is interested.
[Bug middle-end/88575] gcc got confused by different comparison operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
--- Comment #1 from joseph at codesourcery dot com ---
On Sat, 22 Dec 2018, bugzi...@poradnik-webmastera.com wrote:
> In test() gcc is not able to determine that for a==b it does not have to
> evaluate 2nd comparison and can use value of a if 1st comparison is true. When
> operators are swapped like in test2() or are the same, code is optimized.
>
> [code]
> double test(double a, double b)
> {
> if (a <= b)
> return a < b ? a : b;
> return 0.0;
> }
You didn't give compilation options, but if a and b are +0 and -0 in some
order, the first comparison is true but b must be returned instead of a
(in the absence of -fno-signed-zeros or an option implying it).
[Bug c/88582] GCC does not unqualify return types in the case of _Atomic qualified return type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88582 --- Comment #4 from joseph at codesourcery dot com --- The unqualified version of _Atomic int is _Atomic int; references to qualified or unqualified versions of a type do not by default include the type with _Atomic added or removed (see 6.2.5#27).
[Bug c/88584] GCC thinks that the type is complete dispite shaddowing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584 --- Comment #6 from joseph at codesourcery dot com --- This looks like a case that was missed in, or broken by, my fix for bug 13801, which was supposed to address such cases of entities with different (compatible) types in different scopes. It seems GCC handled this correctly (i.e. produced an error) in the 3.4 release series only.
[Bug bootstrap/88623] gcc build uses CXX_FOR_BUILD but files have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88623 --- Comment #1 from joseph at codesourcery dot com --- gcc/ is not libgcc. libgcc is only ever built using exactly the same version of GCC.
[Bug c/88625] c11: GCC Allows enumerator value not representable in type int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88625 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Joseph S. Myers --- This is the same issue with diagnostics using macro definition locations instead of macro expansion locations (so allowing an extension because UINT_MAX was defined in a system header) as in bug 71613, and my comments there still apply that the disabling of warnings for system header locations should be based on the expansion location *by default* rather than fixing a few individual places to use the expansion location (erring on the side of spurious warnings rather than missing warnings). *** This bug has been marked as a duplicate of bug 71613 ***
[Bug c/71613] Useful warnings silenced when macros from system headers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613 Joseph S. Myers changed: What|Removed |Added CC||anders.granlund.0 at gmail dot com --- Comment #10 from Joseph S. Myers --- *** Bug 88625 has been marked as a duplicate of this bug. ***
[Bug c++/88646] New: Optimizer failure on integer sum overflow cast to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88646 Bug ID: 88646 Summary: Optimizer failure on integer sum overflow cast to bool Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gianni at mariani dot ws Target Milestone: --- Created attachment 45310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45310&action=edit Source code for bug: add_bug.cpp Compiler --version "g++ (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516". On a (uname -a): "Linux raspberrypi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux" The attached file runs fine without optimization but fails on signed integers >31 bits in size only in the optimized case. Note: g++ --std=c++14 -O3add_bug.cpp -o add_bug out: ERROR: add_bug.cpp:90 Failed the N test l_v=0 i=33 w_T=i ERROR: add_bug.cpp:90 Failed the N test l_v=0 i=33 w_T=l ERROR: add_bug.cpp:90 Failed the N test l_v=0 i=65 w_T=x The reason is add_bug.cpp:88. i.e.: for ( int i = 2; l_v += l_v, l_v; ++ i ) The termination condition is l_v += l_v which should terminate when l_v==(1<<31) for l_v of 32 bit integer types.
[Bug c++/88646] Optimizer failure on integer sum overflow cast to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88646 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Signed integer overflow is undefined. In the case of short and signed char, the operations are promoted to int due to the way C++ works.
[Bug target/88510] GCC generates inefficient U64x2/v2di scalar multiply for NEON32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88510 Devin Hussey changed: What|Removed |Added Summary|GCC generates inefficient |GCC generates inefficient |U64x2 scalar multiply for |U64x2/v2di scalar multiply |NEON32 |for NEON32 --- Comment #1 from Devin Hussey --- I noticed that the scalarization is performed in the veclower21 stage. In making a patch for LLVM, I found that the x86 code could basically be copy-pasted over, just adding truncates and replacing the SSE instructions with NEON instructions. I would add it if someone told me where the SSE code is and where to put the NEON code. That is what helped me with the LLVM patch.
[Bug c++/88646] Optimizer failure on integer sum overflow cast to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88646 gianni at mariani dot ws changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from gianni at mariani dot ws --- While it may be undefined, should the result at least be consistent? Either the result is zero and the bool cast works as the code expected or the result is non zero and the value printed is non zero. Note the printed l_v=0. Also note that casting the result to int doesn't work either.
