[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 Segher Boessenkool changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #12 from Segher Boessenkool --- Please revert this on 7 and 8 for now, and we'll fix this on trunk? Or revert it on trunk as well, if it is in the way. Thanks!
[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 --- Comment #13 from Iain Sandoe --- (In reply to Joseph S. Myers from comment #11) > This change results in miscompilation of glibc for 32-bit soft-float powerpc > (symptoms: many libm tests as run by "make regen-ulps" either segfault, or > produce spurious errors that don't occur with compilers without this change, > or in the case of tests for float fail the "Value outside of 100 +/- 1ulp." > internal sanity check). > > Specifically, on GCC 7 branch r267476 works OK but the tip of the branch, > which has no subsequent changes other than this patch and changes to > DATESTAMP, miscompiles glibc. On GCC 8 branch r267386 (the revision before > this change) works and tip of the branch miscompiles glibc (but I haven't > bisected there to confirm it is indeed this change that's responsible). > Trunk also miscompiles glibc (I haven't tried previous revisions there). Unfortunately, there doesn't appear to be anything in the GCC test suite that catches this (all languages reg-strap was clean, on gcc110). Does it show for a 32b multilib on a 64b host, or only with a 32b host? (if you have a specific reproducer that would be most welcome).
[Bug fortran/88669] New: Contiguous attribute wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669 Bug ID: 88669 Summary: Contiguous attribute wrongly rejected Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The code below gives the following error contiguous_pointer.f90:7:51: class(t), dimension(:), contiguous, pointer :: x 1 Error: Component ‘x’ at (1) has the CONTIGUOUS attribute but is not an array pointer With type(t) instead of class(t) , the error does not occur. program contiguous_pointer type t end type t type s class(t), dimension(:), contiguous, pointer :: x end type s end program contiguous_pointer
[Bug tree-optimization/88599] ICE in make_decl_rtl, at varasm.c:1337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88599 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-03 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I also can't reproduce that with x86_64-linux-gnu cross compiler configured with: Configured with: ../configure --enable-languages=c,c++ --disable-multilib --prefix=/home/marxin/bin/gcc2 --disable-bootstrap --disable-libsanitizer --target=powerpc-linux-gnu --with-as=/usr/bin/powerpc-suse-linux-as $ ./xgcc -B. ~/Programming/testcases/pr88599.c -c -msoft-float -mcpu=e300c3 All is fine.
[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 --- Comment #14 from Iain Sandoe --- Author: iains Date: Thu Jan 3 08:34:41 2019 New Revision: 267542 URL: https://gcc.gnu.org/viewcvs?rev=267542&root=gcc&view=rev Log: revert fix for pr88343 causes problems with soft-fp in GLIBC, see pr comment 11 2019-01-03 Iain Sandoe revert: 2018-12-30 Iain Sandoe backport from mainline. 2018-12-12 Segher Boessenkool Iain Sandoe PR target/88343 * config/rs6000/rs6000.c (save_reg_p): Do not save the picbase reg unless it has been used. (first_reg_to_save): Remove dead code. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #8 from Martin Liška --- (In reply to David Malcolm from comment #7) > I've been trying to reproduce this, but failing - I tried with today's > trunk, and with a build from 2018-11-16. > > Do you have a revision that is known to trigger the ICE? Started with r265875 and is gone with r266395 where Honza removed sorting of ODR types during LTO streaming in. Maybe one can't use expand_location before all stuff is read in LTO stream in?
[Bug middle-end/80362] [5 Regression] gcc miscompiles arithmetic with signed char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80362 --- Comment #10 from Richard Biener --- (In reply to Alexandre Oliva from comment #9) > I see the same issue of using arg vs op is present in the reciprocal tests > right below the patched ones. AFAICT it is not possible to trigger the > problem in a way that affects the outcome, but... is there any good reason > to keep them different and have people puzzle over the difference? I think > it was not the first time that difference caught my attention and got me > distracted trying to reason it out. Feel free to patch it.
[Bug tree-optimization/88666] GCC 8.2.- gets Internal Compiler Error: seg fault; GCC 8.1.0 works fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88666 Richard Biener changed: What|Removed |Added Keywords||needs-bisection CC||marxin at gcc dot gnu.org Known to work||8.1.0, 8.2.1 Version|unknown |8.2.0 Known to fail||8.2.0 --- Comment #2 from Richard Biener --- Confirmed with GCC 8.2.0, I can't reproduce it on the branch head so I assume it was fixed (and there was likely a duplicate report). Martin, can you bisect the fix?
[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 --- Comment #15 from Iain Sandoe --- Author: iains Date: Thu Jan 3 08:45:35 2019 New Revision: 267543 URL: https://gcc.gnu.org/viewcvs?rev=267543&root=gcc&view=rev Log: revert fix for pr88343 This causes problems for soft-f on GLIBC, see pr comment 11. 2019-01-03 Iain Sandoe revert: 2018-12-23 Iain Sandoe backport from mainline. 2018-12-12 Segher Boessenkool Iain Sandoe PR target/88343 * config/rs6000/rs6000.c (save_reg_p): Do not save the picbase reg unless it has been used. (first_reg_to_save): Remove dead code. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
[Bug c/88568] [8/9 Regression] 'dllimport' no longer implies 'extern' in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |8.3
[Bug target/88570] Missing or ineffective vectorization of scatter load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88570 Richard Biener changed: What|Removed |Added Blocks||53947 --- Comment #4 from Richard Biener --- It's probbaly a dependence issue again. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug ipa/88561] [8/9 Regression] PGO devirtualization miscompilation of firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88561 --- Comment #6 from Martin Liška --- Author: marxin Date: Thu Jan 3 08:49:04 2019 New Revision: 267546 URL: https://gcc.gnu.org/viewcvs?rev=267546&root=gcc&view=rev Log: Backport r267507 2019-01-03 Martin Liska Backport from mainline 2019-01-02 Jakub Jelinek PR ipa/88561 * g++.dg/tree-prof/devirt.C: Expect _ZThn16 only for lp64 and llp64 targets and expect _ZThn8 for ilp32 targets. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-prof/devirt.C
[Bug middle-end/88273] [8/9 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
Martin Liška changed:
What|Removed |Added
Target||powerpc-*-linux-gnu
Status|UNCONFIRMED |NEW
Keywords||needs-bisection
Last reconfirmed||2019-01-03
CC||marxin at gcc dot gnu.org
Host||x86_64-pc-linux-gnu
Ever confirmed|0 |1
Known to fail||9.0
--- Comment #9 from Martin Liška ---
Slightly cleaned up test-case:
$ cat /home/marxin/Programming/testcases/pr88273-2.c
typedef struct {
int b[4];
} c;
void* d;
unsigned e;
inline int h(void *i, int p2, int j) {
if (j < 0 || e < j) {
int copy = j - e;
i += e - p2;
__builtin_memcpy(d, i, copy);
e = copy;
}
}
void a() {
int g = h(&g, 0, sizeof(c));
c vrsave;
h(&vrsave, 33 * sizeof(c), -1);
}
So the warning is triggered for the cross compiler from here:
$ Breakpoint 5, warning_at (location=location@entry=2147483704,
opt=opt@entry=171, gmsgid=gmsgid@entry=0x15a3448 "%G%qD offset %s is out of the
bounds [0, %wu] of object %qD with type %qT") at ../../gcc/diagnostic.c:1289
1289{
(gdb) bt
#0 warning_at (location=location@entry=2147483704, opt=opt@entry=171,
gmsgid=gmsgid@entry=0x15a3448 "%G%qD offset %s is out of the bounds [0, %wu] of
object %qD with type %qT") at ../../gcc/diagnostic.c:1289
#1 0x00a39dc3 in (anonymous namespace)::maybe_diag_offset_bounds
(loc=2147483704, call=, func=, strict=, expr=,
ref=...) at ../../gcc/wide-int.h:831
#2 0x00a3a9d9 in (anonymous namespace)::maybe_diag_offset_bounds
(ref=..., expr=, strict=0, func=,
call=, loc=2147483704) at
../../gcc/gimple-ssa-warn-restrict.c:1586
#3 check_bounds_or_overlap (call=, dst=, src=, dstsize=,
srcsize=, bounds_only=) at
../../gcc/gimple-ssa-warn-restrict.c:1851
#4 0x00a3c718 in (anonymous
namespace)::wrestrict_dom_walker::check_call (this=,
call=) at ../../gcc/gimple-ssa-warn-restrict.c:1814
#5 (anonymous namespace)::wrestrict_dom_walker::before_dom_children
(this=, bb=) at
../../gcc/gimple-ssa-warn-restrict.c:105
#6 0x013256d8 in dom_walker::walk (this=this@entry=0x7fffd720,
bb=) at ../../gcc/domwalk.c:373
#7 0x00a31c38 in (anonymous namespace)::pass_wrestrict::execute
(this=, fun=0x76b360b0) at
../../gcc/gimple-ssa-warn-restrict.c:119
#8 0x00be2885 in execute_one_pass (pass=) at ../../gcc/passes.c:2483
#9 0x00be3008 in execute_pass_list_1 (pass=) at ../../gcc/passes.c:2569
#10 0x00be301a in execute_pass_list_1 (pass=) at ../../gcc/passes.c:2570
#11 0x00be3059 in execute_pass_list (fn=0x76b360b0, pass=) at ../../gcc/passes.c:2580
#12 0x008cd5cb in cgraph_node::expand (this=) at ../../gcc/context.h:48
#13 0x008ce5a4 in expand_all_functions () at
../../gcc/cgraphunit.c:2334
#14 symbol_table::compile (this=0x76991000) at ../../gcc/cgraphunit.c:2685
#15 0x008d0bed in symbol_table::compile (this=0x76991000) at
../../gcc/cgraphunit.c:2863
#16 symbol_table::finalize_compilation_unit (this=0x76991000) at
../../gcc/cgraphunit.c:2863
#17 0x00cb9b4b in compile_file () at ../../gcc/toplev.c:481
#18 0x007522c4 in do_compile () at ../../gcc/toplev.c:2176
#19 toplev::main (this=this@entry=0x7fffd93e, argc=,
argc@entry=23, argv=, argv@entry=0x7fffda38) at
../../gcc/toplev.c:2311
#20 0x007545db in main (argc=23, argv=0x7fffda38) at
../../gcc/main.c:39
For the following gimple IL:
$ (gdb) p debug_gimple_stmt(call)
No symbol "call" in current context.
(gdb) p debug_function(cfun->decl,0)
a ()
{
void * i;
void * i;
int D.2622;
struct c vrsave;
int g;
unsigned int e.0_5;
void * pretmp_10;
unsigned int _12;
unsigned int prephitmp_13;
void * pretmp_14;
void * prephitmp_17;
unsigned int _19;
unsigned int _21;
[local count: 1073741824]:
e.0_5 = e;
pretmp_10 = d;
if (e.0_5 <= 15)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_12 = 16 - e.0_5;
i_15 = &g + e.0_5;
__builtin_memcpy (pretmp_10, i_15, _12);
e = _12;
pretmp_14 = d;
[local count: 1073741824]:
# prephitmp_13 = PHI <_12(3), e.0_5(2)>
# prephitmp_17 = PHI
_19 = ~prephitmp_13;
_21 = prephitmp_13 + 4294966768;
i_22 = &vrsave + _21;
__builtin_memcpy (prephitmp_17, i_22, _19);
e = _19;
g ={v} {CLOBBER};
vrsave ={v} {CLOBBER};
return;
}
I can confirm the warning is false, because the problematic __builtin_memcpy
for which we trigger the warning:
__builtin_memcpy (prephitmp_17, i_22, _19);
and complains about i_22, but this one should be fine (with a reasonable
initial value of global variable 'e').
Martin: can you please ta
[Bug debug/88644] [7/8/9 Regression] Unexpected pub type info eliminated after r246973 (causes pubtypes-*.c to regress).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88644 --- Comment #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > will do a complete test suite run now, to catch any other changed lengths. I don't see any other related changes.
[Bug tree-optimization/88666] GCC 8.2.- gets Internal Compiler Error: seg fault; GCC 8.1.0 works fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88666 --- Comment #3 from Martin Liška --- (In reply to Richard Biener from comment #2) > Confirmed with GCC 8.2.0, I can't reproduce it on the branch head so I > assume it was fixed (and there was likely a duplicate report). Martin, can > you bisect the fix? Doing that.
[Bug middle-end/87099] [8 Regression] internal compiler error: segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87099 Martin Liška changed: What|Removed |Added CC||geir at cray dot com --- Comment #7 from Martin Liška --- *** Bug 88666 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/88666] GCC 8.2.- gets Internal Compiler Error: seg fault; GCC 8.1.0 works fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88666 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 87099 ***
[Bug target/88331] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
Rainer Emrich changed:
What|Removed |Added
CC||rai...@emrich-ebersheim.de
--- Comment #6 from Rainer Emrich ---
The issue is now shown during bootstrap while building libfortran.
libtool: compile:
/opt/devel/SCRATCH/tmp.Q1UXSYzwJg/gcc-9.0.0/gcc-9.0.0/./gcc/xgcc
-B/opt/devel/SCRATCH/tmp.Q1UXSYzwJg/gcc-9.0.0/gcc-9.0.0/./gcc/
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0/x86_64-w64-mingw32/lib
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0/mingw/lib
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0/x86_64-w64-mingw32/include
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0/mingw/include
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0/x86_64-w64-mingw32/bin/
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0/x86_64-w64-mingw32/lib/
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0/x86_64-w64-mingw32/include
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0/x86_64-w64-mingw32/sys-include
-fchecking=1 -DHAVE_CONFIG_H -I.
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran
-iquote../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/io
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/../gcc
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/../gcc/config
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/../libquadmath
-I../.././gcc
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/../libgcc
-I../libgcc
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/../libbacktrace
-I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -ffast-math -ftree-vectorize -funroll-loops
--param max-unroll-times=4 -g -O2 -MT matmul_i4.lo -MD -MP -MF
.deps/matmul_i4.Tpo -c
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/generated/matmul_i4.c
-DDLL_EXPORT -DPIC -o .libs/matmul_i4.o
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/generated/matmul_i4.c:
In function 'matmul_i4_avx2':
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/generated/matmul_i4.c:1210:1:
error: insn outside basic block
1210 | }
| ^
(insn 10248 8120 10249 (parallel [
(set (reg:DI 5750)
(plus:DI (reg/f:DI 19 frame)
(const_int -1200 [0xfb50])))
(clobber (reg:CC 17 flags))
]) 191 {*adddi_1}
(nil))
during RTL pass: reload
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/generated/matmul_i4.c:1210:1:
internal compiler error: in rtl_verify_bb_layout, at cfgrtl.c:2987
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/88592] Passing of packed structures on sparc64 different than in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88592 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-03 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Here's the historical comment in the GCC codebase: /* The ABI obviously doesn't specify how packed structures are passed. These are passed in integer regs if possible, otherwise memory. */
[Bug rtl-optimization/88563] [7/8/9 Regression] wrong code with -O2 -fno-code-hoisting -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-fre -fno-tree-pre -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88563 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- Jakub: Is it fixed on trunk? Can you please adjust title and known-to-fail?
[Bug target/88592] Passing of packed structures on sparc64 different than in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88592 Eric Botcazou changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #2 from Eric Botcazou --- No action required.
[Bug ipa/87554] [8/9 Regression] internal compiler error: in record_reference, at cgraphbuild.c:64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87554 --- Comment #6 from Martin Liška --- With first bad revision the constructor looks as follows: $ (gdb) p print_generic_expr(stderr, decl->decl_common.initial, 0) instance = b::create ()$1 = void (gdb) p debug_tree(decl->decl_common.initial) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76cb5f18 fields context full-name "struct k" X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this reference_to_this chain > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76cbe540> side-effects arg:0 readonly used public static tree_1 tree_3 unsigned external nonlocal read decl_3 decl_5 DI /home/marxin/Programming/testcases/pr87554.ii:11:25 size unit-size align:64 warn_if_not_align:0 context initial template-info 0x76ca6f20 chain external nonlocal suppress-debug decl_4 VOID /home/marxin/Programming/testcases/pr87554.ii:1:30 align:8 warn_if_not_align:0 context result >> arg:1 side-effects fn constant arg:0 > /home/marxin/Programming/testcases/pr87554.ii:11:50 start: /home/marxin/Programming/testcases/pr87554.ii:11:44 finish: /home/marxin/Programming/testcases/pr87554.ii:11:51>> before that C++ FE reported following error: $ ./xgcc -B. ~/Programming/testcases/pr87554.ii -c -O2 /home/marxin/Programming/testcases/pr87554.ii: In instantiation of ‘k& b::instance’: /home/marxin/Programming/testcases/pr87554.ii:3:26: required from ‘static a& b::create() [with a = k]’ /home/marxin/Programming/testcases/pr87554.ii:8:24: required from ‘static a b::d() [with a = k]’ /home/marxin/Programming/testcases/pr87554.ii:26:55: required from ‘void p(m, a) [with m = e*; a = int]’ /home/marxin/Programming/testcases/pr87554.ii:16:39: required from ‘void f::h(a) [with a = int]’ /home/marxin/Programming/testcases/pr87554.ii:15:31: required from here /home/marxin/Programming/testcases/pr87554.ii:11:50: error: call to non-‘constexpr’ function ‘static a& b::create() [with a = k]’ template < class a > a &b< a >::instance = create(); ~~^~ Jason can you please take a look?
[Bug target/88331] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331 --- Comment #7 from Rainer Emrich --- If I call make within the libgfortran directory I get a slightly different error message: during RTL pass: postreload ../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/generated/matmul_i4.c: In function 'matmul_i4_avx2': ../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0/libgfortran/generated/matmul_i4.c:1210:1: internal compiler error: in reload_combine_note_use, at postreload.c:1547 1210 | } | ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate.
[Bug ada/88610] ICE with new ACATS test c452003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88610 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-03 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- There is probably little value in filling PRs against new ACATS tests though.
[Bug target/88331] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331 --- Comment #8 from Rainer Emrich --- Created attachment 45323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45323&action=edit preprocessed source I attached the preprocessed source.
[Bug c++/88636] [9 Regression] ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88636 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Thu Jan 3 10:11:40 2019 New Revision: 267548 URL: https://gcc.gnu.org/viewcvs?rev=267548&root=gcc&view=rev Log: PR c++/88636 * decl.c (builtin_function_1): Return result of pushdecl_top_level or pushdecl rather than decl. * g++.target/i386/pr88636.C: New test. Added: trunk/gcc/testsuite/g++.target/i386/pr88636.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/83651] [7/8/9 regression] 20% slowdown of linux kernel AES cipher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 --- Comment #18 from Martin Liška --- This is what I see on my model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz: gcc-bisect.py bisect 'gcc -O2 aes_generic.c && /usr/bin/time -f '%E' ./a.out' -o Releases 4.8.0 (e9c762ec4671d77e)(22 Mar 2013 10:05): [took: 6.368s] result: OK 0:03.28 4.8.1 (caa62b4636bfed71)(31 May 2013 09:02): [took: 5.318s] result: OK 0:03.40 4.8.2 (9bcca88e24e64d4e)(16 Oct 2013 07:20): [took: 5.344s] result: OK 0:03.43 4.8.3 (6bbf0dec66c0e719)(22 May 2014 09:10): [took: 5.352s] result: OK 0:03.40 4.8.4 (1a97fa0bb3fa5669)(19 Dec 2014 11:43): [took: 5.283s] result: OK 0:03.39 4.8.5 (cf82a597b0d18985)(23 Jun 2015 07:54): [took: 5.431s] result: OK 0:03.45 4.9.0 (a7aa383874520cd5)(22 Apr 2014 09:43): [took: 5.469s] result: OK 0:03.39 4.9.1 (c6fa1b4126635939)(16 Jul 2014 10:04): [took: 5.500s] result: OK 0:03.39 4.9.2 (c1283af40b65f1ad)(30 Oct 2014 08:27): [took: 5.536s] result: OK 0:03.45 4.9.3 (876d41ed80ce13e0)(26 Jun 2015 17:57): [took: 5.499s] result: OK 0:03.39 4.9.4 (d3191480f376c780)(03 Aug 2016 05:07): [took: 5.444s] result: OK 0:03.38 5.1.0 (d5ad84b309d0d97d)(22 Apr 2015 08:43): [took: 5.770s] result: OK 0:03.37 5.2.0 (7b26e3896e268cd4)(16 Jul 2015 09:13): [took: 5.798s] result: OK 0:03.38 5.3.0 (2bc376d60753a58b)(04 Dec 2015 10:45): [took: 5.789s] result: OK 0:03.37 5.4.0 (9d0507742960aa9f)(03 Jun 2016 08:41): [took: 5.795s] result: OK 0:03.38 5.5.0 (ba9cddfdab8b539b)(10 Oct 2017 08:11): [took: 5.824s] result: OK 0:03.39 6.1.0 (c441d9e8e0438dcf)(27 Apr 2016 08:20): [took: 5.673s] result: OK 0:03.18 6.2.0 (6ac74a62ba725829)(22 Aug 2016 08:01): [took: 5.660s] result: OK 0:03.18 6.3.0 (4b5e15daff8b5444)(21 Dec 2016 07:51): [took: 5.665s] result: OK 0:03.18 6.4.0 (45dd06cef49fe00a)(04 Jul 2017 07:22): [took: 5.832s] result: OK 0:03.18 6.5.0 (e4c9bd2bb2324c32)(26 Oct 2018 09:54): [took: 5.724s] result: OK 0:03.18 7.1.0 (f9105a38249fb57f)(02 May 2017 12:42): [took: 6.186s] result: OK 0:03.34 7.2.0 (1bd23ca8c30f4827)(14 Aug 2017 07:59): [took: 6.149s] result: OK 0:03.33 7.3.0 (87fb575328cc5d95)(25 Jan 2018 08:17): [took: 6.350s] result: OK 0:03.53 8.1.0 (af8bbdf198a7cd61)(02 May 2018 08:13): [took: 6.293s] result: OK 0:03.26 8.2.0 (9fb89fa845c1b2e0)(26 Jul 2018 09:47): [took: 6.165s] result: OK 0:03.26 known-to-work: 4.8.5, 4.9.4, 5.5.0, 6.5.0, 7.3.0, 8.2.0 known-to-fail: Active branches 6 (f2b648ddec0a9552)(07 Nov 2018 20:52): [took: 5.662s] result: OK 0:03.19 7 (2d21868dbe6a8be0)(02 Jan 2019 00:16): [took: 6.220s] result: OK 0:03.50 8 (687f6e70d3fd0eac)(02 Jan 2019 00:16): [took: 6.226s] result: OK 0:03.26 Active branch bases 4.8-base (daf81a9011692e3e)(16 Mar 2013 02:48): [took: 5.279s] result: OK 0:03.42 4.9-base (ec86f0be138e2f97)(11 Apr 2014 12:47): [took: 5.383s] result: OK 0:03.38 5-base (905be4e64f0f9136)(12 Apr 2015 19:30): [took: 5.669s] result: OK 0:03.37 6-base (a050099a416f013b)(15 Apr 2016 14:51): [took: 5.671s] result: OK 0:03.19 7-base (7369309777f6d6e6)(20 Apr 2017 09:44): [took: 6.165s] result: OK 0:03.33 8-base (941fafa56b52ee23)(25 Apr 2018 07:10): [took: 6.299s] result: OK 0:03.26 Bisecting latest revisions 553d41a8a57496a6(02 Jan 2019 16:30): [took: 6.285s] result: OK 0:03.24 acafca510c97652f(09 Oct 2014 07:40): [took: 5.520s] result: OK 0:03.38 As mentioned in the previous comment, Richi: can we adjust title and known-to-work as you're installed patch a year ago?
[Bug c++/88636] [9 Regression] ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88636 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed.
[Bug middle-end/88273] [8/9 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Known to fail||8.2.0 --- Comment #10 from Martin Liška --- Started with r255755.
[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87880 --- Comment #9 from Iain Sandoe --- So.. this is somewhat puzzling. Essentially, it seems that on macOS and Linux (at least) currently ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION is set unconditionally to "on" (for any target that has ASAN_HAS_EXCEPTIONS). libsupc++'s implementation doesn't include this, so .. .. the mystery is not so much why it's failing sometimes on macOS - so much as why it's not failing always, when the c++ library is libstdc++ (and also on Linux). Hypothesis, could be that since the search is being carried out in the flat namespace, any library that happens to pull in libc++ (as a dependent) will cause the libc++abi version of __cxa_rethrow_primary_exception to become visible in that flat namespace. using the following hack the results go from wholesale fail on C to a handfull of fails and on c++ similarly. I guess this could be a dyld bug too - if the lookup is supposed to be a weak reference (not checked). .. obviously, this is incomplete .. it just jams the hook off (not looked at the configuration stuff yet, or whether there's a weak symbol problem). [this appears distinct from failure mode on Darwin10 and also distinct from some fails caused by missing symbolization (atos) on m64 / darwin14] diff --git a/libsanitizer/asan/asan_interceptors.h b/libsanitizer/asan/asan_interceptors.h index b599ebb..10b6d2c 100644 --- a/libsanitizer/asan/asan_interceptors.h +++ b/libsanitizer/asan/asan_interceptors.h @@ -79,7 +79,11 @@ void InitializePlatformInterceptors(); #if ASAN_HAS_EXCEPTIONS && !SANITIZER_WINDOWS && !SANITIZER_SOLARIS && \ !SANITIZER_NETBSD # define ASAN_INTERCEPT___CXA_THROW 1 -# define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1 +# if ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION +# define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1 +#else +# define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 0 +# endif # if defined(_GLIBCXX_SJLJ_EXCEPTIONS) || (SANITIZER_IOS && defined(__arm__)) # define ASAN_INTERCEPT__UNWIND_SJLJ_RAISEEXCEPTION 1 # else
[Bug fortran/48543] Collapse identical strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48543 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #5 from Tamar Christina --- Hi, The testcase seems to fail on aarch64-none-linux-gnu and arm-none-linux-gnueabihf. with gfortran.dg/const_chararacter_merge.f90 -O : Supercalifragilis found 2 times
[Bug debug/88644] [7/8/9 Regression] Unexpected pub type info eliminated after r246973 (causes pubtypes-*.c to regress).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88644 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Jan 3 11:05:24 2019 New Revision: 267550 URL: https://gcc.gnu.org/viewcvs?rev=267550&root=gcc&view=rev Log: PR debug/88644 * dwarf2out.c (modified_type_die): If type is equal to sizetype, change it to qualified_type. * gcc.dg/debug/dwarf2/pr88644.c: New test. * gcc.dg/debug/dwarf2/pr80263.c: Remove darwin hack. 2019-01-03 Iain Sandoe * gcc.dg/pubtypes-2.c: Adjust expected pubtypes length. * gcc.dg/pubtypes-3.c: Likewise. * gcc.dg/pubtypes-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr88644.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr80263.c trunk/gcc/testsuite/gcc.dg/pubtypes-2.c trunk/gcc/testsuite/gcc.dg/pubtypes-3.c trunk/gcc/testsuite/gcc.dg/pubtypes-4.c
[Bug fortran/88669] Contiguous attribute wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (9.0).
[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535 --- Comment #16 from Rainer Orth --- Author: ro Date: Thu Jan 3 11:28:27 2019 New Revision: 267551 URL: https://gcc.gnu.org/viewcvs?rev=267551&root=gcc&view=rev Log: Update config.guess, config.sub (PR target/88535) PR target/88535 * config.guess: Import upstream version 2019-01-03. * config.sub: Import upstream version 2019-01-01. Modified: trunk/ChangeLog trunk/config.guess (contents, props changed) trunk/config.sub (contents, props changed)
[Bug fortran/48543] Collapse identical strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48543 Dominique d'Humieres changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Dominique d'Humieres --- See https://gcc.gnu.org/ml/fortran/2019-01/msg00010.html.
[Bug tree-optimization/83651] [7/8/9 regression] 20% slowdown of linux kernel AES cipher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 --- Comment #19 from Richard Biener --- Not sure what you are talking about - your numbers confirm the regression is still present? Or do you mean that GCC 7.1.0 is also bad and only 6.x was OK (which didn't have code hoisting?)
[Bug middle-end/88670] New: [meta-bug] generic vector extension issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Bug ID: 88670 Summary: [meta-bug] generic vector extension issues Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: ---
[Bug middle-end/88670] [meta-bug] generic vector extension issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-03 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- For both user-facing interface and optimization issues when using the extension.
[Bug tree-optimization/83651] [7/8/9 regression] 20% slowdown of linux kernel AES cipher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 --- Comment #20 from Martin Liška --- (In reply to Richard Biener from comment #19) > Not sure what you are talking about - your numbers confirm the regression is > still present? Or do you mean that GCC 7.1.0 is also bad and only 6.x was OK > (which didn't have code hoisting?) My numbers show that I can't see any regression/improvement on my machine. And I'm talking about r251376.
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939
Richard Biener changed:
What|Removed |Added
CC||segher at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #8 from Richard Biener ---
On trunk we get with -Ofast -msse4.2
.L3:
movupd (%rdx,%rax), %xmm0
movupd (%rdx,%rax), %xmm1
movupd (%rcx,%rax), %xmm4
mulpd %xmm3, %xmm1
palignr $8, %xmm0, %xmm0
mulpd %xmm2, %xmm0
addsubpd%xmm0, %xmm1
addpd %xmm4, %xmm1
movups %xmm1, (%rcx,%rax)
addq$16, %rax
cmpq%rsi, %rax
jne .L3
ICC unrolls the body once more. With -mavx2 we get
.L4:
vmovupd (%rdx,%rsi), %xmm6
vinsertf128 $0x1, 16(%rdx,%rsi), %ymm6, %ymm1
vmovupd (%rcx,%rsi), %xmm7
vmulpd %ymm5, %ymm1, %ymm2
vpermpd $177, %ymm1, %ymm1
vmulpd %ymm4, %ymm1, %ymm1
vaddsubpd %ymm1, %ymm2, %ymm1
vinsertf128 $0x1, 16(%rcx,%rsi), %ymm7, %ymm2
vaddpd %ymm2, %ymm1, %ymm1
vmovups %xmm1, (%rcx,%rsi)
vextractf128$0x1, %ymm1, 16(%rcx,%rsi)
addq$32, %rsi
cmpq%rsi, %rdi
jne .L4
if I add -mfma for example via -march=core-avx2 I get again
.L4:
vpermpd $177, (%rdx,%rsi), %ymm2
vmovapd %ymm4, %ymm1
vmulpd %ymm5, %ymm2, %ymm2
vfmsub132pd (%rdx,%rsi), %ymm2, %ymm1
vfmadd231pd (%rdx,%rsi), %ymm4, %ymm2
vshufpd $10, %ymm2, %ymm1, %ymm1
vaddpd (%rcx,%rsi), %ymm1, %ymm1
vmovupd %ymm1, (%rcx,%rsi)
addq$32, %rsi
cmpq%rsi, %rdi
jne .L4
showing that we lack vfmaddsub patterns or those present do not work
properly. combine sees
37: r109:V4DF={r127:V4DF*r105:V4DF+-r108:V4DF}
38: r110:V4DF={r127:V4DF*r105:V4DF+r108:V4DF}
REG_DEAD r127:V4DF
REG_DEAD r108:V4DF
39: r129:V4DF=vec_select(vec_concat(r109:V4DF,r110:V4DF),parallel)
REG_DEAD r110:V4DF
REG_DEAD r109:V4DF
unfortunately the fmaddsub patterns all use UNSPECs with the comment
;; It would be possible to represent these without the UNSPEC as
;;
;; (vec_merge
;; (fma op1 op2 op3)
;; (fma op1 op2 (neg op3))
;; (merge-const))
;;
;; But this doesn't seem useful in practice.
the AVX512 ones do not seem to suffer from this but using AVX512 via
-march=knl also only results in
.L4:
vmovupd (%rdx,%rax), %zmm1
vpermpd $177, %zmm1, %zmm2
vmovapd %zmm1, %zmm0
vmulpd %zmm4, %zmm2, %zmm2
vfmsub132pd %zmm3, %zmm2, %zmm0
vfmadd132pd %zmm3, %zmm2, %zmm1
vshufpd $170, %zmm1, %zmm0, %zmm0
vaddpd (%rcx,%rax), %zmm0, %zmm0
vmovupd %zmm0, (%rcx,%rax)
leaq64(%rax), %rax
cmpq%rax, %rsi
jne .L4
but maybe KNL doesn't have fmaddsub. Ah, with AVX512 we end up with
vec_merge (like with SSE2) but above AVX256 shows concat/select
(avx_shufpd256_1).
Maybe combine itself can try both variants in case there's a duality
between (vec_merge ...) and (vec_select (vec_concat ...))?
[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #15 from Tom de Vries --- Patch fixing the problem mentioned in the description committed to trunk. Other problems mentioned fixed as well in trunk. Marking resolved-fixed.
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #26 from Richard Biener --- Author: rguenth Date: Thu Jan 3 12:23:27 2019 New Revision: 267552 URL: https://gcc.gnu.org/viewcvs?rev=267552&root=gcc&view=rev Log: 2019-01-03 Jan Hubicka PR tree-optimization/85574 * tree-ssa-uncprop.c (struct equiv_hash_elt): Remove unused structure. (struct ssa_equip_hash_traits): Declare. (val_ssa_equiv): Use custom hash traits using operand_equal_p. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-uncprop.c
[Bug fortran/48543] Collapse identical strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48543 --- Comment #7 from Thomas Koenig --- Author: tkoenig Date: Thu Jan 3 12:32:34 2019 New Revision: 267553 URL: https://gcc.gnu.org/viewcvs?rev=267553&root=gcc&view=rev Log: 2019-01-02 Thomas Koenig PR fortran/48543 * gfortran.dg/const_chararacter_merge.f90: Remove. Removed: trunk/gcc/testsuite/gfortran.dg/merge_char_const.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 --- Comment #9 from Segher Boessenkool --- I think we should declare one of the forms canonical, and make simplify use that one, if possible. If we really want one form in some cases and another in other cases something like change_zero_ext will work.
[Bug bootstrap/88668] Code generated was different for PowerPC when build!=host compared to build=host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88668 --- Comment #4 from Umesh Kalappa --- Thank you Andrew for the suggestions and let us try the same and update here .
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 --- Comment #10 from rguenther at suse dot de --- On Thu, 3 Jan 2019, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 > > --- Comment #9 from Segher Boessenkool --- > I think we should declare one of the forms canonical, and make simplify > use that one, if possible. If we really want one form in some cases and > another in other cases something like change_zero_ext will work. Yeah, the main issue is that targets have existing patterns prefering either form. vec_merge avoids the need of wider intermediate modes but with vec_select it's easier to allow constrained operands... So IMHO RTL shouldn't have both but it would be convenient to not need that wider mode... it might ask for a vec_concat_and_select (aka vec_shuffle2). Another issue with vec_merge is the limit of the bitmask operand (CONST_INT) which limits us to 64 vector elements. That said, kill vec_merge and allow (vec_select:V4DF (vec_concat:V8DF (reg:V4DF...) (reg:V4DF...)) (parallel [ (const_int 0) ]))) to be written as (vec_shuffle:V4DF (reg:V4DF...) (reg:V4DF...) (parallel [ (const_int 0) ]))) note vec_concat operands are not constrained in any way but vec_shuffle would be? That is, in practice targets can probably get rid of vec_merge by using vec_select/vec_concat "easily" even if that means introducing of "fake" larger vector modes.
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 --- Comment #11 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #10) > even if that means introducing of "fake" larger vector modes. That would be a good reason to not do this, except many targets already do need double-length modes to describe their permute instructions?
[Bug fortran/88669] Contiguous attribute wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
Strange.
The code looks like it does the right thing, but the attributes
apparently have not been set correctly. In resolve.c:
│13778 /* F2008, C448. */
│
│13779 if (c->attr.contiguous && (!c->attr.dimension ||
!c->attr.pointer))
│
│13780 {
│
>│13781 gfc_error ("Component %qs at %L has the CONTIGUOUS attribute
but "
│
│13782"is not an array pointer", c->name, &c->loc);
│
│13783 return false;
│
│13784 }
│
but
(gdb) p c
$2 = (gfc_component *) 0x2689980
(gdb) p c->attr.dimension
$3 = 0
(gdb) p c->attr.pointer
$4 = 0
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 --- Comment #12 from Uroš Bizjak --- (In reply to Richard Biener from comment #8) > Maybe combine itself can try both variants in case there's a duality > between (vec_merge ...) and (vec_select (vec_concat ...))? Please note that combine splitters are used to help combine create addsub pattern. Please also see addsub_vm_operator predicate that handles vec_merge form and addsub_vs_operator that handles vec_select/vec_concat combo. Please see PR66560. Probably these predicates and similar splitters can be used to handle fmaddsub instructions.
[Bug target/88671] New: generic vector passed in MMX regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88671
Bug ID: 88671
Summary: generic vector passed in MMX regs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
typedef unsigned int U32;
typedef U32 U32x2 __attribute__((vector_size(8)));
typedef U32 U32x4 __attribute__((vector_size(16)));
void bar2(U32x2);
void foo2(U32x2 *p)
{
bar2(*p);
}
void bar4(U32x4);
void foo4(U32x4 *p)
{
bar4(*p);
}
shows bar2/foo2 passing U32x2 in MMX regs on i?86-linux with -msse2
(on the stack when using -mno-mmx). On x86_64-linux args are passed in
SSE regs.
clang passes U32x2 values on the stack on i?86-linux independent of
-m[no-]mmx.
[Bug target/88671] generic vector passed in MMX regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88671 Richard Biener changed: What|Removed |Added Keywords||ABI Target||i?86-*-* --- Comment #1 from Richard Biener --- And -m32 -msse2 -mno-mmx of course warns: t.c: In function ‘foo2’: t.c:8:3: warning: MMX vector argument without MMX enabled changes the ABI [-Wpsabi] bar2(*p); ^~~~ so it seems to work as designed. Still it might be unfortunate to the occasional user of generic vectors with MMX size that MMX is used when not using intrinsics...
[Bug c++/88672] New: friend class template declaration in a class template is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88672 Bug ID: 88672 Summary: friend class template declaration in a class template is ignored Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: damian.jarek93 at gmail dot com Target Milestone: --- Friend class template declaration in a class template is ignored, reproduces on gcc 4.9 and above (didn't check earlier versions) Example: https://godbolt.org/z/FdmEHE Note that if S is not a class template, it works correctly: https://godbolt.org/z/dnp6uT
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 --- Comment #13 from rguenther at suse dot de --- On Thu, 3 Jan 2019, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 > > --- Comment #11 from Segher Boessenkool --- > (In reply to rguent...@suse.de from comment #10) > > even if that means introducing of "fake" larger vector modes. > > That would be a good reason to not do this, except many targets already > do need double-length modes to describe their permute instructions? Yes. I think there's no good need for vec_merge for those targets. vec_shuffle would of course remove the need of the larger modes.
[Bug sanitizer/88619] [9 Regression] ICE in asan_emit_stack_protection, at asan.c:1574 since r266664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88619
--- Comment #3 from Jakub Jelinek ---
Created attachment 45324
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45324&action=edit
gcc9-pr88619.patch
Untested fix. make check-gcc check-c++-all
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp' passes with this, but
haven't checked anything beyond that. The variables are sorted primarily on
large vs. small alignment (not relevant to x86), then on size and only
afterwards on alignment, so if there is e.g. a big variable and after it a
smaller one with much bigger alignment, we could have triggered this already in
earlier releases.
[Bug target/88671] generic vector passed in MMX regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88671 --- Comment #2 from Uroš Bizjak --- This is required by ABI, please see section 2.3.3 of i386 PSABI, where: The exceptions to parameters passed on stack are as follows: • The first three parameters of type __m64 are passed in %mm0, %mm1, and %mm2. So, clang is wrong.
[Bug libstdc++/88673] New: Overflowed array index read error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88673
Bug ID: 88673
Summary: Overflowed array index read error
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: venkateshprabu at gmail dot com
Target Milestone: ---
https://github.com/gcc-mirror/gcc/blob/gcc-6_2_0-release/libstdc++-v3/include/bits/random.tcc#L399
Coverity report:
399_M_gen_rand(void)
400{
401 const _UIntType __upper_mask = (~_UIntType()) << __r;
402 const _UIntType __lower_mask = ~__upper_mask;
403
1. Condition __k < 227UL /* 624UL - 397UL */, taking true branch.
4. Condition __k < 227UL /* 624UL - 397UL */, taking true branch.
7. Condition __k < 227UL /* 624UL - 397UL */, taking false branch.
404 for (size_t __k = 0; __k < (__n - __m); ++__k)
405{
406 _UIntType __y = ((_M_x[__k] & __upper_mask)
407 | (_M_x[__k + 1] & __lower_mask));
2. Condition __y & 1, taking true branch.
5. Condition __y & 1, taking true branch.
408 _M_x[__k] = (_M_x[__k + __m] ^ (__y >> 1)
409 ^ ((__y & 0x01) ? __a : 0));
3. Jumping back to the beginning of the loop.
6. Jumping back to the beginning of the loop.
410}
411
8. Condition __k < 623UL /* 624UL - 1 */, taking true branch.
412 for (size_t __k = (__n - __m); __k < (__n - 1); ++__k)
413{
414 _UIntType __y = ((_M_x[__k] & __upper_mask)
415 | (_M_x[__k + 1] & __lower_mask));
9. overflow: Add operation overflows on operands __k and
18446744073709551389UL.
CID 4797118 (#1-2 of 2): Overflowed array index read (INTEGER_OVERFLOW)
10. overflow_sink: Overflowed or truncated value (or a value computed from an
overflowed or truncated value) __k + 18446744073709551389UL used as array
index.
416 _M_x[__k] = (_M_x[__k + (__m - __n)] ^ (__y >> 1)
417 ^ ((__y & 0x01) ? __a : 0));
418}
[Bug target/88671] generic vector passed in MMX regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88671 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener --- OK, so the question would be whether unsinged int __attribute__((vector_size(8))) is of type __m64 (I guess x87 psABI terms are not C language lawyer terms). But yes, even when naming the type __m64 clang doesn't pass in mmx regs.
[Bug c/88674] New: GCC thinks that register is a qualifier in function declaration with no parameters.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88674
Bug ID: 88674
Summary: GCC thinks that register is a qualifier in function
declaration with no parameters.
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 case (prog.c):
void f(register void);
int main()
{
}
Compilation command line:
gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors
Observed behaviour:
The following error message was outputed:
prog.c:1:8: error: 'void' as only parameter may not be qualified
1 | void f(register void);
|^
Expected behaviour:
No error message outputed.
The program is valid. register is not a type qualifier.
Note:
Clang accepts the program without outputing any error message.
[Bug c++/88675] New: std::make_integer_sequence not working for enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88675
Bug ID: 88675
Summary: std::make_integer_sequence not working for enums
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: huili80 at gmail dot com
Target Milestone: ---
The following code doesn't compile with --std=c++17:
#include
enum Number
{
Zero,
One,
Two,
Three
};
int main()
{
std::make_integer_sequence s;
}
The error read:
/usr/include/c++/8/utility: In substitution of 'template
using make_integer_sequence = std::integer_sequence<_Tp,
__integer_pack(_Num)...> [with _Tp = Number; _Tp _Num = (Number)3]':
t.cpp:13:43: required from here
/usr/include/c++/8/utility:329:55: error: invalid conversion from 'sizetype' to
'Number' [-fpermissive]
= integer_sequence<_Tp, __integer_pack(_Num)...>;
^
/usr/include/c++/8/utility:329:55: error: invalid conversion from 'sizetype' to
'Number' [-fpermissive]
/usr/include/c++/8/utility:329:55: error: invalid conversion from 'sizetype' to
'Number' [-fpermissive]
I suspect that this would be an easy fix by changing
/usr/include/c++/8/utility:329 to
= integer_sequence<_Tp, _Tp(__integer_pack(_Num))...>;
[Bug d/88654] Hangs in libphobos testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654 --- Comment #3 from Iain Buclaw --- (In reply to Jakub Jelinek from comment #0) > The reason I'm filing this is that there are multiple issues: > > 1) what I'm worried about most is that the timeouts for tests don't work, it > happens that some test gets stuck, but it should be killed after 5 minutes > or for how long the default timeout is set and the set should FAIL in that > case or something similar > I couldn't reproduce, maybe I'm running the 32bit testsuite differently though? Running ../../../../../libphobos/testsuite/libphobos.unittests/unittests.exp ... WARNING: program timed out. FAIL: libphobos.unittests/phobos/static/std.net.curl WARNING: program timed out. FAIL: libphobos.unittests/phobos/shared/std.net.curl > 2) if Curl fails to initialize, the test shouldn't get stuck > Patch I've sent upstream fixes this. > 3) and, if libcurl isn't available, I think it would be better to skip the > test as UNSUPPORTED, i.e. add some effective-target that tests if libcurl is > available and if it fails, don't even try to run the test This would be a proc local to libphobos I guess? There's nothing using this module outside of the libphobos testsuite.
[Bug tree-optimization/88598] simplification of multiplication by 1 or 0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88598 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org --- Mine.
[Bug target/88671] generic vector passed in MMX regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88671 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from H.J. Lu --- (In reply to Uroš Bizjak from comment #2) > This is required by ABI, please see section 2.3.3 of i386 PSABI, where: > > The exceptions to parameters passed on stack are as follows: > • The first three parameters of type __m64 are passed in %mm0, %mm1, and > %mm2. > > So, clang is wrong. clang is never good at conforming to psABIs: https://bugs.llvm.org/show_bug.cgi?id=39501 There are other psABI bugs in clang.
[Bug tree-optimization/88676] New: missed opportunity is integer conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88676
Bug ID: 88676
Summary: missed opportunity is integer conditional
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take the following code:
int f(unsigned b)
{
int r;
if (b >= 2)
__builtin_unreachable();
switch (b) {
case 0:
r = 1;
break;
case 1:
r = 2;
break;
default:
r = 0;
break;
}
return r;
}
Compiled using the current trunk gcc and gcc 8.2.1 with -O3 on x86_64 the
following code is produced:
:
0: 31 c0 xor%eax,%eax
2: 83 ff 01cmp$0x1,%edi
5: 0f 94 c0sete %al
8: ff c0 inc%eax
a: c3 retq
This is quite good but it should be something like
leal 1(%edi),%eax
ret
The first three instructions test for 0 or 1 and load into %eax the values 0 or
1 respectively. This should be just a move.
[Bug d/88654] Hangs in libphobos testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654
--- Comment #4 from Jakub Jelinek ---
(In reply to Iain Buclaw from comment #3)
> (In reply to Jakub Jelinek from comment #0)
> > The reason I'm filing this is that there are multiple issues:
> >
> > 1) what I'm worried about most is that the timeouts for tests don't work, it
> > happens that some test gets stuck, but it should be killed after 5 minutes
> > or for how long the default timeout is set and the set should FAIL in that
> > case or something similar
> >
>
> I couldn't reproduce, maybe I'm running the 32bit testsuite differently
> though?
>
> Running ../../../../../libphobos/testsuite/libphobos.unittests/unittests.exp
> ...
> WARNING: program timed out.
> FAIL: libphobos.unittests/phobos/static/std.net.curl
> WARNING: program timed out.
> FAIL: libphobos.unittests/phobos/shared/std.net.curl
My i686-linux bootstraps are done through a couple of executable scripts in
~/hbin directory on x86_64-linux:
for i in ~/hbin/*; do echo ===$i===; cat $i; done
===/home/jakub/hbin/as===
#!/bin/sh
exec /usr/bin/as --32 "$@"
===/home/jakub/hbin/g++===
#!/bin/sh
exec /usr/bin/g++ -m32 "$@"
===/home/jakub/hbin/gcc===
#!/bin/sh
exec /usr/bin/gcc -m32 "$@"
===/home/jakub/hbin/ld===
#!/bin/sh
case "$*" in
--version) cat <<\EOF
GNU ld version 2.20.52.0.1-10.fc17 20100131
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
EOF
exit 0;;
esac
exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"
and then
PATH=~/hbin:$PATH i386 ../configure
--enable-languages=default,obj-c++,lto,go,brig,d
--enable-checking=yes,rtl,extra \
&& PATH=~/hbin:$PATH i386 make -j32 bootstrap > LOG 2>&1 \
&& PATH=~/hbin:$PATH i386 make -j32 -k check > LOGC 2>&1; \
../contrib/test_summary > LOGT 2>&1
and that got stuck forever if libcurl.i?86 wasn't installed (only
libcurl.x86_64 and libcurl-devel.x86_64), but works
fine now that I also have libcurl.i?86 installed.
> > 3) and, if libcurl isn't available, I think it would be better to skip the
> > test as UNSUPPORTED, i.e. add some effective-target that tests if libcurl is
> > available and if it fails, don't even try to run the test
>
> This would be a proc local to libphobos I guess? There's nothing using this
> module outside of the libphobos testsuite.
If the test doesn't fail if it fails to load libcurl (and doesn't get stuck),
it is fine too.
If it fails if it is missing, yeah, something like a tcl procedure somewhere in
libphobos/testsuite/lib/*.exp would do.
As libphobos itself doesn't need libcurl-devel, it is just dlopen, so I think
you want to test that
#include
int
main ()
{
void *h = dlopen ("libcurl.so.4"); // etc., whatever the library will try to
dlopen
...
}
will succeed dlopening it.
[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84478 --- Comment #10 from H.J. Lu --- (In reply to Rainer Orth from comment #5) > The new testcase FAILs e.g. on i386-pc-solaris2.11 and sparc-sun-solaris2.11 > (32-bit only) at -O1 and above: > > +FAIL: gcc.c-torture/execute/pr84478.c -O1 execution test > +FAIL: gcc.c-torture/execute/pr84478.c -O2 execution test > +FAIL: gcc.c-torture/execute/pr84478.c -O2 -flto execution test > +FAIL: gcc.c-torture/execute/pr84478.c -O2 -flto -flto-partition=none > execution test > +FAIL: gcc.c-torture/execute/pr84478.c -O3 -fomit-frame-pointer > -funroll-loops -fpeel-loops -ftracer -finline-functions execution test > +FAIL: gcc.c-torture/execute/pr84478.c -O3 -g execution test > > According to gcc-testresult postings, the same happens on a couple of other > targets, including i686-pc-linux-gnu. Please try r267520 or newer.
[Bug tree-optimization/88598] simplification of multiplication by 1 or 0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88598 --- Comment #6 from rsandifo at gcc dot gnu.org --- I think a general fix for this would involve tracking the set of nonzero vector elements and adding a match.pd rule that uses that to replace REDUC functions in which only one element of the argument is nonzero.
[Bug fortran/88669] Contiguous attribute wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669 --- Comment #3 from Thomas Koenig --- Works when class(t) is replaced by type(t), so the attributes were not correctly set somewhere.
[Bug tree-optimization/88598] simplification of multiplication by 1 or 0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88598 --- Comment #7 from rguenther at suse dot de --- On Thu, 3 Jan 2019, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88598 > > --- Comment #6 from rsandifo at gcc dot gnu.org > --- > I think a general fix for this would involve tracking the set of > nonzero vector elements and adding a match.pd rule that uses that > to replace REDUC functions in which only one element of the > argument is nonzero. Yes. Or even replacing REDUC_PLUS with a partial reduction over the constants plus the single non-constant element. But variable-length stuff is a bit awkward in match.pd.
[Bug lto/88677] New: Divergence in -O2 and -O2 -flto early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 Bug ID: 88677 Summary: Divergence in -O2 and -O2 -flto early opts Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 45325 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45325&action=edit testcase This causes profile data loss for Firefox. There is one PHI different in function obj_seal in fre1 dump when built with: g++ test2.ii -O3 -fomit-frame-pointer -funwind-tables -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno test2.ii -fdump-tree-fre1 -flto and g++ test2.ii -O3 -fomit-frame-pointer -funwind-tables -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno test2.ii -fdump-tree-fre1
[Bug lto/88677] Divergence in -O2 and -O2 -flto early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 --- Comment #1 from Jan Hubicka --- Created attachment 45326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45326&action=edit dump with no lto
[Bug lto/88677] Divergence in -O2 and -O2 -flto early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 --- Comment #2 from Jan Hubicka --- Created attachment 45327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45327&action=edit dump with lto
[Bug target/86891] [9 Regression] __builtin_sub_overflow incorrect for unsigned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891 --- Comment #4 from Richard Earnshaw --- Yes, the extension should be zero-extend, not sign extend. The plus operation is correct, however, since decrementing the first operand could lead to underflow if it was zero. So the correct rtl would be (compare ((zero_x(a)) (plus (zero_x(b) (ltu(cc, 0) (minus (...))
[Bug fortran/88678] New: [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 Bug ID: 88678 Summary: [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- There are a bunch of the gfortran.dg/ieee/ieee_X.f90 test cases that began failing with r267465: FAIL: gfortran.dg/ieee/ieee_10.f90 -O0 execution test FAIL: gfortran.dg/ieee/ieee_10.f90 -O1 execution test FAIL: gfortran.dg/ieee/ieee_10.f90 -O2 execution test FAIL: gfortran.dg/ieee/ieee_10.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/ieee/ieee_10.f90 -O3 -g execution test FAIL: gfortran.dg/ieee/ieee_10.f90 -Os execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -O0 execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -O1 execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -O2 execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -O3 -g execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -Os execution test FAIL: gfortran.dg/ieee/ieee_3.f90 -O0 execution test FAIL: gfortran.dg/ieee/ieee_3.f90 -O1 execution test FAIL: gfortran.dg/ieee/ieee_3.f90 -O2 execution test FAIL: gfortran.dg/ieee/ieee_3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/ieee/ieee_3.f90 -O3 -g execution test FAIL: gfortran.dg/ieee/ieee_3.f90 -Os execution test FAIL: gfortran.dg/ieee/ieee_4.f90 -O0 execution test FAIL: gfortran.dg/ieee/ieee_4.f90 -O1 execution test FAIL: gfortran.dg/ieee/ieee_4.f90 -O2 execution test FAIL: gfortran.dg/ieee/ieee_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/ieee/ieee_4.f90 -O3 -g execution test FAIL: gfortran.dg/ieee/ieee_4.f90 -Os execution test FAIL: gfortran.dg/ieee/large_1.f90 -O0 execution test FAIL: gfortran.dg/ieee/large_1.f90 -O1 execution test FAIL: gfortran.dg/ieee/large_1.f90 -O2 execution test FAIL: gfortran.dg/ieee/large_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/ieee/large_1.f90 -O3 -g execution test FAIL: gfortran.dg/ieee/large_1.f90 -Os execution test The failures all look like this one: spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/ieee/ieee_10.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O0 -ffpe-trap=overflow,invalid -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -lm -o ./ieee_10.exe PASS: gfortran.dg/ieee/ieee_10.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.
[Bug lto/88677] [9 Regression] Divergence in -O2 and -O2 -flto early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-03 Known to work||8.2.0 Summary|Divergence in -O2 and -O2 |[9 Regression] Divergence |-flto early opts|in -O2 and -O2 -flto early ||opts Ever confirmed|0 |1 Known to fail||9.0 --- Comment #3 from Martin Liška --- Started with r265841.
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to seurer from comment #0) > Program received signal SIGFPE: Floating-point exception - erroneous > arithmetic operation. > > Backtrace for this error: > #0 0x3fffb00304d7 in ??? What is this? > #1 0x3fffafd17068 in ??? and this? > FAIL: gfortran.dg/ieee/ieee_10.f90 -O0 execution test > > > r267465 | kargl | 2018-12-29 12:10:57 -0600 (Sat, 29 Dec 2018) | 11 lines > > 2018-12-29 Steven G. Kargl > > PR fortran/88342 > * ieee/ieee_arithmetic.F90: Prevent exceptions in IEEE_VALUE if > -ffpe-trap=invalid or -ffpe-trap=overflow is used. > > 2018-12-29 Steven G. Kargl > > PR fortran/88342 > * gfortran.dg/ieee/ieee_10.f90: New test. The change in question queries the system if it supports IEEE arithmetic. If powerpc64 does not support IEEE arithmetic or the OS prevents a user from manipulating the FPU, then you need to XFAIL the tests.
[Bug lto/88677] [9 Regression] Divergence in -O2 and -O2 -flto early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 --- Comment #4 from Jan Hubicka --- This drops TYPE_NEEDS_CONSTRUCTING. I checked the uses jan@skylake:~/trunk/gcc> grep TYPE_NEEDS_CONSTRU *.c gimplify.c: || TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (decl print-tree.c: if (TYPE_NEEDS_CONSTRUCTING (node)) tree.c: TYPE_NEEDS_CONSTRUCTING (type) = 0; tree.c: verify_variant_match (TYPE_NEEDS_CONSTRUCTING); tree-inline.c: if (TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (p))) I convinced myself that gimply and tree-inline uses are there only for inlining/gimplifying within frontend. Perhaps they can also be dropped? Honza
[Bug lto/88677] [9 Regression] Divergence in -O2 and -O2 -flto early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 Martin Liška changed: What|Removed |Added Keywords||needs-reduction --- Comment #5 from Martin Liška --- I'm reducing that test-case..
[Bug target/88027] PowerPC generates slightly weird code for memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88027 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-03 Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from acsawdey at gcc dot gnu.org --- This is fixed in trunk but I should backport to 8 now too.
[Bug c++/88675] std::make_integer_sequence not working for enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88675 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- The C++ standard requires that the first template argument for std::integer_sequence is an integer type, so your code is undefined.
[Bug c/88679] New: SSE2 intrinsics are available by default on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88679
Bug ID: 88679
Summary: SSE2 intrinsics are available by default on x86
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
SSE2 intrinsics are available by default when compiling code for 32-bit x86.
Code below compiles fine with options -m32 -O3. I had to add -mno-sse2 to get
an error.
Fortunately __SSE2__ is not defined by default, so code can rely on it.
[code]
#include
void test(__m128i const* m)
{
__m128i v = _mm_load_si128(m);
}
[/code]
[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #16 from joseph at codesourcery dot com ---
On Thu, 3 Jan 2019, iains at gcc dot gnu.org wrote:
> Unfortunately, there doesn't appear to be anything in the GCC test suite that
> catches this (all languages reg-strap was clean, on gcc110). Does it show for
> a 32b multilib on a 64b host, or only with a 32b host?
All my testing has been for x86_64-linux-gnu host, powerpc-linux-gnu
target, --disable-multilib --with-float=soft.
The issue appears when a test built with a compiler without the problem
patch is run with glibc built with a compiler with the patch, so it looks
like something miscompiled in glibc - but it also seems sensitive to e.g.
the exact compilation options used for compiling the test with the
non-buggy compiler (as would be expected if e.g. the buggy compiler is
generating code that's using uninitialized or overwritten data in some way
and so details that should be irrelevant end up mattering). I'll look for
a specific object file in glibc that shows the issue if built with the
buggy compiler and inserted in glibc otherwise built with the non-buggy
compiler. The current cut-down version of the glibc test I have (built
with -lm -O2 -fno-builtin with GCC 8 branch just before the change) is:
float nextafterf (float, float);
int printf (const char *, ...);
static void
check_ulp (void)
{
float ulps, value;
value = nextafterf (10, 20);
/* Should print 0x1.42p+3. */
printf ("%a\n", value);
for (int i = 1; i < 100; i++)
value = nextafterf (value, 20);
ulps = __builtin_fabsf (value - 10);
/* Should print 0x1.9p-14; buggy case hangs before this. */
printf ("%a\n", ulps);
}
int
main (void)
{
check_ulp ();
}
[Bug target/88679] SSE2 intrinsics are available by default on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88679 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-03 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- Please show output of $ gcc -v $ gcc -v -m32 -S
[Bug libstdc++/88673] Overflowed array index read error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88673
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2019-01-03
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
GCC 6.x is no longer supported, and 6.2.0 is not even the latest release from
the 6.x branch, so it's not very useful to report bugs against that version.
(In reply to Venkatesh Prabhu from comment #0)
> https://github.com/gcc-mirror/gcc/blob/gcc-6_2_0-release/libstdc++-v3/
> include/bits/random.tcc#L399
>
>
> Coverity report:
>
> 399_M_gen_rand(void)
> 400{
> 401 const _UIntType __upper_mask = (~_UIntType()) << __r;
> 402 const _UIntType __lower_mask = ~__upper_mask;
> 403
> 1. Condition __k < 227UL /* 624UL - 397UL */, taking true branch.
> 4. Condition __k < 227UL /* 624UL - 397UL */, taking true branch.
> 7. Condition __k < 227UL /* 624UL - 397UL */, taking false branch.
> 404 for (size_t __k = 0; __k < (__n - __m); ++__k)
> 405{
> 406 _UIntType __y = ((_M_x[__k] & __upper_mask)
> 407 | (_M_x[__k + 1] & __lower_mask));
> 2. Condition __y & 1, taking true branch.
> 5. Condition __y & 1, taking true branch.
> 408 _M_x[__k] = (_M_x[__k + __m] ^ (__y >> 1)
> 409 ^ ((__y & 0x01) ? __a : 0));
> 3. Jumping back to the beginning of the loop.
> 6. Jumping back to the beginning of the loop.
> 410}
> 411
> 8. Condition __k < 623UL /* 624UL - 1 */, taking true branch.
> 412 for (size_t __k = (__n - __m); __k < (__n - 1); ++__k)
> 413{
> 414 _UIntType __y = ((_M_x[__k] & __upper_mask)
> 415 | (_M_x[__k + 1] & __lower_mask));
> 9. overflow: Add operation overflows on operands __k and
> 18446744073709551389UL.
The operands are unsigned, so cannot overflow.
>
> CID 4797118 (#1-2 of 2): Overflowed array index read (INTEGER_OVERFLOW)
> 10. overflow_sink: Overflowed or truncated value (or a value computed from
> an overflowed or truncated value) __k + 18446744073709551389UL used as array
> index.
> 416 _M_x[__k] = (_M_x[__k + (__m - __n)] ^ (__y >> 1)
The range of values of __k is [n-m, n-1) so the range of indices is
[n-m+m-n, n-1) i.e. [0,n-1) which does not go out of range.
This seems like a Coverity bug.
> 417 ^ ((__y & 0x01) ? __a : 0));
> 418}
[Bug target/88510] GCC generates inefficient U64x2/v2di scalar multiply for NEON32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88510 --- Comment #2 from Devin Hussey --- Update: I did the calculations, and twomul has the same cycle count as goodmul_sse. vmul.i32 with 128-bit operands takes 4 cycles (I assumed it was two), so just like goodmul_sse, it takes 11 cycles.
[Bug c++/88672] friend class template declaration in a class template is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88672 --- Comment #1 from Jonathan Wakely --- Please check if this is a duplicate of one of the bugs that PR 59002 depends on.
[Bug c++/88672] friend class template declaration in a class template is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88672 --- Comment #2 from Jonathan Wakely --- Also, https://gcc.gnu.org/bugs very clearly says we need the testcase in bugzilla, and not just a URL to some other site.
[Bug c/88674] GCC thinks that register is a qualifier in function declaration with no parameters.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88674 --- Comment #1 from joseph at codesourcery dot com --- "qualified" is used in the informal sense of "any additional specifiers along with void", not in the sense of "type qualifiers present". The program is not valid. J.2 explicitly lists "A storage-class specifier or type qualifier modifies the keyword void as a function parameter type list (6.7.6.3)." as undefined behavior. (I think this is a case of undefined-for-lack-of-semantics rather than normative-text-directly-says-is-undefined.)
[Bug target/88679] SSE2 intrinsics are available by default on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88679 --- Comment #2 from Daniel Fruzynski --- I used compiler at https://godbolt.org/. Here are outputs for both commands: $ gcc -v Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++ Target: x86_64-linux-gnu Configured with: ../gcc-trunk-20190103/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=GCC-Explorer-Build Thread model: posix gcc version 9.0.0 20190102 (experimental) (GCC-Explorer-Build) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/tmp/compiler-explorer-compiler11903-60-1nshruf.qczq/output.s' '-masm=intel' '-S' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/compiler-explorer/gcc-trunk-20190103/bin/../libexec/gcc/x86_64-linux-gnu/9.0.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/ -D_GNU_SOURCE -quiet -dumpbase example.cpp -masm=intel -mtune=generic -march=x86-64 -auxbase-strip /tmp/compiler-explorer-compiler11903-60-1nshruf.qczq/output.s -g -version -fdiagnostics-color=always -o /tmp/compiler-explorer-compiler11903-60-1nshruf.qczq/output.s GNU C++14 (GCC-Explorer-Build) version 9.0.0 20190102 (experimental) (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0/backward" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0 /opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0/x86_64-linux-gnu /opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0/backward /opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/include /opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++14 (GCC-Explorer-Build) version 9.0.0 20190102 (experimental) (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: f724e483fb841047a948ffa41ca3218a COMPILER_PATH=/opt/compiler-explorer/gcc-trunk-20190103/bin/../libexec/gcc/x86_64-linux-gnu/9.0.0/:/opt/compiler-explorer/gcc-trunk-20190103/bin/../libexec/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-trunk-20190103/bin/../libexec/gcc/:/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../x86_64-linux-gnu/bin/ LIBRARY_PATH=/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/:/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-trunk-20190103/bin/../lib/gcc/:/opt/compiler-explorer/gcc-trunk-20190103/bin/.
[Bug c++/88680] New: [9 Regression] bogus -Wtype-limits for constant expressions after r267272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88680 Bug ID: 88680 Summary: [9 Regression] bogus -Wtype-limits for constant expressions after r267272 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- -Wtype-limits is documented to Warn if a comparison is always true or always false due to the limited range of the data type, but do not warn for constant expressions. According to the documentation the following test case should be accepted with no warning, but since r267272 triggers one (Clang does not warn): $ cat t.C && gcc -S -Wtype-limits t.C const unsigned n = 8; static_assert (n >= 0 && n % 2 == 0, ""); t.C:3:18: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] 3 | static_assert (n >= 0 && n % 2 == 0, ""); |~~^~~~ This change apparently causes a large number of new warnings in Firefox builds. According to my breakdown of Honza's build here at the following link, there are over 20 thousand such warnings: https://hg.mozilla.org/try/rev/e1e0472c3f68e47b9741d7814ef4417759cde24c DiagnosticCount UniqueFiles -Wtype-limits 2088210441 604 -Wmultistatement-macros155252 -Wcoverage-mismatch 793 225 141 -Wclass-memaccess 346 72 46 -Wsign-compare 292 127 55 -Wnarrowing 27221 -Wmissing-profile 245 212 207 -Wattributes21211 -Wint-in-bool-context 14032 -Wdeprecated-copy 104 22 10 -Wmaybe-uninitialized 103 67 54
[Bug target/88679] SSE2 intrinsics are available by default on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88679 --- Comment #3 from H.J. Lu --- Your GCC is configured -m32 ISA to x86-64 ISA by default. To default -m32 ISA to i686 ISA, please configure your GCC with --with-arch_32=i686. Or you can use "-march=i686 -m32".
[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 --- Comment #17 from Joseph S. Myers --- Created attachment 45328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45328&action=edit Preprocessed source Replacing s_nextafterf.os built with trunk with that patch reverted, by the same file as built with trunk without the reversion, is sufficient to produce a glibc binary showing the problem. Preprocessed sources attached. Given the --with-float=soft compiler, compile with: -std=gnu11 -fgnu89-inline -g -O2 -fmerge-all-constants -frounding-math -fno-stack-protector -fno-math-errno -mlong-double-128 -fpic s_nextafterf.i.
[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 --- Comment #18 from Joseph S. Myers --- Created attachment 45329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45329&action=edit Good assembly (with the GCC patch reverted)
[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343 --- Comment #19 from Joseph S. Myers --- Created attachment 45330 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45330&action=edit Bad assembly (from trunk r267560 with the patch still present)
[Bug target/88679] SSE2 intrinsics are available by default on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88679 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug target/88620] [7/8/9 Regression] ICE in assign_stack_temp_for_type, at function.c:837
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88620 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 45331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45331&action=edit gcc9-pr88620.patch Untested fix.
[Bug libstdc++/88681] New: Missing symbol exports in libstdc++.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88681
Bug ID: 88681
Summary: Missing symbol exports in libstdc++.so
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The following fails to link:
#define _GLIBCXX_USE_CXX11_ABI 0
#include
#include
#include
template
void test_time_get()
{
using namespace std;
locale loc_c = locale::classic();
basic_istringstream iss;
iss.imbue(loc_c);
const time_get& tget = use_facet>(iss.getloc());
typedef istreambuf_iterator iter;
const iter end;
tm time;
ios_base::iostate err = ios_base::badbit;
tget.get(iter(iss), end, iss, err, &time, 'Y');
}
std::string s = "C";
template
struct facet : std::collate_byname
{
facet() : std::collate_byname(s) { }
};
template
void
test_collate_byname()
{
facet c;
}
int main()
{
test_time_get();
test_time_get();
test_collate_byname();
test_collate_byname();
}
The errors are:
/usr/bin/ld: /tmp/ccHErRY2.o: in function `void test_time_get()':
/tmp/missing.cc:22: undefined reference to `std::time_get >
>::get(std::istreambuf_iterator >,
std::istreambuf_iterator >, std::ios_base&,
std::_Ios_Iostate&, tm*, char, char) const'
/usr/bin/ld: /tmp/ccHErRY2.o: in function `void test_time_get()':
/tmp/missing.cc:22: undefined reference to `std::time_get >
>::get(std::istreambuf_iterator >,
std::istreambuf_iterator >, std::ios_base&,
std::_Ios_Iostate&, tm*, char, char) const'
/usr/bin/ld: /tmp/ccHErRY2.o: in function `facet::facet()':
/tmp/missing.cc:30: undefined reference to
`std::collate_byname::collate_byname(std::string const&, unsigned long)'
/usr/bin/ld: /tmp/ccHErRY2.o: in function `facet::facet()':
/tmp/missing.cc:30: undefined reference to
`std::collate_byname::collate_byname(std::string const&, unsigned
long)'
collect2: error: ld returned 1 exit status
The exports have been missing since these symbols were added for GCC 5.1
[Bug libstdc++/88681] Missing symbol exports in libstdc++.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88681 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-03 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/88681] Missing symbol exports in libstdc++.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88681 --- Comment #1 from Jonathan Wakely --- N.B. When optimization is enabled the functions are inlined, so the exports aren't needed.
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #2 from seurer at gcc dot gnu.org --- Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x3fffb17f0477 in ??? #1 0x3fffb14f1694 in feenableexcept at ../sysdeps/powerpc/fpu/feenablxcpt.c:44 #2 0x3fffb1765e73 in __ieee_exceptions_MOD_ieee_support_halting at /home/seurer/gcc/gcc-test2/libgfortran/ieee/ieee_exceptions.F90:193 #3 0x3fffb176590f in __ieee_arithmetic_MOD_ieee_value_4 at /home/seurer/gcc/gcc-test2/libgfortran/ieee/ieee_arithmetic.F90:972 #4 0x1aa7 in foo at /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/ieee/ieee_10.f90:12 #5 0x1aa7 in main at /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/ieee/ieee_10.f90:5 FAIL: gfortran.dg/ieee/ieee_10.f90 -O3 -g execution test
[Bug target/88616] [9 Regression] ICE in gimplify_expr at gcc/gimplify.c:13363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88616 Jakub Jelinek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01750.html patch doesn't solve this, and neither does https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01749.html, nevertheless it looks related to the arm weirdness of returning this from cdtors.
