[Bug tree-optimization/94401] [10 Regression] pr92420.c fails on aarch64 since r10-7415

[linkw at gcc dot gnu.org]

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

--- Comment #5 from Kewen Lin  ---
Created attachment 48150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48150=edit
untested patch

This can fix the REG failures on aarch64.

[Bug target/94420] New: ICE error: insn does not satisfy its constraints

[marxin at gcc dot gnu.org]

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

Bug ID: 94420
   Summary: ICE error: insn does not satisfy its constraints
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org, segher at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-linux-gnu
Target: powerpc64-linux-gnu

It's reduced from moonjit bug:
https://github.com/moonjit/moonjit/issues/74

$ cat /tmp/moonjit.i
register long int *a __asm__("r2");
long int b;

void fn1() {
  long *p = 
  for (;;)
*p++ = (long int)a;
}

$ ./xgcc -B. /tmp/moonjit.i -c
$ ./xgcc -B. /tmp/moonjit.i -c -O2
/tmp/moonjit.i: In function ‘fn1’:
/tmp/moonjit.i:8:1: error: insn does not satisfy its constraints:
8 | }
  | ^
(insn 7 5 8 2 (set (reg/f:DI 121)
(unspec:DI [
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(reg/f:DI 118 [ a.2_2 ])
] UNSPEC_TOCREL)) 731 {*tocrefdi}
 (expr_list:REG_EQUAL (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(nil)))
during RTL pass: combine
/tmp/moonjit.i:8:1: internal compiler error: in extract_constrain_insn_cached,
at recog.c:2207
0x10f19513 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x10f195a7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:119
0x10ea179f extract_constrain_insn_cached(rtx_insn*)
../../gcc/recog.c:2207
0x11b779b7 get_attr_prefixed(rtx_insn*)
../../gcc/config/rs6000/rs6000.md:647
0x116c09df rs6000_insn_cost
../../gcc/config/rs6000/rs6000.c:21141
0x10f30097 insn_cost(rtx_insn*, bool)
../../gcc/rtlanal.c:5440
0x11ef525b combine_instructions
../../gcc/combine.c:1236
0x11f2b06f rest_of_handle_combine
../../gcc/combine.c:15059
0x11f2b1e3 execute
../../gcc/combine.c:15104

[Bug fortran/94411] E0.d not supported

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Tue, Mar 31, 2020 at 04:47:04AM +, longb at cray dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
> 
> --- Comment #2 from Bill Long  ---
> Thanks for the quick reply. Is there a predicted release date for 10.1?
> 

Trunk is in stage 4, which is regression and documentation
fixes only.  Historically, 7.1, 8.1, and 9.1 were released
in May.  I would suspect a May time frame.

[Bug tree-optimization/94401] [10 Regression] pr92420.c fails on aarch64 since r10-7415

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #4 from Kewen Lin  ---
My commit extends the current scalar epilogue peeling for gaps 
elimination, it makes the case can make use of int for the construction. But it
reveals the existing handlings misses to handle VMAT_CONTIGUOUS_REVERSE case,
currently it assumes overrun happens on high address end, it's true for almost
all cases, but this case is on the low address end. So if we have to load the
high part and put it in the latter part of constructed vector for
VMAT_CONTIGUOUS_REVERSE.

The IR before/after the commit looks

good:
  vect__9.16_80 = MEM  [(int *)vectp_y.14_78];
  vect__9.17_81 = VEC_PERM_EXPR ;
  vect__9.18_82 = VEC_PERM_EXPR ;

bad:
  _30 = MEM[(int *)vectp_y.12_34];
  _20 = {_30, 0};
  vect__9.14_19 = VIEW_CONVERT_EXPR(_20);
  vect__9.15_61 = VEC_PERM_EXPR ;
  vect__9.16_54 = VEC_PERM_EXPR ;

[Bug gcov-profile/94394] [GCOV]It will cause random kernel panic during collecting kernel code coverage

[ammy.yi at intel dot com]

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

--- Comment #5 from ammy.yi  ---
(In reply to Martin Liška from comment #4)
> (In reply to ammy.yi from comment #3)
> > Actually, there is some random kernel panic here. 
> > 
> > The following steps may reproduce this issue:
> > 
> > 1. Enable gcov in kconfig
> > 2. build kernel and boot to system
> > 3. Do following load/unload modules steps
> > 
> > modprobe stm_p_basic
> > modprobe intel_th_pci
> > modprobe intel_th_sth
> > modprobe intel_th_msu
> > modprobe stm_console
> > 
> > modprobe -r stm_p_basic
> > modprobe -r intel_th_pci
> > modprobe -r intel_th_sth
> > modprobe -r intel_th_msu
> > modprobe -r stm_console
> 
> Would it be possible to provide a stack-traces where it usually causes a
> kernel panic?
> 
> > 
> > Hi martin,
> > 
> > If it is libgcov issue, do you know where to file issue for it?
> 
> I would create a normal linux kernel bug. The pseudo-runtime is implemented
> in kernel/gcov subfolder.


Hi Martin,

Actually, there is no detailed call trace. The whole call trace I got is added 
in my first comments

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-31

--- Comment #2 from H.J. Lu  ---
This seems to work:

diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 66b120d21a7..78fb373db6e 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -1963,7 +1963,12 @@ rest_of_insert_endbranch (void)
   && (!flag_manual_endbr
 || lookup_attribute ("cf_check",
DECL_ATTRIBUTES (cfun->decl)))
-  && !cgraph_node::get (cfun->decl)->only_called_directly_p ())
+  && (!cgraph_node::get (cfun->decl)->only_called_directly_p ()
+|| ix86_cmodel == CM_LARGE
+|| ix86_cmodel == CM_LARGE_PIC
+|| flag_force_indirect_call
+|| (TARGET_DLLIMPORT_DECL_ATTRIBUTES
+&& DECL_DLLIMPORT_P (cfun->decl
 {
   /* Queue ENDBR insertion to x86_function_profiler.  */
   if (crtl->profile && flag_fentry)

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|-fcf-protection |-fcf-protection
   |-mcmodel=large is broken|-mcmodel=large/-mforce-indi
   ||rect-call is broken

--- Comment #1 from H.J. Lu  ---
-mforce-indirect-call has the same issue.

[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error

[kees at outflux dot net]

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

--- Comment #5 from Kees Cook  ---
Hi! I recently learned that Clang has -fsanitizer-minimal-runtime that is very
close to what I was expecting to use:

https://bugs.llvm.org/show_bug.cgi?id=45295

That is close to what you're already suggesting. Would it be possible to do the
same thing? That way the kernel can have just one "not the full debug details"
handler.

Thanks for looking at this!

[Bug ada/94419] New: accepting wrong programs because compiler error

[yyelle at rbx dot email]

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

Bug ID: 94419
   Summary: accepting wrong programs because compiler error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyelle at rbx dot email
  Target Milestone: ---

I'm currently studing Ada and using GCC and I found a number of bugs in
compiler. It is about Ada 2012. Example buggy code is here:

package A is
type tp is private; -- tp here is considered constrained. Users of
public part will see this only, they do not see unconstrained'ness of private
defnition.
type atp is access all tp;
function ff1 return atp;
function ff2 return atp;
procedure pp1(p: atp);
private
type dd is range 1..10;
type tarr is array(dd range <>) of Integer;
type tp(x : dd := 10) is record -- tp here becomes considered
unconstrained.
a:  tarr(1..x);
end record;
end A;
package body A is
xx : aliased tp; -- unconstrained
yy : aliased tp(2); -- constrained
zz : aliased tp(10); -- constrained.
ax : aliased atp(10); -- access, constrained;
function ff1 return atp is
begin
return yy'Access; -- Conversion from access to constrained to
access unconstrained is errorneous because constrained partial view. Should be
reported but does not by GNAT.
end ff1;

function ff2 return atp is
begin
return xx'Access; -- ok
end ff2;

procedure pp1(a : atp) is
begin
ax := a; -- conversion from unconstrained to constrained (and
constraint match). Errorneous again. Should be reporrted, but GNAT doesn't
report. a here will be xx.
end;

procedure pp2 is
begin
xx := ( x => 2, others => 0);
ax.all := zz; -- No error by GNAT, but is errorneous. ax.all is
xx.
end;

end A;

-- User of A:
with A;
procedure Proc is
begin
A.ff1.all := A.ff2.all; -- No error reported, no error schould be
reported, but it tries to change the discriminant of constrained variable (and
alter the array size). Is bad.
A.pp1(A.ff2);
A.pp2;
end;

-- Ever more bad
package B is
type R is private;
procedure pp;
private
type R(x: Integer := 1) is null record;
end B;

with Ada.Text_IO; use Ada.Text_IO;
package body B is
procedure pp is
type A is access all R;
type A1 is access all R(1);
type A2 is access all R(2);
xx : aliased R(1);
yy : aliased R(2);
zz : aliased R;

aa1 : A1 := xx'Access;
aa2 : A2 := yy'Access;
begin
Put_Line("xx.x = " & xx.x'Image); -- schould be 1
aa1.all := aa2.all; -- No error reported by GNAT.
Put_Line("xx.x = " & xx.x'Image); -- 1 ?
zz := xx; -- ok
Put_Line("zz.x = " & zz.x'Image); -- 2.
end pp;
end B;


-- The following is about accessibility

with Ada.Text_IO; use Ada.Text_IO;
procedure C is
type R(ad : access Integer) is null record;
a : access R;
procedure inner is
y: aliased integer := 0;
begin
a := new R'(ad => y'Access);
end; -- y lifetime is ended.
begin
inner;
Put_Line("a.ad = " & a.ad.all'Image); -- 0
Put_Line("a.ad = " & a.ad.all'Image); -- 32767 ?
end;

Please, note Ada is not C, Ada is about safety. A program should be checked for
corectness and any errors must be reported almost always, at runtime also.
There are also cases when checks would be too hard to implement, but those
cases are relatively rare, they ever need more arguments, than implementation
complexity. And there is no intent to go to what C language is, Ada is not C.

Another bad thing in GNAT is implementation of "mutable" records, they always
need maximum memory. It is from GNAT manual:
type Rec (D : Positive := 15) is record
   Name : String (1..D);
end record;

Too_Large : Rec;

is flagged by the compiler with a warning: an attempt to create
`Too_Large' will raise `Storage_Error', because the required size
includes `Positive'Last' bytes.

It is bad. I think such records should be dynamically reallocatable. GNAT
manual says that such way is improper, but it is not that, it is right. Name in
example above may be allocated and reallocated "in free memory" and record
itself contain address of Name. If, for example, Name are passed as an aliased
parameter to a procedure, discriminant D schould not alter (while the parameter
is in use), this stated by Ada rules (the result is ever "errorneous
execution", which may be unpredictable). Also x.Name'Access will be error.

[Bug fortran/94411] E0.d not supported

[longb at cray dot com]

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

--- Comment #2 from Bill Long  ---
Thanks for the quick reply. Is there a predicted release date for 10.1?

[Bug c/89990] request warning: Use of out of scope compound literals

[modchipv12 at gmail dot com]

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

Andrew D'Addesio  changed:

   What|Removed |Added

 CC||modchipv12 at gmail dot com

--- Comment #5 from Andrew D'Addesio  ---
GCC already warns about this at compile time, but the warning sometimes doesn't
appear (due to PR88058, as Andrew Pinski just mentioned). Plus, the warning is
a bit confusing and could be reworded.

For example, create the following files:

foo.c:

int foo(const unsigned char *buf)
{
(void)buf; /* unused parameter */
return 1;
}

test.c:

int foo(const unsigned char *buf);

struct mytype {
char c;
};

static struct mytype d = { 42 };

int test(int x)
{
const unsigned char buf[32];
const struct mytype *ptr = 

if (x != 0)
ptr = &(const struct mytype){ 43 };

foo(buf);
#ifdef CALL_FOO_TWICE
foo(buf);
#endif

return ptr->c;
}

int main()
{
return test(1); /* returns 43 on GCC8, 0 on GCC9+ */
}

Compiling with one foo() call gives us a warning:

$ gcc -std=c99 -Wall -Wextra -pedantic -O1 -o test test.c foo.c
test.c: In function ‘main’:
test.c:26:15: warning: ‘.c’ is used uninitialized in this function
[-Wuninitialized]
   26 | return ptr->c;
  |~~~^~~
$ ./test
$ echo $?
0

However, compiling with two foo() calls makes the warning disappear, for some
reason:

$ gcc -DCALL_FOO_TWICE -std=c99 -Wall -Wextra -pedantic -O1 -o test test.c
foo.c
$ ./test
$ echo $?
0

My GCC version is 9.3.1 20200317 (Red Hat 9.3.1-1) on Fedora 31 x86-64.

[Bug c++/94418] Please make reverse_iterator nothrow constructible when possible

[rafael at espindo dot la]

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

--- Comment #1 from Rafael Avila de Espindola  ---
For what it is worth, libc++ implements this. Given

static_assert(std::is_nothrow_copy_constructible_v::reverse_iterator>);


With libstdc++:

$ clang -S test3.cc -std=c++17
test3.cc:3:1: error: static_assert failed due to requirement...

with libc++

$ clang clang -S test3.cc -std=c++17 -stdlib=libc++

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #6)
> git g:3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6, r10-7443
> 
> make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90
> # of expected passes  3
> 
> 
> git g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444
> 
> make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90
> 
> # of unexpected failures  3
> FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 6)
> FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 7)
> FAIL: gfortran.dg/pr93600_1.f90   -O  (test for excess errors)
> 
> 
> These were both clean builds run on a powerpc64 power8 LE machine.

The patch committed to fix(?) PR94246 reverted the code that fixed
PR93665 and PR93600 without removing the now failing testcases and
re-opening the now unfixed PR93665 and PR93600.  %len and %kind 
need to be special cased.  See, Oh, I don't know maybe the removed
comments in the diff.

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #4)
> (In reply to Martin Jambor from comment #3)
> > (In reply to Hongtao.liu from comment #1)
> > > Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
> > > according to our experience.
> > 
> > I have seen this helping on one system running SLES 15.1 and with
> > trunk abe13e1847f (Feb 17 2020) but not on another running openSUSE
> > Tumbleweed and with trunk revision 26b3e568a60 (Mar 23 2020).  So,
> > from my perspective, perhaps it helps, perhaps it doesn't.
> 
> What's your GCC option for OPENSUSE?
> 
> Default value of -mprefer-vector-width for -mtune=zenver1 is 128, if that,
> it won't help.
> Different processor have different tune which may has different default
> vector width.

for -march=native, it depends on processor of your server/client.

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[crazylht at gmail dot com]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Martin Jambor from comment #3)
> (In reply to Hongtao.liu from comment #1)
> > Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
> > according to our experience.
> 
> I have seen this helping on one system running SLES 15.1 and with
> trunk abe13e1847f (Feb 17 2020) but not on another running openSUSE
> Tumbleweed and with trunk revision 26b3e568a60 (Mar 23 2020).  So,
> from my perspective, perhaps it helps, perhaps it doesn't.

What's your GCC option for OPENSUSE?

Default value of -mprefer-vector-width for -mtune=zenver1 is 128, if that, it
won't help.
Different processor have different tune which may has different default vector
width.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[i at maskray dot me]

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

--- Comment #23 from Fangrui Song  ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
> 
> I gave you the correct usage for your use case.  If you don't like it is not
> my fault.

A wontfix/invalid does not seem a proper resolution to the bug(s).
We need a solution, instead of a workaround (SHN_ABS _binary_*_size can be
changed to _binary_*_end minus _binary_*_start).

Let me repeat. The code has worked fine for a long time.

1. -fno-pie code can only be linked with -no-pie. A PC32 relocation can be
resolved to a SHN_ABS definition.
2. -fpie code can be linked with either -no-pie or -pie.
3. -fpic code can be linked with -no-pie, -pie or -shared. GCC produces a GOT
relocation.
  The linker will fill up the GOT entry at link time. It is a constant at
runtime.

1 and 3 always work. For 2 -fpie -pie, it is incorrect to reference a
non-preemptible SHN_ABS symbol with a PC relative relocation in a PIC (-shared
or -pie) link (missed GNU ld diagnostic:
https://sourceware.org/bugzilla/show_bug.cgi?id=25749)

A GOT relocation was produced until commit
77ad54d911dd7cb88caf697ac213929f6132fdcf
("x86-64: Optimize access to globals in PIE with copy reloc").

I have proposed my solution in Comment 10: revert the patch.
It has very little value after H.J. invented GOTPCRELX in 2015.
As a compensation, we can invent a pair of new -f options,
-f(no-)direct-access-extern-object.

-fno-pie defaults to -fdirect-access-extern-object. -fpie defaults to
-fno-direct-access-extern-object.

-fno-pie users who really want to get rid of copy relocations can enable
-fno-direct-access-extern-object.
  Note: a copy relocation is needed if the definition turns out to be provided
by a shared object.

-fpie users who really care about GOT slowdown can enable
-fdirect-access-extern-object.
  This is more relevant on non-x86 due to the lack of linker relaxation
(R_X86_64_{REX_,}GOTPCRELX)

[Bug c++/94418] New: Please make reverse_iterator nothrow constructible when possible

[rafael at espindo dot la]

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

Bug ID: 94418
   Summary: Please make reverse_iterator nothrow constructible
when possible
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

The standard in res.on.exception.handling says:

An implementation may strengthen the exception specification for a non-virtual
function by adding a non-throwing exception specification.

So, as far as I understand, libstdc++ could make the constructors of
std::reverse_iterator noexcept when the corresponding constructors of the
underlying iterators are noexcept.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

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

Yuxuan Shui  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #22 from Yuxuan Shui  ---
(In reply to Andrew Pinski from comment #21)
> >Your suggestion is just a workaround as well, as it avoided using the ABS 
> >symbol.
> 
> ABS symbols are invalid in PIE mode.  That is my point.

Well if that's the case, can you point me to something (Specs, standards, etc.)
that says ABS symbols are not allowed in PIE? Otherwise it's just your words.

[Bug target/94417] New: -fcf-protection -mcmodel=large is broken

[hjl.tools at gmail dot com]

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

Bug ID: 94417
   Summary: -fcf-protection -mcmodel=large is broken
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64

From:

https://bugs.llvm.org/show_bug.cgi?id=45364

Testcase:

void ext();
__attribute((noinline)) static void a() { ext(); }
void b() { a(); }

Compile with "gcc -O2 -mcmodel=large -fcf-protection".  Note the indirect
call to "a", which does not have an endbr64.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #21 from Andrew Pinski  ---
>Your suggestion is just a workaround as well, as it avoided using the ABS 
>symbol.

ABS symbols are invalid in PIE mode.  That is my point.

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
I'm not sure the existing infinite loop removal is valid for any C 
standard version.  The C (C11 and later) rule against infinite loops only 
applies when the loop is written as an iteration statement whose 
controlling expression is not constant (not if it's written with goto, or 
has a constant controlling expression); it's not the more general rule 
about forward progress that C++ has.

[Bug c++/93431] FAIL: g++.dg/cpp2a/lambda-uneval9.C -std=c++2a (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Does this test need -fcommon option?

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

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

--- Comment #20 from Yuxuan Shui  ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
> 
> I gave you the correct usage for your use case.  If you don't like it is not
> my fault.

Can you please point me to something that shows me I am wrong?

Your suggestion is just a workaround as well, as it avoided using the ABS
symbol.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

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

Yuxuan Shui  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #19 from Yuxuan Shui  ---
comment #8 claims C variables cannot refer to ABS symbols without substantiate
that claim.

comment #9 suggests a change that is just wrong.

Reopening as previous WONTFIX/WORKSFORME resolutions are not valid.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Yuxuan Shui from comment #17)
> Sorry, I am here to report a bug, not to find a workaround for my use case.

I gave you the correct usage for your use case.  If you don't like it is not my
fault.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

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

--- Comment #17 from Yuxuan Shui  ---
(In reply to H.J. Lu from comment #16)
> (In reply to Yuxuan Shui from comment #15)
> > Your code is going to dereference the value stored in the ABS symbol as an
> > address (e.g. if the symbol has value 10, your code will access (*(char
> > *)10), barring the unwanted relocation), which is not the intention here.
> 
> This works in all cases:
> 
> unsigned long
> size2 (void)
> {
>   return ((unsigned long) &_binary_a_c_end
> - (unsigned long) &_binary_a_c_start);
> }

Sorry, I am here to report a bug, not to find a workaround for my use case.

[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to felix from comment #6)
> I don’t mind the transformation being applied.

That is not what I said.  I said the **language frontend** should not
do this.  A language frontend should give an as faithful as possible
description of the source code to the rest of the compiler.

[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
Passing a variable-size struct or union by value to a non-nested function 
seems very questionable (the function couldn't be declared with a matching 
prototype), but perhaps that doesn't answer the question because the 
cast-to-union case might appear for a nested function as well.

[Bug tree-optimization/94416] New: passing a restricted pointer to a function can be assumed not to modify an accessed object

[msebor at gcc dot gnu.org]

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

Bug ID: 94416
   Summary: passing a restricted pointer to a function can be
assumed not to modify an accessed object
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the test case below, the subtraction can safely be folded to zero because a
is a restricted pointer (as is effectively also b), *a is read, and if (a == b)
were true, the call g(b) couldn't also modify *a either via *(int*)b or by any
other means; as a result, a == b must either be false or g(b) cannot modify *a.
 Clang folds the subtraction but GCC does not.

$ cat c.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout c.c
void g (void *);

int f (int * restrict a, void * /* restrict */ b)
{
  int t = *a;

  g (b);

  return *a - t;   // can be folded to zero
}

;; Function f (f, funcdef_no=0, decl_uid=1933, cgraph_uid=1, symbol_order=0)

f (int * restrict a, void * restrict b)
{
  int t;
  int _1;
  int _7;

   [local count: 1073741824]:
  t_4 = *a_3(D);
  g (b_5(D));
  _1 = *a_3(D);
  _7 = _1 - t_4;
  return _7;

}

[Bug c++/94415] Implement DR 2237: Can a template-id name a constructor?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-30
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Keywords||accepts-invalid

[Bug c++/94415] New: Implement DR 2237: Can a template-id name a constructor?

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94415
   Summary: Implement DR 2237:  Can a template-id name a
constructor?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Implement :

template
struct A {
  A();   // error: simple-template-id not allowed for constructor
  A(int);   // OK, injected-class-name used
  ~A();  // error: simple-template-id not allowed for destructor
};

Note this is not a DR against C++17, the above is only ill-formed in C++20
onwards.

[Bug fortran/94411] E0.d not supported

[kargl at gcc dot gnu.org]

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

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 ---
(In reply to Bill Long from comment #0)
> We have a customer who complained that the Fortran 2018 feature for
> allowing w=0 in E-like format descriptors is not working with
> gfortran version 9.2.  I pointed them to the table at
> https://gcc.gnu.org/wiki/Fortran2018Status and that the entry for
> "d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors" was
> marked "No" They pointed out that the other two compilers they
> commonly use (Cray and Intel) both support this feature.  So, I'm
> submitting their "bug", but changing it to a RFE. With the hope that
> their input might help influence the priority given for this feature.
> 
> Example test program:
> 
> 
> 
>   program test
>   real(8) :: r
>   r = atan(1.0)
>   r = r * 65536
>   write (*,'(e0.6)') r
>   end program test

You need to update to top-of-tree.  It will be available when 10.1 is released.

[Bug c++/94414] New: only `--` gives constexpr

[dmusiienko at gmail dot com]

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

Bug ID: 94414
   Summary: only `--` gives constexpr
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmusiienko at gmail dot com
  Target Milestone: ---

x86-64 gcc (trunk)
-std=c++20 -O3

`++` - is not constexpr
`--` - is constexpr

==
#include 
#include 

namespace rv = std::views;

int main()
{
constexpr std::array arr{5, 6, 7, 8};
auto contfilt = arr | rv::filter([](auto x){return x>5;})
| rv::transform([](auto x){return x*x;});
return *(++contfilt.begin());
}

===

main:
movdqa  xmm0, XMMWORD PTR .LC0[rip]
lea rax, [rsp-16]
movaps  XMMWORD PTR [rsp-24], xmm0
jmp .L3
.L6:
add rax, 4
lea rdx, [rsp-8]
cmp rax, rdx
je  .L2
.L3:
cmp DWORD PTR [rax], 5
jle .L6
.L2:
mov eax, DWORD PTR [rax]
imuleax, eax
ret
.LC0:
.long   5
.long   6
.long   7
.long   8
=

Okay, but ...



#include 
#include 

namespace rv = std::views;

int main()
{
constexpr std::array arr{5, 6, 7, 8};
auto contfilt = arr | rv::filter([](auto x){return x>5;})
| rv::transform([](auto x){return x*x;});
return *(contfilt.end());
}



main:
mov eax, 49
ret



Okay, but.



#include 
#include 

namespace rv = std::views;

int main()
{
constexpr std::array arr{5, 6, 7, 8};
auto contfilt = arr | rv::filter([](auto x){return x>5;})
| rv::transform([](auto x){return x*x;});
return *(++(--contfilt.end()));
}



main:
mov eax, 49
ret

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

[herring at lanl dot gov]

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

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #9 from S. Davis Herring  ---
Another very similar failure (let me know if you want a separate bug for it):

  inline constexpr int x=0,y=0;  // -std=c++17
  static_assert(!=);  // error: '((& x) != (& y))' is not a constant
expression

No failure without the 'inline'.

[Bug fortran/94408] Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure

[michalak at ucar dot edu]

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

--- Comment #3 from michalak at ucar dot edu ---
Thank you, I've verified that removing the interface definitions works for this
test program and provides a workaround for the original code from which this
example was pulled. I'm not sure that the issue itself is resolved, however,
since removing these interface definitions breaks the code for the Intel
compiler. Will investigate further and provide additional context. -John

[Bug c++/90711] [9/10 Regression] Failing SFINAE from unrelated struct since r9-6794

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5830f753559f25a5dabcc3507bffa611c6b575a6

commit r10-7465-g5830f753559f25a5dabcc3507bffa611c6b575a6
Author: Jason Merrill 
Date:   Mon Mar 30 16:09:43 2020 -0400

c++: Fix comparison of fn() and ns::fn() [PR90711]

The resolution of CWG issue 1321 clarified that when deciding whether two
expressions involving template parameters are equivalent, two dependent
function calls where the function is named with an unqualified-id are
considered to be equivalent if the name is the same, even if unqualified
lookup finds different sets of functions.  We were wrongly treating
qualified-ids the same way, so that EXISTS and test::EXISTS were considered
to be equivalent even though they are looking up the name in different
scopes.  This also causes a mangling bug, but I don't think it's safe to
fix
that for GCC 10; this patch just fixes the comparison.

gcc/cp/ChangeLog
2020-03-30  Jason Merrill  

PR c++/90711
* tree.c (cp_tree_equal) [CALL_EXPR]: Compare KOENIG_LOOKUP_P.
(called_fns_equal): Check DECL_CONTEXT.

[Bug middle-end/94412] wrong code with -fsanitize=undefined and vectors

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 48149
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48149=edit
gcc10-pr94412.patch

Patch I'm going to test momentarily.

[Bug target/94406] 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9 with -Ofast -march=native

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
For the record, on AMD Zen2 at least, SPEC 2006 410.bwaves also runs
about 12% faster with --param vect-epilogues-nomask=0 (and otherwise
with -Ofast -march=native -mtune=native).

[Bug c++/94385] [10 Regression] Internal compiler error for __builtin_convertvector + statement expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed (will apply later to release branches anyway as it is latent there).

[Bug c++/94385] [10 Regression] Internal compiler error for __builtin_convertvector + statement expr

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:1cb1986cb596336e688c079b821205ec212a46a3

commit r10-7464-g1cb1986cb596336e688c079b821205ec212a46a3
Author: Jakub Jelinek 
Date:   Mon Mar 30 22:55:36 2020 +0200

c++: Fix handling of internal fn calls in statement expressions [PR94385]

The following testcase ICEs, because the FE when processing the statement
expression changes the .VEC_CONVERT internal fn CALL_EXPR into .PHI call.
That is because the internal fn call is recorded in the base.u.ifn
field, which overlaps base.u.bits.lang_flag_1 which is used for
STMT_IS_FULL_EXPR_P, so this essentially does ifn |= 2 on little-endian.
STMT_IS_FULL_EXPR_P bit is used in:
cp-gimplify.c-  if (STATEMENT_CODE_P (code))
cp-gimplify.c-{
cp-gimplify.c-  saved_stmts_are_full_exprs_p = stmts_are_full_exprs_p
();
cp-gimplify.c-  current_stmt_tree ()->stmts_are_full_exprs_p
cp-gimplify.c:= STMT_IS_FULL_EXPR_P (*expr_p);
cp-gimplify.c-}
and
pt.c-  if (STATEMENT_CODE_P (TREE_CODE (t)))
pt.c:current_stmt_tree ()->stmts_are_full_exprs_p = STMT_IS_FULL_EXPR_P
(t);
so besides being wrong on some other codes, it actually isn't beneficial at
all to set it on anything else, so the following patch restricts it to
trees with STATEMENT_CODE_P TREE_CODE.

2020-03-30  Jakub Jelinek  

PR c++/94385
* semantics.c (add_stmt): Only set STMT_IS_FULL_EXPR_P on trees
with
STATEMENT_CODE_P code.

* c-c++-common/pr94385.c: New test.

[Bug libstdc++/94275] /usr/ccs/bin/ld: Unsatisfied symbols: _ZNSs4_Rep20_S_empty_rep_storageE

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
Disappeared on next build.

[Bug target/94413] New: auto-vectorization of isfinite raises FP exception

[kretz at kde dot org]

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

Bug ID: 94413
   Summary: auto-vectorization of isfinite raises FP exception
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Test case (`-O3`, cf. https://godbolt.org/z/jdfv3r):

#include 
#include 
#include 

using f4 [[gnu::vector_size(16)]] = float;

f4 isfinite(f4 x) {
  f4 r = {};
  for (int i = 0; i < 4; ++i) r[i] = std::isfinite(x[i]) ? 1.f : 0.f;
  return r;
}

using L = std::numeric_limits;
f4 test = {1, 2, 3, L::quiet_NaN()};

int main() {
  std::feclearexcept(FE_ALL_EXCEPT);
  test = isfinite(test);
  if (std::fetestexcept(FE_ALL_EXCEPT) != 0) __builtin_abort();
  return 0;
}

This translates to `fabs(test)<=FLT_MAX` but incorrectly using a signaling
compare instruction.

Alterative vectorization of isfinite(x):
* interpret x as int vector
* return inf > x & inf

This works because if all exponent bits of x are set, x is either inf or NaN
(i.e. not finite).

[Bug middle-end/94412] wrong code with -fsanitize=undefined and vectors

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, -1U / 11 is 390451572, not 0.
11149 /* Convert -A / -B to A / B when the type is signed and overflow
is
11150undefined.  */
11151 if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
11152 && TREE_CODE (op0) == NEGATE_EXPR
11153 && negate_expr_p (op1))
needs to be adjusted the way Marc said.

[Bug middle-end/94412] wrong code with -fsanitize=undefined and vectors

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-03-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marc Glisse  ---
Actually it seems to me that the code is only right with -fsanitize=undefined,
it has to abort.
We replace -v/11u by v/-11u because in fold-const.c we check:
  if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
instead of ANY_INTEGRAL_TYPE_P for instance.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
(In reply to Bill Seurer from comment #6)
> These were both clean builds run on a powerpc64 power8 LE machine.

I can confirm this on x86-64-gnu-linux; if I use the current trunk and undo
this commit, it works – with the patch, it fails.

 * * *

Looking it at in the debugger, one has:

   logical, parameter :: a(0) = .true.
   data d /a%kind/

In gfc_match_varspec, one has:

  if (tmp && tmp->type == REF_INQUIRY)

At this point, primary is "a" and primary->ref->next == tmp == tail while
primary->ref is the (full) array spec. Now one calls:

  gfc_simplify_expr (primary, 0);

which turns this into an EXPR_ARRAY and as this one cleans up, "tmp" now points
to undefined memory and fails.

[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent

[qinzhao at gcc dot gnu.org]

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #6)

> If you have a huge workload, one possible workaround would be to disable
> range tracking, perhaps tweaking line_table->default_range_bits, which would
> give you a bit more "headroom".  IIRC we don't currently expose a way to do
> this, and probably some extra code would be needed.  It's currently
> hardcoded to 5.
> 
> Perhaps some kind of -fno-location-ranges?  It could either:
> (a) don't attempt to store location ranges  (would probably have to disable
> e.g. fix-it hints)
> (b) set line_table->default_range_bits to 0, so that all ranges have to go
> to the ad-hoc table, but buying space for more locations.

I have tried the above (2) to set the line_table->default_range_bits to 0. and
used
this GCC to compile our huge application with -Wmisleading-indent, this time,
the compiler works without the warning. and there are also some proper
misleading-indent warning were emitted.

So, I'd like to add one new gcc option -fno-location-range, whose
implementation is to set line_table->default_range_bits to 0 to save more space
for column tracking.

Is this good to go?

[Bug ipa/90151] 554.roms_r regression on x86_64 at -O2 and generic march/mtune

[jamborm at gcc dot gnu.org]

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

--- Comment #1 from Martin Jambor  ---
This year's numbers:

- on AMD Zen1, we are still 7.2% worse than GCC 7
- on AMD Zen2, the reegression is 4.6%
- in Intel Cascade Lake server CPU, it is 5.4%

This is all -O2, so perhaps not that important for a Fortran
benchmark.

[Bug gcov-profile/94410] 511.povray_r is 11% slower built at -O2 PGO+LTO than with GCC 9 and same options

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
For the record, SPEC 2006 453.povray is similarly affected, the commit
makes it run 26% slower.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  ---
(In reply to Yuxuan Shui from comment #15)
> Your code is going to dereference the value stored in the ABS symbol as an
> address (e.g. if the symbol has value 10, your code will access (*(char
> *)10), barring the unwanted relocation), which is not the intention here.

This works in all cases:

unsigned long
size2 (void)
{
  return ((unsigned long) &_binary_a_c_end
  - (unsigned long) &_binary_a_c_start);
}

[Bug middle-end/90283] 519.lbm_r is 7%-10% slower with -Ofast -march=native and both LTO and PGO than with GCC 8

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
The numbers from this year are:

- on Intel Cascade Lake server CPU the regression disappeared, if
  there ever was one, I don't have Skylake numbers this year.

- On AMD Zen1 CPU, the measured regression is 20% compared to GCC 8
  (15% compared to GCC 9) but that most likely means we hit the known
  code-placement problem again.

- On AMD Zen2 CPU, there is actually 6.8% regression compared to GCC
  8 (and only negligible one compared to GCC 9).  It may or may not be
  the same problem we were looking at last year.  In any event,
  probably not very pressing, given the behavior of the benchmark :-/

[Bug middle-end/94412] New: wrong code with -fsanitize=undefined and vectors

[zsojka at seznam dot cz]

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

Bug ID: 94412
   Summary: wrong code with -fsanitize=undefined and vectors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Output:
$ x86_64-pc-linux-gnu-gcc -fsanitize=undefined testcase.c
$ ./a.out 
Aborted

x[0] looks like garbage

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r10-7453-20200329214350-g60c254b279e-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r10-7453-20200329214350-g60c254b279e-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200329 (experimental) (GCC)

[Bug fortran/94411] New: E0.d not supported

[longb at cray dot com]

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

Bug ID: 94411
   Summary: E0.d not supported
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

We have a customer who complained that the Fortran 2018 feature for
allowing w=0 in E-like format descriptors is not working with
gfortran version 9.2.  I pointed them to the table at
https://gcc.gnu.org/wiki/Fortran2018Status and that the entry for
"d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors" was
marked "No" They pointed out that the other two compilers they
commonly use (Cray and Intel) both support this feature.  So, I'm
submitting their "bug", but changing it to a RFE. With the hope that
their input might help influence the priority given for this feature.

Example test program:



  program test
  real(8) :: r
  r = atan(1.0)
  r = r * 65536
  write (*,'(e0.6)') r
  end program test

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[seurer at linux dot vnet.ibm.com]

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

--- Comment #6 from Bill Seurer  ---
git g:3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6, r10-7443

make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90
# of expected passes3


git g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444

make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90

# of unexpected failures3
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 6)
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 7)
FAIL: gfortran.dg/pr93600_1.f90   -O  (test for excess errors)


These were both clean builds run on a powerpc64 power8 LE machine.

[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation

[felix.von.s at posteo dot de]

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

--- Comment #6 from felix  ---
I don’t mind the transformation being applied. I think it is entirely sound and
may be beneficial; I imagine it may be harder to allocate registers for the
naïve translation of (foo() ? X : X) than it is for (foo(), X). It’s just the
warning that is wrong.

> So, use [[nodiscard]] instead

This is filed against the C frontend, where [[nodiscard]] has not been
implemented. Not even on trunk (as provided today by godbolt.org, at least).
You are asking people to use a feature that does not exist.

Even if [[nodiscard]] is going to be added eventually, most code in the wild
uses __attribute__((warn_unused_result)) and will do so for a while. Which
means it will still be subject to false positives like this one.

Moreover, the attribute often appears in library headers, which the library
user is not really at liberty to change. Are you suggesting that everyone
compile their code with -Dwarn_unused_result=nodiscard
-D__warn_unused_result__=nodiscard passed on the command line? Will that even
work?

Maybe you should reflect for a while on why the C++ and C committees considered
it more useful to standardise [[nodiscard]] with the semantics they did,
instead of the semantics of GCC’s __attribute__((warn_unused_result)) as of
today.

> O_TEXT != 0 ? text_mode () ? O_TEXT : 0 : 0

First of all, that is not equivalent:

int text_mode(void) {
if (mode == MODE_TEXT) {
fprintf(log_file, "text mode selected\n");
return 1;
} else {
fprintf(log_file, "binary mode selected\n");
return 0;
}
}

Maybe I care about that log message, even in the case where the return value
itself happens to be ultimately irrelevant.

Second of all, I should not be faulted for not adding redundant special cases
to my already correct code. I am not going to add convoluted hacks just to
avoid an asinine compiler warning. I do not want to hand-optimise
platform-specific cases like this either; taking care of platform-specific
serendipities that can be exploited for optimisation purposes is the compiler’s
job.

And finally, just because a faulty workaround exists doesn’t make the warning
not wrong. If GCC cannot tell a legitimate use from ‘obfuscation’, it should
err on the side of the former. (I believe a case could be made for multiplying
by zero as well.)

Though I think it would be simpler to just make the semantics of
__attribute__((warn_unused_result)) be exactly like [[nodiscard]].

[Bug gcov-profile/90364] 521.wrf_r is 8-17% slower with PGO at -Ofast and native march/mtune

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

   Last reconfirmed|2019-05-06 00:00:00 |2020-3-30
Summary|521.wrf_r is 9.5 % slower   |521.wrf_r is 8-17% slower
   |with PGO on Zen CPUs at |with PGO at -Ofast and
   |-Ofast and native   |native march/mtune
   |march/mtune |

--- Comment #9 from Martin Jambor  ---
The problem still persists accross the board, causing:

- 17% regression against non-PGO on AMD Zen2 CPU,
-  8% regression against non-PGO on AMD Zen1 CPU, and
- 12% regression against non-PGO on Intel Cascade Lake server CPU.

All of the above is at -Ofast -march=native, by the way, at just -O2
(and generic -march) PGO actually helps by 25-27% on all three
systems, so I would double check before blaming specinvoke (though of
course it might be the culprit).

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
(In reply to Bill Seurer from comment #4)
> The problem is definitely caused by
> 
> g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444
> 
> I built it before and no problems, errors after.

I am utterly perplexed by this. I have reverted once again. The errors reported
by HJ remain and bessel_5.f90 once more segfaults.

I will investigate this PR in its own right.

Regards

Paul

[Bug ipa/94360] 6% run-time regression of 502.gcc_r against GCC 9 when compiled with -O2 and both PGO and LTO

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
PR94410 is another O2 PGO+LTO bug where g:2925cad2151 caused a slowdown.

[Bug gcov-profile/94410] 511.povray_r is 11% slower built at -O2 PGO+LTO than with GCC 9 and same options

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94360

--- Comment #1 from Martin Jambor  ---
PR94360 is another O2 PGO+LTO bug where the commit caused a slowdown.

[Bug gcov-profile/94410] New: 511.povray_r is 11% slower built at -O2 PGO+LTO than with GCC 9 and same options

[jamborm at gcc dot gnu.org]

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

Bug ID: 94410
   Summary: 511.povray_r is 11% slower built at -O2 PGO+LTO than
with GCC 9 and same options
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

SPEC 2017 FPrate benchmark 511.povray_r runs 11 % slower on AMD Zen2
CPU and 10% slower on Intel Cascade Lake server CPU when built with
-O2 (generic march/tuning) and both PGO and LTO with trunk (revision
26b3e568a60) than when compiled with the same options with GCC 9.

Bisecting revealed that the slowdown was introduced with:

commit 2925cad2151842daa387950e62d989090e47c91d
Author: Jan Hubicka 
Date:   Thu Oct 3 17:08:21 2019 +0200

params.def (PARAM_INLINE_HEURISTICS_HINT_PERCENT, [...]): New.

* params.def (PARAM_INLINE_HEURISTICS_HINT_PERCENT,
PARAM_INLINE_HEURISTICS_HINT_PERCENT_O2): New.
* doc/invoke.texi (inline-heuristics-hint-percent,
inline-heuristics-hint-percent-O2): Document.
* tree-inline.c (inline_insns_single, inline_insns_auto): Add new
hint attribute.
(can_inline_edge_by_limits_p): Use it.

From-SVN: r276516

The revision just before it was even 9% and 7% faster than GCC 9 on
AMD and Intel respectively.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug fortran/94408] Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to michalak from comment #1)
> Here is a slightly more simplified version of the test.F90 program that
> still demonstrates the error with gcc 9.1.0 (below). The namelist_t type
> from the previous reproducer code turns out not to be necessary and has been
> removed from the example. Commenting out the indicated line causes the error
> to go away.  Thanks, -John 
> 
> ===
> 
> module mod_input
>   type config_t
> integer :: domain_id
> contains
> procedure :: init  => rw_config
> procedure :: rw_nl_grid
>   end type config_t
>   interface
> module subroutine rw_config (this,iunit)
>   implicit none
>   class (config_t) :: this
>   integer, intent(in), optional :: iunit
> end subroutine rw_config
> module subroutine rw_nl_grid ( this, iunit )
>   implicit none
>   class (config_t) :: this
>   integer, optional, intent(in) :: iunit
> end subroutine rw_nl_grid
>   end interface
>   contains
> module subroutine rw_config (this,iunit)
>   implicit none
>   class (config_t) :: this
>   integer, intent(in), optional :: iunit
>   call this%rw_nl_grid ! comment this out to make error go away
> end subroutine rw_config
> module subroutine rw_nl_grid ( this, iunit )
>   implicit none
>   class (config_t) :: this
>   integer, optional, intent(in) :: iunit
> end subroutine rw_nl_grid
> end module mod_input
> 
> module neptune_write_native
>   contains
>   subroutine Run
> use mod_input
> type(config_t):: config
>   end subroutine Run
> end module neptune_write_native

Although your code is likely conforming (I don't know as I don't
you the construct you're trying to exploit), if you remove the
interface block (which is redundant as contained procedures within
a module have explict interfaces) then the code compiles.

Hopefully, someone who writes similar code will take an interest
in this issue and submit a patch.  Good luck.

[Bug tree-optimization/94403] Missed optimization bswap

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 48147
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48147=edit
gcc10-pr94403.patch

Untested fix for the std::byte part.  Not a regression, so will have to wait
for GCC11.  Also, if the testcase doesn't have the assignment of the parameter
into a separate local temporary (i.e. when the parameter itself is
addressable), then it doesn't work either, the loads stay as MEM_REFs instead
of being transformed to BIT_FIELD_REFs on the parameter.

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Mon, Mar 30, 2020 at 04:23:11PM +, kargl at gcc dot gnu.org wrote:
> 
> --- Comment #2 from kargl at gcc dot gnu.org ---
> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r10-7369-gc38daa7976886a59.
> 
> Patch in the linked git revision appears to expose a latent
> bug in TYPE IS().   Two workarounds are to use either
> 
> type is (real(4))  ! Bad, because of hard coded kind parameter
> 
> or
> 
> integer, parameter :: sp = kind(1.)
> ...
> type is (real(sp))
> 

Untested patch against svn reverion 280157.

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -2239,7 +2239,8 @@ found:
 a scalar integer initialization-expr and valid kind parameter. */
   if (c == ')')
{
- if (e->ts.type != BT_INTEGER || e->rank > 0)
+ if (!gfc_reduce_init_expr (e)
+ || e->ts.type != BT_INTEGER || e->rank > 0)
{
  gfc_free_expr (e);
  return MATCH_NO;

[Bug tree-optimization/94403] Missed optimization bswap

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Component|other   |tree-optimization
   Last reconfirmed||2020-03-30
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Status|RESOLVED|REOPENED

--- Comment #2 from Jakub Jelinek  ---
I don't see how it is similar except that it is about bswap detection.
Your comment is weird, because bswap is detected for int32_t and not for
int64_t, while the comment suggests otherwise.
And the reason this is optimized for int32_t only is that the loop is
completely unrolled in that case, but not for int64_t, where cunrolli punts on
it even with -O2 -funroll-loops or -O3.

And, the std::byte issue is unrelated to that.
--- gcc/gimple-ssa-store-merging.c.jj   2020-03-20 09:33:03.602112329 +0100
+++ gcc/gimple-ssa-store-merging.c  2020-03-30 18:30:31.723341519 +0200
@@ -315,7 +315,8 @@ verify_symbolic_number_p (struct symboli

   lhs_type = gimple_expr_type (stmt);

-  if (TREE_CODE (lhs_type) != INTEGER_TYPE)
+  if (TREE_CODE (lhs_type) != INTEGER_TYPE
+  && TREE_CODE (lhs_type) != ENUMERAL_TYPE)
 return false;

   if (TYPE_PRECISION (lhs_type) != TYPE_PRECISION (n->type))
can fix that one.

[Bug target/94406] 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9 with -Ofast -march=native

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
One more data point, binary compiled for cascadelake does not run on
Zen2, but one for znver2 runs on Cascade Lake and it makes no
difference in run-time.

If disapling epilogues helps on Intel, the difference is less than 2%.

[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese

[gcc-bugzilla at vlasiu dot net]

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

--- Comment #4 from gcc-bugzilla at vlasiu dot net ---
That's really bad news for us. Well, we'll wait for a patch and maybe we are
going to backport-it. If it's going to be too complicated we are probably going
to switch to one of the supported versions (we kind of need to be in sync with
RHEL SCL version of GCC).
Thank you.

[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to gcc-bugzilla from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > N.B. GCC 7 is no longer supported and will not be fixed (but the bug is also
> > present in supported releases).
> 
> We are going to switch soon to GCC 8.3.1 or 9.1.1. It would be nice to have
> a patch for any of those versions. Thank you.

Neither of those is supported either.  Both GCC 8.4 and 9.3 were released
already, so if there is a fix, it can land into 8.4.1 or 9.3.1 or later, not
something older than that.

[Bug fortran/94408] Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure

[michalak at ucar dot edu]

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

--- Comment #1 from michalak at ucar dot edu ---
Here is a slightly more simplified version of the test.F90 program that still
demonstrates the error with gcc 9.1.0 (below). The namelist_t type from the
previous reproducer code turns out not to be necessary and has been removed
from the example. Commenting out the indicated line causes the error to go
away.  Thanks, -John 

===

module mod_input
  type config_t
integer :: domain_id
contains
procedure :: init  => rw_config
procedure :: rw_nl_grid
  end type config_t
  interface
module subroutine rw_config (this,iunit)
  implicit none
  class (config_t) :: this
  integer, intent(in), optional :: iunit
end subroutine rw_config
module subroutine rw_nl_grid ( this, iunit )
  implicit none
  class (config_t) :: this
  integer, optional, intent(in) :: iunit
end subroutine rw_nl_grid
  end interface
  contains
module subroutine rw_config (this,iunit)
  implicit none
  class (config_t) :: this
  integer, intent(in), optional :: iunit
  call this%rw_nl_grid ! comment this out to make error go away
end subroutine rw_config
module subroutine rw_nl_grid ( this, iunit )
  implicit none
  class (config_t) :: this
  integer, optional, intent(in) :: iunit
end subroutine rw_nl_grid
end module mod_input

module neptune_write_native
  contains
  subroutine Run
use mod_input
type(config_t):: config
  end subroutine Run
end module neptune_write_native

[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese

[gcc-bugzilla at vlasiu dot net]

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

--- Comment #2 from gcc-bugzilla at vlasiu dot net ---
(In reply to Jonathan Wakely from comment #1)
> N.B. GCC 7 is no longer supported and will not be fixed (but the bug is also
> present in supported releases).

We are going to switch soon to GCC 8.3.1 or 9.1.1. It would be nice to have a
patch for any of those versions. Thank you.

[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix7.1.0.0
 Status|UNCONFIRMED |NEW
  Component|c++ |libstdc++
   Last reconfirmed||2020-03-30
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
N.B. GCC 7 is no longer supported and will not be fixed (but the bug is also
present in supported releases).

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r10-7369-gc38daa7976886a59.

Patch in the linked git revision appears to expose a latent
bug in TYPE IS().   Two workarounds are to use either

type is (real(4))  ! Bad, because of hard coded kind parameter

or

integer, parameter :: sp = kind(1.)
...
type is (real(sp))

[Bug c++/94409] New: std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese

[gcc-bugzilla at vlasiu dot net]

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

Bug ID: 94409
   Summary: std::regexp (std::collate?) with GCC 7.3.1 on AIX,
Japanese
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at vlasiu dot net
  Target Milestone: ---

std::regexp constructor fail on AIX (Japanese). Works fine for English,
Spanish, Italian, French and German languages.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/freeware/libexec/gcc/powerpc-ibm-aix7.1.0.0/7.3.1/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ../gcc-7.3.1-20180303/configure --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran --prefix=/opt/freeware
--mandir=/opt/freeware/man --infodir=/opt/freeware/info
--enable-version-specific-runtime-libs
--disable-nls --enable-decimal-float=dpd --enable-bootstrap
--build=powerpc-ibm-aix7.1.0.0
Thread model: aix
gcc version 7.3.1 20180303 (GCC) 

The code:

#include 
#include 
#include 

using namespace std;

int main()
{
   char* pLocale = setlocale(LC_ALL, NULL);
   std::cout << "setlocale(): " << pLocale << std::endl;

   const std::regex r1("^(\\s+)?(.*?)(\\s+)?=(\\s+)?(.*?)(\\s+)?");
   std::cout << "std::regex r1: OK" << std::endl;

   setlocale(LC_ALL, "Ja_JP");
   pLocale = setlocale(LC_ALL, NULL);
   std::cout << "setlocale(): " << pLocale << std::endl;

   const std::regex r2("asdf");
   std::cout << "std::regex r2: OK" << std::endl;

   // const std::regex r3("^(\\s+)?(.*?)(\\s+)?=(\\s+)?(.*?)(\\s+)?");
   const std::regex r3("\\s+");
   std::cout << "std::regex r3: OK" << std::endl;

   return 0;
}

The output:

$ ./a.out 
setlocale(): C C C C C C
std::regex r1: OK
setlocale(): Ja_JP Ja_JP Ja_JP Ja_JP Ja_JP Ja_JP
std::regex r2: OK
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::append
IOT/Abort trap (core dumped)
$

$ gdb -c ./core ./a.out
...
(gdb) backtrace
#0  0x0957ff14 in pthread_kill () from
/usr/lib/libpthreads.a(shr_xpg5_64.o)
#1  0x0957f768 in _p_raise () from
/usr/lib/libpthreads.a(shr_xpg5_64.o)
#2  0x0903956c in raise () from /usr/lib/threads/libc.a(shr_64.o)
#3  0x09055f68 in abort () from /usr/lib/threads/libc.a(shr_64.o)
#4  0x090001c91740 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#5  0x090001ca0a4c in __cxxabiv1::__terminate(void (*)()) () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#6  0x090001c91530 in std::terminate() () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#7  0x090001c9fc90 in __cxa_rethrow () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#8  0x090001cdbc50 in std::__cxx11::collate::do_transform () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#9  0x090001cfea54 in std::__cxx11::collate::transform () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#10 0x00010002dba0 in std::__cxx11::basic_string, std::allocator >
std::__cxx11::regex_traits::transform(char*, char*) const ()
#11 0x00010002c6c0 in std::__cxx11::basic_string, std::allocator >
std::__cxx11::regex_traits::transform_primary(char const*,
char const*) const ()
#12 0x00010002ae60 in
std::__detail::_BracketMatcher, false,
false>::_M_apply(char, std::integral_constant)
const::{lambda()#1}::operator()() const ()
#13 0x00010002ab2c in
std::__detail::_BracketMatcher, false,
false>::_M_apply(char, std::integral_constant) const ()
#14 0x00010002a6f8 in
std::__detail::_BracketMatcher, false,
false>::_M_make_cache(std::integral_constant) ()
#15 0x000100026294 in
std::__detail::_BracketMatcher, false,
false>::_M_ready() ()
#16 0x000100022600 in void
std::__detail::_Compiler
>::_M_insert_character_class_matcher() ()
#17 0x000100013208 in
std::__detail::_Compiler >::_M_atom() ()
#18 0x0001000101d8 in
std::__detail::_Compiler >::_M_term() ()
#19 0x000100010028 in
std::__detail::_Compiler >::_M_alternative()
()
#20 0x0001fe48 in
std::__detail::_Compiler >::_M_disjunction()
()#21 0x00012460 in
std::__detail::_Compiler >::_Compiler(char
const*, char const*, std::locale
const&, std::regex_constants::syntax_option_type) ()
#22 0x0001206c in
std::enable_if::value,
std::shared_ptr > const>
>::type std::__detail::__compile_nfa >(char const*, char const*,
std::__cxx11::regex_traits::locale_type const&,
std::regex_constants::syntax_option_type) ()
#23 0x00011e70 in std::__cxx11::basic_regex >::basic_regex(char const*, char
const*, std::locale, std::regex_constants::syntax_option_type) ()
#24 0x00011c40 in std::__cxx11::basic_regex >::basic_regex(char const*, char
const*, std::regex_constants::syntax_option_type) ()
#25 0x00011a7c in std::__cxx11::basic_regex >::basic_regex(char const*,

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

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

--- Comment #15 from Yuxuan Shui  ---
(In reply to H.J. Lu from comment #12)
> (In reply to Yuxuan Shui from comment #11)
> > (In reply to Andrew Pinski from comment #8)
> > > Also it is wrong for a person to assume a normal C variable could be
> > > SHN_ABS; that is the bug here.  It is a bug in the user code.
> > > I showed up to fix it by using an top level inline-asm.
> > 
> > Why is this wrong? Is it written down somewhere that a C variable can never
> > be SHN_ABS, perhaps in the standard, or in the X86-psABI?
> > 
> > If this is wrong, then what is the correct way to access a SHN_ABS symbol?
> > Is it just no way to do it? If so, what's the purpose of objcopy generating
> > such symbols?
> 
> Have you tried my way with ld?  Lld bug is a different issue.

Your code is going to dereference the value stored in the ABS symbol as an
address (e.g. if the symbol has value 10, your code will access (*(char *)10),
barring the unwanted relocation), which is not the intention here.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #19 from Jakub Jelinek  ---
Fixed.

[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5abbfd3cd36342df530410033844584d8b85e187

commit r10-7460-g5abbfd3cd36342df530410033844584d8b85e187
Author: Jakub Jelinek 
Date:   Mon Mar 30 18:05:01 2020 +0200

i386: Fix up *one_cmplv*2* insn with avx512f [PR94343]

This define_insn has two issues.
One is that with -mavx512f -mno-avx512vl it can emit an AVX512VL-only insn
- 128-bit or 256-bit EVEX encoded vpternlog{d,q}.
Another one is that because there is no vpternlog{b,w}, we emit vpternlogd
instead, but then we shouldn't pretend we support masking of that, because
we don't.
The first one can be fixed by forcing the use of %zmm* registers instead of
%xmm* or %ymm* if AVX512F but not AVX512VL, like we do for a couple of
other
insns (although that is primarily done in order to support %xmm16+ regs).
But we need to make sure that in that case the input operand isn't memory,
because while we can read and store the higher bits of registers, we don't
want to read from memory more bytes than what we should read.

A variant to these two if_then_else set attrs, condition in the output and
larger condition would be 4 different define_insns (one with something like
VI48_AVX512VL iterator, masking, no g modifiers and "vm" input constraint,
another one with VI48_AVX iterator, !TARGET_AVX512VL in condition,
no masking, g modifiers and "v" input constraint, one with VI12_AVX512VL
iterator, no masking, no g modifiers and "vm" input constraint and last one
with
VI12_AVX2 iterator, !TARGET_AVX512VL in condition, no masking, g modifiers
and "v" input constraint, but I think having one pattern is shorter than
that.

2020-03-30  Jakub Jelinek  

PR target/94343
* config/i386/sse.md (one_cmpl2): If
!TARGET_AVX512VL, use 512-bit vpternlog and make sure the input
operand is a register.  Don't enable masked variants for
V*[QH]Imode.

* gcc.target/i386/avx512f-pr94343.c: New test.
* gcc.target/i386/avx512vl-pr94343.c: New test.

[Bug fortran/94408] New: Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure

[michalak at ucar dot edu]

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

Bug ID: 94408
   Summary: Spurious error: ‘rw_nl_grid’ must be a module
procedure or an external procedure
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michalak at ucar dot edu
  Target Milestone: ---

The following session log contains a listing of the reproducer program,
test.F90, and a set of compile and run commands that demonstrate the issue. 
This was collected on the NCAR supercomputer cheyenne.ucar.edu using Intel,
then PGI, then GCC Fortran compilers. Intel and PGI compile the code without
issue. Note: although the session log indicates gnu/8.3.0, the test was also
run with the most recent version of gcc installed on Cheyenne, 9.1.0, and
produced identical results.  Thank you.  


John Michalakes, Software Engineer
Cooperative Programs for the Advancement of Earth System Sciences (CPAESS)
University Corporation for Atmospheric Research
micha...@ucar.edu

===


cheyenne:/glade/u/home/michalak/nf 1007 > cat session.txt
Script started on Sun 29 Mar 2020 05:58:20 AM MDT
> cat test.F90
module mod_input
  type config_t
integer :: domain_id
contains
procedure :: init  => rw_config
procedure :: rw_nl_grid
  end type config_t
  type namelist_t
type(config_t) :: config
  end type namelist_t
  interface
module subroutine rw_config (this,iunit)
  implicit none
  class (config_t) :: this
  integer, intent(in), optional :: iunit
end subroutine rw_config
module subroutine rw_nl_grid ( this, iunit )
  implicit none
  class (config_t) :: this
  integer, optional, intent(in) :: iunit
end subroutine rw_nl_grid
  end interface
  contains
module subroutine rw_config (this,iunit)
  implicit none
  class (config_t) :: this
  integer, intent(in), optional :: iunit
  call this%rw_nl_grid
end subroutine rw_config
module subroutine rw_nl_grid ( this, iunit )
  implicit none
  class (config_t) :: this
  integer, optional, intent(in) :: iunit
end subroutine rw_nl_grid
end module mod_input

module neptune_write_native
  contains
  subroutine Run
use mod_input
type(namelist_t):: nl
  end subroutine Run
end module neptune_write_native

> module load intel

Lmod is automatically replacing "gnu/8.3.0" with "intel/18.0.5".


Due to MODULEPATH changes, the following have been reloaded:
  1) hdf5-mpi/1.10.5 2) mpt/2.19 3) ncarcompilers/0.5.0

michalak/nf> ifort -c test.F90
michalak/nf> module load pgi

Lmod is automatically replacing "intel/18.0.5" with "pgi/19.3".


Due to MODULEPATH changes, the following have been reloaded:
  1) hdf5-mpi/1.10.5 2) mpt/2.19 3) ncarcompilers/0.5.0

> pgf90 -c test.F90
> module load gnu

Lmod is automatically replacing "pgi/19.3" with "gnu/8.3.0".


Due to MODULEPATH changes, the following have been reloaded:
  1) hdf5-mpi/1.10.5 2) mpt/2.19 3) ncarcompilers/0.5.0

> gfortran test.F90
test.F90:40:8:

 use mod_input
1
Error: ‘rw_nl_grid’ must be a module procedure or an external procedure with an
explicit interface at (1)
michalak/nf> exit
exit

Script done on Sun 29 Mar 2020 05:59:25 AM MDT

[Bug fortran/94407] New: Spurious Error: ‘rw_nl_grid’ must be a module procedure or an external procedure

[michalak at ucar dot edu]

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

Bug ID: 94407
   Summary: Spurious Error: ‘rw_nl_grid’ must be a module
procedure or an external procedure
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michalak at ucar dot edu
  Target Milestone: ---

The following session log contains a listing of the reproducer program,
test.F90, and a set of compile and run commands that demonstrate the issue. 
This was collected on the NCAR supercomputer cheyenne.ucar.edu using Intel,
then PGI, then GCC Fortran compilers. Intel and PGI compile the code without
issue. Note: although the session log indicates gnu/8.3.0, the test was also
run with the most recent version of gcc installed on Cheyenne, 9.1.0, and
produced identical results.  Thank you.  


John Michalakes, Software Engineer
Cooperative Programs for the Advancement of Earth System Sciences (CPAESS)
University Corporation for Atmospheric Research
micha...@ucar.edu

===


cheyenne:/glade/u/home/michalak/nf 1007 > cat session.txt
Script started on Sun 29 Mar 2020 05:58:20 AM MDT
> cat test.F90
module mod_input
  type config_t
integer :: domain_id
contains
procedure :: init  => rw_config
procedure :: rw_nl_grid
  end type config_t
  type namelist_t
type(config_t) :: config
  end type namelist_t
  interface
module subroutine rw_config (this,iunit)
  implicit none
  class (config_t) :: this
  integer, intent(in), optional :: iunit
end subroutine rw_config
module subroutine rw_nl_grid ( this, iunit )
  implicit none
  class (config_t) :: this
  integer, optional, intent(in) :: iunit
end subroutine rw_nl_grid
  end interface
  contains
module subroutine rw_config (this,iunit)
  implicit none
  class (config_t) :: this
  integer, intent(in), optional :: iunit
  call this%rw_nl_grid
end subroutine rw_config
module subroutine rw_nl_grid ( this, iunit )
  implicit none
  class (config_t) :: this
  integer, optional, intent(in) :: iunit
end subroutine rw_nl_grid
end module mod_input

module neptune_write_native
  contains
  subroutine Run
use mod_input
type(namelist_t):: nl
  end subroutine Run
end module neptune_write_native

> module load intel

Lmod is automatically replacing "gnu/8.3.0" with "intel/18.0.5".


Due to MODULEPATH changes, the following have been reloaded:
  1) hdf5-mpi/1.10.5 2) mpt/2.19 3) ncarcompilers/0.5.0

michalak/nf> ifort -c test.F90
michalak/nf> module load pgi

Lmod is automatically replacing "intel/18.0.5" with "pgi/19.3".


Due to MODULEPATH changes, the following have been reloaded:
  1) hdf5-mpi/1.10.5 2) mpt/2.19 3) ncarcompilers/0.5.0

> pgf90 -c test.F90
> module load gnu

Lmod is automatically replacing "pgi/19.3" with "gnu/8.3.0".


Due to MODULEPATH changes, the following have been reloaded:
  1) hdf5-mpi/1.10.5 2) mpt/2.19 3) ncarcompilers/0.5.0

> gfortran test.F90
test.F90:40:8:

 use mod_input
1
Error: ‘rw_nl_grid’ must be a module procedure or an external procedure with an
explicit interface at (1)
michalak/nf> exit
exit

Script done on Sun 29 Mar 2020 05:59:25 AM MDT

[Bug target/94406] 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9 with -Ofast -march=native

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
And for completeness, LNT sees this too and has just managed to catch the
regression:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=276.427.0=295.427.0;

[Bug target/94406] 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9 with -Ofast -march=native

[jamborm at gcc dot gnu.org]

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

--- Comment #1 from Martin Jambor  ---
For the record, the collected profiles both for the traditional
"cycles:u" event and (originally unintended) "ls_stlf:u" event are
below:

-Ofast -march=native -mtune=native

# Samples: 894K of event 'cycles:u'
# Event count (approx.): 735979402525
#
# Overhead   Samples  Command  Shared Object Symbol 
#     ...   
.
#
67.18%599542  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
mat_times_vec_
11.40%102686  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
shell_
11.37%101388  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
bi_cgstab_block_
 6.95% 62694  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
jacobian_
 1.88% 16957  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
flux_
 1.01%  9023  bwaves_r_peak.e  libc-2.31.so  [.]
__memset_avx2_unaligned


# Samples: 769K of event 'ls_stlf:u'
# Event count (approx.): 154704730574
#
# Overhead   Samples  Command  Shared Object Symbol 
#     ...   

#
94.59%612921  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
mat_times_vec_
 1.83% 88259  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
shell_
 1.12% 13615  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
flux_
 1.11% 43093  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
jacobian_
 1.05%  8746  bwaves_r_peak.e  libc-2.31.so  [.]
__memset_avx2_unaligned



-Ofast -march=native -mtune=native --param vect-epilogues-nomask=0

# Samples: 816K of event 'cycles:u'
# Event count (approx.): 671104061807
#
# Overhead   Samples  Command  Shared Object Symbol 
#     ...   
.
#
64.07%521532  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
mat_times_vec_
12.50%102670  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
shell_
12.39%100777  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
bi_cgstab_block_
 7.60% 62641  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
jacobian_
 2.06% 16925  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
flux_
 1.17%  9531  bwaves_r_peak.e  libc-2.31.so  [.]
__memset_avx2_unaligned

# Samples: 705K of event 'ls_stlf:u'
# Event count (approx.): 55009340780
#
# Overhead   Samples  Command  Shared Object Symbol 
#     ...   
..
#
86.26%532930  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
mat_times_vec_
 5.15% 88270  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
shell_
 3.17% 13696  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
flux_
 3.06% 57149  bwaves_r_peak.e  bwaves_r_peak.experiment-m64  [.]
jacobian_
 1.59%  9226  bwaves_r_peak.e  libc-2.31.so  [.]
__memset_avx2_unaligned

[Bug c++/94405] New: [temp.names]p4 not fully implemented

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94405
   Summary: [temp.names]p4 not fully implemented
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

 says "In a qualified-id of a
declarator-id or in a qualified-id formed by a class-head-name or
enum-head-name, the keyword template shall not appear at the top level." so the
following probably shouldn't compile:

template struct A {
  template struct B;
  template struct B;
};
template template struct A::template B {};

[Bug target/94406] New: 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9 with -Ofast -march=native

[jamborm at gcc dot gnu.org]

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

Bug ID: 94406
   Summary: 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9
with -Ofast -march=native
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: andre.simoesdiasvieira at arm dot com
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

SPEC 2017 FPrate benchmark 503.bwaves_r compiled with -Ofast
-march=native -mtune=native runs 11% slower on AMD Zen2 CPUs when
built with trunk (revision abe13e1847f) than when compiled with GCC
9.2.

Bisecting led to commit:

  commit 1297712fb4af6c6bfd827e0f0a9695b14669f87d
  Author: Andre Vieira 
  Date:   Thu Oct 31 09:49:47 2019 +

[vect]Make vect-epilogues-nomask=1 default

This patch turns epilogue vectorization on by default for all targets.


  From-SVN: r277659

If we use current trunk but build also with option
--param vect-epilogues-nomask=0 we get run-time on par with GCC 9.

This is also the reason why generic march/tuning or building with
-mprefer-vector-width=128 currently results in faster code than simple
-march=native.

Interestingly, I do not see this issue on an Intel Cascade Lake Server
CPU, even though the epilogue is created there too - judging by CFG of
the hottest function which looks the same.

And I am not sure to what extent it tells anything at all, but I
accidentally also perf'ed load-to-store-stall events and in the slow
version, the reported "samples" was 10% higher and the reported "event
count" shot up 2.8 times(!).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/94401] [10 Regression] pr92420.c fails on aarch64 since r10-7415

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-03-30
 CC||law at redhat dot com
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jeffrey A. Law  ---
Confirmed.  My tester tripped over this as well.

No special options are needed at configure time.

[Bug rtl-optimization/87716] [9/10 Regression] FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:291aa50a63194245ad3ab8bd584f9c0286c5b44c

commit r10-7459-g291aa50a63194245ad3ab8bd584f9c0286c5b44c
Author: Martin Liska 
Date:   Mon Mar 30 17:49:27 2020 +0200

XFAIL pr57193.c test-case.

PR rtl-optimization/87716
* gcc.target/i386/pr57193.c: XFAIL a test-case.

[Bug testsuite/94402] FAIL: gfortran.dg/vect/vect-8.f90 -O scan-tree-dump-times vect "vectorized 22 loops" 1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:3a9db91bee496712656e0f8aecf55f39cffd8413

commit r10-7458-g3a9db91bee496712656e0f8aecf55f39cffd8413
Author: Martin Liska 
Date:   Mon Mar 30 17:49:10 2020 +0200

Fix scan pattern of vect-8.f90 dump.

PR testsuite/94402
* gfortran.dg/vect/vect-8.f90: Allow 22 or 23 loops
to be vectorized (based on libmvec presence).

[Bug testsuite/94402] FAIL: gfortran.dg/vect/vect-8.f90 -O scan-tree-dump-times vect "vectorized 22 loops" 1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Fixed on master.

[Bug tree-optimization/93328] missed optimization opportunity in deserialization code

[boris_oncev at hotmail dot com]

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

--- Comment #5 from Boris  ---
full code:
https://godbolt.org/z/zjNqYV

template 
auto reverse(T num) {

// misses optimization when num is int32_t OK for int64_t
auto* bytes = reinterpret_cast();

// misses optimization for both 32 and 64 bit ints
//auto* bytes = reinterpret_cast();

constexpr auto size = sizeof(num);
for (int i = 0; i < size / 2; i++) {
std::swap(bytes[i], bytes[size-i-1]);
}

return num;
}

[Bug tree-optimization/93328] missed optimization opportunity in deserialization code

[boris_oncev at hotmail dot com]

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

Boris  changed:

   What|Removed |Added

 CC||boris_oncev at hotmail dot com

--- Comment #4 from Boris  ---
*** Bug 94403 has been marked as a duplicate of this bug. ***

[Bug other/94403] Missed optimization bswap

[boris_oncev at hotmail dot com]

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

Boris  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Boris  ---
Very similar

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

[Bug c++/94404] New: [meta-bug] C++ core issues

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94404
   Summary: [meta-bug] C++ core issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This meta bug tracks open reports for various C++ DRs.

[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Smaller fix applied to GCC 10, larger one queued for GCC 11.

[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7457-gec919cfcef8d7fcbaab24d0e0d472c65e5329ca6
Author: Jakub Jelinek 
Date:   Mon Mar 30 17:38:21 2020 +0200

Fix vextract* masked patterns [PR93069]

The AVX512F documentation clearly states that in instructions where the
destination is a memory only merging-masking is possible, not zero-masking,
and the assembler enforces that.

The testcase in this patch fails to assemble because of
Error: unsupported masking for `vextracti32x8'
on
vextracti32x8   $0x0, %zmm1, -64(%rsp){%k1}{z}
For the vector extraction patterns, we apparently have 7 *_maskm patterns
that only accept memory destinations and rtx_equal_p merge-masking source
for it, 7 * corresponding patterns that allow memory destination
only for the non-masked cases (through ), then 2
* patterns (lo ssehalf V16FI and lo ssehalf VI8F_256 ones) which
do allow memory destination even for masked cases and are the cause of the
testsuite failure, because we must not allow C constraint if the
destination
is m, and finally one pair of patterns (separate * and *_mask, hi ssehalf
VI4F_256), which has another issue (for which I don't have a testcase
though), where if it would match zero-masking with register destination,
it wouldn't emit the needed {z} into assembly.
The attached patch fixes those 3 issues only, perhaps more suitable for
backporting.

2020-03-30  Jakub Jelinek  

PR target/93069
* config/i386/sse.md (vec_extract_lo_): Use
 instead of m in output operand constraint.
(vec_extract_hi_): Use  instead of
%{%3%}.

* gcc.target/i386/avx512vl-pr93069.c: New test.
* gcc.dg/vect/pr93069.c: New test.

[Bug other/94403] New: Missed optimization bswap

[boris_oncev at hotmail dot com]

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

Bug ID: 94403
   Summary: Missed optimization bswap
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris_oncev at hotmail dot com
  Target Milestone: ---

full code:
https://godbolt.org/z/zjNqYV

template 
auto reverse(T num) {

// misses optimization when num is int32_t OK for int64_t
auto* bytes = reinterpret_cast();

// misses optimization for both 32 and 64 bit ints
//auto* bytes = reinterpret_cast();

constexpr auto size = sizeof(num);
for (int i = 0; i < size / 2; i++) {
std::swap(bytes[i], bytes[size-i-1]);
}

return num;
}

[Bug middle-end/93465] [10 Regression] ICE in oacc_verify_routine_clauses, at omp-general.c:1802 since r10-471-gb48f44bf77a39fef

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
I have acked the patch in
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/msg00247.html, are you going
to commit it?

[Bug rtl-optimization/94344] [9/10 Regression] Rotate pattern not recognized anymore

[stefansf at linux dot ibm.com]

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 48145 [details]
> gcc10-pr94344.patch

LGTM. I did some tests (including the initial one) which all succeeded in
detecting a signed rotate. Thank you very much for the quick fix!

[Bug debug/94281] [8/9 Regression] g++: error: hash.cpp: ‘-fcompare-debug’ failure (length) since r8-5241-g8697bf9f46f36168

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] g++:|[8/9 Regression] g++:
   |error: hash.cpp:|error: hash.cpp:
   |‘-fcompare-debug’ failure   |‘-fcompare-debug’ failure
   |(length) since  |(length) since
   |r8-5241-g8697bf9f46f36168   |r8-5241-g8697bf9f46f36168

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/94298] x86 duplicates loads

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
I think that the root of the problem is that IRA on register cost calculation
sub-pass chooses memory for the pseudo.

It happens because the current algorithm (which is just an adoption of old
recglass.c) considers insn alternatives for each operand independently of other
operands. Roughly speaking, if we have insn with 2 alternatives and constraints
'r,m' for one operand and 'm,r' for another operand, the algorithm considers
'm' for the both operands (or 'r' for the both operands) are perfect (zero
cost) match.

I've tried to modify the current algorithm by small changes without a success. 
The full changes would result in what I have on ira-select branch.  ira-select
chooses an insn alternative and then calculate the costs taking this choice
into account.  Although move insns are a real challenge for such algorithm
because they have too many alternatives.

Switching to ira-select branch creates a lot of new testsuite failures on some
targets for GCC tests expecting a specific code generation and actually does
not improve overall SPEC rates on x86-64.

I am thinking about combination of the two approaches but it is definitely not
work which could be done for GCC10.

[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
--- gcc/config/aarch64/aarch64.c.jj 2020-03-18 12:51:41.051640609 +0100
+++ gcc/config/aarch64/aarch64.c2020-03-30 16:28:29.133717645 +0200
@@ -16030,6 +16030,16 @@ aapcs_vfp_sub_candidate (const_tree type
if (TREE_CODE (field) != FIELD_DECL)
  continue;

+   /* Ignore C++17 empty base fields, while their type indicates
+  they do contain padding, they have zero size and thus don't
+  contain any padding.  */
+   if (DECL_ARTIFICIAL (field)
+   && DECL_NAME (field) == NULL_TREE
+   && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
+   && DECL_SIZE (field)
+   && integer_zerop (DECL_SIZE (field)))
+ continue;
+
sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep);
if (sub_count < 0)
  return -1;
fixes that.  Though, guess there might need to be a -Wpsabi warning and that
would likely need propagate to callers whether such field has been seen and if
it has been seen, let the code retry in a mode where it wouldn't ignore those,
compare the result and if it is different, warn.
Will defer to aarch64 maintainers.

And, guess it would be nice to test other targets for similar issues.
Do we want e.g. to adjust struct-layout-1_generate.c, so that it only tests
structures with such an empty base and just check value passing of such classes
(both caller and callee at various spots in argument list) or returning,
compile everything in C++14 and C++17 and compare assembly, verify that it
fails on aarch64 and then look for others?

[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
The language frontend shouldn't do this kind of code transformations, whether
you think the warning should warn or not here, imo.

[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Compared to [[nodiscard]], warn_unused_result attempts to force users harder
not to ignore the return value.  So, it doesn't allow just (void) cast to shut
up the warning, and this foo () ? 0 : 0 or 0 * foo () is similar obfuscation to
ignore the result when whomever that added the warn_unused_result attribute
wanted users not to do that.
So, use [[nodiscard]] instead of you want less aggressive checking, or change
your code, like O_TEXT != 0 ? text_mode () ? O_TEXT : 0 : 0 where you wouldn't
even call the function if you want to ignore the return value.

[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Seems it is in aapcs_vfp_sub_candidate, which for C++17 recurses on the
DECL_FIELD_IS_BASE FIELD_DECL and because
16039   /* There must be no padding.  */
16040   if (maybe_ne (wi::to_poly_wide (TYPE_SIZE (type)),
16041 count * GET_MODE_BITSIZE (*modep)))
16042 return -1;
check fails, as the type is base, with no elts (count == 0) but TYPE_SIZE of
BITS_PER_UNIT, it returns -1 and thus returns it for the whole pair class too.
The question is what exactly the AAPCS says.  And if we want to ignore the
empty base fields, the question is how to exactly recognize them in the
backend, because DECL_FIELD_IS_BASE is a FE macro, and I doubt one can use it
e.g. in LTO.
So, shall aapcs_vfp_sub_candidate ignore DECL_ARTIFICIAL FIELD_DECLs that have
DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)) ?  Something else?
What do other compilers do here?

[Bug testsuite/94402] FAIL: gfortran.dg/vect/vect-8.f90 -O scan-tree-dump-times vect "vectorized 22 loops" 1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
That will catch testers that will newly have only 21 loops vectorized.
I'm going to send a patch for this.