[Bug target/70314] AVX512 not using kandw to combine comparison results

[crazylht at gmail dot com]

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

--- Comment #6 from Hongtao.liu  ---
Same issue mentioned in PR88808

[Bug target/96493] New: powerpc local call linkage failure

[amodra at gmail dot com]

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

Bug ID: 96493
   Summary: powerpc local call linkage failure
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

/* -O2 -mcpu=power8 */
static int __attribute__ ((target("cpu=power10"),noclone,noinline))
local_func (int x)
{
  return x;
}

int main()
{
  return local_func (0);
}

results in a linker complaint "call to `local_func' lacks nop, can't restore
toc; (toc save/adjust stub)".

rs6000.md call_local et al patterns can't be allowed to match when
caller/callee disagree about r2 usage.

[Bug bootstrap/96492] New: : internal compiler error: Segmentation fault

[townsend at astro dot wisc.edu]

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

Bug ID: 96492
   Summary: : internal compiler error: Segmentation
fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I'm attempting to build 10.2 from within a Docker container based on Centos
5.11, which ships with glibc 2.5 and gcc 4.1.2. (The reason I'm doing this is
I'm building a gcc-based SDK that should be able to run on crusty old systems).

I'm configuring with the following options:

../gcc/configure --build=x86_64-pc-linux-gnu
--prefix=/home/user/sdk2-tmp/mesasdk --with-mpc=/home/user/sdk2-tmp/mesasdk
--with-mpfr=/home/user/sdk2-tmp/mesasdk --with-gmp=/home/user/sdk2-tmp/mesasdk
--disable-multilib --disable-nls --disable-libsanitizer
--enable-languages=c,c++,fortran

During the build (make -j), I get ICEs:

/home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc
-B/home/user/sdk2-tmp/build/gcc-build/./gcc/ -xc -nostdinc /dev/null -S -o
/dev/null -fself-test=../../gcc/gcc/testsuite/selftests
: internal compiler error: Segmentation fault
: internal compiler error: Segmentation fault
/home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc
-B/home/user/sdk2-tmp/build/gcc-build/./gcc/ -xc++ -nostdinc /dev/null -S -o
/dev/null -fself-test=../../gcc/gcc/testsuite/selftests
: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [s-selftest-c] Error 1
make[3]: *** Waiting for unfinished jobs
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
/bin/sh ../../gcc/gcc/../move-if-change tmp-macro_list macro_list
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [s-selftest-c++] Error 1
echo timestamp > s-macro_list
rm gfortran.pod gcc.pod
make[3]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build'
make: *** [all] Error 2

Full build log is attached.

cheers,

Rich

[Bug target/70314] AVX512 not using kandw to combine comparison results

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #5 from Hongtao.liu  ---
(In reply to Marc Glisse from comment #4)
> We now generate for the original testcase
> 
>   vpcmpd  $1, %zmm3, %zmm2, %k1
>   vpcmpd  $1, %zmm1, %zmm0, %k0{%k1}
>   vpmovm2d%k0, %zmm0
> 
> which looks great.
> 
> However, using | instead of &, we get
> 
>   vpcmpd  $1, %zmm1, %zmm0, %k0
>   vpcmpd  $1, %zmm3, %zmm2, %k1
>   kmovw   %k0, %eax
>   kmovw   %k1, %edx
>   orl %edx, %eax
>   kmovw   %eax, %k2

Yes, korw %k0, %k1, %k2 should be used
i'll take a look.

>   vpmovm2d%k2, %zmm0
> 
> Well, at least gimple did what it could, and it is now up to the target to
> handle logical operations on bool vectors / k* registers. There is probably
> already another bug report about that...

[Bug tree-optimization/96491] New: [11 Regression] ICE: tree check: expected ssa_name, have integer_cst in add_phi_arg, at tree-phinodes.c:373

[asolokha at gmx dot com]

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

Bug ID: 96491
   Summary: [11 Regression] ICE: tree check: expected ssa_name,
have integer_cst in add_phi_arg, at
tree-phinodes.c:373
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200802 snapshot (g:6e46b3f3da5c03bc529b3690dd0995927feb9142)
ICEs when compiling the following testcase w/ -O1:

int rj;

void __attribute__ ((returns_twice))
da (void)
{
  rj = 1;
}

void
c5 (void)
{
  for (;;)
++rj;
}

void
ls (int kz)
{
  if (kz == 0)
{
  rj = 0;
  c5 ();
}

  da ();
  c5 ();
}

% gcc-11.0.0 -O1 -c qqdrbiy8.c
during GIMPLE pass: sink
qqdrbiy8.c: In function 'ls':
qqdrbiy8.c:17:1: internal compiler error: tree check: expected ssa_name, have
integer_cst in add_phi_arg, at tree-phinodes.c:373
   17 | ls (int kz)
  | ^~
0x707146 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree.c:9687
0x6be83b tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree.h:3303
0x6be83b add_phi_arg(gphi*, tree_node*, edge_def*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-phinodes.c:373
0xf997e1 sink_common_stores_to_bb
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-ssa-sink.c:594
0xf997e1 sink_code_in_bb
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-ssa-sink.c:656
0xf98cea sink_code_in_bb
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-ssa-sink.c:743
0xf98cea sink_code_in_bb
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-ssa-sink.c:743
0xf9a5ce execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-ssa-sink.c:824

[Bug c/96468] Warn when an empty while loop could have been a do-while

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|tree-optimization   |c

--- Comment #6 from Martin Sebor  ---
Oh.  So you're just looking for a simple lexical check to see if a while
statement is preceded by a block { } and a warning if it is and (presumably)
isn't the result of macro expansion.  E.g., issue a warning here:

  void f (void)
  {
{ debug ("in f ()"); }
while (!signaled);   // warn
  }

but not here (:

  void f (void)
  {
DEBUG   // expands to { debug (...); }
while (!signaled);   // don't warn
  }

That should be simpler and doable in the front end (so back to C for component)
but also seems considerably less useful to me as well as more prone to noise. 

Front end isn't really my area so I don't expect to work on this but a couple
of questions occur to me: should blank lines between the closing curly or the
while have any effect on the warnig?  If yes as I would expect it starts to
feel like it's in the same area as -Wmisleading-indentation.  What about other
iteration statements -- should those be considered as well?

  while (condition);   // warning? (spurious semicolon)
  { }

  for (...; condition; ...);   // ditto
  { }

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

[gu...@henkel-wallace.org]

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

--- Comment #5 from DV Henkel-Wallace  ---
(In reply to Jonathan Wakely from comment #4)
> I believe the rationale for this is that if your <=> can't be defaulted,
> then it must be doing something special, and synthesizing == from it is not
> necessarily safe.

The thing is: properly written user defined operator <=> is supposed to to be
"correct" (whatever that would mean!) for all of the < 0, = 0, and > 0 cases. 
It doesn't make sense to presume that a user defined <=> would only apply to
the < and > cases -- in fact how could it otherwise synthesize <= and => ?

(More jocularly it's not `operator <>` -- would we call that the submarine
operator?)

In fact I just changed my test case to use `((a <=> b) != 0)` and it did what I
expected.

> Clang agrees with GCC FWIW.

Yes, reported it to them too :-(

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I believe the rationale for this is that if your <=> can't be defaulted, then
it must be doing something special, and synthesizing == from it is not
necessarily safe.

If <=> is defaulted, then it does the "obvious" thing and so synthesizing == to
do the obvious thing is probably OK.

If <=> is user-provided but you know that an implicitly-defined operator==
would do the right thing, define operator== as defaulted.

Clang agrees with GCC FWIW.

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to DV Henkel-Wallace from comment #2)
> I don't think this should be marked as resolved.  The bug is not the case
> you cited which indeed works properly as specified.
> 
> The bug is that comparators are not being synthesized when the a *user
> supplied* operator<=> is defined.

They're not supposed to be, because as I quoted above, the == operator is only
sythesized when <=> is defined as defaulted.

> I believe this case is [class.spaceship] case (1.1).  Although that case
> does reference [class.compare.default], it talks about the spaceship
> operator being "usable" which is defined, via clause (3), to have a defined
> binary operator of appropriate types -- _not_ claiming that only the `=
> default` case applies.
> 
> 
> More pragmatically the user will expect that their explicit definition of
> <=> will result in unspecified comparisons being synthesized.  Else why
> define it in the first place?

Because you get the < > <= >= operators for free.

But you only get == for free if <=> is defined as defaulted, and you only get
!= for free if == exists.

I think to get what you expect, you need to either define <=> as defaulted, or
define == as defaulted.

If you have a user-provided operator<=> and no operator== declared, then you
get no ==.

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
https://gcc.gnu.org/g:1f9ceff11132

-ftree-coalesce-vars it sounds like?  But that isn't a 1-1 replacement
probably (or, what was the point of this change otherwise?)

[Bug c++/96490] New: Template code with function pointers fails with very cryptic error message

[khim at google dot com]

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

Bug ID: 96490
   Summary: Template code with function pointers fails with very
cryptic error message
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khim at google dot com
  Target Milestone: ---

The following code works with all other compilers: https://godbolt.org/z/Mv3xsn

template
class TagType;

int foo();
constexpr auto foo_ptr = 

template
int test();

int bar() {
return test>();
}

int baz() {
return test>();

But GCC reports very cryptic error:

could not convert template argument 'foo_ptr' from 'int (* const)()' to 'int (*
const)()'

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[mikpelinux at gmail dot com]

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

--- Comment #3 from Mikael Pettersson  ---
(In reply to Segher Boessenkool from comment #2)
> That option was removed in GCC 6, already.

Oh.  Do you know if they added a replacement or just dropped the functionality
altogether?

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

[gu...@henkel-wallace.org]

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

--- Comment #2 from DV Henkel-Wallace  ---
I don't think this should be marked as resolved.  The bug is not the case you
cited which indeed works properly as specified.

The bug is that comparators are not being synthesized when the a *user
supplied* operator<=> is defined.

I believe this case is [class.spaceship] case (1.1).  Although that case does
reference [class.compare.default], it talks about the spaceship operator being
"usable" which is defined, via clause (3), to have a defined binary operator of
appropriate types -- _not_ claiming that only the `= default` case applies.


More pragmatically the user will expect that their explicit definition of <=>
will result in unspecified comparisons being synthesized.  Else why define it
in the first place?

[Bug tree-optimization/91882] boolean XOR tautology missed optimisation

[sucicf1 at outlook dot com]

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

--- Comment #5 from Ivan Sučić  ---
I have added in match.pd a simplify. But for unknown reason it doesn't get
applied.  Anybody knows why?

[Bug tree-optimization/91882] boolean XOR tautology missed optimisation

[sucicf1 at outlook dot com]

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

Ivan Sučić  changed:

   What|Removed |Added

 CC||sucicf1 at outlook dot com

--- Comment #4 from Ivan Sučić  ---
I have added im match.pd a simplify. But fir unknown reason IT doesn't het
applied.  Anybody knows why?

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
This is correct, [class.compare.default] p5 says:

If the member-specification does not explicitly declare any member or friend
named operator==, an == operator function is declared implicitly for each
three-way comparison operator function defined as defaulted in the
member-specification

[Bug c++/96489] New: Three way comparison operator failure to synthesize traditional comparitors

[gu...@henkel-wallace.org]

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

Bug ID: 96489
   Summary: Three way comparison operator failure to synthesize
traditional comparitors
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gu...@henkel-wallace.org
  Target Milestone: ---

User-defined <=> doesn't generate == or != though user-defined operator== and
operator<=> = default do.

/usr/local/opt/gcc/bin/g++-10   -std=c++20 foo.cc && ./a.out
foo.cc: In function 'int main()':
foo.cc:21:9: error: no match for 'operator!=' (operand types are 'foo' and
'foo')
   21 |   if (a != b) std::cout << "not ";
  |   ~ ^~ ~
  |   ||
  |   foo  foo
foo.cc:25:11: error: no match for 'operator==' (operand types are 'foo' and
'foo')
   25 |   if (!(a == c)) std::cout << "not ";
  | ~ ^~ ~
  | ||
  | foo  foo

#include 

struct foo {
int content;
foo(int x) : content { x } {}

  // works: auto operator <=> (foo const& rhs) const = default;
  // works: auto operator ==  (foo const& rhs) const { return content == 
rhs.content; }
  // fails: 
auto operator <=> (foo const& rhs) const { return content <=>
rhs.content; }
};

int main() {
  foo a { 1 };
  foo b { 2 };
  foo c { 1 };

  if (a != b) std::cout << "not ";
  std::cout  << "equal" << std::endl;


  if (!(a == c)) std::cout << "not ";
  std::cout  << "equal" << std::endl;

  return 0;

Result:

/usr/local/opt/gcc/bin/g++-10   -std=c++20 foo.cc && ./a.out
foo.cc: In function 'int main()':
foo.cc:21:9: error: no match for 'operator!=' (operand types are 'foo' and
'foo')
   21 |   if (a != b) std::cout << "not ";
  |   ~ ^~ ~
  |   ||
  |   foo  foo
foo.cc:25:11: error: no match for 'operator==' (operand types are 'foo' and
'foo')
   25 |   if (!(a == c)) std::cout << "not ";
  | ~ ^~ ~
  | ||
  | foo  foo

[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-08-05
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/96282] [8/9/10/11 Regression] internal compiler error: in output_constructor_regular_field

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-2580-gd21252de6c81ed236d8981d47b9a57dc4f1c6d57
Author: Patrick Palka 
Date:   Wed Aug 5 15:05:30 2020 -0400

c++: cxx_eval_vec_init after zero-initialization [PR96282]

In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.

So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.

This patch fixes this issue by truncating a zero-initialized array
CONSTRUCTOR in cxx_eval_vec_init_1 before we begin appending array
elements to it.  We propagate its zeroed out state during evaluation by
clearing CONSTRUCTOR_NO_CLEARING on each new appended aggregate element.

gcc/cp/ChangeLog:

PR c++/96282
* constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
then clear CONSTRUCTOR_NO_CLEARING on each appended element
initializer if we're initializing a previously zero-initialized
array object.

gcc/testsuite/ChangeLog:

PR c++/96282
* g++.dg/cpp0x/constexpr-array26.C: New test.
* g++.dg/cpp0x/constexpr-array27.C: New test.
* g++.dg/cpp2a/constexpr-init18.C: New test.

Co-authored-by: Jason Merrill 

[Bug fortran/96469] Compile-time check for change in DO variable in contained procedures

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug fortran/96469] Compile-time check for change in DO variable in contained procedures

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

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

commit r11-2579-gdd30d93f1a3ead7b814c1b179cf7197e4bf1e183
Author: Thomas Koenig 
Date:   Wed Aug 5 20:53:44 2020 +0200

Added test case to make sure that legal cases still pass.

gcc/testsuite/ChangeLog:

PR fortran/96469
* gfortran.dg/do_check_14.f90: New test.

[Bug ada/96488] New: Long time failures of gnat.dg/unchecked_convert5.adb and gnat.dg/unchecked_convert6.adb

[seurer at gcc dot gnu.org]

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

Bug ID: 96488
   Summary: Long time failures of gnat.dg/unchecked_convert5.adb
and gnat.dg/unchecked_convert6.adb
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

FAIL: gnat.dg/unchecked_convert5.adb execution test
FAIL: gnat.dg/unchecked_convert6.adb execution test


These failures date back a LONG time, at least into early r9 range.

They are referenced here:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44892


Executing on host: /home/seurer/gcc/git/build/gcc-ada/gcc/gnatmake
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
--GNATBIND=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatbind
--GNATLINK=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatlink -cargs
-B/home/seurer/gcc/git/build/gcc-ada/gcc -largs
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc\
-B/home/seurer/gcc/git/build/gcc-ada/gcc\  -margs
--RTS=/home/seurer/gcc/git/build/gcc-ada/powerpc64le-unknown-linux-gnu/./libada
-q -f /home/seurer/gcc/git/gcc-ada/gcc/testsuite/gnat.dg/unchecked_convert5.adb
  -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -lm  -o ./unchecked_convert5.exe(timeout =
300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-ada/gcc/gnatmake
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
--GNATBIND=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatbind
--GNATLINK=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatlink -cargs
-B/home/seurer/gcc/git/build/gcc-ada/gcc -largs
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-ada/gcc  -margs
--RTS=/home/seurer/gcc/git/build/gcc-ada/powerpc64le-unknown-linux-gnu/./libada
-q -f /home/seurer/gcc/git/gcc-ada/gcc/testsuite/gnat.dg/unchecked_convert5.adb
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -lm -o ./unchecked_convert5.exe^M
unchecked_convert5.adb:9:03: warning: types for unchecked conversion have
different sizes^M
Executing on host: /home/seurer/gcc/git/build/gcc-ada/gcc/gnatclean -c -q -n
./unchecked_convert5   (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-ada/gcc/gnatclean -c -q -n
./unchecked_convert5^M
./unchecked_convert5.ali^M
./unchecked_convert5.o^M
PASS: gnat.dg/unchecked_convert5.adb  (test for warnings, line 9)
PASS: gnat.dg/unchecked_convert5.adb (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-ada/gcc::/home/seurer/gcc/git/build/gcc-ada/gcc:/home/seurer/gcc/git/build/gcc-ada/./gmp/.libs:/home/seurer/gcc/git/build/gcc-ada/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-ada/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-ada/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-ada/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-ada/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-ada/./isl/.libs:/home/seurer/gcc/git/build/gcc-ada/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]^M

raised PROGRAM_ERROR : unchecked_convert5.adb:19 explicit raise
FAIL: gnat.dg/unchecked_convert5.adb execution test
UNSUPPORTED: gnat.dg/unchecked_convert5b.adb
Executing on host: /home/seurer/gcc/git/build/gcc-ada/gcc/gnatmake
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
--GNATBIND=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatbind
--GNATLINK=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatlink -cargs
-B/home/seurer/gcc/git/build/gcc-ada/gcc -largs
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc\
-B/home/seurer/gcc/git/build/gcc-ada/gcc\  -margs
--RTS=/home/seurer/gcc/git/build/gcc-ada/powerpc64le-unknown-linux-gnu/./libada
-q -f /home/seurer/gcc/git/gcc-ada/gcc/testsuite/gnat.dg/unchecked_convert6.adb
  -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -lm  -o ./unchecked_convert6.exe(timeout =
300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-ada/gcc/gnatmake
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
--GNATBIND=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatbind
--GNATLINK=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatlink -cargs
-B/home/seurer/gcc/git/build/gcc-ada/gcc -largs
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-ada/gcc  -margs
--RTS=/home/seurer/gcc/git/build/gcc-ada/powerpc64le-unknown-linux-gnu/./libada
-q -f /home/seurer/gcc/git/gcc-ada/gcc/testsuite/gnat.dg/unchecked_convert6.adb
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -lm -o ./unchecked_convert6.exe^M
unchecked_convert6.adb:9:03: warning: types for unchecked conversion have
different sizes^M
Executing on host: /home/seurer/gcc/git/build/gcc-ada/gcc/gnatclean -c -q -n
./unchecked_convert6   (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-ada/gcc/gnatclean -c -q -n

[Bug fortran/96486] get_environment_variable fails for zero-length values

[kargl at gcc dot gnu.org]

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

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Susi Lehtola from comment #10)
> Compiled with -g, rerun gives
> 
> $ ./a.out 
> Fortran runtime error: Zero-length string passed as value to
> get_environment_variable.
> 
> Error termination. Backtrace:
> #0  0x401267 in zerolen_value
>   at /tmp/readvar2.f90:17
> #1  0x4012c4 in main
>   at /tmp/readvar2.f90:22
> 
> This is the second call.
> 
> The problem originates in
> https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgfortran/intrinsics/env.
> c;hb=HEAD where the size checks are in an incorrect order.

Sorry, I don't understand what you mean by incorrect order.

Can you please run a.out under gdb and post the backtrace

% gdb ./a.out
(gdb) run

[Bug fortran/96486] get_environment_variable fails for zero-length values

[jussilehtola at fedoraproject dot org]

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

--- Comment #10 from Susi Lehtola  ---
Compiled with -g, rerun gives

$ ./a.out 
Fortran runtime error: Zero-length string passed as value to
get_environment_variable.

Error termination. Backtrace:
#0  0x401267 in zerolen_value
at /tmp/readvar2.f90:17
#1  0x4012c4 in main
at /tmp/readvar2.f90:22

This is the second call.

The problem originates in
https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgfortran/intrinsics/env.c;hb=HEAD
where the size checks are in an incorrect order.

[Bug c++/96485] Lambda parsing regression in GCCs 9 and onwards

[s_gccbugzilla at nedprod dot com]

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

--- Comment #3 from Niall Douglas  ---
(In reply to Jakub Jelinek from comment #2)
> [[gnu::no_sanitize_undefined]] instead of the GNU __attribute__ is accepted,
> but as the C++ specification requires it applies to the type not the
> declaration and therefore it is ignored.

Obviously the above is an extract from production code. We were using lambdas
to wrap individual bits of unsafe code which trips the UB sanitiser. It would
be useful to retain that ability, as having to sprinkle the code with:

struct { auto operator()(auto...) const __attribute__((no_sanitize_undefined))
{ } }()(...); 

... seems retrograde.

[Bug tree-optimization/96487] New: cddce1 optimizer depends on order of basic blocks

[sandra at gcc dot gnu.org]

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

Bug ID: 96487
   Summary: cddce1 optimizer depends on order of basic blocks
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49007=edit
c and c++ dump files

If the test case gcc.dg/tree-ssa/ssa-dce-3.c is compiled as C++ code
instead of as C, it fails to reduce to an empty loop as expected.

It seems to be triggered by a slight difference in the input coming
into the cddce1 pass.  The C front end canonicalizes the test to the
end of the loop so the latch (bb 5) falls through to the header (bb
6).  The C++ front end orders the latch (bb 6) last with a goto to the
header (bb 3).

I did some additional tracing of the flow through the pass beyond the
dump file output.  Because the latch in the C input does not end with
a control statement, it is ignored by mark_last_stmt_necessary, via
the call to mark_control_dependent_edges_necessary at the end of
find_obviously_necessary_stmts.  So in the C case, nothing gets added
to the work list, while for C++ it does process the latch block,
follow the control flow out of it, and ends up marking the loop end
test etc as necessary.

I am wondering if this is a bug in the way the C output is handled and
it is incorrectly optimizing away the loop body.  It seems like it
should not matter if the control transfer between blocks is done via
explicit goto or via fallthrough, anyway; either it ought to handle
the fallthrough case like the explicit goto case, or vice versa.

I originally noticed this problem in conjunction with these patches to
unify the loop handling in the C and C++ front ends:

https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534142.html

But it can be reproduced with unmodified sources just by compiling
with g++ instead of gcc.  The commands used to produce the attached
dump files were

x86_64-linux-gnu-gcc /path/to/gcc/testsuite/gcc.dg/tree-ssa/ssa-dce-3.c  -O2
-fdump-tree-dse1 -fdump-tree-cddce1-details -S

x86_64-linux-gnu-g++ /path/to/gcc/testsuite/gcc.dg/tree-ssa/ssa-dce-3.c  -O2
-fdump-tree-dse1 -fdump-tree-cddce1-details -S

[Bug fortran/96486] get_environment_variable fails for zero-length values

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #5)
> (In reply to Susi Lehtola from comment #4)
> > $ export HOSTNAME=foo
> > $ ./a.out 
> > $
> > 
> > $ export HOSTNAME=
> > $ ./a.out 
> > Fortran runtime error: Zero-length string passed as value to
> > get_environment_variable.
> > 
> > Error termination. Backtrace:
> > #0  0x7f25c93aadf1 in ???
> > #1  0x7f25c93ab939 in ???
> > #2  0x7f25c93abe60 in ???
> > #3  0x7f25c960ce53 in ???
> > #4  0x401267 in ???
> > #5  0x4012c4 in ???
> > #6  0x7f25c903a041 in __libc_start_main
> > at ../csu/libc-start.c:308
> > #7  0x4010ad in ???
> > #8  0x in ???
> > $
> 
> Thanks.
> 
> What gfortran version and operating system?  I get
> 
> % gfcx -o z b.f90 && ./z
> STOP System variable unassigned
> % gfcx -o z -g b.f90 && ./z
> STOP System variable unassigned
> % gfcx -o z -g -O b.f90 && ./z
> STOP System variable unassigned
> 
> with your code where gfcx is gfortran 10.0.0 (Jan 2020 vintage)
> and I'm using i585-*-freebsd.

Whoops.  Misread part of bug report. With tcsh, I see

% setenv HOSTNAME ''
% gfcx -o z -g -O b.f90 && ./z
Fortran runtime error: Zero-length string passed as value to
get_environment_variable.

and

unsetenv HOSTNAME
% setenv HOSTNAME
% gfcx -o z -g -O b.f90 && ./z
Fortran runtime error: Zero-length string passed as value to
get_environment_variable.

No backtrace.  Can you compile with -g, run the executable under gdb,
and post the backtrace.

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
That option was removed in GCC 6, already.

[Bug fortran/96486] get_environment_variable fails for zero-length values

[jussilehtola at fedoraproject dot org]

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

--- Comment #8 from Susi Lehtola  ---
(In reply to kargl from comment #5)
> What gfortran version and operating system?  I get
> 
> % gfcx -o z b.f90 && ./z
> STOP System variable unassigned
> % gfcx -o z -g b.f90 && ./z
> STOP System variable unassigned
> % gfcx -o z -g -O b.f90 && ./z
> STOP System variable unassigned
> 
> with your code where gfcx is gfortran 10.0.0 (Jan 2020 vintage)
> and I'm using i585-*-freebsd.

This is
$ gfortran --version
GNU Fortran (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1)
Copyright (C) 2020 Free Software Foundation, Inc.

[Bug c++/96485] Lambda parsing regression in GCCs 9 and onwards

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
[[gnu::no_sanitize_undefined]] instead of the GNU __attribute__ is accepted,
but as the C++ specification requires it applies to the type not the
declaration and therefore it is ignored.

[Bug fortran/96486] get_environment_variable fails for zero-length values

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> I do note there are other problems with get_environment_variable.
> 
> 1) Neither length nor status can be integer(1).  gfortran should issue
>an error.
> 
> 2) Fortran 2018 has added an optional errmsg argument.  This is not
>supported.
> 
> 3) gfortran is issuing errors that don't make sence (to me).
> 
> program foo
>integer( 1) i01
>integer( 2) i02
>integer( 4) i04
>integer( 8) i08
> #ifdef __GFC_INT_16__
>integer(16) i16
> #endif
>character(len=20) name
> 
>print '(A,I0)', 'range(i01) = ', range(i01)
>print '(A,I0)', 'range(i02) = ', range(i02)
>print '(A,I0)', 'range(i04) = ', range(i04)
>print '(A,I0)', 'range(i08) = ', range(i08)
> #ifdef __GFC_INT_16__
>print '(A,I0)', 'range(i16) = ', range(i16)
> #endif
> 
>name = ''
>! Although valid Fortran, this should probably raise a warning.
>call get_environment_variable(name);
> 
>name = 'FOO'
>call get_environment_variable(name,length=i01);  ! Should be an error
>call get_environment_variable(name,length=i02);  ! Should be ok
>call get_environment_variable(name,length=i04);  ! Should be ok
>call get_environment_variable(name,length=i08);  ! Should be ok
> #ifdef __GFC_INT_16__
>call get_environment_variable(name,length=i16);  ! Should be ok
> #endif
> 
> end program foo
> 
> mobile:kargl[256] gfcx -o z a.F90 && ./z
> a.F90:29:45:
> 
>29 |call get_environment_variable(name,length=i01);  ! Should be an
> error
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(1)' to 'INTEGER(4)'
> a.F90:30:45:
> 
>30 |call get_environment_variable(name,length=i02);
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(2)' to 'INTEGER(4)'
> a.F90:32:45:
> 
>32 |call get_environment_variable(name,length=i08);
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(8)' to 'INTEGER(4)'

Need to add a gfc_check_get_environment_variable routine to get pass these
errors.

[Bug c++/96485] Lambda parsing regression in GCCs 9 and onwards

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This has changed in r265787.

[Bug fortran/96486] get_environment_variable fails for zero-length values

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
I do note there are other problems with get_environment_variable.

1) Neither length nor status can be integer(1).  gfortran should issue
   an error.

2) Fortran 2018 has added an optional errmsg argument.  This is not
   supported.

3) gfortran is issuing errors that don't make sence (to me).

program foo
   integer( 1) i01
   integer( 2) i02
   integer( 4) i04
   integer( 8) i08
#ifdef __GFC_INT_16__
   integer(16) i16
#endif
   character(len=20) name

   print '(A,I0)', 'range(i01) = ', range(i01)
   print '(A,I0)', 'range(i02) = ', range(i02)
   print '(A,I0)', 'range(i04) = ', range(i04)
   print '(A,I0)', 'range(i08) = ', range(i08)
#ifdef __GFC_INT_16__
   print '(A,I0)', 'range(i16) = ', range(i16)
#endif

   name = ''
   ! Although valid Fortran, this should probably raise a warning.
   call get_environment_variable(name);

   name = 'FOO'
   call get_environment_variable(name,length=i01);  ! Should be an error
   call get_environment_variable(name,length=i02);  ! Should be ok
   call get_environment_variable(name,length=i04);  ! Should be ok
   call get_environment_variable(name,length=i08);  ! Should be ok
#ifdef __GFC_INT_16__
   call get_environment_variable(name,length=i16);  ! Should be ok
#endif

end program foo

mobile:kargl[256] gfcx -o z a.F90 && ./z
a.F90:29:45:

   29 |call get_environment_variable(name,length=i01);  ! Should be an
error
  | 1
Error: In call to 'get_environment_variable' at (1), type mismatch in argument
length'; pass 'INTEGER(1)' to 'INTEGER(4)'
a.F90:30:45:

   30 |call get_environment_variable(name,length=i02);
  | 1
Error: In call to 'get_environment_variable' at (1), type mismatch in argument
length'; pass 'INTEGER(2)' to 'INTEGER(4)'
a.F90:32:45:

   32 |call get_environment_variable(name,length=i08);
  | 1
Error: In call to 'get_environment_variable' at (1), type mismatch in argument
length'; pass 'INTEGER(8)' to 'INTEGER(4)'

[Bug fortran/96486] get_environment_variable fails for zero-length values

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|WAITING |NEW

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Susi Lehtola from comment #4)
> $ export HOSTNAME=foo
> $ ./a.out 
> $
> 
> $ export HOSTNAME=
> $ ./a.out 
> Fortran runtime error: Zero-length string passed as value to
> get_environment_variable.
> 
> Error termination. Backtrace:
> #0  0x7f25c93aadf1 in ???
> #1  0x7f25c93ab939 in ???
> #2  0x7f25c93abe60 in ???
> #3  0x7f25c960ce53 in ???
> #4  0x401267 in ???
> #5  0x4012c4 in ???
> #6  0x7f25c903a041 in __libc_start_main
>   at ../csu/libc-start.c:308
> #7  0x4010ad in ???
> #8  0x in ???
> $

Thanks.

What gfortran version and operating system?  I get

% gfcx -o z b.f90 && ./z
STOP System variable unassigned
% gfcx -o z -g b.f90 && ./z
STOP System variable unassigned
% gfcx -o z -g -O b.f90 && ./z
STOP System variable unassigned

with your code where gfcx is gfortran 10.0.0 (Jan 2020 vintage)
and I'm using i585-*-freebsd.

[Bug fortran/96486] get_environment_variable fails for zero-length values

[jussilehtola at fedoraproject dot org]

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

--- Comment #4 from Susi Lehtola  ---
$ export HOSTNAME=foo
$ ./a.out 
$

$ export HOSTNAME=
$ ./a.out 
Fortran runtime error: Zero-length string passed as value to
get_environment_variable.

Error termination. Backtrace:
#0  0x7f25c93aadf1 in ???
#1  0x7f25c93ab939 in ???
#2  0x7f25c93abe60 in ???
#3  0x7f25c960ce53 in ???
#4  0x401267 in ???
#5  0x4012c4 in ???
#6  0x7f25c903a041 in __libc_start_main
at ../csu/libc-start.c:308
#7  0x4010ad in ???
#8  0x in ???
$

[Bug other/92396] -ftime-trace support

[jeremycong at gmail dot com]

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

jeremycong at gmail dot com changed:

   What|Removed |Added

 CC||jeremycong at gmail dot com

--- Comment #8 from jeremycong at gmail dot com ---
Anecdotally, this would be an amazing feature to have. Since enabling time
tracing in clang, I've been able to improve build times significantly for a
project that uses templates, but with the GCC time report information, I can't
seem to get GCC build times improved to the same degree. I definitely don't
think this feature is strictly useful for only the compiler developer.

[Bug fortran/96486] get_environment_variable fails for zero-length values

[jussilehtola at fedoraproject dot org]

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

--- Comment #3 from Susi Lehtola  ---
program zerolen_value
  implicit none
  character(len=*), parameter :: name='HOSTNAME'
  character(len=:), allocatable :: value
  integer :: l, err
  call get_environment_variable(name,length=l,status=err)
  if (err.ne.0) then
 stop 'System variable unassigned'
  endif
  allocate( character(len=l) :: value, stat=err )
  if (err.ne.0) then
 stop 'Variable could not be allocated'
  endif
  ! If the environment variable has not been set, l=0, and the  
  ! following get_environment_variable call crashes.
!  if (l.gt.0) then 
  call get_environment_variable(name,value,status=err)
  if (err.ne.0) then
 stop 'System variable corrupted'
  endif
! endif 
end program zerolen_value

[Bug fortran/96469] Compile-time check for change in DO variable in contained procedures

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

https://gcc.gnu.org/g:27eac9ee6137a6b5ae693b54cafa22bdc0cbcd5a

commit r11-2578-g27eac9ee6137a6b5ae693b54cafa22bdc0cbcd5a
Author: Thomas Koenig 
Date:   Wed Aug 5 18:37:32 2020 +0200

Static analysis for definition of DO index variables in contained
procedures.

When encountering a procedure call in a DO loop, this patch checks if
the call is to a contained procedure, and if it is, check for
changes in the index variable.

gcc/fortran/ChangeLog:

PR fortran/96469
* frontend-passes.c (doloop_contained_function_call): New
function.
(doloop_contained_procedure_code): New function.
(CHECK_INQ): Macro for inquire checks.
(doloop_code): Invoke doloop_contained_procedure_code and
doloop_contained_function_call if appropriate.
(do_intent): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/96469
* gfortran.dg/do_check_4.f90: Hide change in index variable
from compile-time analysis.
* gfortran.dg/do_check_13.f90: New test.

[Bug d/96153] d: struct literals have non-deterministic hash values

[ibuclaw at gdcproject dot org]

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

--- Comment #4 from Iain Buclaw  ---
Created attachment 49006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49006=edit
inline memset

(In reply to Iain Buclaw from comment #3)
> (In reply to Rainer Orth from comment #2)
> > The new test FAILs on 64-bit Solaris/SPARC:
> > 
> > The test PASSes with -O0 and -Os, as well as with -m32.
> 
> Thanks, I've checked Linux/SPARC64 and see the same thing.

DSE is removing the call to memset as dead code, so the optimizer is not
understanding the hint.

Inlining the memset using a bunch of MEM_REFs yields the correct result, and
infact the optimizer is able to fully const-fold the hash computation at -O3 so
all assert contracts are removed.

Though not sure about the approach, are there any pitfalls to this?

This is what optimized trees look like at -O1 and -O2 levels, with comments
inserted describing which bits are set.

x86_64 -O1:
  // 0..128 = 0
  MEM  [(uint128_t *)] = 0B;
  // 128..192 = 0
  MEM[(ulong *) + 16B] = 0B;
  // 0..32 = 12
  D.4244.payload = 12;
  // 128..160 = 4294967295
  D.4244.hook.var2 = 4294967295;
  // 64..128 = 18446744073709551615
  D.4244.hook.var1 = 18446744073709551615;

x86_64 -O2:
  // 0..64 = 12
  MEM  [(void *)] = 12;
  // 64..128 = 18446744073709551615
  D.4244.hook.var1 = 18446744073709551615;
  // 128..192 = 4294967295
  MEM  [(void *) + 16B] = 4294967295;

SPARC64 -O1:
  // 0..128 = 51539607552
  MEM  [(void *)] = 51539607552B;
  // 64..128 = 18446744073709551615
  MEM  [(void *) + 8B] = 18446744073709551615;
  // 128..192 = -4294967296
  MEM  [(void *) + 16B] = -4294967296B;

SPARC -O2
  // 0..128 = 51539607552
  MEM  [(void *)] = 51539607552B;
  // 64..128 = 18446744073709551615
  MEM  [(void *) + 8B] = 18446744073709551615;
  // 128..192 = -4294967296
  MEM  [(void *) + 16B] = -4294967296B;


Both SPARC and x86_64 yield the same hash values.

  assert(-1444610504 != -1444610503);
  assert(-1444610503 == -1444610503);

[Bug fortran/96486] get_environment_variable fails for zero-length values

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-08-05

[Bug fortran/96486] get_environment_variable fails for zero-length values

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Could you please provide an example?

[Bug fortran/96486] get_environment_variable fails for zero-length values

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Source code?

[Bug fortran/96486] New: get_environment_variable fails for zero-length variables

[jussilehtola at fedoraproject dot org]

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

Bug ID: 96486
   Summary: get_environment_variable fails for zero-length
variables
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jussilehtola at fedoraproject dot org
  Target Milestone: ---

get_environment_variable checks for zero-length value strings before it checks
the length of the result string.

In the case of zero-length result strings, a zero-length value string should be
perfectly acceptable.

[Bug tree-optimization/96468] Warn when an empty while loop could have been a do-while

[josephcsible at gmail dot com]

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

--- Comment #5 from Joseph C. Sible  ---
I didn't have termination checking in mind at all for this. I envisioned the
warning triggering any time a "while" loop's body was just a semicolon, when
the "while" isn't the first statement in its block.

[Bug tree-optimization/96468] Warn when an empty while loop could have been a do-while

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c   |tree-optimization

--- Comment #4 from Martin Sebor  ---
I see.  In that case, I don't think such a warning can be implemented in the
front end (as suggested by the choice of the Component) because if signaled
were neither atomic nor volatile (and not a function call as in your new
example) the only way to determine whether the loop might terminate is by
analyzing the potential accesses in the body of the prior block for those to
it.  Such analysis is beyond what the C front end can handle.  For example, in

  int signaled;

  void f (double *a)
  {
{
  for (int i = 0; i != 7; ++i)
a[i] = 0;
}
while (!signaled);

including the block in the loop wouldn't make it finite but the front end can't
easily determine that.

My point is that issuing a warning suggesting the while loop might have been
intended to be a do-while would be misleading, as would be suggesting to
rewrite the loop as "while (!signaled) { }"  This is not a concern if the
condition accesses an atomic/volatile object or is a call to a
non-const/non-pure function which is readily available in the front end.  For
others, the warning would need to do quite a bit more work.  With that, I'll
change the component to tree-optimization where I believe implementing this
might be more feasible.

So just to be clear, I'm not objecting to the request, just clarifying what it
asks for and how difficult it might be implement.

[Bug target/96446] ICE when spilling an MMA accumulator

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #2)
> *movpxi tries to not split xxsetaccz insns, but that one is only for
> fpr_reg_operand as operands[0], while *movpxi uses something more
> general.

As we discussed offline, I have already moved xxsetaccz into the movpxi pattern
and I changed the xxsetaccz pattern (needed for the builtin expansion) into a
define_expand that just calls gen_movpxi.  This fixes the ICE above.  However,
I've hit a somewhat related issue with both __vector_pair and __vector_quad
vars being passed as a parameter to an unprototyped function leading to another
ICE or infinite loop.  I'm still digging into that.

[Bug libstdc++/96484] Horrible performance of std::read_symlink

[terra at gnome dot org]

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

--- Comment #1 from M Welinder  ---
I should note that not only does it allocate 500M, it also zeroes it.

[Bug libstdc++/96484] Horrible performance of std::read_symlink

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/95906] Failure to recognize max pattern with mask

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
With the patch (which only affects vectors), f becomes (a>b)?a:b. It should be
easy to add the corresponding transform to MAX_EXPR in match.pd.

[Bug c/96468] Warn when an empty while loop could have been a do-while

[josephcsible at gmail dot com]

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

--- Comment #3 from Joseph C. Sible  ---
I didn't intend to restrict this to only volatile control variables. If you
have "_Bool canMoveOn(void);", I'd like "while(!canMoveOn());" in place of
"while(!signaled);" to warn too for the exact same reasons.

[Bug target/70314] AVX512 not using kandw to combine comparison results

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
We now generate for the original testcase

vpcmpd  $1, %zmm3, %zmm2, %k1
vpcmpd  $1, %zmm1, %zmm0, %k0{%k1}
vpmovm2d%k0, %zmm0

which looks great.

However, using | instead of &, we get

vpcmpd  $1, %zmm1, %zmm0, %k0
vpcmpd  $1, %zmm3, %zmm2, %k1
kmovw   %k0, %eax
kmovw   %k1, %edx
orl %edx, %eax
kmovw   %eax, %k2
vpmovm2d%k2, %zmm0

Well, at least gimple did what it could, and it is now up to the target to
handle logical operations on bool vectors / k* registers. There is probably
already another bug report about that...

[Bug target/96446] ICE when spilling an MMA accumulator

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
*movpxi tries to not split xxsetaccz insns, but that one is only for
fpr_reg_operand as operands[0], while *movpxi uses something more
general.

[Bug c/96468] Warn when an empty while loop could have been a do-while

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
It's not clear whether the request is just for the specific case for while
loops with a volatile control variable or independent of the qualifier.  I
think issuing a warning in either case would be worthwhile but for different
reasons, and with different messages making a distinction between the kinds of
the potential problems.  (The mention of the suggestion to use
"while(condition){}" instead makes me think it might be the former.)

Thanks to the volatile access in the example in comment #0, the loop will
terminate once signaled is set but the intent may have been that it iterate
over the body of the preceding block.  signaled can be set either in one of the
calls in the block in some signal handler, or even in another thread (in
addition to being set prior to the block of course).

But in the absence of the volatile (and atomic) qualifier, unless the initial
value of signaled is non-zero the loop will never terminate regardless of any
extraneous accesses to it outside it because all but the first access to it in
the loop is eliminated:

  int signaled;

  void f (void)
  {
while (!signaled);
  }

[Bug tree-optimization/95906] Failure to recognize max pattern with mask

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Marc Glisse :

https://gcc.gnu.org/g:229752afe3156a3990dacaedb94c76846cebf132

commit r11-2577-g229752afe3156a3990dacaedb94c76846cebf132
Author: Marc Glisse 
Date:   Wed Aug 5 16:45:33 2020 +0200

VEC_COND_EXPR optimizations

When vector comparisons were forced to use vec_cond_expr, we lost a number
of optimizations (my fault for not adding enough testcases to
prevent that). This patch tries to unwrap vec_cond_expr a bit so some
optimizations can still happen.

I wasn't planning to add all those transformations together, but adding one
caused a regression, whose fix introduced a second regression,
etc.

Restricting to constant folding would not be sufficient, we also need at
least things like X|0 or X The transformations are quite
conservative with :s and folding only if everything simplifies, we may want
to relax this later. And of course we are going to miss things
like a?b:c + a?c:b -> b+c.

In terms of number of operations, some transformations turning 2
VEC_COND_EXPR into VEC_COND_EXPR + BIT_IOR_EXPR + BIT_NOT_EXPR might not look
like a gain... I expect the bit_not disappears in most cases, and
VEC_COND_EXPR looks more costly than a simpler BIT_IOR_EXPR.

2020-08-05  Marc Glisse  

PR tree-optimization/95906
PR target/70314
* match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
(v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): New transformations.
(op (c ? a : b)): Update to match the new transformations.

* gcc.dg/tree-ssa/andnot-2.c: New file.
* gcc.dg/tree-ssa/pr95906.c: Likewise.
* gcc.target/i386/pr70314.c: Likewise.

[Bug target/70314] AVX512 not using kandw to combine comparison results

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marc Glisse :

https://gcc.gnu.org/g:229752afe3156a3990dacaedb94c76846cebf132

commit r11-2577-g229752afe3156a3990dacaedb94c76846cebf132
Author: Marc Glisse 
Date:   Wed Aug 5 16:45:33 2020 +0200

VEC_COND_EXPR optimizations

When vector comparisons were forced to use vec_cond_expr, we lost a number
of optimizations (my fault for not adding enough testcases to
prevent that). This patch tries to unwrap vec_cond_expr a bit so some
optimizations can still happen.

I wasn't planning to add all those transformations together, but adding one
caused a regression, whose fix introduced a second regression,
etc.

Restricting to constant folding would not be sufficient, we also need at
least things like X|0 or X The transformations are quite
conservative with :s and folding only if everything simplifies, we may want
to relax this later. And of course we are going to miss things
like a?b:c + a?c:b -> b+c.

In terms of number of operations, some transformations turning 2
VEC_COND_EXPR into VEC_COND_EXPR + BIT_IOR_EXPR + BIT_NOT_EXPR might not look
like a gain... I expect the bit_not disappears in most cases, and
VEC_COND_EXPR looks more costly than a simpler BIT_IOR_EXPR.

2020-08-05  Marc Glisse  

PR tree-optimization/95906
PR target/70314
* match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
(v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): New transformations.
(op (c ? a : b)): Update to match the new transformations.

* gcc.dg/tree-ssa/andnot-2.c: New file.
* gcc.dg/tree-ssa/pr95906.c: Likewise.
* gcc.target/i386/pr70314.c: Likewise.

[Bug tree-optimization/96480] [8/9/10/11 Regression] missed optimisation: unnecessary compare in standard algorithms

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 49005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49005=edit
gcc11-pr96480.patch

Untested fix.

[Bug target/96191] aarch64 stack_protect_test canary leak

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-2576-gfe1a26429038d7cd17abc53f96a6f3e2639b605f
Author: Richard Sandiford 
Date:   Wed Aug 5 15:18:36 2020 +0100

aarch64: Clear canary value after stack_protect_test [PR96191]

The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function.  An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.

gcc/
PR target/96191
* config/aarch64/aarch64.md (stack_protect_test_): Set the
CC register directly, instead of a GPR.  Replace the original GPR
destination with an extra scratch register.  Zero out operand 3
after use.
(stack_protect_test): Update accordingly.

gcc/testsuite/
PR target/96191
* gcc.target/aarch64/stack-protector-1.c: New test.
* gcc.target/aarch64/stack-protector-2.c: Likewise.

[Bug c++/96485] New: Lambda parsing regression in GCCs 9 and onwards

[s_gccbugzilla at nedprod dot com]

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

Bug ID: 96485
   Summary: Lambda parsing regression in GCCs 9 and onwards
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

As the repro at https://godbolt.org/z/Gvx75e shows, the following code compiled
fine in GCCs up to and including GCC 8.3:

```
void test()
{
[]()
#if 1
__attribute__((no_sanitize_undefined))
#endif
->int {
return 0;
};
}
```

>From GCC 9 onwards, we get:

```
: In lambda function:
:7:5: error: expected '{' before '->' token
7 | ->int {
  | ^~
: In function 'void test()':
:7:5: error: base operand of '->' has non-pointer type
'test()::'
:7:7: error: expected unqualified-id before 'int'
7 | ->int {
  |   ^~~
Compiler returned: 1
```

This code compiles fine in clang, incidentally, though it doesn't recognise the
attribute.

[Bug c++/96474] Internal compiler error with template struct inside template struct

[lhlaurini at hotmail dot com]

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

--- Comment #2 from Luiz Henrique Laurini  ---
(In reply to Marek Polacek from comment #1)
> The ICE started with r278298.  Before that:
> 
> 96474.C:11:15: error: class template argument deduction failed:
>11 | A::B x;
>   |   ^
> 96474.C:11:15: error: no matching function for call to ‘B()’

Yes, sorry, forgot to add that error. Compiles fine with Clang though. I don't
see why it shouldn't.

[Bug libstdc++/96484] New: Horrible performance of std::read_symlink

[terra at gnome dot org]

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

Bug ID: 96484
   Summary: Horrible performance of std::read_symlink
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 49004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49004=edit
Preprocessed ttt.C

This program takes ~0.25s per round in the loop for a total of minutes.  It
should take millisecons in total.

To observe the problem, "foo" needs to be a large file -- more than 500M in my
case -- that is not a symlink.  Mine is on an NFS server.


#include 
#include 

namespace fs = std::filesystem;

int
main()
{
  for (int i = 0; i < 1000; i++) {
std::error_code ec;
std::cerr << i << ": " << fs::read_symlink ("foo", ec) << std::endl;
  }
}


The problem is in the implementation of read_symlink.  First an lstat call is
done (fine), but then the st_size field is used as a hint for the symlink's
size.  There is no check that the file is a symlink at this point, so in my
case a 500M buffer is allocated via an mmap system call and the kernel takes
its sweet time.

Note: a file with size 4G-1 on a 32-bit system might produce an infinite loop
as the buffer will have size 0 and get doubled from that.

Suggestion 1: if the lstat doesn't show a symlink, set the error code
right then and exit.

Suggestion 2: cap st_size at something reasonable and let the loop handle it if
it needs to be bigger.








# /usr/local/products/gcc/10.1.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/10.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/10.1.0/lib/gcc/x86_64-suse-linux/10.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-10.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/10.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.32/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.32/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC) 


# uname -a
Linux monsterd09 5.0.13-1-default #1 SMP Sun May 5 15:48:04 UTC 2019 (b11e2d7)
x86_64 x86_64 x86_64 GNU/Linux

[Bug c/96427] Missing align attribute for anchor section from local variables

[zhongyunde at huawei dot com]

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

vfdff  changed:

   What|Removed |Added

 CC||zhongyunde at huawei dot com

--- Comment #4 from vfdff  ---
I test your case base on x86-64 gcc 10.1 with -O2 -S -mavx512f, the .rodata
aligned to 64 bytes, and it aligned to 32 bytes on x86-64 gcc 9.3 with -O2 -S
-mavx512f, i.e. it have different behaviour base on different gcc version.

so it is a undefined behaviour ?

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[matz at gcc dot gnu.org]

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

--- Comment #11 from Michael Matz  ---
(In reply to rguent...@suse.de from comment #9)
> How do we represent sNaNs with -fnon-call-exceptions?  That is,

I think we're currently simply buggy at various stages as soon as sNaNs are
involved _and_ STDC FENV_ACCESS is ON.

>  y_1 = x_2 + 1.;
> 
> may trap.  Does
> 
>  foo (x_2);
> 
> get transformed to
> 
>  tem_3 = x_2;
>  foo (tem_3);
> 
> and the SSA assignment now traps dependent on whether the call
> ABI requires pushing x_2 to a stack slot (which might trap)?

If copying a sNaN (to registers or memory) signals an invalid-op depends on the
CPU (and is implementation defined in ieee754).  And GCC doesn't necessarily
preserve such signals even on CPUs that do signal (if there are any), because
it could e.g. use integer stores to transfer the bit patterns.

> sNaNs are odd anyway I guess.

> But yes, a pure function can still trap (and also throw).
> 
> I think we don't have a good notion for trappingness of calls
> and I do expect inconsistencies here.

__builtin_sqrtf isn't an arbitrary call.  FP operations aren't arbitrary
expressions.

We don't really have the problem of generating calls to arbitrary
arguments out of the blue, not even with non-throwing calls.  I'm not sure if
we should mix this problem here with that more generic problem.

Btw, that we if-convert calls to builtinf_sqrt is indeed a bug without
special options giving a license for that.  But doing that for the original
testcase instead of the division would _not_ be a problem on SVE: the inactive
lanes are zeroed and that doesn't signal anything for square root.

(We could perhaps extend the meaning of -fno-math-errno to give this license,
i.e. guarantee that the user hasn't enabled stops for any FP exceptions; but
that might be too aggressive).

[Bug c++/96443] Incorrect satisfaction value for dependent placeholder return type constraint

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-08-05

[Bug c++/96474] Internal compiler error with template struct inside template struct

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-08-05

--- Comment #1 from Marek Polacek  ---
The ICE started with r278298.  Before that:

96474.C:11:15: error: class template argument deduction failed:
   11 | A::B x;
  |   ^
96474.C:11:15: error: no matching function for call to ‘B()’

[Bug c++/96478] GCC accepts enum definition in alignas()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95935
   Last reconfirmed||2020-08-05

--- Comment #1 from Marek Polacek  ---
Related to 95935.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[matz at gcc dot gnu.org]

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

--- Comment #10 from Michael Matz  ---
(In reply to Andreas Schwab from comment #5)
> > Just note that _all_ floating point operations, not just divisions, can trap
> > (without fast-math).  You never know if the user enabled stops for any of
> > the FP exceptions (overflow, underflow, inexact, invalid op, div-by-zero). 
> 
> You need #pragma STDC FENV_ACCESS ON for that, otherwise it's undefined
> behaviour.

Sure, that's for operations that occur due to normal abstract machine
evaluations.  The point here is that we introduce operations that aren't in the
original
program (for the testcase on "array elements" after [10]), and if we do so
those
must be unobservable.  These pragmas don't give license to introduce additional
faults that can't possibly have happened in the abstract machine.  (To see
this, replace all arrays elements by 1.0, then the FP operations are all exact,
we still get SIGFPE).

[Bug tree-optimization/96483] ICE in code hoisting with AArch64 SVE2 intrinsics

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.3
  Known to fail||10.1.1, 11.0

[Bug tree-optimization/96483] New: ICE in code hoisting with AArch64 SVE2 intrinsics

[ktkachov at gcc dot gnu.org]

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

Bug ID: 96483
   Summary: ICE in code hoisting with AArch64 SVE2 intrinsics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

The following (reduced) testcase ICEs on aarch64 with
-O2 -w -march=armv8.2-a+sve2

GCC 10 and trunk ICE. Since the SVE2 intrinsics were introduced in GCC 10 it's
not a regression.

during GIMPLE pass: pre
red.c: In function 'u':
red.c:25:1: internal compiler error: in create_component_ref_by_pieces_1, at
tree-ssa-pre.c:2659
   25 | u () {
  | ^
0xfc03c8 create_component_ref_by_pieces_1
$SRC/gcc/tree-ssa-pre.c:2659
0xfbe4fc create_expression_by_pieces
$SRC/gcc/tree-ssa-pre.c:2795
0xfc215b do_hoist_insertion
$SRC/gcc/tree-ssa-pre.c:3587
0xfc215b insert
$SRC/gcc/tree-ssa-pre.c:3674
0xfc215b execute
$SRC/gcc/tree-ssa-pre.c:4224
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

include "arm_sve.h"

typedef unsigned long a;

void
b (svuint8_t *c, int d, char e, int f, char g, int h) {
  svbool_t i = svwhilegt_b8(svcntb(), (a)d);
  *c = svld1_u8(i, d);
}

void
j (struct k *ci, long l, svuint8_t *m, svuint8_t *n, int o, char p, int w) {
  int q = 0, r, s;
  if (l)
b(m, q, ci, r, ci, s);
  x(m);
}

void
t (svuint8_t *c, int d, char p, struct k *ci, long offset) {
  j(ci, offset, c, 0, d, p, 6);
}

void
u () {
  for (;;) {
int ci, d;
long offset;
svuint8_t v;
t(, d, 1, ci, offset);
  }
}

[Bug tree-optimization/96480] [8/9/10/11 Regression] missed optimisation: unnecessary compare in standard algorithms

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Simplified testcase:
int v[4];

int
foo (int x)
{
  int *p;
  if (x == 0)
p = [0];
  else if (x == 1)
p = [1];
  else if (x == 2)
p = [2];
  else if (x == 3)
p = [3];
  else
p = [4];
  return p != [4];
}

[Bug d/96153] d: struct literals have non-deterministic hash values

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Rainer Orth from comment #2)
> The new test FAILs on 64-bit Solaris/SPARC:
> 
> The test PASSes with -O0 and -Os, as well as with -m32.

Thanks, I've checked Linux/SPARC64 and see the same thing.

[Bug ipa/96482] [10/11 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|Combination of  |[10/11 Regression]
   |-finline-small-functions|Combination of
   |and ipa-cp optimisations|-finline-small-functions
   |causes incorrect values |and ipa-cp optimisations
   |being passed to a function  |causes incorrect values
   ||being passed to a function
   Keywords||wrong-code
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |10.3
  Component|c   |ipa

--- Comment #2 from Richard Biener  ---
Honza - you added bit-IPA-CP, please have a look.

[Bug tree-optimization/96480] [8/9/10/11 Regression] missed optimisation: unnecessary compare in standard algorithms

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|c++ |tree-optimization
   Keywords||missed-optimization

[Bug tree-optimization/96481] SLP fail to vectorize VEC_COND_EXPR pattern.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> So in theory we could record basic-block boundaries as DR group_id instead

Note for outer loop vect we need the BB restriction which means we'd need to
compute the group_id array also for loop vect.

[Bug tree-optimization/96481] SLP fail to vectorize VEC_COND_EXPR pattern.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
So in theory we could record basic-block boundaries as DR group_id instead
and continue scanning over such "simple" (no VOPs involving) diamonds.
That leaves handling PHI nodes themselves of course but I think it should be
possible to weave them into the SLP graph as special ops - well,
virtual cond-exprs.

[Bug c/96482] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function

[yevh.kolesnikov at gmail dot com]

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

--- Comment #1 from Yevhenii Kolesnikov  ---
Created attachment 49003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49003=edit
Preprocessed file (compressed)

Oh. Preprocessed file was actually too big. Attaching a compressed file.

[Bug c++/96480] [8/9/10/11 Regression] missed optimisation: unnecessary compare in standard algorithms

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
That commit changes the pre-reassoc2 dump like:
--- pr96480.ii.172t.printf-return-value2_   2020-08-05 07:22:42.0
-0400
+++ pr96480.ii.172t.printf-return-value22020-08-05 07:23:32.0
-0400
@@ -31,13 +31,13 @@ bool is_foo(ENUM) (ENUM e)

[12.87%]:
   if (e_2(D) == 3)
-goto  (); [3.00%]
+goto ; [3.00%]
   else
-goto ; [97.00%]
+goto  (); [97.00%]

-   [12.48%]:
+   [0.39%]:

-  # prephitmp_5 = PHI <1(2), 1(3), 1(4), 1(5), 0(6)>
+  # prephitmp_5 = PHI <1(2), 1(3), 1(4), 1(6), 0(5)>
  [14.13%]:
   return prephitmp_5;

So I guess I need to debug why reassoc doesn't like that form.

[Bug tree-optimization/96481] SLP fail to vectorize VEC_COND_EXPR pattern.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Last reconfirmed||2020-08-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Blocks||53947

--- Comment #1 from Richard Biener  ---
Yes, this is a known limitation in that for basic-block SLP we do not perform
if-conversion.  Instead the basic-block SLP code sees

   [local count: 1073741824]:
  _1 = *pd_17(D);
  _2 = *pc_19(D);
  _3 = *pb_20(D);
  _4 = *pa_21(D);
  if (_3 < _4)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  goto ; [100.00%]

   [local count: 536870913]:

   [local count: 1073741824]:
  # iftmp.20_23 = PHI <_1(3), _2(11)>
  *dst_22(D) = iftmp.20_23;
  _5 = MEM[(const unsigned int *)pd_17(D) + 4B];
  _6 = MEM[(const unsigned int *)pc_19(D) + 4B];
  _7 = MEM[(const unsigned int *)pb_20(D) + 4B];
  _8 = MEM[(const unsigned int *)pa_21(D) + 4B];
...

which also rips apart the memory groups (we're slowly relaxing another
limitation that the basic-block SLP code operates on a single basic-block
at a time but for data refs this restriction will prevail).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c/96482] New: Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function

[yevh.kolesnikov at gmail dot com]

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

Bug ID: 96482
   Summary: Combination of -finline-small-functions and ipa-cp
optimisations causes incorrect values being passed to
a function
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yevh.kolesnikov at gmail dot com
  Target Milestone: ---

The bug was originally reported in mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3239

Combination of LTO and O3 caused a crash on replaying a video with mpv.
Backtrace showed pretty unrealistic values passed to a function. I reduced a
number of necessary optimisations to:

+ -O1
+ -finline-small-functions
+ -fipa-bit-cp
+ -fipa-cp
+ LTO

It happens with gcc 10.1.0, but not with gcc 9. I bisected the problem to
c7ac9a0c7e3916f192ad41227e16238fd1fa2fbf.

I wasn't able to produce a minimal reproducer, and even though a preprocessed
file doesn't trigger the bug for me (I assume, LTO is essential for this bug),
I'm attaching it anyway.

Looking at the produced assembler, though, shows that it goes wrong somewhere
around a call to addr_to_index at
https://gitlab.freedesktop.org/mesa/mesa/-/blob/7f25f1f106728f0046672adf9c9ed79185265ea5/src/compiler/nir/nir_lower_io.c#L870.
addr_to_index gets inlined and so is nir_channel, called from it.

Those two are pretty simple functions:

static nir_ssa_def *
addr_to_index(nir_builder *b, nir_ssa_def *addr,
  nir_address_format addr_format)
{
   if (addr_format == nir_address_format_32bit_index_offset) {
  assert(addr->num_components == 2);
  return nir_channel(b, addr, 0);
   } else if (addr_format == nir_address_format_vec2_index_32bit_offset) {
  assert(addr->num_components == 3);
  return nir_channels(b, addr, 0x3);
   } else {
  unreachable("bad address format for index");
   }
}

static inline nir_ssa_def *
nir_channel(nir_builder *b, nir_ssa_def *def, unsigned c)
{
   return nir_swizzle(b, def, , 1);
}

In the final assembly we end up with just a call to nir_swizzle:
movedx,r14d
movrsi,r15
movrdi,rbp
call   0x7fffd26e0ef9 

[Bug c++/96480] [8/9/10/11 Regression] missed optimisation: unnecessary compare in standard algorithms

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
 Ever confirmed|0   |1
Summary|missed optimisation:|[8/9/10/11 Regression]
   |unnecessary compare in  |missed optimisation:
   |standard algorithms |unnecessary compare in
   ||standard algorithms
   Last reconfirmed||2020-08-05
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r8-565-g7581ce9a1ad6df9c8998a3c74256837a1ff6f7cc

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
> 
> --- Comment #8 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to rguent...@suse.de from comment #7)
> > On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
> > > 
> > > --- Comment #6 from rsandifo at gcc dot gnu.org  > > gnu.org> ---
> > > FWIW, I think the reason I mentioned for skimping on this originally
> > > was that we don't e.g. prevent if-conversion of:
> > > 
> > > void
> > > foo (int *c, float *f)
> > > {
> > >   for (int i = 0; i < 16; ++i)
> > > f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i];
> > > }
> > > 
> > > for -O2 -ftree-vectorize -fno-math-errno.  So it seemed like things
> > > weren't very consistent.
> > 
> > I think that's a bug in if-conversion - gimple_could_trap_p only
> > says that the call instruction itself doesn't trap, it doesn't
> > say anything about something in the callee body.
> When's that distinction useful in practice though?  It seems odd
> that an FP x / y is seen as potentially trapping, but a function
> call that wraps (or might wrap) an FP x / y isn't.
> 
> > You should need -fno-trapping-math to get the above if-converted.
> Is there an existing ECF flag that we can check?  ECF_NOTHROW is
> related but seems different enough not to be reliable.
> 
> And is trapping a “side effect“ for the purposes of:

Yes, I think trapping would be a gimple_has_side_effects effect.

No, I don't think NOTRHOW covers this.  On GENERIC we have
TREE_THIS_NOTRAP but it's not even specified for CALL_EXPR.

> /* Nonzero if this is a call to a function whose return value depends 
>   
>solely on its arguments, has no side effects, and does not read
>   
>global memory.  This corresponds to TREE_READONLY for function 
>   
>decls.  */
> #define ECF_CONST (1 << 0)
> 
> I.e. can a function still be const (on the basis that a given
> argument always produces the same result) while still trapping
> for some arguments?  What about pure, where the trapping might
> come from a memory dereference?

How do we represent sNaNs with -fnon-call-exceptions?  That is,

 y_1 = x_2 + 1.;

may trap.  Does

 foo (x_2);

get transformed to

 tem_3 = x_2;
 foo (tem_3);

and the SSA assignment now traps dependent on whether the call
ABI requires pushing x_2 to a stack slot (which might trap)?

sNaNs are odd anyway I guess.

But yes, a pure function can still trap (and also throw).

I think we don't have a good notion for trappingness of calls
and I do expect inconsistencies here.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
(In reply to rguent...@suse.de from comment #7)
> On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
> > 
> > --- Comment #6 from rsandifo at gcc dot gnu.org  > gnu.org> ---
> > FWIW, I think the reason I mentioned for skimping on this originally
> > was that we don't e.g. prevent if-conversion of:
> > 
> > void
> > foo (int *c, float *f)
> > {
> >   for (int i = 0; i < 16; ++i)
> > f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i];
> > }
> > 
> > for -O2 -ftree-vectorize -fno-math-errno.  So it seemed like things
> > weren't very consistent.
> 
> I think that's a bug in if-conversion - gimple_could_trap_p only
> says that the call instruction itself doesn't trap, it doesn't
> say anything about something in the callee body.
When's that distinction useful in practice though?  It seems odd
that an FP x / y is seen as potentially trapping, but a function
call that wraps (or might wrap) an FP x / y isn't.

> You should need -fno-trapping-math to get the above if-converted.
Is there an existing ECF flag that we can check?  ECF_NOTHROW is
related but seems different enough not to be reliable.

And is trapping a “side effect“ for the purposes of:

/* Nonzero if this is a call to a function whose return value depends   
   solely on its arguments, has no side effects, and does not read  
   global memory.  This corresponds to TREE_READONLY for function   
   decls.  */
#define ECF_CONST (1 << 0)

I.e. can a function still be const (on the basis that a given
argument always produces the same result) while still trapping
for some arguments?  What about pure, where the trapping might
come from a memory dereference?

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
> 
> --- Comment #6 from rsandifo at gcc dot gnu.org  
> ---
> FWIW, I think the reason I mentioned for skimping on this originally
> was that we don't e.g. prevent if-conversion of:
> 
> void
> foo (int *c, float *f)
> {
>   for (int i = 0; i < 16; ++i)
> f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i];
> }
> 
> for -O2 -ftree-vectorize -fno-math-errno.  So it seemed like things
> weren't very consistent.

I think that's a bug in if-conversion - gimple_could_trap_p only
says that the call instruction itself doesn't trap, it doesn't
say anything about something in the callee body.  You should need
-fno-trapping-math to get the above if-converted.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
FWIW, I think the reason I mentioned for skimping on this originally
was that we don't e.g. prevent if-conversion of:

void
foo (int *c, float *f)
{
  for (int i = 0; i < 16; ++i)
f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i];
}

for -O2 -ftree-vectorize -fno-math-errno.  So it seemed like things
weren't very consistent.

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
You might want to use the -fno-tree-copyrename option.  The Erlang/OTP VM,
which is a directly-threaded interpreter, uses it on all targets since gcc-4.3.

[Bug tree-optimization/96481] New: SLP fail to vectorize VEC_COND_EXPR pattern.

[crazylht at gmail dot com]

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

Bug ID: 96481
   Summary: SLP fail to vectorize VEC_COND_EXPR pattern.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

testcase not vectorized:
-
#include 

inline unsigned opt(unsigned a, unsigned b, unsigned c, unsigned d) {
return a > b ? c : d;
}

void opt( unsigned * __restrict dst, const unsigned *pa, const unsigned *pb,
const unsigned *pc, const unsigned  *pd )
{

 *dst++ = opt(*pa++, *pb++, *pc++, *pd++);
 *dst++ = opt(*pa++, *pb++, *pc++, *pd++);
 *dst++ = opt(*pa++, *pb++, *pc++, *pd++);
 *dst++ = opt(*pa++, *pb++, *pc++, *pd++);
}



testcase successfully vectorized:


inline unsigned opt(unsigned a, unsigned b, unsigned c, unsigned d) {
return a > b ? c : d;
}

void opt( unsigned * __restrict dst, const unsigned *pa, const unsigned *pb,
const unsigned *pc, const unsigned  *pd )
{
for (int i = 0; i != 4; i++)
 *dst++ = opt(*pa++, *pb++, *pc++, *pd++);
}


llvm can handle both case
refer to https://godbolt.org/z/jYoPxT

[Bug c++/96480] New: missed optimisation: unnecessary compare in standard algorithms

[kurkindmit at gmail dot com]

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

Bug ID: 96480
   Summary: missed optimisation: unnecessary compare in standard
algorithms
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kurkindmit at gmail dot com
  Target Milestone: ---

Consider the C++ code:

#include 
#include 

enum ENUM { A, B, C, D, E, F, G, };

const std::array foo{A, B, C, D};

bool is_foo(ENUM e) {
return std::any_of(foo.begin(), foo.end(),
[e] (auto ee) { return e == ee; });
}

GCC 7.4 optimizes if_foo to a single compare operation e <= 3,
but newer GCC versions do two comare operations e <= 2 || e == 3.

see https://godbolt.org/z/5a6aPa

[Bug target/96342] [SVE] Add support for "omp declare simd"

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
That's great, thanks for the heads-up.

[Bug d/96153] d: struct literals have non-deterministic hash values

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
The new test FAILs on 64-bit Solaris/SPARC:

+FAIL: gdc.dg/pr96153.d   -O1  execution test
+FAIL: gdc.dg/pr96153.d   -O1 -frelease  execution test
+FAIL: gdc.dg/pr96153.d   -O1 -frelease -g  execution test
+FAIL: gdc.dg/pr96153.d   -O1 -g  execution test
+FAIL: gdc.dg/pr96153.d   -O2  execution test
+FAIL: gdc.dg/pr96153.d   -O2 -frelease  execution test
+FAIL: gdc.dg/pr96153.d   -O2 -frelease -g  execution test
+FAIL: gdc.dg/pr96153.d   -O2 -g  execution test
+FAIL: gdc.dg/pr96153.d   -O3  execution test
+FAIL: gdc.dg/pr96153.d   -O3 -frelease  execution test
+FAIL: gdc.dg/pr96153.d   -O3 -frelease -g  execution test
+FAIL: gdc.dg/pr96153.d   -O3 -g  execution test

core.exception.AssertError@/vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/pr96153.d(30):
unittest failure

/vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:500 _d_throw
[0x10008262b]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:459
onAssertErrorMsg [0x100063503]
??:? void pr96153.__unittestL21_1() [0x10005c603]
??:? void pr96153.__modtest() [0x10005c613]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/core/runtime.d:561
__foreachbody2 [0x100075167]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/object.d:1599 __lambda2
[0x10006fce7]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/minfo.d:777
__foreachbody2 [0x10006ab07]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/sections/elf_shared.d:109
int gcc.sections.elf_shared.DSO.opApply(scope int delegate(ref
gcc.sections.elf_shared.DSO)) [0x10005dadf]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/minfo.d:770 int
rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*)))
[0x10006c1cf]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/object.d:1598 int
object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x100071bc3]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/core/runtime.d:551
runModuleUnitTests [0x1000754bb]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/dmain2.d:496 runAll
[0x10005d1ff]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/dmain2.d:472 tryExec
[0x10005d3c3]
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/dmain2.d:505 _d_run_main
[0x10005d3c3]
??:? main [0x10005c63b]
??:? _start [0x10005be4b]

The test PASSes with -O0 and -Os, as well as with -m32.

[Bug middle-end/96459] OpenMP host teams reductions ignored

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:916c7a201a9a1dc94f2c056a773826a26d1daca9

commit r11-2571-g916c7a201a9a1dc94f2c056a773826a26d1daca9
Author: Jakub Jelinek 
Date:   Wed Aug 5 10:40:10 2020 +0200

openmp: Handle reduction clauses on host teams construct [PR96459]

As the new testcase shows, we weren't actually performing reductions on
host teams construct.  And fixing that revealed a flaw in the for-14.c
testcase.
The problem is that the tests perform also initialization and checking
around the
calls to the functions with the OpenMP constructs.  In that testcase, all
the
tests have been spawned from a teams construct but only the tested loops
were
distribute, which means the initialization and checking has been performed
redundantly and racily in each team.  Fixed by performing the
initialization
and checking outside of host teams and only do the calls to functions with
the tested constructs inside of host teams.

2020-08-05  Jakub Jelinek  

PR middle-end/96459
* omp-low.c (lower_omp_taskreg): Call lower_reduction_clauses even
in
for host teams.

* testsuite/libgomp.c/teams-3.c: New test.
* testsuite/libgomp.c-c++-common/for-2.h (OMPTEAMS): Define to
nothing
if not defined yet.
(N(test)): Use it before all N(f*) calls.
* testsuite/libgomp.c-c++-common/for-14.c (DO_PRAGMA, OMPTEAMS):
Define.
(main): Don't call all test_* functions from within
#pragma omp teams reduction(|:err), call them directly.

[Bug target/96479] AArch64: return SIMD register with -mgeneral-regs-only

[qiaopeixin at huawei dot com]

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

--- Comment #2 from qiaopeixin at huawei dot com ---
(In reply to Richard Biener from comment #1)
> If -mgeneral-regs-only is not supposed to be an ABI changing option then the
> compiler has to reject code using non-general regs.  With a diagnostic
> preferably, not by ICEing.

For now, the compiler report the diagnostic information as following

../gcc/gcc/testsuite/c-c++-common/torture/vector-subscript-2.c: In function
‘myfunc2’:
../gcc/gcc/testsuite/c-c++-common/torture/vector-subscript-2.c:17:1: error:
‘-mgeneral-regs-only’ is incompatible with the use of vector types
../gcc/gcc/testsuite/c-c++-common/torture/vector-subscript-2.c: In function
‘modify’:
../gcc/gcc/testsuite/c-c++-common/torture/vector-subscript-2.c:28:10: error:
‘-mgeneral-regs-only’ is incompatible with the use of vector types
../gcc/gcc/testsuite/c-c++-common/torture/vector-subscript-2.c:28:10: error:
‘-mgeneral-regs-only’ is incompatible with the use of vector types
../gcc/gcc/testsuite/c-c++-common/torture/vector-subscript-2.c: In function
‘myfunc2’:
../gcc/gcc/testsuite/c-c++-common/torture/vector-subscript-2.c:16:20: error:
‘-mgeneral-regs-only’ is incompatible with the use of vector types
../gcc/gcc/testsuite/c-c++-common/torture/vector-subscript-2.c:23:12: error:
‘-mgeneral-regs-only’ is incompatible with the use of vector types

[Bug target/96479] AArch64: return SIMD register with -mgeneral-regs-only

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Target||aarch64

--- Comment #1 from Richard Biener  ---
If -mgeneral-regs-only is not supposed to be an ABI changing option then the
compiler has to reject code using non-general regs.  With a diagnostic
preferably, not by ICEing.

[Bug c/96476] [Request] expose preferred vector width to preprocessor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |c
 Target||x86_64-*-* i?86-*-*
   Severity|normal  |enhancement

--- Comment #2 from Richard Biener  ---
Requestor wants it not for inside GCC but for inside a library.  But I, too,
think it should be general (if at all), not target specific.  We could
seed it from largest integer/float vector-mode that has an add optab for
example
if the target does not override it.

Note the distinction between FP and int makes it a bit awkward if you think
about AVX vs. AVX2 for example.  But then so is -mpreferred-vector-with
in that case.

FEs need to expose extra "generic" macros, so adjusting component accordingly.

[Bug c++/95511] Class template argument deduction: guide generated from constructor preferred over deduction-guide.

[okannen at gmail dot com]

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

Olivier Kannengieser  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Olivier Kannengieser  ---
The bug is not more here in GCC version 10.2.

[Bug debug/96471] ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
And auto reduce + some manual sanitizing:

  SUBROUTINE CMUMPS_SCATTER_DIST_RHS(
 &   POSINRHSCOMP_FWD, IFIRSTNOTTOUCHED,
 &   NBRECORDS)
  INTEGER, INTENT(IN):: POSINRHSCOMP_FWD(N)
CALL CMUMPS_DR_ASSEMBLE_LOCAL()
  CONTAINS
SUBROUTINE CMUMPS_DR_ASSEMBLE_LOCAL()
!$OMP PARALLEL DO PRIVATE(I, IRHSCOMP, Iglob)
  DO I = IFIRSTNOTTOUCHED, NBRECORDS
IRHSCOMP = POSINRHSCOMP_FWD(I)
  ENDDO
END SUBROUTINE CMUMPS_DR_ASSEMBLE_LOCAL
  END SUBROUTINE CMUMPS_SCATTER_DIST_RHS

[Bug debug/96471] ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 49002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49002=edit
reduced fortran testcase

Manually reduced the fortran testcase down to a single file, now reproduces
with

> ./f951 -quiet 1.F -O -g -fopenmp -fdebug-types-section

[Bug c/96460] Warn about signed module that is converted to unsigned value

[fw at gcc dot gnu.org]

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

--- Comment #2 from Florian Weimer  ---
(In reply to Richard Biener from comment #1)
> It's perfectly valid code ... guess similar to -Wconversion though.

If the modulo result is never negative, it's not *perfectly* valid because GCC
has to add instructions to produce those negative values, and most programmers
will never realize that this is happening.

[Bug debug/96471] ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2020-08-05

--- Comment #3 from Richard Biener  ---
Confirmed.

[Bug target/96479] New: AArch64: return SIMD register with -mgeneral-regs-only

[qiaopeixin at huawei dot com]

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

Bug ID: 96479
   Summary: AArch64: return SIMD register with -mgeneral-regs-only
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qiaopeixin at huawei dot com
  Target Milestone: ---

Created attachment 49001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49001=edit
aarch64: vector incompatible with -mgeneral-regs-only

Hi,

When compiling the test case of vector extraction and insertion with
-mgeneral-regs-only option, which is
gcc/testsuite/c-c++-common/torture/vector-subscript-2.c, GCC reports the ice,
which should not be. It uses the vector with the length of four integers, which
is defined in test case. The start funciton of expand pass will figure out the
mode of eventual return register to store the vector. At this time, GCC will
check if it can be returned in simd/fp register(s), and return v4si register.
Unfortunately, -mgeneral-regs-only prevent the use of simd/fp register(s).

I proposed to add one if statement when entering into the if statement of
checking that the mode of return register is simd/fp. If TARGET_FLOAT is false,
which is enabled by -mgeneral-regs-only option, it will report the error that
'-mgeneral-regs-only' is incompatiable with the use of vector types.

Is it the solution to solve the problem?

All the best

[Bug target/96476] [Request] expose preferred vector width to preprocessor

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
TARGET_CPU_CPP_BUILTINS?
It says 
---
This function-like macro expands to a block of code that defines built-in
preproces-
sor macros and assertions for the target CPU, using the functions
builtin_define,
builtin_define_std and builtin_assert. When the front end calls this macro it
provides a trailing semicolon, and since it has finished command line option
processing
your code can use those results freely.

[Bug testsuite/96470] [10 regression] gnat.dg/opt39.adb fails since r10-917

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

--- Comment #1 from Richard Biener  ---
possibly a missed optimization caused by that rev.