[Bug d/94496] [D] Use aggressive optimizations in release mode

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
(In reply to Witold Baryluk from comment #1)
> We are close to making 'in' mean 'scope const', it is already available as a
> preview in dmd 2.092: https://dlang.org/changelog/2.092.0.html#preview-in

Indeed, the new @live attribute should also allow strict aliasing rules to be
turned on for them as well.

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Confirmed with current trunk.

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Jim Wilson from comment #3)
> The assumption here seems to be that if the user is
> dividing constants, then we don't need to worry about setting exception
> bits.  If I write (4.0 / 3.0) for instance, the compiler just folds it and
> doesn't worry about setting the inexact bit.

We don't fold 0./0. though (unless -fno-trapping-math), it would make sense for
Inf/Inf to behave the same. And -frounding-math protects 4./3.

> divide gets moved after the fetestexcept call.  That looks like a gcc bug

Yes, that one is known.

[Bug bootstrap/95122] New: Cross-compile arm32 toolchain with hard float, but Error in gcc final

[chengcongxiu at huawei dot com]

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

Bug ID: 95122
   Summary: Cross-compile arm32 toolchain with hard float, but
Error in gcc final
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengcongxiu at huawei dot com
  Target Milestone: ---

Created attachment 48531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48531=edit
Cross-compile arm32 toolchain with hard float, but Error in gcc final

Details of cross toolchain：

TARGET="arm-linux-gnueabihf"
HOST="$(gcc -dumpmachine)"
BUILD="$(gcc -dumpmachine)"

1、 GCC FIRST: 
CFLAGS_FOR_TARGET="${-march=armv7-a -mhard-float}"
CXXFLAGS_FOR_TARGET="${-march=armv7-a -mhardfloat}" ./configure --build=$BUILD
--host=$HOST --target=$TARGET --without-headers --with-newlib
make -j 16 && make install

this step is OK

2、GLIBC HEADER 
CC="arm-linux-gnueabihf-gcc -mhard-float"
$ROOT_TAR_SRC/$EGLIBC/configure --with-float=hard --with-fp

this step is OK

3、GCC SECOND
CFLAGS_FOR_TARGET="${-march=armv7-a -mhard-float}"
CXXFLAGS_FOR_TARGET="${-march=armv7-a -mhardfloat}" --enable-shared

this step is OK

4、GLIBC 
CC="arm-linux-gnueabihf-gcc -mhard-float"
$ROOT_TAR_SRC/$EGLIBC/configure --with-float=hard --with-fp 

this step is OK

5、GCC Final
CFLAGS_FOR_TARGET="${-march=armv7-a -mhard-float}"
CXXFLAGS_FOR_TARGET="${-march=armv7-a -mhardfloat}" --enable-shared 

compier error：the error is checking libgcc terminated。 the checking log at
File， the reason is stubs.h， but I add the option -mhard-float. How I solve
this Error?


/home/ccx/fenghuo/SDK_CPU_HCC/build/hcc_arm32le/arm32le_build_dir/hcc_arm32le/arm-linux-gnueabihf/sys-include/gnu/stubs.h:7:29:
fatal error: gnu/stubs-soft.h: No such file or directory
 # include 
 ^
compilation terminated.

Re: how to find variable related to a virtual ssa name

[易会战 via Gcc]

There are some other cases that I cannot get right answer.
case1: interproceduure
func(int*arg)
{
return arg[0] + arg[1]
}
func2()
{
int a[10]
return func(a);
}
here func cannot tell arg is local var.


case 2: global array point to local
int *array[3]
int func(int x)
{
int sub1[10];
int sub2[10];
int sub3[10];
array[0] = sub1;
array[1]=sub2;
array[2]=sub3;
then refer to array by array[x][y]
}
here i refer to local var, but the points-to cannnot give right answer.


I do not know if this is the points-to analysis problem, or improper use it.

---Original---
From: "Richard Biener"

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #3 from Jim Wilson  ---
Marc Glisse's testcase fails even with old gcc versions.  My x86_64 Ubuntu
16.04 gcc-5.4.0 also removes the divide with -O.  My Ubuntu 18.04 gcc-7.5.0
gives the same result.  This seems to be simple constant folding that we have
always done.  The assumption here seems to be that if the user is dividing
constants, then we don't need to worry about setting exception bits.  If I
write (4.0 / 3.0) for instance, the compiler just folds it and doesn't worry
about setting the inexact bit.

Aurelien Jarno's testcase in the attachment is more interesting, as that works
with older gcc versions, just not gcc-10.  I did a bisect, and tracked this
down to the Richard Biener's patch for pr83518.  It looks like the glibc code
was obfuscated a bit to try to avoid the usual trivial constant folding, and
the patch for pr83518 just made gcc smart enough to recognize that constants
are involved, and then optimize this case the same way we have always optimized
FP constant divides.

Newlib incidentally uses (x-x)/(x-x) where x is the input value, so there are
no constants involved, and the divide does not get optimized away.  This still
works with gcc-10.  The result is a subtract followed by a divide.

At first glance, this looks more like a glibc problem to me than a gcc problem.
 But maybe the fact that constants were written to memory and then read back in
should prevent the usual trivial FP constant divide folding.

I can almost make the glibc testcase work if I mark the unions as volatile. 
That prevents the union reads and writes from being optimized away, but the
divide gets moved after the fetestexcept call.  That looks like a gcc bug
though I think a different problem that this pr.  The 234t.optimized dump is
correct.  The 236r.expand dump is wrong.  This happens for both x86_64 and
RISC-V.  The resulting code is bigger than what the newlib trick generates
though.

Re: [PATCH v2] Fold (add -1; zero_ext; add +1) operations to zero_ext when not overflow (PR37451, part of PR61837)

[luoxhu via Gcc-patches]

On 2020/5/13 02:24, Richard Sandiford wrote:
> luoxhu  writes:
>> +  /* Fold (add -1; zero_ext; add +1) operations to zero_ext. i.e:
>> +
>> + 73: r145:SI=r123:DI#0-0x1
>> + 74: r144:DI=zero_extend (r145:SI)
>> + 75: r143:DI=r144:DI+0x1
>> + ...
>> + 31: r135:CC=cmp (r123:DI,0)
>> + 72: {pc={(r143:DI!=0x1)?L70:pc};r143:DI=r143:DI-0x1;clobber
>> + scratch;clobber scratch;}
> 
> Minor, but it might be worth stubbing out the clobbers, since they're
> not really necessary to understand the comment:
> 
>72: {pc={(r143:DI!=0x1)?L70:pc};r143:DI=r143:DI-0x1;...}
> 
>> +
>> + r123:DI#0-0x1 is param count derived from loop->niter_expr equal to the
>> + loop iterations, if loop iterations expression doesn't overflow, then
>> + (zero_extend (r123:DI#0-1))+1 could be simplified to zero_extend only.
>> +   */
>> +  bool simplify_zext = false;
> 
> I think it'd be easier to follow if this was split out into
> a subroutine, rather than having the simplify_zext variable.
> 
>> +  rtx extop0 = XEXP (count, 0);
>> +  if (GET_CODE (count) == ZERO_EXTEND && GET_CODE (extop0) == PLUS)
> 
> This isn't valid: we can only do XEXP (count, 0) *after* checking
> for a ZERO_EXTEND.  (It'd be good to test the patch with
> --enable-checking=yes,extra,rtl , which hopefully would have
> caught this.)
> 
>> +{
>> +  rtx addop0 = XEXP (extop0, 0);
>> +  rtx addop1 = XEXP (extop0, 1);
>> +
>> +  int nonoverflow = 0;
>> +  unsigned int_mode
>> += GET_MODE_PRECISION (as_a GET_MODE (addop0));
> 
> Heh.  I wondered at first how on earth this compiled.  It looked like
> there was a missing "(...)" around the GET_MODE.  But of course,
> GET_MODE adds its own parentheses, so it all works out. :-)
> 
> Please add the "(...)" anyway though.  We shouldn't rely on that.
> 
> "int_mode" seems a bit of a confusing name, since it's actually a precision
> in bits rather than a mode.
> 
>> +  unsigned HOST_WIDE_INT int_mode_max
>> += (HOST_WIDE_INT_1U << (int_mode - 1) << 1) - 1;
>> +  if (get_max_loop_iterations (loop, )
>> +  && wi::ltu_p (iterations, int_mode_max))
> 
> You could use GET_MODE_MASK instead of int_mode_max here.
> 
> For extra safety, it would be good to add a HWI_COMPUTABLE_P test,
> to make sure that using HWIs is valid.
> 
>> +nonoverflow = 1;
>> +
>> +  if (nonoverflow
> 
> Having the nonoverflow variable doesn't seem necessary.  We could
> just fuse the two "if" conditions together.
> 
>> +  && CONST_SCALAR_INT_P (addop1)
>> +  && GET_MODE_PRECISION (mode) == int_mode * 2
> 
> This GET_MODE_PRECISION condition also shouldn't be necessary.
> If we can prove that the subtraction doesn't wrap, we can extend
> to any wider mode, not just to double the width.
> 
>> +  && addop1 == GEN_INT (-1))
> 
> This can just be:
> 
> addop1 == constm1_rtx
> 
> There's then no need for the CONST_SCALAR_INT_P check.
> 
> Thanks,
> Richard
> 

Thanks for all your great comments, addressed them all with below update,
"--enable-checking=yes,extra,rtl" did catch the ICE with performance penalty.


This "subtract/extend/add" existed for a long time and still annoying us
(PR37451, part of PR61837) when converting from 32bits to 64bits, as the ctr
register is used as 64bits on powerpc64, Andraw Pinski had a patch but
caused some issue and reverted by Joseph S. Myers(PR37451, PR37782).

Andraw:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01070.html
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01321.html
Joseph:
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg02405.html

We still can do the simplification from "subtract/zero_ext/add" to "zero_ext"
when loop iterations is known to be LT than MODE_MAX (only do simplify
when counter+0x1 NOT overflow).

Bootstrap and regression tested pass on Power8-LE.

gcc/ChangeLog

2020-05-14  Xiong Hu Luo  

PR rtl-optimization/37451, part of PR target/61837
* loop-doloop.c (doloop_simplify_count): New function.  Simplify
(add -1; zero_ext; add +1) to zero_ext when not wrapping.
(doloop_modify): Call doloop_simplify_count.

gcc/testsuite/ChangeLog

2020-05-14  Xiong Hu Luo  

PR rtl-optimization/37451, part of PR target/61837
* gcc.target/powerpc/doloop-2.c: New test.
---
 gcc/loop-doloop.c   | 38 -
 gcc/testsuite/gcc.target/powerpc/doloop-2.c | 29 
 2 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/doloop-2.c

diff --git a/gcc/loop-doloop.c b/gcc/loop-doloop.c
index db6a014e43d..02282d45bd5 100644
--- a/gcc/loop-doloop.c
+++ b/gcc/loop-doloop.c
@@ -397,6 +397,42 @@ add_test (rtx cond, edge *e, basic_block dest)
   return true;
 }
 
+/* Fold (add -1; zero_ext; add +1) operations to zero_ext if not wrapping. i.e:
+
+   73: r145:SI=r123:DI#0-0x1
+   74: r144:DI=zero_extend (r145:SI)
+   75: 

[Bug inline-asm/95121] Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Joseph C. Sible from comment #3)
> Also, is that documented to work that way anywhere? I didn't notice anything
> in the manual to that effect.

Register names seems not to be documented, correct.

[Bug inline-asm/95121] Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Joseph C. Sible from comment #2)
> Does this mean that Clang is wrong, then? Because it works the way I
> wanted/expected.

Depends, this is a GNU extension.

Re: [PATCH PR94969]Add unit distant vector to DDR in case of invariant access functions

[Bin.Cheng via Gcc-patches]

On Thu, May 14, 2020 at 1:46 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> On Wed, May 13, 2020 at 02:00:11PM +0200, Christophe Lyon via Gcc-patches 
> wrote:
> > > > 2020-05-11  Bin Cheng  
> > > >
> > > > PR tree-optimization/94969
> > > > * gcc.dg/tree-ssa/pr94969.c: New test.
> >
> > The new test fails on arm and aarch64 and probably everywhere:
> > gcc.dg/tree-ssa/pr94969.c: dump file does not exist
> > UNRESOLVED: gcc.dg/tree-ssa/pr94969.c scan-tree-dump-not Loop 1
> > distributed: split to 3 loops "ldist"
> >
> > Can you fix this?
>
> Seems a mere swapping of the scan-tree-dump-not args, I've verified the
> test passes after this change and fails with older trunk, committed to trunk
> as obvious.
Oh, sorry for the breakage, and thanks for fixing this.

Thanks,
bin
>
> 2020-05-13  Jakub Jelinek  
>
> PR testsuite/95110
> * gcc.dg/tree-ssa/pr94969.c: Swap scan-tree-dump-not arguments.
>
> --- gcc/testsuite/gcc.dg/tree-ssa/pr94969.c.jj  2020-05-13 09:24:36.959012780 
> +0200
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr94969.c 2020-05-13 19:13:53.664499322 
> +0200
> @@ -25,4 +25,4 @@ int main()
>  __builtin_abort ();
>  }
>
> -/* { dg-final { scan-tree-dump-not "ldist" "Loop 1 distributed: split to 3 
> loops"} } */
> +/* { dg-final { scan-tree-dump-not "Loop 1 distributed: split to 3 loops" 
> "ldist" } } */
>
> Jakub
>

[Bug inline-asm/95121] Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

[josephcsible at gmail dot com]

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

--- Comment #3 from Joseph C. Sible  ---
Also, is that documented to work that way anywhere? I didn't notice anything in
the manual to that effect.

[Bug inline-asm/95121] Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

[josephcsible at gmail dot com]

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

--- Comment #2 from Joseph C. Sible  ---
Does this mean that Clang is wrong, then? Because it works the way I
wanted/expected.

[Bug inline-asm/95121] Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
register char x __asm__("dh");

Is the same as:
register char x __asm__("di");

