[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
Can someone please test the patch in Comment #9 on powerpc? It should fix all
failures, modulo ieee_10.f90 which is fixed by [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01685.html

[Bug c/89061] [9 Regression] GCC 9 introduces false positive in -Wjump-misses-init

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/89105] -Wabi warns for functions with internal linkage

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/89105] -Wabi warns for functions with internal linkage

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 30 07:51:24 2019
New Revision: 268382

URL: https://gcc.gnu.org/viewcvs?rev=268382=gcc=rev
Log:
PR c++/89105
* config/i386/i386.c (ix86_warn_parameter_passing_abi): Don't warn
for arguments to functions that are TU-local and shouldn't be
referenced by assembly.

* g++.target/i386/pr89105.C: New test.

Added:
trunk/gcc/testsuite/g++.target/i386/pr89105.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c/89061] [9 Regression] GCC 9 introduces false positive in -Wjump-misses-init

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 30 07:49:58 2019
New Revision: 268381

URL: https://gcc.gnu.org/viewcvs?rev=268381=gcc=rev
Log:
PR c/89061
* c-tree.h (C_DECL_COMPOUND_LITERAL_P): Define.
* c-decl.c (decl_jump_unsafe): Return false for
C_DECL_COMPOUND_LITERAL_P decls.
(build_compound_literal): Set C_DECL_COMPOUND_LITERAL_P.

* gcc.dg/pr89061.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr89061.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-tree.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
Created attachment 45564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45564=edit
Proposed patch

This patch fixes all ieee.exp failures in x86 when configured with fpu-glibc.h.

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
This PR is probably fixed by [1]. It looks that on powerpc feenableexcept fires
exception on stalled exception flags (these were raised when certain exception
was disabled).

Other than that, exception may fire in ieee_procedure_exit, where we enable
state we had on entry (that may have enabled various exceptions), and directly
re-raise possibly stalled exceptions.

Both these issues can be solved by clearing stalled interrupts in
set_fpu_trap_exceptions. This is the solution we have in fpu-387.h.

[1] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01685.html

[Bug c/89113] Missed stack reuse opportunity when using compound literals

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
That seems already fixed in gcc-9.

[Bug c/89113] Missed stack reuse opportunity when using compound literals

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The question becomes what is the scope for the compound literal?

[Bug c/89113] New: Missed stack reuse opportunity when using compound literals

[patrick at motec dot com.au]

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

Bug ID: 89113
   Summary: Missed stack reuse opportunity when using compound
literals
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at motec dot com.au
  Target Milestone: ---

It appears as though gcc is missing a stack reuse opportunity when using
compound literals.

Consider the following example:

void f(int *);

void test1(void)
{
{
f((int []){1, 2, 3, 4});
}
{
f((int []){1, 2, 3, 4});
}
}

void test2(void)
{
{
int tmp[] = {1, 2, 3, 4};
f(tmp);
}
{
int tmp[] = {1, 2, 3, 4};
f(tmp);
}
}

The lifetimes of the compound literals in test1 should be equivalent to the
lifetimes of the tmp arrays in test2.

When compiling with gcc 8.2.1 only test2 reuses the stack locations for the
temporaries making test1 stack use higher:

% gcc -c test.c
% objdump -d test.o

 :
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   48 83 ec 30 sub$0x30,%rsp
   8:   64 48 8b 04 25 28 00mov%fs:0x28,%rax
   f:   00 00
  11:   48 89 45 f8 mov%rax,-0x8(%rbp)
  15:   31 c0   xor%eax,%eax
  17:   c7 45 d0 01 00 00 00movl   $0x1,-0x30(%rbp)
  1e:   c7 45 d4 02 00 00 00movl   $0x2,-0x2c(%rbp)
  25:   c7 45 d8 03 00 00 00movl   $0x3,-0x28(%rbp)
  2c:   c7 45 dc 04 00 00 00movl   $0x4,-0x24(%rbp)
  33:   48 8d 45 d0 lea-0x30(%rbp),%rax
  37:   48 89 c7mov%rax,%rdi
  3a:   e8 00 00 00 00  callq  3f 
  3f:   c7 45 e0 01 00 00 00movl   $0x1,-0x20(%rbp)
  46:   c7 45 e4 02 00 00 00movl   $0x2,-0x1c(%rbp)
  4d:   c7 45 e8 03 00 00 00movl   $0x3,-0x18(%rbp)
  54:   c7 45 ec 04 00 00 00movl   $0x4,-0x14(%rbp)
  5b:   48 8d 45 e0 lea-0x20(%rbp),%rax
  5f:   48 89 c7mov%rax,%rdi
  62:   e8 00 00 00 00  callq  67 
  67:   90  nop
  68:   48 8b 45 f8 mov-0x8(%rbp),%rax
  6c:   64 48 33 04 25 28 00xor%fs:0x28,%rax
  73:   00 00
  75:   74 05   je 7c 
  77:   e8 00 00 00 00  callq  7c 
  7c:   c9  leaveq
  7d:   c3  retq

007e :
  7e:   55  push   %rbp
  7f:   48 89 e5mov%rsp,%rbp
  82:   48 83 ec 20 sub$0x20,%rsp
  86:   64 48 8b 04 25 28 00mov%fs:0x28,%rax
  8d:   00 00
  8f:   48 89 45 f8 mov%rax,-0x8(%rbp)
  93:   31 c0   xor%eax,%eax
  95:   c7 45 e0 01 00 00 00movl   $0x1,-0x20(%rbp)
  9c:   c7 45 e4 02 00 00 00movl   $0x2,-0x1c(%rbp)
  a3:   c7 45 e8 03 00 00 00movl   $0x3,-0x18(%rbp)
  aa:   c7 45 ec 04 00 00 00movl   $0x4,-0x14(%rbp)
  b1:   48 8d 45 e0 lea-0x20(%rbp),%rax
  b5:   48 89 c7mov%rax,%rdi
  b8:   e8 00 00 00 00  callq  bd 
  bd:   c7 45 e0 01 00 00 00movl   $0x1,-0x20(%rbp)
  c4:   c7 45 e4 02 00 00 00movl   $0x2,-0x1c(%rbp)
  cb:   c7 45 e8 03 00 00 00movl   $0x3,-0x18(%rbp)
  d2:   c7 45 ec 04 00 00 00movl   $0x4,-0x14(%rbp)
  d9:   48 8d 45 e0 lea-0x20(%rbp),%rax
  dd:   48 89 c7mov%rax,%rdi
  e0:   e8 00 00 00 00  callq  e5 
  e5:   90  nop
  e6:   48 8b 45 f8 mov-0x8(%rbp),%rax
  ea:   64 48 33 04 25 28 00xor%fs:0x28,%rax
  f1:   00 00
  f3:   74 05   je fa 
  f5:   e8 00 00 00 00  callq  fa 
  fa:   c9  leaveq
  fb:   c3  retq

[Bug target/89112] Incorrect code generated by rs6000 memcmp expansion

[samuel at sholland dot org]

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

--- Comment #1 from Samuel Holland  ---
Created attachment 45563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45563=edit
Output of gcc -v

[Bug target/89112] New: Incorrect code generated by rs6000 memcmp expansion

[samuel at sholland dot org]

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

Bug ID: 89112
   Summary: Incorrect code generated by rs6000 memcmp expansion
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: samuel at sholland dot org
  Target Milestone: ---

Created attachment 45562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45562=edit
Slightly simplified reproducer -- derived from Net::SSLeay constants.c

