[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

[edlinger at gcc dot gnu.org]

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

--- Comment #4 from Bernd Edlinger  ---
Author: edlinger
Date: Sat Sep  7 05:11:16 2019
New Revision: 275484

URL: https://gcc.gnu.org/viewcvs?rev=275484=gcc=rev
Log:
add PR target/91684 to ChangeLog

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug target/38093] undefined predicates in bfin.md

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
So, if I understand the patch, isn't this just papering over the issue by
fixing the specific instance of the bfin target causing this genrecog crash?
That is, couldn't some other port also cause genrecog to crash similarly by
making the same mistake? If that's the case, I think it'd make sense to patch
genrecog to print a sensible error message instead of just crashing...

[Bug middle-end/53074] insn-recog.c:recog calls predicates known to be false before matching bare RTL code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Hans-Peter Nilsson from comment #0)
> The following was observed for gcc-4_7-branch r185763 as well as for trunk
> r186667.
> 
> The decision-tree in insn-recog.c, when generated from candidate patterns
> where one candidate (the first in file) pattern has a bare (label_ref ...)
> (without specified mode) and others (after the first in the file) has
> (match_operand:SI "operand_known_to_not_match_label_ref" ...) where
> operand_known_to_not_match_label_ref is for example, nonimmediate_operand or
> register_operand, inspects the mode of the operand of the insn being matched
> and calls the predicates despite it knowing they will fail.  After the
> calls, it will correctly match the insn to the first pattern.  This will not
> happen if the predicate is not known to fail or when no mode is specified
> for the second pattern (then there's the expected test for LABEL_REF).  It
> should instead always first check the operand to be LABEL_REF, matching the
> first pattern.
> 
> I'm labelling this as "missed optimization"; I can't make a strong case that
> the predicate call should be considered wrong-code, though the argument
> would be that it could assert, as there's no point calling it for a
> label_ref as the first pattern will always match.
> 
> It could be that this is a special-case and that inspecting mode and calling
> predicates is seen as cheaper than inspecting the actual operand code and
> matching any mode, but at face value it doesn't make sense, in particular as
> the rules are that the first pattern has to match.
> 
> See  for actual generated
> code and further discussion.

cc-ing Richard from that thread

[Bug target/33104] Missing error check in .md converter

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
since this is a bug in genextract, cc-ing the gen* maintainer

[Bug other/26966] [7/8/9/10 Regression] linking of C++/ObjC app fail on OpenBSD 3.9/10 due POSIX threading unresolved symbols

[egallager at gcc dot gnu.org]

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

--- Comment #31 from Eric Gallager  ---
(In reply to Mark Mitchell from comment #16)
> OpenBSD is not a primary or secondary platform.

Is the OpenBSD port even still maintained? I don't see any maintainer listed
for it in MAINTAINERS, and the only mention of it at all in that file is in
Marc Espie's email address, but it appears he uses different emails here on
bugzilla... (not sure which one to cc)

[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Patch is ok for trunk by me if it passes proper bootstrap and regtest

[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
(In reply to Martin Sebor from comment #13)
> (In reply to Christophe Lyon from comment #10)
> 
> Yes, the warning is intended and Glibc was just patched to avoid it:
> https://sourceware.org/ml/glibc-cvs/2019-q3/msg00459.html
> 
> (In reply to Iain Sandoe from comment #11)

> Anyway, since this bug is specific to Warray-bounds-4.C on
> hppa2.0w-hp-hpux11.11, 

We have found a number of cases over the years where hpux and darwin shared
test behaviour - so I'll monitor this; if the Darwin case isn't fixed by
whatever resolution we apply for hpux, we can raise a new PR then.

[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
with the path applied on x86_64-darwin16 (same results for c++98 / c++17

unless the line count in the test has changed, this is a progression - three
fewer fails - but it seems 3 different ones)

XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 16)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 24)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 25)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 26)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 35)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 36)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 37)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 46)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 47)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 48)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 58)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 59)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 68)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 311)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 314)
XPASS: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14 pr91463 (test for warnings,
line 318)
FAIL: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14  (test for warnings, line
336)
FAIL: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14  (test for warnings, line
352)
FAIL: g++.dg/warn/Warray-bounds-8.C  -std=gnu++14  (test for warnings, line
366)

  no change here

FAIL: g++.dg/warn/Wstringop-overflow-3.C  -std=gnu++14  (test for warnings,
line 333)
FAIL: g++.dg/warn/Wstringop-overflow-3.C  -std=gnu++14  (test for warnings,
line 349)
FAIL: g++.dg/warn/Wstringop-overflow-3.C  -std=gnu++14  (test for warnings,
line 363)

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[skpgkp2 at gmail dot com]

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

--- Comment #20 from Sunil Pandey  ---
Created attachment 46851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46851=edit
Compile time regression reproducer.

attached reproducer show ~28X compile time regression after the commit. See the
command line in readme.txt file.

