[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490 Alan Modra changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de Summary|char array constant put in |[9 Regression] char array |string merge section|constant put in string ||merge section --- Comment #2 from Alan Modra --- Putting the array initialiser in a STRING_CST conflicts with varasm.c:categorize_decl_for_section returning SECCAT_RODATA_MERGE_STR for STRING_CST.
[Bug tree-optimization/89491] New: Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491
Bug ID: 89491
Summary: Inline jump tables
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
int square(int x) {
return x*x;
}
int add(int x) {
return x + x;
}
typedef int (*p) (int);
p arr[4] = {square, add};
int test(int x) {
int res = arr[1](x);
return res;
}
Expected:
test(int):
lea eax, [rdi+rdi]
ret
Currently:
test(int):
jmp [QWORD PTR arr[rip+8]]
If the index to the jump table isn't a constant, should not be better to expand
"if else" chain like:
if (x==1) arr[1](x);
else if (x==2) arr[2](x);
..and then take an opportunity to inline functions?
[Bug c++/89486] GCC fails to compile designated initializer use involving implicit conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89486
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #1 from Harald van Dijk ---
This is a duplicate of #71446. As the error message hints, {.b = nullptr} is
treated as just {nullptr} here, so it attempts to initialise a rather than b.
[Bug tree-optimization/89491] Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491 --- Comment #1 from Andrew Pinski --- arr is non-constant so GCC cannot assume it would be square or add all the time.
[Bug c++/89481] constexpr function allows writing one active union member and reading another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89481 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- GCC trunk starting with r269052 aka PR89336 fix will reject this too for -std=c++14 and -std=c++17 too: pr89481.C:20:29: in ‘constexpr’ expansion of ‘all_zeros()’ pr89481.C:10:32: error: change of the active member of a union from ‘all_zeros()::mix::numeric’ to ‘all_zeros()::mix::bytes’ 10 | zero.bytes[sizeof(double)] = '\0'; | ~~~^~ It is accepted with -std=c++2a where changing of active member is allowed.
[Bug c++/89481] constexpr function allows writing one active union member and reading another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89481 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 45814 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45814&action=edit gcc9-pr89481.patch Untested fix for -std=c++2a compilation.
[Bug tree-optimization/89491] Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491 --- Comment #2 from Dávid Bolvanský --- Right, static helps. What about more complex examples, like inlining vtables? https://gcc.godbolt.org/z/ZXkRYa
[Bug target/89438] [9 Regression] ICE in glibc/sysdeps/ieee754/dbl-64/e_pow.c (internal compiler error: in decompose, at rtl.h:2266)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89438 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Feb 25 09:51:27 2019 New Revision: 269185 URL: https://gcc.gnu.org/viewcvs?rev=269185&root=gcc&view=rev Log: PR target/89438 * config/arm.vfp.md (*negdf2_vfp): Use gen_int_mode (0x8000, SImode) instead of GEN_INT (0x8000). * config/arm/neon.md (neon_copysignf): Likewise. * gcc.dg/pr89438.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89438.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/neon.md trunk/gcc/config/arm/vfp.md trunk/gcc/testsuite/ChangeLog
[Bug target/89438] [9 Regression] ICE in glibc/sysdeps/ieee754/dbl-64/e_pow.c (internal compiler error: in decompose, at rtl.h:2266)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89438 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-25 Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Hmm, I can't reproduce this with trunk or GCC 8. I think the exact GCC configuration is key here. Can you provide the output of "arm-linux-gnueabihf-gcc -v" please?
[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 Target Milestone|--- |9.0 Summary|ice in |[9 Regression] ice in |df_reg_chain_verify_unmarke |df_reg_chain_verify_unmarke |d, at df-scan.c:3995|d, at df-scan.c:3995 Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak --- Confirmed with "-O2 -mavx".
[Bug target/89434] [7/8/9 Regression] wrong code with -Og and __builtin_mul_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89434 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Feb 25 10:32:38 2019 New Revision: 269186 URL: https://gcc.gnu.org/viewcvs?rev=269186&root=gcc&view=rev Log: PR target/89434 * config/arm/arm.md (*subsi3_carryin_const): Use arm_neg_immediate_operand predicate instead of arm_not_immediate_operand, "L" constraint instead of "K" and print it using %n2 instead of %B2. (*subsi3_carryin_const0): New define_insn. (*subsi3_carryin_compare_const): Use const_int_I_operand predicate instead of arm_not_operand and "I" constraint instead of "K" and print it using %n3 instead of %B2. Instead of using match_dup 2 add another match_operand and in the condition check that it is negation of operands[2]. (*subsi3_carryin_compare_const0): New define_ins. (*subdi_di_zesidi): Adjust to use *subsi3_carryin_const0 instead of *subsi3_carryin_const. (*arm_cmpdi_insn): Fix splitting into *subsi3_carryin_compare_const, split into *subsi3_carryin_compare_const0 if the highpart is zero. * gcc.c-torture/execute/pr89434.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr89434.c trunk/gcc/testsuite/gcc.dg/pr89434.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug libfortran/89274] Inconsistent list directed output of INTEGER(16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89274 --- Comment #2 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Mon Feb 25 10:39:38 2019 New Revision: 269187 URL: https://gcc.gnu.org/viewcvs?rev=269187&root=gcc&view=rev Log: 2019-02-25 Dominique d'Humieres PR libfortran/89274 * gfortran.dg/list_directed_large.f90: New test. 2019-02-25 Dominique d'Humieres PR libfortran/89274 * io/write.c (write_integer): Add width for INTEGER(16). Added: trunk/gcc/testsuite/gfortran.dg/list_directed_large.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c
[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474 Uroš Bizjak changed: What|Removed |Added CC||hjl at gcc dot gnu.org, ||hubicka at gcc dot gnu.org --- Comment #4 from Uroš Bizjak --- Regression introduced by r269119: i386: Add pass_remove_partial_avx_dependency.
[Bug libfortran/89274] Inconsistent list directed output of INTEGER(16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89274 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres --- > Seems obvious, Ok for trunk with a ChangeLog. > > Another point of view would be that for list-directed we should always > use width=0 for all kinds; that would make list-directed more useful > for things like > > print *, 'Frobnicator value is ', frob, ' frobs.' > > but would make it less useful for outputting tables. IIRC this has already been discussed in the past. The choice of a fixed width has been made a long time ago and IMO it is too late to change it.
[Bug rtl-optimization/89487] [8/9 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 CC||jakub at gcc dot gnu.org Target Milestone|--- |8.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Seems tree-data-ref.c creates on this testcase (many apparently) ADDR_EXPRs of these hard register VAR_DECLs and some of them survive until expansion, which ICEs on them. We should never try to create ADDR_EXPR of DECL_HARD_REGISTER VAR_Ps IMHO.
[Bug rtl-optimization/89487] [8/9 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487 --- Comment #2 from Jakub Jelinek --- Can we ignore the DECL_HARD_REGISTER drs, or never canonicalize them to &var (after all, they should never have any non-zero step, offset etc.), something else?
[Bug c++/89488] [9 Regression] ICE in merge_exception_specifiers, at cp/typeck2.c:2395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89488 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-25 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug c++/89488] [9 Regression] ICE in merge_exception_specifiers, at cp/typeck2.c:2395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89488 Jakub Jelinek changed: What|Removed |Added Keywords|ice-on-invalid-code |error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0
[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482 --- Comment #3 from Ciro Santilli --- On Ubuntu 16.04 GCC 5.4.0 which I have access to now and fails with the same error `arm-linux-gnueabihf-gcc -v` gives: Using built-in specs. COLLECT_GCC=arm-linux-gnueabihf-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/5/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --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-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include Thread model: posix gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9)
[Bug target/89434] [7/8 Regression] wrong code with -Og and __builtin_mul_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89434 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] wrong|[7/8 Regression] wrong code |code with -Og and |with -Og and |__builtin_mul_overflow()|__builtin_mul_overflow() Known to fail|9.0 | --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Cleaned up testcase:
int a;
void foo (double);
int baz (void);
void
bar (void)
{
while (baz ())
foo (a);
}
[Bug fortran/89492] New: [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 Bug ID: 89492 Summary: [9 Regression] Endless compilation of an invalid TRANSFER after r269177 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: anlauf at gcc dot gnu.org Target Milestone: --- As reported at https://gcc.gnu.org/ml/fortran/2019-02/msg00198.html, after revision r269177, compiling the reduced test program bug4a implicit none type bug4 ! Intentionally left empty end type bug4 write(*,*) size(transfer(1,[''])) write(*,*) transfer(transfer([1],[bug4()]),[1],size[1]) end program bug4a gives the error pr34202_red.f90:8:54: 8 |write(*,*) transfer(transfer([1],[bug4()]),[1],size[1]) | 1 Error: Function 'size' requires an argument list at (1) and enter an endless state. If I comment the line write(*,*) size(transfer(1,[''])) I get immediately the error Error: Coarray designator at (1) but 'size' is not a coarray
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||7.4.0, 8.3.0 Keywords||compile-time-hog, ||error-recovery Last reconfirmed||2019-02-25 Blocks||31237 Ever confirmed|0 |1 Target Milestone|--- |9.0 Known to fail||9.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237 [Bug 31237] [meta-bug] TRANSFER intrinsic
[Bug target/89484] ICE in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1171 when using __attribute__((interrupt)) w. Debug Info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89484 --- Comment #3 from Hans-Peter Dusel --- This issue is not related to the c++ compiler g++. It happens also if one uses gcc.
[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474 --- Comment #6 from Jakub Jelinek --- I admit I don't know much about df infrastructure, but it looks completely wrong to me to first modify the various instructions to refer to at that point created, but uninitialized v4sf_const0 pseudo, including df_insn_rescan etc., then df_analyze including DF_DU_CHAIN | DF_UD_CHAIN etc. and finally add an initializer for that pseudo. I'd say df_analyze shouldn't be called if the IL is in so inconsistent state.
[Bug target/89484] ICE in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1171 when using __attribute__((interrupt)) w. Debug Info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89484
--- Comment #4 from Hans-Peter Dusel ---
The Release 8.2.0 of GCC is also affected by this issue.
Here is a snapshot (same test program as mentioned above)
- begin --
alvis:tmp hdusel$ /opt/gcc-8.2.0-rx-none-elf/bin/rx-none-elf-gcc ./test.cpp -c
-g
during RTL pass: dwarf2
./test.cpp: In function 'void ISR_handleUartReceiveData()':
./test.cpp:2:2: internal compiler error: in dwarf2out_frame_debug_adjust_cfa,
at dwarf2cfi.c:1171
{}
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474 --- Comment #7 from Jakub Jelinek --- And another issue is the insertion of the v4sf_const0 initializer outside of bbs.
[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Started with r264850.
[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #4 from Bernd Edlinger ---
funny, how I managed to overlook this...
--- varasm.c.orig 2019-01-25 17:57:32.0 +0100
+++ varasm.c2019-02-25 13:13:55.652051780 +0100
@@ -7634,6 +7634,8 @@
/* Output the objects themselves. */
offset = 0;
+ bool merge_strings = (block->sect->common.flags & SECTION_MERGE)
+&& (block->sect->common.flags & SECTION_STRINGS);
FOR_EACH_VEC_ELT (*block->objects, i, symbol)
{
/* Move to the object's offset, padding with zeros if necessary. */
@@ -7652,7 +7654,7 @@
HOST_WIDE_INT size;
decl = SYMBOL_REF_DECL (symbol);
assemble_constant_contents (DECL_INITIAL (decl), XSTR (symbol, 0),
- DECL_ALIGN (decl), false);
+ DECL_ALIGN (decl), merge_strings);
size = get_constant_size (DECL_INITIAL (decl));
offset += size;
@@ -7669,7 +7671,8 @@
{
HOST_WIDE_INT size;
decl = SYMBOL_REF_DECL (symbol);
- assemble_variable_contents (decl, XSTR (symbol, 0), false, false);
+ assemble_variable_contents (decl, XSTR (symbol, 0), false,
+ merge_strings);
size = tree_to_uhwi (DECL_SIZE_UNIT (decl));
offset += size;
if ((flag_sanitize & SANITIZE_ADDRESS)
[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474
--- Comment #8 from Jakub Jelinek ---
For the former issue, I'd go with:
--- gcc/config/i386/i386.c.jj 2019-02-22 23:02:47.805117610 +0100
+++ gcc/config/i386/i386.c 2019-02-25 12:57:18.238284322 +0100
@@ -2835,7 +2835,14 @@ remove_partial_avx_dependency (void)
continue;
if (!v4sf_const0)
- v4sf_const0 = gen_reg_rtx (V4SFmode);
+ {
+ calculate_dominance_info (CDI_DOMINATORS);
+ df_set_flags (DF_DEFER_INSN_RESCAN);
+ df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
+ df_md_add_problem ();
+ df_analyze ();
+ v4sf_const0 = gen_reg_rtx (V4SFmode);
+ }
/* Convert PARTIAL_XMM_UPDATE_TRUE insns, DF -> SF, SF -> DF,
SI -> SF, SI -> DF, DI -> SF, DI -> DF, to vec_dup and
@@ -2883,12 +2890,6 @@ remove_partial_avx_dependency (void)
if (v4sf_const0)
{
- calculate_dominance_info (CDI_DOMINATORS);
- df_set_flags (DF_DEFER_INSN_RESCAN);
- df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
- df_md_add_problem ();
- df_analyze ();
-
/* (Re-)discover loops so that bb->loop_father can be used in the
analysis below. */
loop_optimizer_init (AVOID_CFG_MODIFICATIONS);
[Bug tree-optimization/89491] Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491 --- Comment #3 from Andrew Pinski --- (In reply to Dávid Bolvanský from comment #2) > Right, static helps. > > What about more complex examples, like inlining vtables? > https://gcc.godbolt.org/z/ZXkRYa Your example is much more complex. The vtable might be constant but where the vtable is stored is not.
[Bug target/83443] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 119)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83443 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #11 from John David Anglin --- Test is now fixed.
[Bug target/81879] Bad compilation of small program if LTO is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879 Martin Liška changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24267 --- Comment #6 from Martin Liška --- (In reply to Martin Liška from comment #5) > The .res file contains just a single object, thus PREEMPTED_REG does not > make sense. Problem will be probably in binutils. I'm investigating right > now.. So no. PREEMPTED_REG is correct and culprit is probably linker: https://sourceware.org/bugzilla/show_bug.cgi?id=24267
[Bug target/81879] Bad compilation of small program if LTO is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Created attachment 45815 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45815&action=edit gcc9-pr89474.patch Untested full fix.
[Bug c++/89450] RFC: Strengthen -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #7 from Martin Liška ---
> Please no. -fstrict-enums currently makes the compiler *more* strictly
> conforming, by following the rules of the standard. Your suggestion arguably
> makes it *less* conforming, by deciding that valid values should emit a
> warning.
>
> What you want is not how enums work in C++. Please don't abuse
> -fstrict-enums when what you want is "some other kind of enum, not one that
> strictly follows the C++ standard".
I don't insist on that, I'm fully aware that it's a hackish approach.
My motivation is chromium package which we build with gcc in openSUSE.
In order to handle all
warning: control reaches end of non-void function [-Wreturn-type]
in switch statements, we have a huge patch:
https://build.opensuse.org/package/view_file/network:chromium/chromium-beta/chromium-non-void-return.patch?expand=1
Clang is more tolerant to c++ enums:
$ cat wreturn.cpp
enum A
{
a,
b,
c
};
int foo(int argc)
{
switch ((A)argc)
case a:
case b:
case c:
return 0;
}
int main(int argc, char **argv)
{
return foo(argc);
}
$ clang++ -Wall wreturn.cpp
[no output]
[Bug tree-optimization/89491] Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- "Inlining" from vtables is called devirtualization, and GCC performs that either if there is just a single possibility, or with PGO if a particular method is known to be very common. Doing it in other cases is probably not a very good idea.
[Bug ada/89349] segfault when building GCC 7 & 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 --- Comment #17 from Martin Liška --- (In reply to Eric Botcazou from comment #16) > . Thank you Erik for the fix!
[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug gcov-profile/89465] [GCOV] Wrong coverage with setjmp and longjmp function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89465 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk in r263111.
[Bug gcov-profile/89469] [GCOV] wrong frequencies for the first statement in the for(;;) block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89469 Martin Liška changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug gcov-profile/89470] [GCOV] wrong frequencies when if statement is executed after a complicated "?:"statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89470 Martin Liška changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's a folding of a constant expression.
[Bug gcov-profile/89468] [GCOV] wrong frequencies when the block is empty in a if statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89468 Martin Liška changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, again a folding of sub-expressions.
[Bug gcov-profile/89467] [GCOV] wrong freqencies when there is comparison operator in the right side of the assignment statement after a label statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89467 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk.
[Bug ada/89493] New: Stack smashing on armv7hl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89493 Bug ID: 89493 Summary: Stack smashing on armv7hl Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: pavel at zhukoff dot net Target Milestone: --- Created attachment 45816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45816&action=edit reproducer Reporting this for ada as reproducer is part of gprbuild (gprinstall) code. In some cases (return from exception handler) stack pointer is set to weird value and either stack smashing protection or storage error occurs. it's easy and 100% reproducible in Fedora linux distribution https://bugzilla.redhat.com/show_bug.cgi?id=1677173 gcc-9.0.1-0.4.fc30.armv7hl gprbuild-2018-12.fc30.armv7hl All other architectures (x86, s390x, ppc64le and aarch64 work fine) We were able to strip reproducer to ~200 LOC (attached) # gprbuild -v -cargs:Ada -O2 -g # valgrind ./exe/process ==29563== Memcheck, a memory error detector ==29563== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==29563== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==29563== Command: ./exe/process ==29563== warning: file does not exist '/tmp/a/satrace.log' ==29563== Warning: client switching stacks? SP change: 0xbdef07c0 --> 0x68818 ==29563== to suppress, use: --max-stackframe=1108836440 or greater aaa ==29563== Invalid write of size 4 ==29563==at 0x40C04: system__secondary_stack__ss_release (in /tmp/test/exe/process) ==29563== Address 0x68754 is 12 bytes inside data symbol "ada_main__sec_default_sized_stacks" ==29563== ==29563== Invalid read of size 4 ==29563==at 0x1A09C: _ada_process (process.adb:119) ==29563== Address 0x687ec is 164 bytes inside data symbol "ada_main__sec_default_sized_stacks" ==29563== ==29563== Invalid read of size 4 ==29563==at 0x1A0A4: _ada_process (process.adb:119) ==29563== Address 0xe1a02026 is not stack'd, malloc'd or (recently) free'd
[Bug tree-optimization/89489] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89489 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Known to work||8.2.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #1 from Martin Liška --- Confirmed, a Graphite issue.
[Bug tree-optimization/89489] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89489 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #2 from Jakub Jelinek --- And due to graphite I can't bisect, Martin, can you?
[Bug bootstrap/89494] New: Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 Bug ID: 89494 Summary: Bootstrap error when using GCC 4.2.1 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: pkubaj at anongoth dot pl Target Milestone: --- I use FreeBSD on powerpc64 architecture, which has GCC 4.2.1 as a system compiler. It does support C++98 which, according to https://gcc.gnu.org/install/prerequisites.html is enough to bootstrap GCC. I can compile GCC 6.5 at most. GCC 7 and newer are broken. FreeBSD ports tree has a work around for that to use newer GCC release from FreeBSD's ports, but it means that to compile GCC 7 or newer, we need to compile 5 or 6. Building GCC 9 fails with: /usr/local/poudriere/ports/default/lang/gcc9-devel/work/.build/./gcc/xgcc -B/usr/local/poudriere/ports/default/lang/gcc9-devel/work/.build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/usr/local/poudriere/ports/default/lang/g cc9-devel/work/gcc-9-20190217/gcc/testsuite/selftests cc1: internal compiler error: Segmentation fault no stack trace because unwind library not available Building GCC 7 is more verbose: /usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/xgcc -B/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.0/bin/ -B/usr/local/powerpc64-portbld-freebsd12.0/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.0/include -isystem /usr/local/powerpc64-portbld-freebsd12.0/sys-include-g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -m32 -fPIC -mstrict-align -O2 -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DIN_GCC-W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread -mno-minimal-toc -I. -I. -I../../.././gcc -I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc -I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/. -I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/../gcc -I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.c:56:0: /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.c: In function '__muldi3': /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.h:219:20: internal compiler error: Segmentation fault #define __NDW(a,b) __ ## a ## di ## b ^ /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.h:273:18: note: in expansion of macro '__NDW' #define __muldi3 __NDW(mul,3) ^ /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.c:548:1: note: in expansion of macro '__muldi3' __muldi3 (DWtype u, DWtype v) ^~~~ no stack trace because unwind library not available Obviously, I'm not asking to fix GCC 4.2.1, but to make a workaround for newer releases
[Bug c++/89495] New: gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495 Bug ID: 89495 Summary: gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- It's a recent UBSAN error: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-printf-warn-2.c -O -Wformat -Wformat-overflow=2 -ftrack-macro-expansion=0 -W ../../gcc/c-family/c-format.c:1272:15: runtime error: signed integer overflow: 2147483640 + 8 cannot be represented in type 'int' #0 0xaeca84 in maybe_read_dollar_number ../../gcc/c-family/c-format.c:1272 #1 0xaf28a1 in argument_parser::read_any_dollar() ../../gcc/c-family/c-format.c:2082 #2 0xafd7c6 in check_format_info_main ../../gcc/c-family/c-format.c:2855 #3 0xaf0b77 in check_format_arg ../../gcc/c-family/c-format.c:1748 #4 0xab18f6 in check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) ../../gcc/c-family/c-common.c:5895 #5 0xab1380 in check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) ../../gcc/c-family/c-common.c:5827 #6 0xaedc92 in check_format_info ../../gcc/c-family/c-format.c:1471 #7 0xaebc46 in check_function_format(tree_node const*, tree_node*, int, tree_node**, vec*) ../../gcc/c-family/c-format.c:1128 #8 0xab1020 in check_function_arguments(unsigned int, tree_node const*, tree_node const*, int, tree_node**, vec*) ../../gcc/c-family/c-common.c:5802 #9 0x92d079 in build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*) ../../gcc/c/c-typeck.c:3118 #10 0x92dfdc in c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*) ../../gcc/c/c-typeck.c:3184 #11 0x9db6b7 in c_parser_postfix_expression_after_primary ../../gcc/c/c-parser.c:9595 #12 0x9d9511 in c_parser_postfix_expression ../../gcc/c/c-parser.c:9270 #13 0x9cc738 in c_parser_unary_expression ../../gcc/c/c-parser.c:7383 #14 0x9cb0b0 in c_parser_cast_expression ../../gcc/c/c-parser.c:7222 #15 0x9c58c7 in c_parser_binary_expression ../../gcc/c/c-parser.c:7025 #16 0x9c4a15 in c_parser_conditional_expression ../../gcc/c/c-parser.c:6759 #17 0x9c4518 in c_parser_expr_no_commas ../../gcc/c/c-parser.c:6676 #18 0x9dc1c6 in c_parser_expression ../../gcc/c/c-parser.c:9731 #19 0x9dc6db in c_parser_expression_conv ../../gcc/c/c-parser.c:9764 #20 0x9c0147 in c_parser_statement_after_labels ../../gcc/c/c-parser.c:5610 #21 0x9be83e in c_parser_compound_statement_nostart ../../gcc/c/c-parser.c:5148 #22 0x9bdf55 in c_parser_compound_statement ../../gcc/c/c-parser.c:4982 #23 0x9b437c in c_parser_declaration_or_fndef ../../gcc/c/c-parser.c:2354 #24 0x9b12a7 in c_parser_external_declaration ../../gcc/c/c-parser.c:1653 #25 0x9b0aa4 in c_parser_translation_unit ../../gcc/c/c-parser.c:1534 #26 0xa16edb in c_parse_file() ../../gcc/c/c-parser.c:19854 #27 0xb39675 in c_common_parse_file() ../../gcc/c-family/c-opts.c:1155 #28 0x1ffdeae in compile_file ../../gcc/toplev.c:456 #29 0x2005afb in do_compile ../../gcc/toplev.c:2204 #30 0x2006129 in toplev::main(int, char**) ../../gcc/toplev.c:2339 #31 0x436822f in main ../../gcc/main.c:39 #32 0x76e7bb7a in __libc_start_main ../csu/libc-start.c:308 #33 0x857579 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x857579) ../../gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int' #0 0xaeca29 in maybe_read_dollar_number ../../gcc/c-family/c-format.c:1272 #1 0xaf28a1 in argument_parser::read_any_dollar() ../../gcc/c-family/c-format.c:2082 #2 0xafd7c6 in check_format_info_main ../../gcc/c-family/c-format.c:2855 #3 0xaf0b77 in check_format_arg ../../gcc/c-family/c-format.c:1748 #4 0xab18f6 in check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) ../../gcc/c-family/c-common.c:5895 #5 0xab1380 in check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) ../../gcc/c-family/c-common.c:5827 #6 0xaedc92 in check_format_info ../../gcc/c-family/c-format.c:1471 #7 0xaebc46 in check_function_format(tree_node const*, tree_node*, int, tree_node**, vec*) ../../gcc/c-family/c-format.c:1128 #8 0xab1020 in check_function_arguments(unsigned int, tree_node const*, tree_node const*, int, tree_node**, vec*) ../../gcc/c-family/c-common.c:5802 #9 0x92d079 in build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*) ../../gcc/c/c-typeck.c
[Bug c++/89495] gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495 Martin Liška changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to work||8.2.0 Version|unknown |9.0 Target Milestone|--- |9.0 Known to fail||9.0
[Bug fortran/89496] New: [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 Bug ID: 89496 Summary: [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist' Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- A recent regression: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/altreturn_1.f90 ../../gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist' #0 0xeb78e3 in get_formal_from_actual_arglist ../../gcc/fortran/trans-types.c:3015 #1 0xeb82d5 in gfc_get_function_type(gfc_symbol*, gfc_actual_arglist*) ../../gcc/fortran/trans-types.c:3081 #2 0xd0d1de in gfc_get_extern_function_decl(gfc_symbol*, gfc_actual_arglist*) ../../gcc/fortran/trans-decl.c:2152 #3 0xd6e804 in conv_function_val ../../gcc/fortran/trans-expr.c:3920 #4 0xd8fa14 in gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:6626 #5 0xe65236 in gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:406 #6 0xc7680b in trans_code ../../gcc/fortran/trans.c:1890 #7 0xc76efa in gfc_trans_code(gfc_code*) ../../gcc/fortran/trans.c:2149 #8 0xd3dfce in gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6568 #9 0xc76f85 in gfc_generate_code(gfc_namespace*) ../../gcc/fortran/trans.c:2166 #10 0xad0181 in translate_all_program_units ../../gcc/fortran/parse.c:6134 #11 0xad0d8e in gfc_parse_file() ../../gcc/fortran/parse.c:6337 #12 0xc379c6 in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 #13 0x2307a40 in compile_file ../../gcc/toplev.c:456 #14 0x230f68d in do_compile ../../gcc/toplev.c:2204 #15 0x230fcbb in toplev::main(int, char**) ../../gcc/toplev.c:2339 #16 0x469a7c8 in main ../../gcc/main.c:39 #17 0x76e7bb7a in __libc_start_main ../csu/libc-start.c:308 #18 0x86dbe9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/f951+0x86dbe9)
[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 Known to work||8.2.0 Blocks||63426 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug c++/71446] Incorrect overload resolution when using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Well, before C++2a it is an extension, so outside of the C++ standard, and GCC has been implementing it as not allowing to skip any fields. In C++2a it is actually a standard language feature, so I guess it needs to participate in the overload resolution.
[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 CC||tkoenig at gcc dot gnu.org --- Comment #1 from Dominique d'Humieres --- Likely due to r268992 (the ICE occurs in the added block). The PR requires an instrumented compiler.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Mon Feb 25 15:01:01 2019 New Revision: 269188 URL: https://gcc.gnu.org/viewcvs?rev=269188&root=gcc&view=rev Log: PR c++/89285 * g++.dg/cpp1y/constexpr-89285-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89285-2.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/89285] [8 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] ICE after |[8 Regression] ICE after |casting the this pointer in |casting the this pointer in |the constructor in C++17|the constructor in C++17 |mode|mode Known to fail||8.3.0 --- Comment #19 from Jakub Jelinek --- Actually, #c16 comment is incorrect, that was the case of the earlier approach (#c4) but not of what has been actually committed. Keeping this open for 8.x, though the patch is unlikely to be backportable.
[Bug c++/71446] Incorrect overload resolution when using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #4 from Roman Perepelitsa ---
Please take a look at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446#c1.
This code compiles. Given that it contains `{.value = 0}`, one would reasonably
expect that it creates an instance of a struct with the data member `value` set
to zero. However, it doesn't. The literal `{.value = 0}` creates an instance of
type `std::initialize_list`. This is very misleading. The code should
either not compile or do what was intended (which is also what C++20 requires
and what clang does).
[Bug c++/89481] constexpr function allows writing one active union member and reading another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89481 --- Comment #3 from Michael Veksler --- Thanks for looking into it. With the fix, does it behave the same way for: - runtime evaluation of all_zeros() - compile time evaluation such as std::integral_constant::value; Currently (trunk 20190223 (experimental) with -std=c++2a), it returns different results for both cases, which does not feel right.
[Bug rtl-optimization/86096] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86096 --- Comment #5 from Alexander Monakov --- Author: amonakov Date: Mon Feb 25 15:14:39 2019 New Revision: 269189 URL: https://gcc.gnu.org/viewcvs?rev=269189&root=gcc&view=rev Log: df-scan: fix use of mw_order in df_mw_compare (PR 86096) PR rtl-optimization/86096 * df-scan.c (df_mw_compare): Do not check mw_reg fields when comparing mw_order values. Modified: trunk/gcc/ChangeLog trunk/gcc/df-scan.c
[Bug rtl-optimization/89487] [8/9 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487 Jakub Jelinek changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r249994.
[Bug fortran/89282] Garbage arithmetics results in fortran with -O3 and overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89282 --- Comment #6 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Mon Feb 25 15:19:45 2019 New Revision: 269190 URL: https://gcc.gnu.org/viewcvs?rev=269190&root=gcc&view=rev Log: 2019-02-25 Dominique d'Humieres PR fortran/89282 * gfortran.dg/overload_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/overload_3.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/89282] Garbage arithmetics results in fortran with -O3 and overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89282 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dominique d'Humieres --- > It stopped failing with r240291, but because it just added early VRP, > it just went latent. With -O3 -fno-tree-vrp it was miscompiled until > r240303 aka PR77648 fix. That fix has been backported to 6.3 and 5.5. Closing.
[Bug c++/89495] [9 Regression] gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Looks like a regression only because the test is new.
I see the same code in there e.g. in GCC 3.2.
That said, I think we can do something like:
2019-02-25 Jakub Jelinek
PR c++/89495
* c-format.c (maybe_read_dollar_number): Compute nargnum in
HOST_WIDE_INT type to avoid overflows and change overflow_flag
checking.
--- gcc/c-family/c-format.c.jj 2019-01-16 09:35:04.565323073 +0100
+++ gcc/c-family/c-format.c 2019-02-25 16:26:07.872810237 +0100
@@ -1268,9 +1268,9 @@ maybe_read_dollar_number (const char **f
overflow_flag = 0;
while (ISDIGIT (*fcp))
{
- int nargnum;
- nargnum = 10 * argnum + (*fcp - '0');
- if (nargnum < 0 || nargnum / 10 != argnum)
+ HOST_WIDE_INT nargnum
+ = HOST_WIDE_INT_UC (10) * argnum + (*fcp - '0');
+ if ((int) nargnum != nargnum)
overflow_flag = 1;
argnum = nargnum;
fcp++;
[Bug libstdc++/89466] [7/8/9 Regression] Accessing the Internet while boostrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89466 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Severity|blocker |normal
[Bug fortran/71935] [7/8/9 Regression] ICE is_c_interoperable(): gfc_simplify_expr failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71935 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres --- > I've read the discussion, but I am not clear about > what the problem actually is. > > Is this something that we can close now? The same for me. Let close this PR. If a related problem appears in a real code, please file a new PR.
[Bug c++/89439] [7/8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89439 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- So dup of PR88256. *** This bug has been marked as a duplicate of bug 88256 ***
[Bug c++/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn), C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 Jakub Jelinek changed: What|Removed |Added CC||gs...@t-online.de --- Comment #7 from Jakub Jelinek --- *** Bug 89439 has been marked as a duplicate of this bug. ***
[Bug fortran/71412] [F03] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #15 from Dominique d'Humieres --- > Indeed I think that is a duplicate of pr71544. So let mark this PR as a duplicate. *** This bug has been marked as a duplicate of bug 71544 ***
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 Dominique d'Humieres changed: What|Removed |Added CC||relliott at umn dot edu --- Comment #12 from Dominique d'Humieres --- *** Bug 71412 has been marked as a duplicate of this bug. ***
[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Earnshaw --- Fixed on trunk (aka gcc-9). Not a regression, so no backport.
[Bug c++/89480] internal compiler error: in unify, at cp/pt.c:22160 with the template argument force conversio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89480 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 70149, which changed state. Bug 70149 Summary: [F08] Character pointer initialization causes ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/31392] [meta-bug] gfortran problems with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392 Bug 31392 depends on bug 70149, which changed state. Bug 70149 Summary: [F08] Character pointer initialization causes ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from Dominique d'Humieres --- > Any answer to this question? No feedback, closing. Please open a new PR for any related issue.
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Dominique d'Humieres --- > This PR is almost ten year old. Any point to let it rot anymore? No answer: WONTFIX.
[Bug target/86019] [8/9 Regression] Unref implementation using atomic_thread_fence generates worse code on x86-64 in gcc 8.1 than 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86019
--- Comment #5 from Jakub Jelinek ---
This used to be handled by peephole2, but that can't do anything with multiple
basic blocks and
(insn 12 11 13 3 (set (mem/v:BLK (scratch:DI) [0 A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0 A8])
] UNSPEC_MEMORY_BLOCKAGE))
"/usr/src/gcc-7/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h":102:26
688 {*memory_blockag
e}
(nil))
emitted in there. And generic code doesn't know anything about the memory
blockage instruction that it would e.g. be able to move it from the conditional
to unconditional if it was the only thing (say let ifcvt pass do it?).
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210 Thomas Koenig changed: What|Removed |Added Status|RESOLVED|NEW CC||tkoenig at gcc dot gnu.org Resolution|WONTFIX |--- Severity|normal |enhancement --- Comment #6 from Thomas Koenig --- Sorry, I missed that one. This is definitely an area where improvement would be quite helpful - our performance there is abysmal. Dominique, I'm all for closing bugs :-) but I think one or two of them should stay. Just because nobody has found time, inclination or knowledge to work on them does not mean nobody should.
[Bug c/77754] [7/8/9 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754 --- Comment #13 from Jakub Jelinek --- Created attachment 45817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45817&action=edit gcc9-pr77754.patch Seems all the ICEs went away with r266271 aka PR87229 fix. I'll test these tests for the testsuite.
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210 --- Comment #7 from Dominique d'Humieres --- > This is definitely an area where improvement would be quite helpful - > our performance there is abysmal. Compiling the test on my laptop takes less than 3s!
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210
--- Comment #8 from Jakub Jelinek ---
Well, I'm not convinced the #c0 transformation should be done by default, but
what should and can be done is instead of emitting {42, 42, 42, , 42}; emit
like the C or C++ FEs emit {[1..100] = 42} which is much more compile time
memory friendly, and if the user doesn't require that it is SAVEd, e.g. the
gimplifier has code to decide if having a .rodata initializer vs. initializing
by a loop is beneficial. See PR82294 or PR87436 for the C++ counterparts.
I see a single spot with RANGE_EXPR even in the Fortran FE, so maybe it does it
already.
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210 --- Comment #9 from Jakub Jelinek --- Created attachment 45818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45818&action=edit gcc9-pr43210.patch Like this (untested so far).
[Bug target/88530] [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530 --- Comment #3 from Tamar Christina --- Author: tnfchris Date: Mon Feb 25 17:57:01 2019 New Revision: 269193 URL: https://gcc.gnu.org/viewcvs?rev=269193&root=gcc&view=rev Log: AArch64: Fix command line options canonicalization version #2. (PR target/88530) Commandline options on AArch64 don't get canonicalized into the smallest possible set before output to the assembler. This means that overlapping feature sets are emitted with superfluous parts. Normally this isn't an issue, but in the case of crypto we have retro-actively split it into aes and sha2. We need to emit only +crypto to the assembler so old assemblers continue to work. Because of how -mcpu=native and -march=native work they end up enabling all feature bits. Instead we need to get the smallest possible set, which would also fix the problem with older the assemblers and the retro-active split. The function that handles this is called quite often. It is called for any push/pop options or attribute that changes arch, cpu etc. In order to not make this search for the smallest set too expensive we sort the options based on the number of features (bits) they enable. This allows us to process the list linearly instead of quadratically (Once we have enabled a feature, we know that anything else that enables it can be ignored. By sorting we'll get the biggest groups first and thus the smallest combination of commandline flags). The Option handling structures have been extended to have a boolean to indicate whether the option is synthetic, with that I mean if the option flag itself enables a new feature. e.g. +crypto isn't an actual feature, it just enables other features, but others like +rdma enable multiple dependent features but is itself also a feature. There are two ways to solve this. 1) Either have the options that are feature bits also turn themselves on, e.g. change rdma to turn on FP, SIMD and RDMA as dependency bits. 2) Make a distinction between these two different type of features and have the framework handle it correctly. Even though it's more code I went for the second approach, as it's the one that'll be less fragile (people can't forget it) and gives the least surprises. Effectively this patch changes the following: The values before the => are the old compiler and after the => the new code. -march=armv8.2-a+crypto+sha2 => -march=armv8.2-a+crypto -march=armv8.2-a+sha2+aes => -march=armv8.2-a+crypto The remaining behaviors stay the same. gcc/ChangeLog: PR target/88530 * common/config/aarch64/aarch64-common.c (struct aarch64_option_extension): Add is_synthetic. (all_extensions): Use it. (TARGET_OPTION_INIT_STRUCT): Define hook. (struct gcc_targetm_common): Moved to end. (all_extensions_by_on): New. (opt_ext_cmp, typedef opt_ext): New. (aarch64_option_init_struct): New. (aarch64_contains_opt): New. (aarch64_get_extension_string_for_isa_flags): Output smallest set. * config/aarch64/aarch64-option-extensions.def (AARCH64_OPT_EXTENSION): Explicitly include AES and SHA2 in crypto. (fp, simd, crc, lse, fp16, rcpc, rdma, dotprod, aes, sha2, sha3, sm4, fp16fml, sve, profile, rng, memtag, sb, ssbs, predres): Set is_synthetic to false. (crypto): Set is_synthetic to true. * config/aarch64/driver-aarch64.c (AARCH64_OPT_EXTENSION): Add SYNTHETIC. gcc/testsuite/ChangeLog: PR target/88530 * gcc.target/aarch64/options_set_1.c: New test. * gcc.target/aarch64/options_set_2.c: New test. * gcc.target/aarch64/options_set_3.c: New test. * gcc.target/aarch64/options_set_4.c: New test. * gcc.target/aarch64/options_set_5.c: New test. * gcc.target/aarch64/options_set_6.c: New test. * gcc.target/aarch64/options_set_7.c: New test. * gcc.target/aarch64/options_set_8.c: New test. * gcc.target/aarch64/options_set_9.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/options_set_1.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_2.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_3.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_4.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_5.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_6.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_7.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_8.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_9.c Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/aarch64/aarch64-common.c trunk/gcc/config/aarch64/aarch64-option-extensions.def trunk/gcc/config/aarch64/driver-aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501 --- Comment #18 from Andrey Drobyshev --- (In reply to Martin Liška from comment #16) > Created attachment 45797 [details] > Patch candidate > > Patch candidate where I made some refactoring and come up with tests. > Works fine on x86_64, on ppc64le there are some issues with > -fsection-anchors, but that would be possible to resolve. > > Please let me know if you're fine with that and we can submit that to > gcc-patches ML? Looks good to me. By not setting TREE_PUBLIC flag we give our dummy globals internal linkage (as if they were static), thus allowing linker to mix multiple TUs with these dummies. However, this way number of dummy globals in the resulting executable is proportional to the number of TUs, and each of them occupies additional 64b for redzone (due to alignment) + its poisoned metadata (struct __asan_global, also 64b on x86_64). I guess that's what was meant by "wasting more memory" in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1. I'm not sure, are we ok with such a waste?
[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #19 from Andrey Drobyshev ---
(In reply to Martin Liška from comment #17)
> > 2. What should we do with sections like .data.rel.ro, .data.rel.ro.local?
> > They suffer from this bug too, but it's not that easy to put globals there,
> > as you must set various attributes onto decl to ensure it will receive the
> > right reloc value.
>
> Answer for this would be that we probably can't do that with approach #2 (as
> defined in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1). Btw. how
> can one hit an invalid memory in .data.rel.ro (or .data.rel.ro.local)?
Take a look:
$ cat data_rel_ro.c
extern int a;
int * const b = &a;
int *foo(void)
{
int **ptr = &b;
ptr--;
return *ptr;
}
$ cat main.c
int a = -1;
int *c;
extern int *foo(void);
int main(int argc, char *argv[])
{
c = foo();
return 0;
}
Now compile this thing with -fPIE (assuming we want ASLR):
$ gcc -fsanitize=address -fPIE data_rel_ro.c main.c
...and b is put to .data.rel.ro:
$ objdump -t a.out
a.out: file format elf64-x86-64
SYMBOL TABLE:
00601040 g O .data.rel.ro 0008 b
foo() hits invalid memory to the left of b, but our patched ASan doesn't detect
(as expected though):
$ ./a.out
$
However, there's still a redzone to the right, as it should be:
$ cat data_rel_ro.c
extern int a;
int * const b = &a;
int *foo(void)
{
int **ptr = &b;
ptr++;
return *ptr;
}
$ ./a.out
==32200==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00601048 at pc 0x004007d8 bp 0x7ffee53dc6a0 sp 0x7ffee53dc680
READ of size 8 at 0x00601048 thread T0
#0 0x4007d7 in foo /home/src/gcc/obj/data_rel_ro.c:8
#1 0x40082c in main /home/src/gcc/obj/main.c:8
#2 0x7f80ea98682f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#3 0x4006b8 in _start (/home/src/gcc/obj/a.out+0x4006b8)
0x00601048 is located 0 bytes to the right of global variable 'b' defined
in 'data_rel_ro.c:2:13' (0x601040) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow
/home/src/gcc/obj/data_rel_ro.c:8 in foo
Shadow bytes around the buggy address:
0x800b81b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b81c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b81d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b81e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b81f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x800b8200: 00 00 00 00 00 00 00 00 00[f9]f9 f9 f9 f9 f9 f9
0x800b8210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b8220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b8230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b8240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b8250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
So I guess we still have to detect relocations. I cannot see limitations coming
particularly from approach #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1. We just need to pass the
right reloc value to categorize_decl_for_section().
[Bug c++/70644] Warn about implicit conversion of 'this' to pointer to virtual base class during construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70644
--- Comment #2 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #0)
> (Reduced from PR 58822)
>
> struct Base { Base(int) { } };
>
> int foo(Base*) { return 0; }
>
> struct X : virtual Base {
> X() : Base(foo(this)) { }
> };
>
> int main() {
> X x;
> }
>
> The implicit conversion in the call foo(this) is undefined behaviour. It
> violates [basic.life] 3.8p6 (6.3) by converting the object's address to a
> pointer to virtual base before it is constructed.
>
> There is no warning, and no ubsan error.
>
> If the implicit conversion happens in a different scope, not inside the
> constructor, then we get a ubsan error (and segfault):
>
> struct Base { Base(int) { } };
>
> struct X;
> int foo(X*);
>
> struct X : virtual Base {
> X() : Base(foo(this)) { }
> };
>
> int foo(X* x) { Base* b = x; return 0; }
>
> int main() {
> X x;
> }
>
> vb.cc:10:27: runtime error: cast to virtual base of address 0x7ffd25ef32f0
> which does not point to an object of type 'X'
> 0x7ffd25ef32f0: note: object has invalid vptr
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 0a 40 00
> 00 00 00 00 80 65 20 63
> ^~~
> invalid vptr
> Segmentation fault (core dumped)
>
>
> Since the original example is also UB it would be good to either get a
> diagnostic from the front end at the point of the implicit conversion, or at
> least get a ubsan error..
idea for a name for the proposed new warning?
[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug lto/89497] New: [8.2 regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
Bug ID: 89497
Summary: [8.2 regression] ICE caused by Segmentation Fault when
compiling cups 2.2.10 with LTO flags enabled
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: darkkirb at darkkirb dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I have found a Regression in 8.3 involving cups 2.2.10 and LTO on Gentoo Linux
(x86_64). The package built fine with the C/LDFLAGS found below on 8.2, making
me believe it was recently introduced.
I have not yet tested this out on any recent development version.
Steps to reproduce:
1. Have the following variables set and exported:
a) CFLAGS="-march=native -O3 -fgraphite-identity -floop-nest-optimize
-fipa-pta -fno-semantic-interposition -flto=8 -fuse-linker-plugin -pipe
-falign-functions=32 -fPIC"
b) CXXFLAGS="${CFLAGS}"
c) LDFLAGS="${CFLAGS} -Wl,--hash-style=gnu"
2. untar the cups 2.2.10 release tarball and go into its directory
3. CC=gcc CXX=g++ ./configure
4. make -j$(nproc) libs
The compiler will report an ICE:
during GIMPLE pass: vrp
ppd-localize.c: In function ‘ppdLocalize’:
ppd-localize.c:51:1: internal compiler error: Segmentation fault
ppdLocalize(ppd_file_t *ppd) /* I - PPD file */
^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug lto/89497] [8.2 regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497 --- Comment #1 from darkkirb at darkkirb dot de --- (In reply to darkkirb from comment #0) > Full offending command line: > x86_64-pc-linux-gnu-gcc -m32 -L../cgi-bin -L../cups -L../filter -L../ppdc > [...] This happens for both 32 bit and 64 bit compilation, portage just built the 32 bit variant first (independent from -m32 flag)
[Bug target/89338] sse-cvtss2si-[12].c fails on PPC Big Endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89338 --- Comment #2 from pc at gcc dot gnu.org --- Author: pc Date: Mon Feb 25 19:36:05 2019 New Revision: 269195 URL: https://gcc.gnu.org/viewcvs?rev=269195&root=gcc&view=rev Log: [rs6000] PR89338, PR89339: Fix compat vector intrinsics for BE and 32-bit Test FAILS: sse2-cvtpd2dq-1, sse2-cvtpd2ps, sse2-cvttpd2dq on powerpc64 (big-endian). _mm_cvtpd_epi32, _mm_cvtpd_ps, _mm_cvttpd_epi32: Type conversion from vector doubleword type to vector word type leaves the results in even lanes in big endian mode. Test FAILS: sse-cvtss2si-1, sse-cvtss2si-2, sse-movmskb-1 on powerpc (32-bit big-endian). Incorrect type for interpreting the result from mfvsrd instruction leads to incorrect results. Also, mfvsrd instruction only works as expected in 64-bit mode or for 32-bit quantities in 32-bit mode. A more general, if slower, solution is needed for 32-bit mode. 2019-02-25 Paul A. Clarke [gcc] * config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Fix big endian. (_mm_cvtpd_ps): Likewise. (_mm_cvttpd_epi32): Likewise. PR target/89338 * config/rs6000/xmmintrin.h (_mm_cvtss_f32): Fix type mismatch. (_mm_cvt_ss2si): Fix type mismatch and 32-bit. PR target/89339 * config/rs6000/xmmintrin.h (_mm_movemask_pi8): Fix 32-bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/emmintrin.h trunk/gcc/config/rs6000/xmmintrin.h
[Bug target/89339] sse-movmskb-1.c fails for PPC Big Endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89339 --- Comment #2 from pc at gcc dot gnu.org --- Author: pc Date: Mon Feb 25 19:36:05 2019 New Revision: 269195 URL: https://gcc.gnu.org/viewcvs?rev=269195&root=gcc&view=rev Log: [rs6000] PR89338, PR89339: Fix compat vector intrinsics for BE and 32-bit Test FAILS: sse2-cvtpd2dq-1, sse2-cvtpd2ps, sse2-cvttpd2dq on powerpc64 (big-endian). _mm_cvtpd_epi32, _mm_cvtpd_ps, _mm_cvttpd_epi32: Type conversion from vector doubleword type to vector word type leaves the results in even lanes in big endian mode. Test FAILS: sse-cvtss2si-1, sse-cvtss2si-2, sse-movmskb-1 on powerpc (32-bit big-endian). Incorrect type for interpreting the result from mfvsrd instruction leads to incorrect results. Also, mfvsrd instruction only works as expected in 64-bit mode or for 32-bit quantities in 32-bit mode. A more general, if slower, solution is needed for 32-bit mode. 2019-02-25 Paul A. Clarke [gcc] * config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Fix big endian. (_mm_cvtpd_ps): Likewise. (_mm_cvttpd_epi32): Likewise. PR target/89338 * config/rs6000/xmmintrin.h (_mm_cvtss_f32): Fix type mismatch. (_mm_cvt_ss2si): Fix type mismatch and 32-bit. PR target/89339 * config/rs6000/xmmintrin.h (_mm_movemask_pi8): Fix 32-bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/emmintrin.h trunk/gcc/config/rs6000/xmmintrin.h
[Bug target/89338] sse-cvtss2si-[12].c fails on PPC Big Endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89338 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from pc at gcc dot gnu.org --- fixes committed
[Bug target/89339] sse-movmskb-1.c fails for PPC Big Endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89339 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from pc at gcc dot gnu.org --- fixes committed
[Bug c++/67650] undef reference with -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67650 --- Comment #33 from Vincent --- Still in gcc 8.3.0.
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #1 from Harald Anlauf ---
Potential patch:
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 269177)
+++ gcc/fortran/check.c (working copy)
@@ -5487,6 +5487,13 @@
if (!gfc_element_size (mold, &result_elt_size))
return false;
+ if (result_elt_size == 0 && *source_size > 0)
+{
+ gfc_error ("% argument of % intrinsic at %L "
+ "has storage size 0", &mold->where);
+ return false;
+}
+
if ((result_elt_size > 0 && (mold->expr_type == EXPR_ARRAY || mold->rank))
|| size)
{
Can you please verify that your testcases work?
[Bug c/89498] New: [8/9 Regression] ICE in AT_loc_list, at dwarf2out.c:4871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498
Bug ID: 89498
Summary: [8/9 Regression] ICE in AT_loc_list, at
dwarf2out.c:4871
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects several testsuite cases at -O1+.
Changed between 2018 and 20181118 :
$ cat pr71078-2.c
#include
float f1(float x)
{
float t1 = fabsf (x);
float t2 = t1 / x;
return t2;
}
$ gcc-9-2018 -c pr71078-2.c -O2 -gdwarf-5 -gsplit-dwarf
$
$ gcc-9-20190224 -c pr71078-2.c -O0 -gdwarf-5 -gsplit-dwarf
$
$ gcc-9-20190224 -c pr71078-2.c -O2 -gdwarf-5 -gsplit-dwarf
pr71078-2.c:8:1: internal compiler error: in AT_loc_list, at dwarf2out.c:4871
8 | }
| ^
0x755b87 AT_loc_list
../../gcc/dwarf2out.c:4871
0x76c693 AT_loc_list
../../gcc/dwarf2out.c:9874
0x76c693 value_format
../../gcc/dwarf2out.c:9735
0x76c84c build_abbrev_table
../../gcc/dwarf2out.c:9094
0x76c9d8 build_abbrev_table
../../gcc/dwarf2out.c:9117
0x76c9d8 build_abbrev_table
../../gcc/dwarf2out.c:9117
0x77060f output_comp_unit
../../gcc/dwarf2out.c:11034
0x797441 dwarf2out_finish
../../gcc/dwarf2out.c:31569
[Bug c/89499] New: [7/8/9 Regression] ICE in expand_UNIQUE, at internal-fn.c:2605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89499
Bug ID: 89499
Summary: [7/8/9 Regression] ICE in expand_UNIQUE, at
internal-fn.c:2605
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-6 at -O[23] :
$ cat z1.c
#pragma acc routine vector
void Vector (int *ptr, int n, const int inc)
{
#pragma acc loop vector
for (int i = 0; i < n; i++)
ptr[i] += inc;
return;
}
void foo (void)
{
const int m = 16;
int ary[m][m];
Vector (&ary[0][0], m*m, (1 << 24) - (1 << 16));
return;
}
$ gcc-9-20190224 -c z1.c -fopenacc -O0
$ gcc-9-20190224 -c z1.c -fopenacc -O1
$
$ gcc-9-20190224 -c z1.c -fopenacc -O2
during RTL pass: expand
z1.c: In function 'foo':
z1.c:4:11: internal compiler error: in expand_UNIQUE, at internal-fn.c:2605
4 | #pragma acc loop vector
| ^~~
0x8a133f expand_UNIQUE
../../gcc/internal-fn.c:2605
0x6d3a57 expand_call_stmt
../../gcc/cfgexpand.c:2633
0x6d3a57 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3691
0x6d3a57 expand_gimple_stmt
../../gcc/cfgexpand.c:3850
0x6d5a57 expand_gimple_basic_block
../../gcc/cfgexpand.c:5886
0x6db096 execute
../../gcc/cfgexpand.c:6509
[Bug c/89500] New: [9 Regression] ICE: tree check: expected integer_cst, have ssa_name in get_len, at tree.h:5653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89500
Bug ID: 89500
Summary: [9 Regression] ICE: tree check: expected integer_cst,
have ssa_name in get_len, at tree.h:5653
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-9 at -O[23] :
$ cat z1.c
extern __SIZE_TYPE__ strlen (const char*);
extern __SIZE_TYPE__ strnlen (const char*, __SIZE_TYPE__);
void foo (int *a)
{
char c[0];
a[0] = strlen (c);
a[0] = strnlen (c, 0);
}
$ gcc-9-20190224 -c z1.c -O1
$
$ gcc-9-20190224 -c z1.c -O2
during GIMPLE pass: strlen
z1.c: In function 'foo':
z1.c:3:6: internal compiler error: tree check: expected integer_cst, have
ssa_name in get_len, at tree.h:5653
3 | void foo (int *a)
| ^~~
0x5cf414 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9848
0xc517a7 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3432
0xc517a7 wi::extended_tree<192>::get_len() const
../../gcc/tree.h:5653
0xc517a7 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:964
0xc517a7 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:1013
0xc517a7 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:788
0xc517a7 bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:1880
0xe1a9ae wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
>,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:3227
0xe1a9ae tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc/tree.h:5809
0xe1a9ae handle_builtin_strlen
../../gcc/tree-ssa-strlen.c:1305
0xe1cf63 strlen_check_and_optimize_stmt
../../gcc/tree-ssa-strlen.c:3574
0xe1cf63 strlen_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-strlen.c:3927
0x1483d67 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xe16c97 execute
../../gcc/tree-ssa-strlen.c:4007
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 --- Comment #2 from Dominique d'Humieres --- > Can you please verify that your testcases work? With the patch I get pr34202_red.f90:8:54: 8 |write(*,*) transfer(transfer([1],[bug4()]),[1],size[1]) | 1 Error: Function 'size' requires an argument list at (1) pr34202_red.f90:7:30: 7 |write(*,*) size(transfer(1,[''])) | 1 Error: 'MOLD' argument of 'TRANSFER' intrinsic at (1) has storage size 0 Full test in progress. Thanks for the quick answer.
[Bug c++/71446] Incorrect overload resolution when using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #5 from Harald van Dijk ---
(In reply to Jakub Jelinek from comment #3)
> Well, before C++2a it is an extension, so outside of the C++ standard, and
> GCC has been implementing it as not allowing to skip any fields.
Not exactly. Outside of overload resolution, GCC does implement it as allowing
skipping of fields. Test case:
struct S {
int a, b;
bool equals(S other) const { return a == other.a && b == other.b; }
} s = {.a = 0, .b = 1};
int main() { return !s.equals({.b = 1}); }
This program should and does return 0, showing that {.b = 1} initialises the
second field, not the first.