In a function with a large number of calls to memcmp(), incorrect code is
generated for some comparisons larger than 32 bytes. This incorrect code causes
the comparison to erroneously fail or to crash. It appears that part of the
generated comparison loop is merged between different calls to memcmp() -- I
don't know if this is part of the problem.

I've simplified the code a bit and attached the `reproducer.i` and `log`
generated with the following command:

gcc -v -save-temps reproducer.c -O2 &>log

Here is the relevant assembly for the length == 33 switch case:

:  li  r9,2
:  addis   r6,r2,-2
:  li  r10,0
:  li  r8,8
:  mtctr   r9
:  addir6,r6,-12152
:  ldx r9,r3,r10
:  ldx r7,r6,r10
:  ldx r4,r3,r8
:  ldx r5,r6,r8
:  addir10,r10,16
:  addir8,r8,16
:  cmpld   cr7,r9,r7
:  bne cr7,0x37c6760c 
:  b   0x37c72110 
:  setbr9,cr7
:  cmpwi   cr7,r9,0
:  bne cr7,0x37c6761c 
:  b   0x37c72104 
:  mflrr0
:  std r0,48(r1)
:  b   0x37c67300 
...
: cmpld   cr7,r4,r5
: bdz 0x37c72120 
: beq cr7,0x37c72120 
: b   0x37c72124 
: b   0x37c675e8 
: beq cr7,0x37c7212c 
: b   0x37c6760c 
: add r3,r3,r10
: add r10,r6,r10
: addir9,r3,-7
: addir10,r10,-7
: ld  r9,0(r9)
: ld  r10,0(r10)
: cmpld   cr7,r9,r10
: b   0x37c6760c 

Note that in the case where the bdz is taken, because we've reached the end of
the 16-byte comparison loop (here, after comparing 32 of the 33 bytes), it goes
back and compares another 16 bytes!

If I compile this file with -mblock-compare-inline-loop-limit=32 or some lower
value, I get the expected results (the comparisons all succeed).

If I compile the file with -O1 or lower, it also succeeds. I assume this is
because the memcmp expansion is not enabled at those optimization levels.

This was noticed as 8 failures in the NET:SSLeay test suite, files
t/local/20_autoload.t and t/local/21_constants.t (two of the failures being
related to the OCSP_RESPONSE_* constants in the simplified code attached). The
test suite passes with -mblock-compare-inline-loop-limit=32 or lower.

[Bug c/79010] -Wlarger-than ineffective for VLAs, alloca, malloc

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> 
> 
> Alloca and VLA sizes are controlled by the -Walloca-larger-than= and
> -Wvla-larger-than= options (new in GCC 7).  If it's thought to be useful to
> exclude them from -Wlarger-than= the manual should be updated to make that
> clear.
> 

Does EnabledBy() pass along numeric arguments passed to the option that enables
the enabled option?

[Bug c/39985] Type qualifiers not actually ignored on function return type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||gcc at magfr dot 
user.lysator.liu.
   ||se, joseph at codesourcery dot 
com

--- Comment #6 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #5)
> In C, in C11 mode, type qualifiers are completely ignored on function 
> return types, including not affecting type compatibility, after my commit:
> 
> r236231 | jsm28 | 2016-05-13 21:35:39 + (Fri, 13 May 2016) | 46 lines
> 
> Implement C11 DR#423 resolution (ignore function return type qualifiers).

So can this be closed then?

[Bug c/88956] [9 Regression] ICE: Floating point exception on a memcpy from an zero-length constant array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Patch committed in r268378.

[Bug c/88956] [9 Regression] ICE: Floating point exception on a memcpy from an zero-length constant array

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Wed Jan 30 03:04:14 2019
New Revision: 268378

URL: https://gcc.gnu.org/viewcvs?rev=268378=gcc=rev
Log:
PR middle-end/88956 - ICE: Floating point exception on a memcpy from
a zero-length constant array

gcc/ChangeLog:

PR c/88956
* gimple-fold.c (fold_array_ctor_reference): Avoid zero-length arrays.

gcc/testsuite/ChangeLog:

PR c/88956
* gcc.dg/Warray-bounds-39.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-39.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88752] [8/9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/88761] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/86943] [7/8 Regression] Wrong code when converting stateless generic lambda to function pointer

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] Wrong|[7/8 Regression] Wrong code
   |code when converting|when converting stateless
   |stateless generic lambda to |generic lambda to function
   |function pointer|pointer
  Known to fail|9.0 |

--- Comment #13 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/86943] [7/8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Wed Jan 30 02:43:04 2019
New Revision: 268377

URL: https://gcc.gnu.org/viewcvs?rev=268377=gcc=rev
Log:
PR c++/86943 - wrong code converting lambda to function pointer.

In this PR, instantiating the static thunk returned from the generic lambda
conversion function template was using normal overload resolution, which
meant calling an extra constructor when forwarding its argument.  Fixed by
special-casing thunk calls significantly more.

* lambda.c (maybe_add_lambda_conv_op): Use a template-id in the
call.  Only forward parms for decltype.
* pt.c (tsubst_copy_and_build) [CALL_EXPR]: Handle CALL_FROM_THUNK_P
specially.
* typeck.c (check_return_expr): Don't mess with a thunk call.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c

[Bug c++/86218] [9 Regression] ICE in compare_ics, at cp/call.c:9769

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
mine

[Bug testsuite/89110] r268343 breaks several tests in c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed.

[Bug testsuite/89110] r268343 breaks several tests in c++2a

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan 30 02:32:33 2019
New Revision: 268376

URL: https://gcc.gnu.org/viewcvs?rev=268376=gcc=rev
Log:
PR testsuite/89110
* g++.dg/other/nontype-1.C: Expect error in all modes.
* g++.dg/parse/crash13.C: Likewise.
* g++.dg/parse/error36.C: Likewise.
* g++.dg/template/error29.C: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/nontype-1.C
trunk/gcc/testsuite/g++.dg/parse/crash13.C
trunk/gcc/testsuite/g++.dg/parse/error36.C
trunk/gcc/testsuite/g++.dg/template/error29.C

[Bug c++/87996] [8/9 Regression] "size of array is negative" error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
  Known to work||7.3.0
  Known to fail||8.2.0, 9.0

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01702.html

[Bug c++/80864] [7/8/9 Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #8 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01700.html

[Bug testsuite/89110] r268343 breaks several tests in c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/88850] [9 Regression] Hard register coming out of expand causing reload to fail.

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #8 from Alexandre Oliva  ---
AFAICT Christina is working on it, so I'm changing the bug status so that this
becomes apparent in bug lists

[Bug tree-optimization/89111] New: wrong code at -O1 and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 89111
   Summary: wrong code at -O1 and above on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression.

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190129 (experimental) [trunk revision 268359] (GCC)
$
$ gcctk -O0 small.c; ./a.out
0
0
0
0
0
0
0
0
0
$ gcctk -O1 small.c; ./a.out
0
0
0
0
255
0
0
0
0
$


---


int printf (const char *, ...);

#pragma pack(1)
struct A
{ 
  int b:24;
} c[243], f;

int d, e, g, j;

int main ()
{ 
  struct A h = f;
  h.b = 0;
  while (e++ < 3)
{ 
  while (d++ < 3)
c[46].b ^= 9890739;
  f = c[46] = h;
}
  while (g++ < 9)
j = printf ("%d\n", c[g * 9 + j].b);
  return 0;
}

[Bug other/89106] cast-to-union documentation incorrect w.r.t. lvalueness

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
It does look seem the change went a step too far in describing the feature's
similarity to compound literals.  It probably should have been limited to
removing the mention of a constructor and correcting the part about normal
casts yielding an lvalue.  I.e., it should have replaced the sentence

  A cast to union is actually a constructor, not a cast, and hence does not