[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs

[jorg.brown at gmail dot com]

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

Jorg Brown  changed:

   What|Removed |Added

 CC||jorg.brown at gmail dot com

--- Comment #15 from Jorg Brown  ---
Related non-compilation bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91693

[Bug c++/91693] Comparing addresses of templated inline vars gets bogus "not a constant expression" error

[jorg.brown at gmail dot com]

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

--- Comment #1 from Jorg Brown  ---
Related missed-optimization bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-06
 CC||wilson at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |wilson at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jim Wilson  ---
Created attachment 46850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46850=edit
proposed fix

This is failing in undo_all in combine, trying to write to a pointer into data
that has been garbage collected.

The problem starts with a riscv.md splitter which calls riscv_move_integer
which checks can_create_pseudo_p and calls force_reg if allowed.  This
eventually calls gen_reg_rtx which calls ensure_regno_capacity which calls
ggc_realloc, which invalidates the data in the undo buffer since all pseudo reg
addresses change.  I guess this is another reason why calling gen_reg_rtx in a
splitter is a bad idea.

I can fix it by adding another option to riscv_move_integer to indicate when we
are calling it from inside a splitter, but maybe I will think of a better way
to fix the problem later.

The fact that this requires a ggc_realloc call to happen in a very precise
place means that this testcase does not appear to be very useful.  There is no
guarantee it will trigger the problem if other parts of the compiler change.

[Bug target/91696] [X86] AVX512 intrinsics that only support SAE should allow (_MM_FOUND_NO_EXC|_MM_FROUND_CUR_DIRECTION) to match icc

[craig.topper at gmail dot com]

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

--- Comment #1 from Craig Topper  ---
I've also submitted a patch to clang to do the same.
https://reviews.llvm.org/D67289

[Bug target/91696] New: [X86] AVX512 intrinsics that only support SAE should allow (_MM_FOUND_NO_EXC|_MM_FROUND_CUR_DIRECTION) to match icc

[craig.topper at gmail dot com]

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

Bug ID: 91696
   Summary: [X86] AVX512 intrinsics that only support SAE should
allow (_MM_FOUND_NO_EXC|_MM_FROUND_CUR_DIRECTION) to
match icc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: craig.topper at gmail dot com
  Target Milestone: ---

The intrinsics that only support SAE like _mm512_cmp_round_ps_mask currently
only allow __MM_FROUND_NO_EXC or _MM_FROUND_CUR_DIRECTION to be specified in
the sae immediate parameter.

_MM_FROUND_NO_EXC isn't really the opposite of _MM_FROUND_CUR_DIRECTION based
on the format of this type of immediate. _MM_FROUND_NO_EXC by itself is
equivalent to (_MM_FROUND_NO_EXC|_MM_FROUND_TO_NEAREST_INT) since
_MM_FROUND_TO_NEAREST_INT is 0. But these instructions don't perform any
rounding so the rounding bits don't matter. It's a nice convenience that the
single constants _MM_FROUND_NO_EXC and _MM_FROUND_CUR_DIRECTION can be used.
But since the rounding mode doesn't matter
(_MM_FROUND_CUR_DIRECTION|_MM_FROUND_NO_EXC) should also be allowed.

[Bug libgcc/91695] New: [X86] get_available_features only sets FEATURE_GFNI and FEATURE_VPCLMULQDQ when avx512_usable is true

[craig.topper at gmail dot com]

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

Bug ID: 91695
   Summary: [X86] get_available_features only sets FEATURE_GFNI
and FEATURE_VPCLMULQDQ when avx512_usable is true
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: craig.topper at gmail dot com
  Target Milestone: ---

GFNI has instructions that have legacy SSE-like encodings. It also has VEX and
EVEX encodings. VPCLMULQDQ has a VEX encoding for 256-bit and EVEX encoding
256-bit and 512-bit. So these features are usable without AVX512.

It probably makes sense to qualify VPCLMULQDQ with avx_usable since it requires
at least ymm registers.

[Bug go/91692] gcc build fails with --enable-languages="go"

[thomas at doczkal dot eu]

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

--- Comment #3 from thomas at doczkal dot eu ---
On September 6, 2019 9:00:31 PM UTC, ian at airs dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91692
>
>--- Comment #2 from Ian Lance Taylor  ---
>Thanks for the bug report.  The normal case when configuring GCC is to
>create a
>new empty directory and run SRCDIR/configure in that directory, as
>documented
>at https://gcc.gnu.org/install/configure.html.  Your suggested patch
>will break
>that normal case.
>
>The case of running ./configure should also work, but is rarely tested.
>
>Clearly there is something wrong in that case that will need to be
>fixed.

Thanks for your answer. I'll try to do your suggestions and repeat the build in
a separate directory and will try the configure without options after applying
the patch. 

I'll get back to you.

[Bug libgomp/91694] New: configure.ac does not correctly check for gethostname

[ri...@extreme-scale.com]

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

Bug ID: 91694
   Summary: configure.ac does not correctly check for gethostname
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ri...@extreme-scale.com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

In commit 7e5a76c87d27b72e05b0b32189e9cfafaebba6bc at:
https://github.com/gcc-mirror/gcc/commit/7e5a76c87d27b72e05b0b32189e9cfafaebba6bc

configure.ac (line 283) is setup to COMPILE a program that has:
#include 
int
main ()
{

   char buf[256];
   if (gethostname (buf, sizeof (buf) - 1) == 0)
 buf[255] = '\0';

  ;
  return 0;
}

The output of this (if gethostname is not defined is):
tmp1.c: In function 'main':
tmp1.c:7:8: warning: implicit declaration of function 'gethostname'; did you
mean 'sethostname'? [-Wimplicit-function-declaration]
7 |if (gethostname (buf, sizeof (buf) - 1) == 0)
  |^~~
  |sethostname

And, if you link it, it will error out with:
/tmp/ccYoUvKr.o: In function `main':
.../libgomp/tmp1.c:7: undefined reference to `gethostname'
collect2: error: ld returned 1 exit status

I think AC_COMPILE_IFELSE should be AC_LINK_IFELSE.

However, I'm not sure. Can someone please comment?

[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> (In reply to Thomas Koenig from comment #2)
> > Is this actually required?  My feeling would be that is is not, but I may
> > well be mistaken.
> > 
> > Does somebody have chapter & verse on this? And what do other compilers do?
> 
> NAG, Intel & Cray do not leak according to valgrind.  NAG also gives a nice
> runtime memory trace with -mtrace.
> 
> I think the following applies:
> 
> F2018 DIS:
> 
> 9.7.3.2  Deallocation of allocatable variables
> 
> 8 When a variable of derived type is deallocated, any allocated allocatable
> subobject is deallocated. [...]
> 
> I do not see any mentioning to whether "variable" is ALLOCATABLE or POINTER
> here.

You don't need to see ALLOCATABLE or POINTER.  In "..., any allocated 
allocatable ...' the word 'allocatable' has an internal link to its
definition.

3.2
allocatable
having the ALLOCATABLE attribute (8.5.3)

8.5.3 ALLOCATABLE attribute

A variable with the ALLOCATABLE attribute is a variable for which space is
allocated during execution.

Here, we see that 'allocatable' does not include 'POINTER attribute'.

So, now, we go back to the beginning of the section

The DEALLOCATE statement causes allocatable variables to be deallocated;
it causes pointer targets to be deallocated and the pointers to be
disassociated.

For the lack of a better description, 'allocate(test(10))' allocates
an anonymous target.  'deallocate(test)' deallocates that anonymous
target and dissociates the pointer.

So, now we go to 9.7.3.3 "Deallocation of pointer targets"
This section does not say what happens to allocated allocatable
components when the pointer target is deallocated.  QoI probably
means that gfortran should do a deep deallocation, but I don't
think it is required by the Fortran standard.

[Bug go/91692] gcc build fails with --enable-languages="go"

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
Thanks for the bug report.  The normal case when configuring GCC is to create a
new empty directory and run SRCDIR/configure in that directory, as documented
at https://gcc.gnu.org/install/configure.html.  Your suggested patch will break
that normal case.

The case of running ./configure should also work, but is rarely tested. 
Clearly there is something wrong in that case that will need to be fixed.

[Bug c++/91693] New: Comparing addresses of templated inline vars gets bogus "not a constant expression" error

[jorg.brown at gmail dot com]

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

Bug ID: 91693
   Summary: Comparing addresses of templated inline vars gets
bogus "not a constant expression" error
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jorg.brown at gmail dot com
  Target Milestone: ---

This code works just fine:

inline int inline1 = 0;
inline int inline2 = 0;
static_assert( == );
static_assert( != );

But this code doesn't:

template
inline int NullT = 0;

struct A1;
struct A2;

static_assert( == );
static_assert( != );

Specifically, it produces this incorrect error:

:13:26: error: non-constant condition for static assertion

   13 | static_assert( != );

  |   ~~~^

:13:26: error: '((& NullT) != (& NullT))' is not a constant
expression

= = =

Problem reproduces in gcc 7.1 through 9.2; this code works in clang (tested as
far back as 5.0) as well as MSVC (tested as far back as v19.14)

See https://godbolt.org/z/njyH5d

[Bug c++/91673] [10 Regression] GCC ICE when partially specialising class template on a function-signature type with deduced noexcept qualifier

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Reduced:

template
struct S {
  using U = void() noexcept(B);
};

S s;

[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array

[c.s.brady at warwick dot ac.uk]

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

--- Comment #4 from c.s.brady at warwick dot ac.uk ---
My belief was based on the same statement in section 6.3.3 of the F2003
standard

[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #2)
> Is this actually required?  My feeling would be that is is not, but I may
> well be mistaken.
> 
> Does somebody have chapter & verse on this? And what do other compilers do?

NAG, Intel & Cray do not leak according to valgrind.  NAG also gives a nice
runtime memory trace with -mtrace.

I think the following applies:

F2018 DIS:

9.7.3.2  Deallocation of allocatable variables

8 When a variable of derived type is deallocated, any allocated allocatable
subobject is deallocated. [...]

I do not see any mentioning to whether "variable" is ALLOCATABLE or POINTER
here.

[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
Is this actually required?  My feeling would be that is is not, but I may well
be mistaken.

Does somebody have chapter & verse on this? And what do other compilers do?

[Bug middle-end/91680] Integer promotion quirk prevents efficient power of 2 division

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It is not that easy.  For C99 1 << 31 is UB, but for C89 it is unclear, and I
believe in C++ it is well defined, similarly in the middle-end it is well
defined.
So, while 1 << x is a power of 2, possibly negative, (unsigned long long) (1 <<
x)
is only power of two if x is not 31, otherwise it is -2147483648ULL.
Guess for 256 / q we could still optimize it because 256 / -2147483648ULL == 0
== 256 >> 31, but we can't do that for arbitrary dividend (e.g. variable),
where we can't prove that it makes no difference.

[Bug c++/67862] [concepts] ICE in tsubst, at cp/pt.c:12625

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46849=edit
Patch against concepts-cxx2a (git format-patch format)

The original attachment doesn't build any more (compiler version issues) and
the 2nd issue has some compilation errors. After fixing the compilation errors,
this produces an ICE.

The attached patch fixes the associated crash, but this is likely not the same
as the issue originally submitted, which has either already been fixed or is
handled in completely different way.

There are two fixes here. First, normalization needs to find template
parameters in template-ids, including specializations of type alias templates.
Second, the normalization arguments from partial specializations must be formed
from the specialization parameters and not the most general template.

The included test is a fixed version of the 2nd attachment.

[Bug fortran/91686] ICE in gimplify:2554

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-06
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
You'll need to upgrade to a newer version of gfortran.  The bug appears to be
fixed on the 8-branch, 9-branch, and trunk.  I'll the bug report open as
someone might backport the fix (if it can be identified) to the 7-branch.

% gfcx -o z a.f90 && ./z
c
bbb
a
% gfc9 -o z a.f90 && ./z
c
bbb
a
% gfc8 -o z a.f90 && ./z
c
bbb
a
troutmask:sgk[243] gfc7 -o z a.f90 && ./z
a.f90:6:0:

   pageout=pageout([3,2,1])

internal compiler error:

[Bug go/91692] gcc build fails with --enable-languages="go"

[bugs at doczkal dot eu]

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

--- Comment #1 from Thomas Doczkal  ---
Created attachment 46848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46848=edit
config.log file

[Bug middle-end/91679] missing -Warray-bounds accessing a member array in a local buffer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

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

[Bug c/91463] missing -Warray-bounds accessing past the end of a statically initialized flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00425.html

[Bug target/91654] Regressions of SPEC2017 rate caused by r274994

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Sep  6 19:27:58 2019
New Revision: 275475

URL: https://gcc.gnu.org/viewcvs?rev=275475=gcc=rev
Log:
PR target/91654
* config/i386/x86-tune-costs.h (skylake_cost): Raise the
cost of SSE->integer and integer->SSE moves from 2 to 6.
(core_cost): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/x86-tune-costs.h

[Bug go/91692] New: gcc build fails with --enable-languages="go"

[bugs at doczkal dot eu]

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

Bug ID: 91692
   Summary: gcc build fails with --enable-languages="go"
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: bugs at doczkal dot eu
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 46847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46847=edit
Patch file to patch libgodir

/usr/bin/mkdir -p cmd/go/internal; files=`echo
../../.././libgo/go/cmd/go/internal/bug/bug.go bytes.gox
cmd/go/internal/base.gox cmd/go/internal/cfg.gox cmd/go/internal/envcmd.gox
cmd/go/internal/web.gox fmt.gox io.gox io/ioutil.gox os/exec.gox os.gox
path/filepath.gox regexp.gox runtime.gox strings.gox | sed -e 's/[^ ]*\.gox//g'
-e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile
/home/thomas/builds/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/gccgo
-B/home/thomas/builds/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include   -fno-checking 
-minline-all-stringops  -O2 -g  -m32 -I . -c -fgo-pkgpath=`echo
cmd/go/internal/bug.lo | sed -e 's/.lo$//'` -static -o cmd/go/internal/bug.lo
$files
libtool: compile: 
/home/thomas/builds/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/gccgo
-B/home/thomas/builds/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fno-checking -minline-all-stringops
-O2 -g -m32 -I . -c -fgo-pkgpath=cmd/go/internal/bug
../../.././libgo/go/cmd/go/internal/bug/bug.go -o cmd/go/internal/bug.o
rm -f libgotool.a
ar cru libgotool.a  cmd/go/internal/base.o cmd/go/internal/bug.o
cmd/go/internal/cache.o cmd/go/internal/cfg.o cmd/go/internal/clean.o
cmd/go/internal/cmdflag.o cmd/go/internal/dirhash.o cmd/go/internal/doc.o
cmd/go/internal/envcmd.o cmd/go/internal/fix.o cmd/go/internal/fmtcmd.o
cmd/go/internal/generate.o cmd/go/internal/get.o cmd/go/internal/help.o
cmd/go/internal/imports.o cmd/go/internal/list.o cmd/go/internal/load.o
cmd/go/internal/lockedfile.o cmd/go/internal/lockedfile/internal/filelock.o
cmd/go/internal/modcmd.o cmd/go/internal/modconv.o cmd/go/internal/modfetch.o
cmd/go/internal/modfetch/codehost.o cmd/go/internal/modfile.o
cmd/go/internal/modget.o cmd/go/internal/modinfo.o cmd/go/internal/modload.o
cmd/go/internal/module.o cmd/go/internal/mvs.o cmd/go/internal/par.o
cmd/go/internal/renameio.o cmd/go/internal/run.o cmd/go/internal/search.o
cmd/go/internal/semver.o cmd/go/internal/str.o cmd/go/internal/test.o
cmd/go/internal/tool.o cmd/go/internal/txtar.o cmd/go/internal/version.o
cmd/go/internal/vet.o cmd/go/internal/web.o cmd/go/internal/web2.o
cmd/go/internal/webtest.o cmd/go/internal/work.o cmd/internal/browser.o
cmd/internal/buildid.o cmd/internal/edit.o cmd/internal/objabi.o
cmd/internal/sys.o cmd/internal/test2json.o golang.org/x/tools/go/analysis.o
golang.org/x/tools/go/analysis/internal/analysisflags.o
golang.org/x/tools/go/analysis/internal/facts.o
golang.org/x/tools/go/analysis/passes/asmdecl.o
golang.org/x/tools/go/analysis/passes/assign.o
golang.org/x/tools/go/analysis/passes/atomic.o
golang.org/x/tools/go/analysis/passes/bools.o
golang.org/x/tools/go/analysis/passes/buildtag.o
golang.org/x/tools/go/analysis/passes/cgocall.o
golang.org/x/tools/go/analysis/passes/composite.o
golang.org/x/tools/go/analysis/passes/copylock.o
golang.org/x/tools/go/analysis/passes/ctrlflow.o
golang.org/x/tools/go/analysis/passes/httpresponse.o
golang.org/x/tools/go/analysis/passes/inspect.o
golang.org/x/tools/go/analysis/passes/internal/analysisutil.o
golang.org/x/tools/go/analysis/passes/loopclosure.o
golang.org/x/tools/go/analysis/passes/lostcancel.o
golang.org/x/tools/go/analysis/passes/nilfunc.o
golang.org/x/tools/go/analysis/passes/pkgfact.o
golang.org/x/tools/go/analysis/passes/printf.o
golang.org/x/tools/go/analysis/passes/shift.o
golang.org/x/tools/go/analysis/passes/stdmethods.o
golang.org/x/tools/go/analysis/passes/structtag.o
golang.org/x/tools/go/analysis/passes/tests.o
golang.org/x/tools/go/analysis/passes/unmarshal.o
golang.org/x/tools/go/analysis/passes/unreachable.o
golang.org/x/tools/go/analysis/passes/unsafeptr.o
golang.org/x/tools/go/analysis/passes/unusedresult.o
golang.org/x/tools/go/analysis/unitchecker.o
golang.org/x/tools/go/ast/astutil.o golang.org/x/tools/go/ast/inspector.o
golang.org/x/tools/go/cfg.o golang.org/x/tools/go/types/objectpath.o
golang.org/x/tools/go/types/typeutil.o
ar: `u' modifier ignored since `D' is the default (see `U')
ranlib libgotool.a
make[8]: Leaving directory
'/home/thomas/builds/gcc-9.2.0/x86_64-pc-linux-gnu/32/libgo'
make[7]: Leaving directory

[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #10 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00425.html

[Bug fortran/91690] Slow IEEE intrinsics

[kargl at gcc dot gnu.org]

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

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 ---

(In reply to Rich Townsend from comment #0)
> Created attachment 46844 [details]
> Demo program
> 
> The intrinsics provided by the IEEE_ARITHMETIC module appear to be
> significantly slower than an equivalent implementation based on inspecting
> bits.
> 

The implementations are not equivalent.  -fdump-tree-original may
shield some light.

is_nan_bits() isn't worried about FPU state (ie., keeping track of 
exceptions).  is_nan_bits is reduced to something simply using simple
bit twiddling.  The following is somewhat edited to reduce length

is_nan_bits (real(kind=4) & x)
{
  integer(kind=4) expn, frac, is_nan, ix, sign;
  {
integer(kind=8) D.3904, D.3905, D.3906, transfer.0;
D.3904 = 4;
D.3905 = 4;
__builtin_memcpy ((void *) , (void *) x,
  (unsigned long) MAX_EXPR , 0>);
ix = transfer.0;
  }
  frac = NON_LVALUE_EXPR  & 8388607;
  expn = ix >> 23 & 255;
  sign = (integer(kind=4)) ((unsigned int) ix >> 31);
  is_nan = expn == 255 && frac != 0;
  return is_nan;
}

is_nan_ieee is reduced to something with 2 function calls
to maintain fpu state.

is_nan_ieee (real(kind=4) & restrict x)
{
  c_char fpstate.1[33];
  logical(kind=4) is_nan;
  try
{
  _gfortran_ieee_procedure_entry ((void *) );
  is_nan = SAVE_EXPR <*x> unord SAVE_EXPR <*x>;
  return is_nan;
}
  finally
{
  _gfortran_ieee_procedure_exit ((void *) );
}
}

Both _entry and _exit are manipulating the FPU.

[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-06
 Ever confirmed|0   |1

--- Comment #2 from Wilco  ---
(In reply to Bernd Edlinger from comment #1)
> Created attachment 46846 [details]
> untested patch

Thanks - that fixes the issue indeed! I now get:

mov r2, #0
mov r3, #0
str lr, [sp, #-4]!
sub sp, sp, #20
add r0, sp, #4
strdr2, [sp, #4]
str r2, [sp, #12]
bl  g
add sp, sp, #20
ldr pc, [sp], #4

[Bug c/91463] missing -Warray-bounds accessing past the end of a statically initialized flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Also pr91679.

[Bug c/91463] missing -Warray-bounds accessing past the end of a statically initialized flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-06
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91647
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
My patch for PR 91647 extends -Warray-bounds to detect these bugs.

[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-06
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

All tested versions since at least 4.3 show the leak.

[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
Created attachment 46846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46846=edit
untested patch

[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Looking back at the code I see we are translating from Front-end to run time
regarding whether or not we actually are going to show the positive sign or not
or suppress it the sign altogether in floating point writes. In this process we
actually have three different enumumerators defined. I am going to analyze this
a bit more since it "seems" that one ought to be able to do this all in one
step at the right place.  There is a comment about keeping things alligned so
as to not break the ABI, so I would bet that as the standards evolved we had to
evolve this code a bit. I will see what I can come up with that might make more
sense and not break the ABI. (other than just doing a cast)

[Bug c/91691] Cross compiling glibc produces a false maybe-uninitialized error

[alistair at alistair23 dot me]

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

--- Comment #2 from Alistair  ---
I can also reproduce this with the 9.2 release.

[Bug c/91691] Cross compiling glibc produces a false maybe-uninitialized error

[alistair at alistair23 dot me]

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

--- Comment #1 from Alistair  ---
The full command line is:

gcc clnt_udp.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall -Wwrite-strings -Wundef
-Werror -fmerge-all-constants -frounding-math -fno-stack-protector
-Wstrict-prototypes -Wold-style-definition -fmath-errno   -fPIC  
-ftls-model=initial-exec  -I../include
-I/scratch/alistair/software/tier3/buildroot/output/build/glibc-custom/build/sunrpc
 -I/scratch/alistair/software/tier3/buildroot/output/build/glibc-custom/build 
-I../sysdeps/unix/sysv/linux/riscv/rv32  -I../sysdeps/unix/sysv/linux/riscv 
-I../sysdeps/riscv/nptl  -I../sysdeps/unix/sysv/linux/generic/wordsize-32 
-I../sysdeps/unix/sysv/linux/generic  -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread 
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv 
-I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/riscv/rv32/rvd 
-I../sysdeps/riscv/rv32/rvf  -I../sysdeps/riscv/rvf  -I../sysdeps/riscv/rvd 
-I../sysdeps/riscv/rv32  -I../sysdeps/riscv  -I../sysdeps/init_array 
-I../sysdeps/ieee754/ldbl-128  -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754 
-I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem
/scratch/alistair/software/tier3/buildroot/output/host/lib/gcc/riscv32-buildroot-linux-gnu/8.3.0/include
-isystem
/scratch/alistair/software/tier3/buildroot/output/host/lib/gcc/riscv32-buildroot-linux-gnu/8.3.0/include-fixed
-isystem
/scratch/alistair/software/tier3/buildroot/output/host/riscv32-buildroot-linux-gnu/sysroot/usr/include
 -D_LIBC_REENTRANT -include
/scratch/alistair/software/tier3/buildroot/output/build/glibc-custom/build/libc-modules.h
-DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC -DSHARED
-DTOP_NAMESPACE=glibc -o
/scratch/alistair/software/tier3/buildroot/output/build/glibc-custom/build/sunrpc/compat-clnt_udp.os
-MD -MP -MF
/scratch/alistair/software/tier3/buildroot/output/build/glibc-custom/build/sunrpc/compat-clnt_udp.os.dt
-MT
/scratch/alistair/software/tier3/buildroot/output/build/glibc-custom/build/sunrpc/compat-clnt_udp.os
-DEXPORT_RPC_SYMBOLS

[Bug c/91691] New: Cross compiling glibc produces a false maybe-uninitialized error

[alistair at alistair23 dot me]

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

Bug ID: 91691
   Summary: Cross compiling glibc produces a false
maybe-uninitialized error
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alistair at alistair23 dot me
  Target Milestone: ---
Target: riscv32
 Build: x86_64

Created attachment 46845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46845=edit
Output of -save-temps

When cross compiling the RISC-V 32-bit port/fork of glibc [1] the following
warning/error is seen:

In file included from clnt_udp.c:58:
clnt_udp.c: In function 'clntudp_call':
../inet/net-internal.h:107:13: error: '*((void *)_deadline+8)' may be
used uninitialized in this function [-Werror=maybe-uninitialized]
 || (current.current.tv_sec == deadline.absolute.tv_sec
~~~
 && current.current.tv_nsec >= deadline.absolute.tv_nsec));
 ^~~~
clnt_udp.c:293:19: note: '*((void *)_deadline+8)' was declared here
   struct deadline total_deadline; /* Determined once by overall timeout.  */
   ^~
In file included from clnt_udp.c:58:
../inet/net-internal.h:116:7: error: 'total_deadline' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
   if (__deadline_is_infinite (right)
   ~~
   || left.absolute.tv_sec < right.absolute.tv_sec
   ~~~
   || (left.absolute.tv_sec == right.absolute.tv_sec
   ^
   && left.absolute.tv_nsec < right.absolute.tv_nsec))
   ~~
clnt_udp.c:293:19: note: 'total_deadline' was declared here
   struct deadline total_deadline; /* Determined once by overall timeout.  */
   ^~

This occurs in the clntudp_call) function in glibcs sunrpc/clnt_udp.c.

The code looks like this:

...
  struct deadline total_deadline; /* Determined once by overall timeout.  */
  struct deadline response_deadline; /* Determined anew for each query.  */

  /* Choose the timeout value.  For non-sending usage (xargs == NULL),
 the total deadline does not matter, only cu->cu_wait is used
 below.  */
  if (xargs != NULL)
{
  struct timeval tv;
  if (cu->cu_total.tv_usec == -1)
/* Use supplied timeout.  */
tv = utimeout;
  else
/* Use default timeout.  */
tv = cu->cu_total;
  if (!__is_timeval_valid_timeout (tv))
return (cu->cu_error.re_status = RPC_TIMEDOUT);
  total_deadline = __deadline_from_timeval (current_time, tv);
}

  /* Guard against bad timeout specification.  */
  if (!__is_timeval_valid_timeout (cu->cu_wait))
return (cu->cu_error.re_status = RPC_TIMEDOUT);

call_again:
  xdrs = &(cu->cu_outxdrs);
  if (xargs == NULL)
goto get_reply;
  xdrs->x_op = XDR_ENCODE;
  XDR_SETPOS (xdrs, cu->cu_xdrpos);
  /*
   * the transaction is the first thing in the out buffer
   */
  (*(uint32_t *) (cu->cu_outbuf))++;
  if ((!XDR_PUTLONG (xdrs, (long *) )) ||
  (!AUTH_MARSHALL (cl->cl_auth, xdrs)) ||
  (!(*xargs) (xdrs, argsp)))
return (cu->cu_error.re_status = RPC_CANTENCODEARGS);
  outlen = (int) XDR_GETPOS (xdrs);

send_again:
  if (__sendto (cu->cu_sock, cu->cu_outbuf, outlen, 0,
(struct sockaddr *) &(cu->cu_raddr), cu->cu_rlen)
  != outlen)
{
  cu->cu_error.re_errno = errno;
  return (cu->cu_error.re_status = RPC_CANTSEND);
}

  /* sendto may have blocked, so recompute the current time.  */
  current_time = __deadline_current_time ();
 get_reply:
  response_deadline = __deadline_from_timeval (current_time, cu->cu_wait);

  reply_msg.acpted_rply.ar_verf = _null_auth;
  reply_msg.acpted_rply.ar_results.where = resultsp;
  reply_msg.acpted_rply.ar_results.proc = xresults;
  fd.fd = cu->cu_sock;
  fd.events = POLLIN;
  anyup = 0;

  /* Per-response retry loop.  current_time must be up-to-date at the
 top of the loop.  */
  for (;;)
{
  int milliseconds;
  if (xargs != NULL)
{
  if (__deadline_elapsed (current_time, total_deadline))
/* Overall timeout expired.  */
return (cu->cu_error.re_status = RPC_TIMEDOUT);
  milliseconds = __deadline_to_ms
(current_time, __deadline_first (total_deadline,
 response_deadline));
  if (milliseconds == 0)
/* Per-query timeout expired.  */
goto send_again;
}
...

So although it is confusing, the total_deadline variable can not be used
uninitalised.

Initalising total_deadline to 0 

[Bug fortran/91690] New: Slow IEEE intrinsics

[townsend at astro dot wisc.edu]

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

Bug ID: 91690
   Summary: Slow IEEE intrinsics
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 46844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46844=edit
Demo program

The intrinsics provided by the IEEE_ARITHMETIC module appear to be
significantly slower than an equivalent implementation based on inspecting
bits.

I attach a short program that demonstrates this. Compiling with

gfortran -O2 -o test_ieee test_ieee.f90

...I get the following output:

  Using IEEE
time:   16.1860008
 Using bits
time:  0.10104 

So, the IEEE_IS_NAN() intrinsic appears to be ~160 times slower than inspecting
bits directly. Other intrinsics seem to show similar issues.

cheers,

Rich

[Bug c/91689] New: internal compiler error: in decode_addr_const, at varasm.c:2864

[david at pgmasters dot net]

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

Bug ID: 91689
   Summary: internal compiler error: in decode_addr_const, at
varasm.c:2864
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at pgmasters dot net
  Target Milestone: ---

Created attachment 46843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46843=edit
Pre-processed source file

We received this error from the Debian pgbackrest packager.  I don't have
access to the system but here's the error and the pre-processed source is
attached.

There may be more information in the build log here:
https://pgdgbuild.dus.dg-i.net/job/pgbackrest-binaries/55/architecture=ppc64el,distribution=stretch/console

-

18:59:33 gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -std=c99 -D_POSIX_C_SOURCE=200112L -D_DARWIN_C_SOURCE
-O2 -Wall -Wextra -Wno-clobbered -Wno-missing-field-initializers -I. -I../libc
-I/usr/include/postgresql -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64  -I/usr/lib/powerpc64le-linux-gnu/perl/5.24/CORE 
-I/usr/include/libxml2 -funroll-loops -ftree-vectorize -c
postgres/pageChecksum.c -o postgres/pageChecksum.o
18:59:33 gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -std=c99 -D_POSIX_C_SOURCE=200112L -D_DARWIN_C_SOURCE
-O2 -Wall -Wextra -Wno-clobbered -Wno-missing-field-initializers -I. -I../libc
-I/usr/include/postgresql -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64  -I/usr/lib/powerpc64le-linux-gnu/perl/5.24/CORE 
-I/usr/include/libxml2 -c protocol/client.c -o protocol/client.o
18:59:33 In file included from ./common/type/variantList.h:13:0,
18:59:33  from ./common/type/keyValue.h:15,
18:59:33  from ./common/type/json.h:7,
18:59:33  from protocol/client.c:11:
18:59:33 protocol/client.c: In function ‘protocolClientReadOutput’:
18:59:33 ./common/type/variant.h:200:50: internal compiler error: in
decode_addr_const, at varasm.c:2864
18:59:33  ((const Variant *)&(const VariantStringConst){.type =
varTypeString, .data = dataParam})
18:59:33   ^
18:59:33 protocol/client.c:160:50: note: in expansion of macro ‘VARSTR’
18:59:33  const Variant *error = kvGet(responseKv,
VARSTR(PROTOCOL_ERROR_STR));
18:59:33   ^~
18:59:33 Please submit a full bug report,
18:59:33 with preprocessed source if appropriate.
18:59:33 See  for instructions.
18:59:33 Preprocessed source stored into /tmp/ccsH1wnT.out file, please attach
this to your bugreport.
18:59:33 === BEGIN GCC DUMP ===
18:59:33 5227: // Target: powerpc64le-linux-gnu
18:59:33 5227: // Configured with: ../src/configure -v
--with-pkgversion='Debian 6.3.0-18+deb9u1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=powerpc64le-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-ppc64el/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-ppc64el
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-ppc64el
--with-arch-directory=ppc64le --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc=auto --enable-secureplt --with-cpu=power8
--enable-targets=powerpcle-linux --disable-multilib --enable-multiarch
--with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu

[Bug middle-end/91680] Integer promotion quirk prevents efficient power of 2 division

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/91681] Missed optimization for 128 bit arithmetic operations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/91687] Fused multiply subtract not generated when same operand appears in multiplication and subtraction and -ffast-math

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||86999

--- Comment #2 from Andrew Pinski  ---
Looks like the same as PR 86999.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86999
[Bug 86999] missed FMA optimization with -fassociative-math

[Bug testsuite/27221] g++.dg/ext/alignof2.C fails on powerpc-darwin (and powerpc-aix)

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  ---
Author: iains
Date: Fri Sep  6 16:03:42 2019
New Revision: 275469

URL: https://gcc.gnu.org/viewcvs?rev=275469=gcc=rev
Log:
[Darwin, testsuite] Fix PR27221.

The test can't succeed on 32b powerpc Darwin since the
ABI demands a different result to the tested one. (So XFAIL it).

2019-09-06  Iain Sandoe  

Backport from mainline.
2019-05-22  Iain Sandoe  

PR testsuite/27221
* g++.dg/ext/alignof2.C: XFAIL for 32bit Darwin.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/alignof2.C

[Bug c/91688] New: -Woverride-init could use an intermediate mode of operation

[eblake at redhat dot com]

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

Bug ID: 91688
   Summary: -Woverride-init could use an intermediate mode of
operation
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eblake at redhat dot com
  Target Milestone: ---

Right now, -Woverride-init is so strong that it interferes with the use of
gcc's extension of ranged-array initializer syntax as a common way to
pre-initialize an array to a specific non-zero default value then override
specific members in the array to a different value.  Thus, it is not part of
-Wall (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010#c4).

However, this warning is so strong that the qemu project is unable to use
-Woverride-init (it would fail to compile due to intentional reinitialization
overrides of ranged defaults), but thus failed to diagnose a bug (a partial
initialization caused zero-initialization of an unmentioned member, overriding
an earlier explicit mention of that member:
https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg01143.html), at least
without using pragmas to temporarily silence the warning.

I am wondering if it would be possible to split this warning into two
categories: -Woverride-init=1 (preferably hoisted into -Wall) which warns about
obvious inadvertent overrides, and -Woverride-init=2 (only part of -Wextra, if
at all) that warns about all overrides, where the difference depends on whether
the second initializer occurs on a subobject that is larger in size than the
first initializer's subobject.

For some demonstrations of what I mean (and intentionally using
-Wno-missing-braces):

$ cat foo.c
#include 

struct A {
  int i;
  int j;
};
struct B {
  struct A one;
  struct A two;
  struct A three;
  int four[2];
};

void dump (struct B *b)
{
  printf ("one=[%d,%d],two=[%d,%d],three=[%d,%d],four=[%d,%d]\n",
  b->one.i, b->one.j, b->two.i, b->two.j, b->three.i, b->three.j,
  b->four[0], b->four[1]);
}

int main(void)
{
  struct B b1 = {
 .one.i = 1,
 .two.j = 2,
 3,
 .four[1] = 9,
 .one = { 5, 6 },
 .two = { 7 },
 .three = { .j = 8 },
 .four[0 ... 1] = 4,
  };
  struct B b2 = {
 .one = { 4, 5 },
 .two = { 6 },
 .three = { .j = 7 },
 .four[0 ... 1] = 4,
 .one.i = 1,
 .two.j = 2,
 3,
 .four[1] = 9,
  };
  dump ();
  dump ();
  return 0;
}
$ gcc -Wall -Wextra -Wno-missing-braces -o foo foo.c
foo.c: In function ‘main’:
foo.c:28:11: warning: initialized field overwritten [-Woverride-init]
   28 |.one = { 5, 6 },
  |   ^
foo.c:28:11: note: (near initialization for ‘b1.one’)
foo.c:29:11: warning: initialized field overwritten [-Woverride-init]
   29 |.two = { 7 },
  |   ^
foo.c:29:11: note: (near initialization for ‘b1.two’)
foo.c:30:13: warning: initialized field overwritten [-Woverride-init]
   30 |.three = { .j = 8 },
  | ^
foo.c:30:13: note: (near initialization for ‘b1.three’)
foo.c:31:21: warning: initialized field overwritten [-Woverride-init]
   31 |.four[0 ... 1] = 4,
  | ^
foo.c:31:21: note: (near initialization for ‘b1.four[1]’)
foo.c:38:13: warning: initialized field overwritten [-Woverride-init]
   38 |.one.i = 1,
  | ^
foo.c:38:13: note: (near initialization for ‘b2.one.i’)
foo.c:41:15: warning: initialized field overwritten [-Woverride-init]
   41 |.four[1] = 9,
  |   ^
foo.c:41:15: note: (near initialization for ‘b2.four[1]’)

The four warnings for b1 all make sense at -Woverride-init=1: they are clearly
inadvertent, in that the second half of initializers all touch a larger subset
of the overall b2 object than the first half (providing both members for .one
overrides the earlier specific setting of .one.i; providing a partial
initializer for .two implies a zero-initialization override of the earlier
.two.j; providing a partial initializer for .three implies a
zero-initialization override of the earlier (non-designated) .three.i, and
doing a ranged initializer over .four[0 ... 1] overrides the earlier specific
initialization of .four[1].)

However, while the first warning of b2 is reasonable (the explicit
initialization of .one.i overrides the earlier explicit initialization of
.one),  this is a case of a more-specific override (.one.i is a smaller subset
of b2 than .one), and the second one is the show-stopper that prevents the use
of -Woverride-init in -Wall (it is intentional that a ranged initializer sets a
non-zero default, and then later initializers of obvious smaller scope change
that default).  So the warnings 

[Bug c++/78744] Build errors on OS X 12.1 with Xcode 8.1 GCC 6.2.0

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Nothing to do here.

[Bug testsuite/67958] The tests changed by r223498 now FAILs on darwin

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
Author: iains
Date: Fri Sep  6 15:59:54 2019
New Revision: 275468

URL: https://gcc.gnu.org/viewcvs?rev=275468=gcc=rev
Log:
[Darwin, testsuite] Fix PR67958.

These tests require specific scan-asms in some cases because
of the different codegen for Dawin.  Added some explanations
too.

2019-09-06  Iain Sandoe  

Backport from mainline.
2019-05-21  Iain Sandoe  

PR testsuite/67958
* gcc.target/i386/pr32219-1.c: Adjust scan-asms for Darwin, comment
the differences.
* gcc.target/i386/pr32219-2.c: Likewise.
* gcc.target/i386/pr32219-3.c: Likewise.
* gcc.target/i386/pr32219-4.c: Likewise.
* gcc.target/i386/pr32219-5.c: Likewise.
* gcc.target/i386/pr32219-6.c: Likewise.
* gcc.target/i386/pr32219-7.c: Likewise.
* gcc.target/i386/pr32219-8.c: Likewise.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr32219-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr32219-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr32219-3.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr32219-4.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr32219-5.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr32219-6.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr32219-7.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr32219-8.c

[Bug c++/71394] bad location for -Wconversion-null

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
Fixed in GCC 9:

71394.C: In constructor ‘ErrorConversionNullBug::ErrorConversionNullBug()’:
71394.C:7:13: warning: converting to non-pointer type ‘unsigned int’ from NULL
[-Wconversion-null]
7 | : n(NULL)
  | ^~~~

[Bug target/63891] [7 regression] Failure of darwin-weakimport-3.c

[iains at gcc dot gnu.org]

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

--- Comment #18 from Iain Sandoe  ---
Author: iains
Date: Fri Sep  6 15:56:18 2019
New Revision: 275467

URL: https://gcc.gnu.org/viewcvs?rev=275467=gcc=rev
Log:
[Darwin, testsuite] Fix PR63891 (darwin-weakimport-3).

This is a testcase failing because one part of the codegen is
(correctly) generating the scan-asm-not signature.

Fixed by altering the build options.

2019-09-06  Iain Sandoe  

Backport from mainline.
2019-05-21  Iain Sandoe  

PR target/63891
* gcc.dg/darwin-weakimport-3.c: Adjust options and explain
the reasons.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/darwin-weakimport-3.c

[Bug middle-end/91687] Fused multiply subtract not generated when same operand appears in multiplication and subtraction.

[barnaby.wilks at arm dot com]

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

--- Comment #1 from barnaby.wilks at arm dot com ---
(In reply to barnaby.wilks from comment #0)
> Some architectures have instructions that allow the expressions of the form
> "(x * y) - z" to be done in one instruction (for example the FNMSUB
> instruction in AArch64).
> 
> For example
> 
> float f (float x, float y, float z) {
>   return (y * x) - z;
> }
> 
> Will generate
> 
> f:
>   fnmsub  s0, s0, s1, s2
>   ret
> 
> This is done with -O2/-O3 with GCC but if -funsafe-math-optimizations are
> enabled
> it will convert expressions of the form
>   (x * y) - x
> to
>   (x - 1) * y
> 
> which then means that the FNMSUB instruction is not generated.
> 
> For example on AArch64 trunk (with -O2 -funsafe-math-optimizations)
> 
> float f (float x, float y) {
> return (y * x) - y;
> }
> 
> will generate
> 
> f:
>   fmovs2, 1.0e+0
>   fsubs0, s0, s2
>   fmuls0, s0, s1
>   ret
> 
> whereas if you just compile with (-funsafe-math-optimizations) then the
> correct
> code will be generated.

Ah, wrote the wrong thing :D
Here it should say

  > whereas if you just compile with -O2 then the
  > correct code will be generated.

The problem only occurs with -funsafe-math-optimizations.

> f:
>   fnmsub  s0, s1, s0, s1
>   ret
> 
> This also happens on x86-64.
> 
> Godbolt demonstrating the problem.
> https://godbolt.org/z/HuU5LO

[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  ---
Author: iains
Date: Fri Sep  6 15:51:01 2019
New Revision: 275466

URL: https://gcc.gnu.org/viewcvs?rev=275466=gcc=rev
Log:
[Darwin, testsuite ] Fix for PR58321.

Darwin doesn't emit a .file directive by default
and one of the scan-asm hits for ELF targets comes from
this directive. Adjust for Darwin and explain.

2019-09-06  Iain Sandoe  

Backport from mainline.
2019-05-20  Iain Sandoe  

PR testsuite/58321
* gcc.target/i386/memcpy-strategy-3.c: Adjust count for Darwin and
add a comment as to the reason for the difference.
* gcc.target/i386/memset-strategy-1.c: Likewise.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/memcpy-strategy-3.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/memset-strategy-1.c

[Bug middle-end/91687] New: Fused multiply subtract not generated when same operand appears in multiplication and subtraction.

[barnaby.wilks at arm dot com]

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

Bug ID: 91687
   Summary: Fused multiply subtract not generated when same
operand appears in multiplication and subtraction.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barnaby.wilks at arm dot com
  Target Milestone: ---

Some architectures have instructions that allow the expressions of the form
"(x * y) - z" to be done in one instruction (for example the FNMSUB instruction
in AArch64).

For example

float f (float x, float y, float z) {
  return (y * x) - z;
}

Will generate

f:
  fnmsub  s0, s0, s1, s2
  ret

This is done with -O2/-O3 with GCC but if -funsafe-math-optimizations are
enabled
it will convert expressions of the form
  (x * y) - x
to
  (x - 1) * y

which then means that the FNMSUB instruction is not generated.

For example on AArch64 trunk (with -O2 -funsafe-math-optimizations)

float f (float x, float y) {
return (y * x) - y;
}

will generate

f:
  fmovs2, 1.0e+0
  fsubs0, s0, s2
  fmuls0, s0, s1
  ret

whereas if you just compile with (-funsafe-math-optimizations) then the correct
code will be generated.

f:
  fnmsub  s0, s1, s0, s1
  ret

This also happens on x86-64.

Godbolt demonstrating the problem.
https://godbolt.org/z/HuU5LO

[Bug c++/11247] -frepo fails to instantiate typeinfo

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||mpolacek at gcc dot gnu.org
  Known to work||
 Resolution|--- |WONTFIX

--- Comment #7 from Marek Polacek  ---
-frepo was removed in GCC 10.

[Bug fortran/91686] New: ICE in gimplify:2554

[urbanjost at comcast dot net]

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

Bug ID: 91686
   Summary: ICE in gimplify:2554
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

program shuf
   implicit none
   character(len=:),allocatable :: pageout(:)
   integer  :: i
  pageout=[character(len=20) :: 'a','bbb','c']
  pageout=pageout([3,2,1])
  write(*,'(a)') (trim(pageout(i)),i=1,size(pageout))
   contains
   end program shuf

bug_shuf.f90:6:0:

pageout=pageout([3,2,1])

internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2584

[Bug testsuite/91670] [10 regression] g++.dg/ubsan/pr59415.C fails starting with rr275388

[ctice at gcc dot gnu.org]

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

--- Comment #2 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Fri Sep  6 14:54:48 2019
New Revision: 275460

URL: https://gcc.gnu.org/viewcvs?rev=275460=gcc=rev
Log:
Fix testcase to not use LTO with -fvtable-verify.

2019-09-05  Caroline Tice  

PR testsuite/91670
* g++.dg/ubsan/pr59415.C: Disable LTO, since test uses
-fvtable-verify, and the two options are no longer allowed
together.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ubsan/pr59415.C

[Bug libstdc++/19544] Difference in behaviour if default constructor added

[nic at buymore dot pro]

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

Nic Brown  changed:

   What|Removed |Added

 CC||nic at buymore dot pro

--- Comment #11 from Nic Brown  ---
 I'm still curious as to why the error doesn't appear if let g++ generate a
| default constructor, as from my reading of 12.1/7, the default generated
| constructor should be "ptr() {}", so the error should still appear. Am I
reading

./include/c++/4.0.0/bits/stl_construct.h:81: https://tinyurl.com/y6xhdy8o
warning: 'SR.186' is used
uninitalized in this function
| it wrong?

[Bug c/86647] Test on constant expression (unsigned) -1 < 0 triggers a spurious -Wtype-limits warning

[yann at droneaud dot fr]

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

--- Comment #5 from Yann Droneaud  ---
I've reproduced the issue with 

bool test(void)
{
return ((unsigned int)0 - 1) < 0;
}

See https://godbolt.org/z/b1QqIC

[Bug c/86647] Test on constant expression (unsigned) -1 < 0 triggers a spurious -Wtype-limits warning

[yann at droneaud dot fr]

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

--- Comment #4 from Yann Droneaud  ---
*** Bug 91685 has been marked as a duplicate of this bug. ***

[Bug c/91685] -Wtype-limits warns for constant expression

[yann at droneaud dot fr]

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

Yann Droneaud  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||yann at droneaud dot fr
 Resolution|--- |DUPLICATE

--- Comment #1 from Yann Droneaud  ---
My issue is the same as bug #86647.

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

[Bug c++/81642] -Wtype-limits should not trigger for defined numbers

[yann at droneaud dot fr]

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

Yann Droneaud  changed:

   What|Removed |Added

 CC||yann at droneaud dot fr

--- Comment #3 from Yann Droneaud  ---
See also bug #86647 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86647

[Bug c/86647] Test on constant expression (unsigned) -1 < 0 triggers a spurious -Wtype-limits warning

[yann at droneaud dot fr]

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

Yann Droneaud  changed:

   What|Removed |Added

 CC||yann at droneaud dot fr

--- Comment #3 from Yann Droneaud  ---
See also bug #81642 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81642

[Bug c/91685] New: -Wtype-limits warns for constant expression

[yann at droneaud dot fr]

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

Bug ID: 91685
   Summary: -Wtype-limits warns for constant expression
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at droneaud dot fr
  Target Milestone: ---

I'm was trying to implement a test for socklen_t type signedness, because on
some platform it's signed and some it's unsigned. For signed socklen_t, I
wanted to rejected negative values.

I found following code triggers a warning:

$ cat test.c

#include 

bool test_unsigned(void)
{
return ((unsigned int)0 - 1) < 0;
}

$ gcc -O2 -Wall -Wextra -c test.c 
warning: comparison of unsigned expression in '< 0' is always false
[-Wtype-limits]

According to the documentation for -Wtype-limits, this warning should not be
produced, because expression is constant:

> Warn if a comparison is always true or always false due to the limited range 
> of the data type, but do not warn for constant expressions. For example, warn 
> if an unsigned variable is compared against zero with < or >=. This warning 
> is also enabled by -Wextra. 

https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html#index-Wtype-limits

I've made some tests on godbolt, see https://godbolt.org/z/b1QqIC and found
clang doesn't trigger the warning.

Perhaps warning here is welcomed and documentation should be updated ?

In the mean time, I still looking for a portable way to test if socklen_t is
negative on platform where it's signed ...

[Bug target/91684] New: [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

[wilco at gcc dot gnu.org]

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

Bug ID: 91684
   Summary: [10 regression][ARM] ICE in gen_movdi, at
config/arm/arm.md:5079
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

The following small example fails with an ICE with -mcpu=cortex-a57:

typedef struct { int a, b, c; } S;

void g (S *s);
void bug1 (void)
{
  S s;
  __builtin_memset (, 0, sizeof (S)); 
  g ();
}

bug1.c:30:3: internal compiler error: in gen_movdi, at config/arm/arm.md:5079
   30 |   __builtin_memset (, 0, sizeof (S));
  |   ^~~~
0xb9b8d9 gen_movdi(rtx_def*, rtx_def*)

This appears due to recent changes in alignment on Arm.

[Bug c++/91125] -frepo can't build tramp3d

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Author: nathan
Date: Fri Sep  6 12:51:44 2019
New Revision: 275456

URL: https://gcc.gnu.org/viewcvs?rev=275456=gcc=rev
Log:
[PATCH] Deprecate -frepo option.

https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00379.html
PR c++/91125
* cp-tree.h (IDENTIFIER_REPO_CHOSEN, DECL_REPO_AVAILABLE_P): Delete.
(struct lang_decl_base): Remove repo_available_p.
* decl.c (duplicate_decls): Don't copy DECL_REPO_AVAILABLE_P.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c

[Bug c/89549] [7/8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers

[david.bolvansky at gmail dot com]

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

--- Comment #11 from Dávid Bolvanský  ---
Would be nice to fix this for the last release of GCC 7.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
So to outline the desired approach again the idea is to make the SCC finding
(the DFS walk) in check_reduction_path the first-class operation of
vect_is_simple_reduction, not passing in the reduction code but instead
computing it (the reduction code eventually used in the lane reduction of
the epilogue).

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mika.fischer at zoopnet dot de

--- Comment #12 from Jonathan Wakely  ---
*** Bug 91675 has been marked as a duplicate of this bug. ***

[Bug c++/91675] [9/10 Regression] Memory corruption with std::function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Yes, looks like it. Thanks.

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

[Bug c++/91675] [9/10 Regression] Memory corruption with std::function

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #2 from ensadc at mailnesia dot com ---
Duplicate of PR 90393?

[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |MOVED

--- Comment #28 from Richard Biener  ---
Fixed in BFD.

[Bug rtl-optimization/91683] New: ICE: SIGSEGV at -O when compiling for riscv64

[zsojka at seznam dot cz]

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

Bug ID: 91683
   Summary: ICE: SIGSEGV at -O when compiling for riscv64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Created attachment 46842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46842=edit
reduced testcase

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O testcase.c -wrapper
valgrind,-q,--track-origins=yes
==21541== Invalid read of size 8
==21541==at 0x13005E7: undo_to_marker(void*) (combine.c:4898)
==21541==by 0x1329BC1: undo_all (combine.c:4919)
==21541==by 0x1329BC1: try_combine(rtx_insn*, rtx_insn*, rtx_insn*,
rtx_insn*, int*, rtx_insn*) (combine.c:3500)
==21541==by 0x1AB: combine_instructions (combine.c:1327)
==21541==by 0x1AB: rest_of_handle_combine (combine.c:15067)
==21541==by 0x1AB: (anonymous
namespace)::pass_combine::execute(function*) (combine.c:15112)
==21541==by 0xC94539: execute_one_pass(opt_pass*) (passes.c:2494)
==21541==by 0xC94CD7: execute_pass_list_1(opt_pass*) (passes.c:2580)
==21541==by 0xC94CE9: execute_pass_list_1(opt_pass*) (passes.c:2581)
==21541==by 0xC94D28: execute_pass_list(function*, opt_pass*)
(passes.c:2591)
==21541==by 0x94DC0C: cgraph_node::expand() (cgraphunit.c:2194)
==21541==by 0x94EC0C: expand_all_functions (cgraphunit.c:2332)
==21541==by 0x94EC0C: symbol_table::compile() [clone .part.66]
(cgraphunit.c:2688)
==21541==by 0x95152C: compile (cgraphunit.c:2595)
==21541==by 0x95152C: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2868)
==21541==by 0xD95348: compile_file() (toplev.c:481)
==21541==by 0x7ADAF7: do_compile (toplev.c:2166)
==21541==by 0x7ADAF7: toplev::main(int, char**) (toplev.c:2301)
==21541==  Address 0x5432458 is in a rw- anonymous segment
==21541== 
==21541== Invalid read of size 1
==21541==at 0x9F9B7B: adjust_reg_mode(rtx_def*, machine_mode)
(emit-rtl.c:1279)
==21541==by 0x13005EE: undo_to_marker(void*) (combine.c:4898)
==21541==by 0x1329BC1: undo_all (combine.c:4919)
==21541==by 0x1329BC1: try_combine(rtx_insn*, rtx_insn*, rtx_insn*,
rtx_insn*, int*, rtx_insn*) (combine.c:3500)
==21541==by 0x1AB: combine_instructions (combine.c:1327)
==21541==by 0x1AB: rest_of_handle_combine (combine.c:15067)
==21541==by 0x1AB: (anonymous
namespace)::pass_combine::execute(function*) (combine.c:15112)
==21541==by 0xC94539: execute_one_pass(opt_pass*) (passes.c:2494)
==21541==by 0xC94CD7: execute_pass_list_1(opt_pass*) (passes.c:2580)
==21541==by 0xC94CE9: execute_pass_list_1(opt_pass*) (passes.c:2581)
==21541==by 0xC94D28: execute_pass_list(function*, opt_pass*)
(passes.c:2591)
==21541==by 0x94DC0C: cgraph_node::expand() (cgraphunit.c:2194)
==21541==by 0x94EC0C: expand_all_functions (cgraphunit.c:2332)
==21541==by 0x94EC0C: symbol_table::compile() [clone .part.66]
(cgraphunit.c:2688)
==21541==by 0x95152C: compile (cgraphunit.c:2595)
==21541==by 0x95152C: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2868)
==21541==by 0xD95348: compile_file() (toplev.c:481)
==21541==  Address 0xa5a5a5a5a5a5a5a7 is not stack'd, malloc'd or (recently)
free'd
==21541== 
during RTL pass: combine
testcase.c: In function 'foo':
testcase.c:25:1: internal compiler error: Segmentation fault
   25 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.


$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-275449-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/10.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-275449-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190906 (experimental) (GCC)

[Bug middle-end/91667] bogus -Wformat-overflow warning

[jbeulich at suse dot com]

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

--- Comment #2 from jbeulich at suse dot com ---
(In reply to Martin Sebor from comment #1)
> The warning is still in GCC 9 but has gone away in GCC 10.0 with r274837.

While I trust you one this, ...

> In bug 91490, comment #4 I said: I'm not sure this should be backported.  It
> suppresses bogus warnings but also introduces new warnings for invalid code."

I'm struggling to see how said change affects the case here: There's no
flexible array involved here, and also from other parts of the change I can't
seem to be able to make a connection.

Please forgive me asking, but I'd appreciate some explanation as to the
connection. I'm in particular wondering whether it wouldn't be possible to
backport a subset of the change, if there's worry about new warnings
(personally I'd consider such fine when they only affect invalid code).

[Bug middle-end/91680] Integer promotion quirk prevents efficient power of 2 division

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||easyhack,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-06
 Ever confirmed|0   |1

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

/* (A / (1 << B)) -> (A >> B).
   Only for unsigned A.  For signed A, this would not preserve rounding
   toward zero.
   For example: (-1 / ( 1 << B)) !=  -1 >> B.  */
(simplify
 (trunc_div @0 (lshift integer_onep@1 @2))
 (if ((TYPE_UNSIGNED (type) || tree_expr_nonnegative_p (@0))
  && (!VECTOR_TYPE_P (type)
  || target_supports_op_p (type, RSHIFT_EXPR, optab_vector)
  || target_supports_op_p (type, RSHIFT_EXPR, optab_scalar)))
  (rshift @0 @2)))

lacks a (convert? ...) on the divisor where at least sign-changes are OK.

[Bug target/91681] Missed optimization for 128 bit arithmetic operations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-06
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So while we recognize a widening multiply:

  B0_10 = c_9(D) w* b_7(D);

we don't recognize a highpart one:

  _3 = B0_10 >> 64;

maybe because we're not truncating to 64bits.  Not sure if it would help
the testcase though.

[Bug tree-optimization/91665] [8/9/10 Regression] ICE in build_vector_from_val, at tree.c:1904

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
I'll have a look for a "proper" solution not FAILing
gcc.dg/vect/vect-iv-8{,a}{,-big-array}.c next week.

[Bug c++/88128] G++ should implement CWG 330

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Viktor Ostashevskyi from comment #3)
> > Is it possible to make std::span from std::vector?
> 
> Yes, that works with current trunk.

Although that could be a bug: the constraints use declval<_Container&>() but
should be using declval().

[Bug c++/88128] G++ should implement CWG 330

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Viktor Ostashevskyi from comment #3)
> Was this bug fixed for implenting it?

No.

> Is it possible to make std::span from std::vector?

Yes, that works with current trunk.

[Bug ipa/91682] New: IPA-cp can not propagate value for by-ref argument in form of *arg = param op constant

[fxue at os dot amperecomputing.com]

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

Bug ID: 91682
   Summary: IPA-cp can not propagate value for by-ref argument in
form of *arg = param op constant
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Current IPA only supports CP on by-ref argument assigned with constant. But if
value of the argument is computed via an unary/binary operation on caller's
parameter, it fails to do that. For example.

   struct S
 {
   int a, b;
 };

   void callee2 (struct S *s)
 {
// use s->a;
// use s->b; 
 }

   void callee1 (int a, int *p)
 {
   struct S s;

   s.a = a;
   s.b = *p + 1;
   callee2 ();
 }

   void caller ()
 {
int a = 1;
int b = 2;

callee1 (a, );
 } 

In callee1(), we could know that value of s.a equals 1 and s.b is 3, it is
possible to propagate these value to callee2().

[Bug target/91681] New: Missed optimization for 128 bit arithmetic operations

[antoshkka at gmail dot com]

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

Bug ID: 91681
   Summary: Missed optimization for 128 bit arithmetic operations
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the function:

void multiply128x64x2_3 ( 
const unsigned long a, 
const unsigned long b, 
const unsigned long c, 
const unsigned long d, 
__uint128_t o[2]
  ) noexcept
{
__uint128_t B0 = __uint128_t{ b } * c;
__uint128_t B2 = __uint128_t{ a } * c;
__uint128_t B1 = __uint128_t{ b } * d;
__uint128_t B3 = __uint128_t{ a } * d;

o[0] = B2 + (B0 >> 64);
o[1] = B3 + (B1 >> 64);
}


With compilation flags "-O2 -std=c++17 -mavx" the following assembly is
produced:

multiply128x64x2_3(unsigned long, unsigned long, unsigned long, unsigned long,
unsigned __int128*):
  mov rax, rdx
  push rbx
  mov rbx, rdx
  mov r9, rdi
  mul rsi
  mov rax, rdx
  xor edx, edx
  mov r10, rax
  mov rax, rbx
  mov r11, rdx
  pop rbx
  mul rdi
  add rax, r10
  adc rdx, r11
  mov QWORD PTR [r8], rax
  mov rax, rsi
  xor edi, edi
  mov QWORD PTR [r8+8], rdx
  mul rcx
  mov rax, rcx
  mov rsi, rdx
  mul r9
  add rsi, rax
  adc rdi, rdx
  mov QWORD PTR [r8+16], rsi
  mov QWORD PTR [r8+24], rdi
  ret

However, it is sub-optimal. Touching the stack is not necessary and the same
result could be achieved with less instructions:

multiply128x64x2_3(unsigned long, unsigned long, unsigned long, unsigned long,
unsigned __int128*):
  mov r9, r8
  mov r8, rdx
  mov rax, rsi
  mul r8
  mov rax, r8
  mov r10, rdx
  mul rdi
  add r10, rax
  mov rax, rsi
  mov QWORD PTR [r9], r10
  adc rdx, 0
  mov QWORD PTR [8+r9], rdx
  mul rcx
  mov rax, rdi
  mov r11, rdx
  mul rcx
  add r11, rax
  mov QWORD PTR [16+r9], r11
  adc rdx, 0
  mov QWORD PTR [24+r9], rdx
  ret

[Bug middle-end/91680] New: Integer promotion quirk prevents efficient power of 2 division

[kim.nilsson at effnet dot com]

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

Bug ID: 91680
   Summary: Integer promotion quirk prevents efficient power of 2
division
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kim.nilsson at effnet dot com
  Target Milestone: ---

Created attachment 46841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46841=edit
Preprocessed source

For the function,

uint_fast32_t foo_a(uint_fast8_t x) {
const uint_fast32_t q = 1 << x;
return 256 / q;
}

GCC-{8.*,9.*} generates inefficient division instructions for both x86_64 and
ARM. Since 'q' is a power of 2, the result should be a single right shift.
Indeed, if the function is changed to,

uint_fast32_t foo_b(uint_fast8_t x) {
return 256 / (1 << x); // This is, of course, equivalent to (256 >> x)
},

the expected instructions are generated. Counter-intuitively, if the original
function is instead changed slightly to,

uint_fast32_t foo_c(uint_fast8_t x) {
const uint_fast32_t q = (uint_fast32_t)1 << x;
return 256 / q;
},

the expected instructions are once again generated.

See https://godbolt.org/z/37K0Ig for examples.

[Bug c++/88128] G++ should implement CWG 330

[ostash at ostash dot kiev.ua]

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

--- Comment #3 from Viktor Ostashevskyi  ---
I see that std::span implementation was proposed in
https://gcc.gnu.org/ml/libstdc++/2019-08/msg00068.html.

Was this bug fixed for implenting it?

Is it possible to make std::span from std::vector?

[Bug debug/91507] wrong debug for completed array with previous incomplete declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=24971

--- Comment #4 from Richard Biener  ---
I've opened a gdb bug, maybe I can get clarification that way.

[Bug testsuite/91670] [10 regression] g++.dg/ubsan/pr59415.C fails starting with rr275388

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c/91672] wrong amount of storage allocated for initialized structs with flexible array members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-06
 Ever confirmed|0   |1

[Bug testsuite/91676] new test case gcc.dg/torture/pr91656-1.c in r275406 fails on powerpc64 BE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-06
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Yeah:

  __builtin_memmove (, , 1);

can you try fixing?

[Bug c++/91675] [9/10 Regression] Memory corruption with std::function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug lto/91677] -fbuiltin (default) breaks static link against lto libc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-06
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
That was PR91287.  builtin_with_linkage_p needs to be amended with all those
libc builtins we have for this to work.

[Bug middle-end/91603] Unaligned access in expand_assignment

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
Okay, Thanks!

Looks like these neon instructions don't work at all in big-endian.

[Bug c++/91125] -frepo can't build tramp3d

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
-frepo was removed on trunk, thus closing.

[Bug middle-end/91603] Unaligned access in expand_assignment

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon  ---
Hi,

The new test fails on armeb as of r275342:
FAIL: gcc.target/arm/pr91603.c scan-assembler-times vld1.32 1
FAIL: gcc.target/arm/pr91603.c scan-assembler-times vldr 1
FAIL: gcc.target/arm/pr91603.c scan-assembler-times vst1.32 1
FAIL: gcc.target/arm/pr91603.c scan-assembler-times vstr 1

[Bug c++/91125] -frepo can't build tramp3d

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Fri Sep  6 06:58:42 2019
New Revision: 275450

URL: https://gcc.gnu.org/viewcvs?rev=275450=gcc=rev
Log:
Remove support for repo files (PR c++/91125).

2019-09-06  Martin Liska  

PR c++/91125
* Makefile.in: Remove tlink.o.
* collect2.c (do_link): New function isolated
from do_tlink.
(main): Use.
* collect2.h (do_tlink): Remove declaration of do_tlink.
* doc/extend.texi: Remove documentation of -frepo.
* doc/invoke.texi: Likewise.
* doc/sourcebuild.texi: Remove cleanup-repo-files.
* tlink.c: Remove.
2019-09-06  Martin Liska  

PR c++/91125
* c-common.c: Remove definition of flag_use_repository.
* c-common.h: Likewise.
* c-opts.c (c_common_handle_option):
Do not handle OPT_frepo option.
* c.opt: Mark the option with Deprecated.
2019-09-06  Martin Liska  

PR c++/91125
* Make-lang.in: Remove repo.o.
* config-lang.in: Likewise.
* cp-tree.h (init_repo): Remove declarations
of repo-related functions.
(repo_emit_p): Likewise.
(repo_export_class_p): Likewise.
(finish_repo): Likewise.
* decl2.c (import_export_class): Always
set -1 value/
(mark_needed): Remove -frepo from comment.
(import_export_decl): Similarly here.
(c_parse_final_cleanups): Remove call of finish_repo.
* lex.c (cxx_init): Remove call to init_repo.
* optimize.c (can_alias_cdtor): Remove dead condition.
* pt.c (push_template_decl_real): Update comment.
(instantiate_decl): Remove dead code used for -frepo.
* repo.c: Remove.
2019-09-06  Martin Liska  

PR c++/91125
* g++.dg/parse/repo1.C: Remove.
* g++.dg/rtti/repo1.C: Remove.
* g++.dg/template/repo1.C: Remove.
* g++.dg/template/repo10.C: Remove.
* g++.dg/template/repo11.C: Remove.
* g++.dg/template/repo2.C: Remove.
* g++.dg/template/repo3.C: Remove.
* g++.dg/template/repo4.C: Remove.
* g++.dg/template/repo5.C: Remove.
* g++.dg/template/repo6.C: Remove.
* g++.dg/template/repo7.C: Remove.
* g++.dg/template/repo8.C: Remove.
* g++.dg/template/repo9.C: Remove.
* g++.old-deja/g++.pt/instantiate4.C: Remove.
* g++.old-deja/g++.pt/instantiate6.C: Remove.
* g++.old-deja/g++.pt/repo1.C: Remove.
* g++.old-deja/g++.pt/repo2.C: Remove.
* g++.old-deja/g++.pt/repo3.C: Remove.
* g++.old-deja/g++.pt/repo4.C: Remove.
* lib/g++.exp: Remove removal of repo files.
* lib/gcc-dg.exp: Likewise.
* lib/obj-c++.exp: Likewise.

Removed:
trunk/gcc/cp/repo.c
trunk/gcc/testsuite/g++.dg/parse/repo1.C
trunk/gcc/testsuite/g++.dg/rtti/repo1.C
trunk/gcc/testsuite/g++.dg/template/repo1.C
trunk/gcc/testsuite/g++.dg/template/repo10.C
trunk/gcc/testsuite/g++.dg/template/repo11.C
trunk/gcc/testsuite/g++.dg/template/repo2.C
trunk/gcc/testsuite/g++.dg/template/repo3.C
trunk/gcc/testsuite/g++.dg/template/repo4.C
trunk/gcc/testsuite/g++.dg/template/repo5.C
trunk/gcc/testsuite/g++.dg/template/repo6.C
trunk/gcc/testsuite/g++.dg/template/repo7.C
trunk/gcc/testsuite/g++.dg/template/repo8.C
trunk/gcc/testsuite/g++.dg/template/repo9.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/instantiate4.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/instantiate6.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/repo1.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/repo2.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/repo3.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/repo4.C
trunk/gcc/tlink.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/collect2.c
trunk/gcc/collect2.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/Make-lang.in
trunk/gcc/cp/config-lang.in
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/cp/lex.c
trunk/gcc/cp/optimize.c
trunk/gcc/cp/pt.c
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/g++.exp
trunk/gcc/testsuite/lib/gcc-dg.exp
trunk/gcc/testsuite/lib/obj-c++.exp

[Bug c++/30277] bit-field: wrong overload resolution

[contacts at buymore dot pro]

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

nicbrown  changed:

   What|Removed |Added

 CC||contacts at buymore dot pro

--- Comment #5 from nicbrown  ---
In C++03, integral promotions for bit-fields are specified in 4.5
https://tinyurl.com/y39m4st6

[Bug target/21809] Floating Optimization Bug

[contacts at buymore dot pro]

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

nicbrown  changed:

   What|Removed |Added

 CC||contacts at buymore dot pro

--- Comment #23 from nicbrown  ---
This is a target problem, as the RTL is correct.
Looks like there is a forgotten rounding back https://tinyurl.com/y46wuubk to
float.
Read the code carefully:

test-case.c: 
#include 
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}

Fixed???