dh and dl are the same register really but the high are low parts can be
modified seperately via some of the 8bit instructions.

Re: how to find variable related to a virtual ssa name

[易会战 via Gcc]

Thanks, I patch a version, it can give a heap variable info.
Now the curious is the patch version cannot give right answer for variable 
length array. for example，
int func(int m, int n)
{
int array[m][n];
...
}
here array is allocated by alloca, obviously a local variable.
But the original version can check it a local variable.

---Original---
From: "Richard Biener"

[Bug inline-asm/95121] New: Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

[josephcsible at gmail dot com]

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

Bug ID: 95121
   Summary: Wrong code generated: low-byte registers are silently
used in place of their corresponding high-byte
registers (ah, bh, ch, dh)
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josephcsible at gmail dot com
  Target Milestone: ---

Consider this function:

char f(void) {
register char x __asm__("dh");
__asm__("movb $42, %%dh" : "=r"(x));
return x;
}

It's supposed to return 42, but it actually returns whatever happened to be in
dl. In general, any time you use a high-byte register for input or output to
inline assembly, GCC will instead erroneously use the corresponding low-byte
register in its place. I tested this with -m32 and -m64, with -O0 through -O3,
and with "=d" and "=Q" as constraints in place of "=r", and it occurred in
every combination I tried. I can reproduce it locally with the gcc:10.1.0
Docker image as well as on Godbolt.

[Bug d/95120] [D] Incorrectly allows fqdn access to imported symbols when doing selective imports.

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #2 from Witold Baryluk  ---
Created attachment 48530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48530=edit
Minimized example

[Bug d/95120] [D] Incorrectly allows fqdn access to imported symbols when doing selective imports.

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #1 from Witold Baryluk  ---
Further minimized:

==
import std.stdio;
import std.algorithm.comparison : min;

int main() {
  return std.algorithm.comparison.min(3, 2);
}
==


Removing `import std.stdio;`, results in the same error messages in gdc-10, dmd
and ldc2.

$ gdc badimport.d
badimport.d:5:10: error: undefined identifier ‘std’
5 |   return std.algorithm.comparison.min(3, 2);
  |  ^
$
$ ldc2 badimport.d
badimport.d(5): Error: undefined identifier std
$ dmd badimport.d
badimport.d(5): Error: undefined identifier std
$


it complains about `unknown std`.

When I use `import std.stdio;` at the start, dmd and ldc complain about
`unknown algorithm in package std`.

Not sure if this is something in `std.stdio` package maybe.

[Bug tree-optimization/95118] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang

[admnd at protonmail dot com]

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

--- Comment #4 from Adrien Dessemond  ---
The hang also happens with "-O2 -ftree-vectorize -fopt-info-vec" 
I confirm that removing "-fopt-info-vec" avoids the hang.

[Bug d/95120] New: [D] Incorrectly allows fqdn access to imported symbols when doing selective imports.

[witold.baryluk+gcc at gmail dot com]

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

Bug ID: 95120
   Summary: [D] Incorrectly allows fqdn access to imported symbols
when doing selective imports.
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: witold.baryluk+gcc at gmail dot com
  Target Milestone: ---

Created attachment 48529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48529=edit
Example of incorrectly accepted d source by gdc-10

gdc does violatate D language spec:

https://dlang.org/spec/module.html#selective_imports


4.7 Selective Imports

Specific symbols can be exclusively imported from a module and bound into the
current namespace:

import std.stdio : writeln, foo = write;

void main()
{
std.stdio.writeln("hello!"); // error, std is undefined
writeln("hello!");   // ok, writeln bound into current namespace
write("world");  // error, write is undefined
foo("world");// ok, calls std.stdio.write()
fwritefln(stdout, "abc");// error, fwritefln undefined
}
=


I found that in some weird situations the gdc-10 does behave differently
than dmd and ldc2.

Here are the versions I used:

$ dmd --version
DMD64 D Compiler v2.092.0
Copyright (C) 1999-2020 by The D Language Foundation, All Rights Reserved
written by Walter Bright
$ ldc2 --version
LDC - the LLVM D compiler (1.20.1):
  based on DMD v2.090.1 and LLVM 9.0.1
  built with LDC - the LLVM D compiler (1.20.1)
  Default target: x86_64-pc-linux-gnu
  Host CPU: znver1
$ gdc-10 --version
gdc-10 (Debian 10.1.0-1) 10.1.0
$


All on Debian testing/unstable, amd64.

 badimport.d =
void main() {
  import std.stdio;
  import std.algorithm.comparison : min;

  static struct S {
int min_;

// int min() { return min_; }

void opOpAssign(string op)(const S other) if (op == "+") {
  min_ = std.algorithm.comparison.min(min_, other.min_);
}
  }

  S x = {3};
  x += x;
}
=

(the intention was to use fqdn here, to not reference struct member function
min; using `.min(min_, other.min_)`, is another option, but it actually
shouldn't work either, due to other reasons).

Anyway:

$ gdc-10 badimport.d   # Compiles.
$


$ ldc2 badimport.d # Correct error.
badimport.d(11): Error: undefined identifier algorithm in package std, perhaps
add static import std.algorithm;
badimport.d(16): Error: template instance badimport.main.S.opOpAssign!"+" error
instantiating
$

$ dmd badimport.d  # Correct error.
badimport.d(11): Error: undefined identifier algorithm in package std, perhaps
add static import std.algorithm;
badimport.d(16): Error: template instance badimport.main.S.opOpAssign!"+" error
instantiating
$


Produced code by gdc-10 does work correctly. However, it shouldn't compile at
all.

>From what I can see, it is some kind of interaction with preceding imports,
that is the `import std.stdio;`. Removing `import std.stdio;` makes gdc-10
correctly report the error and stop compilation.

The test case can be further minimizes, and it attached to the bug.

Same behaviour:

==
import std.stdio;
import std.algorithm.comparison : min;

struct S {
  int min_;
  void add(const S other) {
min_ = std.algorithm.comparison.min(min_, other.min_);
  }
}

void main() {
  S x = {3};
  x.add(x);
}
==

[Bug d/94496] [D] Use aggressive optimizations in release mode

[witold.baryluk+gcc at gmail dot com]

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

Witold Baryluk  changed:

   What|Removed |Added

 CC||witold.baryluk+gcc at gmail 
dot co
   ||m

--- Comment #1 from Witold Baryluk  ---
We are close to making 'in' mean 'scope const', it is already available as a
preview in dmd 2.092: https://dlang.org/changelog/2.092.0.html#preview-in

Re: [PATCH] RISC-V: Make unique SECCAT_SRODATA names start with .srodata

[Palmer Dabbelt]

On Tue, 12 May 2020 16:53:14 PDT (-0700), Jim Wilson wrote:

This fixes a bug reported to the RISC-V sw-dev mailing list late last year.
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/JV5Jdh4UjVw

Keith Packard wote the obvious patch to fix it.  I tested it with cross builds
for riscv32-newlib and riscv64-linux.  There were no regressions.  Checking
toolchain libraries with objdump shows that there are no longer sdata2 sections
in the libraries.

Committed.


Thanks!



Jim

2020-05-12  Keith Packard  
* config/riscv/riscv.c (riscv_unique_section): New.
(TARGET_ASM_UNIQUE_SECTION): New.

default_unique_section uses ".sdata2" as a prefix for SECCAT_SRODATA
unique sections, but RISC-V uses ".srodata" instead. Override the
TARGET_ASM_UNIQUE_SECTION function to catch this case, allowing the
default to be used for all other sections.

Signed-off-by: Keith Packard 
---
 gcc/config/riscv/riscv.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index e4c08d780db..1ad9799fce4 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -3492,6 +3492,43 @@ riscv_select_section (tree decl, int reloc,
 }
 }

+/* Switch to the appropriate section for output of DECL.  */
+
+static void
+riscv_unique_section (tree decl, int reloc)
+{
+  const char *prefix = NULL;
+  bool one_only = DECL_ONE_ONLY (decl) && !HAVE_COMDAT_GROUP;
+
+  switch (categorize_decl_for_section (decl, reloc))
+{
+case SECCAT_SRODATA:
+  prefix = one_only ? ".sr" : ".srodata";
+  break;
+
+default:
+  break;
+}
+  if (prefix)
+{
+  const char *name, *linkonce;
+  char *string;
+
+  name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
+  name = targetm.strip_name_encoding (name);
+
+  /* If we're using one_only, then there needs to be a .gnu.linkonce
+prefix to the section name.  */
+  linkonce = one_only ? ".gnu.linkonce" : "";
+
+  string = ACONCAT ((linkonce, prefix, ".", name, NULL));
+
+  set_decl_section_name (decl, string);
+  return;
+}
+  default_unique_section (decl, reloc);
+}
+
 /* Return a section for X, handling small data. */

 static section *
@@ -5254,6 +5291,9 @@ riscv_new_address_profitable_p (rtx memref, rtx_insn 
*insn, rtx new_addr)
 #undef TARGET_ASM_SELECT_SECTION
 #define TARGET_ASM_SELECT_SECTION riscv_select_section

+#undef TARGET_ASM_UNIQUE_SECTION
+#define TARGET_ASM_UNIQUE_SECTION riscv_unique_section
+
 #undef TARGET_ASM_SELECT_RTX_SECTION
 #define TARGET_ASM_SELECT_RTX_SECTION  riscv_elf_select_rtx_section

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Wed, 13 May 2020, Rainer Orth wrote:

> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
> 
> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
> indefinitely until one manually kills them.

 Would you mind sharing a reference such as a DejaGNU Git commit ID of the 
fix for the bug you mean?

 Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