yield an lvalue like normal casts. 

with one like:

  A cast to a union creates a compound literal but yields an rvalue like
standard casts do.

How does that look?

(I suspect the part about a constructor in the original text might have been a
reference to GCC's internal representation of the cast as a CONSTRUCTOR and
didn't have anything to do with C++ constructors because those do yield
lvalues.)

[Bug fortran/57048] [7/8/9 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan 29 22:40:26 2019
New Revision: 268372

URL: https://gcc.gnu.org/viewcvs?rev=268372=gcc=rev
Log:
2019-01-29  Thomas Koenig  

PR fortran/57048
* interface.c (gfc_compare_types): If a derived type and an
integer both have a derived type, and they are identical,
this is a C binding type and compares equal.

2019-01-29  Thomas Koenig  

PR fortran/57048
* gfortran.dg/c_funptr_1.f90: New file.
* gfortran.dg/c_funptr_1_mod.f90: New file.


Added:
trunk/gcc/testsuite/gfortran.dg/c_funptr_1.f90
trunk/gcc/testsuite/gfortran.dg/c_funptr_1_mod.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89077] ICE using * as len specifier for character parameter

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #5)
It does not fix the issue in comment #3.  In fact, the simpler testcase

program pr89077_3
  implicit none
  character(20), parameter :: input = 'Forward'
  integer i
  character(len(input)), parameter :: same = &
   transfer (trim (input), trim (input))
  print *, input, '#', len(input)
  print *, same, '#', len(same)
end program pr89077_3

prints random junk on the second line:

 Forward #  20
 ForwardQÀ@(#  20

:-(

[Bug fortran/89077] ICE using * as len specifier for character parameter

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
The following patch fixes the testcase and seems to pass regression testing.

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 268369)
+++ gcc/fortran/decl.c  (working copy)
@@ -1921,7 +1921,7 @@
}
  else if (init->ts.u.cl && init->ts.u.cl->length)
sym->ts.u.cl->length =
-   gfc_copy_expr (sym->value->ts.u.cl->length);
+   gfc_copy_expr (init->ts.u.cl->length);
}
}
  /* Update initializer character length according symbol.  */


Maybe it needs to be checked against a larger code base.

It changes (and hopefully fixes) almost 10-year old code.

Thanks, Dominique, for pointing to the right area.

[Bug testsuite/89110] New: r268343 breaks several tests in c++2a

[mpolacek at gcc dot gnu.org]

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

Bug ID: 89110
   Summary: r268343 breaks several tests in c++2a
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Yet again I broke a few tests in C++20 mode :(

FAIL: g++.dg/other/nontype-1.C  -std=c++2a (test for excess errors)
FAIL: g++.dg/parse/crash13.C  -std=c++2a (test for excess errors)
FAIL: g++.dg/parse/error36.C  -std=c++2a (test for excess errors)
FAIL: g++.dg/template/error29.C  -std=c++2a (test for excess errors)

Fortunately, it's just a simple update of these tests; the compiler itself is
fine.

[Bug testsuite/89110] r268343 breaks several tests in c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-29
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c/89109] New: Duplicates in COMPILER_PATH and LIBRARY_PATH and not canonicalized absolute paths

[jg at jguk dot org]

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

Bug ID: 89109
   Summary: Duplicates in COMPILER_PATH and LIBRARY_PATH and not
canonicalized absolute paths
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Observed three issues in COMPILER_PATH and LIBRARY_PATH when calling gcc

Example program:
// gcc -v -o main main.c
int main() { return 0; }




1) The COMPILER_PATH and LIBRARY_PATH paths are not canonicalized absolute
paths. Could realpath() be called to make it more readable?

2) There are many duplicates, can they be filtered? And those paths don't need
trailing / either do they?

COMPILER_PATH=
/usr/lib/gcc/x86_64-linux-gnu/8/
/usr/lib/gcc/x86_64-linux-gnu/8/
/usr/lib/gcc/x86_64-linux-gnu/
/usr/lib/gcc/x86_64-linux-gnu/8/
/usr/lib/gcc/x86_64-linux-gnu/

LIBRARY_PATH=
/usr/lib/gcc/x86_64-linux-gnu/8/
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib/
/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/
/usr/lib/../lib/
/usr/lib/gcc/x86_64-linux-gnu/8/../../../
/lib/
/usr/lib/






$ gcc-8 -v -o main main.c
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04) 
COLLECT_GCC_OPTIONS='-v' '-o' 'main' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1 -quiet -v -imultiarch x86_64-linux-gnu
main.c -quiet -dumpbase main.c -mtune=generic -march=x86-64 -auxbase main
-version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccWNJDLa.s
GNU C17 (Ubuntu 8.2.0-1ubuntu2~18.04) version 8.2.0 (x86_64-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C17 (Ubuntu 8.2.0-1ubuntu2~18.04) version 8.2.0 (x86_64-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 465f91519bea3044f6e4e12330b25007
COLLECT_GCC_OPTIONS='-v' '-o' 'main' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccU11di7.o /tmp/ccWNJDLa.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'main' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc9UhxP3.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s 

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
One more issue, shouldn't the #pragma GCC target be added before all include
files?  Various define many inline functions, e.g. unwind-pe.h or unwind-cxx.h.

[Bug fortran/89077] ICE using * as len specifier for character parameter

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
Replacing

  character(*), parameter :: str2 = transfer([(str(i:i), i=1,len(str))], str)

by

  character, parameter:: str2a(*) = [(str(i:i), i=1,len(str))]
  character(*), parameter :: str2 = transfer(str2a, str)

'solves' the issue.  I think there are close (code-wise) duplicates to
this issue, where some information of an array constructor is lost in
constant expressions.

[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 29 21:09:41 2019
New Revision: 268370

URL: https://gcc.gnu.org/viewcvs?rev=268370=gcc=rev
Log:
PR c++/66676
PR ipa/89104
* omp-simd-clone.c (simd_clone_clauses_extract)
: Ignore clauses with NULL
OMP_CLAUSE_ALIGNED_ALIGNMENT.

* gcc.dg/gomp/pr89104.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/pr89104.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-simd-clone.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/89104] ICE: Segmentation fault (in tree_int_cst_elt_check)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 29 21:09:41 2019
New Revision: 268370

URL: https://gcc.gnu.org/viewcvs?rev=268370=gcc=rev
Log:
PR c++/66676
PR ipa/89104
* omp-simd-clone.c (simd_clone_clauses_extract)
: Ignore clauses with NULL
OMP_CLAUSE_ALIGNED_ALIGNMENT.

* gcc.dg/gomp/pr89104.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/pr89104.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-simd-clone.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89103] Allow blank format items in format strings

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 Ever confirmed|0   |1

--- Comment #4 from kargl at gcc dot gnu.org ---
Forgot to note that the patch is ok to commit when gcc 10 stage 1 opens.

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from kargl at gcc dot gnu.org ---
The patch was discussed in the fortran@ list.  One can
find history here: https://gcc.gnu.org/ml/fortran/2019-01/msg00175.html

Patch is OK to commit when gcc 10 stage 1 opens.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[damian at sourceryinstitute dot org]

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

--- Comment #8 from Damian Rouson  ---
(In reply to Nicolas Koenig from comment #7)

> I actually opted to use multiprocessing with shared memory (shm_open() & co)
> instead of multithreading, since it will be much easier and faster with
> static variables, of which gfortran makes extensive use. Also, it greatly
> simplifies interoperability with OpenMP. 

This sounds like a great choice.  I have no prior familiarity with shm_open(),
but I very much like the idea of simplifying interoperability with OpenMP. 

> The only real downsides I can think of are slower spinup times... 

It will be interesting to compare the performance with MPI.  I also wonder if
this would also someday provide for a hybrid implementation wherein shm_open()
is used within a node and MPI is used across nodes, e.g., maybe images within
a TEAM could use shm_open() to communicate, while any communication between
TEAMs could use MPI.

> 
> I actually think it would be best not to turn it into a separate library but
> instead integrate it into libgfortran. 

I agree. 

> This way, it will not be necessary to
> install a seperate library and thereby make it easier for people to start
> using coarrays. Therefore, it would make sense to use the libgfortran
> descriptors.

> 
> At the moment, sync_all() is called after image creation.

I think that will suffice.

[Bug c/35608] limit-structnest.c fails due to O(n^2) memory usage in record_component_alias

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #10 from John David Anglin  ---
This test doesn't fail using gcc-8, but it now fails with 9.0.1 on
hppa-unknown-linux-gnu:
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg02949.html

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagn
ostics-color=never-O0  -w -c -o limits-structnest.o
/home/dave/gnu/gcc/gcc/g
cc/testsuite/gcc.c-torture/compile/limits-structnest.c(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagno
stics-color=never -O0 -w -c -o limits-structnest.o
/home/dave/gnu/gcc/gcc/gcc/te
stsuite/gcc.c-torture/compile/limits-structnest.c
virtual memory exhausted: Cannot allocate memory
compiler exited with status 1
FAIL: gcc.c-torture/compile/limits-structnest.c   -O0  (test for excess errors)
Excess errors:
virtual memory exhausted: Cannot allocate memory

[Bug c/89108] variable tracking size limit exceeded

[jg at jguk dot org]

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

--- Comment #1 from Jonny Grant  ---
Could gcc even support a dynamic size? to avoid a hard coded limit?

[Bug c/89108] New: variable tracking size limit exceeded

[jg at jguk dot org]

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

Bug ID: 89108
   Summary: variable tracking size limit exceeded
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Created attachment 45561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45561=edit
var tracking test case

I'm seeing this on 350 line file, will attach.

Could the "note: variable tracking size limit exceeded with
-fvar-tracking-assignments" message be expanded?

How about including the size limit, and how much would be actually required?

"note: variable tracking size limit 1,000,000 bytes exceeded by 512,000 bytes"


I saw there was this option, but not clear what to set it to, it's not ideal
for me to need to set it.
--param=max-vartrack-size=


$ g++-8 -g -O2 -D_GLIBCXX_ASSERTIONS -fsanitize=undefined,address
-fno-omit-frame-pointer -c var_tracking.cpp
var_tracking.cpp: In function ‘bool f(const string&, std::__cxx11::string&)’:
var_tracking.cpp:20:6: note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without
 bool f(const std::string & name, string & ref)
  ^

[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #22 from Dominique d'Humieres  ---
This PR is probably related to/duplicate of pr55978.

These two PRs are so mangled that it very difficult to tell what has been fixed
and what remains to be fixed.

IMO it would be better to open a new PR for what is still broken an to close
these two as FIXED.

[Bug fortran/55978] class_optional_2.f90 -Os fails

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres  ---
This PR is probably related to/duplicate of pr54618.

These two PRs are so mangled that it very difficult to tell what has been fixed
and what remains to be fixed.

IMO it would be better to open a new PR for what is still broken an to close
these two as FIXED.

[Bug middle-end/89002] [7/8 Regression] ICE in scan_omp_1_op, at omp-low.c:3166

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |scan_omp_1_op, at   |scan_omp_1_op, at
   |omp-low.c:3166  |omp-low.c:3166

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

[Bug c/89107] New: -Wconversion warning is not appropriate since conversion doesn't alter value, because of mask entered before.

[mareksz1958 at wp dot pl]

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

Bug ID: 89107
   Summary: -Wconversion warning is not appropriate since
conversion doesn't alter value, because of mask
entered before.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mareksz1958 at wp dot pl
  Target Milestone: ---

Such code is failing to compile on 2):

union U {
unsigned int a:20;
};

int main() {
union U u;
unsigned int val = 0xaabbc000;

u.a = val & 0xf; // 1) works
u.a = (val >> 12) & 0xf; // 2) doesn't
}

Because of the shift the compiler refuses to accept the conversion. And
complains in the following way:

$ gcc wconv.c -Wconversion -Werror
wconv.c: In function ‘main’:
wconv.c:10:11: error: conversion to ‘unsigned int:20’ from ‘unsigned int’ may
alter its value [-Werror=conversion]
 u.a = (val >> 12) & 0xf; /* 2) doesn't */
   ^
cc1: all warnings being treated as errors

Clang is compiling following code successfully. Seems like there is some
off-by-one bug; Mask 0x7 works without warnings/errors.

[Bug other/89106] New: cast-to-union documentation incorrect w.r.t. lvalueness

[amonakov at gcc dot gnu.org]

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

Bug ID: 89106
   Summary: cast-to-union documentation incorrect w.r.t.
lvalueness
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

The patch for PR 71560 changed the wording in "Cast to a Union Type"
documentation section. It now reads:

A cast to a union actually creates a compound literal and yields an lvalue,
not an rvalue like true casts do.

which is not true: a cast to union never produced an lvalue expression. The
last hunk in the patch was therefore incorrect:

-A cast to union type is similar to other casts, except that the type
-specified is a union type.  You can specify the type either with
-@code{union @var{tag}} or with a typedef name.  A cast to union is actually
-a constructor, not a cast, and hence does not yield an lvalue like
-normal casts.  (@xref{Compound Literals}.)
+A cast to union type looks similar to other casts, except that the type
+specified is a union type.  You can specify the type either with the
+@code{union} keyword or with a @code{typedef} name that refers to
+a union.  A cast to a union actually creates a compound literal and
+yields an lvalue, not an rvalue like true casts do.
+(@xref{Compound Literals}.)

[Bug fortran/89086] Add a Fortran language reference chapter

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #3)
> > > I don't think this is realistic unless someone steps on with at least a
> > > draft.
> >
> > Well, yes. Howewer, I would prefer if you did not close it.
> 
> What is the rationale?

Because I just submitted it? :-)

I think there is no harm in keeping this, because it serves to keep
track of the issue.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #21 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Florian Weimer from comment #18)
> > (In reply to Ramana Radhakrishnan from comment #15)
> > > Testing this and would be grateful for a test run.
> > 
> > Is this hunk needed as well, or will the unwinding information take care of
> > this?  (__cxa_call_unexpected has another d8 register spill.)
> 
> No idea here.

I'll try and analyse that - The key is ensuring that there is absolutely no
floating point code in eh_call.cc , if there is likely to be floating point
anywhere this isn't correct 

> 
> > --- libstdc++-v3/libsupc++/eh_call.cc   (revision 268364)
> > +++ libstdc++-v3/libsupc++/eh_call.cc   (working copy)
> > @@ -22,6 +22,11 @@
> >  // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> >  // .
> >  
> > +#ifdef __arm__
> > +#pragma GCC target ("fpu=none")
> > +#pragma GCC push_options
> > +#endif
> 
> But why the #pragma GCC push_options?  That makes no sense.
> Either you need to push options before GCC target and pop later on, but if
> you pop at the end of TU and don't really expect anything else to be emitted
> there, only #pragma GCC target should be enough (that applies to the other
> patch too).

I think that's just percolated my quick hack to discuss the issue. 

It should be enough to do #pragma GCC target . The final patch I have does that
. Thanks for confirming that the patch in it's essence fixes up the issue.

regards
Ramana

[Bug fortran/66708] Possible (minor) improvement on formatted io with format too short

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of pr27436.

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

[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

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

[Bug c++/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka  ---
> > We ICE on the fact that _ZTV1aIN12_GLOBAL__N_11fEE which is vtable for
> > anonymous namespace type but it has EXTERNAL flag set.
> > 
> > Jason, why this happens? I am changing type to C++: if there is indeed legal
> > reason to have exported vtables for anonymous types, then we can simply drop
> > the sanity check.
> 
> It isn't exported; it has DECL_EXTERNAL set because it isn't defined, and it
> isn't defined because nothing uses it, so it isn't needed.  Note that it isn't
> TREE_PUBLIC.

Hmm, so perhaps just adjusting sanity check to also check ||
!TREE_PUBLIC?

Honza

[Bug fortran/89103] Allow blank format items in format strings

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
The patch was discussed in the fortran@ list.  One can
find history here: https://gcc.gnu.org/ml/fortran/2019-01/msg00175.html

[Bug fortran/61073] -fcheck='do' leads to twice the amount of GDB steps in a do loop

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
I cannot reproduce it with recent gfortran (9.0).

Without feedback I'll close this PR as FIXED.

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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

--- Comment #10 from Hannes Hauswedell  ---
Thanks for the quick fix!

[Bug tree-optimization/89098] ICE: verify_ssa failed (Error: definition in block 27 follows the use)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Reproduceable on x86_64-linux with -m32 too.
We have:
  _62 = stride.18_139 * 4;
  _281 = _62 + offset.19_147;
  _63 = stride.18_139 * 5;
  _282 = _63 + offset.19_147;
  _283 = size.20_140 + offset.19_147;
  _486 = stride.18_139 * 6;
  _487 = offset.19_147 + _486;
  _488 = stride.18_139 * 3;
  _489 = offset.19_147 + _488;
  _490 = stride.18_139 * 2;
  _491 = offset.19_147 + _490;
before slsr and slsr changes that into:
  _62 = stride.18_139 * 4;
  _281 = _62 + offset.19_147;
  _63 = stride.18_139 * 5;
  _282 = _281 + stride.18_139;
  slsr_324 = stride.18_139 * 3;
  _283 = _281 + slsr_324;
  _486 = stride.18_139 * 6;
  _487 = _281 + _490;
  _488 = stride.18_139 * 3;
  _489 = _281 - stride.18_139;
  _490 = stride.18_139 * 2;
  _491 = _281 - _490;
and the ICE is because _490 is used before definition.

C testcase that ICEs even on x86_64-linux with -O2 --param
max-slsr-cand-scan=1:
void bar (int, int, int, int, int, int);

int
foo (int s, int o, int x)
{
  int t0 = s * 7;
  if (x)
{
  int t1 = s * 4;
  int t2 = t1 + o;
  int t3 = s * 5;
  int t4 = t3 + o;
  int t5 = t0 + o;
  int t6 = s * 6;
  int t7 = o + t6;
  int t8 = s * 3;
  int t9 = o + t8;
  int t10 = s * 2;
  int t11 = o + t10;
  bar (t2, t4, t5, t7, t9, t11);
}
  return t0;
}

[Bug c++/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #1)
> We ICE on the fact that _ZTV1aIN12_GLOBAL__N_11fEE which is vtable for
> anonymous namespace type but it has EXTERNAL flag set.
> 
> Jason, why this happens? I am changing type to C++: if there is indeed legal
> reason to have exported vtables for anonymous types, then we can simply drop
> the sanity check.

It isn't exported; it has DECL_EXTERNAL set because it isn't defined, and it
isn't defined because nothing uses it, so it isn't needed.  Note that it isn't
TREE_PUBLIC.

[Bug fortran/51637] Add compile-time error if array is too large

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
If I add a line

print *, size(a, kind=16), sizeof(a(1))

the output is

 184467440737095516150

Note that the size of A is zero.

For very large arrays the darwin loader emits either

ld: LC_SEGMENT filesize too large file 'object.o' for architecture x86_64

for

program main
  character(len=2_8**33), parameter :: a = ""
  character(len=2_8**33) :: b
  print '(A)',a
  b = ""
  print '(A)',b
end program main

or (pr69061)

ld: 32-bit RIP relative reference out of range (5624320831 max is +/-2GB): from
_MAIN__ (0x11692) to _pxz.3873 (0x24F3C8080) in '_MAIN__' from
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccYDTFMi.o for architecture
x86_64

What should be do with this PR?

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

--- Comment #20 from Florian Weimer  ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
> 
> Testing this and would be grateful for a test run.

I can confirm that this patch fixes the glibc test suite failure,
nptl/tst-thread-exit-clobber.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #19 from Jakub Jelinek  ---
(In reply to Florian Weimer from comment #18)
> (In reply to Ramana Radhakrishnan from comment #15)
> > Testing this and would be grateful for a test run.
> 
> Is this hunk needed as well, or will the unwinding information take care of
> this?  (__cxa_call_unexpected has another d8 register spill.)

No idea here.

> --- libstdc++-v3/libsupc++/eh_call.cc   (revision 268364)
> +++ libstdc++-v3/libsupc++/eh_call.cc   (working copy)
> @@ -22,6 +22,11 @@
>  // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>  // .
>  
> +#ifdef __arm__
> +#pragma GCC target ("fpu=none")
> +#pragma GCC push_options
> +#endif

But why the #pragma GCC push_options?  That makes no sense.
Either you need to push options before GCC target and pop later on, but if you
pop at the end of TU and don't really expect anything else to be emitted there,
only #pragma GCC target should be enough (that applies to the other patch too).

[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #10 from Dominique d'Humieres  ---
What should be the status of this PR? It works for me.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

--- Comment #18 from Florian Weimer  ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
> 
> Testing this and would be grateful for a test run.

Is this hunk needed as well, or will the unwinding information take care of
this?  (__cxa_call_unexpected has another d8 register spill.)

Index: libstdc++-v3/libsupc++/eh_call.cc
===
--- libstdc++-v3/libsupc++/eh_call.cc   (revision 268364)
+++ libstdc++-v3/libsupc++/eh_call.cc   (working copy)
@@ -22,6 +22,11 @@
 // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 // .

+#ifdef __arm__
+#pragma GCC target ("fpu=none")
+#pragma GCC push_options
+#endif
+
 #include 
 #include 
 #include 

[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-29
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Looking again what ICC does here: ICC 16 emits a1 (i.e. like aligned(i_x:1)),
ICC 17 emits a8 (i.e. like aligned(i_x:8)), ICC 18 and 19 don't emit anything
(i.e. ignore the aligned clause that doesn't tell anything interesting.
I guess that is the most reasonable behavior, so will implement it in GCC.

[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Jakub Jelinek  ---
*** Bug 89104 has been marked as a duplicate of this bug. ***

[Bug ipa/89104] ICE: Segmentation fault (in tree_int_cst_elt_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #9 from Steve Ellcey  ---
Created attachment 45559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45559=edit
Assembly output from aarch64-linux-gnu

This test is still failing on aarch64.  Attached is the .s file from a
top-of-tree GCC build on aarch64-linux-gnu.

[Bug c++/89105] -Wabi warns for functions with internal linkage

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/86740] [8 Regression] ICE with hana and nested lambdas (likely a regression, tsubst_copy, at cp/pt.c:15325)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 8.3 as well.

[Bug c++/88865] [[no_unique_address]] leads to sizeof(T) == 0, which cannot be

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed.

[Bug c++/88865] [[no_unique_address]] leads to sizeof(T) == 0, which cannot be

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Tue Jan 29 15:39:40 2019
New Revision: 268368

URL: https://gcc.gnu.org/viewcvs?rev=268368=gcc=rev
Log:
PR c++/89089 - ICE with [[no_unique_address]].

In 89089, we were never actually setting DECL_SIZE on an empty data member,
because its type is a POD, so we didn't set it in the maybe-overlapping
section.  Fixed by also handling empty types there.

In 88865, we were failing to consider empty data members in
include_empty_classes.  Fixed by making end_of_class always include them.

While looking at these I noticed that the ABI says that a
potentially-overlapping data member makes its class non-layout-POD, and that
an empty data member doesn't prevent its class from being empty, so I've
implemented those points as well.

PR c++/88865 - wrong layout with [[no_unique_address]].
* class.c (check_field_decls): A potentially-overlapping field makes
the class non-layout-POD, but not non-empty.
(end_of_class): Always consider empty data members.
(layout_class_type): Set DECL_SIZE for empty fields.

Added:
trunk/gcc/testsuite/g++.dg/abi/no_unique_address4.C
trunk/gcc/testsuite/g++.dg/abi/no_unique_address5.C
trunk/gcc/testsuite/g++.dg/cpp2a/no_unique_address2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Tue Jan 29 15:39:40 2019
New Revision: 268368

URL: https://gcc.gnu.org/viewcvs?rev=268368=gcc=rev
Log:
PR c++/89089 - ICE with [[no_unique_address]].

In 89089, we were never actually setting DECL_SIZE on an empty data member,
because its type is a POD, so we didn't set it in the maybe-overlapping
section.  Fixed by also handling empty types there.

In 88865, we were failing to consider empty data members in
include_empty_classes.  Fixed by making end_of_class always include them.

While looking at these I noticed that the ABI says that a
potentially-overlapping data member makes its class non-layout-POD, and that
an empty data member doesn't prevent its class from being empty, so I've
implemented those points as well.

PR c++/88865 - wrong layout with [[no_unique_address]].
* class.c (check_field_decls): A potentially-overlapping field makes
the class non-layout-POD, but not non-empty.
(end_of_class): Always consider empty data members.
(layout_class_type): Set DECL_SIZE for empty fields.

Added:
trunk/gcc/testsuite/g++.dg/abi/no_unique_address4.C
trunk/gcc/testsuite/g++.dg/abi/no_unique_address5.C
trunk/gcc/testsuite/g++.dg/cpp2a/no_unique_address2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c

[Bug c/89061] [9 Regression] GCC 9 introduces false positive in -Wjump-misses-init

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|GCC 9 introduces false  |[9 Regression] GCC 9
   |positive in |introduces false positive
   |-Wjump-misses-init  |in -Wjump-misses-init

[Bug c/89061] GCC 9 introduces false positive in -Wjump-misses-init

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-29
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested patch that implements this.

[Bug c++/89105] -Wabi warns for functions with internal linkage

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This is seen while building libstdc++.so but is harmless and can be ignored:

/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_ops.cc: In function
‘uintmax_t std::filesystem::file_size(const std::filesystem::__cxx11::path&,
std::error_code&)’:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_ops.cc:954:68: warning:
empty class ‘std::filesystem::file_size(const std::filesystem::__cxx11::path&,
std::error_code&)::’ parameter passing ABI changes in
-fabi-version=12 (GCC 8) [-Wabi]
  954 |   auto s = do_stat(p, ec, [](const auto& st) { return S{st}; }, S{});
  |^
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_ops.cc: In function ‘T
{anonymous}::do_stat(const std::filesystem::__cxx11::path&, std::error_code&,
Accessor, T) [with Accessor = std::filesystem::file_size(const
std::filesystem::__cxx11::path&, std::error_code&)::; T
= std::filesystem::file_size(const std::filesystem::__cxx11::path&,
std::error_code&)::S]’:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_ops.cc:925:5: warning:
empty class ‘std::filesystem::file_size(const std::filesystem::__cxx11::path&,
std::error_code&)::’ parameter passing ABI changes in
-fabi-version=12 (GCC 8) [-Wabi]
  925 | do_stat(const fs::path& p, std::error_code& ec, Accessor f, T
deflt)
  | ^~~

It can't be suppressed with a pragma (PR 87611).

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[a.drobyshev at samsung dot com]

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

Andrey Drobyshev  changed:

   What|Removed |Added

 CC||a.drobyshev at samsung dot com

--- Comment #8 from Andrey Drobyshev  ---
I recently started to work on this issue as well. I managed to put a dummy
global variable into .data, .rodata and .bss as follows:

static void
emit_globals_protector(void)
{
  tree decl, id, init;

  id = get_identifier ("__asan_dummy_global");
  decl = build_decl (BUILTINS_LOCATION, VAR_DECL, id, integer_type_node);
  init = build_one_cst(integer_type_node);

  SET_DECL_ASSEMBLER_NAME (decl, id);
  TREE_ADDRESSABLE (decl) = 1;
  DECL_ARTIFICIAL (decl) = 1;
  TREE_STATIC (decl) = 1;
  TREE_PUBLIC (decl) = 1;
  TREE_USED (decl) = 1;

  TREE_READONLY (init) = 1;  // controls whether variable goes to .rodata
or .data
  TREE_STATIC (init) = 1;
  DECL_INITIAL (decl) = init;// controls whether variable gets initialized
or goes to .bss

  varpool_node::add(decl);
}

Calling varpool_node::add() makes sure that created dummy global goes first
into the target section, as it leads to call to assemble_variable():

#0  categorize_decl_for_section (decl=0x77ff4e10, reloc=0) at
../../gcc/varasm.c:6378
#1  0x01096112 in default_elf_select_section (decl=0x77ff4e10,
reloc=0, align=256) at ../../gcc/varasm.c:6499
#2  0x010b6ce3 in x86_64_elf_select_section (decl=0x77ff4e10,
reloc=0, align=256) at ../../gcc/config/i386/i386.c:6549
#3  0x0108afd3 in get_variable_section (decl=0x77ff4e10,
prefer_noswitch_p=false) at ../../gcc/varasm.c:1170
#4  0x0108d70b in assemble_variable (decl=0x77ff4e10, top_level=0,
at_end=1, dont_output_data=0) at ../../gcc/varasm.c:2206
#5  0x0109fd8a in varpool_node::assemble_decl (this=0x77281100) at
../../gcc/varpool.c:582
#6  0x00917f92 in varpool_node::finalize_decl (decl=0x77ff4e10) at
../../gcc/cgraphunit.c:823
#7  0x0109f9c0 in varpool_node::add (decl=0x77ff4e10) at
../../gcc/varpool.c:473
#8  0x0091ba93 in emit_globals_protector () at
../../gcc/cgraphunit.c:2187
#9  0x0091bab6 in output_in_order (no_reorder=false) at
../../gcc/cgraphunit.c:2218
#10 0x0091c4f4 in symbol_table::compile (this=0x771280a8) at
../../gcc/cgraphunit.c:2524
#11 0x0091c73f in symbol_table::finalize_compilation_unit
(this=0x771280a8) at ../../gcc/cgraphunit.c:2620
#12 0x00d90fbf in compile_file () at ../../gcc/toplev.c:496
#13 0x00d93448 in do_compile () at ../../gcc/toplev.c:1998
#14 0x00d936d2 in toplev::main (this=0x7fffdbb0, argc=27,
argv=0x7fffdcb8) at ../../gcc/toplev.c:2106
#15 0x016e11d1 in main (argc=27, argv=0x7fffdcb8) at
../../gcc/main.c:39

However, there're questions:
1. I wonder is it really possible to emit zero-sized dummies and initialize
them as well (i.e. emit them into .data/.rodata)? For now I emit variables of
integer types, but that leads to the presence of couple addressable bytes in
the beginning of the section.
2. What should we do with sections like .data.rel.ro, .data.rel.ro.local? They
suffer from this bug too, but it's not that easy to put globals there, as you
must set various attributes onto decl to ensure it will receive the right reloc
value.

[Bug c++/89105] New: -Wabi warns for functions with internal linkage

[redi at gcc dot gnu.org]

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

Bug ID: 89105
   Summary: -Wabi warns for functions with internal linkage
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

// { dg-options "-fabi-version=12 -Wabi=11" }

namespace {
  template
void run(F f, int i)
{
  f(i);
}
}

void f()
{
  run([](int) { }, 1);
}


wabi.cc: In function ‘void f()’:
wabi.cc:13:6: warning: empty class ‘f()::’ parameter passing ABI
changes in -fabi-version=12 (GCC 8) [-Wabi]
   run([](int) { }, 1);
   ~~~^~~~
wabi.cc: In function ‘void {anonymous}::run(F, int) [with F =
f()::]’:
wabi.cc:5:10: warning: empty class ‘f()::’ parameter passing ABI
changes in -fabi-version=12 (GCC 8) [-Wabi]
 void run(F f, int i)
  ^~~

This seems like a false position, because the function cannot be called from
outside the current translation unit. It has internal linkage, and its address
is never taken.

Making it static instead of using an unnamed namespace doesn't change anything.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #28 from dave.anglin at bell dot net ---
On 2019-01-29 4:53 a.m., redi at gcc dot gnu.org wrote:
> Done - do you want to keep this open?
Could the change be backported?  I will test in coming days.

[Bug ipa/89104] New: ICE: Segmentation fault (in tree_int_cst_elt_check)

[asolokha at gmx dot com]

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

Bug ID: 89104
   Summary: ICE: Segmentation fault (in tree_int_cst_elt_check)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gcc-9.0.0-alpha20190127 snapshot (r268327), 8.2, 7.3, 6.3, 5.4, 4.9.4 all ICE
when compiling the following testcase:

#pragma omp declare simd aligned (c5)
void
lp (int *c5)
{
  (void) c5;
}

% gcc-9.0.0-alpha20190127 -fopenmp -c udqj9h0r.c
during IPA pass: simdclone
udqj9h0r.c:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0xd7147f crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/toplev.c:326
0x1673858 tree_int_cst_elt_check(tree_node*, int, char const*, int, char
const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/tree.h:3375
0x1673858 simd_clone_clauses_extract
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/omp-simd-clone.c:248
0x1673858 expand_simd_clones(cgraph_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/omp-simd-clone.c:1611
0x16744cf ipa_omp_simd_clone
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/omp-simd-clone.c:1704
0x16744cf execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/omp-simd-clone.c:1732

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

--- Comment #17 from Florian Weimer  ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
> 
> Testing this and would be grateful for a test run.

I believe the #pragma GCC push_options needs to come first, but it shouldn't
matter in this context because the option set is never actually restored.

(I have not tested the patch yet.)

[Bug fortran/89103] Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #2 from MarkEggleston  ---
Created attachment 45556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45556=edit
Change Log for gc/testsuite for patch

[Bug fortran/89103] Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #1 from MarkEggleston  ---
Created attachment 4
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4=edit
Change log for gcc/fortran for patch

[Bug fortran/89103] New: Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

Bug ID: 89103
   Summary: Allow blank format items in format strings
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark.eggleston at codethink dot com
  Target Milestone: ---

Created attachment 45554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45554=edit
Patch to allow blank item in format

gfortran as of revision: svn+ssh://gcc.gnu.org/svn/gcc/trunk@268360

At the end of list of specifiers a blank item can appear between the comma and
closing bracket.

The following error is produced, as it should be:

   18 | 10FORMAT( I5,)
  |  1
Error: Unexpected element ')' in format string at (1)

In legacy Fortran this is not the case PGI Fortran 18.10 silently accepts this
with no compiler switches. I believe this is feature originated from DEC
Fortran.

Attached is a patch that will allow this.

As this is non-standard Fortran this feature is only enabled using
-fdec-blank-format-item which is also enabled by -fdec.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[gael.guennebaud at gmail dot com]

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

--- Comment #4 from Gael Guennebaud  ---
Good to know this is fixed in trunk! Thank you, and sorry for the false alarm
then.

[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Known to work||9.0
Version|unknown |8.2.0
   Target Milestone|--- |9.0
  Known to fail||8.2.0

--- Comment #3 from Wilco  ---
(In reply to Gael Guennebaud from comment #2)
> Indeed, it fails to remove the dup only if the coefficient is used multiple
> times as in the following reduced exemple: (https://godbolt.org/z/hmSaE0)
> 
> 
> #include 
> 
> void foo(const float* a, const float * b, float * c, int n) {
> float32x4_t c0, c1, c2, c3;
> c0 = vld1q_f32(c+0*4);
> c1 = vld1q_f32(c+1*4);
> for(int k=0; k {
> float32x4_t a0 = vld1q_f32(a+0*4+k*4);
> float32x4_t b0 = vld1q_f32(b+k*4);
> c0 = vfmaq_laneq_f32(c0, a0, b0, 0);
> c1 = vfmaq_laneq_f32(c1, a0, b0, 0);
> }
> vst1q_f32(c+0*4, c0);
> vst1q_f32(c+1*4, c1);
> }
> 
> 
> I tested with gcc 7 and 8.

Confirmed for GCC8, fixed on trunk. I tried the above example with up to 4 uses
and it always generates the expected code on trunk. So this is fixed for GCC9,
however it seems unlikely the fix (multi-use support in Combine) could be
backported.

[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #4 from Matthias Klose  ---
Created attachment 45553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45553=edit
preprocessed source

another preprocessed source from the trilinos package.

$ g++ -std=c++11 -c -Wall -Wextra TestSerial_SharedAlloc.ii 
TestSerial_SharedAlloc.ii: In instantiation of 'void test_shared_alloc() [with
MemorySpace = HostSpace; ExecutionSpace = Serial]':
TestSerial_SharedAlloc.ii:5645:48:   required from here
TestSerial_SharedAlloc.ii:169:66: internal compiler error: in
lookup_template_class_1, at cp/pt.c:9459
   auto __trans_tmp_5467 = RecordFull::allocate( s, name, size * 0 );
  ^~~~
0x7f0352c3b09a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.


unfortunately creduce doesn't terminate when trying to reproduce it.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

--- Comment #16 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #14)
> We require GNU make, so one can use something like:
> unwind-arm.o unwind-c.o libunwind.o pr-support.o: CFLAGS += -mfpu=none
> or similar in libgcc/config/arm/t-arm (or similar) with a comment explaining
> the reason.  For eh_personality.o that needs to be done elsewhere and there
> are no such makefile fragments (and libtool is used).

Sadly that doesn't work for -mfpu=none in t-arm because we still need gcc-9 to
build with older binutils that don't necessarily support -mfpu=none, thus for
now let's hide this with target pragmas.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

  Attachment #45547|0   |1
is obsolete||

--- Comment #15 from Ramana Radhakrishnan  ---
Created attachment 45552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45552=edit
new patch.

Testing this and would be grateful for a test run.

[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[gael.guennebaud at gmail dot com]

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

--- Comment #2 from Gael Guennebaud  ---
Indeed, it fails to remove the dup only if the coefficient is used multiple
times as in the following reduced exemple: (https://godbolt.org/z/hmSaE0)


#include 

void foo(const float* a, const float * b, float * c, int n) {
float32x4_t c0, c1, c2, c3;
c0 = vld1q_f32(c+0*4);
c1 = vld1q_f32(c+1*4);
for(int k=0; k

[Bug middle-end/89099] Have "-fopt-info" show the original source code context

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #1)
> (a) unify the two, so that -fopt-info messages
..."go through the diagnostics subsystem", I meant to write.

[Bug middle-end/89099] Have "-fopt-info" show the original source code context

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Indeed: -fopt-info is currently implemented via writing to up to two FILE *
destinations: the dumpfile and the opt-info destination (e.g. stderr).

In particular it doesn't go through the diagnostic subsystem.

Some of the differences between dumping and diagnostics:
* as noted in comment #0, it's missing the quoted source code
* it's missing the announcements about function names, such as the: "In
function 'main':" from the diagnostic example; for diagnostics this can include
things like printing the inlining chain
* we don't have quotes and bold in the opt-info output (e.g. via "%qs")
* we don't localize the messages

Two approaches to addressing this:
(a) unify the two, so that -fopt-info messages
(b) hack in a call to diagnostic_show_locus into the dump subsystem (this seems
easier)

Approach (b) seems easier.  It sounds like you want this for the -fopt-info
destination (alt_dump_file; typically stderr).   Should diagnostic_show_locus
be called for the dumpfile as well?

There are some warts involving things like:
* whether colorization should happen (if writing to a "real" file rather than
stderr)
* the cache for suppressing what was last printed, since there'd be multiple
output sources
* probably things I haven't thought of
[perhaps the dump subsystem would need its own diagnostic_context for handling
such output???]

[Bug libstdc++/89102] New: 'common_type' of single abominable function should not have a nested typename

[alisdairm at me dot com]

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

Bug ID: 89102
   Summary: 'common_type' of single abominable function should not
have a nested typename
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

According to the formula for 'common_type', as an abominable function type does
not have a valid return type for 'declval', the trait should not have a nested
'type' name.

The following program shows this is not the case (I have not tried to work out
what the nested name aliases, probably the type itself):


template 
inline constexpr bool DetectType = false;

template 
inline constexpr
bool DetectType> = true;

// Quick proof detector works correctly
struct NoType {};
struct HasType { using type = HasType; };

static_assert( DetectType );
static_assert(!DetectType );


auto main() -> int {
   static_assert(!DetectType< std::common_type >);
   static_assert(!DetectType< std::common_type >);
   static_assert(!DetectType< std::common_type >);
   static_assert(!DetectType< std::common_type >);

   return 0;
}


I have also tested with gcc9 in development, but MacPorts stopped updating
around October 2018, so my test environment is quite out of date - so only
claiming the bug
against the latest release version I have tested.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #7 from Nicolas Koenig  ---
(In reply to Damian Rouson from comment #5)
> This is an exciting idea.  When I gave some thought to writing a
> shared-memory alternative coarray ABI, it seemed to me that pthreads would
> be a better choice than OpenMP.  Part of the problem is that I was
> considering writing the implementation in Fortran, and OpenMP lacked support
> several modern Fortran features, including several object-oriented
> programming features.  That of course won't be an issue for you, however,
> assuming you're going to write the implementation in C.  I was going to
> leverage "forthreads," an open-source Fortran 20003 interface to pthreads. 
> One thing that I think would be a major benefit of having a Fortran
> implementation of the library is that it greatly expand the potential
> community of contributors to include more of the users of the compiler.
> 

I actually opted to use multiprocessing with shared memory (shm_open() & co)
instead of multithreading, since it will be much easier and faster with static
variables, of which gfortran makes extensive use. Also, it greatly simplifies
interoperability with OpenMP. The only real downsides I can think of are slower
spinup times (~1 cycles for processes vs. ~1000 for threads), far slower
context switches (only a problem if more more images than cores are used) and
slower allocation, since at the moment a mmap() call is needed for each one
(the allocator tracks the offset and size in the memfile instead of the
mmap()'ed memory regions. If this is to slow, I can just cache the pointers).
As for writting it in fortran, see below :)

>
> Another important consideration is whether to use the current gfortran
> descriptors as arguments in the library functions (as is currently used) or
> instead to use the Fortran 2018 CFI descriptors for which Paul recently
> committed support.  If you go with the current gfortran descriptors, then
> there could be a lot of code to rewrite if gfortran later adopts the
> standard descriptors internally.  Paul's recent commit adds functions that
> can translate between the gfortran and standard descriptors. I have a
> volunteer who I'm hoping will use the translation functions to develop a
> new, alternative coarray ABI that accepts the standard descriptors.
> 

I actually think it would be best not to turn it into a separate library but
instead integrate it into libgfortran. This way, it will not be necessary to
install a seperate library and thereby make it easier for people to start using
coarrays. Therefore, it would make sense to use the libgfortran descriptors.

>
> On another note mentioned earlier in this PR, I believe it will be necessary
> to fork all threads at the beginning of execution and not join them at the
> end.  Section 5.3.5 of the Fortran 2018 standard states, "Following the
> creation of a fixed number of images, execution begins on each image."
> Assuming there is a one-to-one correspondence between images and threads, I
> read that as implying that a fixed number of threads have to be set up
> before any one thread can execute.  (Possibly there could also be additional
> non-image threads that get forked later also though.) 

At the moment, sync_all() is called after image creation.

> I recall seeing several interesting papers from 10-15 years ago on SPMD-style
> programming using threads (OpenMP) so a literature search on this topic be 
> useful to read.

[Bug c++/87603] [C++17] noexcept isn't special cased for constant expressions anymore

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Specifically, we get a new FAIL when running the libstdc++ tests in c++2a mode:

FAIL: 21_strings/basic_string/types/1.cc (test for excess errors)

That's because the is_convertible trait instantiates the new c++2a-only
__is_nothrow_type member, which instantiates the basic_string_view ctor,
which is ill-formed because X isn't equality comparable.


I think this might be a rejects-valid example:

template
struct basic_string_view
{
  constexpr basic_string_view(T p) noexcept { (void) p.i; }
};

struct X { } x;

bool b = noexcept(basic_string_view{x});


ntconv.cc: In instantiation of 'constexpr
basic_string_view::basic_string_view(T) [with T = X]':
ntconv.cc:10:42:   required from here
ntconv.cc:5:56: error: 'struct X' has no member named 'i'
5 |   constexpr basic_string_view(T p) noexcept { (void) p.i; }
  |  ~~^


If I'm reading the standard correctly, the constructor's noexcept-specifier is
instantiated because it's "needed" but that should not cause the instantiation
of the function declaration.

If the constructor is not constexpr it isn't instantiated when the
noexcept-specifier is needed, which is why I think it's related to this bug.

[Bug c/89061] GCC 9 introduces false positive in -Wjump-misses-init

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Joseph, you mean we should skip the compound literals from this warning because
if one doesn't take their address, they are used only directly in the code in
which they are referenced and not anywhere else, and if their address is taken,
there is probably no way to propagate that address through to after the label?
I mean, if I do:
  struct S *p = something;
  if (whatever)
goto l;
  p = &(struct S){ .a = 1, .b = 2, .c = 3 };
l:
  return p->b;
then although the initialization was crossed by the jump, nothing should be
able to find the address of the compound literal that got not initialized?

If yes, we don't have the complit decls marked specially in any way,
DECL_ARTIFICIAL && !DECL_NAME is way too generic check.  So we'd need some
unused C lang bit to mark it.