[Bug fortran/85566] New: LEN() intrinsic returns zero when given zero-sized array

[urbanjost at comcast dot net]

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

Bug ID: 85566
   Summary: LEN() intrinsic returns zero when given zero-sized
array
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

The following code returns "10,0" instead of "10,20"

 program test_len
 character(len=:), allocatable :: arr(:)
 arr=[ character(len=10)::'A','B']
 write(*,*)len(arr)   ! gets "10", which is what I expect
 arr=[ character(len=20)::]
 write(*,*)len(arr) ! gets "0", but I think it should get "20"
 end program test_len

That is, when passed a zero-length array the LEN(3f) intrinsic appears to
always report a value of zero(0). Even if the array is of zero size it still
has a length defined for the elments, and I believe it should return that,
not zero.

[Bug fortran/85565] New: LEN() intrinsic returns zero when given zero-sized array

[urbanjost at comcast dot net]

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

Bug ID: 85565
   Summary: LEN() intrinsic returns zero when given zero-sized
array
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

The following code returns "10,0" instead of "10,20"

 program test_len
 character(len=:), allocatable :: arr(:)
 arr=[ character(len=10)::'A','B']
 write(*,*)len(arr)   ! gets "10", which is what I expect
 arr=[ character(len=20)::]
 write(*,*)len(arr) ! gets "0", but I think it should get "20"
 end program test_len

That is, when passed a zero-length array the LEN(3f) intrinsic appears to
always report a value of zero(0). Even if the array is of zero size it still
has a length defined for the elments, and I believe it should return that,
not zero.

[Bug c/85564] New: Option "-static" affects the type of generated program

[alinshans at gmail dot com]

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

Bug ID: 85564
   Summary: Option "-static" affects the type of generated program
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alinshans at gmail dot com
  Target Milestone: ---

System: Ubuntu 16.04
GCC version: 7.3.0

For example:

  // main.c
  int main() { return 0; }

Runs the following commands:

  $ gcc main.c -fPIC -pie -nostdlib -emain -static
  $ readelf -h a.out

In the "TYPE" field, GCC 7.3 is "DYN" while GCC 7.1/7.2 is "EXEC". After
removing the option "-static", all of them are "DYN". Does the option "-static"
affect the type of generated program?

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[andysem at mail dot ru]

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

andysem at mail dot ru changed:

   What|Removed |Added

 CC||andysem at mail dot ru

--- Comment #33 from andysem at mail dot ru ---
The r256284 seems to fix the warning for Fortran and I'm seeing the warning in
C/C++ on gcc 7.2. Is the C/C++ compiler also fixed?

[Bug c/85563] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8

[eggert at cs dot ucla.edu]

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

--- Comment #1 from eggert at cs dot ucla.edu ---
Created attachment 44035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44035=edit
sample program illustrating regression

I've gzipped f.i as it is rather large.

[Bug c/85563] New: -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8

[eggert at cs dot ucla.edu]

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

Bug ID: 85563
   Summary: -Wmaybe-uninitialized false alarm regression with
__builtin_unreachable and GCC 8
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

When compiling Emacs with gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20) x86-64
I noticed a regression compared to previous GCC versions, a regression that
causes a false alarm. Briefly, Emacs uses a statement like this:

  ((CONSP (Vframe_list)) ? (void) 0 : __builtin_unreachable ());

to tell Emacs that Vframe_list is a cons (CONSP is inline and side effect
free), and then follows this with a loop:

  for ((tail) = Vframe_list;
   (CONSP (tail) && (frame1 = XCAR (tail), 1));
   tail = XCDR (tail))
 { loop body }

which obviously must initialize frame1. In a later use of frame1, though, GCC
8.0.1 incorrectly complains:

f.i: In function ‘delete_frame’:
f.i:69688:7: warning: ‘frame1’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   do_switch_frame (frame1, 0, 1, builtin_lisp_symbol (0));
   ^~~

where GCC 7 and earlier do not complain. To reproduce the problem, use the
command:

gcc -O2 -S -Wmaybe-uninitialized f.i

on the attached file f.i. Although strictly speaking this isn't a bug since the
"may be used uninitialized" is deliberately wishy-washy, still, it's an
annoyance that I'll have to fiddle with Emacs source to pacify the misguided
compiler here.

