[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 92253, which changed state.

Bug 92253 Summary: [10 Regression] 25% regression in 465.tonto with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92253

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug ipa/92253] [10 Regression] 25% regression in 465.tonto with LTO

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92253

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Richard Biener  ---
It seems fixed.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
This changed in r9-1926-g6f41f92bebfb0b5eb3a3859b1c3bb7710d1cb48b as PR69558
fix.

[Bug tree-optimization/93674] [8/9/10 Regression] GCC eliminates conditions it should not, when strict-enums is on

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Bin Cheng :

https://gcc.gnu.org/g:ed80b385418f97ef087f3f2bbe1abecffb5c9775

commit r10-7650-ged80b385418f97ef087f3f2bbe1abecffb5c9775
Author: Bin Cheng 
Date:   Thu Apr 9 16:42:48 2020 +0800

Add unsigned type iv_cand for iv_use with non mode-precision type

Precisely,  for iv_use if it's not integer/pointer type, or non-mode
precision type, add candidate for the corresponding scev in unsigned
type with the same precision, rather than its original type.

gcc/
PR tree-optimization/93674
* tree-ssa-loop-ivopts.c (langhooks.h): New include.
(add_iv_candidate_for_use): For iv_use of non integer or pointer type,
or non-mode precision type, add candidate in unsigned type with the
same precision.

