[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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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++/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 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 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/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 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 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

[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

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 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

[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 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

[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 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 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 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 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 target/94364] 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Huh, looks like this is the (patched by us) memory copying done in spec_qsort?
I wonder if you can re-measure with our patching undone but then with
-fno-strict-aliasing (though I think that only was required with LTO).

How large are the objects sorted in mcf?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |10.0
   Priority|P3  |P4

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
We end up during gimplification with:

get_flags ()
{
  int D.1939;

  text_mode ();
  D.1939 = 0;
  return D.1939;
}

which then leads to unused value. While:

int get_flags2(void) {
  return text_mode() ? O_TEXT : foo ();
}

is fine and no warning is reported.

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #9 from fdlbxtqi  ---
https://github.com/microsoft/WSL/issues/3898

[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 #11 from Yuxuan Shui  ---
(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?

[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #2)
> But the ICE happens because the result from the function at transform time
> does not match that at analysis time.
> 
> Richard?

Looks like we're trying to compute:

  alignment_support_scheme
= vect_supportable_dr_alignment (first_dr_info, false);
  gcc_assert (alignment_support_scheme);

even for VMAT_GATHER_SCATTER, which always accesses individual
elements.  Guess we should set alignment_support_scheme to
dr_unaligned_supported instead of calling
vect_supportable_dr_alignment.

The target hook is probably incorrect for SVE + -mstrict-align.

[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
(In reply to rsand...@gcc.gnu.org from comment #3)
> (In reply to Richard Biener from comment #2)
> > But the ICE happens because the result from the function at transform time
> > does not match that at analysis time.
> > 
> > Richard?
> 
> Looks like we're trying to compute:
> 
>   alignment_support_scheme
> = vect_supportable_dr_alignment (first_dr_info, false);
>   gcc_assert (alignment_support_scheme);
> 
> even for VMAT_GATHER_SCATTER, which always accesses individual
> elements.  Guess we should set alignment_support_scheme to
> dr_unaligned_supported instead of calling
> vect_supportable_dr_alignment.

...in the gather/scatter case only, of course :-)

[Bug target/94400] 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-03-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
I can confirm on LNT znver2 machine, but the bisection points to a different
commit:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=324.387.0=311.387.0=348.387.0=280.387.0=297.387.0;

while LNT znver1 machine is not affected and the speed is similar to GCC 9:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=145.387.0=49.387.0=79.387.0=259.387.0=29.387.0;

[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[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 #3 from ammy.yi  ---
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

Hi martin,

If it is libgcov issue, do you know where to file issue for it?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||53947

--- Comment #2 from Richard Biener  ---
Do we ever hit the vectorized paths?  I guess the number of iterations isn't
bound so the cost model has a hard time, possibly only triggering at runtime.


Referenced Bugs:

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

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.0
 Ever confirmed|0   |1
 CC||markeggleston at gcc dot 
gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
  Known to work||9.3.0
   Last reconfirmed||2020-03-30

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-7369-gc38daa7976886a59.

[Bug middle-end/87528] Popcount changes caused 531.deepsjeng_r run-time regression on Skylake

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Do I understand correctly that this is fixed?

[Bug target/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The problem is that RA doesn't care about predicates, only constraints, and so
the constraints need to match the predicates, or it needs to be ensured in insn
conditions instead.

[Bug target/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|Infinite loops are  |[10 Regression] Infinite
   |optimized away for C99  |loops are optimized away
   ||for C99
   Target Milestone|--- |10.0
 CC||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Infinite loops do not make much sense so the consensus was to enable it
everywhere by default (also for non-C/C++ languages).

Joseph, any opinion whether we should make the default language (standard)
dependent?  It'll be tracked per function with LTO but inlining currently
does not care about caller/callees state difference.

[Bug tree-optimization/94398] New: ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[z.zhanghaijian at huawei dot com]

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

Bug ID: 94398
   Summary: ICE: in vectorizable_load, at tree-vect-stmts.c:9173
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: z.zhanghaijian at huawei dot com
CC: rguenther at suse dot de
  Target Milestone: ---

test case: gcc/testsuite/gcc.dg/pr94269.c

Command line: aarch64-linux-gnu-gcc -S -O2 -fopt-info -march=armv8.2-a+sve
-msve-vector-bits=256 -ftree-loop-vectorize -funsafe-math-optimizations
-mstrict-align pr94269.c

pr94269.c:16:9: optimized: loop vectorized using 32 byte vectors
during GIMPLE pass: vect
pr94269.c: In function 'foo':
pr94269.c:5:1: internal compiler error: in vectorizable_load, at
tree-vect-stmts.c:9173
5 | foo(long n, float *x, int inc_x,
  | ^~~
0x162fcc7 vectorizable_load
../../gcc-git/gcc/tree-vect-stmts.c:9173
0x1635173 vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../gcc-git/gcc/tree-vect-stmts.c:11034
0x165a33f vect_transform_loop_stmt
../../gcc-git/gcc/tree-vect-loop.c:8307
0x165b5c3 vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc-git/gcc/tree-vect-loop.c:8708
0x1689f07 try_vectorize_loop_1
../../gcc-git/gcc/tree-vectorizer.c:990
0x168a183 try_vectorize_loop
../../gcc-git/gcc/tree-vectorizer.c:1047
0x168a32f vectorize_loops()
../../gcc-git/gcc/tree-vectorizer.c:1127
0x14e55e3 execute
../../gcc-git/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

With -mstrict-align, aarch64_builtin_support_vector_misalignment will returns
false when misalignment factor is unknown at compile time.
Then vect_supportable_dr_alignment returns dr_unaligned_unsupported, which
triggers the ICE.

[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
 CC|rguenther at suse dot de   |rguenth at gcc dot 
gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
But the ICE happens because the result from the function at transform time does
not match that at analysis time.

Richard?

[Bug target/94400] New: 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9

[jamborm at gcc dot gnu.org]

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

Bug ID: 94400
   Summary: 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than
GCC 9
   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: hubicka at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

When compiled with -O2 -march=native and run on an AMD Zen2 CPU,
531.deepsjeng_r runs about 7% slower.  This can be bisected to a
single commit:

commit a9a4edf0e71bbac9f1b5dcecdcf9250111d16889
Author: Jan Hubicka 
Date:   Sat Nov 30 22:25:24 2019 +0100

Update max_bb_count in execute_fixup_cfg

* tree-cfg.c (execute_fixup_cfg): Update also max_bb_count when
scaling happen.

From-SVN: r278879

Surprisingly, I cannot see a similar problem on an Intel Cascade Lake
server CPU, but I have confirmed the above on two different Rome
systems (one running SLES, one openSUSE Tumbleweed).


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 gcov-profile/94369] 505.mcf_r is 6-7% slower at -Ofast -march=native with PGO+LTO than with just LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The profile looks unconclusive, the # samples differ but evenly increase.  The
overall number of samples is missing - does that increase by 6-7%?

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

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(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.

[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[z.zhanghaijian at huawei dot com]

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

--- Comment #1 from z.zhanghaijian at huawei dot com  ---
(gdb) bt
#0  aarch64_builtin_support_vector_misalignment (mode=E_VNx4SFmode,
type=0xb79ec2a0, misalignment=-1, is_packed=false)
at ../../gcc-git/gcc/config/aarch64/aarch64.c:17510
#1  0x0220631c in vect_supportable_dr_alignment (dr_info=0x2ef3798,
check_aligned_accesses=false) at ../../gcc-git/gcc/tree-vect-data-refs.c:6618
#2  0x0162fc9c in vectorizable_load (stmt_info=0x2ef3770,
gsi=0xe0b0, vec_stmt=0xdde0, slp_node=0x0,
slp_node_instance=0x0,
cost_vec=0x0) at ../../gcc-git/gcc/tree-vect-stmts.c:9172
#3  0x01635174 in vect_transform_stmt (stmt_info=0x2ef3770,
gsi=0xe0b0, slp_node=0x0, slp_node_instance=0x0)
at ../../gcc-git/gcc/tree-vect-stmts.c:11034
#4  0x0165a340 in vect_transform_loop_stmt (loop_vinfo=0x2ed0ad0,
stmt_info=0x2ef3770, gsi=0xe0b0, seen_store=0xe0a8)
at ../../gcc-git/gcc/tree-vect-loop.c:8307
#5  0x0165b5c4 in vect_transform_loop (loop_vinfo=0x2ed0ad0,
loop_vectorized_call=0x0) at ../../gcc-git/gcc/tree-vect-loop.c:8708
#6  0x01689f08 in try_vectorize_loop_1
(simduid_to_vf_htab=@0xed68: 0x0, num_vectorized_loops=0xed7c,
loop=0xb782,
loop_vectorized_call=0x0, loop_dist_alias_call=0x0) at
../../gcc-git/gcc/tree-vectorizer.c:990
#7  0x0168a184 in try_vectorize_loop
(simduid_to_vf_htab=@0xed68: 0x0, num_vectorized_loops=0xed7c,
loop=0xb782)
at ../../gcc-git/gcc/tree-vectorizer.c:1047
#8  0x0168a330 in vectorize_loops () at
../../gcc-git/gcc/tree-vectorizer.c:1127
#9  0x014e55e4 in (anonymous namespace)::pass_vectorize::execute
(this=0x2d6f860, fun=0xb7817000) at ../../gcc-git/gcc/tree-ssa-loop.c:414
#10 0x0113dec0 in execute_one_pass (pass=0x2d6f860) at
../../gcc-git/gcc/passes.c:2502
#11 0x0113e284 in execute_pass_list_1 (pass=0x2d6f860) at
../../gcc-git/gcc/passes.c:2590
#12 0x0113e2c0 in execute_pass_list_1 (pass=0x2d6f070) at
../../gcc-git/gcc/passes.c:2591
#13 0x0113e2c0 in execute_pass_list_1 (pass=0x2d6dd00) at
../../gcc-git/gcc/passes.c:2591
#14 0x0113e32c in execute_pass_list (fn=0xb7817000, pass=0x2d6db20)
at ../../gcc-git/gcc/passes.c:2601
#15 0x00be2f50 in cgraph_node::expand (this=0xb79dc870) at
../../gcc-git/gcc/cgraphunit.c:2299
#16 0x00be3814 in expand_all_functions () at
../../gcc-git/gcc/cgraphunit.c:2470
#17 0x00be45c4 in symbol_table::compile (this=0xb79ce000) at
../../gcc-git/gcc/cgraphunit.c:2820
#18 0x00be4b14 in symbol_table::finalize_compilation_unit
(this=0xb79ce000) at ../../gcc-git/gcc/cgraphunit.c:3000
#19 0x0129f7dc in compile_file () at ../../gcc-git/gcc/toplev.c:483
#20 0x012a3a14 in do_compile () at ../../gcc-git/gcc/toplev.c:2273
#21 0x012a3de0 in toplev::main (this=0xf148, argc=21,
argv=0xf298) at ../../gcc-git/gcc/toplev.c:2412
#22 0x0224a038 in main (argc=21, argv=0xf298) at
../../gcc-git/gcc/main.c:39
(gdb) p misalignment
$3 = -1
(gdb) p mode
$4 = E_VNx4SFmode

vect_supportable_dr_alignment is expected to return either dr_aligned or
dr_unaligned_supported for masked operations. But it seems that this function
only catches internal_fn IFN_MASK_LOAD & IFN_MASK_STORE.
We are emitting a mask gather load here for this test case.  As backends have
their own vector misalignment support policy, I am supposing this should be
better handled in the auto-vect shared code.

Proposed fix by felix.y...@huawei.com:
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 0192aa6..67d3345 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -6509,11 +6509,26 @@ vect_supportable_dr_alignment (dr_vec_info *dr_info,

   /* For now assume all conditional loads/stores support unaligned
  access without any special code.  */
-  if (gcall *stmt = dyn_cast  (stmt_info->stmt))
-if (gimple_call_internal_p (stmt)
-   && (gimple_call_internal_fn (stmt) == IFN_MASK_LOAD
-   || gimple_call_internal_fn (stmt) == IFN_MASK_STORE))
-  return dr_unaligned_supported;
+  gcall *call = dyn_cast  (stmt_info->stmt);
+  if (call && gimple_call_internal_p (call))
+{
+  internal_fn ifn = gimple_call_internal_fn (call);
+  switch (ifn)
+   {
+ case IFN_MASK_LOAD:
+ case IFN_MASK_LOAD_LANES:
+ case IFN_MASK_GATHER_LOAD:
+ case IFN_MASK_STORE:
+ case IFN_MASK_STORE_LANES:
+ case IFN_MASK_SCATTER_STORE:
+   return dr_unaligned_supported;
+ default:
+   break;
+   }
+}
+
+  if (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
+return dr_unaligned_supported;

   if (loop_vinfo)
 {

[Bug c/94399] New: analyzer reports false positives for stuff freed using __attribute__((cleanup()))

[zbyszek at in dot waw.pl]

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

Bug ID: 94399
   Summary: analyzer reports false positives for stuff freed using
 __attribute__((cleanup()))
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbyszek at in dot waw.pl
  Target Milestone: ---

Created attachment 48142
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48142=edit
test program

$ rpm -q gcc
gcc-10.0.1-0.9.fc32.x86_64

$ cat testfree.c
#include 

#define _cleanup_(f) __attribute__((cleanup(f)))

static inline void freep(void **p) {
free(*p);
}

void test(void) {
_cleanup_(freep) void *ptr;

ptr = malloc(3);
}

int main(void) {
test();
return 0;
}

$ gcc -fanalyzer testfree.c -o testfree
testfree.c: In function ‘test’:
testfree.c:13:1: warning: leak of ‘ptr’ [CWE-401] [-Wanalyzer-malloc-leak]
   13 | }
  | ^
  ‘test’: events 1-4
|
|9 | void test(void) {
|  |  ^~~~
|  |  |
|  |  (1) entry to ‘test’
|   10 | _cleanup_(freep) void *ptr;
|  |~~~
|  ||
|  |(4) calling ‘freep’ from ‘test’
|   11 | 
|   12 | ptr = malloc(3);
|  | ~~~
|  | | |
|  | | (2) allocated here
|  | (3) allocated here
|
+--> ‘freep’: events 5-6
   |
   |5 | static inline void freep(void **p) {
   |  |^
   |  ||
   |  |(5) entry to ‘freep’
   |6 | free(*p);
   |  | 
   |  | |
   |  | (6) state of ‘ptr’: ‘start’ -> ‘freed’ (origin:
NULL)
   |
<--+
|
  ‘test’: events 7-8
|
|   10 | _cleanup_(freep) void *ptr;
|  |^~~
|  ||
|  |(7) returning to ‘test’ from
‘freep’
|..
|   13 | }
|  | ~   
|  | |
|  | (8) ‘ptr’ leaks here; was allocated at (3)
|



It seems that the analyzer knows that the pointer was freed (event 6), but then
still reports a leak (8).

[Bug target/94373] 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Note the cited commit simply caused more complete unrolling to happen.  Too
much actually which is why I reverted it.  Note GCC 9.2 does not have that more
unrolling so the difference must be something else in the end.

[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
volatile semantics on misaligned fields and strict-align targets cannot be
honored.  I suggest you add appropriate __attribute__((aligned(..))) if you
know the whole structure is aligned and just want fields to be tightly
packed.

[Bug target/94396] [8/9/10 Regression] fp16 feature bits not passed on to assembler from Armv8.4-a and up.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5

[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

[petro.karashchenko at gmail dot com]

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

--- Comment #6 from Petro Karashchenko  ---
Richard Biener thank you for suggestion, but __attribute__((aligned(..))) is
applied only to the base address of the struct, hence to the first field only,
so if I'm having other fields tightly packed and there are 16, 32 or 64 bit
types I will still get excess read instructions generated. In my case I'm
having uint8_t *p0, uint8_t *p1 as an inputs and can't rely that those pointers
are aligned to 16, 32 or 64, but are byte aligned.

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #10 from Christophe Lyon  ---
Hi,
This caused a regression on aarch64:
FAIL: gcc.dg/vect/pr92420.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr92420.c execution test

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Mon, 30 Mar 2020, clyon at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332
> 
> Christophe Lyon  changed:
> 
>What|Removed |Added
> 
>  CC||clyon at gcc dot gnu.org
> 
> --- Comment #10 from Christophe Lyon  ---
> Hi,
> This caused a regression on aarch64:
> FAIL: gcc.dg/vect/pr92420.c -flto -ffat-lto-objects execution test
> FAIL: gcc.dg/vect/pr92420.c execution test

Can you open a new bugreport?

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

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
> It should be sufficient to check whether they have the same DECL_CONTEXT.

This seems to work. I'm testing a patch candidate.

[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Testcase that still FAILs on the trunk:

/* PR target/94368 */
/* { dg-do compile { target fpic } } */
/* { dg-options "-fpic -O1 -fcommon" } */

int b, c, d, e, f, h;
short g;
int foo (int) __attribute__ ((__const__));

void
bar (void)
{
  while (1)
{
  while (1)
{
  __atomic_load_n (, 0);
  if (foo (2))
__sync_val_compare_and_swap (, 0, f);
  b = 1;
  if (h == e)
break;
}
  __sync_val_compare_and_swap (, -1, f);
}
}

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

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
(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.

[Bug target/94373] 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune

[crazylht at gmail dot com]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> I think
> Change lea_cost from 2 --> 1 in skylake can fix this regressions.
> 
> Since it's stage4 now, i hold my patch.

Classify: it's for -O2 -mtune=skylake-avx512

not sure the what cause the regression for -O2 -mtune=generic.

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

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
If I remember correctly kernel implements its own "runtime library" libgcov, so
I would expect a crash somewhere in it. Anyway, a reasonable reproducer would
be needed.

[Bug fortran/94348] gfortran 8/9 reject module procedure definition in same module as function interface

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Tobias Burnus
:

https://gcc.gnu.org/g:79166bd28d0296a510cc65aa21cd6797eba51144

commit r9-8423-g79166bd28d0296a510cc65aa21cd6797eba51144
Author: Tobias Burnus 
Date:   Mon Mar 30 09:23:12 2020 +0200

[Fortran] Fix result-variable handling of MODULE PROCEDURE (PR94348)

Backport from mainline
2020-03-28  Tobias Burnus  

PR fortran/94348
* decl.c (gfc_match_submod_proc): Add result var to the
proc's namespace.

PR fortran/94348
* gfortran.dg/module_procedure_3.f90: New.

[Bug fortran/94348] gfortran 8/9 reject module procedure definition in same module as function interface

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org

--- Comment #5 from Tobias Burnus  ---
FIXED for GCC 10 alias mainline + GCC 9.

Thanks for the report.

[Bug c++/93597] [9 Regression] ICE in get_fns since r10-6219

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
Summary|[10 Regression] ICE in  |[9 Regression] ICE in
   |get_fns since r10-6219  |get_fns since r10-6219
   Target Milestone|10.0|9.4

--- Comment #4 from Richard Biener  ---
r10-6219-g8b91e848130e45b427599ad30e99f96e447ea9aa was backported and now this
fails on the branch as well.  (in future make sure to add appropriate Blocks)

[Bug tree-optimization/93946] Bogus redundant store removal

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
(In reply to sandra from comment #13)
> Well, no.  The problem is that the scheduler is moving 
> 
> ldw r2, 0(r4)
> 
> ahead of
> 
> stw zero, 0(r5)
> 
> which is incorrect because the pointers in r4 and r5 are aliases.

Ah, so the scheduler needs to call anti_dependence (WAR).

> So at the point of call to true_dependence, I see:
> 
> (gdb) frame 1
> #1  0x01d1a108 in sched_analyze_2 (deps=0x7fffdd50, 
> x=0x7742cac8, insn=0x77315600)
> at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/sched-deps.c:2663
> 2663if (true_dependence (pending_mem->element (),
> VOIDmode, t)
> (gdb) print debug_rtx(insn)
> (insn 17 10 18 2 (set (reg/i:SI 2 r2)
> (mem/j:SI (reg/v/f:SI 4 r4 [orig:47 bv ] [47]) [1 bv_3(D)->b.u.f+0
> S4 A32]))
> "/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/torture/
> pr93946-1.c":18:1 5 {movsi_internal}
>  (expr_list:REG_DEAD (reg/v/f:SI 4 r4 [orig:47 bv ] [47])
> (nil)))
> $3 = void
> (gdb) print debug_rtx(pending->insn())
> (insn 9 8 10 2 (set (mem/j:SI (reg/v/f:SI 5 r5 [orig:48 ptr ] [48]) [1
> MEM[(struct aa *)ptr_1(D)].a.u.i+0 S4 A32])
> (const_int 0 [0]))
> "/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/torture/
> pr93946-1.c":15:12 5 {movsi_internal}
>  (nil))
> $4 = void

[Bug fortran/94397] New: [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error.

[chinoune.mehdi at hotmail dot com]

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

Bug ID: 94397
   Summary: [10 Regression] the compiler consider "type is(
real(kind(1.)) )" as a syntax error.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chinoune.mehdi at hotmail dot com
  Target Milestone: ---

Failed to build https://github.com/Goddard-Fortran-Ecosystem/pFUnit (which I
successfully built last Monday 23-03-2020) this morning with gcc-git.
This is the reduced code:

$ cat type_is.f90
module m
  implicit none
contains
  subroutine sub(a)
class(*) :: a
select type(a)
  type is ( real( kind(1.) ) )
a = 1.
end select
  end subroutine sub
end module m

$ gfortran-10 -c type_is.f90
type_is.f90:7:32:

7 |   type is ( real( kind(1.) ) )
  |1
Error: Syntax error in TYPE IS specification at (1)
type_is.f90:8:14:

8 | a = 1.
  |  1
Error: Expected TYPE IS, CLASS IS or END SELECT statement following SELECT TYPE
at (1)

$gfortran-10 --version
GNU Fortran (GCC) 10.0.1 20200330 (experimental)

[Bug target/94396] New: [8/9/10 Regression] fp16 feature bits not passed on to assembler from Armv8.4-a and up.

[tnfchris at gcc dot gnu.org]

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

Bug ID: 94396
   Summary: [8/9/10 Regression] fp16 feature bits not passed on to
assembler from Armv8.4-a and up.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: tnfchris at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*

At Arm8.2-a using `+fp16fml` enables both `+fp` and `+fp16` as such the
smallest canonical option to use is `armv8.2-a+fp16fml`.

For `Armv8.4-a` and up `+fp16fml` is mandatory if `+fp16` but optional
otherwise. This requirement confuses the canonization.

This confusion makes `armv8.4-a+fp16` canonicalize to `armv8.4-a` which is
incorrect and so it's impossible to use `fp16` and `fp16fml` at `armv8.4-a` and
higher.

[Bug tree-optimization/94356] Missed optimisation: useless multiplication generated for pointer comparison

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I also remember tackling this in pointer_int_sum at some point (also with mixed
results).  Keep in mind the sizetype requirement for POINTER_PLUS_EXPR which
IMHO should change to either ssizetype or [s]sizetype - Bin tried the change
to ssizetype with again mixed results ;)

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

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
The defaults are OK (either native or cross aarch64)

[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.

[Bug tree-optimization/94401] 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

   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin  ---
Thanks for reporting this! Do I need some special arch configuration options
for the gcc build to reproduce this on some aarch machine in CFarm? or fine
with default?

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

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
It only fails on systems with the libmvec enablement and vectorizes one more
loop.  Not sure how to "fix" the testcase (split out the offending function,
add some dg-target looking for libmvec enablement?)?

[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 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 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 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 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/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 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/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 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

[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 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 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/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 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/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 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 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%.