[Bug c/85562] New: -Wsuggest-attribute=malloc misleads about "returning normally"

[eggert at cs dot ucla.edu]

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

Bug ID: 85562
   Summary: -Wsuggest-attribute=malloc misleads about "returning
normally"
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

I ran into this problem when compiling Emacs with gcc (GCC) 8.0.1 20180324 (Red
Hat 8.0.1-0.20) x86-64.  When I use this command:

gcc -S -O2 -Wsuggest-attribute=malloc sample.c

to compile the following program:

#include 

void *
xmalloc (size_t n)
{
  if (n == 0)
abort ();
  return malloc (n);
}

the output is:

sample.c: In function ‘xmalloc’:
sample.c:4:1: warning: function might be candidate for attribute ‘malloc’ if it
is known to return normally [-Wsuggest-attribute=malloc]
 xmalloc (size_t n)
 ^~~

The phrase "if it is known to return normally" is misleading and should be
removed from the diagnostic.  Although the phrase is borrowed from similar
diagnostics for pure functions where the phrase is relevant (see GCC bug
51971), whether a function is known to return normally is irrelevant to how the
compiler should optimize the malloc attribute.  The GCC manual does not state
that the malloc attribute should be applied only to functions that return
normally, and GCC's diagnostics should not imply otherwise.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[lucier at math dot purdue.edu]

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

lucier at math dot purdue.edu changed:

   What|Removed |Added

 CC||lucier at math dot purdue.edu

--- Comment #13 from lucier at math dot purdue.edu ---
Is the solution then to remove the -mieee-fp and -mno-ieee-fp options
(especially from the manual) so that credulous users like me don't suffer from
this problem?  (I just got a bug report for the Gambit Scheme system because of
this.)

