[Bug tree-optimization/89672] New: NULL pointer check optimized out for the return value of memchr(NULL, c, 0)

[him at revl dot org]

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

Bug ID: 89672
   Summary: NULL pointer check optimized out for the return value
of memchr(NULL, c, 0)
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: him at revl dot org
  Target Milestone: ---

Created attachment 45947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45947=edit
Source that reproduces the problem

The attached code, when compiled with -O1 or more aggressive,
produces incorrect output and exits with return code 1:

$ g++ -Wall -Wextra -Werror -pedantic -O1 -o parser parser.cc
$ ./parser
tok(first)
m_CurrentPtr=[...]
tok(second)
m_CurrentPtr=(nil)
tok()
echo $?
1

When compiled without optimization, or when *any* of the three optimizations
listed below is disabled, the code produces the correct output and exits
normally:

$ g++ -Wall -Wextra -Werror -pedantic -O0 -o parser parser.cc
$ ./parser
tok(first)
m_CurrentPtr=[...]
tok(second)
echo $?
0

It appears that the check m_CurrentPtr != nullptr in the second call to
PrintTokenIfFound() is optimized out if the built-in memchr is used.
If a custom implementation of memchr (FindNewline()) is used in the
second call, the code produces the correct result.

Adding *any* of these options to the command line also fixes the problem:

-fno-delete-null-pointer-checks
-fno-tree-dominator-opts
-fno-inline

The problem is also reproducible with older versions (I tried 4.9.3 and
7.3.0).

[Bug c/43673] Incorrect warning: use of 'D' length modifier with 'a' type character

[luoxhu at cn dot ibm.com]

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

--- Comment #5 from Xiong Hu XS Luo  ---
Ben's reply regarding to testing dfp on other targets:

"
> I suggest to test it on a platform where dfp is not supported as well,

At this stage, the patches on the trunk don't identify any targets as
supporting DFP, so powerpc64 is as good as any other.  I will double
check on x86, though, for good measure.  Thanks,
"

[Bug c/43673] Incorrect warning: use of 'D' length modifier with 'a' type character

[luoxhu at cn dot ibm.com]

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

--- Comment #4 from Xiong Hu XS Luo  ---
Hi, Joseph, recently, I summited a quick fix in
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01949.html for this issue. 
Actually this was introduced by the initial patch
https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00330.html committed in 2005. All
the decimal floating pointer print function are supported except the Da/DA even
it has no much difference with De/Df/Dg/DE/DF/DG, all the value are filled with
TEX_* instead of BADLEN for decimal printf table. 
From consistent view, this patch can fix the issue more easily. 
But there are questions like Ryan said, the dfp full support requires MACRO
__STDC_DEC_FP__ set in DFP library and compiler check, still this mechanism is
not implemented yet. Otherwise, it maybe fail on other platforms that don't
support DFP.  Also, this implementation may need a lot changes to the c front
end and libdfp support.

What's your suggestion about this? Thanks.

[Bug c++/86521] [8/9 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
(In reply to Jason Merrill from comment #4)
> The cast is ambiguous
> 
> To construct a 'base', we consider the two constructors
> 
> 1) base(const base&);
> 2) base(base&&);
> 
> for each of them we could convert the argument by either
> 
> 3) operator U () &&
> 4) operator U const& () const&
> 
> For #1 we want to convert to const base&.  For direct reference binding, #4
> is the only candidate, and it is viable.  For #2 we want to convert to
> base&&, only #3 is a candidate for direct reference binding, and it is
> viable.
> 
> The two user-defined conversion sequences are not comparable because they
> use different conversion operators, so the initialization is ambiguous.

...although perhaps the C++17 mandatory copy elision should alter this
calculation: initializing the object from the result of #3 doesn't actually use
the copy constructor.  In that case, we'd just be using #3, making it better
than #4+#2.  The standard doesn't currently say this, but it probably should.

[Bug c/43673] Incorrect warning: use of 'D' length modifier with 'a' type character

[luoxhu at cn dot ibm.com]

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

Xiong Hu XS Luo  changed:

   What|Removed |Added

 CC||joseph at codesourcery dot com,
   ||luoxhu at cn dot ibm.com

--- Comment #3 from Xiong Hu XS Luo  ---
Hi

[Bug c++/86521] [8/9 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Mar 12 03:19:22 2019
New Revision: 269602

URL: https://gcc.gnu.org/viewcvs?rev=269602=gcc=rev
Log:
PR c++/86521 - wrong overload resolution with ref-qualifiers.

Here we were wrongly treating binding a const lvalue ref to an xvalue as
direct binding, which is wrong under [dcl.init.ref] and [over.match.ref].

* call.c (build_user_type_conversion_1): Don't use a conversion to a
reference of the wrong rvalueness for direct binding.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/overload-conv-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc

[Bug c++/86521] [8/9 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
The cast is ambiguous

To construct a 'base', we consider the two constructors

1) base(const base&);
2) base(base&&);

for each of them we could convert the argument by either

3) operator U () &&
4) operator U const& () const&

For #1 we want to convert to const base&.  For direct reference binding, #4 is
the only candidate, and it is viable.  For #2 we want to convert to base&&,
only #3 is a candidate for direct reference binding, and it is viable.

The two user-defined conversion sequences are not comparable because they use
different conversion operators, so the initialization is ambiguous.

[Bug c++/89244] __builtin_is_constant_evaluated not documented

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Done in r269129.

[Bug tree-optimization/89644] [8/9 Regression] false-positive -Warray-bounds on strncpy with unterminated array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Blocks||88781
Summary|False-positive  |[8/9 Regression]
   |-Warray-bounds diagnostic   |false-positive
   |on strncpy  |-Warray-bounds on strncpy
   ||with unterminated array

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00535.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
[Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings

[Bug target/89650] [9 Regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:1055 since r269119

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-03-10 00:00:00 |2019-03-12
 CC||hubicka at ucw dot cz
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00534.html

[Bug demangler/89671] Demangling segfault

[juanpotatodev at gmail dot com]

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

--- Comment #1 from Hasan  ---
The Arch package:
https://www.archlinux.org/packages/community/x86_64/telegram-desktop/
The source of the package: https://github.com/telegramdesktop/tdesktop

[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter  ---
Sorry if that maybe a stupid question but is it wise that close before the new
release to start such a bigger coding?

[Bug demangler/89671] New: Demangling segfault

[juanpotatodev at gmail dot com]

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

Bug ID: 89671
   Summary: Demangling segfault
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juanpotatodev at gmail dot com
  Target Milestone: ---

echo
'_ZNSt11_Tuple_implILm0EJN3rpl8producerIN4base5flagsIN11MTPDchannel4FlagEEENS0_8no_errorEZNS0_7details10map_helperIZN4Data18FlagsValueWithMaskINSA_5FlagsIS6_Lj2147486693EE6ChangeES7_ZNS8_11then_helperISE_S7_ZNKS0_12event_streamISE_E6eventsEvEUlRKT_E_EclISE_S7_ZNS0_6singleISE_EEDaOSI_EUlSK_E_SE_S7_EEDaONS1_ISI_T0_T1_EEEUlSK_E_EEDaSU_NSI_4TypeEEUlRKSE_E0_EclISE_S7_ZNS8_13filter_helperIZNSB_ISE_S7_SV_EEDaSU_SW_EUlSY_E_EclISE_S7_SV_vEEDaSU_EUlSK_E_S6_EEDaSU_EUlSK_E_EENS1_IbS7_ZNS9_IZNSA_15SingleFlagValueINSC_INS3_IN19MTPDchatAdminRights4FlagEEELj4294967295EE6ChangeES7_ZNSF_IS1E_S7_ZNKSG_IS1E_E6eventsEvEUlSK_E_EclIS1E_S7_ZNSO_IS1E_EEDaSP_EUlSK_E_S1E_S7_EEDaSU_EUlSK_E_EEDaSU_NSI_4EnumEEUlS1C_E_EclIS1C_S7_ZNS9_IZNSB_IS1E_S7_S1K_EEDaSU_SW_EUlRKS1E_E0_EclIS1E_S7_ZNS12_IZNSB_IS1E_S7_S1K_EEDaSU_SW_EUlS1Q_E_EclIS1E_S7_S1K_vEEDaSU_EUlSK_E_S1C_EEDaSU_EUlSK_E_bEEDaSU_EUlSK_E_EENS1_IbS7_ZNS9_IZNS19_INSC_INS3_IN20MTPDchatBannedRights4FlagEEELj4294967295EE6ChangeES7_ZNSF_IS25_S7_ZNKSG_IS25_E6eventsEvEUlSK_E_EclIS25_S7_ZNSO_IS25_EEDaSP_EUlSK_E_S25_S7_EEDaSU_EUlSK_E_EEDaSU_S1L_EUlS23_E_EclIS23_S7_ZNS9_IZNSB_IS25_S7_S2B_EEDaSU_SW_EUlRKS25_E0_EclIS25_S7_ZNS12_IZNSB_IS25_S7_S2B_EEDaSU_SW_EUlS2G_E_EclIS25_S7_S2B_vEEDaSU_EUlSK_E_S23_EEDaSU_EUlSK_E_bEEDaSU_EUlSK_E_EES2Q_EED1Ev'|c++filt

This monstrosity causes a segfault. llvm-cxxfilt parses it into something
(https://pastebin.com/raw/cJR9QC5b). It's from the telegram-desktop binary in
the Arch Linux repository.

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[joern at purestorage dot com]

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

--- Comment #13 from Jörn Engel  ---
None of those examples convince me.  If you or I know that a zero-argument is
impossible, but the compiler doesn't know, wouldn't that still be UB?  And if
the compiler knows, it can remove the branch either way.

Similar for architectures returning 64 or -1, code could be

asm(...);
if (ret == 64)
return 32;
return ret;

Again, if a null-argument is impossible, the branch can be removed.  And if the
programmer wants to get 64 or -1, that either requires a conditional or invokes
UB.

So far, whichever way I look at it, moving the conditional inside of
__builtin_ctz() and making the result well-defined for any input doesn't have
any downsides.  I cannot even think of existing code that would break unless it
already invoked UB and depended on a lucky roll of the dice to work correctly.

[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug bootstrap/89656] [9 Regression] profiledbootstrap failure on aarch64-linux since r269453

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|wrong-code  |

--- Comment #9 from Jakub Jelinek  ---
Fixed for gcc 9.1+ so far.

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 11 22:27:39 2019
New Revision: 269598

URL: https://gcc.gnu.org/viewcvs?rev=269598=gcc=rev
Log:
PR fortran/89651
* trans-openmp.c (gfc_omp_clause_default_ctor): Set TREE_NO_WARNING
on decl if adding COND_EXPR for allocatable.
(gfc_omp_clause_copy_ctor): Set TREE_NO_WARNING on dest.

* gfortran.dg/gomp/pr89651.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr89651.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Jörn Engel from comment #11)

> Out of curiosity, if the only non-broken way to call __builtin_ctz(foo) is
> via "foo ? __builtin_ctz(foo) : 32", why isn't the conditional moved into
> __builtin_ctz()?  Is there some hidden advantage from callers having to add
> the conditional or getting surprised by undefined behaviour?

In many cases you know the argument is not zero, so no need to write it that
way.
Plus, not everybody wants value 32 for the case when the argument is 0.
Some CPUs have instructions that return -1 in such cases, other return say 64
even when the ctz is 32-bit and it is up to the user to specify in the code
what they want.

[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
The dump-tree looks funny: it appears that in the last test

  print *, "Associated contents?", associated(p1%string, p2%string)

the association is already evaluated at compile time to .false.

[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77746
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[joern at purestorage dot com]

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

--- Comment #11 from Jörn Engel  ---
I stand corrected.  Thank you very much!

Out of curiosity, if the only non-broken way to call __builtin_ctz(foo) is via
"foo ? __builtin_ctz(foo) : 32", why isn't the conditional moved into
__builtin_ctz()?  Is there some hidden advantage from callers having to add the
conditional or getting surprised by undefined behaviour?

[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Created attachment 45946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45946=edit
First step towards a patch

Expect quite a few regressions, but this seems to do the
trick for this PR and PR 77746 + PR 79485.

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
I forgot to list what L15 was:
.L15:
tzcntl  %eax, %eax
vzeroupper
ret

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Jörn Engel from comment #6)
> True for one, but not the other.
> 
> return mask ? __builtin_ctz(mask) : 32;
> 1099:   83 f6 ffxor$0x,%esi
> 109c:   74 47   je 10e5 
> 109e:   f3 0f bc f6 tzcnt  %esi,%esi
> 

But this is because of jump threading:

int ml = matchlen32(src, src + 1);
if (ml >= 32)
ml += matchlen32(src + 32, src + 1 + 32);

Does optimize to the correct thing (only one jump rather than 2):
.cfi_startproc
vmovdqu 1(%rdi), %ymm0
vpcmpeqd%ymm1, %ymm1, %ymm1
vpcmpeqb(%rdi), %ymm0, %ymm0
vpandn  %ymm1, %ymm0, %ymm0
vpmovmskb   %ymm0, %eax
testl   %eax, %eax
jne .L15
vmovdqu 32(%rdi), %ymm0
xorl%eax, %eax
vpcmpeqb33(%rdi), %ymm0, %ymm0
vpandn  %ymm1, %ymm0, %ymm0
vpmovmskb   %ymm0, %edx
tzcntl  %edx, %eax
addl$32, %eax
testl   %edx, %edx
movl$64, %edx
cmove   %edx, %eax
vzeroupper
ret

The other one:
.LFB4795:
.cfi_startproc
vmovdqu 1(%rdi), %ymm0
vpcmpeqd%ymm1, %ymm1, %ymm1
vpcmpeqb(%rdi), %ymm0, %ymm0
vpandn  %ymm1, %ymm0, %ymm0
vpmovmskb   %ymm0, %eax
testl   %eax, %eax
je  .L5
tzcntl  %eax, %eax
cmpl$29, %eax
jle .L7
.L2:
vmovdqu 32(%rdi), %ymm0
vpcmpeqd%ymm1, %ymm1, %ymm1
vpcmpeqb33(%rdi), %ymm0, %ymm0
vpandn  %ymm1, %ymm0, %ymm0
vpmovmskb   %ymm0, %edx
tzcntl  %edx, %edx
addl%edx, %eax
.L7:
vzeroupper
ret
.p2align 4,,10
.p2align 3
.L5:
movl$32, %eax
jmp .L2
.cfi_endproc

Is due to jump threading too, notice how after the test against 0 is jumping to
L5 and then past the comparison again >= 29 :).

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[joern at purestorage dot com]

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

--- Comment #8 from Jörn Engel  ---
Updated testcase below fails to remove the branch with my gcc-8.

/*
 * usage:
 * gcc -std=gnu11 -Wall -Wextra -g -march=core-avx2 -mbmi -fPIC -O3 % &&
./a.out < /dev/zero
 */
#include 
#include 
#include 
#include 

typedef uint8_t u8_256 __attribute__((vector_size(32), may_alias));
typedef char  c256 __attribute__((vector_size(32), may_alias));
typedef uint8_t  u256u __attribute__((vector_size(32), may_alias, aligned(1)));

static inline  u8_256 read256(const void *buf) { return *(const u256u *)buf; }

static inline int movemask8_256(u8_256 mask)
{
return __builtin_ia32_pmovmskb256((c256)mask);
}

static inline int matchlen32(const void *a, const void *b)
{
int mask = ~movemask8_256(read256(a) == read256(b));
return mask ? __builtin_ctz(mask) : 32;
}

static int ml30(const void *src)
{
int ml = matchlen32(src, src + 1);
if (ml >= 30)
ml += matchlen32(src + 32, src + 1 + 32);
return ml;
}

static int ml32(const void *src)
{
int ml = matchlen32(src, src + 1);
if (ml >= 32)
ml += matchlen32(src + 32, src + 1 + 32);
return ml;
}

int main(void)
{
uint8_t src[256];
ssize_t n;

n = read(0, src, sizeof(src));
if (n != sizeof(src))
return -1;
printf("should be 64: %d\n", ml30(src));
printf("should be 64: %d\n", ml32(src));
return 0;
}

[Bug fortran/61261] [OOP] Segfault on source-allocating polymorphic variables

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||anlauf at gcc dot gnu.org

--- Comment #9 from anlauf at gcc dot gnu.org ---
AFAICT all related PRs are fixed.  Close this one, too?

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
int
foo (int x)
{
  return x ? __builtin_ctz (x) : 32;
}
works without conditionals just fine for me, both in 8.x and trunk, both C and
C++, both -O2 and -O3.

[Bug fortran/67123] ICE with source allocation

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from anlauf at gcc dot gnu.org ---
Cannot reproduce the ICE with current 9-trunk or 8-branch.
As this is supposedly a duplicate, can it be set to fixed?

[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 11 21:58:43 2019
New Revision: 269597

URL: https://gcc.gnu.org/viewcvs?rev=269597=gcc=rev
Log:
PR middle-end/89655
PR bootstrap/89656
* vr-values.c (vr_values::update_value_range): If
old_vr->varying_p (), don't update it, make new_vr also VARYING
and return false.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr89655.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vr-values.c

[Bug bootstrap/89656] [9 Regression] profiledbootstrap failure on aarch64-linux since r269453

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 11 21:58:43 2019
New Revision: 269597

URL: https://gcc.gnu.org/viewcvs?rev=269597=gcc=rev
Log:
PR middle-end/89655
PR bootstrap/89656
* vr-values.c (vr_values::update_value_range): If
old_vr->varying_p (), don't update it, make new_vr also VARYING
and return false.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr89655.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vr-values.c

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[joern at purestorage dot com]

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

--- Comment #6 from Jörn Engel  ---
True for one, but not the other.

return mask ? __builtin_ctz(mask) : 32;
1099:   83 f6 ffxor$0x,%esi
109c:   74 47   je 10e5 
109e:   f3 0f bc f6 tzcnt  %esi,%esi

I used:
gcc-8 -std=gnu11 -Wall -Wextra -g -march=core-avx2 -mbmi -fPIC -O3 %

_tzcnt_u32() works as you said it should.  Nicer than inline asm and allows
type checking.  Thank you for that hint!

[Bug libstdc++/71312] mutexes for shared_ptr atomics should be padded to cacheline size

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
A slightly simpler fix:

--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -34,7 +34,9 @@ namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden)
   __gnu_cxx::__mutex&
   get_mutex(unsigned char i)
   {
-static __gnu_cxx::__mutex m[mask + 1];
+// increase alignment to ensure each lock is on a separate cache line
+struct alignas(64) M : __gnu_cxx::__mutex { };
+static M m[mask + 1];
 return m[i];
   }
 }

[Bug c++/89668] make[2]: autogen: Command not found

[jiapei at longervision dot com]

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

--- Comment #4 from Pei JIA  ---

I just strictly follow
http://linuxfromscratch.org/lfs/view/stable/chapter06/gcc.html,

and I'm using the following command line:

su nobody -s /bin/bash -c "PATH=$PATH make -k check"


Should I do:

su nobody -s /bin/bash -c "PATH=$PATH make -k -j8 check" instead??

[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
It's likely a duplicate of PR78746.

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Jörn Engel from comment #4)
> Fair enough.  That means the only way to get tzcnt without a conditional is
> by using inline asm.

Of course not.
Either you can use _tzcnt_u32, or you can use x ? __builtin_ctz (x) : 32, both
with with -mbmi expand to tzcnt when optimizing.

[Bug c++/89668] make[2]: autogen: Command not found

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
You can also look at the progress by tail -f gcc.log or gcc.sum if you want. 
But yes there are many testcases which causes this to be slow especially if you
are not using -j.

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[joern at purestorage dot com]

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

--- Comment #4 from Jörn Engel  ---
Fair enough.  That means the only way to get tzcnt without a conditional is by
using inline asm.  Annoying, but something I can work with.

Annoying because for CPUs with BMI1, tzcnt is well-defined and I explicitly
tell the compiler to generate code for BMI1.  So while the __builtin_ctz() in
generall is undefined, it is actually well-defined for the case I care about.

But I need to support older compilers anyway, so inline asm it is.  Thank you!

[Bug fortran/89462] [7/8/9 Regression] gfortran loops in code generation

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Commenting the line

!  CALL ttest3(aTP)

it does no longer loop indefinitely, but produce a bogus error:

pr89462.f90:2:0:

2 |   CHARACTER*1 test2,TR,aTP
  | 
Error: size of variable 'tr' is too large

The dump tree of this variant looks strange.  Maybe the character length
is not handled properly.

[Bug libstdc++/71312] mutexes for shared_ptr atomics should be padded to cacheline size

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-11
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/89668] make[2]: autogen: Command not found

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This doesn't seem like a bug.

If you have questions, please use the gcc-help mailing list, not a bug report.

[Bug c++/89668] make[2]: autogen: Command not found

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Pei JIA from comment #0)
> So, my questions are:
> 
> Is make[2]: autogen: Command not found an ERROR? Is autogen required?

This seems pretty clearly documented at
https://gcc.gnu.org/install/prerequisites.html

> Is WARNING: Couldn't find the global config file. an ERROR? It looks
> like it's just a harmless warning, right?

You can ignore it.

> Any suggestions? Should I just wait? But, it's already been hours

There are thousands and thousands of tests. You probably should have told make
to run multiple jobs at once, using the -j option and an argument.

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
__builtin_ctz (0) is undefined behavior, anytime you invoke UB, all bets are
off.
The compiler optimizes based on the assumption that UB does not happen.
So, as all valid __builtin_ctz calls return values from 0 to 31, the compiler
does optimize away __builtin_ctz (x) == 32 into 0.

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[joern at purestorage dot com]

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

--- Comment #2 from Jörn Engel  ---
The input is 32.  Does the "undefined-if-zero" thing give gcc license to remove
code depending on the output?  If it does, why is the code only removed when
comparing against 31/32, not when comparing against 30?

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
__builtin_ctz is undefined if the input is 0 as documented.

[Bug c/89670] New: __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

[joern at purestorage dot com]

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

Bug ID: 89670
   Summary: __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be
<31 ?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joern at purestorage dot com
  Target Milestone: ---

Created attachment 45945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45945=edit
matchlen testcase extracted from lz compressor

I ran across this while working on a LZ compression library.  One way of
calculating the match length is through vector-comparison, movemask and ctz. 
It is relatively useful because it covers up to 32 equal bytes without branch.

If 32 bytes match, the true match length might be much longer than 32.  So
naturally the code contains a branch
if (ml == 32) {
/* calculate actual match length */
}

That branch was optimized away, which surprised me a bit.  I have reduced the
problem to the attached testcase.  Testcase seems to work fine with gcc 4.8,
but fails with 4.9, 5, 6, 7 and 8.  It also fails with clang 3.5, 3.8, 4.0, 6.0
and 7, fwiw.

System is an old Debian unstable, compilers are from Debian.b

[Bug libbacktrace/89669] /usr/ccs/bin/ld: Unsatisfied symbols: backtrace_uncompress_zdebug

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed.  Thanks.

[Bug libbacktrace/89669] /usr/ccs/bin/ld: Unsatisfied symbols: backtrace_uncompress_zdebug

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Mar 11 20:40:34 2019
New Revision: 269594

URL: https://gcc.gnu.org/viewcvs?rev=269594=gcc=rev
Log:
PR libbacktrace/89669
* Makefile.am (BUILDTESTS): Only add ztest and ztest_alloc if
HAVE_ELF.
* Makefile.in: Regenerate.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/Makefile.am
trunk/libbacktrace/Makefile.in

[Bug libstdc++/89615] FAIL: 17_intro/headers/c++1998/charset.cc (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2019-03-06 7:26 p.m., redi at gcc dot gnu.org wrote:
> OK, so then maybe something like this:
>
> --- a/libstdc++-v3/include/ext/codecvt_specializations.h
> +++ b/libstdc++-v3/include/ext/codecvt_specializations.h
> @@ -35,6 +35,7 @@
>  #ifndef _EXT_CODECVT_SPECIALIZATIONS_H
>  #define _EXT_CODECVT_SPECIALIZATIONS_H 1
>
> +#if defined __has_include && __has_include()
I had not realized this, but the system has  and it's clearly broken. 
So, the errors
are still there with this change.

[Bug tree-optimization/89662] [9 Regression] -Warray-bounds ICE on void* arithmetic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
Summary|[9 Regression]  |[9 Regression]
   |-Warray-bounds ICE in   |-Warray-bounds ICE on void*
   |contains_struct_check, at   |arithmetic
   |tree.h:3545 |

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00520.html

[Bug preprocessor/89665] inconsistent macro expansion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
When you are using a C preprocessor, it needs to behave how the C standard
mandates it to behave.  All of gcc, clang and icc agree here.

[Bug libbacktrace/89669] New: /usr/ccs/bin/ld: Unsatisfied symbols: backtrace_uncompress_zdebug

[danglin at gcc dot gnu.org]

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

Bug ID: 89669
   Summary: /usr/ccs/bin/ld: Unsatisfied symbols:
backtrace_uncompress_zdebug
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: ian at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

/opt/gnu/bin/bash ./libtool  --tag=CC   --mode=link
/test/gnu/gcc/objdir/./prev-
gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/gnu/gcc/gcc-9/hppa2.0w-hp-hpu
x11.11/bin/ -B/opt/gnu/gcc/gcc-9/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-9
/hppa2.0w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-9/hppa2.0w-hp-hpux11.11/in
clude -isystem /opt/gnu/gcc/gcc-9/hppa2.0w-hp-hpux11.11/sys-include   
-DSRCDIR=
\"../../gcc/libbacktrace\" -g -O2  -static-libstdc++ -static-libgcc  -o
ztest_al
loc ztest_alloc-ztest.o ztest_alloc-testlib.o libbacktrace_alloc.la
libtool: link: /test/gnu/gcc/objdir/./prev-gcc/xgcc
-B/test/gnu/gcc/objdir/./pre
v-gcc/ -B/opt/gnu/gcc/gcc-9/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-9/hppa
2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-9/hppa2.0w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-9/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc-9/hpp
a2.0w-hp-hpux11.11/sys-include -DSRCDIR=\"../../gcc/libbacktrace\" -g -O2
-stati
c-libstdc++ -static-libgcc -o ztest_alloc ztest_alloc-ztest.o
ztest_alloc-testli
b.o  ./.libs/libbacktrace_alloc.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   backtrace_uncompress_zdebug (first referenced in ztest_alloc-ztest.o) (code)
collect2: error: ld returned 1 exit status
Makefile:1163: recipe for target 'ztest_alloc' failed
make[3]: *** [ztest_alloc] Error 1

Seems  backtrace_uncompress_zdebug() is only provided for elf.

[Bug c/89667] initializers for character string arrays (char *[]) appear to reside in protected storage

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
That is not a bug, that is how C works.  You'd need gcc older than 4.0 and use
-fwritable-strings option if you'd need it to work.  Or just use the named char
array variables initialized with string literals which is the portable way of
making strings writable.

[Bug middle-end/89663] [7/8/9 Regression] ICE in expand_builtin_int_roundingfn_2, at builtins.c:2831

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/89668] New: make[2]: autogen: Command not found

[jiapei at longervision dot com]

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

Bug ID: 89668
   Summary: make[2]: autogen: Command not found
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiapei at longervision dot com
  Target Milestone: ---

Hi, all:

I'm trying to build GCC-8.3.0 for LFS on my host Ubuntu 18.04.2, but NOW hanged
for hours at the testsuite, which seems to be exactly the same reported BUG:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29700 .


What I met:

(lfs chroot) root:/sources/compiler/gcc-8.3.0/build# su nobody -s /bin/bash -c
"PATH=$PATH make -k check"
make[1]: Entering directory '/sources/compiler/gcc-8.3.0/build'
make[2]: Entering directory '/sources/compiler/gcc-8.3.0/build/fixincludes'
autogen -T ../../fixincludes/check.tpl ../../fixincludes/inclhack.def
make[2]: autogen: Command not found
make[2]: *** [Makefile:176: check] Error 127
make[2]: Leaving directory '/sources/compiler/gcc-8.3.0/build/fixincludes'
make[1]: *** [Makefile:3674: check-fixincludes] Error 2
make[2]: Entering directory '/sources/compiler/gcc-8.3.0/build/gcc'
rm -rf testsuite/gcc-parallel
make[3]: Entering directory '/sources/compiler/gcc-8.3.0/build/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
   && [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
   && [ -f testsuite/gcc-parallel/finished ]; then \
  rm -rf testsuite/gcc; \
else \
  cd testsuite/gcc; \
  rm -f tmp-site.exp; \
  sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
  /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
  EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
  if [ -f ${rootme}/../expect/expect ] ; then  \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
  fi ; \
  `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc ; \
  if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
  fi ; \
fi )
WARNING: Couldn't find the global config file.
Using /sources/compiler/gcc-8.3.0/gcc/testsuite/lib/gcc.exp as tool init file.
Test run by nobody on Mon Mar 11 06:49:06 2019
Native configuration is x86_64-pc-linux-gnu

=== gcc tests ===

Schedule of variations:
unix

Running target unix
Using /tools/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /tools/share/dejagnu/config/unix.exp as generic interface file for
target.
Using /sources/compiler/gcc-8.3.0/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/sources/compiler/gcc-8.3.0/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
Running
/sources/compiler/gcc-8.3.0/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
...
Running
/sources/compiler/gcc-8.3.0/gcc/testsuite/gcc.c-torture/execute/execute.exp ... 


So, my questions are:

Is make[2]: autogen: Command not found an ERROR? Is autogen required?
Is WARNING: Couldn't find the global config file. an ERROR? It looks like
it's just a harmless warning, right?
I'm pretty sure that my memory is NOT used up. top result is as follows:

top - 02:28:19 up 1 day, 15:05, 10 users,  load average: 4.14, 3.92, 3.97
Tasks: 434 total,   2 running, 360 sleeping,   0 stopped,   1 zombie
%Cpu(s): 12.8 us,  4.6 sy,  0.0 ni, 79.6 id,  0.7 wa,  0.0 hi,  2.3 si,  0.0 st
KiB Mem : 49277888 total,  1009552 free, 10700956 used, 37567380 buff/cache

KiB Swap:  2097148 total,  2097148 free,0 used. 36817604 avail Mem


Any suggestions? Should I just wait? But, it's already been hours



Cheers, have a nice day...

Pei

[Bug c/89667] New: initializers for character string arrays (char *[]) appear to reside in protected storage

[rick at regreer dot net]

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

Bug ID: 89667
   Summary: initializers for character string arrays (char *[])
appear to reside in protected storage
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rick at regreer dot net
  Target Milestone: ---

Created attachment 45943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45943=edit
See description of bug

This string is writeable:

   char foo[] = "foo':

This one is not:

   char *foo[] = { "foo" };

Attachment includes source for a simple demonstration program "bug,c", with 
preprocessed source (the only include file is "stdio.h), output of
"uname -a" and "gcc -v" appended as comments.

[Bug tree-optimization/89664] [8/9 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
We're leaving occ_head with stale data.  Patch I am testing:

Index: tree-ssa-math-opts.c
===
--- tree-ssa-math-opts.c(revision 269212)
+++ tree-ssa-math-opts.c(working copy)
@@ -799,7 +799,7 @@ execute_cse_reciprocals_1 (gimple_stmt_i

   /* If it is more profitable to optimize 1 / x, don't optimize 1 / (x * x). 
*/
   if (sqrt_recip_count > square_recip_count)
-return;
+goto out;

   /* Do the expensive part only if we can hope to optimize something.  */
   if (count + square_recip_count >= threshold && count >= 1)
@@ -842,6 +842,7 @@ execute_cse_reciprocals_1 (gimple_stmt_i
}
 }

+out:
   for (occ = occ_head; occ; )
 occ = free_bb (occ);

[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Untested patch:

--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -9433,10 +9433,12 @@ maybe_warn_pessimizing_move (tree retval, tree
functype)
}
  /* Warn if the move is redundant.  It is redundant when we would
 do maybe-rvalue overload resolution even without std::move.  */
- else if (treat_lvalue_as_rvalue_p (arg, /*parm_ok*/true))
+ else if (warn_redundant_move
+  && treat_lvalue_as_rvalue_p (arg, /*parm_ok*/true))
{
  /* Make sure that the overload resolution would actually succeed
 if we removed the std::move call.  */
+ cp_unevaluated e;
  tree t = convert_for_initialization (NULL_TREE, functype,
   move (arg),
   (LOOKUP_NORMAL

[Bug tree-optimization/89662] [9 Regression] -Warray-bounds ICE in contains_struct_check, at tree.h:3545

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |9.0

[Bug middle-end/89663] [7/8/9 Regression] ICE in expand_builtin_int_roundingfn_2, at builtins.c:2831

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.5

[Bug preprocessor/89665] inconsistent macro expansion

[gciofono at gmail dot com]

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

--- Comment #2 from Giacinto Cifelli  ---
It mentions the following:
"A parameter in the replacement list, unless preceded by a # or ##
preprocessing token or followed by a ## preprocessing token (see below), is
replaced by the corresponding argument after all macros contained therein have
been expanded."
(in a 2005 free draft on internet from WG14, but I have hopes that the official
ISO document hasn't changed this)

So, this is not really helpful. It can lead to the current lazy expansion or to
the expansion of each argument each time it is used, or possibly to the
pre-expansion of the list of parameters. All options are possible.

[Bug tree-optimization/89664] [8/9 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.4

[Bug middle-end/89663] [7/8/9 Regression] ICE in expand_builtin_int_roundingfn_2, at builtins.c:2831

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Mine then.

[Bug c/89573] -fexcess-precision=standard doesn't work for conversion to integer of multiplication

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to jos...@codesourcery.com from comment #2)
> On Mon, 4 Mar 2019, rguenth at gcc dot gnu.org wrote:
> 
> > where the first result is off.  The IL looks like
> > 
> > int r = (int) ((long double) log (p) * (long double) inv_log_of_base);
> > 
> > where possibly the missing cast to (double) is elided by bogus optimization
> > (didn't try to track down the issue yet).
> 
> What missing cast to double?
> 
> I wouldn't expect such a cast to be generated on the result of the 
> multiplication; I'd expect long double to be converted directly to int.  
> There is, indeed, a test of that (see test_cast in 
> gcc.target/i386/excess-precision-1.c).

Exactly why?  The multiplication result has excess precision here.
Do you say an extra rounding step to double precision cannot change
the conversion to integer result or do you say such extra rounding step
isn't allowed here?  IMHO this is exactly the "issue" pointed out by
the testcase.

Note the frontend _does_ originally emit (int) (double) ((long double) log (p)
* (long double) inv_log_of_base) but the conversion to double is elided
by convert_to_real in the code piece I qouted.

[Bug tree-optimization/82608] missing -Warray-bounds on an out-of-bounds VLA index

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
A few more test cases:

$ cat z.c && gcc -O2 -S -Wall z.c
int idx_negative (void)
{ 
  int n = 4;
  char a[n];
  return a[-99]; // -Warray-bounds (since GCC 8)
}

int idx_cst_too_big (void)
{
  int n = 4;
  char a[n];
  return a[n + 1];   // missing _Warray-bounds
}

int idx_out_of_type_bounds (unsigned char n)
{
  char a[n];
  return a[__INT_MAX__]; // missing -Warray-bounds
}

int idx_var_too_big (int n)
{ 
  char a[n];
  return a[n + 1];   // missing -Warray-bounds
}

z.c: In function ‘idx_negative’:
z.c:5:11: warning: array subscript -99 is below array bounds of ‘char[ +
1]’ [-Warray-bounds]
5 |   return a[-99]; // _Warray-bounds (since GCC 8)
  |  ~^

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[jfeng33 at hotmail dot com]

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

--- Comment #7 from Jim Feng  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Jim Feng from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > > On the other side, the testcase is invalid, because you are summing
> > > uninitialized data.  It is like if you did:
> > > program pr89651
> > >   integer :: n
> > >   real, allocatable :: t(:)
> > >   n = 10
> > >   allocate (t(n))
> > >   print *, sum (t)
> > > end program pr89651
> > > but it is true gfortran doesn't warn here either.  And we do warn even 
> > > with
> > > firstprivate(t) when it is not undefined.
> > 
> > In the test case, the array is initialized:
> > 
> > allocate(t(n),source=0.0)
> 
> Outside of the OpenMP region yes, but you are using private clause, and the
> privatized variable is just allocated, but not initialized.  You'd need to
> use firstprivate(t) clause instead to copy the data too.

I just did firstprivate  instead of private directive. Eaxct same error.

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jim Feng from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > On the other side, the testcase is invalid, because you are summing
> > uninitialized data.  It is like if you did:
> > program pr89651
> >   integer :: n
> >   real, allocatable :: t(:)
> >   n = 10
> >   allocate (t(n))
> >   print *, sum (t)
> > end program pr89651
> > but it is true gfortran doesn't warn here either.  And we do warn even with
> > firstprivate(t) when it is not undefined.
> 
> In the test case, the array is initialized:
> 
> allocate(t(n),source=0.0)

Outside of the OpenMP region yes, but you are using private clause, and the
privatized variable is just allocated, but not initialized.  You'd need to use
firstprivate(t) clause instead to copy the data too.

[Bug c++/68160] Can bind packed field if it's packed with #pragma pack(push, 1)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||nathan at acm dot org

--- Comment #2 from Eric Gallager  ---
cc-ing C++ FE maintainers

[Bug c++/60972] Mixing #pragma pack and __attribute__((packed)) leads to spurious warnings.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||nathan at acm dot org

--- Comment #2 from Eric Gallager  ---
cc-ing C++ FE maintainers

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[jfeng33 at hotmail dot com]

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

--- Comment #5 from Jim Feng  ---
(In reply to Jakub Jelinek from comment #4)
> On the other side, the testcase is invalid, because you are summing
> uninitialized data.  It is like if you did:
> program pr89651
>   integer :: n
>   real, allocatable :: t(:)
>   n = 10
>   allocate (t(n))
>   print *, sum (t)
> end program pr89651
> but it is true gfortran doesn't warn here either.  And we do warn even with
> firstprivate(t) when it is not undefined.

In the test case, the array is initialized:

allocate(t(n),source=0.0)

It is puzzling that normal compile without optimization is OK. My concern is
whether I should just disregard the warning or compile the program without
optimization.

[Bug c/82179] Optionally compile free calls in such a way that the passed pointer is clobbered after the call

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Federico Bento from comment #1)
> Hello,
> 
> This a request for an exploit mitigation to be added to the compiler,
> possibly when making use of FORTIFY_SOURCE.
> 
> Something like the below, but at the compiler level:
> 
> #define SAFE_FREE(x) do { if((x) != 0x0) { free(x); (x) = (void *)0x1; } }
> while(0)
> 
> After free(x), we set x to an address that will crash when dereferenced
> (use-after-free), and will also crash when it's an argument to free().
> Note that NULL isn't used, because free(NULL) does nothing, which might
> hide potential double-free bugs.
> 
> This will detect use-after-free and double-free bugs by having the program
> crash instead of allowing various heap grooms and further exploitation.
> 
> After discussion with Martin Sebor and Florian Weimer in the libc-alpha
> list, it was pointed out to me to post the request here for further interest.
> 
> https://sourceware.org/ml/libc-alpha/2017-09/msg00238.html
> https://sourceware.org/ml/libc-alpha/2017-09/msg00423.html
> 

In this, Martin said, "David Malcolm has done some preliminary work
on a GCC maaloc/free optimization and diagnostic pass that might be
well suited to this sort of instrumentation," so cc-ing him.

[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Slightly reduced:

namespace std {
  template  T &(T &&);
}

template  struct D {
  template  D (D x) : k( ()) {}
  S  ();
  int *k;
};

D bar ();

struct F {
  D baz () {
D f = bar ();
return std::move (*reinterpret_cast *> ());
  }
};

[Bug ipa/89666] FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Looks like test needs:
/* { dg-require-alias "" } */

[Bug ipa/89666] FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Created attachment 45942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45942=edit
ICF

[Bug ipa/89666] New: FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2

[danglin at gcc dot gnu.org]

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

Bug ID: 89666
   Summary: FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf
"Unified;" 2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c -fno-diagnostics-show-caret
-fno-diagnos
tics-show-line-numbers -fdiagnostics-color=never -O2 -fdump-ipa-icf
-fmerge-all-
constants -fdbg-cnt=merged_ipa_icf:1:3 -S -o ipa-icf-39.s
dbg_cnt 'merged_ipa_icf' set to 1-3
output is:
dbg_cnt 'merged_ipa_icf' set to 1-3

PASS: gcc.dg/ipa/ipa-icf-39.c (test for excess errors)
gcc.dg/ipa/ipa-icf-39.c: pattern found 0 times
FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[redbeard0531 at gmail dot com]

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

--- Comment #4 from Mathias Stearn  ---
@Jakub, This code doesn't have either mutable or noexcept, so the "wrong place
in the grammer" issue doesn't apply. That part of the fix seems correct and
useful.

While it seems correct to fix what the c++11-syle [[attribute]] appertains to
to match the standard, it would be unfortunate to do the same to
__attribute__(()) style attributes which are already outside of the standard.
Until the standard provides some way to have an attribute that appertains to
the lambda function, this part of the "fix" is breaking useful functionality
that has existed since GCC-5 without offering any replacement.

[Bug preprocessor/89665] inconsistent macro expansion

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The question here is does it match what the C standard says it should be
instead.

[Bug c/89663] [7/8/9 Regression] ICE in expand_builtin_int_roundingfn_2, at builtins.c:2831

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 CC||msebor at gcc dot gnu.org
Summary|ICE in  |[7/8/9 Regression] ICE in
   |expand_builtin_int_rounding |expand_builtin_int_rounding
   |fn_2, at builtins.c:2831|fn_2, at builtins.c:2831
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.4.0, 6.4.0,
   ||7.3.0, 8.2.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r185431 (GCC 4.8):

r185431 | jakub | 2012-03-15 09:30:04 -0400 (Thu, 15 Mar 2012) | 7 lines

PR middle-end/52592
* builtins.c (expand_builtin_int_roundingfn_2): If expanding
BUILT_IN_IR{INT,OUND}* using optab fails, emit lr{int,ound}*
calls instead of __builtin_ir{int,ound}*.

[Bug c/89573] -fexcess-precision=standard doesn't work for conversion to integer of multiplication

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Mon, 4 Mar 2019, rguenth at gcc dot gnu.org wrote:

> where the first result is off.  The IL looks like
> 
> int r = (int) ((long double) log (p) * (long double) inv_log_of_base);
> 
> where possibly the missing cast to (double) is elided by bogus optimization
> (didn't try to track down the issue yet).

What missing cast to double?

I wouldn't expect such a cast to be generated on the result of the 
multiplication; I'd expect long double to be converted directly to int.  
There is, indeed, a test of that (see test_cast in 
gcc.target/i386/excess-precision-1.c).

You could argue about whether the result of log should be converted to 
double (the GCC IR is unable to represent that a function might return a 
result with excess range and precision, as far as it's concerned the 
return value of log is always representable in double) - but if the issue 
is with the return value of log, that would be a glibc issue, where maybe 
glibc should avoid excess precision in return values (currently it only 
does so for functions with exactly determined IEEE results, and otherwise 
acts to avoid excess range but not excess precision in return values).  In 
the presence of Annex F a function defined by the user cannot return with 
excess range or precision, but that may not apply to standard library 
functions which don't need to behave as if written in standard C.

convert_to_real_1 has a detailed check for when conversions can be removed 
(see the "Sometimes this transformation is safe" comment), but that 
shouldn't be relevant here (it's cases like (float)((double)float * 
(double)float) where removing conversions is safe).

[Bug tree-optimization/89662] [9 Regression] -Warray-bounds ICE in contains_struct_check, at tree.h:3545

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug preprocessor/89665] New: inconsistent macro expansion

[gciofono at gmail dot com]

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

Bug ID: 89665
   Summary: inconsistent macro expansion
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gciofono at gmail dot com
  Target Milestone: ---

Created attachment 45941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45941=edit
hellomacro.c shows the inconsistent macro expansion of gcc.

The preprocessing of the macros follows a lazy-expansion algorithm that is not
entirely satisfying, nor exactly matching the description of the gcc guide,
paragraph 3.10.6 Argument Prescan.

I find that an argument should be expanded each time it is used, or
(suboptimal) each time it is declared, but the gcc preprocessor does none.

My full gcc version with Ubuntu 18.04 is:
   gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0


please compile with (includes only stdio.h but it is unavoidable to see the
output):
   gcc -v -save-temps -o hm hellomacro.c

the commented result of execution is:

$ ./hm
0-1-2-3-4<< 5 times expansion of __COUNTER__, as expected
x<< INCONSISTENCY: no expansion to __COUNTER__, because not used
direcly
5-5-5-5-5<< inconsistency: 1 expansion of counter. 5 times would have been
better
x<< inconsistency: 1 expansion of counter, because of it indirect
use, but finally discarded like two lines above
7-7-7-7-7<< output of the current counter (6 is skipped).

[Bug tree-optimization/89664] [8/9 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
  Known to work||7.4.0
 Ever confirmed|0   |1
  Known to fail||8.3.0, 9.0

--- Comment #2 from Dominique d'Humieres  ---
Revision r254940 (2017-11-19) is OK, the compiler hangs with r255143, and gives
an ICE with r255620 (2017-11-24).

[Bug tree-optimization/89662] [9 Regression] -Warray-bounds ICE in contains_struct_check, at tree.h:3545

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 CC||msebor at gcc dot gnu.org
  Component|c   |tree-optimization
Summary|[9 Regression] ICE in   |[9 Regression]
   |contains_struct_check, at   |-Warray-bounds ICE in
   |tree.h:3545 |contains_struct_check, at
   ||tree.h:3545
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Introduced by my r262893:

r262893 | msebor | 2018-07-19 19:36:34 -0400 (Thu, 19 Jul 2018) | 20 lines

PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds index
into an array
PR tree-optimization/83776 - missing -Warray-bounds indexing past the end of a
string literal

gcc/ChangeLog:

PR tree-optimization/84047
PR tree-optimization/83776
* tree-vrp.c (vrp_prop::check_mem_ref): New function.
(check_array_bounds): Call it.

[Bug rtl-optimization/89654] [8/9 Regression] Invalid reload with -march=skylake -m32

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Apparently started with r253934:

foo:
.LFB0:
.cfi_startproc
vmovq   4(%esp), %xmm0
vpsllq  $3, %xmm0, %xmm0
vmovd   %xmm0, %eax
vpextrd $1, %xmm0, %edx
ret
.cfi_endproc

while the previous revision generates:

foo:
.LFB0:
.cfi_startproc
pushl   %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
movl8(%esp), %ecx
movl12(%esp), %ebx
movl%ecx, %eax
movl%ebx, %edx
sall$3, %eax
popl%ebx
.cfi_restore 3
.cfi_def_cfa_offset 4
shldl   $3, %ecx, %edx
ret
.cfi_endproc

[Bug tree-optimization/89644] False-positive -Warray-bounds diagnostic on strncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug tree-optimization/89644] False-positive -Warray-bounds diagnostic on strncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 Ever confirmed|0   |1
  Known to fail||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Looks like a bug in handle_builtin_stxncpy which doesn't take the
strncpy bound into consideration when computing the number of characters the
function writes.

[Bug tree-optimization/89664] [8/9 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-pc-linux-gnu

--- Comment #1 from G. Steinmetz  ---

With type real functions :


$ cat z2.f90
subroutine s (x)
   real :: x
   call sub (x)
end
subroutine sub (x)
   real :: x, y
   logical :: a, b
   real :: f1, f2, f3, f4
   y = f1()
   a = .false.
   if ( f2() > f3() ) a = .true.
   b = .false.
   if ( f2() > f4() ) b = .true.
   if ( a ) then
  x = 1.0
   else if ( b ) then
  x = 1.0/y**2
   else
  x = 1.0/y - y**2
   end if
end


$ gcc-7  -c z2.f90 -Ofast
$ gcc-9-20190310 -c z2.f90 -O3
$
$ gcc-9-20190310 -c z2.f90 -Ofast
during GIMPLE pass: recip
z2.f90:1:0:

1 | subroutine s (x)
  |
internal compiler error: Segmentation fault
0xb369df crash_signal
../../gcc/toplev.c:326
0x7f4f6f nearest_common_dominator(cdi_direction, basic_block_def*,
basic_block_def*)
../../gcc/dominance.c:1015
0xc64147 insert_bb
../../gcc/tree-ssa-math-opts.c:230
0xc66380 register_division_in
../../gcc/tree-ssa-math-opts.c:293
0xc66380 execute_cse_reciprocals_1
../../gcc/tree-ssa-math-opts.c:790
0xc69e99 execute
../../gcc/tree-ssa-math-opts.c:956

[Bug tree-optimization/89664] New: [8/9 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

[gs...@t-online.de]

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

Bug ID: 89664
   Summary: [8/9 Regression] ICE in free_bb, at
tree-ssa-math-opts.c:522
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8 in combination with option -Ofast :


$ cat z1.f90
subroutine s (x)
   real :: x
   call sub (x)
end
subroutine sub (x)
   real :: x, y
   logical :: a, b
   integer :: f1, f2, f3, f4
   y = f1()
   a = .false.
   if ( f2() > f3() ) a = .true.
   b = .false.
   if ( f2() > f4() ) b = .true.
   if ( a ) then
  x = 1.0
   else if ( b ) then
  x = 1.0/y**2
   else
  x = 1.0/y - y**2
   end if
end


$ gcc-7  -c z1.f90 -Ofast
$ gcc-9-20190310 -c z1.f90 -O3
$
$ gcc-9-20190310 -c z1.f90 -Ofast
during GIMPLE pass: recip
z1.f90:1:0:

1 | subroutine s (x)
  |
internal compiler error: Segmentation fault
0xb369df crash_signal
../../gcc/toplev.c:326
0xc638b9 free_bb
../../gcc/tree-ssa-math-opts.c:522
0xc66597 execute_cse_reciprocals_1
../../gcc/tree-ssa-math-opts.c:846
0xc69e99 execute
../../gcc/tree-ssa-math-opts.c:956

[Bug c/89663] New: ICE in expand_builtin_int_roundingfn_2, at builtins.c:2831

[gs...@t-online.de]

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

Bug ID: 89663
   Summary: ICE in expand_builtin_int_roundingfn_2, at
builtins.c:2831
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Follow-up of pr89520 and pr89521 :


$ cat z1.c
long long llrint ();
long f ()
{
  return llrint(1);
}


$ cat z2.c
long long llrint (x);
void f ()
{
  return llrint(1);
}


$ cat z3.c
long lround ();
long f ()
{
  return lround(1);
}


$ cat z4.c
long lround (x);
long f ()
{
  return lround(1);
}


$ gcc-9-20190310 -c z1.c -O2
z1.c: In function 'f':
z1.c:4:17: warning: 'llrint' argument 1 type is 'int' where 'double' is
expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
4 |   return llrint(1);
  | ^
z1.c:1:11: note: built-in 'llrint' declared here
1 | long long llrint ();
  |   ^~
during RTL pass: expand
z1.c:4:10: internal compiler error: in expand_builtin_int_roundingfn_2, at
builtins.c:2831
4 |   return llrint(1);
  |  ^
0x73832c expand_builtin_int_roundingfn_2
../../gcc/builtins.c:2831
0x74eb27 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.c:7341
0x8ac4a6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11029
0x8b8256 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5673
0x8b9b48 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5436
0x7748c2 expand_call_stmt
../../gcc/cfgexpand.c:2722
0x7748c2 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3691
0x7748c2 expand_gimple_stmt
../../gcc/cfgexpand.c:3850
0x777488 expand_gimple_tailcall
../../gcc/cfgexpand.c:3897
0x777488 expand_gimple_basic_block
../../gcc/cfgexpand.c:5863
0x77d38e execute
../../gcc/cfgexpand.c:6509

[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
On x86_64-apple-darwin18 and an instrumented GCC9 (r269205) I get

% gfcg /opt/gcc/_clean/gcc/testsuite/gfortran.dg/class_61.f90 -O
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/class_61.f90:9:30:

9 | class(t2), pointer :: q(2)  ! { dg-error "must have a deferred
shape" }
  |  1
Error: Pointer array component of structure at (1) must have a deferred shape
=
==32481==ERROR: AddressSanitizer: heap-use-after-free on address 0x61303900
at pc 0x0001003efd9b bp 0x7ffeefbfe2b0 sp 0x7ffeefbfe2a8
READ of size 8 at 0x61303900 thread T0
#0 0x1003efd9a in resolve_component(gfc_component*, gfc_symbol*)
resolve.c:13828
#1 0x1003f5eec in resolve_fl_derived0(gfc_symbol*) resolve.c:14282
#2 0x1003f72d8 in resolve_fl_derived(gfc_symbol*) resolve.c:14411
#3 0x1003e45c3 in resolve_symbol(gfc_symbol*) resolve.c:14785
#4 0x1004d43fb in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4156
#5 0x1004f22e0 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4181
#6 0x10044e99d in resolve_types(gfc_namespace*) resolve.c:16697
#7 0x1003dfbe0 in gfc_resolve(gfc_namespace*) resolve.c:16811
#8 0x1003422f8 in resolve_all_program_units(gfc_namespace*) parse.c:6073
#9 0x1003629f3 in gfc_parse_file() parse.c:6321
#10 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#11 0x1063b24e8 in compile_file() toplev.c:456
#12 0x1063be87e in do_compile() toplev.c:2204
#13 0x109550717 in toplev::main(int, char**) toplev.c:2339
#14 0x1099c9345 in main main.c:39
#15 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)

0x61303900 is located 192 bytes inside of 344-byte region
[0x61303840,0x61303998)
freed by thread T0 here:
#0 0x1599d18ff in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x1004f1a17 in gfc_free_symbol(gfc_symbol*) symbol.c:3086
#2 0x1004f1d63 in gfc_release_symbol(gfc_symbol*) symbol.c:3113
#3 0x100501a1d in gfc_restore_last_undo_checkpoint() symbol.c:3706
#4 0x100502946 in gfc_undo_symbols() symbol.c:3737
#5 0x1003438c8 in reject_statement() parse.c:2576
#6 0x100343a0e in match_word(char const*, match (*)(), locus*) parse.c:70
#7 0x100350471 in decode_statement() parse.c:376
#8 0x100352bac in next_free() parse.c:1241
#9 0x10035357a in next_statement() parse.c:1473
#10 0x100358682 in parse_derived() parse.c:3285
#11 0x10035a077 in parse_spec(gfc_statement) parse.c:3825
#12 0x100360637 in parse_progunit(gfc_statement) parse.c:5680
#13 0x1003629b5 in gfc_parse_file() parse.c:6220
#14 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#15 0x1063b24e8 in compile_file() toplev.c:456
#16 0x1063be87e in do_compile() toplev.c:2204
#17 0x109550717 in toplev::main(int, char**) toplev.c:2339
#18 0x1099c9345 in main main.c:39
#19 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)

previously allocated by thread T0 here:
#0 0x1599d0de2 in wrap_calloc sanitizer_malloc_mac.inc:132
#1 0x108a1d5c7 in xcalloc xmalloc.c:162
#2 0x1004e916b in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3122
#3 0x1004eb6de in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3374
#4 0x1004eccfd in gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**)
symbol.c:3424
#5 0x1000eb431 in gfc_match_decl_type_spec(gfc_typespec*, int) decl.c:4337
#6 0x1000fac2f in gfc_match_data_decl() decl.c:5949
#7 0x10034399f in match_word(char const*, match (*)(), locus*) parse.c:65
#8 0x100350471 in decode_statement() parse.c:376
#9 0x100352bac in next_free() parse.c:1241
#10 0x10035357a in next_statement() parse.c:1473
#11 0x100358682 in parse_derived() parse.c:3285
#12 0x10035a077 in parse_spec(gfc_statement) parse.c:3825
#13 0x100360637 in parse_progunit(gfc_statement) parse.c:5680
#14 0x1003629b5 in gfc_parse_file() parse.c:6220
#15 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#16 0x1063b24e8 in compile_file() toplev.c:456
#17 0x1063be87e in do_compile() toplev.c:2204
#18 0x109550717 in toplev::main(int, char**) toplev.c:2339
#19 0x1099c9345 in main main.c:39
#20 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)

SUMMARY: AddressSanitizer: heap-use-after-free resolve.c:13828 in
resolve_component(gfc_component*, gfc_symbol*)
Shadow bytes around the buggy address:
  0x1c2606d0: fd fd fd fd fd fd fd fd fd fd fd fd fd 

[Bug c/89662] New: [9 Regression] ICE in contains_struct_check, at tree.h:3545

[gs...@t-online.de]

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

Bug ID: 89662
   Summary: [9 Regression] ICE in contains_struct_check, at
tree.h:3545
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180708 and 20180722,
with option -Wall or -Warray-bounds :


$ cat z1.c
void *f (void *c)
{
  return c;
}
void g ()
{
  int n = 1;
  char c[n];
  h (f(c) - 1);
}


$ gcc-9-20190310 -c z1.c -O2 -Wall
z1.c: In function 'g':
z1.c:9:3: warning: implicit declaration of function 'h'
[-Wimplicit-function-declaration]
9 |   h (f(c) - 1);
  |   ^
during GIMPLE pass: vrp
z1.c:5:6: internal compiler error: Segmentation fault
5 | void g ()
  |  ^
0xc2668f crash_signal
../../gcc/toplev.c:326
0x8661a7 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3545
0x8661a7 wi::extended_tree<128>::extended_tree(tree_node const*)
../../gcc/tree.h:5629
0xeeebe6 generic_wide_int >::generic_wide_int(tree_node const* const&)
../../gcc/wide-int.h:780
0xeeebe6 wi::to_offset(tree_node const*)
../../gcc/tree.h:5581
0xeeebe6 vrp_prop::check_mem_ref(unsigned int, tree_node*, bool)
../../gcc/tree-vrp.c:4726
0xeef466 vrp_prop::search_for_addr_array(tree_node*, unsigned int)
../../gcc/tree-vrp.c:4785
0xeef629 check_array_bounds
../../gcc/tree-vrp.c:4884
0xf223c3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:12108
0x95d9f0 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:253
0xed9ef1 check_array_bounds_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-vrp.c:4934
0x1486517 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xede54c vrp_prop::check_all_array_refs()
../../gcc/tree-vrp.c:4951
0xedfee5 vrp_prop::vrp_finalize(bool)
../../gcc/tree-vrp.c:6712
0xeeff2e execute_vrp
../../gcc/tree-vrp.c:6780

[Bug libstdc++/77691] [7/8/9 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #30 from Jonathan Wakely  ---
Created attachment 45940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45940=edit
Patch to fix resource_adaptor failures due to max_align_t bugs

Could you please try this patch on Soalris and HP-UX?

Commit log:

Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is.

Instead use a hardcoded list of fundamental types that will definitely
be supported by the platform malloc, and use a copy of the allocator
rebound to the first type that matches the requested alignment.

This means allocations for alignof(__float128) might use additional
memory to store the token, because we can't assume the platform malloc
will return memory aligned to alignof(__float128). Ideally we'd be able
to add __float128 to the list of fundamental types when we know it works
for a given target.

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
On the other side, the testcase is invalid, because you are summing
uninitialized data.  It is like if you did:
program pr89651
  integer :: n
  real, allocatable :: t(:)
  n = 10
  allocate (t(n))
  print *, sum (t)
end program pr89651
but it is true gfortran doesn't warn here either.  And we do warn even with
firstprivate(t) when it is not undefined.

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This changed with r265787 aka PR60503 fix and from that it seems it was
completely intentional.

[Bug fortran/89661] New: FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)

[danglin at gcc dot gnu.org]

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

Bug ID: 89661
   Summary: FAIL: gfortran.dg/class_61.f90   -O  (internal
compiler error)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.
11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/class_61.f90
-fno-
diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=ne
ver -O -pedantic-errors -S -o class_61.s
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/class_61.f90:9:30: Error: Pointer
ar
ray component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/class_61.f90:9:30: Error: Pointer
ar
ray component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gfortran.dg/class_61.f90   -O  (internal compiler error)
PASS: gfortran.dg/class_61.f90   -O   (test for errors, line 9)
FAIL: gfortran.dg/class_61.f90   -O  (test for excess errors)

[Bug libstdc++/89460] FAIL: experimental/net/headers.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Should be fixed on trunk now.

[Bug libstdc++/89460] FAIL: experimental/net/headers.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 11 16:28:11 2019
New Revision: 269588

URL: https://gcc.gnu.org/viewcvs?rev=269588=gcc=rev
Log:
PR libstdc++/89460 Fix Networking TS test failures on HP-UX

Check for availability of POSIX sockatmark before using it.

Rename _S_ntoh overloads that are ambiguous when passed an integral type
that is neither uint16_t nor uint32_t.

PR libstdc++/89460
* configure.ac: Check for sockatmark.
* crossconfig.m4: Check for sockatmark.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/experimental/internet (address_v4::_S_hton): Rename
overloaded functions to _S_hton_16 and _S_ntoh_16.
(address_v4::_S_ntoh): Rename to _S_ntoh_16 and _S_ntoh_32.
(basic_endpoint): Adjust calls to _S_hton and _S_ntoh.
* include/experimental/socket (basic_socket::at_mark): Check
_GLIBCXX_HAVE_SOCKATMARK.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/crossconfig.m4
trunk/libstdc++-v3/include/experimental/internet
trunk/libstdc++-v3/include/experimental/socket

[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/89660] New: [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[jakub at gcc dot gnu.org]

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

Bug ID: 89660
   Summary: [9 Regression] Rejects-valid error with
-Wredundant-move starting with r269427
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

enum A { B };
namespace std {
template  T &(T &&);
}
struct C;
template  struct D;
struct C { using f = int *; };
template  struct D {
  template  D (D x) : k( ()) {}
  S  ();
  typename V::f k;
};
struct E {
  D bar ();
};
struct F {
  E e;
  D baz () {
D f = e.bar ();
return std::move (*reinterpret_cast *> ());
  }
};

is rejected with -Wredundant-move but accepted with -Wno-redundant-move,
starting with r269427.  Before it has been accepted regardless of whether
-W{,no-}redundant-move has been specified or not (but warned about a redundant
move).