gcc/testsuite/
PR tree-optimization/93674
* g++.dg/pr93674.C: New test.

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #18 from Richard Biener  ---
So the resolution for PR64076 the testcase was added for was "similar" as in
short-cut an assert with !in_lto_p.(In reply to Jan Hubicka from comment #15)
> The testcase has an ODR violation that makes comdat groups go out of sync.
> So I guess it is just about finding way to not make verifier to ICE.
> With release settings the testcase will however quietly compile this I do
> not think this is release blocker (P1).

Huh, the testcase failure mode is a link-fail - remember the testcase
has one object compiled with -fno-lto.  It might be there's another bug
in us ICEing when you LTO the whole thing and I'd agree that's more an
ice-after-error and we should eventually make ODR violations error and
simply give up after WPA.

So - can you please see why the testcase fails to _link_?  For reference
this is what my testsuite log says:

spawn -ignore SIGHUP /home/rguenther/obj/gcc/testsuite/g++/../../xg++
-B/home/rguenther/obj/gcc/testsuite/g++/../../ cp_lto_pr64076_0.o
cp_lto_pr64076_1.o -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -nostdinc++
-I/home/rguenther/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/rguenther/obj/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/rguenther/src/trunk/libstdc++-v3/libsupc++
-I/home/rguenther/src/trunk/libstdc++-v3/include/backward
-I/home/rguenther/src/trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -O0
-flto -flto-partition=none -fuse-linker-plugin
-L/home/rguenther/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs
-B/home/rguenther/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs
-L/home/rguenther/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs
-B/home/rguenther/obj/x86_64-pc-linux-gnu/./libitm/
-L/home/rguenther/obj/x86_64-pc-linux-gnu/./libitm/.libs -o
g++-dg-lto-pr64076-01.exe^M
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
g++-dg-lto-pr64076-01.exe.lto.o:(.rodata+0x58): undefined reference to
`non-virtual thunk to S::f()'^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
FAIL: g++.dg/lto/pr64076 cp_lto_pr64076_0.o-cp_lto_pr64076_1.o link, -O0 -flto
-flto-partition=none -fuse-linker-plugin

I guess the explanation is similar in the end - the wrong comdat wins?

For a usual bugreport such report would be INVALID I guess.  Now the issue
is we have that testcase in our testsuite and the solution to PR64076.
I suppose PR64076 would have ICEd when producing a shared object as well
so that might be something we could do to alleivate the link failure?
The testcase unfortunately doesn't reproduce the old issue anymore
when reverting the fix.

The question is of course also why appearantly the causing rev caused
that symbol to be necessary.

diff --git a/gcc/testsuite/g++.dg/lto/pr64076_0.C
b/gcc/testsuite/g++.dg/lto/pr64076_0.C
index fb9b060e323..57d0fd6a1c3 100644
--- a/gcc/testsuite/g++.dg/lto/pr64076_0.C
+++ b/gcc/testsuite/g++.dg/lto/pr64076_0.C
@@ -1,4 +1,8 @@
 // { dg-lto-do link }
+// { dg-lto-options { { -O0 -flto -shared -fPIC } } }
+// { dg-require-effective-target fpic }
+// { dg-require-effective-target shared }
+// { dg-extra-ld-options "-shared" }

 #define XXX
 #include "pr64076.H"
diff --git a/gcc/testsuite/g++.dg/lto/pr64076_1.C
b/gcc/testsuite/g++.dg/lto/pr64076_1.C
index 4bd00817b1d..c9c58b798ec 100644
--- a/gcc/testsuite/g++.dg/lto/pr64076_1.C
+++ b/gcc/testsuite/g++.dg/lto/pr64076_1.C
@@ -1,4 +1,4 @@
-// { dg-options -fno-lto }
+// { dg-options "-fno-lto -fPIC" }

 #include "pr64076.H"


fixes the testcase for me (and would be OK to me to resolve this P1).
Other opinions?

[Bug target/94530] [9/10 Regression] ICE: SIGSEGV in rhs_regno (rtl.h:1924) with -Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94530

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Andrea Corallo :

https://gcc.gnu.org/g:af19e4d0e23e5f61fc15e44a58bfa3b047854b1e

commit r10-7651-gaf19e4d0e23e5f61fc15e44a58bfa3b047854b1e
Author: Andrea Corallo 
Date:   Wed Apr 8 13:38:28 2020 +0100

PR target/94530

gcc/ChangeLog

2020-04-09  Andrea Corallo  

PR target/94530
* config/aarch64/falkor-tag-collision-avoidance.c
(valid_src_p): Fix missing rtx type check.

gcc/testsuite/ChangeLog

2020-04-09  Andrea Corallo  

* gcc.target/aarch64/pr94530.c: New test.

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #16 from Richard Biener  ---
(In reply to Martin Jambor from comment #14)
> Another option, which does not create an inter-pass dependency and
> does not clutter tree-inline any more, but which pessimizes IPA-SRA
> (put perhaps just alittle bit?), is making sure that the statements
> which might be left behind are harmless:
> 
> diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
> index 31de527d111..df54b98759c 100644
> --- a/gcc/ipa-sra.c
> +++ b/gcc/ipa-sra.c
> @@ -859,7 +859,8 @@ isra_track_scalar_value_uses (cgraph_node *node, tree
> name, int parm_num,
> }
>   res += all_uses;
> }
> -  else if ((is_gimple_assign (stmt) && !gimple_has_volatile_ops (stmt))
> +  else if ((is_gimple_assign (stmt) && !gimple_has_volatile_ops (stmt)
> +   && !gimple_could_trap_p (stmt))
>|| gimple_code (stmt) == GIMPLE_PHI)
> {
>   tree lhs;
> 
> I'll see what a tree-inline.c solution would look like and then decide
> which of these I'll propose.

Any progress here?  I think using the above would be best.  Another
option would be, during inlining, to make sure that removed parameters
get initialized (that also silences the warning), just the constant to use
isn't 100% obvious.  I'd settle for a 1 which is safe for all cases I
can think of besides array indexing or pointer adjustment and for
signed operations where anything but 0 might cause some undefined overflow.
Note the overflow thing also means that the gimple_could_trap_p check
is not sufficient.

But in the end I always wonder whether those "premature" optimizations
during IPA analysis are worth it and why we not simply consider all uses
as "uses"?

I also think that the user should not be able to disable all of DCE
(or enable IPA SRA ontop of -O0).  But of course that only makes the
attack surface smaller - I can very well imagine "bad" circumstances
with us arriving at a similarly problematic IL before IPA SRA
analysis with plain -O2.

Oh, instead of initializing dropped parameters the inliner could also
make sure to map it to a NaT, dropping stmts that use that and turn
their defs into NaTs as well.  Of course then IPA SRAs "DCE" decision
becomes a correctness thing.

That said, a proper solution _will_ need to get rid of the dead stmts
at IPA transform time.

Not sure if we really need an "improper" solution right now (given
the testcase needs to disable DCE).  The situation here is similar
to that with inline predicates and __builtin_constant_p.

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350

--- Comment #7 from Jonathan Wakely  ---
(In reply to Arthur O'Dwyer from comment #6)
> What do you mean "if an exception is thrown"? If we call std::copy from
> here, then it's because we are taking the memmove path.

The whole point of the bug is the conditions for which we call std::copy. My
comment is discussing when we can and can't call it. You seem to be assuming
that we've already got the conditions correct and therefore the conditions are
already correct. That's a tautology.

If we get the conditions wrong, then "it's because we are taking the memmove
path" might be false. We might end up calling a specialization of std::copy
that decides not to memmove.

So when discussing the conditions when it's valid to call std::copy, it's worth
enumerating the requirements on std::uninitialized_copy and how they differ
from std::copy. 

But as I said right after the part you quoted, trivially copyable implies
trivially destructible, so the trivially destructible requirement is trivially
met.

[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495

--- Comment #7 from Jakub Jelinek  ---
Created attachment 48246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48246&action=edit
gcc10-pr94495.patch

Untested fix.  This does two things during var-tracking.  One is try to reuse
even more the SP_DERIVED_VALUE_P and VALUEs equated to that + CONST_INT in
!frame_pointer_needed functions (ideally have just a single SP_DERIVED_VALUE_P)
and through that make sure they can be all expressed using cfa_base_rtx or
cfa_base_rtx + CONST_INT (and thus in DWARF using DW_OP_fbreg).
And the second change is that for VALUEs that can be expressed that way it
throws away all MO_VAL_SETs, we have the best expression for it (DW_OP_fbreg)
that is constant through the function, so it is not beneficial to express it in
one part of the function using that, in another part of the function using the
stack pointer, in yet another part using some other register.

[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322

Richard Biener  changed:

   What|Removed |Added

Summary|[10 regression] alias-4 |[10 regression]
   |test failure|g++.dg/lto/alias-4_0.C test
   ||failure
 Status|WAITING |NEW
   Keywords||alias, missed-optimization
 Target||arm

--- Comment #14 from Richard Biener  ---
FAIL: g++.dg/lto/alias-4 cp_lto_alias-4_0.o-cp_lto_alias-4_0.o execute  -O3
-flto -fno-early-inlining 

on periodic testing on armv8l-linux-gnueabihf

Adjusting summary - we also have gcc.dg/alias-4.c.

So we're failing to disambiguate loads against stores here for some reason
(we sure need either IPA PTA or TBAA for this to work - it's unclear
what's special here about 'arm' - all loads and stores are pointers
and there's one aggregate assignment involving struct a, also containing
a pointer)

  # VUSE <.MEM_6(D)>
  # PT = nonlocal escaped null
  _1 = ptrD.5611;
  # .MEM_7 = VDEF <.MEM_6(D)>
  *_1 = 0B;
  # VUSE <.MEM_7>
  # PT = nonlocal escaped null
  _10 = aptrD.5614;
  # .MEM_11 = VDEF <.MEM_7>
  *_10 = aD.5615;
  # VUSE <.MEM_11>
  # PT = nonlocal escaped null
  _2 = ptrD.5611;
  # VUSE <.MEM_11>
  # PT = nonlocal escaped null
  _3 = *_2;
  _4 = _3 == 0B;

So I'm quite sure the missed optimization isn't a regression?  (can somebody
quickly check GCC 9 whether the testcase is optimized there on ARM?)

Which makes it a testsuite issue to solve for GCC 10, for example by
xfail-ing it on affected platforms.

The actual issue can probably be simplified quite a bit into a testcase
for alias analysis and FRE1.

[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322

--- Comment #15 from Wilco  ---
(In reply to Richard Biener from comment #14)

> So I'm quite sure the missed optimization isn't a regression?  (can somebody
> quickly check GCC 9 whether the testcase is optimized there on ARM?)

It fails on both AArch64 and Arm all the way back to GCC6 (oldest compiler I
tried). So it's not a regression but this is all target independent so I
wouldn't expect this to fail.

[Bug debug/94502] [aarch64] Missing LR register location in FDE

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94502

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #7 from Richard Earnshaw  ---
Compiler was conforming to specification.  Not a bug.

[Bug target/94538] New: [9/10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538

Bug ID: 94538
   Summary: [9/10 Regression] ICE: in
extract_constrain_insn_cached, at recog.c:2223 (insn
does not satisfy its constraints) with
-mcpu=cortex-m23 -mslow-flash-data
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

Created attachment 48247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48247&action=edit
reduced testcase

Compiler output:
$ armv7a-hardfloat-linux-gnueabi-gcc -mcpu=cortex-m23 -mslow-flash-data
testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: error: insn does not satisfy its constraints:
9 | }
  | ^
(insn 91 90 17 (set (reg:SI 12 ip [128])
(plus:SI (reg:SI 12 ip [128])
(const_int 255 [0xff]))) "testcase.c":8:5 905 {*thumb1_addsi3}
 (expr_list:REG_EQUAL (const_int 4095 [0xfff])
(nil)))
during RTL pass: shorten
testcase.c:9:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2207
0x6f8802 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x6f888f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:118
0x6e9a7e extract_constrain_insn_cached(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2207
0x166862f insn_default_length(rtx_insn*)
/repo/gcc-trunk/gcc/config/arm/arm.md:363
0xcb4c3e shorten_branches(rtx_insn*)
/repo/gcc-trunk/gcc/final.c:1118
0xcb4d0f rest_of_handle_shorten_branches
/repo/gcc-trunk/gcc/final.c:4753
0xcb4d0f execute
/repo/gcc-trunk/gcc/final.c:4782
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r10-7640-20200408212358-gd0cc1b79b39-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/10.0.1/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r10-7640-20200408212358-gd0cc1b79b39-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200408 (experimental) (GCC)

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369

--- Comment #19 from Jan Hubicka  ---
The reason why we get link failure is that we behave differently to mismatched
comdats.  While linker choose comdat that wins and eliminate other one we keep
the other symbol and end up compiling it which leads to interesting issues with
"half comdat" I am aiming to solve with the patch for proper handling of
aliases.

I think updating the testcase with -shared is a way to go for this P1 and I we
can discuss the alias issue (probably for 10.2, since it is bit involved and
very old)

Honza

[Bug c++/94523] [10 Regression] error: 'constexpr' evaluation depth exceeds maximum of 512 (use '-fconstexpr-depth=' to increase the maximum) since r10-7490-g76f09260b7eccd6c

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94523

Volker Reichelt  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #4 from Volker Reichelt  ---
Here's a simpler testcase without variadic templates and template alias:

===
struct A
{
  char c;
  constexpr A(int) : c() {}
};

template struct B
{
  static constexpr auto X = A(N);
};

constexpr A a = B<0>::X;
===

[Bug c++/94523] [10 Regression] error: 'constexpr' evaluation depth exceeds maximum of 512 (use '-fconstexpr-depth=' to increase the maximum) since r10-7490-g76f09260b7eccd6c

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94523

--- Comment #5 from Volker Reichelt  ---
Btw, larger testcases also fail with -std=c++2a, so it's not restricted to
-std=c++14

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:bb40460646ce4e6ad27a2f6795106d004d405314

commit r10-7652-gbb40460646ce4e6ad27a2f6795106d004d405314
Author: Richard Biener 
Date:   Thu Apr 9 13:54:01 2020 +0200

testsuite/93369 - use -shared to avoid issue with ODR violation

The testcase contains an ODR violation and thus the observed
link failure is an accepted outcome (it originally was for
an ICE during WPA).  Thus the following adds -shared to the link.

2020-04-09  Richard Biener  

PR testsuite/93369
* g++.dg/lto/pr64076_0.C: Add -shared -fPIC.
* g++.dg/lto/pr64076_1.C: Add -fPIC.

[Bug c++/94523] [10 Regression] error: 'constexpr' evaluation depth exceeds maximum of 512 (use '-fconstexpr-depth=' to increase the maximum) since r10-7490-g76f09260b7eccd6c

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94523

--- Comment #6 from Volker Reichelt  ---
Please ignore my previous comment, it really only fails with -std=c++14 or
-std=c++11 .

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Richard Biener  ---
Fixed.

[Bug ipa/94434] [AArch64][SVE] ICE caused by incompatibility of SRA and svst3 builtin-function

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434

Martin Jambor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-04-09
  Component|tree-optimization   |ipa
 Status|UNCONFIRMED |ASSIGNED
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

[Bug ada/94419] missing errors for constraints on access types

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94419

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW
Summary|accepting wrong programs|missing errors for
   |because compiler error  |constraints on access types

--- Comment #5 from Eric Botcazou  ---
> Recently I test gcc 9.3.0 and it report some errors in the example code. But
> I modify it slightly and it works with no errors.
> I think the code is enough clear to see what exact clauses RM are violated.
> For example there is conversion from access to constrained to access to
> unconstrained type, and the type have a constrained partial view, while
> legality rules for conversions requires for such case that any partial view
> were unconstrained. There is also assignments of different subtypes (which
> have no common values).

Yes, some errors are indeed missing.  The thing is, constraints on access types
have been historically problematic in Ada from an implementation point of view
and there even have been talks about removing them.

[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:f60979edbfcf6ce2cbf2cb09b8af8c125ff7774f

commit r10-7654-gf60979edbfcf6ce2cbf2cb09b8af8c125ff7774f
Author: Jan Hubicka 
Date:   Thu Apr 9 14:12:36 2020 +0200

Avoid g++.dg/lto/alias-4_0.C test failure on ARM [PR91322]

PR tree-optimization/91322
* g++.dg/lto/alias-4_0.C: Avoid conflict with va_list on ARM and
add
a template testing that.

[Bug target/94341] mve_mov can produce ICE on latest trunk

[sripar01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94341

--- Comment #2 from SRINATH PARVATHANENI  ---
Patch committed by Andre:

commit b094133c1c5bf21ccd60c344de6f4a798140e61b
Author: Andre Simoes Dias Vieira 
Date:   Tue Apr 7 13:36:43 2020 +0100

arm: MVE: Fix constant load pattern

This patch fixes the constant load pattern for MVE, this was not accounting
correctly for label + offset cases.

Added test that ICE'd before and removed the scan assemblers for the
mve_vector*
tests as they were too fragile.

[Bug target/94341] mve_mov can produce ICE on latest trunk

[sripar01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94341

SRINATH PARVATHANENI  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from SRINATH PARVATHANENI  ---
Fixed

[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Jan Hubicka  ---
So this turned out to be disabled ODR based TBAA for this struct since on ARM
the builtin va_list type has same structure.
I fixed the fialure by adjusting the structure and next stage1 we can make ODR
TBAA to not give up in this case.

[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
   Target Milestone|10.0|11.0

--- Comment #16 from Richard Biener  ---
Downgrading and re-targeting to GCC 11 (sorry).  The underlying issue is latent
since a long time while the actual testcase with SMS + partitioning on the
respective target worked before "by accident" and now no longer works.

[Bug c++/93790] [10 Regression] Cannot initialize reference from std::reference_wrapper using direct- or list-initialization syntax in GCC 10 c++2a mode

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93790

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:830c572428758f134bd001e699a08e622e2452c3

commit r10-7656-g830c572428758f134bd001e699a08e622e2452c3
Author: Marek Polacek 
Date:   Wed Apr 8 17:03:53 2020 -0400

c++: Fix wrong paren-init of aggregates interference [PR93790]

This PR points out that we are rejecting valid code in C++20.  The
problem is that we were surreptitiously transforming

  T& t(e)

into

  T& t{e}

which is wrong, because the type of e had a conversion function to T,
while aggregate initialization of t from e doesn't work.  Therefore, I
was violating a design principle of P0960, which says that any existing
meaning of A(b) should not change.  So I think we should only attempt to
aggregate-initialize if the original expression was ill-formed.

Another design principle is that () should work where {} works, so this:

  struct S { int i; };
  const S& s(1);

has to keep working.  Thus the special handling for paren-lists with one
element.  (A paren-list with more than one element would give you "error:
expression list treated as compound expression in initializer" C++17.)

PR c++/93790
* call.c (initialize_reference): If the reference binding failed,
maybe
try initializing from { }.
* decl.c (grok_reference_init): For T& t(e), set
LOOKUP_AGGREGATE_PAREN_INIT but don't build up a constructor yet.

* g++.dg/cpp2a/paren-init23.C: New test.
* g++.dg/init/aggr14.C: New test.

[Bug c++/93790] [10 Regression] Cannot initialize reference from std::reference_wrapper using direct- or list-initialization syntax in GCC 10 c++2a mode

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93790

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
Should be fixed, thanks for the great report!

[Bug middle-end/94539] New: gcc.dg/alias-14.c fails on gcc 10, succeeds on gcc 9, when turned into an execution test

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94539

Bug ID: 94539
   Summary: gcc.dg/alias-14.c fails on gcc 10, succeeds on gcc 9,
when turned into an execution test
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

The test gcc/testsuite/gcc.dg/alias-14.c fails when compiled and executed with
gcc 10, and succeeds when compiled and executed with gcc 9.

It was added in r6-1220 as a compile-only test, but seems like it should be an
execution test?  Apologies in advance if this test is bogus as an execution
test.

[Bug tree-optimization/94482] [8/9/10 Regression] Inserting into vector with optimization enabled on x86 generates incorrect result

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482

--- Comment #23 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:2111d5406a4ec56d6335bde779a995914d0a36d1

commit r10-7657-g2111d5406a4ec56d6335bde779a995914d0a36d1
Author: Martin Jambor 
Date:   Thu Apr 9 14:37:21 2020 +0200

sra: Fix sra_modify_expr handling of partial writes (PR 94482)

when sra_modify_expr is invoked on an expression that modifies only
part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
of an assignment and the SRA replacement's type is not compatible with
what is being replaced (0th operand of the B_F_R in the above
example), it does not work properly, basically throwing away the partd
of the expr that should have stayed intact.

This is fixed in two ways.  For BIT_FIELD_REFs, which operate on the
binary image of the replacement (and so in a way serve as a
VIEW_CONVERT_EXPR) we just do not bother with convertsing.  For
REALPART_EXPRs and IMAGPART_EXPRs, if the replacement is not a
register, we insert a VIEW_CONVERT_EXPR under
the complex partial access expression, which is always OK, for loads
from registers we take the extra step of converting it to a temporary.

This revealed a bug in fwprop which is fixed with the hunk from Richi.

The testcase for handling REALPART_EXPR and IMAGPART_EXPR is a bit
fragile because SRA prefers complex and vector types over anything
else (and in between the two it decides based on TYPE_UID which in my
testing today always preferred complex types) and so I only run it at
-O1 (which is the only level where the the test fails for me).

Bootstrapped and tested on x86_64-linux, i686-linux and aarch64-linux.

2020-04-09  Martin Jambor  
Richard Biener  

PR tree-optimization/94482
* tree-sra.c (create_access_replacement): Dump new replacement with
TDF_UID.
(sra_modify_expr): Fix handling of cases when the original EXPR
writes
to only part of the replacement.
* tree-ssa-forwprop.c (pass_forwprop::execute): Properly verify
the first operand of combinations into REAL/IMAGPART_EXPR and
BIT_FIELD_REF.

testsuite/
* gcc.dg/torture/pr94482.c: New test.
* gcc.dg/tree-ssa/pr94482-2.c: Likewise.

[Bug tree-optimization/94482] [8/9 Regression] Inserting into vector with optimization enabled on x86 generates incorrect result

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482

Martin Jambor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #24 from Martin Jambor  ---
Fixed on trunk, will backport in a week or so.

[Bug ipa/94434] [AArch64][SVE] ICE caused by incompatibility of SRA and svst3 builtin-function

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434

Martin Jambor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #1 from Martin Jambor  ---
Created attachment 48248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48248&action=edit
Proposed fix

After our discussion on the mailing list, I'm currently testing this patch

[Bug libstdc++/94540] New: stack overflow populating std::vector

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94540

Bug ID: 94540
   Summary: stack overflow populating std::vector
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct yooj_type { char data[20*1024*1024]; };

int main() {
  std::vector v(1);
}

This dies with SIGSEGV due to a stack overflow, because a yooj_type temporary
is created on the stack in :

  template<>
struct __uninitialized_default_1
{
  template
static void
__uninit_default(_ForwardIterator __first, _ForwardIterator __last)
{
  typedef typename iterator_traits<_ForwardIterator>::value_type
_ValueType;

  std::fill(__first, __last, _ValueType());
}
};

We should either avoid using std::fill for large objects (for some arbitrary
meaning of large) or we should construct the first object in place and then use
that as the fill argument:

--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -549,7 +549,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  typedef typename iterator_traits<_ForwardIterator>::value_type
_ValueType;

- std::fill(__first, __last, _ValueType());
+ if (__first == __last)
+   return;
+
+ const _ValueType& __val
+   = *std::_Construct(std::__addressof(*__first));
+ if (++__first != __last)
+   std::fill(__first, __last, __val);
}
 };

@@ -585,7 +591,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  typedef typename iterator_traits<_ForwardIterator>::value_type
_ValueType;

- return std::fill_n(__first, __n, _ValueType());
+ if (__size_to_integer(__n) <= 0)
+   return __first;
+
+ const _ValueType& __val
+   = *std::_Construct(std::__addressof(*__first));
+ return std::fill_n(++__first, __size_to_integer(__n) - 1, __val);
}
 };

I'm concerned this will confuse the optimisers, but haven't checked yet.

[Bug ipa/94434] [AArch64][SVE] ICE caused by incompatibility of SRA and svst3 builtin-function

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434

Martin Jambor  changed:

   What|Removed |Added

  Attachment #48248|0   |1
is obsolete||

--- Comment #2 from Martin Jambor  ---
Created attachment 48249
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48249&action=edit
Proposed fix without a stupid pasto

The previous attachment had an obviou pasto in it, this is what I'm testing.

[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516

--- Comment #12 from Jakub Jelinek  ---
Wonder if we couldn't let postreload.c add REG_EQUAL notes when it replaces sp
+= CONST_INT with sp = reg, like:
--- gcc/postreload.c.jj 2020-04-08 12:03:54.600398023 +0200
+++ gcc/postreload.c2020-04-09 14:36:48.288632884 +0200
@@ -97,6 +97,16 @@ reload_cse_simplify (rtx_insn *insn, rtx
   if (NO_FUNCTION_CSE && CALL_P (insn))
 return false;

+  /* Remember if this insn has been sp += const_int.  */
+  rtx sp_set = set_for_reg_notes (insn);
+  rtx sp_addend = NULL_RTX;
+  if (sp_set
+  && SET_DEST (sp_set) == stack_pointer_rtx
+  && GET_CODE (SET_SRC (sp_set)) == PLUS
+  && XEXP (SET_SRC (sp_set), 0) == stack_pointer_rtx
+  && CONST_INT_P (XEXP (SET_SRC (sp_set), 1)))
+sp_addend = XEXP (SET_SRC (sp_set), 1);
+
   if (GET_CODE (body) == SET)
 {
   int count = 0;
@@ -180,6 +190,15 @@ reload_cse_simplify (rtx_insn *insn, rtx
reload_cse_simplify_operands (insn, testreg);
 }

+  /* If sp += const_int insn is changed into sp = reg;, add REG_EQUAL
+ note so that the stack_adjustments pass can undo it if beneficial.  */
+  if (sp_addend
+  && SET_DEST (sp_set) == stack_pointer_rtx
+  && GET_CODE (SET_SRC (sp_set)) != PLUS)
+set_dst_reg_note (insn, REG_EQUAL,
+ gen_rtx_PLUS (Pmode, stack_pointer_rtx,
+   sp_addend), stack_pointer_rtx);
+
 done:
   return (EDGE_COUNT (insn_bb->succs) != insn_bb_succs);
 }
and teach combine-stack-adj.c to deal with that.
I guess the major problem is that e.g. on x86 sp += const_int has a CC clobber,
but sp = reg doesn't.  And post-RA not really sure how can one figure out what
clobbers to readd and how to check whether it is safe (the reg is dead).
Perhaps the clobbers could be taken from the other stack adjustment insn, but
still we need to verify the register(s) aren't live there.

[Bug middle-end/94539] [10 Regression] gcc.dg/alias-14.c fails on gcc 10, succeeds on gcc 9, when turned into an execution test

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94539

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-04-09
   Target Milestone|--- |10.0
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
Summary|gcc.dg/alias-14.c fails on  |[10 Regression]
   |gcc 10, succeeds on gcc 9,  |gcc.dg/alias-14.c fails on
   |when turned into an |gcc 10, succeeds on gcc 9,
   |execution test  |when turned into an
   ||execution test

--- Comment #1 from Richard Biener  ---
On x86_64 we're failing

  /* Again we should make void * in the structure conflict with any pointer. 
*/
  asm ("":"=r"(ptr):"0"(&c));
  c.a=NULL;
  *ptr=(float*)(size_t)1;
  if (!c.a)
__builtin_abort ();

and at that point FRE1 already has

   :
  __asm__("" : "=r" ptr_23 : "0" &b);
  *ptr_23 = 1B;
  __asm__("" : "=r" ptr_26 : "0" &c);
  c.a = 0B;
  *ptr_26 = 1B;
  __builtin_abort ();

I'll have a more detailed look.

[Bug target/94538] [9/10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538

Wilco  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||wilco at gcc dot gnu.org
   Last reconfirmed||2020-04-09
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org

--- Comment #1 from Wilco  ---
Thanks for the concise testcase. -mslow-flash-data disables MOVW generation
which exactly the opposite of what we want. I'm testing a trivial fix.

[Bug target/94541] New: -mx32 gcc produces wrong code passing structs by value

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

Bug ID: 94541
   Summary: -mx32 gcc produces wrong code passing structs by value
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Created attachment 48250
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48250&action=edit
test case

Attached reduced example.

Compiled with 'g++ -Wall -Wextra -fno-strict-aliasing -fwrapv', the run-time
results of the following combinations:

-O0 -m64:   0  0
-O1 -m64:   0  0
-O2 -m64:   0  0
-O3 -m64:   0  0
-O0 -m32:   0  0
-O1 -m32:   0  0
-O2 -m32:   0  0
-O3 -m32:   0  0
-O0 -mx32:  0  0
-O1 -mx32: -1 22  // munmap failed, EINVAL
-O2 -mx32: -1 22
-O3 -mx32: -1 22

A failure is not observed when:

- The condition is: if (b.ptr && b.length)
- The condition is: if (b.length)
- The ptr and length fields in Array are swapped.
- Array is passed by reference.


Tested with 8.4.0, 9.2.0, and 10.0.1.  All have the same problem.

[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs since r10-2106-g6343b6bf3bb83c87

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314

Martin Liška  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #12 from Martin Liška  ---
Let's reopen it again..

[Bug target/94541] -mx32 gcc produces wrong code passing structs by value

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #1 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #0)
> A failure is not observed when:
> 
> - The condition is: if (b.ptr && b.length)
> - The condition is: if (b.length)
> - The ptr and length fields in Array are swapped.
> - Array is passed by reference.
> 

- A call to puts("") is inserted before munmap().

[Bug middle-end/94539] [10 Regression] gcc.dg/alias-14.c fails on gcc 10, succeeds on gcc 9, when turned into an execution test

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94539

--- Comment #2 from Jan Hubicka  ---
Hmm, the testcase is mine so I will take a look (and make it dg-do-run :)
Honza

[Bug tree-optimization/94532] [10 Regression] ICE while compiling speccpu2017 blender

[dpochepk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94532

Dmitrij Pochepko  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Dmitrij Pochepko  ---


*** This bug has been marked as a duplicate of bug 94443 ***

[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad

[dpochepk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443

Dmitrij Pochepko  changed:

   What|Removed |Added

 CC||dpochepk at gmail dot com

--- Comment #19 from Dmitrij Pochepko  ---
*** Bug 94532 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/94532] [10 Regression] ICE while compiling speccpu2017 blender

[dpochepk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94532

--- Comment #4 from Dmitrij Pochepko  ---
Yes. It'a a diplicate of 94443

[Bug target/94541] -mx32 gcc produces wrong code passing structs by value

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I don't have a -mx32 capable environment, so can't verify, but mmap/munmap
shouldn't be inlined in any way, so can you reproduce if you replace
mmap with foo and munmap with bar and define them like:
static char c;
__attribute__((noipa)) void *
foo (void *addr, size_t length, int prot, int flags, int fd, off_t offset)
{
  return (void *) &c;
}
__attribute__((noipa)) int
bar (void *addr, size_t length)
{
  if (addr != (void *) &c)
return -1;
  return 0;
}
or so?  If yes, can you also drop errno from the testcase, and possibly drop
unnecessary arguments to foo and/or bar as long as it reproduces?  Once
minimized that way, please preprocess it.

[Bug libstdc++/94540] stack overflow populating std::vector

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94540

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-09
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
   Last reconfirmed||2020-04-09
 Status|UNCONFIRMED |ASSIGNED
  Known to work||4.9.3
Summary|-mx32 gcc produces wrong|[8/9/10 Regression] -mx32
   |code passing structs by |gcc produces wrong code
   |value   |passing structs by value
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
[hjl@gnu-cfl-2 tmp]$ cat bar.c
typedef unsigned int size_t;
struct Array
{
  size_t length;
  void *ptr;
};
extern int munmap (void *__addr, size_t __len);

int
deallocate(struct Array b)
{
  int result = 0;
  if (b.length)
result = munmap(b.ptr, b.length);
  return result;
}
[hjl@gnu-cfl-2 tmp]$  gcc -S -O bar.c -mx32 
[hjl@gnu-cfl-2 tmp]$ cat bar.s
.file   "bar.c"
.text
.globl  deallocate
.type   deallocate, @function
deallocate:
.LFB0:
.cfi_startproc
movl$0, %eax
testl   %edi, %edi
jne .L8
ret
.L8:
subl$8, %esp
.cfi_def_cfa_offset 16
movq%rdi, %rsi   << It should be movl %edi, %esi
shrq$32, %rdi
callmunmap
addl$8, %esp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   deallocate, .-deallocate
.ident  "GCC: (GNU) 9.3.1 20200408 (Red Hat 9.3.1-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$ 

GCC 4.9.3 works.

[Bug ipa/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550

--- Comment #3 from Martin Jambor  ---
Almost certainly started with new IPA-SRA (r275982 or as we now call
it gcc-10-3311-gff6686d2e5f).  I looked at dumps from a cross-compiler
and the funny bit is, however, that new IPA-SRA simply does nothing.

That is not as it should be.  Because foo is not versionable, the pass
does not even look at it and then cannot do anything because it has
not seen a call to get_a.  But of course it should still analyze
outgoing calls to allow IPA-SRA of callees.

But that is merely a missed optimization, not this miscompilation.  I
looks almost as if it was simply the expand of misaligned structure
copy that is broken on (this?) strict-aliasing target.  I also believe
the test case does not successfuly run when compiled with earlier
revisions and option -fno-ipa-sra.

[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538

Wilco  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE: in   |[10 Regression] ICE: in
   |extract_constrain_insn_cach |extract_constrain_insn_cach
   |ed, at recog.c:2223 (insn   |ed, at recog.c:2223 (insn
   |does not satisfy its|does not satisfy its
   |constraints) with   |constraints) with
   |-mcpu=cortex-m23|-mcpu=cortex-m23
   |-mslow-flash-data   |-mslow-flash-data

--- Comment #2 from Wilco  ---
This was introduced by commit e24f6408d so only in GCC10.

[Bug target/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550

Martin Jambor  changed:

   What|Removed |Added

  Component|ipa |target

--- Comment #4 from Martin Jambor  ---
Not an IPA issue.

[Bug middle-end/94539] [10 Regression] gcc.dg/alias-14.c fails on gcc 10, succeeds on gcc 9, when turned into an execution test

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94539

--- Comment #3 from Patrick Palka  ---
Bisection seems to be pointing to r10-779

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #4 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #2)
> I don't have a -mx32 capable environment, so can't verify, but mmap/munmap
> shouldn't be inlined in any way, so can you reproduce if you replace
> mmap with foo and munmap with bar and define them like:
> static char c;
> __attribute__((noipa)) void *
> foo (void *addr, size_t length, int prot, int flags, int fd, off_t offset)
> {
>   return (void *) &c;
> }
> __attribute__((noipa)) int
> bar (void *addr, size_t length)
> {
>   if (addr != (void *) &c)
> return -1;
>   return 0;
> }
> or so?  If yes, can you also drop errno from the testcase, and possibly drop
> unnecessary arguments to foo and/or bar as long as it reproduces?  Once
> minimized that way, please preprocess it.

Can't reduce it down so there is no munmap().  I suspect this is because going
across the syscall layer means there's some naked asm involved to call the real
munmap().

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #5 from Iain Buclaw  ---
(In reply to H.J. Lu from comment #3)
> .L8:
>   subl$8, %esp
>   .cfi_def_cfa_offset 16
>   movq%rdi, %rsi   << It should be movl %edi, %esi
>   shrq$32, %rdi
>   callmunmap
>   addl$8, %esp
>   .cfi_def_cfa_offset 8

Confirmed on my end, if I compile with -O1 -mx32 -S, and make this change, the
call succeeds.

[Bug target/94542] New: test gcc/testsuite/gcc.dg/tls/pr24428-2.c generates incorrect code on ppc64le with -mpcrel -mcpu=future -O2

[acsawdey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94542

Bug ID: 94542
   Summary: test gcc/testsuite/gcc.dg/tls/pr24428-2.c generates
incorrect code on ppc64le with -mpcrel -mcpu=future
-O2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---

The test case is:

__thread double thrtest[81];
int main ()
{
  double *p, *e;
  e = &thrtest[81];
  for (p = &thrtest[0]; p < e; ++p)
*p = 1.0;
  return 0;
}

Generated code for p and e is

paddi 9,13,thrtest@tprel
pla 8,thrtest+648@pcrel

The second should also be using a @tprel relocation. Because it didn't, the
loop runs off the end of allocated memory and segfaults. This test runs
correctly when compiled with -O0.

Compile command:

/home2/sawdey/work/gcc/mamboCI/build-mambo/gcc/xgcc
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/gcc/
/home2/sawdey/work/gcc/mamboCI/pike-trunk/gcc/testsuite/gcc.dg/tls/pr24428-2.c
-O2 -mpcrel -mcpu=future -S -o pr24428-2.exe.s

[Bug target/94542] test gcc/testsuite/gcc.dg/tls/pr24428-2.c generates incorrect code on ppc64le with -mpcrel -mcpu=future -O2

[acsawdey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94542

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |acsawdey at gcc dot 
gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-09
 Ever confirmed|0   |1

[Bug target/87163] ICE in extract_insn, at recog.c:2305

[seurer at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163

--- Comment #15 from Bill Seurer  ---
Martin, are you expecting this build to have 64 bit or 128 bit long doubles? 
The default should be 128 as it is natively but for some reason the cross
compiler is using 64.  Even with that, though, the compiler shouldn't be
ICEing.

I tested and if you add --with--long-double-128 the cross compiler will behave
the same as a native compiler and the ICE won't occur.

[Bug target/93932] PowerPC vec_extract with variable element number has code regressions for V2DI/V2DF vectors

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93932

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Michael Meissner
:

https://gcc.gnu.org/g:892c755eae2e2e45547395013695fdd819c297fa

commit r9-8486-g892c755eae2e2e45547395013695fdd819c297fa
Author: Michael Meissner 
Date:   Thu Apr 9 12:25:05 2020 -0500

Backport PR target/93932 (variable vec_extract) to GCC 9

2020-04-09  Michael Meissner  

Back port from trunk
2020-02-26  Michael Meissner  

PR target/93932
* config/rs6000/vsx.md (vsx_extract__var, VSX_D iterator):
Split the insn into two parts.  This insn only does variable
extract from a register.
(vsx_extract__var_load, VSX_D iterator): New insn, do
variable extract from memory.
(vsx_extract_v4sf_var): Split the insn into two parts.  This insn
only does variable extract from a register.
(vsx_extract_v4sf_var_load): New insn, do variable extract from
memory.
(vsx_extract__var, VSX_EXTRACT_I iterator): Split the insn
into two parts.  This insn only does variable extract from a
register.
(vsx_extract__var_load, VSX_EXTRACT_I iterator): New insn,
do variable extract from memory.

[Bug c++/94521] Infinite loop with decltype of function parameter of type decltype([]{})

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94521

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538

--- Comment #3 from Zdenek Sojka  ---
(In reply to Wilco from comment #2)
> This was introduced by commit e24f6408d so only in GCC10.

Thank you for checking this!

I am quite sure this fails in gcc-9 as well:

$ armv7a-hardfloat-linux-gnueabi-gcc -mcpu=cortex-m23 -mslow-flash-data
testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: error: insn does not satisfy its constraints:
9 | }
  | ^
(insn 91 90 17 (set (reg:SI 12 ip [125])
(plus:SI (reg:SI 12 ip [125])
(const_int 255 [0xff]))) "testcase.c":8:5 812 {*thumb1_addsi3}
 (expr_list:REG_EQUAL (const_int 4095 [0xfff])
(nil)))
during RTL pass: shorten
testcase.c:9:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2223
0x68bade _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-9-branch/gcc/rtl-error.c:108
0x68bb6b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-9-branch/gcc/rtl-error.c:118
0x67c6a2 extract_constrain_insn_cached(rtx_insn*)
/repo/gcc-9-branch/gcc/recog.c:2223
0x14555b3 insn_default_length(rtx_insn*)
/repo/gcc-9-branch/gcc/config/arm/arm.md:376
0xbc958e shorten_branches(rtx_insn*)
/repo/gcc-9-branch/gcc/final.c:1119
0xbc965f rest_of_handle_shorten_branches
/repo/gcc-9-branch/gcc/final.c:4754
0xbc965f execute
/repo/gcc-9-branch/gcc/final.c:4783
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-9-branch/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-9-branch/binary-9-branch-20200407210206-g14192f1ed48-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/9.3.1/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-9-branch//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-9-branch//binary-9-branch-20200407210206-g14192f1ed48-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 9.3.1 20200407 (GCC) 

Perhaps the offending commit, or part of it, was backported to gcc-9 as well?

[Bug target/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550

Richard Biener  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #5 from Richard Biener  ---
Just a wild guess that this might be fallout of all the param/expand reorg
around strict alignment correctness for arm.

John, are you set up to bisect the testcase with an additional -fno-ipa-sra
flag?

[Bug target/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550

--- Comment #6 from Richard Biener  ---
Might also be interesting to try other strict-align targets with -fno-ipa-sra.
But - this might also be a speciality of the callee-copy ABI of hpux.

[Bug ipa/94434] [AArch64][SVE] ICE caused by incompatibility of SRA and svst3 builtin-function

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434

--- Comment #3 from Martin Jambor  ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543658.html

[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538

--- Comment #4 from Wilco  ---
(In reply to Zdenek Sojka from comment #3)
> (In reply to Wilco from comment #2)
> > This was introduced by commit e24f6408d so only in GCC10.
> 
> Thank you for checking this!
> 
> I am quite sure this fails in gcc-9 as well:
...
> Perhaps the offending commit, or part of it, was backported to gcc-9 as well?

It's possible it was recently backported and our GCC9 builds don't yet have it.
But that whole patch is badly broken and introduces multiple issues...

[Bug target/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550

--- Comment #7 from dave.anglin at bell dot net ---
On 2020-04-09 1:53 p.m., rguenth at gcc dot gnu.org wrote:
> Might also be interesting to try other strict-align targets with -fno-ipa-sra.
> But - this might also be a speciality of the callee-copy ABI of hpux.
I agree. The test doesn't fail on linux which we changed to caller copy.

[Bug target/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550

--- Comment #8 from dave.anglin at bell dot net ---
On 2020-04-09 1:52 p.m., rguenth at gcc dot gnu.org wrote:
> John, are you set up to bisect the testcase with an additional -fno-ipa-sra
> flag?
I can bisect but not in a very automated way.

[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill  ---
(In reply to Patrick Palka from comment #5)
> Here is a rejects-valid testcase caused by the same underlying issue:

Actually, A does not have guaranteed copy elision in function argument passing
or return.  Which is a good thing, since it can't have it under the current
ABI.

http://eel.is/c++draft/class.temporary#3 

"When an object of class type X is passed to or returned from a function, if X
has at least one eligible copy or move constructor ([special]), each such
constructor is trivial, and the destructor of X is either trivial or deleted,
implementations are permitted to create a temporary object to hold the function
parameter or result object."

So I suppose my comment on Paolo's patch was wrong, and this is only a
diagnostic quality issue after all.

[Bug c++/94537] Possibly wrong code with mandatory copy elision and 'this' pointer resolution

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94537

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
As described in my patch for PR 94034, these testcases are not guaranteed to
work because A is trivially copyable and therefore the implementation can
introduce an extra temporary on return.

[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034

--- Comment #7 from Jason Merrill  ---
(In reply to Jason Merrill from comment #6)
> So I suppose my comment on Paolo's patch was wrong, and this is only a
> diagnostic quality issue after all.

Ah, there is a constexpr issue to fix: if we add constructors to A, we should
get guaranteed RVO, but still see the same bogus error.

struct A {
  A() = default; A(const A&);
  A *ap = this;
};
constexpr A foo() { return {}; }
static constexpr A a = foo(); // works without 'constexpr'
int main() {
  if (&a != a.ap)
__builtin_abort();
}

[Bug c++/94537] Possibly wrong code with mandatory copy elision and 'this' pointer resolution

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94537

--- Comment #4 from Jason Merrill  ---
(In reply to Jason Merrill from comment #3)
> As described in my patch for PR 94034, these testcases are not guaranteed to

s/patch/comment/

[Bug middle-end/94543] New: missed optimization with MIN and AND with type promotion

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94543

Bug ID: 94543
   Summary: missed optimization with MIN and AND with type
promotion
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

unsigned f(unsigned short x) { return (x > 0xff ? 0xff : x) & 0xff; }

cmpw$255, %di
movl$255, %eax
cmova   %eax, %edi
movzwl  %di, %eax
ret

The final AND is of course redundant.  The optimizer removes it
for wider types, but fails to do so when promoting from short.

[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:33c45e51b4914008064d9b77f2c1fc0eea1ad060

commit r10-7665-g33c45e51b4914008064d9b77f2c1fc0eea1ad060
Author: Jakub Jelinek 
Date:   Thu Apr 9 21:21:24 2020 +0200

cselib, var-tracking: Improve debug info after the cselib sp tracking
changes [PR94495]

On the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495#c5
testcase GCC emits worse debug info after the PR92264 cselib.c
changes.
The difference at -O2 -g -dA in the assembly is (when ignoring debug info):
# DEBUG g => [argp]
# DEBUG k => [argp+0x20]
# DEBUG j => [argp+0x18]
# DEBUG a => di
# DEBUG b => si
# DEBUG c => dx
# DEBUG d => cx
# DEBUG h => [argp+0x8]
# DEBUG e => r8
# DEBUG i => [argp+0x10]
# DEBUG f => r9
...
 .LVL4:
+   # DEBUG h => [sp+0x10]
+   # DEBUG i => [sp+0x18]
+   # DEBUG j => [sp+0x20]
+   # DEBUG k => [sp+0x28]
# DEBUG c => entry_value
 # SUCC: EXIT [always]  count:1073741824 (estimated locally)
ret
 .LVL5:
+   # DEBUG k => [argp+0x20]
# DEBUG a => bx
# DEBUG b => si
# DEBUG c => dx
# DEBUG d => cx
# DEBUG e => r8
# DEBUG f => r9
+   # DEBUG h => [argp+0x8]
+   # DEBUG i => [argp+0x10]
+   # DEBUG j => [argp+0x18]
This means that before the changes, h, i, j, k could be all expressed
in DW_AT_location directly with DW_OP_fbreg , but now we need
to use a location list, where in the first part of the function and last
part of the function (everything except the ret instruction) we use that
DW_OP_fbreg , but for the single ret instruction we instead
say those values live in something pointed by stack pointer + offset.
It is true, but only because stack pointer + offset is equal to DW_OP_fbreg
 at that point.

The var-tracking pass has for !frame_pointer_needed functions code to
canonicalize stack pointer uses in the insns before it hands it over
to cselib to cfa_base_rtx + offset depending on the stack depth at each
point.  The problem is that on the last epilogue pop insn (the one right
before ret) the canonicalization is sp = argp - 8 and add_stores records
a MO_VAL_SET operation for that argp - 8 value (which is the
SP_DERIVED_VALUE_P VALUE the cselib changes canonicalize sp based accesses
on) and thus var-tracking from that point onwards tracks that that VALUE
(2:2) now lives in sp.  At the end of function it of course needs to forget
it again (or it would need on any changes to sp).  But when processing
that uop, we note that the VALUE has changed and anything based on it
changed too, so emit changes for everything.  Before that var-tracking
itself doesn't track it in any register, so uses cselib and cselib knows
through the permanent equivs how to compute it using argp (i.e. what
will be DW_OP_fbreg).

The following fix has two parts.  One is it detects if cselib can compute
a certain VALUE using the cfa_base_rtx and for such VALUEs doesn't add
the MO_VAL_SET operation, as it is better to express them using
cfa_base_rtx
rather than temporarily through something else.  And the other is make sure
we reuse in !frame_pointer_needed the single SP_DERIVED_VALUE_P VALUE in
other extended basic blocks too (and other VALUEs) too.  This can be done
because we have computed the stack depths at the start of each basic block
in vt_stack_adjustments and while cselib_reset_table is called at the end
of each extended bb, which throws away all hard registers (but the magic
cfa_base_rtx) and so can hint cselib.c at the start of the ebb what VALUE
the sp hard reg has.  That means fewer VALUEs during var-tracking and more
importantly that they will all have the cfa_base_rtx + offset equivalency.

I have performed 4 bootstraps+regtests (x86_64-linux and i686-linux,
each with this patch (that is the new cselib + var-tracking variant) and
once with that patch reverted as well as all other cselib.c changes from
this month; once that bootstrapped, I've reapplied the cselib.c changes and
this patch and rebuilt cc1plus, so that the content is comparable, but
built
with the pre-Apr 2 cselib.c+var-tracking.c (that is the old cselib one)).

Below are readelf -WS cc1plus | grep debug_ filtered to only have debug
sections whose size actually changed, followed by dwlocstat results on
cc1plus.  This shows that there was about 3% shrink in those .debug*
sections for 32-bit and 1% shrink for 64-bit, with minor variable coverage
changes one or the other way that are IMHO insignificant.

32-bit old c

[Bug target/52565] __builtin_va_arg(va, double); may fail on cortex-m3

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52565

Christophe Lyon  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||clyon at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Christophe Lyon  ---
(In reply to Ravaz from comment #0)
[...]
> The instruction at 0x810c forces the address used for the ldrd to be
> alligned to an 8 bytes boundary. The problem is that the double parameter is
> passed on register r2-r3 and pushed on the stack at the entry point of 
> vargTest function. Since the stack is aligned on 4 bytes boundary only the
> double value may be misaligned and as a consequence the
> __builtin_va_arg(vaList, double) function fails to retrive the correct
> value. 
> 
> Is this a bug?

AFAIC, the ARM ABI (AAPCS) mandates that the stack is aligned on 8 bytes, so
r2/r3 are pushed on an 8 bytes boundary.

For the record, today's trunk generates (-O0):

vargTest:
@ args = 4, pretend = 16, frame = 16
@ frame_needed = 1, uses_anonymous_args = 1
@ link register save eliminated.
push{r0, r1, r2, r3}
str fp, [sp, #-4]!
add fp, sp, #0
sub sp, sp, #20
add r3, fp, #8
str r3, [fp, #-16]
ldr r3, [fp, #-16]
add r3, r3, #7
bic r3, r3, #7
add r2, r3, #8
str r2, [fp, #-16]
ldrdr2, [r3]
strdr2, [fp, #-12]
ldrdr2, [fp, #-12]
mov r0, r2
mov r1, r3
add sp, fp, #0
@ sp needed
ldr fp, [sp], #4
add sp, sp, #16
bx  lr

and -O2:
vargTest:
@ args = 4, pretend = 16, frame = 8
@ frame_needed = 0, uses_anonymous_args = 1
@ link register save eliminated.
push{r0, r1, r2, r3}
sub sp, sp, #8
add r3, sp, #19
add r2, sp, #12
bic r3, r3, #7
ldrdr0, [r3]
str r2, [sp, #4]
add sp, sp, #8
@ sp needed
add sp, sp, #16
bx  lr


So I think this is invalid.

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #6 from H.J. Lu  ---
It was caused by r5-901:

commit acea91c9012e211283130eb486d83243bcbbb327
Author: Martin Jambor 
Date:   Mon May 26 17:36:00 2014 +0200

ira.c (split_live_ranges_for_shrink_wrap): Remove bailout on subreg uses.

2014-05-26  Martin Jambor  

* ira.c (split_live_ranges_for_shrink_wrap): Remove bailout on
subreg uses.

From-SVN: r210936

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

H.J. Lu  changed:

   What|Removed |Added

   Assignee|hjl.tools at gmail dot com |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359

--- Comment #11 from Iain Sandoe  ---
Created attachment 48251
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48251&action=edit
Patch for testing

coroutines: Fix compile error with symmetric transfers [PR94359]

For symmetric transfers to work with C++20 coroutines, it is
currently necessary to tail call the callee coroutine from resume
method of the caller coroutine.  The current codegen marks these
resume calls as "MUST_TAIL_CALL" to indicate that the tail call is
required for correctness, in the general case.

Unfortunately, several targets have ABI constraints that prevent
an indirect tail-call, which results in the PRs compile error.

The change here tests the target sibcall hook for the resume
expression and only marks it as requiring a tail call if that's
supported.

This doesn't fix the underlying problem; that really a solution is
needed to allow the tail-calls (or equivalent) to take place - but
that will be deferred until next stage 1.

The test case is 'xfail-run-if'd for the targets mentioned in this
PR since we still want to test that the compile proceeds without
error.  At compile-time we can't tell if missing the tail-call will
cause a specific code to fail, so that most likely a warning for this
case would produce a lot of false positives.


gcc/cp/ChangeLog:

2020-04-09  Iain Sandoe  

PR c++/94359
* coroutines.cc (build_actor_fn): Check that the target can
support the resume tail-call before mandating it.

gcc/testsuite/ChangeLog:

2020-04-09  Iain Sandoe  

PR c++/94359
* g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:
Expect a run fail for targets without indirect tail-calls.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

H.J. Lu  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #7 from H.J. Lu  ---
After 284r.ira:

(insn 12 11 13 3 (parallel [
(set (reg:DI 88)
(lshiftrt:DI (reg/v:DI 85 [ b ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "y.i":14:14 639 {*lshrdi3_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 13 12 14 3 (set (reg:SI 4 si)
(subreg:SI (reg/v:DI 85 [ b ]) 0)) "y.i":14:14 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 85 [ b ])
(nil)))
(insn 14 13 15 3 (set (reg:DI 5 di)
(reg:DI 88)) "y.i":14:14 66 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 88)
(nil)))

After 285r.reload:

(insn 32 11 12 3 (set (reg:DI 5 di [88])
(reg/v:DI 4 si [orig:85 b ] [85])) "y.i":14:14 66 {*movdi_internal}
 (nil))
(insn 12 32 15 3 (parallel [
(set (reg:DI 5 di [88])
(lshiftrt:DI (reg:DI 5 di [88])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "y.i":14:14 639 {*lshrdi3_1}
 (nil))

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #8 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #7)
> After 284r.ira:

That is fine according to the rules as long as TARGET_TRULY_NOOP_TRUNCATION  is
true.

[Bug c++/94149] __is_constructible doesn't know about C++20 parenthesized init for arrays

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94149

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch, rejects-valid

--- Comment #4 from Marek Polacek  ---
Patch posted:

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #9 from H.J. Lu  ---
I am testing this:

diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c
index 0caa4acd3b5..bd4ee80245d 100644
--- a/gcc/lra-spills.c
+++ b/gcc/lra-spills.c
@@ -844,9 +844,14 @@ lra_final_code_change (void)

  struct lra_static_insn_data *static_id = id->insn_static_data;
  bool insn_change_p = false;
+ set = single_set (insn);

+ /* NB: Never change SUBREG in the source operand of a SET
+insn to REG.  */
  for (i = id->insn_static_data->n_operands - 1; i >= 0; i--)
if ((DEBUG_INSN_P (insn) || ! static_id->operand[i].is_operator)
+   && (set == NULL
+   || !rtx_equal_p (SET_SRC (set), *id->operand_loc[i]))
&& alter_subregs (id->operand_loc[i], ! DEBUG_INSN_P (insn)))
  {
lra_update_dup (id, i);
@@ -855,7 +860,7 @@ lra_final_code_change (void)
  if (insn_change_p)
lra_update_operator_dups (id);

- if ((set = single_set (insn)) != NULL
+ if (set != NULL
  && REG_P (SET_SRC (set)) && REG_P (SET_DEST (set))
  && REGNO (SET_SRC (set)) == REGNO (SET_DEST (set)))
{

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #10 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to H.J. Lu from comment #7)
> > After 284r.ira:
> 
> That is fine according to the rules as long as TARGET_TRULY_NOOP_TRUNCATION 
> is true.

We can't turn

(insn 13 12 14 3 (set (reg:SI 4 si)
(subreg:SI (reg/v:DI 85 [ b ]) 0)) "y.i":14:14 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 85 [ b ])
(nil)))

into


(insn 13 12 14 3 (set (reg:SI 4 si)
(reg:SI 4 si [orig:85 b ] [85])) "y.i":14:14 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
(nil)))

This is simple wrong.

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #11 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #10)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to H.J. Lu from comment #7)
> > > After 284r.ira:
> > 
> > That is fine according to the rules as long as TARGET_TRULY_NOOP_TRUNCATION 
> > is true.
> 
> We can't turn
> 
> (insn 13 12 14 3 (set (reg:SI 4 si)
> (subreg:SI (reg/v:DI 85 [ b ]) 0)) "y.i":14:14 67 {*movsi_internal}
>  (expr_list:REG_DEAD (reg/v:DI 85 [ b ])
> (nil)))
> 
> into
> 
> 
> (insn 13 12 14 3 (set (reg:SI 4 si)
> (reg:SI 4 si [orig:85 b ] [85])) "y.i":14:14 67 {*movsi_internal}
>  (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
> (nil)))
> 
> This is simple wrong.

How is that wrong?  What register was 85 assigned to?  4?
Then is fully correct as TARGET_TRULY_NOOP_TRUNCATION is true for those sizes.  

On MIPS,  TARGET_TRULY_NOOP_TRUNCATION is false for SI/DI truncation.
You need TARGET_TRULY_NOOP_TRUNCATION to be false for those sizes and you get a
truncate RTL instead of the subreg.  subreg means the upper bits of the
register are undefined.

[Bug c++/94523] [10 Regression] error: 'constexpr' evaluation depth exceeds maximum of 512 (use '-fconstexpr-depth=' to increase the maximum) since r10-7490-g76f09260b7eccd6c

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94523

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:ef529765234bea7893bd56f3ab3a2da7695f6b21

commit r10-7669-gef529765234bea7893bd56f3ab3a2da7695f6b21
Author: Jason Merrill 
Date:   Wed Apr 8 23:59:30 2020 -0400

c++: constexpr static data member instantiation [PR94523]

Here due to my recent change to store_init_value we were expanding the
initializer of aw knowing that we were initializing aw.  When
cxx_eval_call_expression finished the constructor, it wanted to look up the
value of aw to set TREE_READONLY on it, but we haven't set DECL_INITIAL
yet,
so decl_constant_value tried to instantiate the initializer again.  And
infinite recursion.  Stopped by optimizing the case of asking for the value
of ctx->object, which is ctx->value.  It also would have worked to look in
the values hash table, so let's move that up before decl_constant_value as
well.

gcc/cp/ChangeLog
2020-04-09  Jason Merrill  

PR c++/94523
* constexpr.c (cxx_eval_constant_expression) [VAR_DECL]: Look at
ctx->object and ctx->global->values first.

[Bug fortran/87923] ICE in gfc_widechar_to_char, at fortran/scanner.c:198

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87923

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Fritz Reese :

https://gcc.gnu.org/g:44facdb79f2d96ea8f5f93cfd440b3d0351d9bdb

commit r10-7670-g44facdb79f2d96ea8f5f93cfd440b3d0351d9bdb
Author: Fritz Reese 
Date:   Thu Apr 9 16:55:44 2020 -0400

PR fortran/87923 -- fix ICE when resolving I/O tags and simplify io.c

2020-04-06  Fritz Reese  

This patch reorganizes I/O checking code. Checks which were done in the
matching phase which do not affect the match result are moved to the
resolution phase. Checks which were duplicated in both the matching phase
and resolution phase have been reduced to one check in the resolution
phase.

Another section of code which used a global async_io_dt flag to check for
and assign the asynchronous attribute to variables used in asynchronous I/O
has been simplified.

Furthermore, this patch improves error reporting and expands test coverage
of I/O tags:

 - "TAG must be an initialization expression" reported by io.c
   (check_io_constraints) is replaced with an error from expr.c
   (gfc_reduce_init_expr) indicating _why_ the expression is not a valid
   initialization expression.

 - Several distinct error messages regarding the check for scalar
   + character + default kind have been unified to one message reported by
   resolve_tag or check_*_constraints.

gcc/fortran/ChangeLog:

2020-04-09  Fritz Reese  

PR fortran/87923
* gfortran.h (gfc_resolve_open, gfc_resolve_close): Add
locus parameter.
(gfc_resolve_dt): Add code parameter.
* io.c (async_io_dt, check_char_variable, is_char_type): Removed.
(resolve_tag_format): Add locus to error message regarding
zero-sized array in FORMAT tag.
(check_open_constraints, check_close_constraints): New functions
called at resolution time.
(gfc_match_open, gfc_match_close, match_io): Move checks which
don't
affect the match result to new functions check_open_constraints,
check_close_constraints, check_io_constraints.
(gfc_resolve_open, gfc_resolve_close): Call new functions
check_open_constraints, check_close_constraints after all tags have
been independently resolved.  Remove duplicate constraints which
are
already verified by resolve_tag. Explicitly pass locus to all error
reports.
(compare_to_allowed_values): Add locus parameter and provide
explicit locus all error reports.
(match_open_element, match_close_element, match_file_element,
match_dt_element, match_inquire_element): Remove redundant special
cases for ASYNCHRONOUS and IOMSG tags.
(gfc_resolve_dt): Remove redundant special case for format
expression.  Call check_io_constraints, forwarding an I/O list as
the io_code parameter if present.
(check_io_constraints): Change return type to bool. Pass explicit
locus to error reports. Move generic checks after tag-specific
checks, since errors are no longer buffered.  Move simplification
of
format string to match_io.  Remove redundant checks which are
verified by resolve_tag.  Remove usage of async_io_dt flag and
explicitly mark symbols used in asynchronous I/O with the
asynchronous attribute.
* resolve.c (resolve_transfer, resolve_fl_namelist): Remove checks
for async_io_dt flag. This is now done in io.c
(check_io_constraints).
(gfc_resolve_code): Pass code locus to gfc_resolve_open,
gfc_resolve_close, gfc_resolve_dt.

gcc/testsuite/ChangeLog:

2020-04-09  Fritz Reese  

PR fortran/87923
* gfortran.dg/f2003_io_8.f03: Fix expected error messages.
* gfortran.dg/io_constraints_8.f90: Likewise.
* gfortran.dg/iomsg_2.f90: Likewise.
* gfortran.dg/pr66725.f90: Likewise.
* gfortran.dg/pr88205.f90: Likewise.
* gfortran.dg/write_check4.f90: Likewise.
* gfortran.dg/asynchronous_5.f03: New test.
* gfortran.dg/io_constraints_15.f90: Likewise.
* gfortran.dg/io_constraints_16.f90: Likewise.
* gfortran.dg/io_constraints_17.f90: Likewise.
* gfortran.dg/io_constraints_18.f90: Likewise.
* gfortran.dg/io_tags_1.f90: Likewise.
* gfortran.dg/io_tags_10.f90: Likewise.
* gfortran.dg/io_tags_2.f90: Likewise.
* gfortran.dg/io_tags_3.f90: Likewise.
* gfortran.dg/io_tags_4.f90: Likewise.
* gfortran.dg/io_tags_5.f90: Likewise.
* gfortran.dg/io_tags_6.f90: Likewise.
* gfortran.dg/io_tags_7.f90: Likewise.
* gfortran.dg/i

[Bug fortran/87923] ICE in gfc_widechar_to_char, at fortran/scanner.c:198

[foreese at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87923

Fritz Reese  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Fritz Reese  ---
Fixed on master.

[Bug middle-end/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

--- Comment #12 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to H.J. Lu from comment #10)
> > (In reply to Andrew Pinski from comment #8)
> > > (In reply to H.J. Lu from comment #7)
> > > > After 284r.ira:
> > > 
> > > That is fine according to the rules as long as 
> > > TARGET_TRULY_NOOP_TRUNCATION 
> > > is true.
> > 
> > We can't turn
> > 
> > (insn 13 12 14 3 (set (reg:SI 4 si)
> > (subreg:SI (reg/v:DI 85 [ b ]) 0)) "y.i":14:14 67 {*movsi_internal}
> >  (expr_list:REG_DEAD (reg/v:DI 85 [ b ])
> > (nil)))
> > 
> > into
> > 
> > 
> > (insn 13 12 14 3 (set (reg:SI 4 si)
> > (reg:SI 4 si [orig:85 b ] [85])) "y.i":14:14 67 {*movsi_internal}
> >  (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
> > (nil)))
> > 
> > This is simple wrong.
> 
> How is that wrong?  What register was 85 assigned to?  4?
> Then is fully correct as TARGET_TRULY_NOOP_TRUNCATION is true for those
> sizes.  
> 
> On MIPS,  TARGET_TRULY_NOOP_TRUNCATION is false for SI/DI truncation.
> You need TARGET_TRULY_NOOP_TRUNCATION to be false for those sizes and you
> get a truncate RTL instead of the subreg.  subreg means the upper bits of
> the register are undefined.

In this case, upper bits in 85 are undefined:

(insn 13 12 14 3 (set (reg:SI 4 si)
(subreg:SI (reg/v:DI 4 si [orig:85 b ] [85]) 0)) "y.i":14:14 67
{*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
(nil)))

LRA has:

 for (i = id->insn_static_data->n_operands - 1; i >= 0; i--)
if ((DEBUG_INSN_P (insn) || ! static_id->operand[i].is_operator)
&& alter_subregs (id->operand_loc[i], ! DEBUG_INSN_P (insn)))
  {
lra_update_dup (id, i);
insn_change_p = true;
  }
  if (insn_change_p)
lra_update_operator_dups (id);

  if ((set = single_set (insn)) != NULL
  && REG_P (SET_SRC (set)) && REG_P (SET_DEST (set))
  && REGNO (SET_SRC (set)) == REGNO (SET_DEST (set)))
{
  /* Remove an useless move insn.  IRA can generate move
 insns involving pseudos.  It is better remove them
 earlier to speed up compiler a bit.  It is also
 better to do it here as they might not pass final RTL
 check in LRA, (e.g. insn moving a control register
 into itself).  */
  lra_invalidate_insn_data (insn);
  delete_insn (insn);
}

But

(insn 13 12 14 3 (set (reg:SI 4 si)
(subreg:SI (reg/v:DI 4 si [orig:85 b ] [85]) 0)) "y.i":14:14 67
{*movsi_internal}
 (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
(nil)))

isn't useless and shouldn't be removed.

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #13 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #12)
> 
> But
> 
> (insn 13 12 14 3 (set (reg:SI 4 si)
> (subreg:SI (reg/v:DI 4 si [orig:85 b ] [85]) 0)) "y.i":14:14 67
> {*movsi_internal}
>  (expr_list:REG_DEAD (reg/v:DI 4 si [orig:85 b ] [85])
> (nil)))
> 
> isn't useless and shouldn't be removed.

It is useless because TARGET_TRULY_NOOP_TRUNCATION is true.  So the problem is
you don't have a zero_extend in the RTL in the first place where you needed it
to be.
THIS IS NOT A BUG in the middle-end.

[Bug c++/94544] New: aarch64 stlr and single total order

[wypelniamkonta at wp dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94544

Bug ID: 94544
   Summary: aarch64 stlr and single total order
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wypelniamkonta at wp dot pl
  Target Milestone: ---

Per https://en.cppreference.com/w/cpp/atomic/memory_order

"std::memory_order specifies how memory accesses, including regular, non-atomic
memory accesses, are to be ordered around an atomic operation."

and

"memory_order_seq_cst ... plus a single total order exists in which all threads
observe all modifications in the same order"

I conducted a test on Cortex-72 (rpi4) and:

struct Atoms
{
std::atomic a = 0;
uint64_t space1[3];
uint64_t b = 0;
uint64_t space2[3];
std::atomic c = 0;
};

Atoms at;

core 1:
for (int i=0;i<1000;i++)
{
at.a.store(i, std::memory_order_seq_cst);
at.b = i;
at.c.store(i, std::memory_order_seq_cst);
}

   99198:   c89ffc01stlrx1, [x0]
   9919c:   f981str x1, [x4]
   991a0:   c89ffc61stlrx1, [x3]


core 0:

while (core1.isRunning()
{
dmb();
int a = at.a.load(std::memory_order_relaxed);
dmb();
int b = at.b;
dmb();
if (aa.store(i, std::memory_order_seq_cst);
dmb();
at->b = i;
at->c.store(i, std::memory_order_seq_cst);

It of course works, but I don't think that original code hits "single total
order exists" requirement.

(similar topic with ldar)

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #14 from H.J. Lu  ---
It is an x32 kernel bug.  These system calls:

   int mprotect(void *addr, size_t len, int prot);
   void *mmap(void *addr, size_t length, int prot, int flags,
  int fd, off_t offset);
   int munmap(void *addr, size_t length);

take both void *, off_t and size_t.  They need special conversions
since they can't use LP64 nor IA32 versions.

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94541

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=207187
 Resolution|INVALID |MOVED

[Bug target/94544] aarch64 stlr and single total order

[wypelniamkonta at wp dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94544

--- Comment #1 from Paweł Różański  ---
Ahh Sequentially-consistent ordering only between tagged atomic, so i suppose
this is expected.

[Bug libstdc++/94545] New: std::to_integer(std::numeric_limits::max()) returns 0

[thomas.mercier.jr at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94545

Bug ID: 94545
   Summary: std::to_integer(std::numeric_limits::m
ax()) returns 0
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.mercier.jr at gmail dot com
  Target Milestone: ---

Created attachment 48252
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48252&action=edit
Preprocessed file

$ g++ -v -save-temps -std=c++17 test.cc
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE test.cc -mtune=generic -march=x86-64 -std=c++1z
-fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o test.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/7
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cc -mtune=generic -march=x86-64 -auxbase test -std=c++1z
-version -fstack-protector-strong -Wformat -Wformat-security -o test.s
GNU C++14 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3eb3dc290cd5714c3e1c3ae751116f07
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o test.o test.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
-plugin-opt=-fresolution=test.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie -z

[Bug tree-optimization/94482] [8/9 Regression] Inserting into vector with optimization enabled on x86 generates incorrect result

[e...@coeus-group.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482

--- Comment #25 from Evan Nemerson  ---
Created attachment 48253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48253&action=edit
Similar test which fails on armv7

I'm also getting an error on armv7-a for the same original code
()
when compiling with -O1 or above and -fstack-protector-strong.  I'm not sure if
it's the same issue or not; Jakub's test case from comment #12 doesn't abort
with the same target and flags.

I'm attaching a test test case which does trigger the issue on armv7.  If it
would be better to open a new bug just let me know, and if it has already been
fixed sorry for the noise :(

Here is the output from GCC with -v:

Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/10/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 10-20200324-1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --without-target-system-zlib
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf-
--includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200324 (experimental) [master revision
596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536] (Debian
10-20200324-1) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Werror' '-O1' '-fstack-protector-strong' 
'-o' 'insert-pp' '-shared-libgcc' '-mfloat-abi=hard' '-mfpu=vfpv3-d16'
'-mthumb' '-mtls-dialect=gnu' '-march=armv7-a+fp'
 /usr/lib/gcc-cross/arm-linux-gnueabihf/10/cc1plus -quiet -v -imultilib .
-imultiarch arm-linux-gnueabihf -D_GNU_SOURCE insert-pp.c -quiet -dumpbase
insert-pp.c -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu
-march=armv7-a+fp -auxbase insert-pp -O1 -Wall -Werror -version
-fstack-protector-strong -o /tmp/ccwvIVRJ.s
GNU C++14 (Debian 10-20200324-1) version 10.0.1 20200324 (experimental) [master
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]
(arm-linux-gnueabihf)
compiled by GNU C version 10.0.1 20200324 (experimental) [master
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536], GMP
version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version
isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc-cross/arm-linux-gnueabihf/10/include-fixed"
#include "..." search starts here:
#include <...> search starts here:

/usr/lib/gcc-cross/arm-linux-gnueabihf/10/../../../../arm-linux-gnueabihf/include/c++/10

/usr/lib/gcc-cross/arm-linux-gnueabihf/10/../../../../arm-linux-gnueabihf/include/c++/10/arm-linux-gnueabihf/.

/usr/lib/gcc-cross/arm-linux-gnueabihf/10/../../../../arm-linux-gnueabihf/include/c++/10/backward
 /usr/lib/gcc-cross/arm-linux-gnueabihf/10/include

/usr/lib/gcc-cross/arm-linux-gnueabihf/10/../../../../arm-linux-gnueabihf/include
 /usr/include/arm-linux-gnueabihf
 /usr/include
End of search list.
GNU C++14 (Debian 10-20200324-1) version 10.0.1 20200324 (experimental) [master
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]
(arm-linux-gnueabihf)
compiled by GNU C version 10.0.1 20200324 (experimental) [master
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536], GMP
version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version
isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f8090281bdf780936f7dd6668f41be1f
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Werror' '-O1' '-fstack-protector-strong' 
'-o' 'insert-pp' '-shared-libgcc' '-mfloat-abi=hard' '-mfpu=vfpv3-d16'
'-mthumb' '-mtls-dialect=gnu' '-march=armv7-a+fp'

/usr/lib/gcc-cross/arm-linux-gnueabihf/10/../../../../arm-linux-gnueabihf/bin/as
-v -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -meabi=5 -o /tmp/cck1klAL.o
/tmp/ccwvIVRJ.s
GNU assembler version 2.34 (arm-linux-gnueabihf) using BFD version (GNU
Binutils for Debian) 2.34
COMPILER_PATH=/us