very week I have been chasing a phenomenon with Expect's `wait' semantics 
causing a reliable hang in remote testing if `ssh' to the target board 
stops responding for whatever reason.  I have come up with a solution 
(that I'd be happy to upstream, except that DejaGNU maintenance seems to 
have been dead for like a year now), which I have also confirmed to be 
required with current DejaGNU Git master so it must be a different one, 
and I would like to know how it might be related to the bug you mention.

  Maciej

[Bug tree-optimization/95118] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Sergei Trofimovich  ---
Bisect points to an old revision. Might be a coincidence?

38988cbf9ebaa96fb1e891a46aa063f0c298a2e2 is the first bad commit
commit 38988cbf9ebaa96fb1e891a46aa063f0c298a2e2
Author: Richard Biener 
Date:   Mon Jul 8 07:09:24 2019 +

re PR tree-optimization/83518 (Missing optimization: useless instructions
should be dropped)

2019-07-08  Richard Biener  

PR tree-optimization/83518
* tree-ssa-sccvn.c: Include splay-tree.h.
(struct pd_range, struct pd_data): New.
(struct vn_walk_cb_data): Add data to track partial definitions.
(vn_walk_cb_data::~vn_walk_cb_data): New.
(vn_walk_cb_data::push_partial_def): New.
(pd_tree_alloc, pd_tree_dealloc, pd_range_compare): New.
(vn_reference_lookup_2): When partial defs are registered give up.
(vn_reference_lookup_3): Track partial defs for memset and
constructor zeroing and for defs from constants.

* gcc.dg/tree-ssa/ssa-fre-73.c: New testcase.
* gcc.dg/tree-ssa/ssa-fre-74.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-75.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-76.c: Likewise.
* g++.dg/tree-ssa/pr83518.C: Likewise.

From-SVN: r273194

 gcc/ChangeLog  |  13 +
 gcc/testsuite/ChangeLog|   9 +
 gcc/testsuite/g++.dg/tree-ssa/pr83518.C|  27 ++
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-73.c |  14 ++
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-74.c |  16 ++
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-75.c |  34 +++
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-76.c |  16 ++
 gcc/tree-ssa-sccvn.c   | 389 +
 8 files changed, 469 insertions(+), 49 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr83518.C
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-73.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-74.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-75.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-76.c

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[longb at cray dot com]

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

--- Comment #1 from Bill Long  ---
Appears to be a regression. 

The original submitter thinks it is hanging in  __lll_lock_wait inside CLOSE. 

Th same hang can be observed if the references to omp_get_num_threads are
removed, but you still compile with -fopenmp (even though there is no openmp in
the code).  Appears to be related to linking with -lpthreads.

[Bug fortran/95119] New: CLOSE hangs when -fopenmp is specified in compilation

[longb at cray dot com]

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

Bug ID: 95119
   Summary: CLOSE hangs when -fopenmp is specified in compilation
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test3.f90
program test
  integer,external :: omp_get_num_threads
  character(len=16) my_status
  open (unit=10, file='test.dat')
  print *, omp_get_num_threads()
  write (10, *) 'weird'
  rewind (10)
  read (10, *) my_status
  close (10)
  open (unit=10, file='test.dat')
  close (unit=10, status=my_status, iostat=ios)
  print *, ios
  close (10, status='delete')
  end program test

Works fine with gfortran 8.3.0:

> gfortran -fopenmp test3.f90
> ./a.out
   1
5002
>


Hangs with gfortran 9.3.0:

> gfortran -fopenmp test3.f90
> ./a.out
   1
5002
^C
> module avail gcc

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[seurer at linux dot vnet.ibm.com]

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

--- Comment #19 from Bill Seurer  ---
There's some stuff above this in the module but this is the part that shows the
error and I think it contains all the declarations.

subroutine Z()
   real(r8) :: cld(99,99)
   real(r8) cldeps
   parameter (cldeps = 0.0_r8)
   real(r8) asort(99)
   if (cldeps > 0) then
  asort(1) = 1.0_r8-(floor(cld(1,7)/cldeps)*cldeps)
   endif
   return
end subroutine Z

   15 |   asort(1) = 1.0_r8-(floor(cld(1,7)/cldeps)*cldeps)
  |  1
Error: Division by zero at (1)

[Bug tree-optimization/95118] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang

[slyfox at inbox dot ru]

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

--- Comment #2 from Sergei Trofimovich  ---
Seems to be a regression since gcc-9.3.0.

[Bug tree-optimization/95118] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 48528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48528=edit
bug.c

[Bug tree-optimization/95118] New: gcc-10 and master -O3 -fopt-info-vec causes gcc to hang

[slyfox at inbox dot ru]

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

Bug ID: 95118
   Summary: gcc-10 and master -O3 -fopt-info-vec causes gcc to
hang
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

The bug originally reported by Adrien Dessemond as
https://bugs.gentoo.org/722774 where gzip-1.10's ./configure CFLAGS="-O3 -pipe
-march=native -fomit-frame-pointer -fopt-info-vec -mindirect-branch=thunk
-mindirect-branch-register" makes gcc hang.

Minimal reproducer against gcc-10.1.0 anf gcc-master is:

  // $ cat bug.c
  void a();
  void b() {
union {
  int c[4];
  long double d;
} e = {{0, 0, 4}};
a(e.d);
  }

$ /usr/bin/x86_64-pc-linux-gnu-gcc-10.1.0 -o conftest -O3 -fopt-info-vec -c
bug.c


Reproducible on the following gcc config against master:

Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200513 (experimental) (GCC)

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[seurer at linux dot vnet.ibm.com]

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

--- Comment #18 from Bill Seurer  ---
I am still cutting down the code but this should answer the question about if
it really could be zero:


  if (cldeps > 0) then
 do k = k1,k2
   asort(nxs) = 1.0_r8-(floor(cld(i,k)/cldeps)*cldeps)
. . .
 5911 |asort(nxs) =
1.0_r8-(floor(cld(i,k)/cldeps)*cldeps)
  | 1
Error: Division by zero at (1)

[Bug fortran/81827] Large compile time with derived-type rrays

[robison at arlut dot utexas.edu]

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

Luke Robison  changed:

   What|Removed |Added

 CC||robison at arlut dot utexas.edu

--- Comment #25 from Luke Robison  ---
gcc 10.1 has been released, and still exhibits exponentially increasing compile
time for these test cases.

Paul, could you describe what you had in mind, and perhaps give some pointers
to someone who hasn't modified gcc before to point them in the right direction?

Luke

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Or during CCP with the simpler

double f(){
  double d=__builtin_inf();
  return d/d;
}

and all the -frounding-math -ftrapping-math -fsignaling-nans don't seem to
help.

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
I am seeing the same thing on x86_64, happens during FRE1, so it looks like
tree-optimization.

Re: [PATCH] [V2] rs6000: Add vec_extracth and vec_extractl

[Segher Boessenkool]

Hi!

On Wed, May 13, 2020 at 07:50:50AM -0500, Bill Schmidt wrote:
> From: Kelvin Nilsen 
> 
> Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
> vextddvhx, along with built-in access and overloaded built-in
> access to these insns.
> 
> Changes from previous patch:
>  * Removed the int iterators
>  * Created separate expansions and insns
> vextractl
> vextractl_internal
> vextractr
> vextractr_internal
>  * Adjusted rs6000-builtin.def entries to match the new expansion
>names
> 
> I didn't understand the comment about moving the decision making
> part to the built-in handling code.  All the built-in handling
> does is a table-driven call to the expansions; this logic *is*
> the built-in handling code.  I don't see any way to simplify that.

I'll try it myself :-)

> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions, using a Power9 configuration.  Is this okay for
> master?

This is okay for trunk.  Thanks!


Segher


> 2020-05-12  Kelvin Nilsen  
> 
>   * config/rs6000/altivec.h (vec_extractl): New #define.
>   (vec_extracth): Likewise.
>   * config/rs6000/altivec.md (UNSPEC_EXTRACTL): New constant.
>   (UNSPEC_EXTRACTR): Likewise.
>   (vextractl): New expansion.
>   (vextractl_internal): New insn.
>   (vextractr): New expansion.
>   (vextractr_internal): New insn.
>   * config/rs6000/rs6000-builtin.def (__builtin_altivec_vextdubvlx):
>   New built-in function.
>   (__builtin_altivec_vextduhvlx): Likewise.
>   (__builtin_altivec_vextduwvlx): Likewise.
>   (__builtin_altivec_vextddvlx): Likewise.
>   (__builtin_altivec_vextdubvhx): Likewise.
>   (__builtin_altivec_vextduhvhx): Likewise.
>   (__builtin_altivec_vextduwvhx): Likewise.
>   (__builtin_altivec_vextddvhx): Likewise.
>   (__builtin_vec_extractl): New overloaded built-in function.
>   (__builtin_vec_extracth): Likewise.
>   * config/rs6000/rs6000-call.c (altivec_overloaded_builtins):
>   Define overloaded forms of __builtin_vec_extractl and
>   __builtin_vec_extracth.
>   (builtin_function_type): Add cases to mark arguments of new
>   built-in functions as unsigned.
>   (rs6000_common_init_builtins): Add
>   opaque_ftype_opaque_opaque_opaque_opaque.
>   * config/rs6000/rs6000.md (du_or_d): New mode attribute.
>   * doc/extend.texi (PowerPC AltiVec Built-in Functions Available
>   for a Future Architecture): Add description of vec_extractl and
>   vec_extractr built-in functions.
> 
> [gcc/testsuite]
> 
> 2020-05-10  Kelvin Nilsen  
> 
>   * gcc.target/powerpc/vec-extracth-0.c: New.
>   * gcc.target/powerpc/vec-extracth-1.c: New.
>   * gcc.target/powerpc/vec-extracth-2.c: New.
>   * gcc.target/powerpc/vec-extracth-3.c: New.
>   * gcc.target/powerpc/vec-extracth-4.c: New.
>   * gcc.target/powerpc/vec-extracth-5.c: New.
>   * gcc.target/powerpc/vec-extracth-6.c: New.
>   * gcc.target/powerpc/vec-extracth-7.c: New.
>   * gcc.target/powerpc/vec-extracth-be-0.c: New.
>   * gcc.target/powerpc/vec-extracth-be-1.c: New.
>   * gcc.target/powerpc/vec-extracth-be-2.c: New.
>   * gcc.target/powerpc/vec-extracth-be-3.c: New.
>   * gcc.target/powerpc/vec-extractl-0.c: New.
>   * gcc.target/powerpc/vec-extractl-1.c: New.
>   * gcc.target/powerpc/vec-extractl-2.c: New.
>   * gcc.target/powerpc/vec-extractl-3.c: New.
>   * gcc.target/powerpc/vec-extractl-4.c: New.
>   * gcc.target/powerpc/vec-extractl-5.c: New.
>   * gcc.target/powerpc/vec-extractl-6.c: New.
>   * gcc.target/powerpc/vec-extractl-7.c: New.
>   * gcc.target/powerpc/vec-extractl-be-0.c: New.
>   * gcc.target/powerpc/vec-extractl-be-1.c: New.
>   * gcc.target/powerpc/vec-extractl-be-2.c: New.
>   * gcc.target/powerpc/vec-extractl-be-3.c: New.

[Bug c++/79706] invalid delete[] expression doesn't cause substitution failure

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 11.

[Bug c++/79706] invalid delete[] expression doesn't cause substitution failure

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:4924293a62ee797310dd448e545118afd5aebb3f

commit r11-373-g4924293a62ee797310dd448e545118afd5aebb3f
Author: Patrick Palka 
Date:   Wed May 13 16:27:45 2020 -0400

c++: SFINAE for invalid delete-expression [PR79706]

This fixes SFINAE when substitution yields an invalid delete-expression
due to the pertinent deallocation function being marked deleted or
otherwise inaccessible.

We need to check for an erroneous result from build_op_delete_call and
exit early in that case, so that we don't build a COND_EXPR around the
erroneous result which finish_decltype_type would then quietly accept.

gcc/cp/ChangeLog:

PR c++/79706
* init.c (build_vec_delete_1): Just return error_mark_node if
deallocate_expr is error_mark_node.
(build_delete): Just return error_mark_node if do_delete is
error_mark_node.

gcc/testsuite/ChangeLog:

PR c++/79706
* g++.dg/template/sfinae30.C: New test.

[Bug c++/95117] New: Segmentation fault with static await_ready() or await_resume()

[oficsu at gmail dot com]

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

Bug ID: 95117
   Summary: Segmentation fault with static await_ready() or
await_resume()
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oficsu at gmail dot com
  Target Milestone: ---

Created attachment 48527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48527=edit
Minimal example

The attached archive contains a minimal example and a command that leads to an
internal compiler error in GCC 10 and later

Also, you can see the error on godbolt for gcc 10.1.0:
https://godbolt.org/z/CsJ4nG
The same error is reproducing in trunk version from godbolt:
https://godbolt.org/z/CsJ4nG


Working Draft contains the following definitions:
await-ready is the expression e.await_­ready(), contextually converted to bool.
...
await-suspend is the expression e.await_­suspend(h), which shall be a prvalue
of type void, bool, or std​::​coroutine_­handle for some type Z.
...
await-resume is the expression e.await_­resume().

Most likely the definition await_ready() and await_resume() as static is
ill-formed and should lead to a compilation error, but not to an segmentation
fault. BUT, please note that await-suspend is defined in the same way, but this
is compiled fine, so I'm not sure which behavior is right

[Bug c++/95020] requires expression always evaluates to true in the definition of template lambda defined within template function

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:7e52f8b1e03776575b92574252d9b6bbed9f1af4

commit r11-372-g7e52f8b1e03776575b92574252d9b6bbed9f1af4
Author: Patrick Palka 
Date:   Wed May 13 16:40:10 2020 -0400

c++: premature requires-expression folding [PR95020]

In the testcase below we're prematurely folding away the
requires-expression to 'true' after substituting in the function's
template arguments, but before substituting in the lambda's deduced
template arguments.

This patch removes the uses_template_parms check when deciding in
tsubst_requires_expr whether to keep around a new requires-expression.
Regardless of whether the template arguments are dependent, there still
might be more template parameters to later substitute in (as in the
below testcase) and even if not, tsubst_expr doesn't perform full
semantic processing unless !processing_template_decl, so we should still
wait until then to fold away the requires-expression.

gcc/cp/ChangeLog:

PR c++/95020
* constraint.c (tsubst_requires_expr): Produce a new
requires-expression when processing_template_decl, even if
template arguments are not dependent.

gcc/testsuite/ChangeLog:

PR c++/95020
* g++/cpp2a/concepts-lambda7.C: New test.

[Bug c++/95116] [C++ 20] Accepts invalid code with decltype dependent type

[ojman101 at protonmail dot com]

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

--- Comment #2 from Owen Smith  ---
Ah ok thanks, I didn't know about P0634R3 :D.

[Bug c++/95066] [C++ 20] Incorrect successful compilation with a conditional explicit

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:661232da72d29f8f2385d5f588727beb74360144

commit r11-371-g661232da72d29f8f2385d5f588727beb74360144
Author: Marek Polacek 
Date:   Mon May 11 18:28:19 2020 -0400

c++: explicit(bool) malfunction with dependent expression [PR95066]

I forgot to set DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P when merging two
function declarations and as a sad consequence, we never tsubsted
the dependent explicit-specifier in tsubst_function_decl, leading to
disregarding the explicit-specifier altogether, and wrongly accepting
this test.

PR c++/95066
* decl.c (duplicate_decls): Set DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P.

* g++.dg/cpp2a/explicit16.C: New test.

[C++] template arg comparison

[Nathan Sidwell]

When fixing up the template specialization hasher I was confused by the 
control flow through template_args_equal.  This reorders the category 
checking, so it is clearer as to what kind of node can reach which point.


nathan

--
Nathan Sidwell
2020-05-13  Nathan Sidwell  

	* pt.c (template_args_equal): Reorder category checking for
	clarity.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index a732ced2d8d..a36f603761c 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -9092,22 +9084,22 @@ template_args_equal (tree ot, tree nt, bool partial_order /* = false */)
   if (class_nttp_const_wrapper_p (ot))
 ot = TREE_OPERAND (ot, 0);
 
-  if (TREE_CODE (nt) == TREE_VEC)
+  if (TREE_CODE (nt) == TREE_VEC || TREE_CODE (nt) == TREE_VEC)
 /* For member templates */
-return TREE_CODE (ot) == TREE_VEC && comp_template_args (ot, nt);
-  else if (PACK_EXPANSION_P (ot))
-return (PACK_EXPANSION_P (nt)
+return TREE_CODE (ot) == TREE_CODE (nt) && comp_template_args (ot, nt);
+  else if (PACK_EXPANSION_P (ot) || PACK_EXPANSION_P (nt))
+return (PACK_EXPANSION_P (ot) && PACK_EXPANSION_P (nt)
 	&& template_args_equal (PACK_EXPANSION_PATTERN (ot),
 PACK_EXPANSION_PATTERN (nt))
 	&& template_args_equal (PACK_EXPANSION_EXTRA_ARGS (ot),
 PACK_EXPANSION_EXTRA_ARGS (nt)));
   else if (ARGUMENT_PACK_P (ot) || ARGUMENT_PACK_P (nt))
 return cp_tree_equal (ot, nt);
-  else if (ot && TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
+  else if (TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
 gcc_unreachable ();
-  else if (TYPE_P (nt))
+  else if (TYPE_P (nt) || TYPE_P (nt))
 {
-  if (!TYPE_P (ot))
+  if (!(TYPE_P (nt) && TYPE_P (ot)))
 	return false;
   /* Don't treat an alias template specialization with dependent
 	 arguments as equivalent to its underlying type when used as a
@@ -9125,8 +9117,6 @@ template_args_equal (tree ot, tree nt, bool partial_order /* = false */)
   else
 	return same_type_p (ot, nt);
 }
-  else if (TREE_CODE (ot) == TREE_VEC || TYPE_P (ot))
-return 0;
   else
 {
   /* Try to treat a template non-type argument that has been converted
@@ -9136,6 +9126,7 @@ template_args_equal (tree ot, tree nt, bool partial_order /* = false */)
 	 || code1 == NON_LVALUE_EXPR;
 	   code1 = TREE_CODE (ot))
 	ot = TREE_OPERAND (ot, 0);
+
   for (enum tree_code code2 = TREE_CODE (nt);
 	   CONVERT_EXPR_CODE_P (code2)
 	 || code2 == NON_LVALUE_EXPR;

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #10 from Avi Kivity  ---
Well, the standard is useless here.

In

[foo] () -> lazy { co_return foo; } ()

a temporary is clearly passed to the lambda body, yet the standard mandates
that we capture it by reference. As a result, a use-after-free is guaranteed.

[Bug lto/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #10 from Viktor Ostashevskyi  ---
Hello,

During GCC 10.1.0 bootstrap in LTO+PGO mode, configured as:

Configured with: ../gcc-10.1.0/configure --disable-multiarch
--disable-libquadmath --disable-libquadmath-support --disable-libssp
--disable-libstdcxx-pch --disable-multilib --disable-nls
--enable-checking=release --enable-__cxa_atexit --enable-languages=c,c++
--enable-libstdcxx-debug --enable-lto --enable-plugin --enable-threads=posix
--enable-tls --with-build-config=bootstrap-lto
--with-default-libstdcxx-abi=gcc4-compatible --with-linker-hash-style=gnu
--with-system-zlib --with-zstd=no --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu

I got following ICE:

/ostash/buildtc10/gcc-10.1.0-build/./prev-gcc/xgcc
-B/ostash/buildtc10/gcc-10.1.0-build/./prev-gcc/
-B/ostash/tc10/x86_64-pc-linux-gnu/bin/ -B/ostash/tc10/x86_64-pc-linux-gnu/bin/
-B/ostash/tc10/x86_64-pc-linux-gnu/lib/ -isystem
/ostash/tc10/x86_64-pc-linux-gnu/include -isystem
/ostash/tc10/x86_64-pc-linux-gnu/sys-include-c -DHAVE_CONFIG_H
-fprofile-use -flto=jobserver -frandom-seed=1  -I.
-I../../gcc-10.1.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE -fcf-protection
../../gcc-10.1.0/libiberty/hashtab.c -o hashtab.o
during IPA pass: fnsummary
../../gcc-10.1.0/libiberty/hashtab.c:997:1: internal compiler error: in
stream_out_histogram_value, at value-prof.c:338
  997 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [hashtab.o] Error 1
make[3]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build/libiberty'
make[2]: *** [all-stagefeedback-libiberty] Error 2
make[2]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build'
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build'
make: *** [profiledbootstrap] Error 2


I can provide gcda files if needed.

[C++] simplify typedef access checking

[Nathan Sidwell]

I discovered template typedef access checking was more expensive than it 
need be.  The call of get_types_needed_access_check in the 
FOR_EACH_VEC_SAFE_ELT is the moral equivalent of


  for (size_t pos = 0; pos != strlen (string); pos++)'

Let's not do that.

nathan

--
Nathan Sidwell
2020-05-13  Nathan Sidwell  

	* pt.c (perform_typedefs_access_check): Cache expensively
	calculated object references.
	(check_auto_in_tmpl_args): Just assert we do not get unexpected
	nodes, rather than silently do nothing.
	(append_type_to_template_for_access): Likewise, cache expensie
	object reference.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index a732ced2d8d..a36f603761c 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -11521,26 +11512,28 @@ perform_typedefs_access_check (tree tmpl, tree targs)
 	  && TREE_CODE (tmpl) != FUNCTION_DECL))
 return;
 
-  FOR_EACH_VEC_SAFE_ELT (get_types_needing_access_check (tmpl), i, iter)
-{
-  tree type_decl = iter->typedef_decl;
-  tree type_scope = iter->context;
-
-  if (!type_decl || !type_scope || !CLASS_TYPE_P (type_scope))
-	continue;
+  if (vec *tdefs
+  = get_types_needing_access_check (tmpl))
+FOR_EACH_VEC_ELT (*tdefs, i, iter)
+  {
+	tree type_decl = iter->typedef_decl;
+	tree type_scope = iter->context;
 
-  if (uses_template_parms (type_decl))
-	type_decl = tsubst (type_decl, targs, tf_error, NULL_TREE);
-  if (uses_template_parms (type_scope))
-	type_scope = tsubst (type_scope, targs, tf_error, NULL_TREE);
+	if (!type_decl || !type_scope || !CLASS_TYPE_P (type_scope))
+	  continue;
 
-  /* Make access check error messages point to the location
- of the use of the typedef.  */
-  iloc_sentinel ils (iter->locus);
-  perform_or_defer_access_check (TYPE_BINFO (type_scope),
- type_decl, type_decl,
- tf_warning_or_error);
-}
+	if (uses_template_parms (type_decl))
+	  type_decl = tsubst (type_decl, targs, tf_error, NULL_TREE);
+	if (uses_template_parms (type_scope))
+	  type_scope = tsubst (type_scope, targs, tf_error, NULL_TREE);
+
+	/* Make access check error messages point to the location
+	   of the use of the typedef.  */
+	iloc_sentinel ils (iter->locus);
+	perform_or_defer_access_check (TYPE_BINFO (type_scope),
+   type_decl, type_decl,
+   tf_warning_or_error);
+  }
 }
 
 static tree
@@ -29225,25 +29218,13 @@ check_auto_in_tmpl_args (tree tmpl, tree args)
 vec *
 get_types_needing_access_check (tree t)
 {
-  tree ti;
-  vec *result = NULL;
-
-  if (!t || t == error_mark_node)
-return NULL;
-
-  if (!(ti = get_template_info (t)))
-return NULL;
+  gcc_checking_assert ((CLASS_TYPE_P (t) || TREE_CODE (t) == FUNCTION_DECL));
+  
+  if (tree ti = get_template_info (t))
+if (TI_TEMPLATE (ti))
+  return TI_TYPEDEFS_NEEDING_ACCESS_CHECKING (ti);
 
-  if (CLASS_TYPE_P (t)
-  || TREE_CODE (t) == FUNCTION_DECL)
-{
-  if (!TI_TEMPLATE (ti))
-	return NULL;
-
-  result = TI_TYPEDEFS_NEEDING_ACCESS_CHECKING (ti);
-}
-
-  return result;
+  return NULL;
 }
 
 /* Append the typedef TYPE_DECL used in template T to a list of typedefs
@@ -29328,9 +29309,11 @@ append_type_to_template_for_access_check (tree templ,
   gcc_assert (type_decl && (TREE_CODE (type_decl) == TYPE_DECL));
 
   /* Make sure we don't append the type to the template twice.  */
-  FOR_EACH_VEC_SAFE_ELT (get_types_needing_access_check (templ), i, iter)
-if (iter->typedef_decl == type_decl && scope == iter->context)
-  return;
+  if (vec *tdefs
+  = get_types_needing_access_check (templ))
+FOR_EACH_VEC_ELT (*tdefs, i, iter)
+  if (iter->typedef_decl == type_decl && scope == iter->context)
+	return;
 
   append_type_to_template_for_access_check_1 (templ, type_decl,
 	  scope, location);

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #8)
> Created attachment 48526 [details]
> less lame testcase

thanks, it's in my queue to look at.

FWIW see the note in bullet 13 here:
http://eel.is/c++draft/dcl.fct.def.coroutine#13

consider also:
gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C

where, if the closure object were copied into the coroutine frame, the
operation would be incorrect.

[C++] canonical_type_parameter

[Nathan Sidwell]

Canonical_type_parameter shows C-like thinking.  This modernizes it, 
which I found simpler to understand.


pushed to master

nathan
--
Nathan Sidwell
2020-05-13  Nathan Sidwell  

	* pt.c (canonical_type_parameter): Simplify.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index a732ced2d8d..a36f603761c 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -4417,29 +4417,21 @@ build_template_parm_index (int index,
 static tree
 canonical_type_parameter (tree type)
 {
-  tree list;
   int idx = TEMPLATE_TYPE_IDX (type);
 
   gcc_assert (TREE_CODE (type) != TEMPLATE_TEMPLATE_PARM);
 
-  if (!canonical_template_parms)
-vec_alloc (canonical_template_parms, idx + 1);
-
-  if (canonical_template_parms->length () <= (unsigned) idx)
+  if (vec_safe_length (canonical_template_parms) <= (unsigned) idx)
 vec_safe_grow_cleared (canonical_template_parms, idx + 1);
 
-  list = (*canonical_template_parms)[idx];
-  while (list && !comptypes (type, TREE_VALUE (list), COMPARE_STRUCTURAL))
-list = TREE_CHAIN (list);
+  for (tree list = (*canonical_template_parms)[idx];
+   list; list = TREE_CHAIN (list))
+if (comptypes (type, TREE_VALUE (list), COMPARE_STRUCTURAL))
+  return TREE_VALUE (list);
 
-  if (list)
-return TREE_VALUE (list);
-  else
-{
-  (*canonical_template_parms)[idx]
-	= tree_cons (NULL_TREE, type, (*canonical_template_parms)[idx]);
-  return type;
-}
+  (*canonical_template_parms)[idx]
+= tree_cons (NULL_TREE, type, (*canonical_template_parms)[idx]);
+  return type;
 }
 
 /* Return a TEMPLATE_PARM_INDEX, similar to INDEX, but whose

[Bug c++/95116] [C++ 20] Accepts invalid code with decltype dependent type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Not a bug; this is valid C++20 code since we implement P0634R3, Down with
typename!.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #7 from Avi Kivity  ---
I have a simple reproducer. A lambda fails while a fake lambda using structs
passes. I don't think gcc is at fault, but the standard is problematic here
IMO.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #8 from Avi Kivity  ---
Created attachment 48526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48526=edit
less lame testcase

[Bug c++/95116] New: [C++ 20] Accepts invalid code with decltype dependent type

[ojman101 at protonmail dot com]

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

Bug ID: 95116
   Summary: [C++ 20] Accepts invalid code with decltype dependent
type
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ojman101 at protonmail dot com
  Target Milestone: ---

The code below is invalid. The keyword "typename" needs to be inserted before
the decltype expression as "bar" is a dependent type (dependent on template
type T).

template 
struct Bar {
using bar_type = int;
};

template 
struct Foo {
Bar bar;

using foo_type = decltype(bar)::bar_type;
};

int main() {
// Instantiate Foo template
Foo foo;
}

The code successfully compiles with GCC 9.3.0 when running the command "g++
-std=c++2a main.cpp". Note that the "-std=c++2a" must be passed. When passing
"-std=c++17", GCC successfully detects the error and prints:

main.cpp:10:22: error: need 'typename' before 'decltype
(((Foo*)(void)0)->Foo::bar)::bar_type' because 'decltype
(((Foo*)(void)0)->Foo::bar)' is a dependent scope
   10 | using foo_type = decltype(bar)::bar_type;
  |  ^~~~
  |  typename

Running clang 10 with the command "clang++ -std=c++2a main.cpp" also
successfully detects the error and prints:

main.cpp:10:22: error: missing 'typename' prior to dependent type name
'decltype(bar)::bar_type'
using foo_type = decltype(bar)::bar_type;
 ^~~
 typename 
1 error generated.

[Bug target/95115] New: [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[aurelien at aurel32 dot net]

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

Bug ID: 95115
   Summary: [10 Regression] RISC-V 64: inf/inf division optimized
out, invalid operation not raised
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: riscv64-unknown-linux-gnu
Target: riscv64-unknown-linux-gnu
 Build: riscv64-unknown-linux-gnu

Created attachment 48525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48525=edit
Testcase

On 64-bit RISC-V, the acos/asin tests from the glibc testsuite fails when it is
built with GCC 10, as the invalid operation flag is not raised for invalid
input values. The glibc code uses the following code to generate a NaN and
raise an invalid input [1]:

  else {
u.i[HIGH_HALF]=0x7ff0;
v.i[HIGH_HALF]=0x7ff0;
u.i[LOW_HALF]=0;
v.i[LOW_HALF]=0;
return u.x/v.x;
  }

With GCC 9, this results in the following code:
li  a1,2047
sllia1,a1,52
fmv.d.x fa5,a1
li  a0,16
fdiv.d  fs0,fa5,fa5

With GCC 10, the division is optimized out and the result is directly loaded as
a constant, causing the invalid operation not to be raised.

I have attached a small testcase to reproduce the issue.

[C++] some cleanup patches

[Nathan Sidwell]

I've committed this set of minor cleanups from the modules branch.

nathan
--
Nathan Sidwell
2020-05-13  Nathan Sidwell  

	Formatting fixups & some simplifications.
	* pt.c (spec_hash_table): New typedef.
	(decl_specializations, type_specializations): Use it.
	(retrieve_specialization): Likewise.
	(register_specialization): Remove unnecessary casts.
	(push_template_decl_real): Reformat.
	(instantiate_class_template_1): Use more RAII.
	(make_argument_pack): Simplify.
	(instantiate_template_1): Use gcc_checking_assert for expensive
	asserts.
	(instantiate_decl): Likewise.
	(resolve_typename_type): Reformat comment.
	* semantics.c (struct deferred_access): Remove unnecessary GTY on
	member.
	(begin_class_definition): Fix formatting.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 7911293571e..ff15a926db9 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -48,9 +48,9 @@ along with GCC; see the file COPYING3.  If not see
returning an int.  */
 typedef int (*tree_fn_t) (tree, void*);
 
-/* The PENDING_TEMPLATES is a TREE_LIST of templates whose
-   instantiations have been deferred, either because their definitions
-   were not yet available, or because we were putting off doing the work.  */
+/* The PENDING_TEMPLATES is a list of templates whose instantiations
+   have been deferred, either because their definitions were not yet
+   available, or because we were putting off doing the work.  */
 struct GTY ((chain_next ("%h.next"))) pending_template
 {
   struct pending_template *next;
@@ -116,9 +116,10 @@ struct spec_hasher : ggc_ptr_hash
   static bool equal (spec_entry *, spec_entry *);
 };
 
-static GTY (()) hash_table *decl_specializations;
-
-static GTY (()) hash_table *type_specializations;
+/* The general template is not in these tables.  */
+typedef hash_table spec_hash_table;
+static GTY (()) spec_hash_table *decl_specializations;
+static GTY (()) spec_hash_table *type_specializations;
 
 /* Contains canonical template parameter types. The vector is indexed by
the TEMPLATE_TYPE_IDX of the template parameter. Each element is a
@@ -1278,7 +1279,7 @@ retrieve_specialization (tree tmpl, tree args, hashval_t hash)
 {
   spec_entry *found;
   spec_entry elt;
-  hash_table *specializations;
+  spec_hash_table *specializations;
 
   elt.tmpl = tmpl;
   elt.args = args;
@@ -1573,10 +1574,9 @@ register_specialization (tree spec, tree tmpl, tree args, bool is_friend,
   if (hash == 0)
 	hash = spec_hasher::hash ();
 
-  slot =
-	decl_specializations->find_slot_with_hash (, hash, INSERT);
+  slot = decl_specializations->find_slot_with_hash (, hash, INSERT);
   if (*slot)
-	fn = ((spec_entry *) *slot)->spec;
+	fn = (*slot)->spec;
   else
 	fn = NULL_TREE;
 }
@@ -4474,7 +4466,7 @@ reduce_template_parm_level (tree index, tree type, int levels, tree args,
   TEMPLATE_PARM_PARAMETER_PACK (tpi)
 	= TEMPLATE_PARM_PARAMETER_PACK (index);
 
-	/* Template template parameters need this.  */
+  /* Template template parameters need this.  */
   tree inner = decl;
   if (TREE_CODE (decl) == TEMPLATE_DECL)
 	{
@@ -5705,8 +5697,7 @@ push_template_decl_real (tree decl, bool is_friend)
  template  friend void A::f();
is not primary.  */
 is_primary = false;
-  else if (TREE_CODE (decl) == TYPE_DECL
-	   && LAMBDA_TYPE_P (TREE_TYPE (decl)))
+  else if (TREE_CODE (decl) == TYPE_DECL && LAMBDA_TYPE_P (TREE_TYPE (decl)))
 is_primary = false;
   else
 is_primary = template_parm_scope_p ();
@@ -5845,8 +5836,7 @@ push_template_decl_real (tree decl, bool is_friend)
   if (!ctx
   || TREE_CODE (ctx) == FUNCTION_DECL
   || (CLASS_TYPE_P (ctx) && TYPE_BEING_DEFINED (ctx))
-  || (TREE_CODE (decl) == TYPE_DECL
-	  && LAMBDA_TYPE_P (TREE_TYPE (decl)))
+  || (TREE_CODE (decl) == TYPE_DECL && LAMBDA_TYPE_P (TREE_TYPE (decl)))
   || (is_friend && !DECL_TEMPLATE_INFO (decl)))
 {
   if (DECL_LANG_SPECIFIC (decl)
@@ -11752,13 +11743,10 @@ instantiate_class_template_1 (tree type)
 		continue;
 
 	  /* Build new CLASSTYPE_NESTED_UTDS.  */
+	  bool class_template_p = (TREE_CODE (t) != ENUMERAL_TYPE
+   && TYPE_LANG_SPECIFIC (t)
+   && CLASSTYPE_IS_TEMPLATE (t));
 
-	  tree newtag;
-	  bool class_template_p;
-
-	  class_template_p = (TREE_CODE (t) != ENUMERAL_TYPE
-  && TYPE_LANG_SPECIFIC (t)
-  && CLASSTYPE_IS_TEMPLATE (t));
 	  /* If the member is a class template, then -- even after
 		 substitution -- there may be dependent types in the
 		 template argument list for the class.  We increment
@@ -11767,7 +11755,7 @@ instantiate_class_template_1 (tree type)
 		 when outside of a template.  */
 	  if (class_template_p)
 		++processing_template_decl;
-	  newtag = tsubst (t, args, tf_error, NULL_TREE);
+	  tree newtag = tsubst (t, args, tf_error, NULL_TREE);
 	  if (class_template_p)
 		--processing_template_decl;
 	  if (newtag == error_mark_node)
@@ -11834,6 

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #5)
> This snippet from cppreference:
> 
>   If the coroutine is a non-static member function, such as task 
>   my_class::method1(int x) const;, its Promise type is 
>   std::coroutine_traits, const my_class&, int>::promise_type
> 
> implies that both gcc and my interpretation are wrong. gcc passes a pointer
> for the lambda, and I'd like the lambda to be passed by value. The
> difference between gcc and cppreference is trivial, and both of them make
> coroutine lambdas unusable if they contain state and if the lambda is
> asynchronous.

( assuming that this is the problem, I haven't yet had a chance to check *
could still be a bug ;) ).

I have a pending change to pass a reference to the lambda object to the traits,
promise preview and allocator lookups.

This was a source of considerable discussion amongst the implementors (GCC,
clang, MSVC) about how the std should be interpreted.  The change I mention
will make the lambda capture object pointer behave in the same manner as 'this'
(which was the intended behaviour as determined by the long discussion).  MSVC
implements this now, and clang will be changing to match it also.

That won't solve any lifetime issue with the capture object - you will still
need to ensure that it exists for the duration of the coroutine * as you would
for a class instance with a method coroutine *.

We (at least several of us) agree that this is a source of easy programming
errors - and I expect there to be some revisiting in c++23.  That's a
considerable challenge in the face of a mutable lambda - maybe (thinking aloud)
needs something like Apple blocks, but with an automatic promotion of the
closure to a heap object if it escapes the creating scope.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #5 from Avi Kivity  ---
This snippet from cppreference:

  If the coroutine is a non-static member function, such as task 
  my_class::method1(int x) const;, its Promise type is 
  std::coroutine_traits, const my_class&, int>::promise_type

implies that both gcc and my interpretation are wrong. gcc passes a pointer for
the lambda, and I'd like the lambda to be passed by value. The difference
between gcc and cppreference is trivial, and both of them make coroutine
lambdas unusable if they contain state and if the lambda is asynchronous.

Re: [PATCH] c++: premature requires-expression folding [PR95020]

[Jason Merrill via Gcc-patches]

On 5/11/20 6:43 PM, Patrick Palka wrote:

In the testcase below we're prematurely folding away the
requires-expression to 'true' after substituting in the function's
template arguments, but before substituting in the lambda's deduced
template arguments.

This happens because during the first tsubst_requires_expr,
processing_template_decl is 1 but 'args' is just {void} and therefore
non-dependent, so we end up folding away the requires-expression to
boolean_true_node before we could substitute in the lambda's template
arguments and determine that '*v' is ill-formed.

This patch removes the uses_template_parms check when deciding in
tsubst_requires_expr whether to keep around a new requires-expression.
Regardless of whether the template arguments are dependent, there still
might be more template parameters to later substitute in -- as in the
testcase below -- and even if not, tsubst_expr doesn't perform full
semantic processing unless !processing_template_decl, so it seems we
should wait until then to fold away the requires-expression.

Passes 'make check-c++', does this look OK to commit after a full
bootstrap/regtest?


OK.


gcc/cp/ChangeLog:

PR c++/95020
* constraint.c (tsubst_requires_expr): Produce a new
requires-expression when processing_template_decl, even if
template arguments are not dependent.

gcc/testsuite/ChangeLog:

PR c++/95020
* g++/cpp2a/concepts-lambda7.C: New test.
---
  gcc/cp/constraint.cc  |  4 +---
  gcc/testsuite/g++.dg/cpp2a/concepts-lambda7.C | 14 ++
  2 files changed, 15 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda7.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 4ad17f3b7d8..8ee347cae60 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2173,9 +2173,7 @@ tsubst_requires_expr (tree t, tree args,
if (reqs == error_mark_node)
  return boolean_false_node;
  
-  /* In certain cases, produce a new requires-expression.

- Otherwise the value of the expression is true.  */
-  if (processing_template_decl && uses_template_parms (args))
+  if (processing_template_decl)
  return finish_requires_expr (cp_expr_location (t), parms, reqs);
  
return boolean_true_node;

diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda7.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda7.C
new file mode 100644
index 000..50746b777a3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda7.C
@@ -0,0 +1,14 @@
+// PR c++/95020
+// { dg-do compile { target c++2a } }
+
+template
+void foo() {
+  auto t = [](auto v) {
+static_assert(requires { *v; }); // { dg-error "static assertion failed" }
+  };
+  t(0);
+}
+
+void bar() {
+  foo();
+}

Re: [PATCH] c++: explicit(bool) malfunction with dependent expression [PR95066]

[Jason Merrill via Gcc-patches]

On 5/11/20 7:06 PM, Marek Polacek wrote:

I forgot to set DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P when merging two
function declarations and as a sad consequence, we never tsubsted
the dependent explicit-specifier in tsubst_function_decl, leading to
disregarding the explicit-specifier altogether, and wrongly accepting
this test.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10/9?


OK.


PR c++/95066
* decl.c (duplicate_decls): Set DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P.

* g++.dg/cpp2a/explicit16.C: New test.
---
  gcc/cp/decl.c   |  2 ++
  gcc/testsuite/g++.dg/cpp2a/explicit16.C | 21 +
  2 files changed, 23 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/explicit16.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1b6a5672334..604ecf42e95 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2035,6 +2035,8 @@ duplicate_decls (tree newdecl, tree olddecl, bool 
newdecl_is_friend)
DECL_FINAL_P (newdecl) |= DECL_FINAL_P (olddecl);
DECL_OVERRIDE_P (newdecl) |= DECL_OVERRIDE_P (olddecl);
DECL_THIS_STATIC (newdecl) |= DECL_THIS_STATIC (olddecl);
+  DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P (newdecl)
+   |= DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P (olddecl);
if (DECL_OVERLOADED_OPERATOR_P (olddecl))
DECL_OVERLOADED_OPERATOR_CODE_RAW (newdecl)
  = DECL_OVERLOADED_OPERATOR_CODE_RAW (olddecl);
diff --git a/gcc/testsuite/g++.dg/cpp2a/explicit16.C 
b/gcc/testsuite/g++.dg/cpp2a/explicit16.C
new file mode 100644
index 000..9d95b0d669e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/explicit16.C
@@ -0,0 +1,21 @@
+// PR c++/95066 - explicit malfunction with dependent expression.
+// { dg-do compile { target c++2a } }
+
+template 
+struct Foo {
+  template 
+  explicit(static_cast(true)) operator Foo();
+};
+
+template 
+template 
+Foo::operator Foo() {
+  return {};
+}
+
+int
+main ()
+{
+  Foo a;
+  Foo b = a; // { dg-error "conversion" }
+}

base-commit: 840ac85ced0695fefecee433327e4298b4adb20a

Re: [PATCH] c++: SFINAE for invalid delete-expression [PR79706]

[Jason Merrill via Gcc-patches]

On 5/12/20 11:36 PM, Patrick Palka wrote:

This fixes SFINAE when substitution yields an invalid delete-expression
due to the pertinent deallocation function being marked deleted or
otherwise inaccessible.

We need to check for an erroneous result from build_op_delete_call and
exit early in that case, so that we don't build a COND_EXPR around the
erroneous call which finish_decltype_type would then quietly accept.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?


OK.


gcc/cp/ChangeLog:

PR c++/79706
* init.c (build_vec_delete_1): Return error_mark_node if
deallocate_expr is error_mark_node.
(build_delete): Return error_mark_node if do_delete is
error_mark_node.

gcc/testsuite/ChangeLog:

PR c++/79706
* g++.dg/template/sfinae30.C: New test.
---
  gcc/cp/init.c|  8 ++--
  gcc/testsuite/g++.dg/template/sfinae30.C | 21 +
  2 files changed, 27 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/template/sfinae30.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index e2e547afd96..c1047dbb1cc 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -4076,7 +4076,9 @@ build_vec_delete_1 (location_t loc, tree base, tree 
maxindex, tree type,
  }
  
body = loop;

-  if (!deallocate_expr)
+  if (deallocate_expr == error_mark_node)
+return error_mark_node;
+  else if (!deallocate_expr)
  ;
else if (!body)
  body = deallocate_expr;
@@ -4993,7 +4995,9 @@ build_delete (location_t loc, tree otype, tree addr,
return expr;
  }
  
-  if (do_delete)

+  if (do_delete == error_mark_node)
+return error_mark_node;
+  else if (do_delete)
  {
tree do_delete_call_expr = extract_call_expr (do_delete);
if (TREE_CODE (do_delete_call_expr) == CALL_EXPR)
diff --git a/gcc/testsuite/g++.dg/template/sfinae30.C 
b/gcc/testsuite/g++.dg/template/sfinae30.C
new file mode 100644
index 000..82f31aaa625
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/sfinae30.C
@@ -0,0 +1,21 @@
+// PR c++/79706
+// { dg-do compile { target c++11 } }
+
+struct A {
+  void operator delete(void*) = delete;
+private:
+  void operator delete[](void*);
+};
+
+extern A *p;
+
+template
+auto foo(T *t) -> decltype(delete t); // { dg-error "use of deleted function" }
+
+template
+auto bar(T *t) -> decltype(delete[] t); // { dg-error "private within this 
context" }
+
+void baz() {
+  foo(p); // { dg-error "no match" }
+  bar(p); // { dg-error "no match" }
+}

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #3)
> The test case I uploaded only shows the failure, it won't work if gcc worked
> as I expect it. I'll try to get a better testcase, unfortunately a small
> coroutine testcase is still some work.

yeah, I have some boiler-plate code in headers in the GCC test-suite that can
help.

[pushed] testsuite: Support { target c++20 } in tests.

[Jason Merrill via Gcc-patches]

I'm not sure why I didn't check this in along with adding -std=c++20, since
I wrote this patch at the same time.  The testsuite should support both
{ target c++2a } and { target c++20 }.

Tested x86_64-pc-linux-gnu, applying to trunk and 10.

gcc/testsuite/ChangeLog
2020-05-13  Jason Merrill  

* lib/target-supports.exp (check_effective_target_c++20_only)
(check_effective_target_c++20): New.
---
 gcc/testsuite/lib/target-supports.exp | 8 
 1 file changed, 8 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 3a6ab8740c3..88f4a9cd812 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9134,6 +9134,14 @@ proc check_effective_target_c++2a { } {
 return [check_effective_target_c++2a_only]
 }
 
+proc check_effective_target_c++20_only { } {
+return [check_effective_target_c++2a_only]
+}
+
+proc check_effective_target_c++20 { } {
+return [check_effective_target_c++2a]
+}
+
 # Check for C++ Concepts support, i.e. -fconcepts flag.
 proc check_effective_target_concepts { } {
 if [check_effective_target_c++2a] {

base-commit: 18edc195442291525e04f0fa4d5ef972155117da
-- 
2.18.1

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #3 from Avi Kivity  ---
The test case I uploaded only shows the failure, it won't work if gcc worked as
I expect it. I'll try to get a better testcase, unfortunately a small coroutine
testcase is still some work.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #2 from Avi Kivity  ---
Created attachment 48524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48524=edit
lame testcase

Lame testcase that shows that the lambda is passed as a pointer rather than by
value, leading to a leak if the coroutine is suspended.

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #1 from Iain Sandoe  ---
There are some gotchas with coroutines and references (both regular and
rvalue).

* there could still be a bug here, so I want to double-check.

Please could you expand your snippets of code into a small test-case that would
would expect to work?

(FWIW, in my original impl. I tried to be more defensive about lambda captures
- but that wasn't correct in the presence of a mutable lambda - and didn't
agree with other implementations - or the collective understanding of the
intent of the standard - so I backed that out).

[Bug middle-end/95114] [9/10/11 Regression] ICE in obj_type_ref_class for structural-equality types

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |9.4
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
   Last reconfirmed||2020-05-13
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Testing a patch that tests for null returns.

[Bug middle-end/95114] New: [9/10/11 Regression] ICE in obj_type_ref_class for structural-equality types

[rsandifo at gcc dot gnu.org]

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

Bug ID: 95114
   Summary: [9/10/11 Regression] ICE in obj_type_ref_class for
structural-equality types
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

Since r9-5035-g4611c03d2b0edefc8d8e17872ef143428f56380b,
the following testcase has ICEd for aarch64, compiled at -O0:

---
template struct foo { virtual void f() = 0; };
extern foo<__Int8x8_t> 
void f() { x.f(); }
---

The exact ICE has changed over time, but the current form is:

---
during GIMPLE pass: *rebuild_cgraph_edges
foo.c: In function ‘void f()’:
foo.c:3:19: internal compiler error: Segmentation fault
3 | void f() { x.f(); }
  |   ^
0x16cfec1 crash_signal
src/gcc/gcc/toplev.c:328
0x129a4ca obj_type_ref_class(tree_node const*)
src/gcc/gcc/ipa-devirt.c:1915
0x1afe3d7 virtual_method_call_p(tree_node const*)
src/gcc/gcc/tree.c:12867
0xf1102b cgraph_node::create_indirect_edge(gcall*, int, profile_count, bool)
src/gcc/gcc/cgraph.c:990
0xf2113d cgraph_edge::rebuild_edges()
src/gcc/gcc/cgraphbuild.c:421
0xf214aa execute
src/gcc/gcc/cgraphbuild.c:490
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
---

This is because for structural-equality types we call
get_odr_type:

---
  if (!in_lto_p && !TYPE_STRUCTURAL_EQUALITY_P (ret))
ret = TYPE_CANONICAL (ret);
  else
ret = get_odr_type (ret)->type;
---

and the hash table is empty at this point.  (We did previously
have a hash entry for the type, but that was freed during
pass_ipa_free_lang_data.)

The test does pass at -O2, but fails with
-fdump-tree-all-details -O2:

---
foo.c: In function ‘void f()’:
foo.c:3:19: internal compiler error: Segmentation fault
3 | void f() { x.f(); }
  |   ^
0x16cfec1 crash_signal
src/gcc/gcc/toplev.c:328
0x12a20f8 hash_table::find_slot_with_hash(tree_node* const&, unsigned int,
insert_option)
src/gcc/gcc/hash-table.h:967
0x129a622 get_odr_type(tree_node*, bool)
src/gcc/gcc/ipa-devirt.c:1939
0x129a4c9 obj_type_ref_class(tree_node const*)
src/gcc/gcc/ipa-devirt.c:1915
0x1afe3d7 virtual_method_call_p(tree_node const*)
src/gcc/gcc/tree.c:12867
0x180f086 dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
src/gcc/gcc/tree-pretty-print.c:3125
...
---

I guess the fact that this routine is called by the dump routines
(which shouldn't affect codegen) suggests that we should cope
with null returns from get_odr_type, rather than passing "true"
as the insert parameter.  Is that right?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #212 from dave.anglin at bell dot net ---
On 2020-05-13 2:03 p.m., jared.martinsen at fiserv dot com wrote:
> --- Comment #211 from Jared  ---
> Are these errors the same as described above?
>
> It give the following 2 errors:
> ld: The value 0xfe38a260 does not fit when applying the relocation
> PCREL21B for symbol ".text" at offset 0x22 in
> section index 222 of file
> /library/home/build/tapecut5/code/lib/libsubo.a[file1.o]
> ld: The value 0xfe587970 does not fit when applying the relocation
> PCREL21B for symbol ".text" at offset 0x22 in
> section index 2125 of file
> /library/home/build/tapecut5/code/lib/libsubo.a[file2.o]
Yes.  Most likely these are references to weak symbols.  Compiling with -Os
might help.
>  
>
>
> Using gcc version 4.2.3.  On 64 bit HP-UX
> Here is the raw command line.
> /usr/local/bin/g++ /library/home/build/tapecut5/code/obj/ocu00.o -z
> -L/usr/local/lib/hpux32 -lxerces-c -lxerces-depdom -
> L/opt/eloquence/8.2/lib/hpux32 -leqdb -limage3k -lfwutil
> -L/library/home/build/tapecut5/code/lib -lsubo -lsubr -L/librar
> y/home/build/tapecut5/code/spx/lib -lspx -lm  -lcrypto -lssl -o
> /library/home/build/tapecut5/code/bin/spectrum 
>
> Is there a fix for this?  Newer compiler or an option?
>
No.  They block building latter versions of gcc that require g++.

[Bug c++/94024] Error message has misleading source location for constructor member initialisation.

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug middle-end/95108] [9/10/11 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug go/95061] shared libgo library not found when running the testsuite

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Should be fixed now.

Note that this can only happen when running the tests as root.

libgo patch committed: Build syscall test with -static

[Ian Lance Taylor via Gcc-patches]

This libgo patch builds the syscall test with -static.  This avoids
problems finding libgo.so when running the test as root, which invokes
the test as a child process in various limited environments.  This
fixes GCC PR 95061.  Bootstrapped and ran Go tests on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
0d5d880994660e231f82b7cb1dcfab744158f7e0
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 02f6746cf6b..b63bb3bd547 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-876bdf3df3bb33dbf1414237d84be5da32a48082
+93b3d88515db85e203d54f382200b84b56b0ae4c
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index dea09de592b..eff0e00e787 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -967,6 +967,10 @@ endif
 # Also use -fno-inline to get better results from the memory profiler.
 runtime_pprof_check_GOCFLAGS = -static-libgo -fno-inline
 
+# Use -static for the syscall tests, because otherwise when
+# running as root the re-execs ignore LD_LIBRARY_PATH.
+syscall_check_GOCFLAGS = -static
+
 extra_go_files_runtime_internal_sys = version.go
 runtime/internal/sys.lo.dep: $(extra_go_files_runtime_internal_sys)
 

[Bug go/95061] shared libgo library not found when running the testsuite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:0d5d880994660e231f82b7cb1dcfab744158f7e0

commit r11-364-g0d5d880994660e231f82b7cb1dcfab744158f7e0
Author: Ian Lance Taylor 
Date:   Wed May 13 11:12:01 2020 -0700

libgo: build syscall test with -static

This avoids problems finding libgo.so when running the test as root,
which invokes the test as a child process in various limited environments.

Fixes PR go/95061

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/233897

[Bug tree-optimization/95113] [10/11 Regression] Wrong code w/ -O2 -fexceptions -fnon-call-exceptions

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
(In reply to Jakub Jelinek from comment #2)
> Guess dup of the other PR where the IPA opts assume DCE which doesn't really
> happen (the *p load result is never used).

Indeed, -fno-ipa-sra fixes it. So, a duplicate of PR93385?

Re: dejagnu version update?

[Rainer Orth]

Jonathan Wakely via Gcc  writes:

>> I had previously approved the update to 1.5.3, but no one really wanted
>> it as no one updated the requirement.  Let's have the 1.6 discussion.
>> I'm not only inclined to up to 1.6, but to actually edit it in this time.
>
> Would the tests actually refuse to run with an older version?
>
>> Anyone strongly against?  Why?
>
> I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.

If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
indefinitely until one manually kills them.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: dejagnu version update?

[Rob Savoye]

On 5/13/20 10:51 AM, Mike Stump wrote:

> So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both
> contain 6, and SLES has 6 and since we've been sitting at 1.4.4 for
> so long, anyone want to not update dejagnu to require 1.6?

  We do still find and fix bugs occasionally. :-) And 1.4.4 was released
16 years ago... Linaro has been using the most recent release for years,
so I think it's a safe upgrade.

- rob -
---
https://www.senecass.com

[Bug libfortran/95101] Optimize libgfortran library handling of arrays

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-05-13

[Bug tree-optimization/95113] [10/11 Regression] Wrong code w/ -O2 -fexceptions -fnon-call-exceptions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
int a, b;

static inline long int
foo (long int x, int y)
{
  if (y == 0)
return 0;

  if (x == -1 && y == -1)
return 0;

  return x / y;
}

static inline int
bar (int *p)
{
  int c = foo (a, 1) + *p;
  return b;
}

int
main ()
{
  int d = 0;
  b = foo (1, 1);
  bar ();
  return 0;
}

Guess dup of the other PR where the IPA opts assume DCE which doesn't really
happen (the *p load result is never used).

libbacktrace patch committed: Mark state unused in ztest.c test_large

[Ian Lance Taylor via Gcc-patches]

This libbacktrace patch marks the state parameter of test_large in
ztest.c as ATTRIBUTE_UNUSED.  The parameter is not used if HAVE_ZLIB
is not defined.  Bootstrapped and ran libbacktrace tests on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian

2020-05-13  Ian Lance Taylor  

* ztest.c (test_large): Mark state ATTRIBUTE_UNUSED.
diff --git a/libbacktrace/ztest.c b/libbacktrace/ztest.c
index 2663c90061a..39476704972 100644
--- a/libbacktrace/ztest.c
+++ b/libbacktrace/ztest.c
@@ -294,7 +294,7 @@ average_time (const size_t *times, size_t trials)
 /* Test a larger text, if available.  */
 
 static void
-test_large (struct backtrace_state *state)
+test_large (struct backtrace_state *state ATTRIBUTE_UNUSED)
 {
 #ifdef HAVE_ZLIB
   unsigned char *orig_buf;

[Bug tree-optimization/95113] [10/11 Regression] Wrong code w/ -O2 -fexceptions -fnon-call-exceptions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.2
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r10-3542-g0b92cf305dcf34387a8e2564e55ca8948df3b47a

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jared.martinsen at fiserv dot com]

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

Jared  changed:

   What|Removed |Added

 CC||jared.martinsen at fiserv dot 
com

--- Comment #211 from Jared  ---
Are these errors the same as described above?

It give the following 2 errors:
ld: The value 0xfe38a260 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in
section index 222 of file
/library/home/build/tapecut5/code/lib/libsubo.a[file1.o]
ld: The value 0xfe587970 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in
section index 2125 of file
/library/home/build/tapecut5/code/lib/libsubo.a[file2.o] 


Using gcc version 4.2.3.  On 64 bit HP-UX
Here is the raw command line.
/usr/local/bin/g++ /library/home/build/tapecut5/code/obj/ocu00.o -z
-L/usr/local/lib/hpux32 -lxerces-c -lxerces-depdom -
L/opt/eloquence/8.2/lib/hpux32 -leqdb -limage3k -lfwutil
-L/library/home/build/tapecut5/code/lib -lsubo -lsubr -L/librar
y/home/build/tapecut5/code/spx/lib -lspx -lm  -lcrypto -lssl -o
/library/home/build/tapecut5/code/bin/spectrum 

Is there a fix for this?  Newer compiler or an option?

[Bug tree-optimization/95113] New: [10/11 Regression] Wrong code w/ -O2 -fexceptions -fnon-call-exceptions

[asolokha at gmx dot com]

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

Bug ID: 95113
   Summary: [10/11 Regression] Wrong code w/ -O2 -fexceptions
-fnon-call-exceptions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

The following program compiled w/ gcc-11.0.0-alpha20200510 snapshot
(g:13a46321516e2efd3bbb1f1899c539c6724240a9) w/ -O2 -fexceptions
-fnon-call-exceptions:

int p4, cd;

static long int
sg (long int kl, int mp)
{
  if (mp == 0)
return 0;

  if (kl == -1 && mp == -1)
return 0;

  return kl / mp;
}

static int
eo (int *yg)
{
  int du;

  du = sg (p4, 1) + *yg;
  (void) du;

  return cd;
}

int
main (void)
{
  int um = 0;

  cd = sg (1, 1);
  eo ();

  return 0;
}

% x86_64-unknown-linux-gnu-gcc-11.0.0 -O2 -fexceptions -Wuninitialized -o good
li6hfrrz.c
% ./good
% echo $?
0
% objdump --section=.text --disassemble=main good | tail -n6

04e0 :
 4e0:   c7 05 32 1b 00 00 01movl   $0x1,0x1b32(%rip)# 201c 
 4e7:   00 00 00
 4ea:   31 c0   xor%eax,%eax
 4ec:   c3  retq

% x86_64-unknown-linux-gnu-gcc-11.0.0 -O2 -fexceptions -fnon-call-exceptions
-Wuninitialized -o bad li6hfrrz.c
% ./bad
zsh: segmentation fault (core dumped)  ./bad
% objdump --section=.text --disassemble=main bad | tail -n6
04e0 :
 4e0:   c7 05 32 1b 00 00 01movl   $0x1,0x1b32(%rip)# 201c 
 4e7:   00 00 00
 4ea:   8b 04 25 00 00 00 00mov0x0,%eax
 4f1:   31 c0   xor%eax,%eax
 4f3:   c3  retq

https://gcc.godbolt.org/z/V4a-K7

Re: ChangeLog files - server and client scripts

[Joseph Myers]

On Wed, 13 May 2020, Martin Liška wrote:

> I'm sending the gcc-changelog relates scripts which should be added to contrib
> folder. The patch contains:
> - git_check_commit.py - checking script that verifies git message format

We need a documentation patch to contribute.html or gitwrite.html that 
describes the exact commit message format being used.

> - git_update_version.py - a replacement of
> maintainer-scripts/update_version_git which
> bumps DATESTAMP and generates ChangeLog entries (for now into ChangeLog.test
> files)

Where does this check things out?  (The existing ~gccadmin/gcc-checkout 
isn't suitable for that, it needs to stay on master to have the correct 
version of maintainer-scripts rather than being switched to other 
branches, though I suppose a second long-lived checkout that gets updated 
automatically could be used.  If you check things out somewhere else 
temporarily, it's important to be sure the checkout gets deleted 
afterwards rather than having multiple checkouts accumulating.  That's 
especially the case if you use a checkout in /tmp as a single GCC 
repository clone / checkout uses a significant proportion of the free 
space on the root filesystem; /sourceware/snapshot-tmp/gcc has more free 
space for large temporary directories.)

> The second part is git hook that will reject all commits for release and
> master branches.
> that violate ChangeLog format. Right now, strict mode is disabled in the
> hooks.

Note that the present state of having GCC-specific patches to the git 
hooks is supposed to be a temporary one; we want to move to all relevant 
GCC-specific configuration being in refs/meta/config rather than custom 
code, so GCC and sourceware can share a single instance of the hooks which 
in turn can use the same code as in the upstream AdaCore repository, so 
that future updates of the hooks from upstream are easier.  See the issues 
I filed at https://github.com/AdaCore/git-hooks/issues for the existing 
custom GCC changes and the pull request 
https://github.com/AdaCore/git-hooks/pull/12 to bring in implementations 
of many of those features (not sure if it covers everything or not).  So 
it's important to consider how these checks could be implemented without 
needing GCC-specific code directly in these hooks (for example, using the 
new hooks.update-hook mechanism added by one of the commits in that pull 
request, or getting extra features added to the upstream hooks in a 
generic form if necessary).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ChangeLog files - server and client scripts

[Joseph Myers]

On Wed, 13 May 2020, Martin Liška wrote:

> I'm sending the gcc-changelog relates scripts which should be added to contrib
> folder. The patch contains:
> - git_check_commit.py - checking script that verifies git message format

We need a documentation patch to contribute.html or gitwrite.html that 
describes the exact commit message format being used.

> - git_update_version.py - a replacement of
> maintainer-scripts/update_version_git which
> bumps DATESTAMP and generates ChangeLog entries (for now into ChangeLog.test
> files)

Where does this check things out?  (The existing ~gccadmin/gcc-checkout 
isn't suitable for that, it needs to stay on master to have the correct 
version of maintainer-scripts rather than being switched to other 
branches, though I suppose a second long-lived checkout that gets updated 
automatically could be used.  If you check things out somewhere else 
temporarily, it's important to be sure the checkout gets deleted 
afterwards rather than having multiple checkouts accumulating.  That's 
especially the case if you use a checkout in /tmp as a single GCC 
repository clone / checkout uses a significant proportion of the free 
space on the root filesystem; /sourceware/snapshot-tmp/gcc has more free 
space for large temporary directories.)

> The second part is git hook that will reject all commits for release and
> master branches.
> that violate ChangeLog format. Right now, strict mode is disabled in the
> hooks.

Note that the present state of having GCC-specific patches to the git 
hooks is supposed to be a temporary one; we want to move to all relevant 
GCC-specific configuration being in refs/meta/config rather than custom 
code, so GCC and sourceware can share a single instance of the hooks which 
in turn can use the same code as in the upstream AdaCore repository, so 
that future updates of the hooks from upstream are easier.  See the issues 
I filed at https://github.com/AdaCore/git-hooks/issues for the existing 
custom GCC changes and the pull request 
https://github.com/AdaCore/git-hooks/pull/12 to bring in implementations 
of many of those features (not sure if it covers everything or not).  So 
it's important to consider how these checks could be implemented without 
needing GCC-specific code directly in these hooks (for example, using the 
new hooks.update-hook mechanism added by one of the commits in that pull 
request, or getting extra features added to the upstream hooks in a 
generic form if necessary).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH v2 1/2] RISC-V: Add shorten_memrefs pass

[Craig Blackmore]

On 12/05/2020 23:33, Jim Wilson wrote:
> On Mon, Apr 27, 2020 at 10:08 AM Craig Blackmore
>  wrote:
>> Thanks for the review. I have updated the following patch with those changes.
> This looks good, and the tree is open for development work again, so I
> committed both parts 1 and 2 and pushed it.
>
> One weird thing is that while the patch program accepted the patch
> fine, git am would not, and kept giving me an error that didn't make
> any sense, pointing at a line that didn't have any visible problem.
> So I had to commit it by hand and then use git commit --amend to fix
> the authorship before pushing it.  The end result looks OK to me
> though.
>
> Jim

Hi Jim,

Many thanks for your help in reviewing this patch.

I am not sure what happened with git am, thanks for working around it,
the end result looks good to me.

Craig

[Bug c/95108] [9/10/11 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |9.4
 Status|UNCONFIRMED |NEW
Summary|[10/11 Regression] ICE in   |[9/10/11 Regression] ICE in
   |tree_fits_uhwi_p, at|tree_fits_uhwi_p, at
   |tree.c:7292 |tree.c:7292

--- Comment #1 from Jakub Jelinek  ---
Started with r9-6508-g33813f1d703c95d4fc87d16a17f6c834135ab209

[Bug target/95112] New: i386 procedures have prolog endbr32

[akobets at mail dot ru]

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

Bug ID: 95112
   Summary: i386 procedures have prolog endbr32
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akobets at mail dot ru
  Target Milestone: ---

gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu1)

Test file:
===
void test()
{
}
===

Buld:
i686-linux-gnu-gcc -c -fno-PIC -mno-mmx -mno-sse -O2 -fomit-frame-pointer
-ffreestanding -fno-stack-protector --no-exceptions test.c

Result:
i686-linux-gnu-objdump -d test.o

test.o: file format elf32-i386


disassembling section .text:

 :
   0:   f3 0f 1e fb endbr32 
   4:   c3  ret
==
Please help me find way to build clear code.
__attribute__((naked)) do not resolve problem.

Re: dejagnu version update?

[Jonathan Wakely via Gcc]

On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc  wrote:
>
> I've changed the subject to match the 2015, 2017 and 2018 email threads.
>
> On May 13, 2020, at 3:26 AM, Thomas Schwinge  wrote:
> >
> > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > vs. "new") that ought to return identical results, I found that they
> > didn't:
>
> > I have not found any evidence in DejaGnu master branch that this not
> > working would've been a "recent" DejaGnu regression (and then fixed for
> > DejaGnu 1.6) -- so do we have to assume that this never worked as
> > intended back then?
>
> Likely not.
>
> > Per our "Prerequisites for GCC" installation documentation, we currently
> > require DejaGnu 1.4.4.  Advancing that to 1.6 is probably out of
> > question, given that it has "just" been released (four years ago).
>
> :-)  A user that wants full coverage should use 1.6, apparently.

As documented at
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations
anything older than 1.5.3 causes problems for libstdc++ (and probably
the rest of GCC) because the options in --target_board get placed
after the options in dg-options. If the test depends on the options in
dg-options to work properly it might fail. For example, a test that
has { dg-options "-O2" } and fails without optimisation would FAIL if
you use --target_board=unix/-O0 with dejagnu 1.5.


> > As the failure mode with old DejaGnu is "benign" (only causes missing
> > execution testing), we could simply move on, and accept non-reproducible
> > results between different DejaGnu versions?  Kind of lame...  ;-|
>
> An ugly wart to be sure.
>
> So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 6, 
> and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone want 
> to not update dejagnu to require 1.6?

There are still lots of older systems in use for GCC dev, like all the
POWER servers in the compile farm (but I've put a recent dejagnu in
/opt/cfarm on some of them).

> I had previously approved the update to 1.5.3, but no one really wanted it as 
> no one updated the requirement.  Let's have the 1.6 discussion.  I'm not only 
> inclined to up to 1.6, but to actually edit it in this time.

Would the tests actually refuse to run with an older version?

> Anyone strongly against?  Why?

I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.

[Bug c++/95111] New: coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

Bug ID: 95111
   Summary: coroutines use-after-free with lambdas
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

coroutines copy their input to the coroutine frame, so a coroutine like

future f(T x) {
co_await something();
co_return x;
}


will copy x back from the coroutine frame. However, lambdas are passed by
pointer, so something like


[x] () -> future {
co_await something();
co_return x;
}

will fail, it is translated as something like


struct lambda {
T x;
}

future lambda_operator_parens(const lambda* l) {
co_await something();
co_return l->x;
}

Since l is captured by value, *l is dangling and is leaked.


I think the following translation would be more useful:


future lambda_operator_parens_rref(const lambda l) {
co_await something();
co_return l.x;
}

l would be copied by value and would survive copying/moving into the coroutine
frame.

I don't know if the current behavior is mandated by the standard, but if it is,
it seems a serious defect.

[Bug c++/90320] [8/9 Regression] Explicit constructor called implicitly

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Actually, maybe not.  But it's fixed in GCC 10.  I can backport if anyone
thinks it's important.

[Bug go/95061] shared libgo library not found when running the testsuite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:702adbb2fff0cc043f9c4e1af890421cb238cd18

commit r11-362-g702adbb2fff0cc043f9c4e1af890421cb238cd18
Author: Ian Lance Taylor 
Date:   Wed May 13 10:18:45 2020 -0700

libbacktrace: treat EACCESS like ENOENT

libbacktrace/
PR go/95061
* posix.c (backtrace_open): Treat EACCESS like ENOENT.

[PATCH] PR94397 the compiler consider "type is( real(kind(1.)) )" as a syntax error

[Mark Eggleston]

Please find attached a patch for PR94397.

Commit message:

Fortran  : "type is( real(kind(1.)) )" spurious syntax error PR94397

Based on a patch in the comments of the PR. That patch fixed this problem
but caused the test cases for PR93484 to fail. Changed to reduce
initialisation expressions if the expression is not EXPR_VARIABLE and not
EXPR_CONSTANT.

2020-05-13  Steven G. Kargl  
            Mark Eggleston 

gcc/fortran/

    PR fortran/94397
    * match.c (gfc_match_type_spec): New variable ok initialised
    to true. Set ok with the return value of gfc_reduce_init_expr
    called only if the expression is not EXPR_CONSTANT and is not
    EXPR_VARIABLE. Add !ok to the check for type not being integer
    or the rank being greater than zero.

2020-05-13  Mark Eggleston 

gcc/testsuite/

    PR fortran/94397
    * gfortran.dg/pr94397.F90: New test.

The formatting with tabs and date will be corrected prior to commit.

Tested on x86_64 for master, releases/gcc-9, releases/gcc-10 branches. 
OK to commit and backport?


--
https://www.codethink.co.uk/privacy.html

>From 425d05f2e735cf5fd30de2d0edc9d8a0e99b823c Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Wed, 1 Apr 2020 09:52:41 +0100
Subject: [PATCH] Fortran  : "type is( real(kind(1.)) )" spurious syntax error
 PR94397

Based on a patch in the comments of the PR. That patch fixed this problem
but caused the test cases for PR93484 to fail. Changed to reduce
initialisation expressions if the expression is not EXPR_VARIABLE and not
EXPR_CONSTANT.

2020-05-13  Steven G. Kargl  
	Mark Eggleston  

gcc/fortran/

	PR fortran/94397
	* match.c (gfc_match_type_spec): New variable ok initialised
	to true. Set ok with the return value of gfc_reduce_init_expr
	called only if the expression is not EXPR_CONSTANT and is not
	EXPR_VARIABLE. Add !ok to the check for type not being integer
	or the rank being greater than zero.

2020-05-13  Mark Eggleston  

gcc/testsuite/

	PR fortran/94397
	* gfortran.dg/pr94397.F90: New test.
---
 gcc/fortran/match.c   |  5 -
 gcc/testsuite/gfortran.dg/pr94397.F90 | 26 ++
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr94397.F90

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 8ae34a94a95..82d2b5087e5 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -2265,7 +2265,10 @@ found:
 	 a scalar integer initialization-expr and valid kind parameter. */
   if (c == ')')
 	{
-	  if (e->ts.type != BT_INTEGER || e->rank > 0)
+	  bool ok = true;
+	  if (e->expr_type != EXPR_CONSTANT && e->expr_type != EXPR_VARIABLE)
+	ok = gfc_reduce_init_expr (e);
+	  if (!ok || e->ts.type != BT_INTEGER || e->rank > 0)
 	{
 	  gfc_free_expr (e);
 	  return MATCH_NO;
diff --git a/gcc/testsuite/gfortran.dg/pr94397.F90 b/gcc/testsuite/gfortran.dg/pr94397.F90
new file mode 100644
index 000..fda10c1a88b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr94397.F90
@@ -0,0 +1,26 @@
+! { dg-do run }
+!
+
+module m
+  implicit none
+contains
+  function is_real8(a)
+class(*) :: a
+logical :: is_real8
+is_real8 = .false.
+select type(a)
+  type is(real(kind(1.0_8)))
+is_real8 = .true. 
+end select
+  end function is_real8
+end module m
+
+program test
+  use m
+
+  if (is_real8(1.0_4)) stop 1
+  if (.not. is_real8(1.0_8)) stop 2
+#ifdef __GFC_REAL_16__
+  if (is_real8(1.0_16)) stop 3
+#endif
+end program
-- 
2.11.0

Re: [PATCH PR94969]Add unit distant vector to DDR in case of invariant access functions

[Jakub Jelinek via Gcc-patches]

On Wed, May 13, 2020 at 02:00:11PM +0200, Christophe Lyon via Gcc-patches wrote:
> > > 2020-05-11  Bin Cheng  
> > >
> > > PR tree-optimization/94969
> > > * gcc.dg/tree-ssa/pr94969.c: New test.
> 
> The new test fails on arm and aarch64 and probably everywhere:
> gcc.dg/tree-ssa/pr94969.c: dump file does not exist
> UNRESOLVED: gcc.dg/tree-ssa/pr94969.c scan-tree-dump-not Loop 1
> distributed: split to 3 loops "ldist"
> 
> Can you fix this?

Seems a mere swapping of the scan-tree-dump-not args, I've verified the
test passes after this change and fails with older trunk, committed to trunk
as obvious.

2020-05-13  Jakub Jelinek  

PR testsuite/95110
* gcc.dg/tree-ssa/pr94969.c: Swap scan-tree-dump-not arguments.

--- gcc/testsuite/gcc.dg/tree-ssa/pr94969.c.jj  2020-05-13 09:24:36.959012780 
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr94969.c 2020-05-13 19:13:53.664499322 
+0200
@@ -25,4 +25,4 @@ int main()
 __builtin_abort ();
 }
 
-/* { dg-final { scan-tree-dump-not "ldist" "Loop 1 distributed: split to 3 
loops"} } */
+/* { dg-final { scan-tree-dump-not "Loop 1 distributed: split to 3 loops" 
"ldist" } } */

Jakub

libbacktrace patch committed: Treat EACCES like ENOENT

[Ian Lance Taylor via Gcc-patches]

This patch to libbacktrace treats an EACCES error when opening a file
like an ENOENT error.  This case happens when running the libgo
syscall tests as root, when testing various ways of restricting a
child process.  Bootstrapped and ran libbacktrace and Go tests on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian

2020-05-13  Ian Lance Taylor  

PR go/95061
* posix.c (backtrace_open): Treat EACCESS like ENOENT.
diff --git a/libbacktrace/posix.c b/libbacktrace/posix.c
index 356e72b4a3b..a2c88dd8e4a 100644
--- a/libbacktrace/posix.c
+++ b/libbacktrace/posix.c
@@ -67,7 +67,11 @@ backtrace_open (const char *filename, 
backtrace_error_callback error_callback,
   descriptor = open (filename, (int) (O_RDONLY | O_BINARY | O_CLOEXEC));
   if (descriptor < 0)
 {
-  if (does_not_exist != NULL && errno == ENOENT)
+  /* If DOES_NOT_EXIST is not NULL, then don't call ERROR_CALLBACK
+if the file does not exist.  We treat lacking permission to
+open the file as the file not existing; this case arises when
+running the libgo syscall package tests as root.  */
+  if (does_not_exist != NULL && (errno == ENOENT || errno == EACCES))
*does_not_exist = 1;
   else
error_callback (data, filename, errno);

[Bug testsuite/95110] new test case in r11-345 error: gcc.dg/tree-ssa/pr94969.c: dump file does not exist

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:287552950d56be47adb6b6bf2eae2d612233eaec

commit r11-361-g287552950d56be47adb6b6bf2eae2d612233eaec
Author: Jakub Jelinek 
Date:   Wed May 13 19:16:06 2020 +0200

testsuite: Fix up tree-ssa/pr94969.c testcase [PR95110]

2020-05-13  Jakub Jelinek  

PR testsuite/95110
* gcc.dg/tree-ssa/pr94969.c: Swap scan-tree-dump-not arguments.

[PATCH resend] rs6000, pr 94833: fix vec_first_match_index for nulls

[Carl Love via Gcc-patches]

GCC maintainers:

This is a resend of "[PATCH]rs6000, fix vec_first_match_index for
nulls".

Per the received comments the pr number was added to the subject line. 
I also tweaked the message to make it clear that the patch fixed issues
with vectors whose elements contain zeros rather then a zero length
vector.

-
The following patch fixes PR94833, vec_first_match_index does not
function as described in its description.

The builtin does not handle vector elements which are zero correctly. 
The following patch fixes the issue and adds additional test cases to
verify the vec_first_match_index builtin and related builtins work
correctly with elements that are zero.

The patch has been compiled and tested on

  powerpc64le-unknown-linux-gnu (Power 9 LE)

with no regression errors.

Please let me know if the patch is acceptable for mainline and for
backporting as needed.

Thanks.

   Carl Love

--

gcc/ChangeLog

2020-04-30  Carl Love  

PR target/94833
* config/rs6000/vsx.md (define_expand): Fix instruction generation for
first_match_index_.
* testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c (main): Add
additional test cases with zero vector elements.
---
 gcc/config/rs6000/vsx.md  |   4 +-
 .../powerpc/builtins-8-p9-runnable.c  | 118 ++
 2 files changed, 120 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 1fcc1b03096..12a0d5e668c 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -4803,8 +4803,8 @@
   rtx cmp_result = gen_reg_rtx (mode);
   rtx not_result = gen_reg_rtx (mode);
 
-  emit_insn (gen_vcmpnez (cmp_result, operands[1],
-operands[2]));
+  emit_insn (gen_vcmpne (cmp_result, operands[1],
+   operands[2]));
   emit_insn (gen_one_cmpl2 (not_result, cmp_result));
 
   sh = GET_MODE_SIZE (GET_MODE_INNER (mode)) / 2;
diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c 
b/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c
index b2f7dc855e8..19457eebfc4 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c
@@ -103,6 +103,31 @@ int main() {
  The element index in natural element order is returned for the
  first match or the number of elements if there is no match.  */
   /* char */
+  char_src1 = (vector signed char) { 0x40, 0, 0x40, 0x40,
+0x40, 0x40, 0x40, 0x40,
+0x40, 0x40, 0x40, 0x40,
+0x40, 0x40, 0x40, 0x40 };
+   
+  char_src2 = (vector signed char) {0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0, 0, 0, 0, 0, 0, 0};
+  expected_result = 1;
+
+  result = vec_first_match_index (char_src1, char_src2);
+
+#ifdef DEBUG2
+  print_signed_char("src1", char_src1);
+  print_signed_char("src2", char_src2);
+  printf(" vec_first_match_index = %d\n\n", result);
+#endif
+
+  if (result != expected_result)
+#ifdef DEBUG
+printf("Error: char first match result (%d) does not match expected result 
(%d)\n",
+  result, expected_result);
+#else
+abort();
+#endif
+
   char_src1 = (vector signed char) {-1, 2, 3, 4, -5, 6, 7, 8,
9, 10, 11, 12, 13, 14, 15, 16};
   char_src2 = (vector signed char) {-1, 2, 3, 20, -5, 6, 7, 8,
@@ -367,6 +392,50 @@ int main() {
  The element index in BE order is returned for the first mismatch
  or the number of elements if there is no match.   */
   /* char */
+  char_src1 = (vector signed char) {1, 2, 0, 4, -5, 6, 7, 8,
+   9, 10, 11, 12, 13, 14, 15, 16};
+  char_src2 = (vector signed char) {1, 2, 0, 20, -5, 6, 7, 8,
+   9, 10, 11, 12, 13, 14, 15, 16};
+  expected_result = 3;
+
+  result = vec_first_mismatch_index (char_src1, char_src2);
+
+#ifdef DEBUG2
+  print_signed_char("src1", char_src1);
+  print_signed_char("src2", char_src2);
+  printf("vec_first_mismatch_index = %d\n\n", result);
+#endif
+
+  if (result != expected_result)
+#ifdef DEBUG
+printf("Error: char first mismatch result (%d) does not match expected 
result (%d)\n",
+  result, expected_result);
+#else
+abort();
+#endif
+
+  char_src1 = (vector signed char) {0, 2, 3, 4, -5, 6, 7, 8,
+   9, 10, 11, 12, 13, 14, 15, 16};
+  char_src2 = (vector signed char) {0, 2, 3, 20, -5, 6, 7, 8,
+   9, 10, 11, 12, 13, 14, 15, 16};
+  expected_result = 3;
+
+  result = vec_first_mismatch_index (char_src1, char_src2);
+
+#ifdef DEBUG2
+  print_signed_char("src1", char_src1);
+  print_signed_char("src2", char_src2);
+  

[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Confirmed – see PR 94690 comment 10.

[Bug testsuite/95110] New: new test case in r11-345 error: gcc.dg/tree-ssa/pr94969.c: dump file does not exist

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95110
   Summary: new test case in r11-345 error:
gcc.dg/tree-ssa/pr94969.c: dump file does not exist
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:f6e1a4cd83190746b6544917f7526fa480ca5f18, r11-345

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/pr94969.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3
-fdump-tree-ldist-details -lm -o ./pr94969.exe
Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled23126.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -S -o
exceptions_enabled23126.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled23126.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -S -o
exceptions_enabled23126.s
exceptions_enabled23126.c: In function 'foo':
exceptions_enabled23126.c:4:7: error: 'throw' undeclared (first use in this
function)
exceptions_enabled23126.c:4:7: note: each undeclared identifier is reported
only once for each function it appears in
exceptions_enabled23126.c:4:12: error: expected ';' before numeric constant
compiler exited with status 1
PASS: gcc.dg/tree-ssa/pr94969.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test2/gcc::/home/seurer/gcc/git/build/gcc-test2/gcc:/home/seurer/gcc/git/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./isl/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/tree-ssa/pr94969.c execution test
gcc.dg/tree-ssa/pr94969.c: dump file does not exist
UNRESOLVED: gcc.dg/tree-ssa/pr94969.c scan-tree-dump-not Loop 1 distributed:
split to 3 loops "ldist"

Re: back to cvs, cool

[Ian Lance Taylor via Gcc]

On Wed, May 13, 2020 at 9:56 AM Mike Stump via Gcc  wrote:
>
> As seen in recent bug report:
>
>   CVS Commits 2020-05-12 20:40:40 UTC
>
> I guess that git thing was a bust and we're back to using cvs now.  At least 
> Ian did up the remote patches to make cvs work better.

In fairness, I worked on it but it was really Jim Kingdon who did the
bulk of the remote CVS support.

Ian

[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  ---
Created attachment 48522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48522=edit
Patch to add OpenMP 5 feature (private + lastprivate permitted for 'simd')

The patch solves an independent issue, required for the test case below
(namely, the "private(j)").

The *committed* patch causes gfortran.dg/gomp/target1.f90 to FAIL.

The problem shows up with the following test case (reduced but modified):
-
  subroutine foo ()
integer :: s, i, j
!$omp target teams
!$omp distribute parallel do default(shared) &
!$omp collapse (2) private(j) lastprivate (s)
  do i = 1, 10
do j = 1, 10
  s = i * 10 + j
end do
  end do
!$omp end target teams
  end subroutine
-

The problem is that this currently produces (-fdump-tree-original):
  #pragma omp teams private(i) private(j)

Which later causes problems as it doesn't add a  (last)private(i) when it
should 

(Search for "if (outer && lastprivate)" in gimplify_omp_for – and look through
the lines below. As "i" is present, omp_check_private() returns true and a
required omp_add_variable is not called. – Leading later to the ICE.)

That's solved by:

--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -5688,3 +5688,3 @@ gfc_resolve_do_iterator (gfc_code *code, gfc_symbol *sym,
bool add_clause)
   gfc_code *omp_code = omp_current_ctx->code->block;
-  for ( ; omp_code->next; omp_code = omp_code->next)
+  for ( ; omp_code; omp_code = omp_code->next)
switch (omp_code->op)

However, that leads to the odd result that:

  !$omp target teams
!$omp distribute parallel do default(shared) &  ! "do"
!$omp collapse (2) private(j) lastprivate (s)
...
!$omp distribute parallel do simd default(shared) & ! "do simd" (!)
!$omp collapse (2) private(j) lastprivate (s)
...

has "#pragma omp teams" [w/o private(i) private(j)]

While removing the "simd" from the code above leads to no "private(i)
private(j)", which does not make sense.

The code (openmp.c's gfc_do_resolve_do_iterator) is supposed to do:
  /* !$omp do and !$omp parallel do iteration variable is predetermined
 private just in the !$omp do resp. !$omp parallel do construct,
 with no implications for the outer parallel constructs.  */

But here it adds it to 'teams', which looks wrong/inconsistent.

[Bug c++/95003] coroutines: Wrong code for some reference capture cases.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Sandoe  ---
so fixed for master and 10.2

back to cvs, cool

[Mike Stump via Gcc]

As seen in recent bug report:

  CVS Commits 2020-05-12 20:40:40 UTC

I guess that git thing was a bust and we're back to using cvs now.  At least 
Ian did up the remote patches to make cvs work better.

[Bug fortran/95109] New: [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95109
   Summary: [11 regression] ICE in gfortran.dg/gomp/target1.f90
after r11-349
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

git g:f884bef2105d748fd7869cd641cbb4f6b6bb, r11-349
make -k check-gcc RUNTESTFLAGS=gomp.exp=gfortran.dg/gomp/target1.f90

# of unexpected failures2

FAIL: gfortran.dg/gomp/target1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/gomp/target1.f90   -O  (test for excess errors)

FAIL: gfortran.dg/gomp/target1.f90   -O  (test for excess errors)
Excess errors:
during GIMPLE pass: omplower
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/gomp/target1.f90:318:0:
internal compiler error: in lookup_decl_in_outer_ctx, at omp-low.c:3967
0x10a156cb lookup_decl_in_outer_ctx
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:3967
0x10a44a7b lower_send_clauses
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:7290
0x10a44a7b lower_omp_taskreg
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:11295
0x10a2adc7 lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12878
0x10a2adc7 lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a467bb lower_omp_for
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:10564
0x10a2b147 lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12823
0x10a2b147 lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015