[Bug fortran/85507] [8/9 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Dominique d'Humieres  ---
*** Bug 85561 has been marked as a duplicate of this bug. ***

[Bug fortran/85561] [9.0 regression] ICE in in gfc_dep_resolver when compiling OpenCoarrays

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
As for pr85507 the ICE is gone if I revert the change in dependency.c from
r259385. Marking as duplicate.

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

[Bug fortran/85507] [8/9 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> The change occurred between revisions r259378 (2018-04-13, OK) and r259540
> (2018-04-21), likely r259385.

The ICE is gone if I revert the change in dependency.c from r259385.

[Bug fortran/85561] [9.0 regression] ICE in in gfc_dep_resolver when compiling OpenCoarrays

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-28
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Likely a duplicate of pr85507.

[Bug fortran/85561] [9.0 regression] ICE in in gfc_dep_resolver when compiling OpenCoarrays

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
One more addition: I was using mpich-3.2, which compiled without error and also
fulfilled its complete test suite.

[Bug fortran/85561] [9.0 regression] ICE in in gfc_dep_resolver when compiling OpenCoarrays

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
I just started playing around with OpenCoarrays. Not sure whether I should also
report this to the OpenCoarrays team.

[Bug fortran/85561] New: [9.0 regression] ICE in in gfc_dep_resolver when compiling OpenCoarrays

[juergen.reuter at desy dot de]

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

Bug ID: 85561
   Summary: [9.0 regression] ICE in in gfc_dep_resolver when
compiling OpenCoarrays
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

When compiling OpenCoarrays 2.0.0 I get the following ICE:
cd
/usr/local/packages/OpenCoarrays-2.0.0/_build/src/tests/integration/dist_transpose
&& ../../../../bin/caf -I /usr/local/include -DPREFIX_NAME=_gfortran_caf_
-DGCC_GE_7 -DGCC_GE_8 -DHAVE_MPI -O3 -DNDEBUG -O3 -o
/usr/local/packages/OpenCoarrays-2.0.0/_build/bin/OpenCoarrays-2.0.0-tests/coarray_distributed_transpose
/usr/local/packages/OpenCoarrays-2.0.0/src/tests/integration/dist_transpose/coarray_distributed_transpose.F90
/usr/local/packages/OpenCoarrays-2.0.0/src/tests/integration/dist_transpose/coarray_distributed_transpose.F90:57:0:

 do i = 2, num_nodes;variable[i] = variable;  end do

internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2258
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.

Using the official version OpenCoarrays 2.0.0 with the actual 9.0 trunk
r259698. I recently compiled it with 8.0.1 r258195 and it was still working.

[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

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

--- Comment #9 from Aurelien Jarno  ---
(In reply to Jim Wilson from comment #8)
> (In reply to Aurelien Jarno from comment #7)
> > Should I just close this bug and open a new one on the glibc side?
> 
> That is fine if you want to do that.

As this actually a GNU libc bug, I have opened the following bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=23125

[Bug fortran/25829] [F03] Asynchronous IO support

[jvdelisle at gcc dot gnu.org]

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

--- Comment #39 from Jerry DeLisle  ---
Per definition in ioparm.def in frontend:

IOPARM (wait,id,1 << 7,  pint4)

id should be a pointer to an integer kind=4.

This means:

>  typedef struct
>  {
>st_parameter_common common;
>GFC_IO_INT id;
>  }
>  st_parameter_wait;

should be:

 typedef struct
 {
   st_parameter_common common;
   GFC_INTEGER_4 *id;
 }
 st_parameter_wait;

[Bug c++/85555] Use of concepts gives access to private members.

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #1 from Casey Carter  ---
Duplicate of 67225 and/or 78715.

[Bug fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.

[vehre at gcc dot gnu.org]

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

--- Comment #7 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sat Apr 28 14:54:09 2018
New Revision: 259741

URL: https://gcc.gnu.org/viewcvs?rev=259741=gcc=rev
Log:
gcc/fortran/ChangeLog:

2018-04-28  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
Backport from trunk
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation.  They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.

gcc/testsuite/ChangeLog:

2018-04-28  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
Backport from trunk
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.


Added:
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/coarray/get_to_indexed_array_1.f90
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/coarray/get_to_indirect_array.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/dependency.c
branches/gcc-6-branch/gcc/fortran/trans-array.c
branches/gcc-6-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/83606] [6/7/8 Regression] co-indexed array RHS yields incorrect result in assignment to vector-indexed LHS

[vehre at gcc dot gnu.org]

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

--- Comment #9 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sat Apr 28 14:54:20 2018
New Revision: 259742

URL: https://gcc.gnu.org/viewcvs?rev=259742=gcc=rev
Log:
gcc/fortran/ChangeLog:

2018-04-28  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
Backport from trunk
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation.  They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.

gcc/testsuite/ChangeLog:

2018-04-28  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
Backport from trunk
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.


Added:
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/get_to_indexed_array_1.f90
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/get_to_indirect_array.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/dependency.c
branches/gcc-7-branch/gcc/fortran/trans-array.c
branches/gcc-7-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/83606] [6/7/8 Regression] co-indexed array RHS yields incorrect result in assignment to vector-indexed LHS

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sat Apr 28 14:54:09 2018
New Revision: 259741

URL: https://gcc.gnu.org/viewcvs?rev=259741=gcc=rev
Log:
gcc/fortran/ChangeLog:

2018-04-28  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
Backport from trunk
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation.  They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.

gcc/testsuite/ChangeLog:

2018-04-28  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
Backport from trunk
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.


Added:
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/coarray/get_to_indexed_array_1.f90
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/coarray/get_to_indirect_array.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/dependency.c
branches/gcc-6-branch/gcc/fortran/trans-array.c
branches/gcc-6-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sat Apr 28 14:54:20 2018
New Revision: 259742

URL: https://gcc.gnu.org/viewcvs?rev=259742=gcc=rev
Log:
gcc/fortran/ChangeLog:

2018-04-28  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
Backport from trunk
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation.  They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.

gcc/testsuite/ChangeLog:

2018-04-28  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
Backport from trunk
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.


Added:
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/get_to_indexed_array_1.f90
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/get_to_indirect_array.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/dependency.c
branches/gcc-7-branch/gcc/fortran/trans-array.c
branches/gcc-7-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/25829] [F03] Asynchronous IO support

[jvdelisle at gcc dot gnu.org]

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

--- Comment #38 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #37)
> (In reply to Nicolas Koenig from comment #36)
> > so some adjustment of
> > 
> > typedef struct
> > {
> >   st_parameter_common common;
> >   CHARACTER1 (id);
> > }
> > st_parameter_wait;
> > 
> > is probably required.
> 
> If id is not a string, so should be:
> 
>  typedef struct
>  {
>st_parameter_common common;
>GFC_IO_INT id;
>  }
>  st_parameter_wait;

The funky cast of int 8 to an integer 4 in the front end is odd. I wonder if it
is related to patches to try to get -fdefault-integer-8 to work. It looks
horrible.

[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor

[wilson at gcc dot gnu.org]

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

--- Comment #8 from Jim Wilson  ---
(In reply to Aurelien Jarno from comment #7)
> Should I just close this bug and open a new one on the glibc side?

That is fine if you want to do that.

> +   /* Mark ra as undefined in order to stop unwinding here!  */
> +   cfi_undefined (ra)

I tried this, and it worked for me.

[Bug fortran/25829] [F03] Asynchronous IO support

[jvdelisle at gcc dot gnu.org]

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

--- Comment #37 from Jerry DeLisle  ---
(In reply to Nicolas Koenig from comment #36)
> so some adjustment of
> 
> typedef struct
> {
>   st_parameter_common common;
>   CHARACTER1 (id);
> }
> st_parameter_wait;
> 
> is probably required.

If id is not a string, so should be:

 typedef struct
 {
   st_parameter_common common;
   GFC_IO_INT id;
 }
 st_parameter_wait;

[Bug rtl-optimization/85560] New: Missed optimization in bit-by-bit variable zeroing

[vlad at ivanov dot email]

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

Bug ID: 85560
   Summary: Missed optimization in bit-by-bit variable zeroing
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vlad at ivanov dot email
  Target Milestone: ---

The following C++ code loops until a variable is cleared bit-by-bit:

#include 

uint32_t b;
uint32_t test() {
uint32_t a = b;
uint32_t bits = 1;

while (a != 0) {
a &= ~bits;
bits <<= 1;
}

return 0;
}

After looping, it returns 0. While the loop is useless, it still exists in the
assembly even with -O3.

GCC version: 9.0.0 20180427 
Demo: https://godbolt.org/g/7gRMqu

Notably, the loop is optimized away on ICC 18

[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
(In reply to Jim Wilson from comment #3)
Thanks a lot Jim for finding out the issue without using gdb, that was quite a
challenge.

(In reply to Jim Wilson from comment #6)
> I suggest you handle the glibc patch.

Should I just close this bug and open a new one on the glibc side?

> Note that you can probably also fix this by adding unwind direcives to
> _start to say that the return address is in x0.  This would avoid the minor
> code size increase, but takes a little more effort to figure out how to add
> the right unwind directives to assembly code to make this work.  I haven't
> tried that.

I think this should be done with the cfi_undefined directive, like in the patch
below:

--- a/sysdeps/riscv/start.S
+++ b/sysdeps/riscv/start.S
@@ -43,6 +43,8 @@
__libc_start_main wants this in a5.  */

 ENTRY (ENTRY_POINT)
+   /* Mark ra as undefined in order to stop unwinding here!  */
+   cfi_undefined (ra)
call  .Lload_gp
mva5, a0  /* rtld_fini.  */
/* main may be in a shared library.  */

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

--- Comment #36 from Nicolas Koenig  ---
There seems to be a mismatch between the front end and the library.

For

program main
  integer :: id
  character(len=50) :: iomsg
  integer :: iostat
  id = 0
  open(10,file="wait.dat",iostat=iostat,iomsg=iomsg, asynchronous="yes")
  wait (10,id=id)
end program main

the front end generates

struct __st_parameter_wait wait_parm.1;

wait_parm.1.common.filename = &"wait.f90"[1]{lb: 1 sz: 1};
wait_parm.1.common.line = 7;
wait_parm.1.id = (integer(kind=4) *) (integer(kind=8)) id;
wait_parm.1.common.flags = 128;
wait_parm.1.common.unit = 10;
_gfortran_st_wait (_parm.1);

where the type conversions are strange. The library then receives

(gdb) p *wtp
$1 = {common = {flags = 128, unit = 10, filename = 0x428d70 "wait.f90", line =
7, iomsg_len = 50, iomsg = 0x7fffdc90 "\377\377\377\377", 
iostat = 0x7fffdc8c}, id = 0x0, id_len = 8}

so some adjustment of

typedef struct
{
  st_parameter_common common;
  CHARACTER1 (id);
}
st_parameter_wait;

is probably required.

[Bug middle-end/85559] New: [meta-bug] Improve conditional move

[hjl.tools at gmail dot com]

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

Bug ID: 85559
   Summary: [meta-bug] Improve conditional move
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: meta-bug
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
Depends on: 22568, 29144, 46279, 56309, 65492, 78947, 80520,
80874, 81456, 82666, 82858, 83610, 85390
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

cmov generation should be improved.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
[Bug 22568] Should use cmov in some stituations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29144
[Bug 29144] Missing if-conversion. If-conversion dependent on operand order.
Inconsistent if-conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46279
[Bug 46279] cmov not hoisted out of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309
[Bug 56309] conditional moves instead of compare and branch result in almost 2x
slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
[Bug 65492] Bad optimization in -O3 due to if-conversion and/or unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78947
[Bug 78947] sub-optimal code for (bool)(int ? int : int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80520
[Bug 80520] [7/8/9 Regression] Performance regression from missing
if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80874
[Bug 80874] gcc does not emit cmov for minmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456
[Bug 81456] [7/8/9 Regression] x86-64 optimizer makes wrong decision when
optimizing for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666
[Bug 82666] [7/8/9 regression]: sum += (x>128/9 ? x : 0) puts the cmov on the
critical path (at -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858
[Bug 82858] __builtin_add_overflow() generates suboptimal code with unsigned
types on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83610
[Bug 83610] __builtin_expect sometimes is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85390
[Bug 85390] possible missed optimisation / regression from 6.3 with conditional
expression

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #43877|0   |1
is obsolete||

--- Comment #35 from Nicolas Koenig  ---
Created attachment 44034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44034=edit
Concept patch (works with read and simple wait for integers)

[Bug c++/85558] New: ICE in make_rtl_for_nonlocal_decl when using static member of template class

[xaizek at posteo dot net]

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

Bug ID: 85558
   Summary: ICE in make_rtl_for_nonlocal_decl when using static
member of template class
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xaizek at posteo dot net
  Target Milestone: ---

Source code to reproduce the ICE


// no ICE if triggerBug is not a template
template 
struct triggerBug {
// no ICE if order of these two lines is swapped
friend void doInitUser(bool = triggerBug::doInit);
static bool doInit;
};

template 
bool triggerBug::doInit = true;

triggerBug bug;

Command line and error message
==

$ g++-trunk gcc-bug.cpp -c -o /dev/null
gcc-bug.cpp: In instantiation of ‘struct triggerBug’:
gcc-bug.cpp:12:17:   required from here
gcc-bug.cpp:10:6: internal compiler error: in make_rtl_for_nonlocal_decl, at
cp/decl.c:6587
 bool triggerBug::doInit = true;
  ^
0x702c4a make_rtl_for_nonlocal_decl
../../gcc/cp/decl.c:6585
0x73211c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7243
0x8638f0 instantiate_class_template_1
../../gcc/cp/pt.c:11174
0x8638f0 instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:11398
0x8be552 complete_type(tree_node*)
../../gcc/cp/typeck.c:136
0x7071e7 start_decl_1(tree_node*, bool)
../../gcc/cp/decl.c:5278
0x72ce17 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5241
0x7ed93f cp_parser_init_declarator
../../gcc/cp/parser.c:19620
0x7ef8d9 cp_parser_simple_declaration
../../gcc/cp/parser.c:13063
0x7f07d8 cp_parser_block_declaration
../../gcc/cp/parser.c:12875
0x7fc394 cp_parser_declaration
../../gcc/cp/parser.c:12772
0x7fad96 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12648
0x7fb0a3 cp_parser_translation_unit
../../gcc/cp/parser.c:4563
0x7fb0a3 c_parse_file()
../../gcc/cp/parser.c:39045
0x943bc5 c_common_parse_file()
../../gcc/c-family/c-opts.c:1132

Compiler version


Same results locally on 5.5.0, 7.3.0, trunk (git:
2e7e8f549a4c4c5885e4f7f5a4271f3610b54c3a, svn: 259739), and looks like any
version since 4.4 on compiler explorer (4.1 says `incomplete type
'triggerBug' used in nested name specifier`). So I'm not providing
compiler flags or system details as this probably affects pretty much anything
in use today.

[Bug c++/85557] New: Incorrect calculation of function arguments with C++17 sequencing rules

[ixsci at yandex dot ru]

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

Bug ID: 85557
   Summary: Incorrect calculation of function arguments with C++17
sequencing rules
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ixsci at yandex dot ru
  Target Milestone: ---

Given the following simple code:

#include 
using namespace std;

int foo(int first, int second)
{
return first << second;
}

int main()
{
int i = 0;
cout << "Result: " << foo(i = 1, i = 2) << "\n";
};

The latest GCC (9.0 tested on Wandbox) with -std=c++17 produces the following
output: "Result: 2" but it should produce "Result: 4" because function
parameters calculations are indeterminately sequenced between each other.

[Bug sanitizer/85556] New: attribute no_sanitize does not accept multiple options as documented

[doko at gcc dot gnu.org]

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

Bug ID: 85556
   Summary: attribute no_sanitize does not accept multiple options
as documented
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/891489]

In
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-no_005fsanitize-function-attribute
gcc 8.0.1 claims to add a no_sanitize attribute which works the same as
the clang one does.

In practice however it doesn't, and it currently will only accept a
single option.  The example given above is:

  $ cat nosan.c
  void __attribute__ ((no_sanitize ("alignment", "object-size")))
  f () { /* Do something. */; }

  int main(void) { return 0; }


Which results in:

  $ gcc-8 nosan.c 
  nosan.c:3:1: error: wrong number of arguments specified for ‘no_sanitize’
attribute
   f () { /* Do something. */; }
   ^


It would be really nice if that did work as documented, to avoid having
to special case this in user code even more than we already do.

[Bug c++/85533] Missing optimization for right-shift of unsigned int (avr-g++)

[randy.brecker64 at gmail dot com]

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

Randy Brecker  changed:

   What|Removed |Added

 Target|avr |x86 avr
 Status|RESOLVED|VERIFIED
Version|7.3.0   |8.0.1

--- Comment #3 from Randy Brecker  ---
This is also true von x86_64, where we get:

   movzbl  x(%rip), %eax
sarl%eax
movb%al, x(%rip)
movzbl  y(%rip), %eax
shrb%al
movb%al, y(%rip)
xorl%eax, %eax

Looks like a FE bug here.

[Bug c++/82658] Suboptimal codegen on AVR when right-shifting 8-bit unsigned integers.

[randy.brecker64 at gmail dot com]

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

--- Comment #5 from Randy Brecker  ---
I confirm this is still true for x86 (!) with gcc-7.3.1 and gcc-8.0.1 in
language-mode c++.

[Bug c++/85555] Use of concepts gives access to private members.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-28
 Ever confirmed|0   |1

[Bug c++/85555] New: Use of concepts gives access to private members.

[tobias.bruell at gmail dot com]

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

Bug ID: 8
   Summary: Use of concepts gives access to private members.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tobias.bruell at gmail dot com
  Target Milestone: ---

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

In the following condensed example the unrelated use of concepts seems to be
giving access to the private non-static member functions of a class.

Compile with:
g++-7.3 -std=c++17 -fconcepts gcc_bug.cpp



/*
 * Uncommenting the following line and commenting the line after that
 * makes the program fail to compile (as it should).
 */
//template
template
concept bool has_resize ()
{
  return requires (Target tgt)
  {
{ tgt.resize () };
  };
};

template
void resize (Target tgt)
{
  if constexpr (has_resize ())
  {
tgt.resize ();
  }
}

class MyClass
{
  private:
int foo (int i)
{
  return i * 2;
}
};

int main ()
{
  return MyClass {}.foo (7);
}

[Bug target/84431] Suboptimal code for masked shifts (x86/x86-64)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #8 from Uroš Bizjak  ---
Fixed.

[Bug target/84431] Suboptimal code for masked shifts (x86/x86-64)

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Apr 28 07:37:04 2018
New Revision: 259739

URL: https://gcc.gnu.org/viewcvs?rev=259739=gcc=rev
Log:
PR target/84431
* config/i386/i386.md (*ashl3_doubleword_mask): New pattern.
(*ashl3_doubleword_mask_1): Ditto.
(*3_doubleword_mask): Ditto.
(*3_doubleword_mask_1): Ditto.

testsuite/ChangeLog:

PR target/84431
* gcc.target/i386/pr84431.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr84431.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog