[Bug target/93709] [10 regression] fortran.dg/minlocval_4.f90 fails on power 9 after r10-4160

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |10.0

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

[Bug c++/93713] [10 Regression] ICE in equivalently_constrained, at cp/constraint.cc:2949

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |10.0

[Bug fortran/93715] [9/10 Regression] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:6320

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.3

[Bug c++/93716] [feature request] Improve error message for Classes without a default constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug testsuite/93717] [10 Regression] gcc.dg/optimize-bswapsi-2.c fails after it was updated in r10-5832

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-13
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Huh, I remember updating one of the testcases, guess I forgot this second.

[Bug testsuite/93717] [10 Regression] gcc.dg/optimize-bswapsi-2.c fails after it was updated in r10-5832

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed.

[Bug testsuite/93717] [10 Regression] gcc.dg/optimize-bswapsi-2.c fails after it was updated in r10-5832

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Guenther :

https://gcc.gnu.org/g:8ea884b85e338d09b14e6a54043c53ae0c1b1fe9

commit r10-6613-g8ea884b85e338d09b14e6a54043c53ae0c1b1fe9
Author: Richard Biener 
Date:   Thu Feb 13 09:10:28 2020 +0100

testsuite/93717 fix up gcc.dg/optimize-bswapsi-2.c for BE

2020-02-13  Richard Biener  

PR testsuite/93717
* gcc.dg/optimize-bswapsi-2.c: Add BE case.

[Bug tree-optimization/93721] swapping adjacent scalars could be more efficient

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Store merging and bswap should be merged - there's PRs for bswap not working
for "stores" (because those are not seeds it works from).  And bswap would
need to be enhanced to detect more permutation patterns (eventually also use
vector load + permute + store/pun to GPR).

[Bug gcov-profile/93726] New: [GCOV] unexecuted functions lead to incorrect code coverage when it calls a function with a variable argument

[yangyibiao at hust dot edu.cn]

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

Bug ID: 93726
   Summary: [GCOV] unexecuted functions lead to incorrect code
coverage when it calls a function with a variable
argument
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcov -v
gcov (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or 
FITNESS FOR A PARTICULAR PURPOSE.


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)


$ cat small.c
#include 

long x, y;

inline void __attribute__((always_inline)) f1(va_list ap)
{
  x = va_arg(ap, double);
  x += va_arg(ap, long);
  x += va_arg(ap, double);
}

void foo(int i, ...)
{
  va_list ap;
  va_start(ap, i);
  f1(ap);
  va_end(ap);
}

void bar(int i, ...)
{
  va_list ap;
  va_start(ap, i);
  switch (i)
  {
  case 0:
y = va_arg(ap, double);
break;
  default:
break;
  }
  f1(ap);
  va_end(ap);
}

void main(void) { foo(3, 16.0); }


$ gcc -O0 --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:42.11% of 19
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:#include 
-:2:
-:3:long x, y;
-:4:
-:5:inline void __attribute__((always_inline)) f1(va_list ap)
-:6:{
#:7:  x = va_arg(ap, double);
1*:8:  x += va_arg(ap, long);
1*:9:  x += va_arg(ap, double);
1*:   10:}
-:   11:
1:   12:void foo(int i, ...)
-:   13:{
-:   14:  va_list ap;
1:   15:  va_start(ap, i);
-:   16:  f1(ap);
1:   17:  va_end(ap);
1:   18:}
-:   19:
#:   20:void bar(int i, ...)
-:   21:{
-:   22:  va_list ap;
#:   23:  va_start(ap, i);
#:   24:  switch (i)
-:   25:  {
#:   26:  case 0:
#:   27:y = va_arg(ap, double);
#:   28:break;
#:   29:  default:
#:   30:break;
-:   31:  }
-:   32:  f1(ap);
#:   33:  va_end(ap);
#:   34:}
-:   35:
1:   36:void main(void) { foo(3, 16.0); }



### We can find that: Line #7 is not executed.
### when the definition of function "bar" is removed from the source code, the
coverage will be different.

[Bug analyzer/93388] ensure -fanalyzer works with our C code

[dcb314 at hotmail dot com]

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

--- Comment #11 from David Binderman  ---
(In reply to David Binderman from comment #9)
> I'll report back with anything else I find.

154 ice left. They are all in get_lvalue_1. They
are are duplicates of these three:

./c-c++-common/pr51628-30.c:21:3: internal compiler error: unhandled tree code
i
n region_model::get_lvalue_1: ‘imagpart_expr’

./gcc.c-torture/compile/20060625-1.c:8:3: internal compiler error: unhandled
tre
e code in region_model::get_lvalue_1: ‘realpart_expr’

./c-c++-common/pr59037.c:9:3: internal compiler error: unhandled tree code in
re
gion_model::get_lvalue_1: ‘view_convert_expr’

Once these are fixed, I'll look into C++ and Fortran.

[Bug libfortran/93727] New: Fortran 2018: EX edit descriptor

[thenlich at gcc dot gnu.org]

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

Bug ID: 93727
   Summary: Fortran 2018: EX edit descriptor
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thenlich at gcc dot gnu.org
  Target Milestone: ---

13.7.2.3.6 EX editing

1 The EX edit descriptor produces an output field in the form of a
hexadecimal-significand number.

2 The EXw.d and EXw.dEe edit descriptors indicate that the external field
occupies w positions, except when w is zero in which case the processor selects
the field width. The fractional part of the field contains d hexadecimal
digits, except when d is zero in which case the processor selects the number of
hexadecimal digits to be the minimum required so that the output field is equal
to the internal value; d shall not be zero if the radix of the internal value
is not a power of two. The hexadecimal point, represented by a decimal symbol,
appears after the first hexadecimal digit. For the form EXw.d, and for EXw.dE0,
the exponent part contains the minimum number of digits needed to represent the
exponent; otherwise the exponent contains e digits. The e has no effect on
input. The scale factor has no effect on output. 

3 The form and interpretation of the input field is the same as for Fw.d
editing (13.7.2.3.2).

4 For an internal value that is an IEEE infinity or NaN, the form of the output
field is the same as for Fw.d.

5 For an internal value that is neither an IEEE infinity nor a NaN, the form of
the output field is
  [ ± ] 0X x0 . x1x2 . . . exp
where:

• ± signifies a plus sign or a minus sign;
• . signifies a decimal symbol (13.6);
• x0x1x2 . . . are the most significant hexadecimal digits of the internal
value, after rounding if d is not zero (13.7.2.3.8);
• exp is a binary exponent expressed as a decimal integer; for EXw.d and
EXw.dE0, the form is P ±z1 . . . zn20 , where n is the minimum number of digits
needed to represent exp, and for EXw.dEe with e greater than zero the form is P
±z1 . . . ze22 . The choice of binary exponent is processor dependent. If the
most significant binary digits of the internal value are b0b1b2 . . ., the
binary exponent might make the value of x0 be that of b0, b0b1, b0b1b2, or
b0b1b2b3. A plus sign is produced if the exponent value is zero.

Examples:
Internal value  Edit descriptor  Possible output with SS in effect
1.375   EX0.10X1.6P+0
−15.625 EX14.4E3 -0X1.F400P+003
1048580.0   EX0.00X1.4P+20
2.375   EX0.10X2.6P+0

[Bug c++/93728] New: First half of warning message suppressed because code pointed to is in system header

[loximann at gmail dot com]

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

Bug ID: 93728
   Summary: First half of warning message suppressed because code
pointed to is in system header
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: loximann at gmail dot com
  Target Milestone: ---

Created attachment 47833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47833&action=edit
Minimal reproducible example

-Woverloaded-virtual shows only the second half of a warning, making it
confusing, when several circumstances happen:
- A class with two virtual methods with the same name and different signature
exists in a system header.
- Another class inheriting from the previous class does not override any
methods.
- Another class inheriting from the previous class overrides only one method.

The output is this:

$ make
g++ -isystem include -Woverloaded-virtual Woverloaded-virtual.cpp -c
Woverloaded-virtual.cpp:8:9: warning:   by ‘virtual void Bar::f(int)’
[-Woverloaded-virtual]
8 |void f(int) final {};
  | ^

Including the header as a regular header shows also the first half.

sergio@bnct1:~/src/playground/Woverloaded-virtual$ make
g++ -Iinclude -Woverloaded-virtual Woverloaded-virtual.cpp -c
In file included from Woverloaded-virtual.cpp:1:
include/Woverloaded-virtual.h:4:16: warning: ‘virtual void Foo::f(int,
int)’ was hidden [-Woverloaded-virtual]
4 |   virtual void f(int, int){};
  |^
Woverloaded-virtual.cpp:8:9: warning:   by ‘virtual void Bar::f(int)’
[-Woverloaded-virtual]
8 |void f(int) final {};
  | ^


Minimal reproducible example also available here:

https://gitlab.com/loximann/woverloaded-virtual

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8aba425f4ebc5e2c054776d3cdddf13f7c1918f8

commit r10-6614-g8aba425f4ebc5e2c054776d3cdddf13f7c1918f8
Author: Jakub Jelinek 
Date:   Thu Feb 13 10:04:11 2020 +0100

sccvn: Handle bitfields in vn_reference_lookup_3 [PR93582]

The following patch is first step towards fixing PR93582.
vn_reference_lookup_3 right now punts on anything that isn't byte aligned,
so to be able to lookup a constant bitfield store, one needs to use
the exact same COMPONENT_REF, otherwise it isn't found.

This patch lifts up that that restriction if the bits to be loaded are
covered by a single store of a constant (keeps the restriction so far
for the multiple store case, can tweak that incrementally, but I think
for bisection etc. it is worth to do it one step at a time).

2020-02-13  Jakub Jelinek  

PR tree-optimization/93582
* fold-const.h (shift_bytes_in_array_left,
shift_bytes_in_array_right): Declare.
* fold-const.c (shift_bytes_in_array_left,
shift_bytes_in_array_right): New function, moved from
gimple-ssa-store-merging.c, no longer static.
* gimple-ssa-store-merging.c (shift_bytes_in_array): Move
to gimple-ssa-store-merging.c and rename to shift_bytes_in_array_left.
(shift_bytes_in_array_right): Move to gimple-ssa-store-merging.c.
(encode_tree_to_bitpos): Use shift_bytes_in_array_left instead of
shift_bytes_in_array.
(verify_shift_bytes_in_array): Rename to ...
(verify_shift_bytes_in_array_left): ... this.  Use
shift_bytes_in_array_left instead of shift_bytes_in_array.
(store_merging_c_tests): Call verify_shift_bytes_in_array_left
instead of verify_shift_bytes_in_array.
* tree-ssa-sccvn.c (vn_reference_lookup_3): For native_encode_expr
/ native_interpret_expr where the store covers all needed bits,
punt on PDP-endian, otherwise allow all involved offsets and sizes
not to be byte-aligned.

* gcc.dg/tree-ssa/pr93582-1.c: New test.
* gcc.dg/tree-ssa/pr93582-2.c: New test.
* gcc.dg/tree-ssa/pr93582-3.c: New test.

[Bug c++/93729] New: [concepts] binding bit-field to lvalue reference in requires expression should be SFINAE

[kretz at kde dot org]

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

Bug ID: 93729
   Summary: [concepts] binding bit-field to lvalue reference in
requires expression should be SFINAE
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Test case (https://godbolt.org/z/VaSCCA):

template  concept foo =
  requires(T& x, void(fun)(int &)) { fun(x.a); };

struct A {
  int a, b;
};
struct B {
  int a : 4;
  int b : 4;
};

bool a = foo;
bool b = foo;

GCC 10.0.1 20200212 errors out with: "error: cannot bind bit-field 'x.B::a' to
'int&'". Since this error only happens when substituting B for T in foo,
this should not be ill-formed and foo thus needs to be false.

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich at gcc dot gnu.org]

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

--- Comment #33 from Thomas Henlich  ---
Created attachment 47834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47834&action=edit
Proposed fix for test

Proposed test for verifying the correct output after finishing this bug.

[Bug c++/91921] Incomplete -Woverloaded-virtual warning when base class is in system header

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||loximann at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 93728 has been marked as a duplicate of this bug. ***

[Bug c++/93728] First half of warning message suppressed because code pointed to is in system header

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Already fixed.  See PR 91921.

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

[Bug target/93696] AVX512VPOPCNTDQ writemask intrinsics produce incorrect results

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6617-gae2b8ede40a81a83f50d1e705972bc46fafd4ce5
Author: Jakub Jelinek 
Date:   Thu Feb 13 10:43:27 2020 +0100

i386: Fix up _mm*_mask_popcnt_epi* [PR93696]

As mentioned in the PR and as
   
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mask_popcnt_epi
also documents, _mm*_popcnt_epi* intrinsics are consistent with all other
unary AVX512* intrinsics regarding arguments, i.e. the
_mm*_whatever has just single argument (called a in the docs, and __A in
the
GCC headers),
_mm*_mask_whatever has 3 arguments (called src, k, a in the docs and
_W, __U, __A in GCC headers) and
_mm*_maskz_whatever 2 arguments (called k, a in the docs and __U, __A in
GCC
headers).  Unfortunately, whomever implemented the _mm*_popcnt_epi*
intrinsics got it wrong for the _mm*_mask_popcnt_epi* ones, calling the
args __A, __U, __B and not passing them in the canonical order to the
builtins, making it API incompatible with ICC as well as clang (tested on
godbolts clang 7/8/9/trunk and ICC 19.0.{0,1}, older clang/ICC don't
understand those, so it isn't that it used to be broken even in other
compilers and got changed afterwards).

2020-02-13  Jakub Jelinek  

PR target/93696
* config/i386/avx512bitalgintrin.h (_mm512_mask_popcnt_epi8,
_mm512_mask_popcnt_epi16, _mm256_mask_popcnt_epi8,
_mm256_mask_popcnt_epi16, _mm_mask_popcnt_epi8,
_mm_mask_popcnt_epi16): Rename __B argument to __A and __A to __W,
pass __A to the builtin followed by __W instead of __A followed by
__B.
* config/i386/avx512vpopcntdqintrin.h (_mm512_mask_popcnt_epi32,
_mm512_mask_popcnt_epi64): Likewise.
* config/i386/avx512vpopcntdqvlintrin.h (_mm_mask_popcnt_epi32,
_mm256_mask_popcnt_epi32, _mm_mask_popcnt_epi64,
_mm256_mask_popcnt_epi64): Likewise.

* gcc.target/i386/pr93696-1.c: New test.
* gcc.target/i386/pr93696-2.c: New test.
* gcc.target/i386/avx512bitalg-vpopcntw-1.c (TEST): Fix argument order
of _mm*_mask_popcnt_*.
* gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c (TEST): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c (TEST): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntb-1.c (TEST): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntb.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntbvl.c (foo): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntd.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntwvl.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntw.c (foo): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntq.c (foo): Likewise.

[Bug target/93722] rorq is not produced for rotate on some cases

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
But, x86 doesn't have 128bit rotate.

For:

void f0 (unsigned int *a)
{
  unsigned long t0 = ((unsigned long *)a)[0];
  unsigned long t1 = t0 >> sizeof(unsigned int)*8;
  unsigned long t2 = t0 << sizeof(unsigned int)*8;

  ((unsigned long *)a)[0] = t1 | t2;
}

gcc generates:

rolq$32, (%rdi)
ret

[Bug tree-optimization/93674] [8/9/10 Regression] GCC eliminates conditions it should not, when strict-enums is on

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> I can't reproduce this with GCC 9, only 8.

Sorry, I was using -fsanitize=undefined, which prevented the miscompilation for
gcc 9.

[Bug analyzer/93388] ensure -fanalyzer works with our C code

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #12 from Arseny Solokha  ---
(In reply to David Binderman from comment #9)
>   /home/dcb/gcc/results.20200212/bin/gcc -c -O2 -fanalyzer -w $i

Optimization options seem to make a difference, as they affect the IL analyzer
works with. Could you try re-running this also w/ -O1 and -O0 and check if you
get the same results each time?

[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 Ever confirmed|0   |1

[Bug libgomp/93481] Do not fail with nowait clause

[frederik at gcc dot gnu.org]

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

Frederik Harwath  changed:

   What|Removed |Added

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

--- Comment #1 from Frederik Harwath  ---
Fixed for GCC 10.

See
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=001ab12e620c6f117b2e93c77d188bd62fe7ba03

author  Frederik Harwath 
Thu, 13 Feb 2020 06:30:16 + (07:30 +0100)
commit  001ab12e620c6f117b2e93c77d188bd62fe7ba03

openmp: ignore nowait if async execution is unsupported [PR93481]

An OpenMP "nowait" clause on a target construct currently leads to
a call to GOMP_OFFLOAD_async_run in the plugin that is used for
offloading at execution time. The nvptx plugin contains only a stub
of this function that always produces a fatal error if called.

This commit changes the "nowait" implementation to ignore the clause
if the executing device's plugin does not implement GOMP_OFFLOAD_async_run.
The stub in the nvptx plugin is removed which effectively means that
programs containing "nowait" can now be executed with nvptx offloading
as if the clause had not been used.
This behavior is consistent with the OpenMP specification which says that
"[...] execution of the target task *may* be deferred" (emphasis added),
cf. OpenMP 5.0, page 172.

libgomp/

* plugin/plugin-nvptx.c: Remove GOMP_OFFLOAD_async_run stub.
* target.c (gomp_load_plugin_for_device): Make "async_run" loading
optional.
(gomp_target_task_fn): Assert "devicep->async_run_func".
(clear_unsupported_flags): New function to remove unsupported flags
(right now only GOMP_TARGET_FLAG_NOWAIT) that can be be ignored.
(GOMP_target_ext): Apply clear_unsupported_flags to flags.
* testsuite/libgomp.c/target-33.c:
Remove xfail for offload_target_nvptx.
* testsuite/libgomp.c/target-34.c: Likewise.

[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Jason, do you think the current spec is clear enough on when the consteval
evaluation of default arguments ought to happen (and does our implementation
match that), or does it need clarification?

[Bug rtl-optimization/93730] New: [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375

[akhilesh.k at samsung dot com]

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

Bug ID: 93730
   Summary: [Bug] internal compiler error: in make_decl_rtl, at
varasm.c:1375
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akhilesh.k at samsung dot com
  Target Milestone: ---

Hello 

I am Getting "internal compiler error: in make_decl_rtl, at varasm.c:1375"
during RTL optimization, but works fine if i pass value instead of variable
name 


#g++ -c -Wno-format-truncation -Wno-narrowing MYTV/Picture.cpp
-I=/usr/include/kernel-headers/ -I=/usr/include/mylog/
-I/usr/include/kernel-interfaces/ 
during RTL pass: expand
/home/user/MY/Picture.cpp:1521:13: internal compiler error: in make_decl_rtl,
at varasm.c:1375
1521 | int GammaTable[RGB_LAST][SeedCnt] = {{0,},};   /Where my seed count
is 1024 
  | ^~

but code works fine if i pass direct Value in array 

-int GammaTable[RGB_LAST][SeedCnt] = {{0,},};
int GammaTable[RGB_LAST][1024] = {{0,},};
#g++ -c -Wno-format-truncation -Wno-narrowing MYTV/Picture.cpp
-I=/usr/include/kernel-headers/ -I=/usr/include/mylog/
-I/usr/include/kernel-interfaces/ 
#

Unfortunately I can share Picture.cpp code 
but I am trying to reproduce this issue with some sample test application

[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
This is https://github.com/cplusplus/nbballot/issues/167

In CWG today we decided that since this is all compiler magic anyway, we can be
a bit more magical to get around this problematic interaction with consteval.

[Bug c++/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
It is easy to prevent the ICE with the following, which prevents total
scalarization from happening.  However, if someone marked a field with
such an attribute, the encompassing structure perhaps should be
optimized a much as we can?

So I am thinking of adding a predicate
bunch_of_empty_records_p which will return true for a type which only
consists of records which only have field_decls which are other
records but nothing else and still allow total scalarization of
those.

The easy fix is:

--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -958,6 +958,9 @@ scalarizable_type_p (tree type, bool const_decl)
   if (type_contains_placeholder_p (type))
 return false;

+  bool have_predecesor_field = false;
+  HOST_WIDE_INT prev_pos = 0;
+
   switch (TREE_CODE (type))
   {
   case RECORD_TYPE:
@@ -966,6 +969,14 @@ scalarizable_type_p (tree type, bool const_decl)
{
  tree ft = TREE_TYPE (fld);

+ HOST_WIDE_INT pos = int_bit_position (fld);
+ if (have_predecesor_field
+ && pos <= prev_pos)
+   return false;
+
+ have_predecesor_field = true;
+ prev_pos = pos;
+
  if (DECL_BIT_FIELD (fld))
return false;

[Bug sanitizer/93731] New: [10 regression] asan tests cause kernel panic on Darwin 11

[ro at gcc dot gnu.org]

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

Bug ID: 93731
   Summary: [10 regression] asan tests cause kernel panic on
Darwin 11
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
iains 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: ---
  Host: x86_64-apple-darwin11.4.2
Target: x86_64-apple-darwin11.4.2
 Build: x86_64-apple-darwin11.4.2

Sometime after 20191101, my mainline bootstraps on Mac OS X 10.7/Darwin 11
began
to fail completely.  Initially it seemed the Mac minis I've been using remotely
had just been turned off willy-nilly, but even after it had been assured that
this
wasn't the case, the machines still stopped in the middle of make check without
any indication of what had happened.

Only after I'd run such a bootstrap in a VirtualBox VM (with Mac OS X 10.7.5)
did
I see that the machines (obviously like bare metal) crashed with a kernel panic
for some asan tests (I've seen alloca_big_alignment.exe,
alloca_detect_custom_size. and bitfield-1.exe).  Only asan tests seem to be
affected (I didn't try any more given the tedious nature of the failure) and
probably only 64-bit ones (I do run multilib tests on Darwin if possible).

As expected, the ubsan tests still work.

Here's the gist of the panics (I do have screen shots if need be):

panic(cpu 0 caller 0xff8002c4794): Kernel trap at 0xff800053ae2, type
14=page fault, registers:
[...]

Debugger called: 
Backtrace (CPU 0),Frame : Return Address
[...] mach_kernel : _panic + 0x252
_kernel_trap + 0x6a4
_return_from_trap + 0xcd
_fdexec + 0x172
_kco_ma_addsample + 0x162c
_kco_ma_addsample + 0x2a80
_posix_spawn + 0xab6
_unix_syscall64 + 0x1fb
_hndl_unix_scall64 + 0x13

BSD process name corresponding to current thread: alloca_big_align

The obvious immediate fix is to disable libsanitizer on Darwin 11.  While in
theory one could keep the 32-bit tests if it really turns out that they
continue
to work and the ubsan ones, it's probably not worth the effort given the age of
the OS version and missing provision for enabling ubsan separately.

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug fortran/93715] [9/10 Regression] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:6320

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 CC||markeggleston at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Confirmed using compiler built at commit
https://gcc.gnu.org/g:8ea884b85e338d09b14e6a54043c53ae0c1b1fe9

ICE also occurs for 9.1 and 9.2 releases.

[Bug rtl-optimization/93730] [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-02-13
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please provide a testcase.  What architecture is this on?

[Bug rtl-optimization/93730] [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375

[akhilesh.k at samsung dot com]

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

--- Comment #2 from Akhilesh Kumar  ---
Working on Arm architecture.
I am trying to reproduce the same with sample test case

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
So you could just disable asan and keep ubsan (set ASAN_SUPPORTED=no in
libsanitizer/configure.tgt for a particular darwin OS version, and if it is
32-bit only, also test x$ac_cv_sizeof_void_p = x4 ?
Of course, trying to workaround kernel bugs this way is weird, but if it isn't
supported anymore or Apple isn't willing to fix their bugs...

[Bug c++/93639] [c++2a] Segfault on non type template parameter and consteval (master)

[raphael.grimm at kit dot edu]

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

--- Comment #4 from raphael grimm  ---
Created attachment 47835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47835&action=edit
reduced to 11 lines and no includes

http://coliru.stacked-crooked.com/a/be3bbfdf6a59b45e

on g++ (GCC) 9.2.0

output:

main.cpp:8:26: internal compiler error: Segmentation fault
8 | using type = B;
  |  ^
0xb5c5ff crash_signal
../.././gcc/toplev.c:326
0x5cb5c3 resolve_args
../.././gcc/cp/call.c:4350
0x5da0c7 build_new_function_call(tree_node*, vec**, int)
../.././gcc/cp/call.c:4469
0x6bbeaf do_class_deduction
../.././gcc/cp/pt.c:27497
0x6bbeaf do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../.././gcc/cp/pt.c:27556
0x6c492d convert_template_argument
../.././gcc/cp/pt.c:8086
0x6c492d convert_template_argument
../.././gcc/cp/pt.c:7859
0x6cf795 coerce_template_parms
../.././gcc/cp/pt.c:8589
0x6d0b2a lookup_template_class_1
../.././gcc/cp/pt.c:9399
0x6d0b2a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../.././gcc/cp/pt.c:9769
0x6ebe5d finish_template_type(tree_node*, tree_node*, int)
../.././gcc/cp/semantics.c:3312
0x6929c5 cp_parser_template_id
../.././gcc/cp/parser.c:16481
0x692b07 cp_parser_class_name
../.././gcc/cp/parser.c:23276
0x695790 cp_parser_qualifying_entity
../.././gcc/cp/parser.c:6696
0x695790 cp_parser_nested_name_specifier_opt
../.././gcc/cp/parser.c:6382
0x6931f5 cp_parser_simple_type_specifier
../.././gcc/cp/parser.c:17839
0x68a1a5 cp_parser_type_specifier
../.././gcc/cp/parser.c:17507
0x69d118 cp_parser_type_specifier_seq
../.././gcc/cp/parser.c:21985
0x69a4b4 cp_parser_type_id_1
../.././gcc/cp/parser.c:21814
0x69e902 cp_parser_type_id
../.././gcc/cp/parser.c:21893
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/93732] New: [10 Regression] Incorrect symbol type when activating LTO a compile step

[laurent.stacul at gmail dot com]

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

Bug ID: 93732
   Summary: [10 Regression] Incorrect symbol type when activating
LTO a compile step
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: laurent.stacul at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello,

With gcc (GCC) 10.0.1 20200211 and the following program:

#ifdef __cplusplus
extern "C" {
#endif
char nm_test_var;
void nm_test_func(void);
void nm_test_func(void){}
#ifdef __cplusplus
}
#endif
int main(){nm_test_var='a';nm_test_func();return(0);}

If you compile with the LTO support, with the command:

$  gcc -c  -DNDEBUG -O3 -std=gnu17 -fno-working-directory -ggdb3 -flto
-ffat-lto-objects -fuse-linker-plugin conftest.c

The symbol nm_test_var will be flagged as in text section.

$ nm conftest.o
 T main
 T nm_test_func
 T nm_test_var

Whereas, compiling without LTO support as follow:

$ $  gcc -c  -DNDEBUG -O3 -std=gnu17 -fno-working-directory -ggdb3 -fno-lto
-ffat-lto-objects -fuse-linker-plugin conftest.c

Will give:

$ nm conftest.o
 T main
 T nm_test_func
 B nm_test_var

I also compared with gcc (GCC) 9.2.1 20191112. With or without LTO, the result
is the same but the symbol nm_test_var is neither in the text section not in
the BSS one, but in the common section:

 T main
 T nm_test_func
 C nm_test_var

For info, this leads to errors when you build libtoolized libraries (error at
configure step).

Regards,
Laurent

[Bug inline-asm/93027] ICE: in match_reload, at lra-constraints.c:1060

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So fixed for trunk?  GCC 9 seems to ICE on this too in the same spot (but with
-fchecking only or --enable-checking=yes), GCC 8 in extract_constraint_insn
(but again with checking only).

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Jakub Jelinek  ---
> So you could just disable asan and keep ubsan (set ASAN_SUPPORTED=no in
> libsanitizer/configure.tgt for a particular darwin OS version, and if it is
> 32-bit only, also test x$ac_cv_sizeof_void_p = x4 ?

Right now there's only [LT]SAN_SUPPORTED in configure.{ac,tgt}.  Sure
ASAN_SUPPORTED (and/or UBSAN_SUPPORTED) could be added, but I doubt it's
worth the effort.

I have a prototype patch that just sets UNSUPPORTED=1 for *86*-apple-darwin11*.

> Of course, trying to workaround kernel bugs this way is weird, but if it isn't
> supported anymore or Apple isn't willing to fix their bugs...

Mac OS X 10.7 is almost 9 years old by now and long past support.  I
don't feel particularly inclined to reghunt which gcc/sanitizer change
caused this, let alone debug the Darwin kernel either.

[Bug lto/93732] [10 Regression] Incorrect symbol type when activating LTO a compile step

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 93609.  The issue is mostly inside binutils.  The duplicated bug
report explains more.

-fno-common is the default which caused the major difference between the
versions and why it is a regression.

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

[Bug lto/93609] gcc -flto -fno-comon places symbols into ".text" section

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||laurent.stacul at gmail dot com

--- Comment #4 from Andrew Pinski  ---
*** Bug 93732 has been marked as a duplicate of this bug. ***

[Bug target/93722] rorq is not produced for rotate on some cases

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
q is quad word where word is really 16bits.  Stupid x86 world where things are
confusing :).

[Bug middle-end/93576] [8/9/10 Regression] internal compiler error: Segmentation fault (in gimplify.c)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 47836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47836&action=edit
gcc10-pr93576.patch

Untested fix.

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

[dave.anglin at bell dot net]

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

--- Comment #168 from dave.anglin at bell dot net ---
On 2020-02-13 12:24 a.m., peter.bisroev at groundlabs dot com wrote:
> Tonight I have been trying to find a test case where this problem can be
> reproduced with gcc and then compiled with aCC. Unfortunately no luck so far. 
>
> With objdump I can see PCREL21B relocations in my .o files. However after the
> final linking, disassembly shows direct short branch if the distance is small
> enough and a call through a stub with brl.few if the distance is large enough.
> I have almost no experience with IA-64 arch, but this behavior seems expected
> to me.
The ia64 PCREL21B relocation is very similar to the PA-RISC 2.0
R_PARISC_PCREL22F relocation.
These determine the maximum branch distance by a pc-relative branch.  I believe
ia64 aligns
code on 8-byte boundaries.  PA-RISC aligns on 4-byte boundaries.  So, in both
cases a branch
is capable of branching about 8 MB from call point.

There seems to be something broken regarding stub insertion for calls to weak
functions.  Are we
using the correct branch form for calls to weak?  There doesn't seem to be a
problem with branches
to functions that aren't defined in the module.

Could you try compiling sancov.c from gcc-8 with aCC in C++ mode.  Use -S to
get assembler output.
What happens to weak calls (e.g., the one I pointed out previously)?

Dave

[Bug fortran/93733] New: F2008: G0.d output editing for integer/logical/character data

[thenlich at gcc dot gnu.org]

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

Bug ID: 93733
   Summary: F2008: G0.d output editing for
integer/logical/character data
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thenlich at gcc dot gnu.org
  Target Milestone: ---

This example compiles and runs.

But the second part should be rejected with -std=f2008 because these are
Fortran 2018 features.


program g0d_ilc
!F2008:
write(*, "(g0)")  23
write(*, "(g0)")  .true.
write(*, "(g0)")  'hello'
!F2018:
write(*, "(g0.2)")  -23
write(*, "(g0.2)")  .true.
write(*, "(g0.2)")  'hello'
end


gfortran -std=f2008 g0d_ilc.f90 && ./a.out
23
T
hello
-23
T
hello


The new features of Fortran 2018 (ISO/IEC JTC1/SC22/WG5 N2145):

"The g0.d edit descriptor can be used to specify the output of integer,
logical, and character data. It follows the rules for the i0, l1, and a edit
descriptors, respectively."

F2008:

10.7.5.2.1 Generalized integer editing
When used to specify the input/output of integer data, the Gw.d and Gw.d Ee
edit descriptors follow the rules for the Iw edit descriptor (10.7.2.2), except
that w shall not be zero. When used to specify the output of integer data, the
G0 edit descriptor follows the rules for the I0 edit descriptor.

10.7.5.3 Generalized logical editing
When used to specify the input/output of logical data, the Gw.d and Gw.d Ee
edit descriptors follow the rules for the Lw edit descriptor (10.7.3). When
used to specify the output of logical data, the G0 edit descriptor follows the
rules for the L1 edit descriptor. 

10.7.5.4 Generalized character editing
When used to specify the input/output of character data, the Gw.d and Gw.d Ee
edit descriptors follow the rules for the Aw edit descriptor (10.7.4). When
used to specify the output of character data, the G0 edit descriptor follows
the rules for the A edit descriptor with no field width.

F2018:

13.7.5.2.2 Generalized integer editing
When used to specify the input/output of integer data, the Gw, Gw.d, and Gw.d
Ee edit descriptors follow the rules for the Iw edit descriptor (13.7.2.2).
Note that w cannot be zero for input editing (13.7.5.1). 

13.7.5.3 Generalized logical editing
When used to specify the input/output of logical data, the Gw.d and Gw.d Ee
edit descriptors with nonzero w follow the rules for the Lw edit descriptor
(13.7.3). When used to specify the output of logical data, the G0 and G0.d edit
descriptors follow the rules for the L1 edit descriptor. 

13.7.5.4 Generalized character editing
When used to specify the input/output of character data, the Gw.d and Gw.d Ee
edit descriptors with nonzero w follow the rules for the Aw edit descriptor
(13.7.4). When used to specify the output of character data, the G0 and G0.d
edit descriptors follow the rules for the A edit descriptor with no field
width.

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
Patch in comment 1 produces:

z1.f90 -> pr93714_1.f90

pr93714_1.f90:3:4:

3 |character, pointer :: b => a
  |1
Error: Unclassifiable statement at (1)
pr93714_1.f90:2:13:

2 |character((1.)) :: a
  | 1
Error: Expression at (1) must be of INTEGER type, found REAL

z2.f90 -> pr93714_1.f90

pr93714_2.f90:3:4:

3 |character(:), pointer :: b => a
  |1
Error: Unclassifiable statement at (1)
pr93714_2.f90:2:13:

2 |character((9.)), target :: a
  | 1
Error: Expression at (1) must be of INTEGER type, found REAL

Can do better than "Unclassifiable statement".

Moving the check for lvalue being a character to after the handling of pointer
and target attributes:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index a9698c3e3d2..79e00b4112a 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4222,13 +4222,6 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue,
   if (rvalue->expr_type == EXPR_NULL)
 return true;

-  if (lvalue->ts.type == BT_CHARACTER)
-{
-  bool t = gfc_check_same_strlen (lvalue, rvalue, "pointer assignment");
-  if (!t)
-   return false;
-}
-
   if (rvalue->expr_type == EXPR_VARIABLE && is_subref_array (rvalue))
 lvalue->symtree->n.sym->attr.subref_array_pointer = 1;

@@ -4284,6 +4277,13 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue,
}
 }

+  if (lvalue->ts.type == BT_CHARACTER)
+{
+  bool t = gfc_check_same_strlen (lvalue, rvalue, "pointer assignment");
+  if (!t)
+   return false;
+}
+
   if (is_pure && gfc_impure_variable (rvalue->symtree->n.sym))
 {
   gfc_error ("Bad target in pointer assignment in PURE "

and omitting Steve Kargl's patch results in:

pr93714_1.f90:3:31:

3 |character, pointer :: b => a
  |   1
Error: Pointer assignment target in initialization expression does not have the
TARGET attribute at (1)
pr93714_1.f90:2:13:

2 |character((1.)) :: a
  | 1
Error: Expression at (1) must be of INTEGER type, found REAL

and

pr93714_2.f90:3:34:

3 |character(:), pointer :: b => a
  |  1
Error: Pointer assignment target in initialization expression does not have the
TARGET attribute at (1)
pr93714_2.f90:2:13:

2 |character((9.)) :: a
  | 1
Error: Expression at (1) must be of INTEGER type, found REAL

Running make with check-fortran resulted in char_pointer_assign_6.f90 failing:

char_pointer_assign_6.f90:8:2:

8 |   p1 => s1(2:3) ! { dg-error "Unequal character lengths \\(20/2\\)" }
  |  1
Error: Unequal character lengths (20/2) in pointer assignment at (1)
char_pointer_assign_6.f90:9:8:

9 |   p1 => c(1:) ! { dg-error "Unequal character lengths \\(20/4\\)" }
  |1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
char_pointer_assign_6.f90:10:8:

   10 |   p1 => c(:4) ! { dg-error "Unequal character lengths \\(20/4\\)" }
  |1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)

The variable c does not have the target attribute so the unequal character
lengths messages should not have occurred.

I'm now modifying char_pointer_assign_6.f90 and adding test cases so I can send
a patch upstream for approval.

[Bug target/93656] FAIL: gcc.target/i386/pr67770.c execution test with -fcf-protection

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r10-6622-g1d69147af203d4dcd2270429f90c93f1a37ddfff
Author: H.J. Lu 
Date:   Thu Feb 13 05:28:38 2020 -0800

i386: Skip ENDBR32 at the target function entry

Skip ENDBR32 at the target function entry when initializing trampoline.

Tested on Linux/x86-64 CET machine with and without -m32.

gcc/

PR target/93656
* config/i386/i386.c (ix86_trampoline_init): Skip ENDBR32 at
the target function entry.

gcc/testsuite/

PR target/93656
* gcc.target/i386/pr93656.c: New test.

[Bug fortran/93734] New: Invalid code generated with -O2 -march=haswell -ftree-vectorize

[bartoldeman at users dot sourceforge.net]

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

Bug ID: 93734
   Summary: Invalid code generated with -O2 -march=haswell
-ftree-vectorize
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bartoldeman at users dot sourceforge.net
  Target Milestone: ---

Created attachment 47837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47837&action=edit
Fortran code that prints 0 if correct, and -9 if miscompiled

The attached code prints -9. if compiled using

gfortran -O2 -march=haswell -ftree-vectorize bug.f90 -o bug
./bug
  -9.
using
GNU Fortran (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

also reproduceable on GCC 9.2.0, but not with GCC 7.3.0 and earlier.

The correct answer is 1-1=0.

(I found this issue first when compiling the reference BLAS using those options
and running the "zblat2" tests, the test is a much reduced version of ztrsv,
see
http://www.netlib.org/lapack/explore-html/dc/dc1/group__complex16__blas__level2_ga99cc66f0833474d6607e6ea7dbe2f9bd.html#ga99cc66f0833474d6607e6ea7dbe2f9bd)

[Bug gcov-profile/93735] New: [GCOV] incorrect coverage for calling variable arguments function with incremental expression in its parameter list

[yangyibiao at hust dot edu.cn]

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

Bug ID: 93735
   Summary: [GCOV] incorrect coverage for calling variable
arguments function with incremental expression in its
parameter list
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcov -v
gcov (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or 
FITNESS FOR A PARTICULAR PURPOSE.


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)

$ cat small.c
int v = 8;

__attribute__((noinline)) int foo(int x, int y, ...) { return x; }

inline __attribute__((always_inline, gnu_inline)) int bar(int x, ...) { return
foo(x, 1, 2); }

int main(void)
{
  bar(0, ++v, 1);
  if (bar(0, ++v, 1) != 0)
return 1;
  return 0;
}


$ gcc -O0 -g --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:71.43% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:int v = 8;
-:2:
2:3:__attribute__((noinline)) int foo(int x, int y, ...) { return x; }
-:4:
#:5:inline __attribute__((always_inline, gnu_inline)) int bar(int x,
...) { return foo(x, 1, 2); }
-:6:
1:7:int main(void)
-:8:{
1:9:  bar(0, ++v, 1);
2:   10:  if (bar(0, ++v, 1) != 0)
#:   11:return 1;
1:   12:  return 0;
-:   13:}



### We can find that: Line #9 is marked as executed one time. 
### However, Line #10 is wrongly marked as executed two times. 
### when removing ++v in its parameter list, the coverage will be correct. 

[Bug tree-optimization/93734] [8/9/10 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.5.0
   Keywords||wrong-code
   Last reconfirmed||2020-02-13
  Component|fortran |tree-optimization
 Blocks||53947
 Ever confirmed|0   |1
Summary|Invalid code generated with |[8/9/10 Regression] Invalid
   |-O2 -march=haswell  |code generated with -O2
   |-ftree-vectorize|-march=haswell
   ||-ftree-vectorize
   Target Milestone|--- |8.4
  Known to fail||10.0, 8.1.0, 8.3.1, 9.1.0,
   ||9.2.1

--- Comment #1 from Richard Biener  ---
It works fine with GCC 7.5.


Referenced Bugs:

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

[Bug tree-optimization/93734] [8/9/10 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||10.0
  Known to fail|10.0|

--- Comment #2 from Richard Biener  ---
Hmm, it seems to be fixed on trunk.

Testcase that aborts on failure, we probably have a duplicate.

subroutine test(incx)
  implicit none
  integer i,incx,jx
  double complex a(5),x(9),temp

  a(1:4)=1
  a(5)=10
  x(1:9)=1

  jx = 9
  temp = x(9)
  do i = 4,1,-1
 jx = jx - incx
 x(jx) = x(jx) - temp*a(i)
  enddo

  if (x(5).ne.0) call abort
end subroutine test

program bug
  call test(2)
end program bug

[Bug tree-optimization/93734] [8/9/10 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
I tried to make an equivalent C testcase, but complex ops don't map 1:1 from
Fortran, so it's a bit difficult. Nevertheless, here's a somewhat similar
testcase that aborts on 8/9, works on trunk, but IR and resulting assembly look
quite different:

( needs -O2 -ftree-vectorize -mfma -fcx-limited-range )

__attribute__((noipa))
static
_Complex double
test(_Complex double * __restrict a,
 _Complex double * __restrict x,
 _Complex double t, long jx)
{
long i, j;

for (j = 6, i = 3; i>=0; i--, j-=jx)
x[j] -= t*a[i];

return x[4];
}

int main()
{
_Complex double a[5] = {1, 1, 1, 1, 10};
_Complex double x[9] = {1,1,1,1,1,1,1,1,1};
if (test(a, x, 1, 2))
__builtin_abort();
}

[Bug c++/93705] [C++2a] Non-type literal class template-parameter types with mutable data members should not be allowed

[kevin at hart dot mn]

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

Kevin Hartman  changed:

   What|Removed |Added

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

--- Comment #1 from Kevin Hartman  ---
I misread the spec. “Non-mutable” means “not marked with the ‘mutable’
specifier.

[Bug fortran/93736] New: Add .f18 and .F18 file suffixes

[thenlich at gcc dot gnu.org]

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

Bug ID: 93736
   Summary: Add .f18 and .F18 file suffixes
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thenlich at gcc dot gnu.org
  Target Milestone: ---

The Fortran compiler should recognize Fortran source files with the .f18 and
.F18 filename extension.

[Bug fortran/93736] Add .f18 and .F18 file suffixes

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
IMHO, this should be closed.  The file naming scheme does not imply a standard.
 It implies fixed-form versus free-form.  It was a mistake to add f03, f08,
etc.

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/93678] ICE in 9.2/9.2.1 not happening in previous gfortran versions

[mail.luis at web dot de]

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

--- Comment #2 from Luis Kornblueh  ---
Created attachment 47838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47838&action=edit
New testcase

[Bug fortran/93678] ICE in 9.2/9.2.1 not happening in previous gfortran versions

[mail.luis at web dot de]

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

--- Comment #3 from Luis Kornblueh  ---
Thanks @kargl for simplifing my still very long case. However, a bug has been
introduced in this version.

The nested transfers cannot be split into two as the result of the first
transfer is not a character :: c(1) result, but, in the nested case a 
presumably  character :: tmp(4) array to keep an integer. which gets passed to
the outer transfer. A write another, a bit bigger case, doing things correctly.

I created a new testcase, a little bit larger, but, as I think, correct
Fortran.

[Bug tree-optimization/93734] [8/9/10 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
#c2 isn't miscompiled since r10-4543-g599bd99078439b9f11cb271aa919844318381ec5
and the miscompilation started with
r8-6708-g85c5e2f576fd41e1ab5620cde3c63b3ca6673bea

[Bug c++/93713] [10 Regression] ICE in equivalently_constrained, at cp/constraint.cc:2949

[jason at gcc dot gnu.org]

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

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 fortran/93736] Add .f18 and .F18 file suffixes

[thenlich at gcc dot gnu.org]

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

--- Comment #2 from Thomas Henlich  ---
I don't know why the Fortran compiler doesn't treat all files as free-form
Fortran source files, unless they have a known extension indicating otherwise.

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

[peter.bisroev at groundlabs dot com]

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

Peter Bisroev  changed:

   What|Removed |Added

  Attachment #47829|0   |1
is obsolete||

--- Comment #169 from Peter Bisroev  ---
Created attachment 47839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47839&action=edit
GCC 4.9.4 gimple-expr.c dump (aCC)

[Bug fortran/93678] ICE in 9.2/9.2.1 not happening in previous gfortran versions

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Thu, Feb 13, 2020 at 03:46:17PM +, mail.luis at web dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
> 
> --- Comment #3 from Luis Kornblueh  ---
> Thanks @kargl for simplifing my still very long case. However, a bug has been
> introduced in this version.
> 
> The nested transfers cannot be split into two as the result of the first
> transfer is not a character :: c(1) result, but, in the nested case a 
> presumably  character :: tmp(4) array to keep an integer. which gets passed to
> the outer transfer. A write another, a bit bigger case, doing things 
> correctly.
> 
> I created a new testcase, a little bit larger, but, as I think, correct
> Fortran.
> 

I was trying to get to the minimum code required to
trigger the bug.

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
These systems are EOL so we can't expect any fixes to the systems themselves.

The question is "is the latest imported as an version even supposed to support
10.7"?

I have a patch to unsupport the sanitiser for <= 10.6 [where it has been
unsupported upstream since at least the last release].  That is something that
I can apply immediately.

If the latest sanitiser code is _supposed_ to work on 10.7 - we should at least
take a cursory look at why/where it's failing before punting.

I agree that spending much time on making the sanitisers work on EOL machines
is not a priority.  I don't have access to my 10.7 box right now - but will
take a look next week.

[Bug tree-optimization/93737] New: inline memmove for insertion into small arrays

[msebor at gcc dot gnu.org]

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

Bug ID: 93737
   Summary: inline memmove for insertion into small arrays
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC emits what's likely more efficient code for the insertion of elements into
the middle of small arrays by copying parts of the array into a temporary
buffer than it does for straight calls to memmove that achieve the same result
without the temporary buffer.

The example below shows the difference.  Clang emits the same, presumably
optimally efficient, code for both functions as GCC does for f0.

$ cat t.c && gcc -DN=32 -O2 -S -Wall -o/dev/stdout t.c
int a[N];

void f0 (int x)
{
  int b[N];
  __builtin_memcpy (b, a + 1, sizeof a - sizeof *a);
  __builtin_memcpy (a + 2, b, sizeof a - 2 * sizeof *a);
  a[1] = x;
}

void f2 (int x)
{
  __builtin_memmove (a + 2, a + 1, sizeof a - 2 * sizeof *a);
  a[1] = x;
}


.file   "t.c"
.text
.p2align 4
.globl  f0
.type   f0, @function
f0:
.LFB0:
.cfi_startproc
subq$16, %rsp
.cfi_def_cfa_offset 24
movdqu  a+20(%rip), %xmm5
movdqu  a+36(%rip), %xmm4
movdqu  a+52(%rip), %xmm3
movdqu  a+68(%rip), %xmm2
movdqu  a+84(%rip), %xmm1
movdqu  a+100(%rip), %xmm0
movups  %xmm5, a+24(%rip)
movqa+116(%rip), %rax
movdqu  a+4(%rip), %xmm6
movups  %xmm4, a+40(%rip)
movl%edi, a+4(%rip)
movq%rax, a+120(%rip)
movups  %xmm6, a+8(%rip)
movups  %xmm3, a+56(%rip)
movups  %xmm2, a+72(%rip)
movups  %xmm1, a+88(%rip)
movups  %xmm0, a+104(%rip)
addq$16, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   f0, .-f0
.p2align 4
.globl  f2
.type   f2, @function
f2:
.LFB1:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$120, %edx
movl%edi, %ebx
movl$a+4, %esi
movl$a+8, %edi
callmemmove
movl%ebx, a+4(%rip)
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size   f2, .-f2
.globl  a
.bss
.align 32
.type   a, @object
.size   a, 128
a:
.zero   128
.ident  "GCC: (GNU) 10.0.1 20200212 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/93737] inline memmove for insertion into small arrays

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90262

--- Comment #1 from Martin Sebor  ---
A similar, if not the same, improvement is tracked in pr90262.

[Bug fortran/93736] Add .f18 and .F18 file suffixes

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Thu, Feb 13, 2020 at 04:40:08PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736
> 
> --- Comment #2 from Thomas Henlich  ---
> I don't know why the Fortran compiler doesn't treat all files as free-form
> Fortran source files, unless they have a known extension indicating otherwise.

I suppose it has something to do with the fact that gfortran
will accept languages other than Fortran.

% gfortran9 -o z hello.c 
% ./z
hello

If you're really keen on the idea of adding yet another 
useless extension.  Look in gcc/fortran/lang-specs.h.

In 70 years, when F2090 is released, I'll let the next
generation deal with .F90 and .f90. :-)

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 CC||msebor at gcc dot gnu.org
  Known to work||7.3.0
Summary|internal compiler error: in |[8/9/10 Regression]
   |force_constant_size, at |internal compiler error: in
   |gimplify.c:733  |force_constant_size, at
   ||gimplify.c:733
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.0, 9.2.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  Bisection points to r256748 (GCC 8):

commit 47c268c4b27782717fbccec5019e0cd97d005afb
Author: Jakub Jelinek 
Date:   Tue Jan 16 16:18:24 2018 +0100

re PR libgomp/83590 ([nvptx] openacc reduction C regressions)

PR libgomp/83590
* gimplify.c (gimplify_one_sizepos): For is_gimple_constant (expr)
return early, inline manually is_gimple_sizepos.  Make sure if we
call gimplify_expr we don't end up with a gimple constant.
* tree.c (variably_modified_type_p): Don't return true for
is_gimple_constant (_t).  Inline manually is_gimple_sizepos.
* gimplify.h (is_gimple_sizepos): Remove.

Co-Authored-By: Richard Biener 

From-SVN: r256748

[Bug c/93572] [8/9/10 Regression] internal compiler error: q from h referenced in main

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 CC||msebor at gcc dot gnu.org
  Known to work||4.4.3
Summary|internal compiler error: q  |[8/9/10 Regression]
   |from h referenced in main   |internal compiler error: q
   ||from h referenced in main
 Ever confirmed|0   |1
  Known to fail||10.0, 4.5.3, 4.6.4, 4.7.4,
   ||4.8.4, 4.9.4, 5.5.0, 6.4.0,
   ||7.2.0, 8.0, 9.2.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  Bisection points to r145256 (4.5.0):

commit 2ec5deb5c3146cdaf0119ebf7f37df6e57f1521d
Author: Paolo Bonzini 
Date:   Sun Mar 29 18:26:43 2009 +

c-common.c (c_expand_expr, c_staticp): Remove.

2009-03-28  Paolo Bonzini  

* c-common.c (c_expand_expr, c_staticp): Remove.
* c-common.def (COMPOUND_LITERAL_EXPR): Delete.
* c-common.h (emit_local_var, c_staticp,
COMPOUND_LITERAL_EXPR_DECL,
COMPOUND_LITERAL_EXPR_DECL_EXPR): Remove.
* c-gimplify.c (gimplify_compound_literal_expr,
optimize_compound_literals_in_ctor): Remove.
(c_gimplify_expr): Remove COMPOUND_LITERAL_EXPR handling.
* c-objc-common.h (LANG_HOOKS_STATICP): Remove.
* c-semantics.c (emit_local_var): Remove.

* langhooks-def.h (lhd_expand_expr): Remove.
* langhooks.c (lhd_expand_expr): Remove.
* langhooks.h (LANG_HOOKS_DEF): Remove LANG_HOOKS_EXPAND_EXPR.

* expr.c (expand_expr_real_1): Move COMPOUND_LITERAL_EXPR
handling from c-semantics.c; don't call into langhook.
(expand_expr_addr_expr_1): Check that we don't get non-GENERIC
trees.
* gimplify.c (gimplify_compound_literal_expr,
optimize_compound_literals_in_ctor): Move from c-gimplify.c.
(gimplify_init_constructor): Call
optimize_compound_literals_in_ctor.
(gimplify_modify_expr_rhs, gimplify_expr): Handle
COMPOUND_LITERAL_EXPR
as was done in c-gimplify.c.
* tree.c (staticp): Move COMPOUND_LITERAL_EXPR handling from
c_staticp.
* tree.h (COMPOUND_LITERAL_EXPR_DECL,
COMPOUND_LITERAL_EXPR_DECL_EXPR):
Move from c-common.h.
* tree.def (COMPOUND_LITERAL_EXPR): Move from c-common.def.

* tree.c (staticp): Do not call langhook.
* langhooks.c (lhd_staticp): Delete.
* langhooks-def.h (lhd_staticp): Delete prototype.
(LANG_HOOKS_STATICP): Delete.
(LANG_HOOKS_INITIALIZER): Delete LANG_HOOKS_STATICP.

* doc/c-tree.texi (Expression nodes): Refer to DECL_EXPRs
instead of DECL_STMTs.

cp:
2009-03-28  Paolo Bonzini  

* cp/cp-objcp-common.h (LANG_HOOKS_STATICP): Remove.
* cp/cp-objcp-common.c (cxx_staticp): Remove.
* cp/cp-tree.h (cxx_staticp): Remove.

From-SVN: r145256

[Bug fortran/93736] Add .f18 and .F18 file suffixes

[thenlich at gcc dot gnu.org]

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

Thomas Henlich  changed:

   What|Removed |Added

   Priority|P3  |P5

--- Comment #4 from Thomas Henlich  ---
Additionally, we could also imply -std=f2018 with the .f18/.F18 suffix. That
would make them more useful.

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

[peter.bisroev at groundlabs dot com]

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

Peter Bisroev  changed:

   What|Removed |Added

  Attachment #47839|0   |1
is obsolete||

--- Comment #170 from Peter Bisroev  ---
Created attachment 47840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47840&action=edit
GCC 4.9.4 gimple-expr.c dump (aCC) V3

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

[peter.bisroev at groundlabs dot com]

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

--- Comment #171 from Peter Bisroev  ---
Comment on attachment 47839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47839
GCC 4.9.4 gimple-expr.c dump (aCC)

Obsoleted by attachment 47840 as in this attachment inlining with aCC was not
fully disabled.

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

[peter.bisroev at groundlabs dot com]

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

--- Comment #172 from Peter Bisroev  ---
Hi Dave,

(In reply to dave.anglin from comment #168)
> There seems to be something broken regarding stub insertion for calls to
> weak functions.  Are we
> using the correct branch form for calls to weak?  There doesn't seem to be a
> problem with branches
> to functions that aren't defined in the module.
> 
> Could you try compiling sancov.c from gcc-8 with aCC in C++ mode.  Use -S to
> get assembler output.
> What happens to weak calls (e.g., the one I pointed out previously)?

Unfortunately as mentioned in comment 165 I was unable to get aCC to compile
sancov.c from gcc 8.3.0 or use HP's assember with gcc generated .s output.
However I was able to reproduce the same relocation issue when attempting to
compile gcc 4.9.4 and at the same time was able to compile one of the
problematic files (gimple-expr.c) with aCC as well.

I have attached relevant results as you have requested in attachment 47828. But
I did not see the relevant functions appearing in object file compiled with aCC
(attachment 47829). I took a look at it a bit more last night and realized that
the code that was causing relocation issues with gcc was not compiled in when
using aCC. After a bit of mucking around with aCC to approximate compilations
options to as close as possible to gcc ones (so -O0, no inlining, target arhc,
etc...) and enabling gnu mode and a few defines allowed me to compile the
relevant parts in to the object. You can see the .o and .s from aCC as well as
a few more dumps in attachment 47840.

Just to make sure I do not waste your time, I tried to get some info for you
from the gcc dumps (attachment 47828) as you have previously requested for
sancov.c (please let me know if I made any mistakes there).

Original linker error was:

ld: The value 0xfdf81640 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file
libbackend.a[gimple-expr.o]


Looking for section 59's name and confirming with readlef:

$ elfdump -C -D 59 -h gimple-expr.o

gimple-expr.o:

*** Section Header ***

Idx: 59  
  Section: .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
  Type:PBIT   Flags:   -- EA-  
  Vaddr:   0x Offset:  0xcd50
  Size:0x0240 Link:  
  Info:   Align:   0x0010
  Entsize: 0x

$ readelf -S -W gimple-expr.o | grep '\[59\]'   
  [59] .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_ PROGBITS 
   00cd50 000240 00  AX  0   0 16


Dumping relocations for this section:

$ objdump -r -j .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
gimple-expr.o

gimple-expr.o: file format elf32-ia64-hpux-big

RELOCATION RECORDS FOR
[.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_]:
OFFSET   TYPE  VALUE 
0071 LTOFF22X  .rodata
0080 LDXMOV.rodata
0082 LTOFF22X  .rodata+0x0188
0090 LDXMOV.rodata+0x0188
0092 PCREL21B  _Z10expr_checkPK9tree_nodePKciS3_
0102 PCREL21B  .text
01d2 PCREL21B  _Z25tree_operand_check_failediPK9tree_nodePKciS3_


And we can see the PCREL21B relocation at offset 0x102 there.

And here is a disassembly of this section showing the same PCREL21B relocation
at the same offset. If I understand the code correctly than that should be a
call to tree_operand_length() at that offset.

$ objdump -d -C -S -t -r -j
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_ gimple-expr.o

gimple-expr.o: file format elf32-ia64-hpux-big

SYMBOL TABLE:
 ld  .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
 .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
  wF .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
0240 tree_operand_check(tree_node const*, int, char const*, int, char
const*)



Disassembly of section
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_:

 :
}

inline const_tree *
tree_operand_check (const_tree __t, int __i,
const char *__f, int __l, const char *__g)
{
   0:   00 30 39 12 80 05   [MII]   alloc r38=ar.pfs,14,9,0
   6:   70 02 30 00 42 80   mov r39=r12
   c:   01 65 fc 8c adds r12=-48,r12
  10:   01 00 00 00 01 00   [MII]   nop.m 0x0
  16:   50 02 00 62 00 00   mov r37=b0
  1c:   05 08 00 84 mov r40=r1;;
  20:   0b 70 c0 4f 3f 23   [MMI]   adds r14=-16,r39;;
  26:   00 00 39 20 23 c0   st4 [r14]=r32
  2c:   41 3f fd 8c adds r14=-12,r39;;
  30:   02 00 84 1c 90 11   [MI

[Bug fortran/93736] Add .f18 and .F18 file suffixes

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Thu, Feb 13, 2020 at 05:59:18PM +, thenlich at gcc dot gnu.org wrote:
> 
> --- Comment #4 from Thomas Henlich  ---
> Additionally, we could also imply -std=f2018 with the .f18/.F18 suffix. That
> would make them more useful.
> 

That would be a POLA as neither f03 nor f08 imply -std=f2003 or
-std=f2008.  AFAIK, these were added as a simply mnemonic for
the programmer.  By default, we have -std=gnu, which is a garabage
consumer (meaning, here's some code, do whatever it takes to 
compile it).  I think that that was a mistake, but that ship
sailed 15+ years ago.

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

[dave.anglin at bell dot net]

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

--- Comment #173 from dave.anglin at bell dot net ---
On 2020-02-13 1:11 p.m., peter.bisroev at groundlabs dot com wrote:
> If I try to compare this to aCC dump in attachment 47840, I do not see any
> calls to weak. Equivalent section to the above dump in gimple-expr.s
> (_Z18tree_operand_checkPK9tree_nodeiPKciS3_) can be found on line 9007, also
> gimple-expr.o.objdump on line 2099. I believe the place where with gcc we
> expect to see a call to tree_operand_length() through PCREL21B reloc, aCC does
> similar thing in gimple-expr.s line 9098 (gimple-expr.o.objdump line 2181).
I looked at the definition and branches to
_Z18tree_operand_checkPK9tree_nodeiPKciS3_
in the gimple-expr.s file that you uploaded.

We have the following:

    .type   _Z18tree_operand_checkPK9tree_nodeiPKciS3_,@function
    .global _Z18tree_operand_checkPK9tree_nodeiPKciS3_

    .size   _Z18tree_operand_checkPK9tree_nodeiPKciS3_, 784
// Routine [id=0064] ( tree_operand_check )

// ===
    .secalias .abe$170.text, ".text"
    .section .abe$170.text = "axC", "progbits", .abe$comdat0010
    .align  16
    .proc   _Z18tree_operand_checkPK9tree_nodeiPKciS3_
..L0:
//  $start  ARid768 =   ;; // A

..L2:
_Z18tree_operand_checkPK9tree_nodeiPKciS3_::
.prologue
//  $entry  ARid770, S:r32, S:r33, S:r34, S:r35, S:r36 =  ;; // A
[tree.h: 3177/1]
//file/line/col tree.h/3177/1
.save ar.pfs, r39
    alloc   r39 = ar.pfs, 5, 4, 5, 0   // M [tree.h: 3177/1]

    br.ret.dptk.many rp ;; // B [tree.h: 3181/3]

..L1:
//  $end    ;; // A

    .endp   _Z18tree_operand_checkPK9tree_nodeiPKciS3_

    nop.m   0  // M
    nop.i   0  // I
    nop.m   0  // M
    nop.m   0  // M
    br.call.dptk.many rp = _Z18tree_operand_checkPK9tree_nodeiPKciS3_# ;;
// B [gimple-expr.c: 658/3]
    add r9 = 0, r8 // M [gimple-expr.c: 658/3]

    .secalias .abe$comdat0010, "_Z18tree_operand_checkPK9tree_nodeiPKciS3_"

The first thing to note is aCC doesn't use weak.  Instead, it uses COMDAT
sections.  Probably, HP ld does support
weak but it's unlikely there is support for linkonce sections.  See defines in
config/pa/som.h.  There we implimented
one only support using the linker's COMDAT support.

Regarding the call to _Z18tree_operand_checkPK9tree_nodeiPKciS3_, this is
preceeded by a bunch of nops.  This is
probably to allow linker to modify call should it select a different instance
of _Z18tree_operand_checkPK9tree_nodeiPKciS3_.

[Bug target/93738] New: [8/9 regression] test case gcc.target/powerpc/20050603-3.c fails

[seurer at gcc dot gnu.org]

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

Bug ID: 93738
   Summary: [8/9 regression] test case
gcc.target/powerpc/20050603-3.c fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

git g:8d2d39587d941a40f25ea0144cceb677df115040, r9-3594

ok, this is an old issue that slipped past unnoticed somehow.  It was
introduced in gcc 8 or maybe 9 but also then effects 10.  I am not sure which
order the changes were done back in 8/9.  There is an extra instruction,
rldicl, generated after the change in this test case.


Executing on host: /home/seurer/gcc/git/build/gcc-9-test-2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-9-test-2/gcc/
/home/seurer/gcc/git/gcc-9-test-2/gcc/testsuite/gcc.target/powerpc/20050603-3.c
   -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -O2 -ffat-lto-objects -fno-ident -S -o 20050603-3.s 
  (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-9-test-2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-9-test-2/gcc/
/home/seurer/gcc/git/gcc-9-test-2/gcc/testsuite/gcc.target/powerpc/20050603-3.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -ffat-lto-objects -fno-ident -S -o 20050603-3.s
PASS: gcc.target/powerpc/20050603-3.c (test for excess errors)
PASS: gcc.target/powerpc/20050603-3.c scan-assembler-not \\mrlwinm
FAIL: gcc.target/powerpc/20050603-3.c scan-assembler-not \\mrldic
PASS: gcc.target/powerpc/20050603-3.c scan-assembler-not \\mrot[lr]
PASS: gcc.target/powerpc/20050603-3.c scan-assembler-not \\ms[lr][wd]
PASS: gcc.target/powerpc/20050603-3.c scan-assembler-times \\mrl[wd]imi 1
Executing on host: /home/seurer/gcc/git/build/gcc-9-test-2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-9-test-2/gcc/ vmx_hw_available76502.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -mno-vsx  -lm  -o vmx_hw_available76502.exe   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-9-test-2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-9-test-2/gcc/ vmx_hw_available76502.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -mno-vsx -lm -o vmx_hw_available76502.exe
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-9-test-2/gcc::/home/seurer/gcc/git/build/gcc-9-test-2/gcc:/home/seurer/gcc/git/build/gcc-9-test-2/./gmp/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./isl/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
testcase
/home/seurer/gcc/git/gcc-9-test-2/gcc/testsuite/gcc.target/powerpc/powerpc.exp
completed in 1 seconds

=== gcc Summary ===

# of expected passes5
# of unexpected failures1


/* This should generate a single rl[wd]imi. */
void rotins (unsigned int x)
{
  b.y = (x<<12) | (x>>20);
}



Before the change:

addis 10,2,.LC0@toc@ha
ld 10,.LC0@toc@l(10)
lwz 9,0(10)
rlwimi 9,3,20,20,23
stw 9,0(10)
blr


After the change:

addis 10,2,.LC0@toc@ha
ld 10,.LC0@toc@l(10)
*** rldicl 9,3,52,32
lwz 3,0(10)
rlwimi 3,9,0,3840
stw 3,0(10)
blr

[Bug target/93738] [8/9 regression] test case gcc.target/powerpc/20050603-3.c fails

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64-linux-gnu
 CC||segher at gcc dot gnu.org
   Host||powerpc64-linux-gnu
  Build||powerpc64-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
The actual FAILs only seem to happen with gcc 9 and 10 (trunk)  and then only
on BE.  On some of the other combos I see some XPASSes, though.

[Bug middle-end/93576] [8/9/10 Regression] internal compiler error: Segmentation fault (in gimplify.c)

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6625-gbacdd5e978dad84e9c547b0d5c7fed14b8d75157
Author: Jakub Jelinek 
Date:   Thu Feb 13 21:00:09 2020 +0100

c: Fix ICE with cast to VLA [93576]

The following testcase ICEs, because the PR84305 changes try to evaluate
the size earlier.  If size has side-effects, that is desirable, and the
side-effects will actually be wrapped in a SAVE_EXPR.  The problem on this
testcase is that there are no side-effects, and c_fully_fold doesn't fold
those COMPOUND_EXPRs to constant, and while before gimplification we
unshare
trees found in the expressions, the unsharing doesn't involve TYPE_SIZE
etc.
of used types.  Gimplification is destructive though, so when we gimplify
the two nested COMPOUND_EXPRs and then try to gimplify it the second time
for the TYPE_SIZEs, we ICE.
Now, we could use unshare_expr in what we push to *expr, SAVE_EXPRs and
their operands in there aren't unshared, but I really don't see a point of
evaluating expressions that don't have side-effects before, so instead
this just pushes there expressions that do have side-effects.

2020-02-13  Jakub Jelinek  

PR c/93576
* c-decl.c (grokdeclarator): If this_size_varies, only push size into
*expr if it has side effects.

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

[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux

[wkaras at yahoo dot com]

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

--- Comment #7 from Walt Karas  ---
I see this problem running in a Docker container on a MacBook.  When I try it
on the Mac (clang, Darwin kernel), the output is 2.

[Bug c++/68061] Can't use [[deprecated]] with requires clause

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
  Known to work||10.0
 Blocks||67491
 Ever confirmed|0   |1
  Known to fail||9.2.0

--- Comment #3 from Jonathan Wakely  ---
This was fixed for GCC 10 by r276764.

It still fails on the release branches. I'm not sure if there's a test to
detect regressions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/93228] [[deprecated("message")]] on template struct/class drops message

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
PR 90515 has similar cases that still fail.

[Bug c++/90515] g++ ignores [[deprecated("text")]] in some template specialisations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 Ever confirmed|0   |1

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #3)
> These systems are EOL so we can't expect any fixes to the systems themselves.
> 
> The question is "is the latest imported as an version even supposed to
> support 10.7"?
> 
> I have a patch to unsupport the sanitiser for <= 10.6 [where it has been
> unsupported upstream since at least the last release].  That is something
> that I can apply immediately.
> 
> If the latest sanitiser code is _supposed_ to work on 10.7 - we should at
> least take a cursory look at why/where it's failing before punting.
> 
> I agree that spending much time on making the sanitisers work on EOL
> machines is not a priority.  I don't have access to my 10.7 box right now -
> but will take a look next week.

I'm on 10.6 and have been configuring with --disable-libsanitizer for some time
now anyways, so it won't be too much of a loss if that becomes the default

[Bug target/90262] Inline small constant memmoves

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
  Component|middle-end  |target

--- Comment #2 from Andrew Pinski  ---
Most of the infrastructure is there now:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00087.html

[Bug target/93737] inline memmove for insertion into small arrays

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Sdee the thread starting at:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01618.html
Continued at:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00277.html

This infastructure patch was committed October 2, 2019.  So it is now a target
specific issue.

[Bug target/93737] inline memmove for insertion into small arrays

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I was thinking for small N, the middle-end could make it work by emitting
copies of the sequences using MEM_REFs, along these lines:

  char _2[N - 2];
  _2 = MEM  [(char * {ref-all})&a + 1];
  MEM  [(char * {ref-all})&a + 2] = _2;

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6628-gabc79c6498a99e9c39e6056f432796c6dde3a887
Author: Jason Merrill 
Date:   Thu Feb 13 16:42:04 2020 +0100

c++: Fix static local vars in extern "C".

Since my patch for PR 91476 moved visibility determination sooner, a local
static in a vague linkage function now gets TREE_PUBLIC set before
retrofit_lang_decl calls set_decl_linkage, which was making decl_linkage
think that it has external linkage.  It still has no linkage according to
the standard.

gcc/cp/ChangeLog
2020-02-13  Jason Merrill  

PR c++/93643
PR c++/91476
* tree.c (decl_linkage): Always lk_none for locals.

[Bug c++/91476] [9/10 Regression] const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6628-gabc79c6498a99e9c39e6056f432796c6dde3a887
Author: Jason Merrill 
Date:   Thu Feb 13 16:42:04 2020 +0100

c++: Fix static local vars in extern "C".

Since my patch for PR 91476 moved visibility determination sooner, a local
static in a vague linkage function now gets TREE_PUBLIC set before
retrofit_lang_decl calls set_decl_linkage, which was making decl_linkage
think that it has external linkage.  It still has no linkage according to
the standard.

gcc/cp/ChangeLog
2020-02-13  Jason Merrill  

PR c++/93643
PR c++/91476
* tree.c (decl_linkage): Always lk_none for locals.

[Bug c++/93713] [10 Regression] ICE in equivalently_constrained, at cp/constraint.cc:2949

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:9a0c4f5b373e236cb4af5491f50862d41fd8775a

commit r10-6629-g9a0c4f5b373e236cb4af5491f50862d41fd8775a
Author: Jason Merrill 
Date:   Thu Feb 13 16:56:08 2020 +0100

c++: Fix useless using-declaration.

Here reintroducing the same declarations into the global namespace via
using-declaration is useless but OK.  And a function and a function
template
with the same parameters do not conflict.

gcc/cp/ChangeLog
2020-02-13  Jason Merrill  

PR c++/93713
* name-lookup.c (matching_fn_p): A function does not match a
template.

[Bug c++/93713] [10 Regression] ICE in equivalently_constrained, at cp/constraint.cc:2949

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[segher at gcc dot gnu.org]

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

--- Comment #18 from Segher Boessenkool  ---
Created attachment 47841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47841&action=edit
Patch to treat sign_extend as is_just_move

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[segher at gcc dot gnu.org]

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

--- Comment #19 from Segher Boessenkool  ---
With that above patch, I get (T0 is original, T2 is with patch, these are
file sizes of a Linux build, mostly defconfig):

T0T2
   alpha   6049096  100.020%
 arc   4019384  100.000%
 arm  14177962   99.999%
   arm64  12968466   99.938%
 c6x   2346077  100.000%
csky   3332454  100.000%
   h8300   1165256   99.999%
i386  11227764  100.001%
ia64  18088488  100.003%
m68k   3716871  100.000%
  microblaze   4935181  100.000%
mips   8407681  100.000%
  mips64   6979344   99.987%
   nds32   4471023  100.000%
   nios2   3643253  100.000%
openrisc   4182200  100.000%
  parisc   7710095  100.001%
parisc64   8676725  100.003%
 powerpc  10603859  100.000%
   powerpc64  17552718  100.007%
 powerpc64le  17552718  100.007%
 riscv32   1546172  100.000%
 riscv64   6623170  100.010%
s390  13103095   99.995%
  sh   3216555   99.999%
 shnommu   1611176   99.999%
   sparc   436  100.000%
 sparc64   6751939  100.000%
  x86_64  19681173  100.000%
  xtensa 0 0

I think I'll commit this, but let's look at the original problem first as well.

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[pinskia at gcc dot gnu.org]

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

--- Comment #20 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #18)
> Created attachment 47841 [details]
> Patch to treat sign_extend as is_just_move

Do you think zero_extend should maybe be treated as such too?  What about
truncate (MIPS64 uses truncate a lot as moves)?

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[segher at gcc dot gnu.org]

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

--- Comment #21 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #20)
> (In reply to Segher Boessenkool from comment #18)
> > Created attachment 47841 [details]
> > Patch to treat sign_extend as is_just_move
> 
> Do you think zero_extend should maybe be treated as such too?

Maybe?

> What about truncate (MIPS64 uses truncate a lot as moves)?

Also maybe.

Test runs take a little over three hours (vs. less than two hours
in GCC 8 times).  I'll experiment with those things, but first the
bigger issue (parallel of two identical SETs, just with different
dest).

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

[dave.anglin at bell dot net]

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

--- Comment #174 from dave.anglin at bell dot net ---
On 2020-02-13 2:44 p.m., dave.anglin at bell dot net wrote:
> The first thing to note is aCC doesn't use weak.  Instead, it uses COMDAT
> sections.  Probably, HP ld does support
> weak but it's unlikely there is support for linkonce sections.  See defines in
> config/pa/som.h.  There we implimented
> one only support using the linker's COMDAT support.
Is HAVE_COMDAT_GROUP defined in auto-host.h?

[Bug rtl-optimization/93402] [8/9 Regression] Wrong code when returning padded struct

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

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

commit r9-8213-g3b2fbe3e723b20ea9089e5f45c55b79feb37085b
Author: Jakub Jelinek 
Date:   Thu Jan 23 20:08:22 2020 +0100

postreload: Fix up postreload combine [PR93402]

The following testcase is miscompiled, because the postreload pass changes:
-(insn 14 13 23 2 (parallel [
-(set (reg:DI 1 dx [94])
-(plus:DI (reg:DI 1 dx [95])
-(reg:DI 5 di [92])))
-(clobber (reg:CC 17 flags))
-]) "pr93402.c":8:30 186 {*adddi_1}
- (expr_list:REG_EQUAL (plus:DI (reg:DI 5 di [92])
-(const_int  [0x19debd01c7]))
-(nil)))
-(insn 23 14 25 2 (set (reg:SI 0 ax)
+(insn 23 13 25 2 (set (reg:SI 0 ax)
 (const_int 0 [0])) "pr93402.c":10:1 67 {*movsi_internal}
  (nil))
 (insn 25 23 26 2 (use (reg:SI 0 ax)) "pr93402.c":10:1 -1
  (nil))
-(insn 26 25 35 2 (use (reg:DI 1 dx)) "pr93402.c":10:1 -1
+(insn 26 25 35 2 (use (plus:DI (reg:DI 1 dx [95])
+(reg:DI 5 di [92]))) "pr93402.c":10:1 -1
  (nil))
A USE insn is not a normal insn and verify_changes called from
apply_change_group is happy about any changes into it.
The following patch avoids this optimization if we were to change
the USE operand (this routine only changes a reg into (plus reg reg2)).

2020-01-23  Jakub Jelinek  

PR rtl-optimization/93402
* postreload.c (reload_combine_recognize_pattern): Don't try to adjust
USE insns.

* gcc.c-torture/execute/pr93402.c: New test.

[Bug target/93418] [9 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:764e831291a2e510978ca7be0bffb55589a5a0b6

commit r9-8214-g764e831291a2e510978ca7be0bffb55589a5a0b6
Author: Jakub Jelinek 
Date:   Tue Jan 28 08:46:23 2020 +0100

i386: Fix ix86_fold_builtin shift folding [PR93418]

The following testcase is miscompiled, because the variable shift left
operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
we call builder.new_unary_operation, builder.encoded_nelts () will be just
1
and thus we encode the resulting vector as if all the elements were the
same.
For non-masked is_vshift, we could perhaps call
builder.new_binary_operation
(TREE_TYPE (args[0]), args[0], args[1], false), but then there are masked
shifts, for non-is_vshift we could perhaps call it too but with args[2]
instead of args[1], but there is no builder.new_ternary_operation.
All this stuff is primarily for aarch64 anyway, on x86 we don't have any
variable length vectors, and it is not a big deal to compute all elements
and just let builder.finalize () find the most efficient VECTOR_CST
representation of the vector.  So, instead of doing too much, this just
keeps using new_unary_operation only if only one VECTOR_CST is involved
(i.e. non-masked shift by constant) and for the rest just compute all elts.

2020-01-28  Jakub Jelinek  

PR target/93418
* config/i386/i386.c (ix86_fold_builtin) : If mask is not
-1 or is_vshift is true, use new_vector with number of elts npatterns
rather than new_unary_operation.

* gcc.target/i386/avx2-pr93418.c: New test.

[Bug fortran/93463] ICE in oacc_code_to_statement, at fortran/openmp.c:6007

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:244f4b8c2823531a1e479a3773272af539dda258

commit r9-8215-g244f4b8c2823531a1e479a3773272af539dda258
Author: Jakub Jelinek 
Date:   Wed Jan 29 09:39:16 2020 +0100

openmp: Handle rest of EXEC_OACC_* in oacc_code_to_statement [PR93463]

As the testcase shows, some EXEC_OACC_* codes weren't handled in
oacc_code_to_statement.  Fixed thusly.

2020-01-29  Jakub Jelinek  

PR fortran/93463
* openmp.c (oacc_code_to_statement): Handle
EXEC_OACC_{ROUTINE,UPDATE,WAIT,CACHE,{ENTER,EXIT}_DATA,DECLARE}.

* gfortran.dg/goacc/pr93463.f90: New test.

[Bug c++/91118] ubsan does not work with openmp default (none) directive

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:4b124e3c9c35121969cc23d0aea4bcb2c406fd21

commit r9-8216-g4b124e3c9c35121969cc23d0aea4bcb2c406fd21
Author: Jakub Jelinek 
Date:   Wed Jan 29 09:41:42 2020 +0100

openmp: c++: Consider typeinfo decls to be predetermined shared [PR91118]

If the typeinfo decls appear in OpenMP default(none) regions, as we no
longer
predetermine const with no mutable members, they are diagnosed as errors,
but it isn't something the users can actually provide explicit sharing for
in
the clauses.

2020-01-29  Jakub Jelinek  

PR c++/91118
* cp-gimplify.c (cxx_omp_predetermined_sharing): Return
OMP_CLAUSE_DEFAULT_SHARED for typeinfo decls.

* g++.dg/gomp/pr91118-1.C: New test.
* g++.dg/gomp/pr91118-2.C: New test.

[Bug middle-end/93505] [8/9 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:329475795c6eeaa2b122672091c9119b9d6c5564

commit r9-8217-g329475795c6eeaa2b122672091c9119b9d6c5564
Author: Jakub Jelinek 
Date:   Thu Jan 30 21:28:17 2020 +0100

combine: Punt on out of range rotate counts [PR93505]

What happens on this testcase is with the out of bounds rotate we get:
Trying 13 -> 16:
   13: r129:SI=r132:DI#0<-<0x20
  REG_DEAD r132:DI
   16: r123:DI=r129:SI<0
  REG_DEAD r129:SI
Successfully matched this instruction:
(set (reg/v:DI 123 [  ])
(const_int 0 [0]))
during combine.  So, perhaps we could also change simplify-rtx.c to punt
if it is out of bounds rather than trying to optimize anything.
Or, but probably GCC11 material, if we decide that ROTATE/ROTATERT doesn't
have out of bounds counts or introduce targetm.rotate_truncation_mask,
we should truncate the argument instead of punting.
Punting is better for backports though.

2020-01-30  Jakub Jelinek  

PR middle-end/93505
* combine.c (simplify_comparison) : Punt on out of range
rotate counts.

* gcc.c-torture/compile/pr93505.c: New test.