[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #12 from Marc Glisse ---
(In reply to Qi Feng from comment #11)
> I tried 2 patterns for the following test
>
> /* 1. x > y && x != 0 --> x > y */
> /* 2. y < x && x != 0 --> y < x */
> /* 3. x != 0 && x > y --> x > y */
> /* 4. x != 0 && y < x --> y < x */
>
> _Bool f1 (unsigned x, unsigned y)
> {
> return x > y && x != 0;
> }
>
> _Bool f2 (unsigned x, unsigned y)
> {
> return y < x && x != 0;
> }
>
> _Bool f3 (unsigned x, unsigned y)
> {
> return x != 0 && x > y;
> }
>
> _Bool f4 (unsigned x, unsigned y)
> {
> return x != 0 && y < x;
> }
>
> The first one is
>
> (for and (truth_and bit_and)
> (simplify
> (and:c (gt:c@2 @0 @1) (ne @0 integer_zerop))
> (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@0))
>&& INTEGRAL_TYPE_P (TREE_TYPE(@1)) && TYPE_UNSIGNED
> (TREE_TYPE(@1)))
>@2)))
>
> The transformations did not happen as I checked the dump files of
> -fdump-tree-{original,optimized}.
It isn't supposed to be done in original anyway. It does work in optimized
(even forwprop1) for me. Did you forget to pass -O? Did you look at some old
dump file?
(I think you could use ANY_INTEGRAL_TYPE_P, this seems valid for vectors)
[Bug middle-end/90607] [10 regression] gcc.dg/pr53265.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90607 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-24 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Known to work||9.1.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Started with Richi's r271553.
[Bug sanitizer/90570] [9 Regression] AddressSanitizer: stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570 --- Comment #10 from Martin Liška --- Author: marxin Date: Fri May 24 07:44:15 2019 New Revision: 271594 URL: https://gcc.gnu.org/viewcvs?rev=271594&root=gcc&view=rev Log: Backport r271548 2019-05-24 Martin Liska Backport from mainline 2019-05-23 Martin Liska PR sanitizer/90570 * gimplify.c (gimplify_target_expr): Skip TREE_STATIC target expression similarly to gimplify_decl_expr. 2019-05-24 Martin Liska Backport from mainline 2019-05-23 Martin Liska PR sanitizer/90570 * g++.dg/asan/pr90570.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/asan/pr90570.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gimplify.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug sanitizer/90570] [9 Regression] AddressSanitizer: stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570 --- Comment #9 from Martin Liška --- Author: marxin Date: Fri May 24 07:43:48 2019 New Revision: 271593 URL: https://gcc.gnu.org/viewcvs?rev=271593&root=gcc&view=rev Log: Backport r271548 2019-05-24 Martin Liska Backport from mainline 2019-05-23 Martin Liska PR sanitizer/90570 * gimplify.c (gimplify_target_expr): Skip TREE_STATIC target expression similarly to gimplify_decl_expr. 2019-05-24 Martin Liska Backport from mainline 2019-05-23 Martin Liska PR sanitizer/90570 * g++.dg/asan/pr90570.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/asan/pr90570.C Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug sanitizer/90570] AddressSanitizer: stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.1.1 Resolution|--- |FIXED Summary|[9 Regression] |AddressSanitizer: |AddressSanitizer: |stack-use-after-scope |stack-use-after-scope | Known to fail|9.1.0 | --- Comment #11 from Martin Liška --- Fixed now.
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #13 from rguenther at suse dot de ---
On Fri, 24 May 2019, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
>
> --- Comment #12 from Marc Glisse ---
> (In reply to Qi Feng from comment #11)
> > I tried 2 patterns for the following test
> >
> > /* 1. x > y && x != 0 --> x > y */
> > /* 2. y < x && x != 0 --> y < x */
> > /* 3. x != 0 && x > y --> x > y */
> > /* 4. x != 0 && y < x --> y < x */
> >
> > _Bool f1 (unsigned x, unsigned y)
> > {
> > return x > y && x != 0;
> > }
> >
> > _Bool f2 (unsigned x, unsigned y)
> > {
> > return y < x && x != 0;
> > }
> >
> > _Bool f3 (unsigned x, unsigned y)
> > {
> > return x != 0 && x > y;
> > }
> >
> > _Bool f4 (unsigned x, unsigned y)
> > {
> > return x != 0 && y < x;
> > }
> >
> > The first one is
> >
> > (for and (truth_and bit_and)
> > (simplify
> > (and:c (gt:c@2 @0 @1) (ne @0 integer_zerop))
> > (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@0))
> >&& INTEGRAL_TYPE_P (TREE_TYPE(@1)) && TYPE_UNSIGNED
> > (TREE_TYPE(@1)))
> >@2)))
> >
> > The transformations did not happen as I checked the dump files of
> > -fdump-tree-{original,optimized}.
>
> It isn't supposed to be done in original anyway. It does work in optimized
> (even forwprop1) for me. Did you forget to pass -O? Did you look at some old
> dump file?
>
> (I think you could use ANY_INTEGRAL_TYPE_P, this seems valid for vectors)
I would have expected fold to first change the TRUTH_ANDIF to a
TRUTH_AND and then your pattern match. But maybe I misremember
that we have such transformation for cases where the 2nd operand
doesn't have side-effects.
While genmatch inserts checks for and rejects operands with side-effects
I still wouldn't use truth_andif here.
As Marc says, expecting the transform in .original is probably
premature. OTOH whether it is applicable on GIMPLE in the end might
depend on LOGICAL_OP_NON_SHORT_CIRCUIT and BRANCH_COST.
[Bug middle-end/90597] [9/10 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90597 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.2 Summary|FAIL: |[9/10 Regression] FAIL: |gcc.dg/attr-vector_size.c |gcc.dg/attr-vector_size.c |(internal compiler error) |(internal compiler error)
[Bug target/90599] Inefficient code for __builtin_memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90599 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-24 Component|middle-end |target Ever confirmed|0 |1
[Bug d/90601] ICE: gimplification failed (gimplify.c at 13436)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90601
--- Comment #1 from Richard Biener ---
Well, fix_trunc_expr isn't an lvalue you can pre-increment ... if D means
to pre-increment a temporary (and not a) then it has to say so explicitely.
Note GENERIC doesn't allow floating types on {PRE,POST}{DE,IN}CREMENT_EXPR
just in case D does.
A C compiler says the code is invalid C:
t.c: In function ‘f’:
t.c:3:12: error: lvalue required as increment operand
return ++(a += 1.0);
^
[Bug middle-end/90607] [10 regression] gcc.dg/pr53265.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90607 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I'll have a look.
[Bug target/90600] incompatible 64-bit-types in x86-intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600 --- Comment #6 from Jakub Jelinek --- In 325462 SDM vol 1-2abcd-3abcd in 3.1.1.10 Intel ® C/C++ Compiler Intrinsics Equivalents Section, it is actually written: "The declarations of Intel C/C++ compiler intrinsic functions may reference some non-standard data types, such as __int64. The C Standard header stdint.h defines similar platform-independent types, and the documentation for that header gives characteristics that apply to corresponding non-standard types according to the following table." __int64 int64_t unsigned __int64 uint64_t But I wonder how recent that section is (whether it hasn't been introduced years after GCC intrinsic headers made their choice).
[Bug fortran/90608] New: Inline masked minlo/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 Bug ID: 90608 Summary: Inline masked minlo/maxloc calls Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target Milestone: --- Created attachment 46402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46402&action=edit minloc example One of the benchmarks we care about performs much better when compiled with ifort than with gfortran. One of the differences seems to be due to ifort inlining calls to some minloc/maxloc intrinsics whereas gfortran emits calls to libgfortran, for example _gfortran_mminloc0_4_i4 to perform various minloc/maxloc operations combined with a mask over array sections. Inlining these intrinsics seems to enable further optimisations in the pipeline like vectorisation Attached is a small-but-representable standalone example of the kind of calls it would be good to inline. I'm not too familiar with Fortran and the frontend but it seems to inline some minloc/maxloc intrinsics already in trans-intrinsic.c. Would it be possible to beef it up?
[Bug middle-end/90607] [10 regression] gcc.dg/pr53265.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90607
Richard Biener changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
There's not really anything wrong here - we just diagnose things twice for
void
fn3 (void)
{
unsigned char a[16], b[16], c[16];
int i;
bar (b);
for (i = 0; i < (int) (sizeof (a) / sizeof (a[0])); i++) /* { dg-message
"note: within this loop" } */
{
c[i + 8] = b[i]; /* { dg-warning "8 invokes undefined behavior" } */
a[i + 8] = b[i + 8];
}
bar (a);
bar (c);
}
first we see
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c: In function
‘fn3’:
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c:40:16: warning:
iteration 8 invokes undefined behavior [-Waggressive-loop-optimizations]
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c:38:3: note:
within this loop
and then later, after loop-distribution makes undefined memcpy calls out
of this loop invoking undefined behavior we warn about that again:
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c: In function
‘fn3’:
cc1: warning: ‘__builtin_memcpy’ forming offset [17, 24] is out of the bounds
[0, 16] of object ‘c’ with type ‘unsigned char[16]’ [-Warray-bounds]
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c:34:31: note: ‘c’
declared here
cc1: warning: ‘__builtin_memcpy’ forming offset [17, 24] is out of the bounds
[0, 16] of object ‘a’ with type ‘unsigned char[16]’ [-Warray-bounds]
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c:34:17: note: ‘a’
declared here
generally warning about stmts with UNKNOWN_LOCATION isn't very helpful
(the generated memcpy calls fall under this category). We might want
to improve the location here (use the location of the stmt doing the store?).
With adjusting the location we see
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c:40:16: warning:
‘__builtin_memcpy’ forming offset [17, 24] is out of the bounds [0, 16] of
object ‘c’ with type ‘unsigned char[16]’ [-Warray-bounds]
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c:34:31: note: ‘c’
declared here
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c:41:16: warning:
‘__builtin_memcpy’ forming offset [17, 24] is out of the bounds [0, 16] of
object ‘a’ with type ‘unsigned char[16]’ [-Warray-bounds]
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/pr53265.c:34:17: note: ‘a’
declared here
which is of course nicer and can be tested for. I'll simply amend
the testcase.
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 --- Comment #14 from Qi Feng --- Checking .original and .optimized file is just a quick method I use to check whether an optimization happened (if not happen in first and last pass, probably it didn't happen). I didn't mean or think the transform should happen in these passes. Using the second pattern, the result of transform already showed in .original file, so I think it maybe happened earlier (like in GENERIC). And I tried the first pattern again using a totally clean debug build (bootstrap disabled), still didn't see the transformation happen. I don't know what went wrong. :( (I tested it on a ppc64le machine, don't know if that matters)
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #25 from Richard Biener --- Author: rguenth Date: Fri May 24 08:48:14 2019 New Revision: 271595 URL: https://gcc.gnu.org/viewcvs?rev=271595&root=gcc&view=rev Log: 2019-05-23 Richard Biener PR tree-optimization/88440 * opts.c (default_options_table): Enable -ftree-loop-distribute-patterns at -O[2s]+. * tree-loop-distribution.c (generate_memset_builtin): Fold the generated call. (generate_memcpy_builtin): Likewise. (distribute_loop): Pass in whether to only distribute patterns. (prepare_perfect_loop_nest): Also allow size optimization. (pass_loop_distribution::execute): When optimizing a loop nest for size allow pattern replacement. * gcc.dg/tree-ssa/ldist-37.c: New testcase. * gcc.dg/tree-ssa/ldist-38.c: Likewise. * gcc.dg/vect/vect.exp: Add -fno-tree-loop-distribute-patterns. * gcc.dg/tree-ssa/ldist-37.c: Adjust. * gcc.dg/tree-ssa/ldist-38.c: Likewise. * g++.dg/tree-ssa/pr78847.C: Likewise. * gcc.dg/autopar/pr39500-1.c: Likewise. * gcc.dg/autopar/reduc-1char.c: Likewise. * gcc.dg/autopar/reduc-7.c: Likewise. * gcc.dg/tree-ssa/ivopts-lt-2.c: Likewise. * gcc.dg/tree-ssa/ivopts-lt.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-1.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-2.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-3.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-4.c: Likewise. * gcc.dg/tree-ssa/prefetch-7.c: Likewise. * gcc.dg/tree-ssa/prefetch-8.c: Likewise. * gcc.dg/tree-ssa/prefetch-9.c: Likewise. * gcc.dg/tree-ssa/scev-11.c: Likewise. * gcc.dg/vect/costmodel/i386/costmodel-vect-31.c: Likewise. * gcc.dg/vect/costmodel/i386/costmodel-vect-33.c: Likewise. * gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c: Likewise. * gcc.dg/vect/costmodel/x86_64/costmodel-vect-33.c: Likewise. * gcc.target/i386/pr30970.c: Likewise. * gcc.target/i386/vect-double-1.c: Likewise. * gcc.target/i386/vect-double-2.c: Likewise. * gcc.dg/tree-ssa/gen-vect-2.c: Likewise. * gcc.dg/tree-ssa/gen-vect-26.c: Likewise. * gcc.dg/tree-ssa/gen-vect-28.c: Likewise. * gcc.dg/tree-ssa/gen-vect-32.c: Likewise. * gfortran.dg/vect/vect-5.f90: Likewise. * gfortran.dg/vect/vect-8.f90: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-37.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-38.c
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 --- Comment #15 from rguenther at suse dot de --- On Fri, 24 May 2019, ffengqi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 > > --- Comment #14 from Qi Feng --- > Checking .original and .optimized file is just a quick method I use to check > whether an optimization happened (if not happen in first and last pass, > probably it didn't happen). I didn't mean or think the transform should > happen > in these passes. > > Using the second pattern, the result of transform already showed in .original > file, so I think it maybe happened earlier (like in GENERIC). > > And I tried the first pattern again using a totally clean debug build > (bootstrap disabled), still didn't see the transformation happen. I don't > know > what went wrong. :( > > (I tested it on a ppc64le machine, don't know if that matters) It can matter because we might have gimplified the && to control flow.
[Bug target/90568] stack protector should use cmp or sub, not xor, to allow macro-fusion on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90568 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri May 24 08:58:50 2019 New Revision: 271596 URL: https://gcc.gnu.org/viewcvs?rev=271596&root=gcc&view=rev Log: PR target/90568 * config/i386/x86-tune-sched.c (ix86_macro_funsion_pair_p): Call gen_attr_type just once instead of 4-7 times. Formatting fixes. Handle stack_protect_test_ codegen similarly to corresponding sub instruction. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/x86-tune-sched.c
[Bug libgomp/90585] libgomp hsa plugin ftbfs in the x32 multilib variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90585 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri May 24 08:59:37 2019 New Revision: 271597 URL: https://gcc.gnu.org/viewcvs?rev=271597&root=gcc&view=rev Log: PR libgomp/90585 * plugin/plugin-hsa.c: Include gstdint.h. Include inttypes.h only if HAVE_INTTYPES_H is defined. (print_uint64_t): New typedef. (PRIu64): Define if HAVE_INTTYPES_H is not defined. (print_kernel_dispatch, run_kernel): Use PRIu64 macro instead of "lu", cast uint64_t HSA_DEBUG and fprintf arguments to print_uint64_t. (release_kernel_dispatch): Likewise. Cast shadow->debug to uintptr_t before casting to void *. * plugin/plugin-nvptx.c: Include gstdint.h instead of stdint.h. * oacc-mem.c: Don't include config.h nor stdint.h. * target.c: Don't include config.h. * oacc-cuda.c: Likewise. * oacc-host.c: Don't include stdint.h. Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-cuda.c trunk/libgomp/oacc-host.c trunk/libgomp/oacc-mem.c trunk/libgomp/plugin/plugin-hsa.c trunk/libgomp/plugin/plugin-nvptx.c trunk/libgomp/target.c
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 --- Comment #16 from Marc Glisse --- (In reply to rguent...@suse.de from comment #15) > It can matter because we might have gimplified the && to > control flow. Indeed. You want to look at the forwprop1 dump to see what gimple-match would need to match (and does match on x86_64). When X > Y && X != 0 is represented with control flow, in theory, VRP could deduce a range [1,inf] for X from X>Y, but in practice it uses a symbolic range [y_3(D) + 1, +INF] from which we fail to deduce X!=0. I think the new ranger thing that doesn't try to do symbolic ranges would handle that better ;-)
[Bug c++/90609] New: Compilation error in std::function default member initialization inside template class with defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90609
Bug ID: 90609
Summary: Compilation error in std::function default member
initialization inside template class with defaulted
constructor
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tgolyi at ya dot ru
Target Milestone: ---
When compiling the following code in gcc 9.1 compilation fails
#include
#include
template
struct test
{
std::function f = [](T *) {};
};
struct test2
{
test d;
test i;
};
void g ()
{
std::make_unique ();
}
Error is:
:7:32: error: could not convert 'test::{}' from
'test::' to 'std::function'
7 | std::function f = [](T *) {};
|^~
||
|test::
If you provide empty constructor to test class everything works fine.
[Bug target/90568] stack protector should use cmp or sub, not xor, to allow macro-fusion on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90568 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Should be fixed now for GCC 10+.
[Bug libgomp/90585] libgomp hsa plugin ftbfs in the x32 multilib variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90585 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk, guess for the backport we could do a simpler thing (as we included inttypes.h unconditionally and nobody complained on the branch, just use the PRIu64 and nothing else). On the trunk it is better to stay being more portable.
[Bug demangler/88783] integer overflow in libiberty, heap overflow will be triggered in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88783 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |MOVED --- Comment #2 from Nick Clifton --- Hi tfx, Thank you vert much for reporting this bug. Unfortunately the binutils project does not maintain the libiberty library (which contains the cplus-dem.c source file). Instead this is handled by the gcc project. So please could you refile your bug report on the gcc bugzilla system: https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc Thank you. Cheers Nick
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 --- Comment #17 from rguenther at suse dot de --- On Fri, 24 May 2019, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 > > --- Comment #16 from Marc Glisse --- > (In reply to rguent...@suse.de from comment #15) > > It can matter because we might have gimplified the && to > > control flow. > > Indeed. You want to look at the forwprop1 dump to see what gimple-match would > need to match (and does match on x86_64). > > When X > Y && X != 0 is represented with control flow, in theory, VRP could > deduce a range [1,inf] for X from X>Y, but in practice it uses a symbolic > range > [y_3(D) + 1, +INF] from which we fail to deduce X!=0. I think the new ranger > thing that doesn't try to do symbolic ranges would handle that better ;-) Note that in theory the ifcombine pass should pick up the opportunity to simplify the comparison via maybe_fold_and_comparisons. It looks like that code is quite old and could need a rewrite to match-and-simplify. But of course it exists to avoid creating trees for the combination parts which still has a point in match-and-simplify times. An opportunity for an alternate code-generator from match.pd since the patterns are still valid sources for the transform just the input is bigger exploded forms.
[Bug demangler/88783] integer overflow in libiberty, heap overflow will be triggered in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88783 --- Comment #3 from Richard Earnshaw --- (In reply to Nick Clifton from comment #2) > Hi tfx, > > Thank you vert much for reporting this bug. Unfortunately the binutils > project does not maintain the libiberty library (which contains the > cplus-dem.c source file). Instead this is handled by the gcc project. > So please could you refile your bug report on the gcc bugzilla system: > >https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc > > Thank you. > > Cheers > Nick ??? This is the gcc bugzilla.
[Bug tree-optimization/90610] New: [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 Bug ID: 90610 Summary: [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- I see following miscomparison: Running 526.blender_r refrate (ref) peak gcc7-m64 (1 copy) [2019-05-24 10:53:13] Error with '/home/marxin/Programming/cpu2017/bin/specinvoke -d /home/marxin/Programming/cpu2017/benchspec/CPU/526.blender_r/run/run_peak_refrate_gcc7-m64.0001 -f compare.cmd -E -e compare.err -o compare.stdout'; no non-empty output files exist Command returned exit code 1 Contents of imagevalidate_sh3_no_char_0849.err ImageValidator r4696 INFO: threshold set to 0.75 INFO: max threshold set to 0 absolute, 0.01 relative Blocks below threshold: 406 blocks of 144 allowed (14400 total) AVG SSIM: 0.980123076 MIN SSIM: -0.481028709 SSIM distribution: [ 1.000]: 5014 [ 0.900, 1.000): 8836 [ 0.800, 0.900): 103 [ 0.700, 0.800): 71 [ 0.600, 0.700): 62 [ 0.500, 0.600): 59 [ 0.400, 0.500): 73 [ 0.300, 0.400): 49 [ 0.200, 0.300): 30 [ 0.100, 0.200): 31 [ 0.000, 0.100): 39 [-0.100, 0.000): 26 [-0.200, -0.100): 5 [-0.300, -0.200): 1 [-0.400, -0.300): 0 [-0.500, -0.400): 1 [-0.600, -0.500): 0 [-0.700, -0.600): 0 [-0.800, -0.700): 0 [-0.900, -0.800): 0 [-1.000, -0.900): 0
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-24 CC||rguenth at gcc dot gnu.org Known to work||9.1.0 Version|unknown |10.0 Blocks||26163 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- I'm going to reduce that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug testsuite/90517] [10 regression] test case gcc.dg/cdce1.c fails (unresolved) starting with r271281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90517 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri May 24 10:15:16 2019 New Revision: 271598 URL: https://gcc.gnu.org/viewcvs?rev=271598&root=gcc&view=rev Log: PR tree-optimization/90106 PR testsuite/90517 * gcc.dg/cdce1.c: Don't scan-assembler, instead -fdump-tree-optimized and scan-tree-dump for tail call. * gcc.dg/cdce2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cdce1.c trunk/gcc/testsuite/gcc.dg/cdce2.c
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #21 from Jakub Jelinek --- Author: jakub Date: Fri May 24 10:15:16 2019 New Revision: 271598 URL: https://gcc.gnu.org/viewcvs?rev=271598&root=gcc&view=rev Log: PR tree-optimization/90106 PR testsuite/90517 * gcc.dg/cdce1.c: Don't scan-assembler, instead -fdump-tree-optimized and scan-tree-dump for tail call. * gcc.dg/cdce2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cdce1.c trunk/gcc/testsuite/gcc.dg/cdce2.c
[Bug c++/69864] Fix various Wnarrowing minor issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864 Jonathan Wakely changed: What|Removed |Added CC|redi at gcc dot gnu.org| --- Comment #14 from Jonathan Wakely --- Un-CCing because I'm not going to work on this.
[Bug c++/90609] [9/10 Regression] Compilation error in std::function default member initialization inside template class with defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90609 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-24 Known to work||8.3.1 Summary|Compilation error in|[9/10 Regression] |std::function default |Compilation error in |member initialization |std::function default |inside template class with |member initialization |defaulted constructor |inside template class with ||defaulted constructor Ever confirmed|0 |1 Known to fail||10.0, 9.1.0
[Bug target/90588] [AArch64] SVE2 flag patch omits aarch64-protos.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90588 --- Comment #2 from Matthew Malcomson --- Author: matmal01 Date: Fri May 24 10:39:38 2019 New Revision: 271599 URL: https://gcc.gnu.org/viewcvs?rev=271599&root=gcc&view=rev Log: [aarch64] Change two function declaration types Commit r271514 missed changing the type of two functions in aarch64-protos.h. The function definitions had been updated to use uint64_t while the function declarations had been missed. They were missed since I only tested the patch on aarch64 where `unsigned long` is the same as `uint64_t`. This patch updates these declarations in aarch64-protos.h. Tested by building an aarch64 cross-compiler on arm-none-linux-gnu (so that `unsigned long` and `uint64_t` are different and would give error messages), and bootstrapping on aarch64-none-linux-gnu. Also manually tested command line options to see that -march=armv8-a+typo prints out the expected flags while using the new feature flags does not complain about missing flags. gcc/ChangeLog: 2019-05-24 Matthew Malcomson PR target/90588 * common/config/aarch64/aarch64-common.c (aarch64_rewrite_selected_cpu): Change local temporary variable type from unsigned long to uint64_t. * config/aarch64/aarch64-protos.h (aarch64_parse_extension, aarch64_get_extension_string_for_isa_flags): Change declaration to match new definition by replacing unsigned long with uint64_t. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/aarch64/aarch64-common.c trunk/gcc/config/aarch64/aarch64-protos.h
[Bug c++/90611] New: Generating a bad sse instruction for 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611
Bug ID: 90611
Summary: Generating a bad sse instruction for 32 bit
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron.greig at codeplay dot com
Target Milestone: ---
Created attachment 46403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46403&action=edit
cpp file that triggers the bug
I am finding that when I compile the attached file, with the following command:
g++-8 -m32 -std=c++11 -msse -O3 repro.cpp -o repro -Wall -Wextra
-fno-strict-aliasing -fwrapv
I get this output:
repro.cpp: In function ‘int main(int, char**)’:
repro.cpp:13:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
int main(int argc, char** argv) {
^~~~
repro.cpp:13:27: warning: unused parameter ‘argv’ [-Wunused-parameter]
int main(int argc, char** argv) {
~~~^~~~
and when I run the resulting binary on a 32-bit system I get an immediate
segfault. This seems to be due to a movaps instruction generating a general
protection exception (see https://www.felixcloutier.com/x86/movaps) because the
address it is loading from isn't aligned to 16 bytes. The minimal command I
have found to reproduce this is
g++-8 -m32 -std=c++11 -msse -O3 repro.cpp -o repro
the output of g++-8 --version is:
g++-8 (Ubuntu 8.3.0-6ubuntu1~18.04) 8.3.0
The system I run the binary on is a virtualbox VM with 32-bit Ubuntu 16.04
installed on it. I can reproduce this bug in the same way by compiling with
that system's installed g++, version:
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
[Bug middle-end/90607] [10 regression] gcc.dg/pr53265.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90607 --- Comment #5 from Richard Biener --- Author: rguenth Date: Fri May 24 11:31:11 2019 New Revision: 271601 URL: https://gcc.gnu.org/viewcvs?rev=271601&root=gcc&view=rev Log: 2019-05-24 Richard Biener PR testsuite/90607 * tree-loop-distribution.c (struct partition): Add location member. (partition_alloc): Initialize all fields. (generate_memset_builtin): Use the location recorded in the partition for the generated call. (generate_memcpy_builtin): Likewise. (classify_partition): Record the location of a single store as location for the partition. * gcc.dg/pr53265.c: Amend for new expected diagnostic. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr53265.c trunk/gcc/tree-loop-distribution.c
[Bug middle-end/90607] [10 regression] gcc.dg/pr53265.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90607 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug c++/90611] Generating a bad sse instruction for 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611 --- Comment #1 from Aaron Greig --- actually it seems that vector_size(16) creates a type that is over aligned, the following assert fails: static_assert(std::alignment_of::value <= alignof(max_align_t), "over aligned!"); so I think I should have been using a custom allocator in the std::vector? It might be worth considering generating a warning for such cases
[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-05-24
Component|c++ |libstdc++
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed.
(gdb) p this
$2 = (std::vector > * const) 0xcf24
(gdb) p *this
$3 = { >> = {
_M_impl = {> = {<__gnu_cxx::new_allocator> =
{}, }, _M_start = 0x804fa28, _M_finish = 0x0,
_M_end_of_storage = 0x804fa38}}, }
it looks like libstdc++ doesn't allocate aligned memory properly or
eventually malloc on 32bit doesn't return 16byte aligned memory.
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 --- Comment #2 from Martin Liška --- Happens also for --size=train and following files are different after the revision: 56/ 1040: blender/source/blender/blenkernel/intern/camera.o: different 64/ 1040: blender/source/blender/blenkernel/intern/curve.o: different 69/ 1040: blender/source/blender/blenkernel/intern/displist.o: different 87/ 1040: blender/source/blender/blenkernel/intern/implicit.o: different 91/ 1040: blender/source/blender/blenkernel/intern/lattice.o: different 100/ 1040: blender/source/blender/blenkernel/intern/mesh.o: different 553/ 1040: blender/source/blender/editors/space_view3d/drawobject.o: different 668/ 1040: blender/source/blender/modifiers/intern/MOD_smooth.o: different 895/ 1040: blender/source/blender/render/intern/source/rayshade.o: different 910/ 1040: blender/source/blender/render/intern/source/zbuf.o: different
[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611
--- Comment #3 from Jonathan Wakely ---
(In reply to Aaron Greig from comment #0)
> Created attachment 46403 [details]
> cpp file that triggers the bug
>
> I am finding that when I compile the attached file, with the following
> command:
> g++-8 -m32 -std=c++11 -msse -O3 repro.cpp -o repro -Wall -Wextra
> -fno-strict-aliasing -fwrapv
> I get this output:
> repro.cpp: In function ‘int main(int, char**)’:
> repro.cpp:13:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
> int main(int argc, char** argv) {
> ^~~~
> repro.cpp:13:27: warning: unused parameter ‘argv’ [-Wunused-parameter]
> int main(int argc, char** argv) {
> ~~~^~~~
You know you can just declare int main() or int main(int, char**) to have a
reproducer that doesn't give any warnings, right?
> and when I run the resulting binary on a 32-bit system I get an immediate
> segfault. This seems to be due to a movaps instruction generating a general
> protection exception (see https://www.felixcloutier.com/x86/movaps) because
> the address it is loading from isn't aligned to 16 bytes. The minimal
> command I have found to reproduce this is
> g++-8 -m32 -std=c++11 -msse -O3 repro.cpp -o repro
> the output of g++-8 --version is:
> g++-8 (Ubuntu 8.3.0-6ubuntu1~18.04) 8.3.0
> The system I run the binary on is a virtualbox VM with 32-bit Ubuntu 16.04
> installed on it. I can reproduce this bug in the same way by compiling with
> that system's installed g++, version:
> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
There are a few issues interacting here.
1) Glibc now (since version 2.26) returns 16-byte aligned memory from malloc,
so this Just Works with a newer glibc. But if your code needed more than
16-byte alignment it would still fail even with a newer glibc, so let's assume
you needed 32-byte alignment...
2) In C++11 and C++14 the standard library does not support overaligned types,
it only supports the alignments that malloc supports. But C++17 added extended
alignment support to the standard library, so compiling with -std=c++17 or
-std=gnu++17 should make extended alignments work. You can also enable extended
alignment support for C++11 and C++14 with the -faligned-new flag. However ...
3) GCC assumes glibc malloc always returns 16-byte aligned memory, even if you
have glibc 2.25 or older, which only returns 8-byte alignment for x86. That
means GCC thinks 16-byte is not extended, but malloc disagrees. I'm trying to
fix that, see PR 90569.
4) To workaround PR 90569 you can use the -faligned-new=8 which tells GCC that
any alignment higher than 8 should be considered an extended alignment, and so
needs special handling (which means it doesn't use malloc, so isn't affected by
old versions of malloc only returning 8-byte alignment).
In summary: With a new glibc and C++17 extended alignments just work
automatically. For older glibc and/or C++11 you can use -faligned-new=8 to make
it work.
I think there is no GCC bug here (except for PR 90569 which I'm already working
on).
[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611 --- Comment #4 from Jonathan Wakely --- (In reply to Aaron Greig from comment #1) > actually it seems that vector_size(16) creates a type that is over aligned, > the following assert fails: > > static_assert(std::alignment_of::value <= alignof(max_align_t), "over > aligned!"); That should only fail with GCC 5, not with GCC 8. Current versions of GCC defined max_align_t to have 16-byte alignment, so your type is not overaligned with current versions (but as I said above, the old glibc on Ubuntu 16.04 disagrees).
[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611
--- Comment #5 from Jonathan Wakely ---
We could do this in std::allocator:
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -110,6 +110,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::align_val_t __al = std::align_val_t(alignof(_Tp));
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp), __al));
}
+#elif __cplusplus >= 201103L
+ if (alignof(_Tp) > alignof(std::max_align_t))
+ __throw_bad_alloc();
#endif
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
}
Which would mean std::allocator refuses to allocate memory for overaligned
types in C++11 and C++14 unless -faligned-new is enabled.
I tried issuing a warning instead:
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -35,6 +35,7 @@
#include
#if __cplusplus >= 201103L
#include
+#include
#endif
namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
@@ -110,10 +111,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::align_val_t __al = std::align_val_t(alignof(_Tp));
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp), __al));
}
+#elif __cplusplus >= 201103L
+ if (alignof(_Tp) > alignof(std::max_align_t))
+ __overaligned();
#endif
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
}
+ void __overaligned() __attribute__((__warning__("use -faligned-new to
enable support for overaligned types"))) { }
+
// __p is not permitted to be a null pointer.
void
deallocate(pointer __p, size_type __t)
But that warning is suppressed unless you use -Wsystem-headers.
Alternatively:
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -35,6 +35,7 @@
#include
#if __cplusplus >= 201103L
#include
+#include
#endif
namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
@@ -110,6 +111,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::align_val_t __al = std::align_val_t(alignof(_Tp));
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp), __al));
}
+#elif __cplusplus >= 201103L
+ static_assert(alignof(_Tp) <= alignof(std::max_align_t),
+ "use -faligned-new to support allocation of overaligned types");
#endif
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
}
But none of these would help for the original reproducer, because GCC 8 doesn't
think it's overaligned, because of the disagreement between max_align_t and
malloc.
[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611
--- Comment #6 from Jonathan Wakely ---
Oh, I forgot that I already implemented another option in
__gnu_cxx::malloc_allocator, which is to check the alignment of the returned
memory and only fail if it isn't suitably aligned:
pointer
allocate(size_type __n, const void* = 0)
{
if (__n > this->max_size())
std::__throw_bad_alloc();
pointer __ret = 0;
#if __cpp_aligned_new
#if __cplusplus > 201402L && _GLIBCXX_HAVE_ALIGNED_ALLOC
if (alignof(_Tp) > alignof(std::max_align_t))
{
__ret = static_cast<_Tp*>(::aligned_alloc(alignof(_Tp),
__n * sizeof(_Tp)));
}
#else
# define _GLIBCXX_CHECK_MALLOC_RESULT
#endif
#endif
if (!__ret)
__ret = static_cast<_Tp*>(std::malloc(__n * sizeof(_Tp)));
if (!__ret)
std::__throw_bad_alloc();
#ifdef _GLIBCXX_CHECK_MALLOC_RESULT
#undef _GLIBCXX_CHECK_MALLOC_RESULT
if (reinterpret_cast(__ret) % alignof(_Tp))
{
// Memory returned by malloc is not suitably aligned for _Tp.
deallocate(__ret, __n);
std::__throw_bad_alloc();
}
#endif
return __ret;
}
This means it might work sometimes, if you get lucky with malloc's return
value.
[Bug c++/90609] [9/10 Regression] Compilation error in std::function default member initialization inside template class with defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90609 Jonathan Wakely changed: What|Removed |Added CC||aoliva at gcc dot gnu.org Target Milestone|--- |9.2 --- Comment #1 from Jonathan Wakely --- This is a regression caused by r268850 PR c++/87322 * pt.c (tsubst_lambda_expr): Avoid duplicate tsubsting. Move cp_evaluated resetting before signature tsubsting. (gen_elem_of_pack_expansion_instantiation): Separate local specializations per index.
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 --- Comment #3 from Martin Liška --- The problematic one is: 910/ 1040: blender/source/blender/render/intern/source/zbuf.o: different
[Bug libstdc++/90612] New: std::filesystem::path crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90612
Bug ID: 90612
Summary: std::filesystem::path crash
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 46404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46404&action=edit
Preprocessed source code
# /usr/local/products/gcc/9.1.0/bin/g++ -std=gnu++2a
-Wl,-rpath,/usr/local/products/gcc/9.1.0/lib64 -lstdc++fs short_fail.C
# ./a.out
Segmentation fault (core dumped)
# /usr/local/products/gcc/9.1.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/9.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/9.1.0/lib/gcc/x86_64-suse-linux/9.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-9.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/9.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.32/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.32/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
gcc version 9.1.0 (GCC)
# cat short_fail.C
#include
#include
namespace fs = std::filesystem;
struct ChainStruct {
std::vector directories;
};
struct Foo {
void reset();
void set(std::filesystem::path const &baz);
std::filesystem::path baz;
};
void Foo::reset() {
char const *bar = "/aaa/a/aa/";
std::filesystem::path baz(bar);
set(std::filesystem::path(bar));
}
void Foo::set(std::filesystem::path const &baz) {
this->baz = baz;
}
void moo() {
ChainStruct oink;
oink.directories.emplace_back("//aaa/aaa/aaa");
oink.directories.emplace_back("//aaa/aaa/aaa");
oink.directories.emplace_back("//aaa/aaa/aaa");
oink.directories.emplace_back("//aaa/aaa/aaa");
}
int main() {
Foo foo;
foo.set("/aaa//a/aaa/aaa");
foo.reset();
foo.set("/aaa//a/aaa/aaa");
foo.reset();
moo();
return 0;
}
[Bug c++/90609] [9/10 Regression] Compilation error in std::function default member initialization inside template class with defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90609
Jonathan Wakely changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #2 from Jonathan Wakely ---
Reduced:
template T&& declval();
template struct function
{
template()(declval()))>
function(F) { }
};
template
struct test
{
function f = [](T *) {};
};
struct test2
{
test d;
test i;
};
template void make() { new T(); }
void g ()
{
make();
}
[Bug libstdc++/90612] std::filesystem::path crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90612 --- Comment #1 from M Welinder --- fs_path.cc line 281 reads... std::uninitialized_copy (to + oldsize, new_size - oldsize, from + oldsize); 1st and 3rd arguments are swapped.
[Bug libstdc++/90612] std::filesystem::path crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90612 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Already fixed. *** This bug has been marked as a duplicate of bug 90557 ***
[Bug libstdc++/90557] [9/10 Regression] Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557 Jonathan Wakely changed: What|Removed |Added CC||terra at gnome dot org --- Comment #5 from Jonathan Wakely --- *** Bug 90612 has been marked as a duplicate of this bug. ***
[Bug libstdc++/90612] std::filesystem::path crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90612 --- Comment #3 from Jonathan Wakely --- N.B. for GCC9 you don't need to use -lstdc++fs for std::filesystem, only for std::experimental::filesystem.
[Bug c++/90613] New: [10 Regression] Debug info size increase after r271467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90613 Bug ID: 90613 Summary: [10 Regression] Debug info size increase after r271467 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- I see debug info increase with -O2 (generic) on 471.omnetpp and probably other C++ benchmarks: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=21.245.4 Other benchmarks would be 473.astar: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=23.255.4 453.povray: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=23.155.4
[Bug c++/90613] [10 Regression] Debug info size increase after r271467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90613 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-24 CC||nathan at gcc dot gnu.org Known to work||9.1.0 Version|unknown |10.0 Blocks||26163 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 --- Comment #4 from Martin Liška --- First change is in zbuf.c.170t.veclower21: GOOD: vect_shuffle3_high_369 = VEC_PERM_EXPR ; vect_shuffle3_low_444 = VEC_PERM_EXPR ; vect_shuffle3_high_368 = VEC_PERM_EXPR ; MEM[(float * *)vectp_vlzp.1055_503] = vect_shuffle3_low_371; vectp_vlzp.1054_445 = vectp_vlzp.1055_503 + 16; MEM[(float * *)vectp_vlzp.1054_445] = vect_shuffle3_high_369; BAD: vect_shuffle3_low_444 = VEC_PERM_EXPR ; vect_shuffle3_high_368 = VEC_PERM_EXPR ; MEM[(float * *)vectp_vlzp.1055_503] = vect_shuffle3_low_371; vectp_vlzp.1054_445 = vectp_vlzp.1055_503 + 16; MEM[(float * *)vectp_vlzp.1054_445] = vect_cst__502; Type of vectors: vector(2) long unsigned int @Richi: Is it enough to see the problem?
[Bug go/90614] New: gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614 Bug ID: 90614 Summary: gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w) Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: mfe at live dot de CC: cmang at google dot com Target Milestone: --- Created attachment 46405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46405&action=edit config.log libgo the exact version of GCC: gcc-9.1.0 the system type: NetgearReadyNAS Duo (http://wiki.dietpc.org/index.php/DIET-PC_on_SPARC_ReadyNAS) the options given when GCC was configured/built: ../gcc-9.1.0/configure CC=/opt/gcc-7.1/bin/gcc CXX=/opt/gcc-7.1/bin/g++ --enable-languages=c,c++,go --prefix=/opt/gcc-9.1 --with-cpu=v7 --with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local --with-isl=/usr/local/ --disable-libstdcxx-pch --disable-linux-futex --disable-libsanitizer --enable-__cxa_atexit --enable-nls --enable-clocale=gnu --enable-debug --disable-doc --disable-libcilkrts --disable-libitm the complete command line that triggers the bug; /usr/local/bin/make the compiler output (error messages, warnings, etc.); [...] /bin/sh ./libtool --tag=CC --mode=compile /backup/fes-readynasduo/gcc-9.1.0-compiled/./gcc/xgcc -B/backup/fes-readynasduo/gcc-9.1.0-compiled/./gcc/ -B/opt/gcc-9.1/sparc-unknown-linux-gnu/bin/ -B/opt/gcc-9.1/sparc-unknown-linux-gnu/lib/ -isystem /opt/gcc-9.1/sparc-unknown-linux-gnu/include -isystem /opt/gcc-9.1/sparc-unknown-linux-gnu/sys-include -fno-checking -DHAVE_CONFIG_H -I. -I../../../gcc-9.1.0/libgo -I ../../../gcc-9.1.0/libgo/runtime -I../../../gcc-9.1.0/libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../gcc-9.1.0/libgo/../libgcc -I ../../../gcc-9.1.0/libgo/../libbacktrace -I ../../gcc/include -g -O2 -c -o syscall/wait.lo ../../../gcc-9.1.0/libgo/go/syscall/wait.c libtool: compile: /backup/fes-readynasduo/gcc-9.1.0-compiled/./gcc/xgcc -B/backup/fes-readynasduo/gcc-9.1.0-compiled/./gcc/ -B/opt/gcc-9.1/sparc-unknown-linux-gnu/bin/ -B/opt/gcc-9.1/sparc-unknown-linux-gnu/lib/ -isystem /opt/gcc-9.1/sparc-unknown-linux-gnu/include -isystem /opt/gcc-9.1/sparc-unknown-linux-gnu/sys-include -fno-checking -DHAVE_CONFIG_H -I. -I../../../gcc-9.1.0/libgo -I ../../../gcc-9.1.0/libgo/runtime -I../../../gcc-9.1.0/libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../gcc-9.1.0/libgo/../libgcc -I ../../../gcc-9.1.0/libgo/../libbacktrace -I ../../gcc/include -g -O2 -c ../../../gcc-9.1.0/libgo/go/syscall/wait.c -fPIC -DPIC -o syscall/.libs/wait.o ../../../gcc-9.1.0/libgo/go/syscall/wait.c: In function ‘Continued’: ../../../gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] 54 | Continued (uint32_t *w) | ~~^ cc1: all warnings being treated as errors make[4]: *** [Makefile:2888: syscall/wait.lo] Error 1 make[4]: Leaving directory '/c/backup/fes-readynasduo/gcc-9.1.0-compiled/sparc-unknown-linux-gnu/libgo' make[3]: *** [Makefile:2235: all-recursive] Error 1 make[3]: Leaving directory '/c/backup/fes-readynasduo/gcc-9.1.0-compiled/sparc-unknown-linux-gnu/libgo' make[2]: *** [Makefile:1160: all] Error 2
[Bug go/90614] gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614 --- Comment #1 from martin --- Created attachment 46406 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46406&action=edit libgo gen-sysinfo.go
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 --- Comment #5 from Martin Liška --- Created attachment 46407 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46407&action=edit Veclower dump files
[Bug target/90588] [AArch64] SVE2 flag patch omits aarch64-protos.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90588 Matthew Malcomson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Matthew Malcomson --- fixed on trunk
[Bug demangler/88783] integer overflow in libiberty, heap overflow will be triggered in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88783 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|MOVED |--- --- Comment #4 from Andrew Pinski --- .
[Bug fortran/89782] Can do an internal READ of a character array when it is a parameter, but not a scalar character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89782 --- Comment #5 from Jerry DeLisle --- It appears that character(len=*),parameter :: VALUES(*)=[character(len=10) :: is being marked as a variable when it should be BT_CONSTANT.
[Bug testsuite/90615] New: [10 regression] several vector test cases fail starting with r271553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90615 Bug ID: 90615 Summary: [10 regression] several vector test cases fail starting with r271553 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- I think a few tests got missed in r271553 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76a.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76c.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.target/powerpc/vsx-vectorize-1.c scan-tree-dump-times vect "Alignment of access forced using versioning" 1 FAIL: gcc.target/powerpc/vsx-vectorize-1.c scan-tree-dump-times vect "vectorized 1 loops" 1 one example: Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -ftree-vectorize -fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-vect-details -lm -o ./costmodel-vect-31b.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -ftree-vectorize -fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-vect-details -lm -o ./costmodel-vect-31b.exe PASS: gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test2/gcc::/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/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c execution test gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c: pattern found 0 times FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c scan-tree-dump-times vect "vectorized 1 loops" 1 testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/costmodel/ppc/ppc-costmodel-vect.exp completed in 0 seconds === gcc Summary === # of expected passes2 # of unexpected failures1 and also FAIL: gcc.dg/pr53265.c (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -Wall -S -o pr53265.s /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c: In function 'fn1': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:16:14: warning: iteration 64 invokes undefined behavior [-Waggressive-loop-optimizations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:15:3: note: within this loop /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c: In function 'fn2': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:27:22: warning: iteration 112 invokes undefined behavior [-Waggressive-loop-optimizations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:26:3: note: within this loop /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c: In function 'fn3': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:40:16: warning: iteration 8 invokes undefined behavior [-Waggressive-loop-optimizations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:38:3: note: within this loop /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c: In function 'fn4': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:55:9: warning: iteration 32 invokes undefined behavior [-Waggressive-loop-optimizations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:53:3: note: within this loop /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c: In function 'fn5': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr53265.c:69:24: warning: iteration 950 invokes undefined behavior [-Wagg
[Bug target/90616] New: Suboptimal code generated for accessing an aligned array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90616
Bug ID: 90616
Summary: Suboptimal code generated for accessing an aligned
array.
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: igusarov at mail dot ru
Target Milestone: ---
Consider the following code:
#include
uint8_t globalArray[68] __attribute__((aligned(256)));
uint8_t foo(uint8_t index)
{
return globalArray[index];
}
avr-gcc-5.4.0 generates the following code for the body of foo():
movr30,r24# r24 is where 'index' argument is stored
ldir31,0
subi r30,lo8(-(globalArray))
sbci r31,hi8(-(globalArray))
ld r24,Z
which is suboptimal because the lower byte of the address of globalArray is
always 0 due to the extended alignment enforced on that object.
Would it be possible to generate a better code for such specific indexing? For
example, the following snippet takes full advantage of the overalignment:
movr30,r24
ldir31,hi8(globalArray)
ld r24,Z
[Bug go/90614] gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614 --- Comment #2 from martin --- Created attachment 46408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46408&action=edit wait.h in /usr/include/
[Bug go/90614] gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614 --- Comment #3 from martin --- Created attachment 46409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46409&action=edit wait.h /usr/include/sys/
[Bug c++/90320] [7/8/9/10 Regression] Explicit constructor called implicitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90320
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||5.5.0
Keywords||rejects-valid
Last reconfirmed||2019-05-24
CC||paolo at gcc dot gnu.org
Ever confirmed|0 |1
Summary|Explicit constructor called |[7/8/9/10 Regression]
|implicitly |Explicit constructor called
||implicitly
Known to fail||10.0, 6.5.0, 7.4.0, 8.3.0,
||9.1.0
--- Comment #1 from Jonathan Wakely ---
Here's a rejects-valid testcase that Clang and EDG accept:
struct M {
M() = default;
template explicit M(T&&) = delete;
};
struct V {
V(M m);
};
M m;
V v = m;
GCC tries to use the deleted constructor template instead of the copy
constructor when initializing the parameter of V::V(M):
m.cc:11:7: error: use of deleted function ‘M::M(T&&) [with T = M&]’
V v = m;
^
m.cc:3:34: note: declared here
template explicit M(T&&) = delete;
^
m.cc:7:3: note: initializing argument 1 of ‘V::V(M)’
V(M m);
^
M::M(M&) is a better match for a non-const lvalue than the implicit
M::M(const M&) copy constructor, but because it's explicit it shouldn't be
used.
GCC 5 compiled it OK (with -std=c++11) but it started to be rejected with
r225705:
PR c++/54521
* call.c (convert_like_real): Do not set LOOKUP_ONLYCONVERTING for
the second step of copy-initialization.
[Bug c++/90320] [7/8/9/10 Regression] Explicit constructor called implicitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90320 --- Comment #2 from Jonathan Wakely --- (In reply to Adam Mitz from comment #0) > May be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87605 but > this doesn't involve the ternary operator. It's similar, but I don't think it's the same bug, because the example in PR 87605 was always incorrectly accepted by GCC. The one here used to be rejected and so is a regression.
[Bug c++/90617] New: GCC 9 miscompiles Qt4 "foreach" macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90617
Bug ID: 90617
Summary: GCC 9 miscompiles Qt4 "foreach" macro
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bastian.beisc...@rwth-aachen.de
Target Milestone: ---
Created attachment 46410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46410&action=edit
preprocessed qt4.C source.
The following piece of code, which uses Qt 4.8.7:
#include
#include
int main(int argc, char** argv) {
QList list;
list.append(1);
list.append(2);
list.append(3);
foreach(int x, list) {
std::cout << x << std::endl;
}
return 0;
}
Compiled with gcc 9.1.0 like this:
$ g++ -I/usr/include/qt4 -I/usr/include/qt4/QtCore -lQtCore -o qt4 qt4.C
does not execute the "foreach" loop correctly.
$ ./qt4
1
Only the first list element is printed. This is a regression with respect to
GCC 8.3.0:
$ g++-8 -I/usr/include/qt4 -I/usr/include/qt4/QtCore -lQtCore -o qt4 qt4.C
$ ./qt4
1
2
3
The preprocessed sources of qt4.C are attached as 'qt4.i'.
I managed to construct a reproducer (based on the Qt foreach macro) which is
short and does not use Qt:
#include
#include
template
class ForeachContainer {
public:
inline ForeachContainer(const T& t)
: c(t)
, brk(0)
, i(c.begin())
, e(c.end()) {
}
const T c;
int brk;
typename T::const_iterator i, e;
};
int main() {
std::vector v;
v.push_back(0);
v.push_back(1);
v.push_back(2);
for (ForeachContainer> _container_(v);
!_container_.brk && _container_.i != _container_.e;
__extension__ ({ ++_container_.brk; ++_container_.i; })) {
for (int x = *_container_.i;
;
__extension__ ({--_container_.brk; break;})) {
std::cout << "x = " << x << std::endl;
}
}
return 0;
}
$ g++ -g -o mini9 mini.C
$ ./mini9
x = 0
$ g++-8 -g -o mini8 mini.C
$ ./mini8
x = 0
x = 1
x = 2
Admittedly, the code is ugly, but that's what is in Qt 4.8.7.
[Bug c++/90617] GCC 9 miscompiles Qt4 "foreach" macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90617
--- Comment #1 from Andrew Pinski ---
> for (int x = *_container_.i;
> ;
> __extension__ ({--_container_.brk; break;})) {
>
> std::cout << "x = " << x << std::endl;
>}
Hmmm, the question here becomes where is that break should be breaking on; the
inner most for loop or the outer one? Before GCC 9, it was the inner one but
in GCC 9 (and above) it is the outer most one.
[Bug libstdc++/90618] New: new test case testsuite/20_util/shared_ptr/cons/alias-rval.cc introduced in r271583 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90618 Bug ID: 90618 Summary: new test case testsuite/20_util/shared_ptr/cons/alias-rval.cc introduced in r271583 fails Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- testsuite/20_util/shared_ptr/cons/alias-rval.cc Executing on host: /home/seurer/gcc/build/gcc-test2/./gcc/xg++ -shared-libgcc -B/home/seurer/gcc/build/gcc-test2/./gcc -nostdinc++ -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/sys-include -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util /home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias-rval.cc -std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./alias-rval.exe(timeout = 600) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/./gcc/xg++ -shared-libgcc -B/home/seurer/gcc/build/gcc-test2/./gcc -nostdinc++ -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/sys-include -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util /home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias-rval.cc -std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./alias-rval.exe PASS: 20_util/shared_ptr/cons/alias-rval.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gc
[Bug libstdc++/90618] new test case testsuite/20_util/shared_ptr/cons/alias-rval.cc introduced in r271583 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90618 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonathan Wakely --- Already fixed by r271603. Somehow a half-finished test didn't fail (or I didn't notice the failure?) and committed it.
[Bug c++/78667] nonsensical attribute alloc_size silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78667
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work||9.0
Resolution|--- |FIXED
Target Milestone|--- |9.0
Known to fail||7.3.0, 8.2.0
--- Comment #3 from Martin Sebor ---
The test case in comment #0 is diagnosed by GCC 9:
pr78667.c:2:1: warning: ‘alloc_size’ attribute ignored on a function returning
‘void’ [-Wattributes]
2 | void f (int) __attribute__ ((alloc_size (1)));
| ^~~~
pr78667.c:3:1: warning: ‘alloc_size’ attribute ignored on a function returning
‘long int’ [-Wattributes]
3 | long g (int*) __attribute__ ((alloc_size (1)));
| ^~~~
GCC 9 also rejects the test case in comment #2 with an error:
a.c:1:1: error: requested alignment is not an integer constant
1 | void f (void) __attribute__ ((aligned ("foo")));
| ^~~~
a.c:2:1: warning: ‘alloc_size’ attribute ignored on a function returning ‘void’
[-Wattributes]
2 | void g (void) __attribute__ ((alloc_size ("bar")));
| ^~~~
So this bug can be resolved as fixed.
[Bug libstdc++/90618] new test case testsuite/20_util/shared_ptr/cons/alias-rval.cc introduced in r271583 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90618 --- Comment #2 from seurer at gcc dot gnu.org --- Sorry, I looked but didn't see a fix.
[Bug target/90619] New: [10 regression] spec 2017 tests 527.cam4_r and 521.wrf_r segfault while running after r271386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90619 Bug ID: 90619 Summary: [10 regression] spec 2017 tests 527.cam4_r and 521.wrf_r segfault while running after r271386 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- I saw the same failures on both power 8 and power 9. runcpu -c wds_test.cfg --rebuild -n 1 -v 9 527.cam4_r . . . Running 527.cam4_r refrate (ref) base none (1 copy) [2019-05-24 09:26:33] /home/seurer/gcc/cpu2017/bin/specinvoke -d /home/seurer/gcc/cpu2017/benchspec/CPU/527.cam4_r/run/run_base_refrate_none. -f speccmds.cmd -q -e speccmds.err -o speccmds.stdout 527.cam4_r: copy 0 non-zero return code (exit code=0, signal=11) Contents of cam4_r_base.none.err Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7fffb7f804a7 in ??? #1 0x7fffb7a3369c in ??? #2 0x106364cb in ??? #3 0x1006bbaf in ??? #4 0x1006bc47 in ??? #5 0x1020a98f in ??? #6 0x1044e807 in ??? #7 0x1046a4d3 in ??? #8 0x104b725f in ??? #9 0x10003517 in ??? #10 0x7fffb79a391f in ??? #11 0x7fffb79a3b1b in ??? #12 0x in ??? similary for 521.wrf_r Running 521.wrf_r refrate (ref) base none (1 copy) [2019-05-24 10:25:28] /home/seurer/gcc/cpu2017/bin/specinvoke -d /home/seurer/gcc/cpu2017/benchspec/CPU/521.wrf_r/run/run_base_refrate_none. -f speccmds.cmd -q -e speccmds.err -o speccmds.stdout 521.wrf_r: copy 0 non-zero return code (exit code=0, signal=11) Contents of wrf.err Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x3fffac0804d7 in ??? #1 0x11077c48 in ??? #2 0x11090c2f in ??? #3 0x110924d7 in ??? #4 0x110a524f in ??? #5 0x10c61113 in ??? #6 0x11340fef in ??? #7 0x113838a7 in ??? #8 0x10d449bf in ??? #9 0x11240fb3 in ??? #10 0x10004473 in ??? #11 0x3fffabaf309b in ???
[Bug libstdc++/85965] [8/9/10 Regression] G++ gives cryptic error instead of incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965 --- Comment #17 from Jonathan Wakely --- Author: redi Date: Fri May 24 16:09:28 2019 New Revision: 271607 URL: https://gcc.gnu.org/viewcvs?rev=271607&root=gcc&view=rev Log: PR libstdc++/85965 move is_invocable assertions again This is another attempt to reduce how often the assertions are evaluated, so that code which doesn't try to use the function objects doesn't need them to be invocable. For _Rb_tree we access the _M_key_compare object directly, so can't put the assertions in an accessor function for it. However, every invocation of _M_key_compare is accompanied by a use of _S_key, so the assertions can be put in there. For _Hashtable there are member functions that are consistently used to obtain a hash code or test for equality, so the assertions can go in those members. Backport from mainline 2019-05-17 Jonathan Wakely PR libstdc++/85965 * include/bits/hashtable.h (_Hashtable::~_Hashtable()): Remove static assertions from the destructor. * include/bits/hashtable_policy.h (_Hash_code_base::_M_hash_code): Move static_assert for hash function to here. (_Hash_table_base::_M_equals): Move static_assert for equality predicate to here. * include/bits/stl_tree.h (_Rb_tree::_S_key(_Const_Link_type)): Move assertions here. Access the value directly instead of calling _S_value. (_Rb_tree::_S_key(_Const_Base_ptr)): Do downcast and forward to _S_key(_Const_Link_type). * testsuite/23_containers/set/85965.cc: Check construction, destruction, assignment and size() do not trigger the assertions. * testsuite/23_containers/unordered_set/85965.cc: Likewise. * testsuite/23_containers/map/48101_neg.cc: Call find and adjust expected errors. * testsuite/23_containers/multimap/48101_neg.cc: Likewise. * testsuite/23_containers/multiset/48101_neg.cc: Likewise. * testsuite/23_containers/set/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_map/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_set/48101_neg.cc: Likewise. Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/include/bits/hashtable.h branches/gcc-9-branch/libstdc++-v3/include/bits/hashtable_policy.h branches/gcc-9-branch/libstdc++-v3/include/bits/stl_tree.h branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/set/85965.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
[Bug target/90619] [10 regression] spec 2017 tests 527.cam4_r and 521.wrf_r segfault while running after r271386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90619 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64le-unknown-linux-g ||nu CC||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64le-unknown-linux-g ||nu Build||powerpc64le-unknown-linux-g ||nu --- Comment #1 from seurer at gcc dot gnu.org --- I will work on trying to extract a smaller test case. 527.cam4_r may be the better one to look at as it runs only about 10% as long (clock wise) as the other before failing.
[Bug c++/90617] GCC 9 miscompiles Qt4 "foreach" macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90617 --- Comment #2 from Andreas Schwab --- According to [stmt.for] the expression is supposed to be evaluated in the scope of the inner loop.
[Bug c/90620] New: Microblaze: ICE similar to bug 16267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90620 Bug ID: 90620 Summary: Microblaze: ICE similar to bug 16267 Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: giulio.benetti at micronovasrl dot com Target Milestone: --- This ICE bug is similar to Bug 16267 and happens with GCC 7.4.0 too. Here is the build log: http://autobuild.buildroot.org/results/64706f96db793777de9d3ec63b0a47d776cf33fd/build-end.log
[Bug target/90621] New: [mingw] Command line switch -print-multiarch prints nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90621 Bug ID: 90621 Summary: [mingw] Command line switch -print-multiarch prints nothing Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: development at jordi dot vilar.cat Target Milestone: --- mingw-w64 releases (at least from 6.x through 8.x) print nothing when invoked with command line switch -print-multiarch.
[Bug target/90621] [mingw] Command line switch -print-multiarch prints nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90621 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Multi-arch is different from multi-lib. Multi-arch is used on debian derivied distros.
[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401 Giulio Benetti changed: What|Removed |Added CC||giulio.benetti@micronovasrl ||.com --- Comment #8 from Giulio Benetti --- This duplicates Bug 68485
[Bug target/90621] [mingw] Command line switch -print-multiarch prints nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90621 --- Comment #2 from Andrew Pinski --- More to the point is that if multi-arch is not used, then it is empty. This is true on Linux as it is true under mingw.
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 Andrew Pinski changed: What|Removed |Added CC||thomas.petazzoni@free-elect ||rons.com --- Comment #6 from Andrew Pinski --- *** Bug 69401 has been marked as a duplicate of this bug. ***
[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 68485 ***
[Bug target/71124] Compiler enters infinite loop on Microblaze with -O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71124 --- Comment #5 from Giulio Benetti --- Sorry for the noise, I didn't know how it worked here. Anyway this duplicates Bug 85180.
[Bug target/90622] New: Suboptimal code generated for __builtin_avr_insert_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90622
Bug ID: 90622
Summary: Suboptimal code generated for
__builtin_avr_insert_bits
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: igusarov at mail dot ru
Target Milestone: ---
Please consider the following function:
uint8_t copy_bit_5_to_bit_2(uint8_t dst, uint8_t src)
{
return __builtin_avr_insert_bits(0xF5FF, src, dst);
}
That particular map value (magic hex constant) is supposed to copy the 5-th bit
from argument 'src' to the 2-nd bit of argument 'dst' while leaving all other
bits of src unmodified.
In other words, given that
bit representation of src is [s7 s6 s5 s4 s3 s2 s1 s0], and
bit representation of dst is [d7 d6 d5 d4 d3 d2 d1 d0],
it should return [d7 d6 d5 d4 d3 s5 d1 d0].
The code generated for such function is perfect:
bst r22,5# Take the 5-th bit of r22
bld r24,2# Put it as the 2-nd bit in r24
Similar code is generated for copying any n-th bit to any m-th bit, provided
that n and m are different. Thus far everything is great.
However, the code generated for copying n-th bit to n-th bit is surprisingly
suboptimal. A similar function
uint8_t copy_bit_2_to_bit_2(uint8_t dst, uint8_t src)
{
return __builtin_avr_insert_bits(0xF2FF, src, dst);
}
gives:
eor r22,r24
andi r22,lo8(4)
eor r24,r22
which takes an extra word of program memory and an extra CPU cycle at runtime.
I wonder what's wrong with using the same bst/bld idiom which is successfully
used for n-to-m copy? I would expect that the following code is much better:
bst r22,2
bld r24,2
It would be great if the compiler can generate it.
[Bug c++/90572] [9/10 Regression] Wrong disambiguation in friend declaration as implicit typename context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90572 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.2 Summary|Wrong disambiguation in |[9/10 Regression] Wrong |friend declaration as |disambiguation in friend |implicit typename context |declaration as implicit ||typename context
[Bug c++/90572] [9/10 Regression] Wrong disambiguation in friend declaration as implicit typename context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90572 Marek Polacek changed: What|Removed |Added Keywords|wrong-code |patch --- Comment #2 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01716.html
[Bug middle-end/85598] [7/8 Regression] Incorrect -Wformat-truncation in a loop only at -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598 Martin Sebor changed: What|Removed |Added Known to work||9.0 Summary|[7/8 Regression] Incorrect |[7/8 Regression] Incorrect |warning only at -O2 and -O3 |-Wformat-truncation in a ||loop only at -O2 and -O3 Known to fail||6.3.0, 7.3.0, 8.2.0 --- Comment #24 from Martin Sebor --- I'm guessing this is not going to be backported, correct?
[Bug tree-optimization/88814] transform snprintf into memccpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88814 Martin Sebor changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=90263 | --- Comment #1 from Martin Sebor --- The proposal to add memccpy to C2X was approved in WG14 last month so once __builtin_memccpy is implemented the transformation can be added. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2349.htm
[Bug tree-optimization/81772] Compile-time snprintf optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81772 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88814 --- Comment #4 from Martin Sebor --- I forgot about this request. An alternate solution to the strncat trick is to use memccpy (bug 88814). I'm hoping to look into one or the other for GCC 10.
[Bug c++/90623] New: compilation error with fold expression and parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90623
Bug ID: 90623
Summary: compilation error with fold expression and parameter
pack
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: remi.louvot at gmail dot com
Target Milestone: ---
This is (literally) a text book example of lambda expression with c++17, it
compiles fine with gcc8 and latest clang, but gcc9 throws an error around the
fold expression in which each expression takes the whole pack as third argument
source>: In instantiation of 'main():: [with auto:4 = {int,
int, int}]':
:17:56: required from here
:11:36: error: redeclaration of 'const int xs#1'
11 | (call_cart(f, xs, xs... ), ...);
//compiled with -std=c++17
#include
int main(){
auto call_cart{[=](auto f, auto x, auto...rest) {
(((x < rest) ? f(x, rest) : (void) 0), ...);
}};
auto cartesian{[=](auto...xs) {
return [=](auto f) {
(call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with gcc9
// other version without fold expression // same problem
// (void)std::initializer_list{((void)call_cart(f,xs,xs...),0)...};
};
}};
constexpr auto print_cart{cartesian(1, 2, 3)};
static_assert((print_cart([](int x, int y)constexpr{}),true));
print_cart([](int x, int y) { std::cout << x << "," << y << std::endl; });
}
[Bug ada/90624] New: nt_spawnve() may use stack variable escape_char uninitialized (in gcc/ada/terminals.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90624 Bug ID: 90624 Summary: nt_spawnve() may use stack variable escape_char uninitialized (in gcc/ada/terminals.c) Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: adamrichter4 at gmail dot com CC: adamrichter4 at gmail dot com Target Milestone: --- cppcheck noticed that, in pristine gcc-9.1.0 from ftp.gnu.org, in the file gcc-9.1.0/gcc/ada/terminals.c, the static function nt_spawnve contains a local variable escape_char that appears to be used in some string processing without its value ever being set. I believe that the value of escape_char is actually never set, because the static variable Vw32_quote_process_args is always zero. I have not attempted to build gcc-9.1.0 with Ada enabled, because I am basically just trying cppcheck on a bunch of different source trees. However, I have installed gcc-9.1.0 and could try building the Ada support if that would really help with processing of this bug report. I do not have a proposed patch at this point because I am not sure what value escape_char should default to. My guess is '\\'. The public function __gnat_setup_child_communication is the only function that calls nt_spawnve. __gnat_setup_child_communication does not appear to be called by anything in the gcc source tree, so I am guessing that this is some for some runtime support library similar to libgcc. Thanks for considering this report of a possible bug.
[Bug tree-optimization/90625] New: fold strcmp(a, b) == 0 to zero for strings of unequal but non-const lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90625
Bug ID: 90625
Summary: fold strcmp(a, b) == 0 to zero for strings of unequal
but non-const lengths
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following was prompted by pr83431 that seems harder to solve than I
expected. In the test case below, the lengths of the two strings are either
the same and the function returns 0, or they are different and the function
also returns zero because strcmp of two strings of unequal lengths must return
non-zero. So the strcmp equality can be folded to zero, and the whole function
body then replaced with 'return 0.'
GCC already tries to optimize strcmp equalities in handle_builtin_string_cmp()
in strlen.c (thanks to the solutin for pr83026 committed in r261039) but it
only handles simple cases.
gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout b.c
typedef __SIZE_TYPE__ size_t;
int f (const char *a, const char *b)
{
size_t m = __builtin_strlen (a);
size_t n = __builtin_strlen (b);
if (m == n)
return 0;
return __builtin_strcmp (a, b) == 0;
}
;; Function f (f, funcdef_no=0, decl_uid=1908, cgraph_uid=1, symbol_order=0)
f (const char * a, const char * b)
{
size_t n;
size_t m;
int _1;
_Bool _2;
int _3;
int _9;
[local count: 1073741824]:
m_6 = __builtin_strlen (a_5(D));
n_8 = __builtin_strlen (b_7(D));
if (m_6 == n_8)
goto ; [20.97%]
else
goto ; [79.03%]
[local count: 848578164]:
_1 = __builtin_strcmp (a_5(D), b_7(D));
_2 = _1 == 0;
_9 = (int) _2;
[local count: 1073741824]:
# _3 = PHI <_9(3), 0(2)>
return _3;
}
[Bug tree-optimization/90626] New: fold strcmp(a, b) == 0 to zero when one string length is exact and the other is unequal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90626
Bug ID: 90626
Summary: fold strcmp(a, b) == 0 to zero when one string length
is exact and the other is unequal
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Similar to pr90625 but simpler, the strcmp equality in the function below can
safely be folded to zero because the two strings are of unequal lengths. The
code in handle_builtin_string_cmp() in strlen.c (committed in r261039) should
have all it needs to implement this optimization, it just also needs to
consider minimum string lengths.
$ cat b.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout b.c
int f (char * restrict a, char * restrict b)
{
__builtin_memcpy (a, "1234", 4); // length >= 4
__builtin_strcpy (b, "123"); // length == 3
return __builtin_strcmp (a, b) == 0; // must be false
}
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)
f (char * restrict a, char * restrict b)
{
int _1;
_Bool _2;
int _8;
[local count: 1073741824]:
__builtin_memcpy (a_4(D), "1234", 4);
__builtin_memcpy (b_6(D), "123", 4);
_1 = __builtin_strcmp (a_4(D), b_6(D));
_2 = _1 == 0;
_8 = (int) _2;
return _8;
}
[Bug c/90627] New: : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 Bug ID: 90627 Summary: : internal compiler error when compiling cython-generated python3 modules Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bogi788 at hotmail dot com Target Milestone: --- Created attachment 46411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46411&action=edit sample source file that causes the internal compiler error compiling any cython-generated python3 extension causes an internal compiler error using gcc 9.1.0 (on CentOS 7.6 x86_64). the output for one of the failing modules, compiled with gcc -v -save-temps -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fdata-sections -fdata-sections -flto -march=native -s -fPIC -I/opt/include/python3.7m -c _time.c -o _time.o -g0 is as follows: Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: /opt/src/gcc-9.1.0/configure --prefix=/opt --disable-multilib --enable-languages=c,c++,lto --with-arch=native --with-system-zlib Thread model: posix gcc version 9.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-pthread' '-Wno-unused-result' '-Wsign-compare' '-D' 'NDEBUG' '-g' '-fwrapv' '-O3' '-Wall' '-fdata-sections' '-flto' '-march=native' '-s' '-fPIC' '-I' '/opt/include/python3.7m' '-c' '-o' '_time.o' '-g0' /opt/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/cc1 -E -quiet -v -I /opt/plone-5.2/include -I /opt/include/python3.7m -D_REENTRANT -D NDEBUG _time.c -march=x86-64 -mmmx -mno-3dnow -msse -msse2 -msse3 -mno-ssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic -Wno-unused-result -Wsign-compare -Wall -fwrapv -fdata-sections -flto -fPIC -O3 -fpch-preprocess -o _time.i ignoring nonexistent directory "/opt/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/plone-5.2/include /opt/include/python3.7m /opt/lib/gcc/x86_64-pc-linux-gnu/9.1.0/include /usr/local/include /opt/include /opt/lib/gcc/x86_64-pc-linux-gnu/9.1.0/include-fixed /usr/include End of search list. : internal compiler error: in build_common_tree_nodes, at tree.c:10521 The resulting _time.i file contains only # 1 "ti/cache/_time.c" It should however be possible to compile the attached .c file with only the python 3.7 headers. Compiling the same source file using gcc 8.3 doesn't cause the internal compiler error. If it helps I can send the .i file generated by gcc 8.3.
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #18 from John David Anglin --- Author: danglin Date: Fri May 24 23:12:16 2019 New Revision: 271611 URL: https://gcc.gnu.org/viewcvs?rev=271611&root=gcc&view=rev Log: PR target/90530 * config/pa/pa.c (pa_can_change_mode_class): Accept mode changes from DImode to SImode in floating-point registers on 64-bit target. * config/pa/pa.md (umulsidi3): Change nonimmediate_operand to register_operand in xmpyu patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/pa.md
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #19 from John David Anglin --- Author: danglin Date: Fri May 24 23:15:49 2019 New Revision: 271612 URL: https://gcc.gnu.org/viewcvs?rev=271612&root=gcc&view=rev Log: PR target/90530 * config/pa/pa.c (pa_can_change_mode_class): Accept mode changes from DImode to SImode in floating-point registers on 64-bit target. * config/pa/pa.md (umulsidi3): Change nonimmediate_operand to register_operand in xmpyu patterns. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/pa/pa.c branches/gcc-9-branch/gcc/config/pa/pa.md
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #20 from John David Anglin --- Author: danglin Date: Fri May 24 23:17:09 2019 New Revision: 271613 URL: https://gcc.gnu.org/viewcvs?rev=271613&root=gcc&view=rev Log: PR target/90530 * config/pa/pa.c (pa_can_change_mode_class): Accept mode changes from DImode to SImode in floating-point registers on 64-bit target. * config/pa/pa.md (umulsidi3): Change nonimmediate_operand to register_operand in xmpyu patterns. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/pa/pa.c branches/gcc-8-branch/gcc/config/pa/pa.md
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 --- Comment #21 from John David Anglin --- Author: danglin Date: Fri May 24 23:20:25 2019 New Revision: 271614 URL: https://gcc.gnu.org/viewcvs?rev=271614&root=gcc&view=rev Log: PR target/90530 * config/pa/pa.c (pa_cannot_change_mode_class): Accept mode changes from DImode to SImode in floating-point registers on 64-bit target. * config/pa/pa.md (umulsidi3): Change nonimmediate_operand to register_operand in xmpyu patterns. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/pa/pa.c branches/gcc-7-branch/gcc/config/pa/pa.md
[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from John David Anglin --- Fixed.
[Bug c++/69020] wrong ADL for attribute cleanup functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69020 Eric Gallager changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||nathan at gcc dot gnu.org --- Comment #4 from Eric Gallager --- cc-ing C++ FE maintainers for their opinions as to how to handle this.
