[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Feb 22 08:28:42 2018 New Revision: 257891 URL: https://gcc.gnu.org/viewcvs?rev=257891&root=gcc&view=rev Log: PR tree-optimization/84503 * gimple-ssa-store-merging.c (merged_store_group::merge_into): Compute width as info->bitpos + info->bitsize - start. (merged_store_group::merge_overlapping): Simplify width computation. (check_no_overlap): New function. (imm_store_chain_info::try_coalesce_bswap): Compute expected start + width and last_order of the group, fail if check_no_overlap fails. (imm_store_chain_info::coalesce_immediate_stores): Don't merge info to group if check_no_overlap fails. * gcc.dg/pr84503-1.c: New test. * gcc.dg/pr84503-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr84503-1.c trunk/gcc/testsuite/gcc.dg/pr84503-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Feb 22 08:29:56 2018 New Revision: 257892 URL: https://gcc.gnu.org/viewcvs?rev=257892&root=gcc&view=rev Log: PR target/84502 * stor-layout.c (finalize_type_size): Propagate TYPE_EMPTY_P flag to all type variants. * g++.dg/torture/pr84502.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr84502.C Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/84503] [7 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression]|[7 Regression] |store-merging |store-merging |miscompilation on powerpc64 |miscompilation on powerpc64 |with -O3 since r241789 |with -O3 since r241789 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far, 7.x fix will be very different.
[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193 --- Comment #12 from Martin Liška --- Author: marxin Date: Thu Feb 22 08:50:41 2018 New Revision: 257893 URL: https://gcc.gnu.org/viewcvs?rev=257893&root=gcc&view=rev Log: Add "native" as a valid option value for -march= on i386 (PR driver/83193). 2018-02-22 Martin Liska PR driver/83193 * config/i386/i386.c (ix86_option_override_internal): Add "native" as a possible value for -march and -mtune. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug fortran/84509] STOP and PAUSE statements with -fdefault-integer-8 and large stop code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509 Janne Blomqvist changed: What|Removed |Added Component|gcov-profile|fortran --- Comment #1 from Janne Blomqvist --- Oops, component was supposed to be fortran, not gcov, sorry!
[Bug gcov-profile/84509] New: STOP and PAUSE statements with -fdefault-integer-8 and large stop code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509 Bug ID: 84509 Summary: STOP and PAUSE statements with -fdefault-integer-8 and large stop code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Consider the program ! compile with -fdefault-integer-8 program test stop 12345678901 end program test Compiling this with -fdefault-integer-8 and running it results in STOP -539222987 This is because the value is larger than 2**31-1 and is typecasted to an INTEGER(kind=4) before calling the stop function in libgfortran. The same happens for the ERROR STOP and PAUSE statements as well. (Not sure this is actually worth fixing since with -fdefault-integer-8 we're throwing standards conformance out of the window anyway)
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-22 Target Milestone|--- |8.0 Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.0 --- Comment #2 from Martin Liška --- Confirmed for all releases supporting -fsanitize=alignment. Clang does not emit the error. Jakub can you please take a look?
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #3 from Marc Glisse --- Copying from https://gcc.gnu.org/ml/gcc-help/2017-12/msg00031.html "The way _mm_load_sd is currently implemented in gcc, yes, sanitizers are right to complain. Intel could have named the thing _mm_loadu_sd if that's what they meant. It would be simple to change if we decide to do so, please file a PR in bugzilla. Workaround: define a typedef for double with __attribute__((__aligned__(1))), and use _mm_set_sd(*(newtype*)p), that's how it will likely be done if we change emmintrin.h."
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #4 from Jakub Jelinek ---
I don't see how this is related to sanitizer, sanitizer just checks what it
sees.
Say _mm_load_sd is implemented as
/* Create a vector with element 0 as *P and the rest zero. */
extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_sd (double const *__P)
{
return _mm_set_sd (*__P);
}
and so pedantically requires aligned load, it is like any other double *
dereference.
If these intrinsics really allow misaligned loads, then we need to use
something different, not sure if e.g.
struct S __attribute__((packed)) { double d; } const *p = (struct S const *)
(void *) __P;
return _mm_set_sd (p->d);
would be ok from aliasing POV or if we'd need to introduce a builtin to load a
potentially misaligned float or double. I guess the most important would be
that it doesn't slow down code.
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #5 from Jakub Jelinek --- (In reply to Marc Glisse from comment #3) > Workaround: define a typedef for double with > __attribute__((__aligned__(1))), and use _mm_set_sd(*(newtype*)p), that's > how it will likely be done if we change emmintrin.h." I don't think we really support misaligned loads from non-aggregates, there have been lengthy discussions about that in the past.
[Bug c++/81589] Possible False-Positive with decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81589 Martin Liška changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #4 from Martin Liška --- Is there any progress about it? It's blocking chromium build right now..
[Bug c/84510] New: C front-end does not utilise -Wuseless-cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84510 Bug ID: 84510 Summary: C front-end does not utilise -Wuseless-cast Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bje at gcc dot gnu.org Target Milestone: --- The -Wuseless-cast option only applies to C++ and Objective C. It would also be useful in the C front-end, particularly for finding 'do nothing' casts and casts of literals, which the compiler can do itself by inferring the type of the literal.
[Bug c++/84496] [6/7 Regression] Internal compiler error with lambda, static and auto since r236615
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84496
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-22
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Version|unknown |7.0
Target Milestone|--- |6.5
Summary|Internal compiler error |[6/7 Regression] Internal
|with lambda, static and |compiler error with lambda,
|auto|static and auto since
||r236615
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r236615 and got fixed on the trunk with r253600.
Reduced testcase:
// PR c++/84496
// { dg-do compile { target c++14 } }
template struct C { static constexpr T D = n; };
struct E : C {};
template struct F : C {};
template T foo ();
template struct H { typedef int G; };
template class I;
struct L;
template struct J;
template struct K;
struct R {
template
static J () (foo...)), L> o;
};
template struct K : R {
typedef decltype (o) G;
};
template
struct D : K::G>::D, P, Q...> {};
template struct I : D {};
template class function;
template struct function {
template ::G> struct C;
template using U = int;
template , typename = U, void>>
function (P);
};
template
template
function::function (P)
{
}
void bar (function);
void
baz ()
{
auto a = [] {
static int counter;
bar ([] (auto) { counter++; });
};
}
Will commit the testcase to trunk now to make sure we don't regress it again.
[Bug c++/84496] [6/7 Regression] Internal compiler error with lambda, static and auto since r236615
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84496 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Feb 22 09:55:32 2018 New Revision: 257895 URL: https://gcc.gnu.org/viewcvs?rev=257895&root=gcc&view=rev Log: PR c++/84496 * g++.dg/cpp1y/pr84496.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr84496.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/77655] [6/7/8 Regression]ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1plus))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77655 --- Comment #4 from Paolo Carlini --- This is fixed in trunk. I'm adding the testcase and removing the 8 Regression marker.
[Bug c++/77655] [6/7/8 Regression]ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1plus))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77655 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Feb 22 10:44:04 2018 New Revision: 257896 URL: https://gcc.gnu.org/viewcvs?rev=257896&root=gcc&view=rev Log: 2018-02-22 Paolo Carlini PR c++/77655 * g++.dg/cpp0x/pr77655.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr77655.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/84493] [8 Regression] ICE with invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84493 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Thu Feb 22 11:18:37 2018 New Revision: 257899 URL: https://gcc.gnu.org/viewcvs?rev=257899&root=gcc&view=rev Log: PR c++/84493 * parser.c (cp_parser_braced_list): Use require_open instead of consume_open. * g++.dg/parse/error59.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/error59.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #6 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Marc Glisse from comment #3)
> > Workaround: define a typedef for double with
> > __attribute__((__aligned__(1))), and use _mm_set_sd(*(newtype*)p), that's
> > how it will likely be done if we change emmintrin.h."
>
> I don't think we really support misaligned loads from non-aggregates, there
> have been lengthy discussions about that in the past.
We already use
typedef long long __m128i_u __attribute__ ((__vector_size__ (16),
__may_alias__, __aligned__ (1)));
_mm_loadu_si128 (__m128i_u const *__P)
{
return *__P;
}
So if that doesn't work, it needs fixing in a number of places...
[Bug fortran/84511] New: Internal compiler error from directly printing return of C_LOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84511 Bug ID: 84511 Summary: Internal compiler error from directly printing return of C_LOC Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: h.ratcliffe at warwick dot ac.uk Target Milestone: --- Created attachment 43487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43487&action=edit Tarball of 2-file working example Directly printing return from C_LOC causes an internal compiler error if C_LOC is called on a type defined in a module in a separate file. Capturing the return and then printing succeeds. Full error report is f951: internal compiler error: Bad IO basetype (10) 0x5cbd3f gfc_internal_error(char const*, ...) ../../src/gcc/fortran/error.c:1348 0x6bd3fe transfer_expr ../../src/gcc/fortran/trans-io.c:2475 0x6c0748 gfc_trans_transfer(gfc_code*) ../../src/gcc/fortran/trans-io.c:2620 0x6697a7 trans_code ../../src/gcc/fortran/trans.c:2017 0x6be1d6 build_dt ../../src/gcc/fortran/trans-io.c:2028 0x669787 trans_code ../../src/gcc/fortran/trans.c:1989 0x68e887 gfc_generate_function_code(gfc_namespace*) ../../src/gcc/fortran/trans-decl.c:6332 0x66d1f9 gfc_generate_module_code(gfc_namespace*) ../../src/gcc/fortran/trans.c:2195 0x622f3b translate_all_program_units ../../src/gcc/fortran/parse.c:6061 0x622f3b gfc_parse_file() ../../src/gcc/fortran/parse.c:6274 0x66600f gfc_be_parse_file ../../src/gcc/fortran/f95-lang.c:204 Same error arises on gfortran 5.4 and 7.2.0 on Ubuntu and 6.3.0 on OSX, but 4.3.4 on SLES 11 (SP4) succeeds. The error does not occur if module TWO defining the type is in the file where C_LOC is called.
[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #16 from Felix Fietkau --- Any update on this, or any way I could help in getting this fixed? It would be nice if we could finally switch OpenWrt to a more recent GCC version soon.
[Bug c++/84493] [8 Regression] ICE with invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84493 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/80955] Macros expanded in definition of user-defined literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955
--- Comment #4 from Jonathan Wakely ---
This causes a regression for:
const char* err() { return "Error in "__FILE__; }
file.cc: In function ‘const char* err()’:
file.cc:1:28: error: unable to find string literal operator
‘operator""__FILE__’ with ‘const char [10]’, ‘long unsigned int’ arguments
const char* err() { return "Error in "__FILE__; }
^~~
With GCC 7 this gave a warning about not finding a literal operator, and then
continued as the author intended, i.e. concatenating the two strings.
[Bug tree-optimization/84512] New: Missed optimization: should be precalculated in compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84512
Bug ID: 84512
Summary: Missed optimization: should be precalculated in
compile-time
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zamazan4ik at tut dot by
Target Milestone: ---
gcc(trunk) with '-O3' option for this code:
int foo()
{
int a[10];
for(int i = 0; i < 10; ++i)
{
a[i] = i*i;
}
int res = 0;
for(int i = 0; i < 10; ++i)
{
res += a[i];
}
return res;
}
produces this:
foo():
movabs rax, 4294967296
mov QWORD PTR [rsp-56], rax
movabs rax, 38654705668
mov QWORD PTR [rsp-48], rax
movabs rax, 107374182416
mov QWORD PTR [rsp-40], rax
movabs rax, 210453397540
mov QWORD PTR [rsp-32], rax
movdqa xmm0, XMMWORD PTR [rsp-40]
paddd xmm0, XMMWORD PTR [rsp-56]
movdqa xmm1, xmm0
psrldq xmm1, 8
paddd xmm0, xmm1
movdqa xmm1, xmm0
psrldq xmm1, 4
paddd xmm0, xmm1
movd eax, xmm0
add eax, 145
ret
but clang(trunk) with '-O3' produces this one:
foo(): # @foo()
mov eax, 285
ret
[Bug fortran/84513] New: gfortran -M generates circular dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84513 Bug ID: 84513 Summary: gfortran -M generates circular dependency Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: eh.toussaint at gmail dot com Target Milestone: --- When using the -M option to let gfortran generate a rule for inclusion in makefiles, the following code (all in one file) results in a circular dependency for the .mod file. $ cat foobar.f90 module bar end module program foo use bar end program ---end foobar.f90 $ gfortran -cpp -M foobar.f90 foobar.o bar.mod: foobar.f90 bar.mod It's not a major problem, because (GNU) Make simply drops it with the following message, but I'd still like to report it for the sake of neatness. make: Circular bar.mod <- bar.mod dependency dropped.
[Bug fortran/84513] gfortran -M generates circular dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84513 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-02-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Similar to/duplicate of pr47720?
[Bug c/84514] New: powerpc sub optimal condition register reuse with extended inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84514 Bug ID: 84514 Summary: powerpc sub optimal condition register reuse with extended inline asm Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: npiggin at gmail dot com Target Milestone: --- Created attachment 43488 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43488&action=edit test case with description in comment at the top There seem to be some missed opportunities reusing condition register over extended asm (that does not clobber cc).
[Bug fortran/84511] [6/7/8 Regression] Internal compiler error from directly printing return of C_LOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84511 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.8.5 Keywords||ice-on-valid-code Last reconfirmed||2018-02-22 Ever confirmed|0 |1 Summary|Internal compiler error |[6/7/8 Regression] Internal |from directly printing |compiler error from |return of C_LOC |directly printing return of ||C_LOC Target Milestone|--- |6.5 Known to fail||4.9.3, 5.5.0, 6.4.0, 7.3.0, ||8.0 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.9.3 up to trunk (8.0). The test compiles with 4.8.5.
[Bug tree-optimization/83126] [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83126 Tom de Vries changed: What|Removed |Added Keywords||patch --- Comment #10 from Tom de Vries --- https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01272.html
[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193 --- Comment #13 from Martin Liška --- Author: marxin Date: Thu Feb 22 12:16:58 2018 New Revision: 257900 URL: https://gcc.gnu.org/viewcvs?rev=257900&root=gcc&view=rev Log: Add "native" as a valid option value for -mcpu/-mtune= on arm (PR driver/83193). 2018-02-22 Martin Liska PR driver/83193 * common/config/arm/arm-common.c (arm_print_hint_for_cpu_option): Add "native" as a possible value. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/arm/arm-common.c
[Bug c++/80955] Macros expanded in definition of user-defined literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955 --- Comment #5 from Jonathan Wakely --- Is there a way to check if it's a pre-defined macro? Or just change the condition to allow starting with two underscores, but not allow starting with one (since user-defined UDLs must start with a single underscore, and must not start with two).
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #7 from Marc Glisse --- Unless vectors count as aggregates (more or less), in which case we can ignore my previous comment.
[Bug target/81572] [7/8 Regression] gcc-7 regression: unnecessary vector regmove on compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81572 --- Comment #3 from Vladimir Makarov --- I am working on this PR. The patch will be ready today or tomorrow. The problem is that the move insn has one alternative with early clobber and this move insn is processed on a fast path which ignores that other alternatives might have no early clobbers.
[Bug tree-optimization/84515] New: missed optimization: expected loop merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84515
Bug ID: 84515
Summary: missed optimization: expected loop merging
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i expected f1 and f2 to compile to the same code:
unsigned g;
void f1(unsigned count) {
unsigned i;
for (i = 0; i < count ; i++) g++;
}
void f2(unsigned count) {
unsigned i;
for (i = 0; i < count/2; i++) g++;
for ( ; i < count ; i++) g++;
}
but with -O3 the asm is
f1:
testl %edi, %edi
je .L1
addl %edi, g(%rip)
.L1:
ret
f2:
movl %edi, %eax
shrl %eax
je .L8
addl %eax, g(%rip)
.L8:
cmpl %eax, %edi
jbe .L7
subl %eax, %edi
addl %edi, g(%rip)
.L7:
ret
(on aarch64 even the address of g is recomputed for the second loop with adrp)
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #17 from Tom Tromey --- The results in comment #13 seem to be missing some compilations -- I would have expected to see more files from libcpp in there. As it is I only see directives.o and line-map.o.
[Bug target/81228] [7 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81228 --- Comment #10 from sudi at gcc dot gnu.org --- Author: sudi Date: Thu Feb 22 15:01:05 2018 New Revision: 257901 URL: https://gcc.gnu.org/viewcvs?rev=257901&root=gcc&view=rev Log: Adding the missing LTGT to plug the ICE in PR81228. This is a backport of r255625 of trunk. *** gcc/ChangeLog *** 2018-02-22 Sudakshina Das Bin Cheng Backport from mainline: 2017-12-14 Sudakshina Das Bin Cheng PR target/81228 * config/aarch64/aarch64.c (aarch64_select_cc_mode): Move LTGT to CCFPEmode. * config/aarch64/aarch64-simd.md (vec_cmp): Add LTGT. *** gcc/testsuite/ChangeLog *** 2017-02-22 Sudakshina Das Backport from mainline: 2017-12-14 Sudakshina Das PR target/81228 * gcc.dg/pr81228.c: New. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81228.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/aarch64/aarch64-simd.md branches/gcc-7-branch/gcc/config/aarch64/aarch64.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/81228] [7 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81228 sudi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from sudi at gcc dot gnu.org --- Backported to gcc-7 as r257901
[Bug c++/84516] New: bitfield temporaries > 32-bits have wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84516
Bug ID: 84516
Summary: bitfield temporaries > 32-bits have wrong type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu at mllr dot cc
Target Milestone: ---
(Disclaimer: I'm not a compiler guy, so I may accidentally use the wrong
terminology)
Example: https://godbolt.org/g/brhTMw
#include
struct A {
long x : 32;
long y : 33;
};
int main() {
A a;
std::cout << a.x; // OK
std::cout << a.y; // OK
std::cout << +a.x; // OK
std::cout << +a.y; // BREAKS on gcc
}
The problem is the last line. The type of the expression `+a.y` is 'long
int:33', which is not a type that operator<<() has an overload for. The type of
the expression `a.y` is 'long int' and so op<<() has an overload and works.
This issue seems to be affected by
(a) The size of the bit field; <= 32 bits works, > 32 bits breaks.
(b) Whether the bitfield is used in an expression producing a temporary;
>32-bit size AND a temporary breaks, <= 32-bit size and an lvalue works.
I confirmed this behavior on x86-64 gcc trunk using godbolt.org. (link again:
https://godbolt.org/g/brhTMw)
[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784 Paolo Carlini changed: What|Removed |Added Keywords|error-recovery, |ice-on-valid-code |ice-on-invalid-code | Summary|[6/7/8 Regression] ICE on |[6/7/8 Regression] ICE on |invalid code in |valid code in |push_access_scope, at |push_access_scope, at |cp/pt.c:229 |cp/pt.c:229 --- Comment #14 from Paolo Carlini --- Thus Comment #11 contains valid code.
[Bug c++/84516] bitfield temporaries > 32-bits have wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84516
--- Comment #1 from Greg Miller ---
The issue is not related to iostream. So, here's perhaps a simpler reproduction
example that may focus more on the issue at hand.
Link: https://godbolt.org/g/vA2rPN
struct A {
long x : 32;
long y : 33;
};
void F(int) {}
void F(long) {}
template
void F(T) = delete;
int main() {
A a;
F(a.x); // Calls F(long)
F(+a.x); // Calls F(int)
F(a.y); // Calls F(long)
F(+a.y); // error: use of deleted function 'void F(T) [with T = long
int:33]'
}
Here we can see that the type of the expression `+a.y` is `long int:33`, which
I suspect is a problem. I think the type of that expression should be `long
int`.
[Bug tree-optimization/84515] missed optimization: expected loop merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84515 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-22 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #28 from Janne Blomqvist --- Author: jb Date: Thu Feb 22 16:14:21 2018 New Revision: 257903 URL: https://gcc.gnu.org/viewcvs?rev=257903&root=gcc&view=rev Log: PR 78534, 84509 Fix libgfortran API for PAUSE statement This patch changes the libgfortran API for the PAUSE statement. By passing a GFC_INTEGER_8 it handles -fdefault-integer-8, and for the character version passing the length as a size_t. Regtested on x86_64-pc-linux-gnu, committed as obvious. gcc/fortran/ChangeLog: 2018-02-22 Janne Blomqvist PR 78534 PR 84509 * trans-decl.c (gfc_build_builtin_function_decls): Pass gfc_int8_type node to pause_numeric, size_type_node to pause_string. * trans-stmt.c (gfc_trans_pause): Likewise. libgfortran/ChangeLog: 2018-02-22 Janne Blomqvist PR 78534 PR 84509 * runtime/pause.c (pause_numeric): Modify to take GFC_INTEGER_8 argument. (pause_string): Modify to take size_t character length argument. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-stmt.c trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/pause.c
[Bug fortran/84509] STOP and PAUSE statements with -fdefault-integer-8 and large stop code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509 --- Comment #2 from Janne Blomqvist --- Author: jb Date: Thu Feb 22 16:14:21 2018 New Revision: 257903 URL: https://gcc.gnu.org/viewcvs?rev=257903&root=gcc&view=rev Log: PR 78534, 84509 Fix libgfortran API for PAUSE statement This patch changes the libgfortran API for the PAUSE statement. By passing a GFC_INTEGER_8 it handles -fdefault-integer-8, and for the character version passing the length as a size_t. Regtested on x86_64-pc-linux-gnu, committed as obvious. gcc/fortran/ChangeLog: 2018-02-22 Janne Blomqvist PR 78534 PR 84509 * trans-decl.c (gfc_build_builtin_function_decls): Pass gfc_int8_type node to pause_numeric, size_type_node to pause_string. * trans-stmt.c (gfc_trans_pause): Likewise. libgfortran/ChangeLog: 2018-02-22 Janne Blomqvist PR 78534 PR 84509 * runtime/pause.c (pause_numeric): Modify to take GFC_INTEGER_8 argument. (pause_string): Modify to take size_t character length argument. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-stmt.c trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/pause.c
[Bug target/79926] i386: untranslated placeholder "exception/interrupt" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79926 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, easyhack, patch CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79868 Severity|normal |trivial --- Comment #2 from Eric Gallager --- (In reply to David Malcolm from comment #1) > Candidate patch: > https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00446.html This was reviewed as "ok with changes"
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to niXman from comment #10) > (In reply to Jonathan Wakely from comment #9) > > There's a patch at https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html > > > > I haven't reviewed or tested it yet. > > https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00772.html > > Tested on i686/x86_64-MinGW-W64 and x86_64-linux-gnu. Adding "patch" keyword
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964
Jakub Jelinek changed:
What|Removed |Added
CC||carll at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
I guess this regressed with r253238 when these builtins were introduced.
I actually see multiple issues with these builtins:
1) as written above, lrintsfsi2 condition is TARGET_SF_FPR && TARGET_FPRND,
ditto lrintsfdi2 and lrintdfdi2 condition is TARGET_DF_FPR && TARGET_FPRND.
The builtins def file says just RS6000_BTM_HARD_FLOAT as the requirement, which
isn't enough, we also need TARGET_FPRND and for one of the builtins
TARGET_SF_FPR, for the other TARGET_DF_FPR. Changing
BU_FP_MISC_1 to require even (RS6000_BTM_HARD_FLOAT | RS6000_BTM_CELL)
doesn't work, then the builtin is refused on all CPUs but -mcpu=cell.
So, do we need to introduce two new RS6000_BTM_* values for these two builtins
and arrange for the right tests for them to be done?
2) with -mcpu=power6 or -mcpu=power7
long
f1 (float x)
{
return __builtin_fctid (x);
}
long
f2 (double x)
{
return __builtin_fctid (x);
}
int
f3 (float x)
{
return __builtin_fctiw (x);
}
int
f4 (double x)
{
return __builtin_fctiw (x);
}
ICEs in LRA instead:
pr83964.c: In function ‘f3’:
pr83964.c:24:1: error: unable to generate reloads for:
}
^
(insn 7 6 8 2 (set (reg:SI 124)
(unspec:SI [
(reg:DF 121 [ _1 ])
] UNSPEC_FCTIW)) "pr83964.c":23 419 {lrintsfsi2}
(expr_list:REG_DEAD (reg:DF 121 [ _1 ])
(nil)))
during RTL pass: reload
pr83964.c:24:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3884
0xdc05c5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
Either the rs6000 builtins expansion code for __builtin_fctiw float_truncate
the operand so that it is SFmode rather than DFmode, or it shouldn't use
lrintsf* code, but some other for an expander that adds the float_truncate.
What is the point of these builtins, i.e. what is the advantage of them over a
C cast from float or double to int or long?
[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80092 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #10 from Eric Gallager --- Have all of the changes committed from this bug fixed it?
[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW --- Comment #11 from Segher Boessenkool --- I rebuilt everything, and it still does not break at all.
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #5 from Jakub Jelinek --- The ICE is with -m64 -mcpu=power6 -O0.
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #6 from Jakub Jelinek --- Seems any -O* level with -mcpu=power6 or -mcpu=power7 actually.
[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80092 --- Comment #11 from Tom de Vries --- (In reply to Eric Gallager from comment #10) > Have all of the changes committed from this bug fixed it? No, I'm preparing some changes for stage1.
[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551 --- Comment #12 from Segher Boessenkool --- It does break if I set the breakpoints before the shared libs have loaded. Thread 3 "a.out" hit Breakpoint 1, 0x3fffb6e0c860 in .__memset_power7 () from /lib64/libc.so.6 #0 0x3fffb6e0c860 in .__memset_power7 () from /lib64/libc.so.6 #1 0x3fffb7055b10 in __interceptor_memset (dst=0x100201f0 , v=, size=40) at /home/segher/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:709 #2 0x3fffb6f9f2b0 in .pthread_mutex_init () from /lib64/libpthread.so.0 #3 0x3fffb704d58c in __interceptor_pthread_mutex_init ( m=0x100201f0 , a=0x0) at /home/segher/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:1132 #4 0x1dc4 in .Thread1 () #5 0x3fffb7049454 in __tsan_thread_start_func (arg=0x3fffeda0) at /home/segher/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:905 #6 0x3fffb6f9c95c in .start_thread () from /lib64/libpthread.so.0 #7 0x3fffb6e83bbc in .__clone () from /lib64/libc.so.6
[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 --- Comment #5 from Steve Ellcey --- Author: sje Date: Thu Feb 22 17:06:31 2018 New Revision: 257907 URL: https://gcc.gnu.org/viewcvs?rev=257907&root=gcc&view=rev Log: 2018-02-22 Steve Ellcey PR target/83335 * config/aarch64/aarch64.c (aarch64_print_address_internal): Change gcc_assert call to output_operand_lossage. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 --- Comment #6 from Steve Ellcey --- Author: sje Date: Thu Feb 22 17:08:10 2018 New Revision: 257908 URL: https://gcc.gnu.org/viewcvs?rev=257908&root=gcc&view=rev Log: 2018-02-22 Steve Ellcey PR target/83335 * gcc/testsuite/gcc.target/aarch64/asm-2.c: Add dg-error for ILP32 mode. * gcc/testsuite/gcc.target/aarch64/asm-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/asm-4.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/asm-2.c
[Bug c++/80955] Macros expanded in definition of user-defined literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955
--- Comment #6 from Jonathan Wakely ---
Testing this:
--- a/libcpp/lex.c
+++ b/libcpp/lex.c
@@ -1903,7 +1903,7 @@ lex_raw_string (cpp_reader *pfile, cpp_token *token,
const uchar *base,
literal thus breaking the program.
Try to identify macros with is_macro. A warning is issued.
The macro name should not start with '_' for this warning. */
- if ((*cur != '_') && is_macro (pfile, cur))
+ if ((*cur != '_' || cur[1] == '_') && is_macro (pfile, cur))
{
/* Raise a warning, but do not consume subsequent tokens. */
if (CPP_OPTION (pfile, warn_literal_suffix) &&
!pfile->state.skipping)
@@ -2034,7 +2034,7 @@ lex_string (cpp_reader *pfile, cpp_token *token, const
uchar *base)
literal thus breaking the program.
Try to identify macros with is_macro. A warning is issued.
The macro name should not start with '_' for this warning. */
- if ((*cur != '_') && is_macro (pfile, cur))
+ if ((*cur != '_' || cur[1] == '_') && is_macro (pfile, cur))
{
/* Raise a warning, but do not consume subsequent tokens. */
if (CPP_OPTION (pfile, warn_literal_suffix) &&
!pfile->state.skipping)
[Bug target/84176] Need a different thunk for -mindirect-branch=thunk-extern -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84176 --- Comment #1 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Feb 22 17:09:06 2018 New Revision: 257909 URL: https://gcc.gnu.org/viewcvs?rev=257909&root=gcc&view=rev Log: i386: Add __x86_indirect_thunk_nt_reg for -fcf-protection -mcet nocf_check attribute can be used with -fcf-protection -mcet to disable control-flow check by adding NOTRACK prefix before indirect branch. When -mindirect-branch=thunk-extern -mindirect-branch-register is added, indirect branch via register, "notrack call/jmp reg", is converted to call/jmp __x86_indirect_thunk_nt_reg When running on machines with CET enabled, __x86_indirect_thunk_nt_reg can be updated to notrack jmp reg at run-time to restore NOTRACK prefix in the original indirect branch. Since we don't support -mindirect-branch=thunk-extern, CET and MPX at the same time, -mindirect-branch=thunk-extern is disallowed with -fcf-protection=branch and -fcheck-pointer-bounds. Tested on i686 and x86-64. gcc/ PR target/84176 * config/i386/i386.c (ix86_set_indirect_branch_type): Issue an error when -mindirect-branch=thunk-extern, -fcf-protection=branch and -fcheck-pointer-bounds are used together. (indirect_thunk_prefix): New enum. (indirect_thunk_need_prefix): New function. (indirect_thunk_name): Replace need_bnd_p with need_prefix. Use "_nt" instead of "_bnd" for NOTRACK prefix. (output_indirect_thunk): Replace need_bnd_p with need_prefix. (output_indirect_thunk_function): Likewise. (): Likewise. (ix86_code_end): Update output_indirect_thunk_function calls. (ix86_output_indirect_branch_via_reg): Replace ix86_bnd_prefixed_insn_p with indirect_thunk_need_prefix. (ix86_output_indirect_branch_via_push): Likewise. (ix86_output_function_return): Likewise. * doc/invoke.texi: Document -mindirect-branch=thunk-extern is incompatible with -fcf-protection=branch and -fcheck-pointer-bounds. gcc/testsuite/ PR target/84176 * gcc.target/i386/indirect-thunk-11.c: New test. * gcc.target/i386/indirect-thunk-12.c: Likewise. * gcc.target/i386/indirect-thunk-attr-12.c: Likewise. * gcc.target/i386/indirect-thunk-attr-13.c: Likewise. * gcc.target/i386/indirect-thunk-attr-14.c: Likewise. * gcc.target/i386/indirect-thunk-attr-15.c: Likewise. * gcc.target/i386/indirect-thunk-attr-16.c: Likewise. * gcc.target/i386/indirect-thunk-extern-10.c: Likewise. * gcc.target/i386/indirect-thunk-extern-8.c: Likewise. * gcc.target/i386/indirect-thunk-extern-9.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-11.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-12.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-12.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-13.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-14.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-15.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-16.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-10.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-8.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/84196] invalid call to a function template with a vector argument silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84196
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Known to work|4.7.4 |
Target Milestone|6.5 |---
Summary|[6/7/8 Regression] invalid |invalid call to a function
|call to a function template |template with a vector
|with a vector argument |argument silently accepted
|silently accepted |
--- Comment #2 from Jakub Jelinek ---
Which means this really is not a regression.
If you replace the v[0] + v[1] + v[2] + v[3] part that is only accepted
starting from r186994, it will be accepts-invalid all the way to the
introduction of vector_size attribute.
The clang++ error looks bogus as well, there is no reason why I can't do:
template
int f (T x)
{
T __attribute__((vector_size (16))) v = { x };
v[0] += 1;
...
return v[0];
}
int x = f (5);
What doesn't work is that 1) we don't really have mangling for template
parameter with attributes on it 2) something else is broken for parameter
passing of these, e.g.
template
int f (T v __attribute__ ((vector_size (16
{
return 0;
}
int main ()
{
return f ((int __attribute__ ((vector_size (16 { 1, 2, 3, 4} );
}
where we really don't need deduction fails too and 3) deduction doesn't work
with these. So, I think we should instead reject just what we can't support
and sorry about stuff we don't want to support right now.
[Bug c++/80955] Macros expanded in definition of user-defined literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955 --- Comment #7 from Jonathan Wakely --- Moved to PR 84517
[Bug preprocessor/84517] New: [8 Regression] "string literal"__FILE__ no longer accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84517
Bug ID: 84517
Summary: [8 Regression] "string literal"__FILE__ no longer
accepted
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
const char* err() { return "Error in "__FILE__; }
With GCC 7 this gave a warning:
file.cc:1:28: warning: invalid suffix on literal; C++11 requires a space
between literal and string macro [-Wliteral-suffix]
const char* err() { return "Error in "__FILE__; }
^
But GCC 8 now rejects it:
file.cc: In function ‘const char* err()’:
file.cc:1:28: error: unable to find string literal operator
‘operator""__FILE__’ with ‘const char [10]’, ‘long unsigned int’ arguments
const char* err() { return "Error in "__FILE__; }
^~~
This was caused by r254443 for PR 80955
I'm not going to add the "rejects-valid" keyword, because technically the code
is invalid, but we accept it as an extension because there is no matching UDL.
[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #17 from Martin Liška --- (In reply to Felix Fietkau from comment #16) > Any update on this, or any way I could help in getting this fixed? > It would be nice if we could finally switch OpenWrt to a more recent GCC > version soon. I would like to really help you. But it's really problematic to have a mips qemu machine with working network. Having that I would be able to run e.g. https://people.debian.org/~aurel32/qemu/mips/ and I would be able to debug that locally. Any help how to play with?
[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #18 from Laurent GUERBY --- Marxin, you have a cfarm account and access to gcc22 / 23 / 24 which are mips64 machines. If you need to change ssh keys see here: https://cfarm.tetaneutral.net/login/
[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 --- Comment #4 from Martin Sebor --- Author: msebor Date: Thu Feb 22 17:35:29 2018 New Revision: 257910 URL: https://gcc.gnu.org/viewcvs?rev=257910&root=gcc&view=rev Log: PR tree-optimization/84480 - bogus -Wstringop-truncation despite assignment with an inlined string literal gcc/ChangeLog: PR tree-optimization/84480 * gimple-fold.c (gimple_fold_builtin_strcpy): Move warnings to maybe_diag_stxncpy_trunc. Call it. * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Integrate warnings from gimple_fold_builtin_strcpy. Print inlining stack. (handle_builtin_stxncpy): Print inlining stack. * tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Declare. gcc/testsuite/ChangeLog: PR tree-optimization/84480 * c-c++-common/Wstringop-truncation.c: Adjust text of expected warnings. * g++.dg/warn/Wstringop-truncation-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wstringop-truncation-1.C trunk/gcc/tree-ssa-strlen.h Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wstringop-truncation.c trunk/gcc/tree-ssa-strlen.c
[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 --- Comment #6 from Romain Geissler --- Thanks ;)
[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82851 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Can't reproduce it here, both on x86_64-linux and i686-linux I see PASS: gcc.target/i386/avx2-vpaddq-3.c scan-assembler-times vpaddq[ \\t]+[^\n]*%ymm[0-9] 1 PASS: gcc.target/i386/avx2-vpsubq-3.c scan-assembler-times vpsubq[ \\t]+[^\n]*%ymm[0-9] 1 Any special --with-arch/--with-tune you're using? My builds are just ../configure --enable-languages=default,ada,obj-c++,lto,go,brig --enable-checking=yes,rtl,extra for x86_64-linux and ../configure --enable-languages=default,obj-c++,lto,go,brig --enable-checking=yes,rtl,extra for i686-linux.
[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- Fixed in r257910.
[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82851 --- Comment #6 from Jakub Jelinek --- Ah, I can reproduce with -mtune=silvermont or -mtune=atom, it works fine with -mtune=generic or e.g. -mtune=silvermont -fno-vect-cost-model. I'd just add -mtune=generic to the 2 test's dg-options.
[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Known to fail||8.0 --- Comment #3 from kargl at gcc dot gnu.org --- Assign to Jerry per his request.
[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Dominique d'Humieres --- > Assign to Jerry per his request. So moved status to ASSIGN.
[Bug c++/84518] New: [8 Regression] ICE with lambda capturing broken variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84518
Bug ID: 84518
Summary: [8 Regression] ICE with lambda capturing broken
variable
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid testcase triggers an ICE on trunk:
template void foo()
{
int x[=];
[&x]{};
}
void bar()
{
foo<0>();
}
bug.cc: In function 'void foo()':
bug.cc:3:9: error: expected primary-expression before '=' token
int x[=];
^
bug.cc:3:10: error: expected primary-expression before ']' token
int x[=];
^
bug.cc: In instantiation of 'void foo() [with int = 0]':
bug.cc:9:10: required from here
bug.cc:4:3: internal compiler error: tree check: expected class 'expression',
have 'exceptional' (error_mark) in tree_operand_check, at tree.h:3630
[&x]{};
^
0x78a846 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9385
0x614d34 expr_check(tree_node*, char const*, int, char const*)
../../gcc/gcc/tree.h:3301
0x614d34 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/gcc/tree.h:3630
0x614d34 build_capture_proxy(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:447
0x8d8596 start_lambda_function(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:1374
0x95a004 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17080
0x95a9e2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18368
0x969349 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17130
0x969349 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16862
0x968ce0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16079
0x9683c9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16065
0x966481 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16346
0x965718 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16050
0x965718 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23406
0x98b7ab instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23522
0x8b1cab c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4720
Please submit a full bug report, [etc.]
The regression was introduced between 2017-09-26 and 2017-10-07.
[Bug fortran/84519] New: STOP and ERROR STOP statements with QUIET specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84519 Bug ID: 84519 Summary: STOP and ERROR STOP statements with QUIET specifier Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- In F2018 the STOP and ERROR STOP statements take and extra QUIET= specifier, a logical value determining whether any information should be printed to the screen or not. For GCC 8, it would be good to have this in the library API even though the parsing could well be postponed to a later release.
[Bug c++/84518] [8 Regression] ICE with lambda capturing broken variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84518
--- Comment #1 from Volker Reichelt ---
A modified testcase produces a slightly different stack-trace:
template void foo()
{
T x[=];
[&x]{};
}
bug.cc: In function 'void foo()':
bug.cc:3:7: error: expected primary-expression before '=' token
T x[=];
^
bug.cc:3:8: error: expected primary-expression before ']' token
T x[=];
^
bug.cc: In lambda function:
bug.cc:4:6: internal compiler error: in is_normal_capture_proxy, at
cp/lambda.c:289
[&x]{};
^
0x614602 is_normal_capture_proxy(tree_node*)
../../gcc/gcc/cp/lambda.c:289
0x8d4918 is_capture_proxy_with_ref(tree_node*)
../../gcc/gcc/cp/lambda.c:301
0x8d49ad insert_capture_proxy(tree_node*)
../../gcc/gcc/cp/lambda.c:311
0x8d546f build_capture_proxy(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:474
0x8d8596 start_lambda_function(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:1374
0x91daad cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:10662
0x91daad cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10182
0x91daad cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5257
0x93043c cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7026
0x931010 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91139f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
0x911baa cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x9133e4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9482
0x913af8 cp_parser_expression
../../gcc/gcc/cp/parser.c:9651
0x9157b8 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:8
0x91bb2d cp_parser_statement
../../gcc/gcc/cp/parser.c:10922
0x91d040 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d117 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933890 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933890 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
Please submit a full bug report, [etc.]
[Bug c++/80955] Macros expanded in definition of user-defined literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955 --- Comment #8 from Jonathan Wakely --- Also the new testcase for this bug has undefined behaviour. _ID is a reserved name so the program cannot use it to define a macro or a UDL.
[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982 Will Schmidt changed: What|Removed |Added CC||willschm at gcc dot gnu.org --- Comment #4 from Will Schmidt --- Tried to re-create locally, I've gotten two ICE's using the provided testcode snippet, neither look quite like the originally reported issue. (thus I don't know if this is actually the same issue). Neither of these require the -fgraphite-identity option be specified. -m32 or -m64 doesn't seem to matter for me. Target: powerpc64-unknown-linux-gnu Configured with: /home/willschm/gcc/gcc-mainline-regtest_patches/configure --enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7 --with-long-double-128 --prefix=/home/willschm/gcc/install/gcc-mainline-regtest_patches --disable-bootstrap --with-isl --with-graphite : (reconfigured) /home/willschm/gcc/gcc-mainline-regtest_patches/configure --enable-languages=c,c++ --with-cpu=power7 --with-long-double-128 --prefix=/home/willschm/gcc/install/gcc-mainline-regtest_patches --disable-bootstrap --with-isl --with-graphite # with -O2. > $GCC_INSTALL/bin/gcc ./pr82982.c -c -O2 -m32 during GIMPLE pass: store-merging ./pr82982.c: In function ‘km’: ./pr82982.c:4:1: internal compiler error: Segmentation fault km (void) ^~ 0x10f75447 crash_signal /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/toplev.c:325 # with -O3. > $GCC_INSTALL/bin/gcc ./pr82982.c -c -O3 during IPA pass: cp ./pr82982.c:31:1: internal compiler error: Segmentation fault } ^ 0x10f75447 crash_signal /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/toplev.c:325 0x103de084 tree_check(tree_node*, char const*, int, char const*, tree_code) /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/tree.h:3131 0x10da9e77 opts_for_fn /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/tree.h:5319 0x10dbe04b cgraph_node::optimize_for_size_p() /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/cgraph.h:3152 0x11e50afb ipcp_cloning_candidate_p /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:709 0x11e50ef3 initialize_node_lattices /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:1177 0x11e5df7b ipcp_propagate_stage /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:3284 0x11e5e317 ipcp_driver /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:5026 0x11e5e3ff execute /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:5120
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #7 from Segher Boessenkool --- We actually do *not* need TARGET_FPRND; fctiw and fctid are ISA 1.xx insns. Before power8 we do not allow putting SImode in FPRs.
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- I'll handle it.
[Bug c++/84520] New: [6/7/8 Regression] ICE with lambda and static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84520
Bug ID: 84520
Summary: [6/7/8 Regression] ICE with lambda and static member
function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following valid testcase triggers an ICE since GCC 5.1.0.
It was compiled without problems in GCC 4.9.x.
struct A
{
static void foo(int);
void (*f)(int) = [](auto i) { foo(i); };
};
bug.cc: In instantiation of 'A:: [with auto:1 = int]':
bug.cc:4:29: required by substitution of 'template
Aoperator decltype
(((A::)0u).operator()(i)) (*)(auto:1)() const [with auto:1 =
int]'
bug.cc:4:41: required from here
bug.cc:4:36: internal compiler error: in lambda_expr_this_capture, at
cp/lambda.c:697
void (*f)(int) = [](auto i) { foo(i); };
^
0x83f04c lambda_expr_this_capture(tree_node*, bool)
../../gcc-5.1.0/gcc/cp/lambda.c:695
0x83f387 maybe_resolve_dummy(tree_node*, bool)
../../gcc-5.1.0/gcc/cp/lambda.c:789
0x6485a1 build_new_method_call_1
../../gcc-5.1.0/gcc/cp/call.c:8027
0x6485a1 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-5.1.0/gcc/cp/call.c:8275
0x7cd9ef finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-5.1.0/gcc/cp/semantics.c:2367
0x6b536f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-5.1.0/gcc/cp/pt.c:15211
0x6a2a85 tsubst_expr
../../gcc-5.1.0/gcc/cp/pt.c:14398
0x6a39b2 tsubst_expr
../../gcc-5.1.0/gcc/cp/pt.c:13809
0x6a25fb tsubst_expr
../../gcc-5.1.0/gcc/cp/pt.c:13981
0x6a25fb tsubst_expr
../../gcc-5.1.0/gcc/cp/pt.c:13981
0x6a0774 instantiate_decl(tree_node*, int, bool)
../../gcc-5.1.0/gcc/cp/pt.c:20407
0x7219f8 mark_used(tree_node*, int)
../../gcc-5.1.0/gcc/cp/decl2.c:5029
0x63d88a build_over_call
../../gcc-5.1.0/gcc/cp/call.c:7489
0x64889e build_new_method_call_1
../../gcc-5.1.0/gcc/cp/call.c:8205
0x64889e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-5.1.0/gcc/cp/call.c:8275
0x6b5fe2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-5.1.0/gcc/cp/pt.c:15205
0x6aac9e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-5.1.0/gcc/cp/pt.c:12530
0x6b0a5f tsubst_function_type
../../gcc-5.1.0/gcc/cp/pt.c:11624
0x6ab365 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-5.1.0/gcc/cp/pt.c:12357
0x6aac06 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-5.1.0/gcc/cp/pt.c:11899
Please submit a full bug report, [etc.]
[Bug target/84521] New: [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 Bug ID: 84521 Summary: [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org CC: jgreenhalgh at gcc dot gnu.org, marcus.shawcroft at arm dot com, rearnsha at gcc dot gnu.org, wilco at gcc dot gnu.org Target Milestone: --- Host: aarch64-unknown-linux-gnu Target: aarch64-unknown-linux-gnu Build: aarch64-unknown-linux-gnu The downstream bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=1545239 describes a problem seen on aarch64 with gcc 8 that breaks the build of Ruby at -O1 and above. Bisection shows that the problem started with r254815, which made -fomit-frame-pointer the default. Jakub reported: > It is actually much older, I get the same crash if vm.c is compiled with > -mlittle-endian -mabi=lp64 -g -grecord-gcc-switches -O1 -Wall > -Werror=format-security > -fexceptions -fPIC -fstack-protector -fno-strict-overflow > -fexcess-precision=standard -fomit-frame-pointer > with r204770, so already GCC 4.9 behaves that way too. > Note ruby uses -fno-omit-frame-pointer already, but only on mingw32. The issue is that the code generated for __builtin_longjmp reads a value for x29 (the frame pointer) from the jmp_buf, but the code generated for __builtin_setjmp doesn't actually write x29 to the jmp_buf, leading to corruption of x29 when a longjmp occurs. This corruption seems to be short-lived when -fno-omit-frame-pointer (the old default), as every function restores x29 from the stack on exit. With the new default of -fomit-frame-pointer the corruption can survive long enough to cause crashes. There's a lot more analysis at the downstream bug report in the URL above. I'm about to attach a reproducer. I'm marking this as "[8 Regression]" since although this is appears to be a long-standing bug, the change of default in r254815 exposes it by default.
[Bug c++/70468] [6/7/8 Regression] ICE on invalid code on x86_64-linux-gnu in emit_mem_initializers, at cp/init.c:1109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70468 --- Comment #6 from Jakub Jelinek --- clang++ errors here are on #c0: pr70468.C:6:10: error: type 'A::f0' (aka 'A<>') is not a direct or virtual base of 'A' and on #c2: pr70468-2.C:5:10: error: type 'A::f0' (aka 'A<>') is not a direct or virtual base of 'A'
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 --- Comment #1 from David Malcolm --- Created attachment 43489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43489&action=edit Reproducer When compiled with: gcc -DDUMP -g -O0 -fstack-protector-strong -Wall test.c this runs to completion, and the x29 values show the function calls/returns: x29 = 0x7ff2977910 : main : start of main x29 = 0x7ff29778d0 : test_2 : start of test_2 x29 = 0x7ff29776a0 : test_1 : start of test_1 x29 = 0x7ff29776a0 : test_1 : zero return x29 = 0x7ff2977690 : uses_longjmp : in uses_longjmp x29 = 0x7ff2977740 : test_1 : non-zero return x29 = 0x7ff2977690 : after_longjmp : after raise x29 = 0x7ff2977740 : test_1 : end of test_1 x29 = 0x7ff29778d0 : test_2 : end of test_2 x29 = 0x7ff2977910 : main : end of main On adding -fomit-frame-pointer, it crashes, and the x29 values show a corruption after "uses_longjmp" which becomes a crash when the x29 value is later used: x29 = 0x7fff4709c0 : main : start of main x29 = 0x7fff470960 : test_2 : start of test_2 x29 = 0x7fff470960 : test_1 : start of test_1 x29 = 0x7fff470960 : test_1 : zero return x29 = 0x7fff470720 : uses_longjmp : in uses_longjmp x29 = 0x7fff4707d0 : test_1 : non-zero return x29 = 0x7fff4707d0 : after_longjmp : after raise x29 = 0x7fff4707d0 : test_1 : end of test_1 x29 = 0x7fff4707d0 : test_2 : end of test_2 *** stack smashing detected ***: ./test-O0-omit-fp terminated
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 James Greenhalgh changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-22 CC||ramana.radhakrishnan at arm dot co ||m Ever confirmed|0 |1 --- Comment #2 from James Greenhalgh --- It is a bug that we have changed to -fomit-frame-pointer by default for AArch64. That changes a long standing ABI decision made at the dawn of the port, and promised as a feature of the architecture. I would like to see this fixed for GCC 8. Ramana was testing a patch to fix this and change us back to -fno-omit-frame-pointer, it (or someone else's patch achieving the same) would be appreciated as the immediate fix for this issue. I haven't validated the longer-term problem you mention with -fomit-frame-pointer. Ramana, can you pick this up and set us back to the appropriate default? Otherwise, I can spin a patch. We should fix this urgently, or we miss the good value that comes from whole-distribution testing.
[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Thu Feb 22 18:52:21 2018 New Revision: 257912 URL: https://gcc.gnu.org/viewcvs?rev=257912&root=gcc&view=rev Log: 2018-02-22 Thomas Koenig PR fortran/81116 PR fortran/84495 Backport from trunk * frontend-passes.c (realloc_string_callback): If expression is a concatenation, also check for dependency. (constant_string_length): Check for presence of symtree. 2018-02-22 Thomas Koenig PR fortran/81116 PR fortran/84495 * gfortran.dg/realloc_on_assignment_29.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_29.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/frontend-passes.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/81116] Last character of allocatable-length string reset to blank in an assigment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81116 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Thu Feb 22 18:52:21 2018 New Revision: 257912 URL: https://gcc.gnu.org/viewcvs?rev=257912&root=gcc&view=rev Log: 2018-02-22 Thomas Koenig PR fortran/81116 PR fortran/84495 Backport from trunk * frontend-passes.c (realloc_string_callback): If expression is a concatenation, also check for dependency. (constant_string_length): Check for presence of symtree. 2018-02-22 Thomas Koenig PR fortran/81116 PR fortran/84495 * gfortran.dg/realloc_on_assignment_29.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_29.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/frontend-passes.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Thomas Koenig --- Backported the patch due to overwhelming popular demand :-) This really is a duplicate, closing the patch as such. *** This bug has been marked as a duplicate of bug 81116 ***
[Bug fortran/81116] Last character of allocatable-length string reset to blank in an assigment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81116 Thomas Koenig changed: What|Removed |Added CC||david.sagan at gmail dot com --- Comment #7 from Thomas Koenig --- *** Bug 84495 has been marked as a duplicate of this bug. ***
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 David Malcolm changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug c++/70468] [6/7/8 Regression] ICE on invalid code on x86_64-linux-gnu in emit_mem_initializers, at cp/init.c:1109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70468 --- Comment #7 from Jakub Jelinek --- It is the expand_member_init's current_template_parms check that matters here, with - if (current_template_parms - || same_type_p (basetype, current_class_type)) - return basetype; + if (/* current_template_parms + || */same_type_p (basetype, current_class_type)) + return basetype; both testcases from this PR are properly rejected and no ICEs. That breaks other stuff though, like: /usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:134:9: error: type '__gnu_cxx::new_allocator<_Tp>' is not a direct base of 'std::allocator< >' /usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:146:4: error: type 'typename __gnu_cxx::__alloc_traits<_Alloc>::rebind<_CharT>::other' is not a direct base of 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_Alloc_hider' /usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:149:4: error: type 'typename __gnu_cxx::__alloc_traits<_Alloc>::rebind<_CharT>::other' is not a direct base of 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_Alloc_hider'
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 --- Comment #3 from Andrew Pinski --- To me any use of __builtin_setjmp/__builtin_longjmp is almost always incorrect.
[Bug fortran/84519] STOP and ERROR STOP statements with QUIET specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84519 Janne Blomqvist changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #1 from Janne Blomqvist --- Working on a patch, assigning to myself.
[Bug fortran/84511] [6/7/8 Regression] Internal compiler error from directly printing return of C_LOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84511 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- I have a patch.
[Bug middle-end/21161] [6/7/8 Regression] "clobbered by longjmp" warning ignores the data flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #12 from Jeffrey A. Law --- I've got something that is working on most targets. I'm still refining a bit, but I'm pretty confident we'll be able to fix in this cycle. As expected scanning RTL from the setjmp point to figure out where the longjmp will go (so that we can use the live-in set at the longjmp target rather than the live set at the setjmp point) is a bit hairy. It's almost certainly the case that the scanning is not going to work on all targets. For example MIPS inserts an unspec sequence to fiddle the GOT after the call and I really don't want to ignore an insn we don't understand. But again, what I've currently got works on most targets and there's still some refinements to do to improve coverage.
[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
--- Comment #4 from Jakub Jelinek ---
Is the requirement just for functions that contain setjmp? If so, the backend
could just force frame pointers in cfun->calls_setjmp functions.
If not, even if the default is tweaked again to be -fno-omit-frame-pointer on
aarch64, the code is still wrong with explicit -fno-omit-frame-pointer, even
before that change.
The test uses __builtin_setjmp, can't reproduce it when using normal setjmp,
so is it just __builtin_setjmp that requires frame pointers? I think we don't
really have a flag about uses of __builtin_setjmp right now, but it could be
added next to calls_setjmp (calls_builtin_setjmp). Marking the function with
__builtin_setjmp with __attribute__((optimize ("no-omit-frame-pointer"))) fixes
it too.
[Bug tree-optimization/84515] missed optimization: expected loop merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84515
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #2 from rsandifo at gcc dot gnu.org
---
count==1 might be the difficult case, since it's the only situation in which
the second loop does something but the first loop doesn't. But the code for:
void f2(unsigned count) {
unsigned i;
if (count <= 1) {
g += count;
} else {
for (i = 0; i < count/2; i++) g++;
for ( ; i < count ; i++) g++;
}
}
is also poor.
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |8.0
--- Comment #5 from Jakub Jelinek ---
--- gcc/config/aarch64/aarch64.c.jj 2018-02-22 09:26:12.028616476 +0100
+++ gcc/config/aarch64/aarch64.c2018-02-22 20:23:29.449621557 +0100
@@ -7432,6 +7432,20 @@ aarch64_secondary_reload (bool in_p ATTR
return NO_REGS;
}
+/* Value should be nonzero if functions must have frame pointers.
+ Zero means the frame pointer need not be set up (and parms may
+ be accessed via the stack pointer) in functions that seem suitable. */
+
+static bool
+aarch64_frame_pointer_required (void)
+{
+ /* __builtin_setjmp requries frame pointers. */
+ if (cfun->calls_setjmp)
+return true;
+
+ return false;
+}
+
static bool
aarch64_can_eliminate (const int from ATTRIBUTE_UNUSED, const int to)
{
@@ -17463,6 +17477,9 @@ aarch64_run_selftests (void)
#undef TARGET_CALLEE_COPIES
#define TARGET_CALLEE_COPIES hook_bool_CUMULATIVE_ARGS_mode_tree_bool_false
+#undef TARGET_FRAME_POINTER_REQUIRED
+#define TARGET_FRAME_POINTER_REQUIRED aarch64_frame_pointer_required
+
#undef TARGET_CAN_ELIMINATE
#define TARGET_CAN_ELIMINATE aarch64_can_eliminate
(completely untested) would require frame pointers for all setjmp calls, not
just __builtin_setjmp.
I agree pretty much all uses of __builtin_setjmp are a bug, but somebody needs
to explain it to the ruby authors. It is even weirder because they are using
the builtin with jmp_buf variable, jmp_buf is for the libc setjmp, for
__builtin_setjmp I think it is just void *buf[5]; or something similar.
BTW, does __builtin_return_address really work on aarch64 without frame
pointers? Various other targets require frame pointers when
cfun->machine->access_prev_frame (i.e. when SETUP_FRAME_ADDRESSES () has been
used).
[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 Steve Ellcey changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Steve Ellcey --- This should be fixed now.
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #17 from ian at gcc dot gnu.org --- Author: ian Date: Thu Feb 22 19:49:04 2018 New Revision: 257914 URL: https://gcc.gnu.org/viewcvs?rev=257914&root=gcc&view=rev Log: PR go/84484 libgo: add support for riscv64 Patch by Andreas Schwab. Reviewed-on: https://go-review.googlesource.com/96377 * go.test/go-test.exp (go-set-goarch): Recognize riscv64-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/go.test/go-test.exp trunk/libgo/configure trunk/libgo/configure.ac trunk/libgo/go/cmd/cgo/main.go trunk/libgo/go/go/build/syslist.go trunk/libgo/go/internal/syscall/unix/getrandom_linux_generic.go trunk/libgo/go/runtime/hash64.go trunk/libgo/go/runtime/lfstack_64bit.go trunk/libgo/go/runtime/unaligned1.go trunk/libgo/go/syscall/endian_little.go trunk/libgo/go/syscall/libcall_linux_ustat.go trunk/libgo/goarch.sh trunk/libgo/match.sh trunk/libgo/misc/cgo/testcshared/src/libgo2/dup2.go trunk/libgo/misc/cgo/testcshared/src/libgo2/dup3.go trunk/libgo/testsuite/gotest
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Ian Lance Taylor --- Thanks for the patch. I committed it.
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 --- Comment #9 from Carl Love --- This test case is in the list in PR 84422 . Working on a patch.
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 --- Comment #6 from Wilco --- (In reply to Jakub Jelinek from comment #5) > (completely untested) would require frame pointers for all setjmp calls, not > just __builtin_setjmp. That's the correct approach indeed, however aarch64_frame_pointer_required is no longer used, this now needs to added to aarch64_layout_frame: /* Force a frame chain for EH returns so the return address is at FP+8. */ cfun->machine->frame.emit_frame_chain = frame_pointer_needed || crtl->calls_eh_return; > BTW, does __builtin_return_address really work on aarch64 without frame > pointers? Various other targets require frame pointers when > cfun->machine->access_prev_frame (i.e. when SETUP_FRAME_ADDRESSES () has > been used). It only supports returning the return address of the current function (and even that is most likely a bug rather than useful). When level != 0 it always returns 0.
[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 --- Comment #7 from Jakub Jelinek --- cfun->has_nonlocal_label instead of cfun->calls_setjmp would cover __builtin_setjmp. aarch64_frame_pointer_required would force frame_pointer_needed and thus be true in that case too. But sure, if it works, we can change: /* Force a frame chain for EH returns so the return address is at FP+8. */ cfun->machine->frame.emit_frame_chain -= frame_pointer_needed || crtl->calls_eh_return; += frame_pointer_needed || crtl->calls_eh_return || cfun->has_nonlocal_label;
