[Bug tree-optimization/88459] New: vectorization failure for a simple sum reduction loop

[jiangning.liu at amperecomputing dot com]

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

Bug ID: 88459
   Summary: vectorization failure for a simple sum reduction loop
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangning.liu at amperecomputing dot com
  Target Milestone: ---

For the simple loop below, gcc -O3 fails to vectorize it.

unsigned int tmp[1024];
unsigned int test_vec(int n)
{
int sum = 0;
for(int i = 0; i < 1024; i++)
{
sum += tmp[i];
}
return sum;
}

The kernel loop is,

.L2:
ldr w2, [x1], 4
add w0, w0, w2
cmp x3, x1
bne .L2


But if we change the data type of sum from "int" to "unsigned int" as below,

unsigned int tmp[1024];
unsigned int test_vec(int n)
{
unsigned int sum = 0;
for(int i = 0; i < 1024; i++)
{
sum += tmp[i];
}
return sum;
}

gcc can vectorize it, and the kernel loop is like,

.L2:
ldr q1, [x0], 16
add v0.4s, v0.4s, v1.4s
cmp x1, x0
bne .L2

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

--- Comment #7 from Andrey Belevantsev  ---
Looks like mine.

[Bug bootstrap/88450] ICE in stage 2 compiler while configuring libgcc

[sbence92 at gmail dot com]

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

--- Comment #1 from Bence Szabó  ---
Correction: 9-21081118 works after patching with "PR bootstrap/88106" (r266309)

[Bug c++/88458] New: Conditional expression where the second and third operand are int and nullptr treated as ill-formed

[yaghmour.shafik at gmail dot com]

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

Bug ID: 88458
   Summary: Conditional expression where the second and third
operand are int and nullptr treated as ill-formed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yaghmour.shafik at gmail dot com
  Target Milestone: ---

Given the following code

char* ch4 = true ? 0 : nullptr;

and compiling with the following flags:

-std=c++17

gcc produces the following diagnostic:

 error: operands to ?: have different types 'int' and 'std::nullptr_t'
4 |   char* ch4 = true ? 0 : nullptr;
  |   ~^

Both clang and MSVC accepts this code w/o diagnostic, see godbolt:
https://godbolt.org/z/BraaEu

I believe according to http://eel.is/c++draft/expr.cond#7.5 this is
well-formed.

[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)

[claziss at gmail dot com]

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

--- Comment #6 from Claudiu Zissulescu  ---
The dejagnu tests for ARC look alright. No extra failures.

[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)

[vgupta at synopsys dot com]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||vgupta at synopsys dot com

--- Comment #5 from Vineet Gupta  ---
Hi, I'm the ARC glibc maintainer (and desperate for this fix).

The proposed (one liner) patch seems to fix the compiler assert for sue. I'm
still running more tests to make sure it is functional but looks promising.

[Bug rtl-optimization/79593] [7/8/9 Regression] Poor/Worse code generation for FPU on versions after 6

[law at redhat dot com]

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

--- Comment #21 from Jeffrey A. Law  ---


We have this after IRA:

(insn 27 26 28 4 (set (reg:DI 101 [ pretmp_22 ])
(zero_extend:DI (subreg:SI (reg:SF 91 [ pretmp_22 ]) 0))) "j.C":20:35
114 {*zero_extendsidi2}
 (expr_list:REG_DEAD (reg:SF 91 [ pretmp_22 ])
(nil)))
(insn 28 27 29 4 (set (reg:XF 100)
(float:XF (reg:DI 101 [ pretmp_22 ]))) "j.C":20:35 169 {floatdixf2}
 (expr_list:REG_DEAD (reg:DI 101 [ pretmp_22 ])
(nil)))

Where 91 and 101 will get assigned to memory locations because of the 'm'
constraint for floatdixf2.  r100 gets a hard register.  We're going to need a
reload for insn 27.  So after LRA we have:

(insn 100 26 27 4 (set (reg:SI 0 ax [110])
(mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])) "j.C":20:35 67
{*movsi_internal}
 (nil))
(insn 27 100 28 4 (set (mem/c:DI (reg/f:SI 7 sp) [6 %sfp+-8 S8 A64])
(zero_extend:DI (reg:SI 0 ax [110]))) "j.C":20:35 114
{*zero_extendsidi2}
 (nil))

[  insn 28 doesn't really play a role here other than requiring the 'm'
operand]

The x86 backend has a splitter to optimize insn 27.  So post LRA splitting
generates:

(insn 100 26 107 4 (set (reg:SI 0 ax [110])
(mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])) "j.C":20:35 67
{*movsi_internal}
 (nil))
(insn 107 100 108 4 (set (mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])
(reg:SI 0 ax [110])) "j.C":20:35 67 {*movsi_internal}
 (nil))
(insn 108 107 28 4 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [6 %sfp+-4 S4 A32])
(const_int 0 [0])) "j.C":20:35 67 {*movsi_internal}
 (nil))


Now we've finally exposed the redundancy.This can be addressed in DSE2
which runs after SPLIT2.  But it's not all that generally effective.  Figure
we're getting ~8 hits per stage during a bootstrap -- all in the runtime
system.


I looked at perhaps trying to detect the partial dead store in postreload-gcse.
 THere's a lot of good memory tracking bits in here, but it's still not a good
fit.  

It doesn't really feel like an IRA/LRA problem to me.  Their decisions are sane
AFAICT.

We could try and catch it with a new peephole pattern, but that seems even less
desirable than detecting this in a generic way during DSE.

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #18 from Eric Gallager  ---
(In reply to Vitali from comment #17)
> I was explicitly asked to open this as a separate bug in comment #7 of
> 87950. Would be helpful if the GCC devs could coordinate to figure out if
> they want separate bugs for C/C++ or 1 bug.
> 
> Jonathan, on this forum your feedback comes off a bit like Skinner where he
> blames the children. There's clearly a gap between how compiler authors
> define switches as working & how developers wish to use those enums/wish
> those enums were actually defined. I appreciate there's a large amount of
> legacy code that complicates this issue but I don't think that condescending
> to people trying to communicate the issue in good faith moves the
> conversation along.
> 
> I'd argue that clang strikes a much better balance here in terms of the
> practical implications of the warning even if it's not perfect. In my mind,
> warnings are most useful when they optimize for a low rate of false
> positives. The GCC warnings for enums do not in practice have a low rate of
> false positives and are clearly tuned to minimize false negatives (i.e.
> accidentally missing a switch statement that doesn't have all enums
> covered). 
> 
> At the very least it would be useful to give users the power to turn on a
> warning equivalent to Clang's that minimizes false negatives (or change
> -Wswitch to be equivalent to Clang & add a -Wpedantic-switch that's part of
> -pedantic for the current behaviour).
> 
> You could even provide annotations that let users annotate enums/switches in
> an explicit fashion to indicate that they can be constructed with non-label
> values/aren't expected to be depending on which flag you choose to use to
> silence warnings/let the compiler optimize more fully.
> 
> In practice, definitely in C++, enums ARE intended to be a closed set of all
> possible paths & the flags/random integer value cases are far less
> frequently used; even for bitmasks it's a lazy way to do it. In C++ I
> usually define strongly-typed types that represent the bitmask & overload
> the bit math operators for the enum to yield that secondary type. I think
> considering that's a technique used by Boost & Qt, it's reasonable to assume
> that having the enum double as the storage type for the bitmask is more of a
> hack technically allowed than one that is considered best practice by large
> C++ projects. In C it's more muddled because there's no operator
> overloading, but the number of enums that exist far outnumber the uses where
> it's used for bitwise math.

This reminded me of bug 81665

[Bug target/51509] Inefficient neon intrinsic code sequence

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=65375

--- Comment #7 from Eric Gallager  ---
(In reply to Maxim Kuvyrkov from comment #5)
> Oh, sorry, I missed the fact that PR65375 is for aarch64 and this one is for
> armv7.  Charles, would you please look at this?

Should Charles still remain the assignee for this?

[Bug tree-optimization/81811] missing -Wreturn-local-addr returning strcpy result

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> (In reply to Richard Biener from comment #2)
> > Wonder whether the memcpy case is because we fold the memcpy away as both
> > memcpy and strcpy are marked RET1 (returns arg1).
> 
> The memcpy is eliminated in DSE and turned into a plain 'return a' statement
> that  the find_explicit_erroneous_behavior() in tree-ssa-isolate-paths.c
> that implements the warning knows how to handle.
> 
> DSE doesn't handle strcpy or strncpy so the calls are not eliminated and
> because find_explicit_erroneous_behavior() doesn't handle calls, the 'return
> strcpy(a, s)' statement isn't detected.
> 
> This suggests an opportunity to improve not just the warning but also DSE.

so, sounds like a missed-optimization too, then

[Bug testsuite/37703] Ada testsuites lack multilib support

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
Related: bug 37704

[Bug c/26732] different argument type not rejected for K style function definitions

[egallager at gcc dot gnu.org]

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

--- Comment #7 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #6)
> Now we don't even error out at -O3.

Why would the -O3 matter?

[Bug target/88457] New: ICE: Max. number of generated reload insns per insn is achieved (90)

[asolokha at gmx dot com]

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

Bug ID: 88457
   Summary: ICE: Max. number of generated reload insns per insn is
achieved (90)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc-9.0.0-alpha20181209 snapshot (r266934) ICEs when compiling
gcc/testsuite/gcc.target/powerpc/clone1.c w/ -mcpu=power7 -O1
-fexpensive-optimizations --param ira-max-conflict-table-size=0 --param
max-cse-insns=3:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181209 -mcpu=power7 -O1
-fexpensive-optimizations --param ira-max-conflict-table-size=0 --param
max-cse-insns=3 -c gcc/testsuite/gcc.target/powerpc/clone1.c
during RTL pass: reload
gcc/testsuite/gcc.target/powerpc/clone1.c: In function 'mod_func_or':
gcc/testsuite/gcc.target/powerpc/clone1.c:23:1: internal compiler error: Max.
number of generated reload insns per insn is achieved (90)

   23 | }
  | ^
0xba14ee lra_constraints(bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/lra-constraints.c:4850
0xb882f8 lra(_IO_FILE*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/lra.c:2446
0xb3e2f4 do_reload
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/ira.c:5475
0xb3e2f4 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/ira.c:5659

[Bug fortran/88116] [8/9 Regression] ICE in gfc_convert_constant(): Unexpected type

[kargl at gcc dot gnu.org]

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

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 G. Steinmetz from comment #0)

> Silently accepted invalid code, produces a wrong result :
> 
> 
> $ cat z2.f90
> program p
>print *, [integer :: 1, [integer(8) :: 2, '3']]
> end
> 
> 
> $ gfortran-9-20181118 z2.f90 -static-libgfortran
> $ a.out
>1   2   0

Gerhard, I don't know if you like to keep track of issues
that you submit or not.  The above is quite strange if 
integer(8) is replaced with integer or integer(4),  I get
the expected error message.  If it is integer(1), integer(2),
or integer(8), it silently compiles.  If I do, 

print *, [integer(8) :: 2, '3']

I et the expected error.  Do you want to migrate this to its
own PR?  If not, I'll do it when I get around to committing the
fix for the other issues.

[Bug bootstrap/59447] --with-dwarf2 should be documented as meaning "DWARF 2 or later" instead of just "DWARF 2"

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Actually, this issue is already on my radar, but there are definitely more
documentation bugs out there than I have time to fix this release cycle.

Of course there's nothing stopping other people from fixing some of these
things too.  :-)

[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.5

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk, branch-8, and branch-7.

[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Dec 12 01:26:12 2018
New Revision: 267043

URL: https://gcc.gnu.org/viewcvs?rev=267043=gcc=rev
Log:
2018-12-11  Steven G. Kargl  

PR fortran/88155
* primary.c (gfc_match_structure_constructor):  Set the locus of
an expression to avoid a NULL pointer dereference.

2018-12-11  Steven G. Kargl  

PR fortran/88155
* gfortran.dg/pr70870_1.f90: Update testcase to use -std=gnu.
* gfortran.dg/pr88155.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88155.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/primary.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr70870_1.f90

[Bug other/88456] New: __atomic_compare_exchange implementation inconsistently used

[patrick at motec dot com.au]

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

Bug ID: 88456
   Summary: __atomic_compare_exchange implementation
inconsistently used
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at motec dot com.au
  Target Milestone: ---

While implementing atomic support for an embedded target I came across some
unexpected behaviour in gcc.

In the following example:

#include 
#include 
#include 

bool
__atomic_compare_exchange_1(uint8_t *p, uint8_t *e, uint8_t d, bool w, int sm,
int fm)
{
asm volatile("nop");
return false;
}

int main()
{
uint8_t x, e, d;
atomic_compare_exchange_strong_explicit(, , d, 0, 0);

return 0;
}

The provided __atomic_compare_exchange_1 implementation is only used at -O2 or
greater:

% gcc -c -O0 test.c; objdump -d test.o |grep cmpxchg  
  60:   f0 40 0f b0 31  lock cmpxchg %sil,(%rcx)
% gcc -c -O1 test.c; objdump -d test.o |grep cmpxchg
  20:   f0 0f b0 4c 24 07   lock cmpxchg %cl,0x7(%rsp)
% gcc -c -O2 test.c; objdump -d test.o |grep cmpxchg
% gcc -c -O3 test.c; objdump -d test.o |grep cmpxchg

This was observed with gcc 8.2.1:

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

[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Dec 12 01:14:58 2018
New Revision: 267042

URL: https://gcc.gnu.org/viewcvs?rev=267042=gcc=rev
Log:
2018-12-11  Steven G. Kargl  

PR fortran/88155
* primary.c (gfc_match_structure_constructor):  Set the locus of
an expression to avoid a NULL pointer dereference.

2018-12-11  Steven G. Kargl  

PR fortran/88155
* gfortran.dg/pr70870_1.f90: Update testcase to use -std=gnu.
* gfortran.dg/pr88155.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88155.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/primary.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr70870_1.f90

[Bug tree-optimization/88440] size optimization of memcpy-like code

[hoganmeier at gmail dot com]

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

--- Comment #3 from krux  ---
Adding -ftree-loop-distribute-patterns to -Os does not seem to make a
difference though.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

[skunk at iskunk dot org]

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

--- Comment #8 from Daniel Richard G.  ---
Hello Rainer,

(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> That bootstrap (amd64-pc-solaris2.10 with as/ld, --disable-shared
> --with-pic) has now completed as well: in addition to libcc1 (PR
> other/66955) and ada (cf. PR ada/88429), I also had to disable go
> because it uses sendfile without explicitly linking with -lsendfile (in
> the shared case, this works because libgo is linked with libsendfile).
> 
> Anyway, the bootstrap has now finished successfully and make check is
> running: no comparison failures at all.  So unless there's additional
> information how to reproduce this, I'll close the PR as WORKSFORME.

I tested this again with GCC 8.2.0 on the same system, using as/ld, and am
still seeing the object diffs. Would it help if I provided a copy of the
objects at issue?

[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Dec 12 00:53:08 2018
New Revision: 267041

URL: https://gcc.gnu.org/viewcvs?rev=267041=gcc=rev
Log:
2018-12-11  Steven G. Kargl  

PR fortran/88155
* primary.c (gfc_match_structure_constructor):  Set the locus of
an expression to avoid a NULL pointer dereference.

2018-12-11  Steven G. Kargl  

PR fortran/88155
* gfortran.dg/pr70870_1.f90: Update testcase to use -std=gnu.
* gfortran.dg/pr88155.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr88155.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr70870_1.f90

[Bug fortran/77385] "Unclassifiable statement" from gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Dominique d'Humieres  ---
AFAICT everything has been fixed, closing.

[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.5

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk, branch-8, and branch-7.  Closing.

[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Dec 12 00:08:12 2018
New Revision: 267037

URL: https://gcc.gnu.org/viewcvs?rev=267037=gcc=rev
Log:
2018-12-11  Steven G. Kargl  

PR fortran/88249
* gfortran.h: Update prototype for gfc_resolve_filepos().
* io.c (gfc_resolve_filepos): Check for UNIT number if ERR= is present.
Use passed in locus for error message.
* resolve.c (gfc_resolve_code): Pass locus in gfc_resolve_filepos()
call.

2018-12-11  Steven G. Kargl  

PR fortran/88249
* gfortran.dg/pr88249.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88249.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/gfortran.h
branches/gcc-7-branch/gcc/fortran/io.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Dec 11 23:39:43 2018
New Revision: 267036

URL: https://gcc.gnu.org/viewcvs?rev=267036=gcc=rev
Log:
2018-12-11  Steven G. Kargl  

PR fortran/88249
* gfortran.h: Update prototype for gfc_resolve_filepos().
* io.c (gfc_resolve_filepos): Check for UNIT number if ERR= is present.
Use passed in locus for error message.
* resolve.c (gfc_resolve_code): Pass locus in gfc_resolve_filepos()
call.

2018-12-11  Steven G. Kargl  

PR fortran/88249
* gfortran.dg/pr88249.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88249.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/gfortran.h
branches/gcc-8-branch/gcc/fortran/io.c
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Dec 11 23:13:19 2018
New Revision: 267035

URL: https://gcc.gnu.org/viewcvs?rev=267035=gcc=rev
Log:
2018-12-11  Steven G. Kargl  

PR fortran/88249
* gfortran.h: Update prototype for gfc_resolve_filepos().
* io.c (gfc_resolve_filepos): Check for UNIT number if ERR= is present.
Use passed in locus for error message.
* resolve.c (gfc_resolve_code): Pass locus in gfc_resolve_filepos()
call.

2018-12-11  Steven G. Kargl  

PR fortran/88249
* gfortran.dg/pr88249.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr88249.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/88429] [9 regression] libada build fails with --disable-shared

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0
Summary|Ada bootstrap fails with|[9 regression] libada build
   |--disable-shared|fails with --disable-shared

--- Comment #4 from Eric Botcazou  ---
This should work again.

[Bug ada/88429] Ada bootstrap fails with --disable-shared

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Dec 11 23:04:39 2018
New Revision: 267034

URL: https://gcc.gnu.org/viewcvs?rev=267034=gcc=rev
Log:
libada/
PR ada/88429
* configure.ac (default_gnatlib_target): Set to gnatlib instead of
gnatlib-plain if --disable-shared.
* configure: Regenerate.
* Makefile.in (all): Replace gnatlib prerequisite with libada.
(ADA_RTS_SUBDIR): Delete.
(libada): New target, renamed from...
(gnatlib): ...this.  Merge with other library targets.
(gnatlib-plain): Delete.
(install-gnatlib): Rename to...
(install-libada): ...this.
(install): Replace install-gnatlib prerequisite with install-libada.
gcc/ada/
PR ada/88429
* gcc-interface/Makefile.in (./stamp-gnatlib1-$(RTSDIR)): Also pass
MULTISUBDIR to sub-make and add quotes around $(THREAD_KIND).
(gnatlib-shared-dual): Also pass PICFLAG_FOR_TARGET to sub-make.
(gnatlib-sjlj): Also pass MULTISUBDIR to sub-make, but do not pass
PICFLAG_FOR_TARGET.
(gnatlib-zcx): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in
trunk/libada/ChangeLog
trunk/libada/Makefile.in
trunk/libada/configure
trunk/libada/configure.ac

[Bug middle-end/53714] false positive for -Wuninitialized

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dominique d'Humieres  ---
Fixed between revisions r232451 (2016-01-15, warning) and r233563 (2016-02-19,
OK).

[Bug fortran/88455] False positive for allocatable character array of deferred length, ALLOCATE using SOURCE/MOLD [-Wuninitialized]

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
Version|unknown |9.0
 Blocks||24639
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from 5.5.0 up to trunk (9.0). Compiling the code with 4.8 or 4.9
gives an ICE.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org,
   ||amonakov at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Aha, I had to use -fpic additionally in my cross.
Seems like sel-sched bug to me.
In *.split4 we still have correct:
(insn/f 71 9 72 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0  A8]))
]) "pr69102.c":8:1 954 {pro_epilogue_adjust_stack_si_add}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(nil
in prologue at the start of function, then body including a tablejump and
finally
(insn 48 47 49 5 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) "pr69102.c":22:3 190 {*addsi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil
(insn 49 48 50 5 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [1  S4 A32])
(reg/v:SI 0 ax [orig:84 ch ] [84])) "pr69102.c":22:3 43 {*pushsi2}
 (expr_list:REG_DEAD (reg/v:SI 0 ax [orig:84 ch ] [84])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
(call_insn 50 49 73 5 (call (mem:QI (symbol_ref:SI ("bar") [flags 0x41] 
) [0 bar S1 A8])
(const_int 16 [0x10])) "pr69102.c":22:3 663 {*call}
 (nil)
(nil))
(note 73 50 74 5 NOTE_INSN_EPILOGUE_BEG)
(insn/f 74 73 75 5 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0  A8]))
]) "pr69102.c":23:1 954 {pro_epilogue_adjust_stack_si_add}
 (expr_list:REG_ARGS_SIZE (const_int 0 [0])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])))
(nil)
(jump_insn 75 74 78 5 (simple_return) "pr69102.c":23:1 686
{simple_return_internal}
 (nil)
as the only stack-changing instructions.  But sel-sched for some reason copies
the sp adjustment (insn 48) above to a different basic block before the
tablejump and due to that copy there is a basic block reachable from code with
different stack depths (i.e. different CFA offset), the initial one from right
after the prologue and the adjusted one due to this sel-sched bug.

[Bug fortran/88455] False positive for allocatable character array of deferred length, ALLOCATE using SOURCE/MOLD [-Wuninitialized]

[adam at aphirst dot karoo.co.uk]

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

--- Comment #2 from Adam Hirst  ---
Slightly reduced - the issue occurs even in the MAIN program:

program test
  implicit none
integer   :: a, b, c
character(:), allocatable :: line(:)
a = 1; b = 10; c = 30
allocate( line(a:b), source = repeat(" ",c) )
end program test


...and also if the integers are declared PARAMETER:

program test
  implicit none
integer, parameter:: a=1, b=10, c=30
character(:), allocatable :: line(:)
allocate( line(a:b), source = repeat(" ",c) )
end program test

...and even if they're hard-coded into the ALLOCATE call:

program test
  implicit none
character(:), allocatable :: line(:)
allocate( line(1:10), source = repeat(" ",30) )
end program test

Yet, as far as I understand the Fortran standard, the string `line` here should
  be considered fully allocated by the ALLOCATE statement, therefore I think
the warning is spurious.

[Bug c++/88375] Vague source location for bad initialization

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00746.html

[Bug fortran/88455] False positive for allocatable character array of deferred length, ALLOCATE using SOURCE/MOLD [-Wuninitialized]

[adam at aphirst dot karoo.co.uk]

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

--- Comment #1 from Adam Hirst  ---
I'm not sure whether they're related, but I found a handful of
potentially-similar bugs, which might be worth collating here for quicker
reference.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459

[Bug target/83562] broken destructors of thread_local objects on i686 mingw targets

[thiago at kde dot org]

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

--- Comment #3 from Thiago Macieira  ---
This can easily be fixed by way of a trampoline that adjusts the parameter.

[Bug fortran/88455] New: False positive for allocatable character array of deferred length, ALLOCATE using SOURCE/MOLD [-Wuninitialized]

[adam at aphirst dot karoo.co.uk]

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

Bug ID: 88455
   Summary: False positive for allocatable character array of
deferred length, ALLOCATE using SOURCE/MOLD
[-Wuninitialized]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at aphirst dot karoo.co.uk
  Target Milestone: ---

program test
  implicit none

  call F(1, 10, 30)

contains

  subroutine F(i,j,k)
integer,  intent(in)  :: i, j, k
character(:), allocatable :: line(:)
! with a hard-coded len, the warning goes away
! similarly if it's deferred-length but scalar
!character(k), allocatable :: line(:) 

allocate( line(i:j), source = repeat(" ",k) )
print *, size(line) ! gives 10
print *, len(line)  ! gives 30

  end subroutine
end program test

---

Warning: ‘.line’ is used uninitialized in this function [-Wuninitialized]

---

Using a single ALLOCATE statement for an allocatable array of CHARACTER with
deferred length (using either SOURCE or MOLD) results in a false positive for
uninitialised variables.

The issue doesn't occur if the variable is ONLY an allocatable array, or
respectively if it's ONLY of deferred length. The issue occurs only when both
degrees of freedom are present.

System:
---
gcc (GCC) 8.2.1 20181127
Arch Linux x86_64

[Bug middle-end/88448] [9 regression] gnat.dg/opt66.adb etc. FAIL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
-FAIL: gnat.dg/opt66.adb (test for excess errors)
-FAIL: gnat.dg/opt66.adb 3 blank line(s) in output

[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
Should be fixed now.

[Bug c++/86049] Array bindings are not const when initializer is

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #5 from Richard Smith  ---
This was just reported as http://lists.isocpp.org/core/2018/12/5320.php; I
don't believe it's on the core issues list yet.


[@Tomalak, I think the standard is clear here:

"If the assignment-expression in the initializer has array type A and no
ref-qualifier is present, e has type cv A"

Here, A is the array type 'const int[1]' and cv is empty, so e has type 'const
int[1]'. But, as noted in comment#2, that seems like the wrong outcome. It also
contradicts the non-normative note in [dcl.struct.bind]p3, which further
suggests that this outcome was probably not the intent of the wording.]

[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 11 20:37:53 2018
New Revision: 267032

URL: https://gcc.gnu.org/viewcvs?rev=267032=gcc=rev
Log:
PR c++/87861
* class.c (build_vtbl_initializer): For TARGET_VTABLE_USES_DESCRIPTORS
bump index for each added word.
* constexpr.c (find_array_ctor_elt): Add forward declaration.
(cxx_eval_call_expression): Handle TARGET_VTABLE_USES_DESCRIPTORS
vtable calls.
(cxx_eval_constant_expression) : Divide token
by TARGET_VTABLE_USES_DESCRIPTORS if non-zero.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/constexpr.c

[Bug tree-optimization/80520] [7/8/9 Regression] Performance regression from missing if-conversion

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 11 20:28:35 2018
New Revision: 267031

URL: https://gcc.gnu.org/viewcvs?rev=267031=gcc=rev
Log:
PR tree-optimization/80520
* gcc.dg/tree-ssa/split-path-11.c (foo): Make the test ilp32 target
clean.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/split-path-11.c

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[vlovich at gmail dot com]

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

--- Comment #17 from Vitali  ---
I was explicitly asked to open this as a separate bug in comment #7 of 87950.
Would be helpful if the GCC devs could coordinate to figure out if they want
separate bugs for C/C++ or 1 bug.

Jonathan, on this forum your feedback comes off a bit like Skinner where he
blames the children. There's clearly a gap between how compiler authors define
switches as working & how developers wish to use those enums/wish those enums
were actually defined. I appreciate there's a large amount of legacy code that
complicates this issue but I don't think that condescending to people trying to
communicate the issue in good faith moves the conversation along.

I'd argue that clang strikes a much better balance here in terms of the
practical implications of the warning even if it's not perfect. In my mind,
warnings are most useful when they optimize for a low rate of false positives.
The GCC warnings for enums do not in practice have a low rate of false
positives and are clearly tuned to minimize false negatives (i.e. accidentally
missing a switch statement that doesn't have all enums covered). 

At the very least it would be useful to give users the power to turn on a
warning equivalent to Clang's that minimizes false negatives (or change
-Wswitch to be equivalent to Clang & add a -Wpedantic-switch that's part of
-pedantic for the current behaviour).

You could even provide annotations that let users annotate enums/switches in an
explicit fashion to indicate that they can be constructed with non-label
values/aren't expected to be depending on which flag you choose to use to
silence warnings/let the compiler optimize more fully.

In practice, definitely in C++, enums ARE intended to be a closed set of all
possible paths & the flags/random integer value cases are far less frequently
used; even for bitmasks it's a lazy way to do it. In C++ I usually define
strongly-typed types that represent the bitmask & overload the bit math
operators for the enum to yield that secondary type. I think considering that's
a technique used by Boost & Qt, it's reasonable to assume that having the enum
double as the storage type for the bitmask is more of a hack technically
allowed than one that is considered best practice by large C++ projects. In C
it's more muddled because there's no operator overloading, but the number of
enums that exist far outnumber the uses where it's used for bitwise math.

[Bug c++/86608] [7/8 Regression] volatile variable is taken as a constexpr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[7/8/9 Regression] volatile |[7/8 Regression] volatile
   |variable is taken as a  |variable is taken as a
   |constexpr   |constexpr

--- Comment #7 from Marek Polacek  ---
Fixed for GCC 9.

[Bug c++/86608] [7/8/9 Regression] volatile variable is taken as a constexpr

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Tue Dec 11 18:53:03 2018
New Revision: 267030

URL: https://gcc.gnu.org/viewcvs?rev=267030=gcc=rev
Log:
PR c++/86608 - reading constexpr volatile variable.
* constexpr.c (potential_constant_expression_1): Check want_rval
instead of checking if we have a decl.
* decl2.c (decl_maybe_constant_var_p): Don't consider volatile
constexpr variables as maybe constant.

* g++.dg/cpp0x/constexpr-volatile2.C: New test.
* g++.dg/cpp0x/pr65327.C: Add dg-error.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-volatile2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr65327.C

[Bug c++/88434] [DR1835] operator< should take precedence over template argument in basic.lookup.classref

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #4 from Andrew Pinski  ---
Suspecting until the Defect report is resolved.

[Bug c++/88434] operator< should take precedence over template argument in basic.lookup.classref

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Since the CWG issue is still "drafting", should we be making any changes at
this time?

[Bug target/88435] Compiling with optimizations causes the compiler to fail.

[mattis at mattisborgen dot se]

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

Mattis Lind  changed:

   What|Removed |Added

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

--- Comment #3 from Mattis Lind  ---
I can confirm that latest 9.0 doesn't have this problem.

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[ebotcazou at gcc dot gnu.org]

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

--- Comment #20 from Eric Botcazou  ---
> I guess the middle-end relies on TYPE_NAME to have the TYPE_MAIN_VARIANT
> type rather than be qualified.  The question if just here and it is possible
> to cope with that, or elsewhere too.

Yes, but only here and only for a couple of weeks, i.e. it's a novelty.

[Bug ada/88429] Ada bootstrap fails with --disable-shared

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> Unlike the default (--enable-shared) case, it seems that the rts directory
> for the non-default multilib is created incorrectly: with --enable-shared, I 
> see
> 
> make THREAD_KIND=native setup-rts
> make[9]: Entering directory
> '/var/scratch/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/gcc/ada'
> rm -rf rts_32
> mkdir -p rts_32
> chmod u+w rts_32
> 
> while with --disable-shared, I get the creation of rts twice.
> 
> This may be related to libada/configure.ac referencing a gnatlib-plain
> target for --disable-shared, which I couldn't find elsewhere.

Yes, but I don't understand why this doesn't fail in the default case too...

[Bug ada/88429] Ada bootstrap fails with --disable-shared

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug tree-optimization/88444] [9 Regression] ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:468; or ICE: tree check: expected ssa_name, have integer_cst in get_val

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 11 17:16:48 2018
New Revision: 267026

URL: https://gcc.gnu.org/viewcvs?rev=267026=gcc=rev
Log:
PR tree-optimization/88444
* tree-vrp.c (register_edge_assert_for_2): Only register assertions
for conversions if rhs1 is a SSA_NAME.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr88444.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug testsuite/88454] [9 regression] test case gcc.dg/tree-ssa/split-path-5.c fails after r266971

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
On i686-linux I get:
FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths "join
point for if-convertable half-diamond" 1
on x86_64-linux it passes.

[Bug c++/88375] Vague source location for bad initialization

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-11
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/88434] operator< should take precedence over template argument in basic.lookup.classref

[gieseanw+gcc at gmail dot com]

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

--- Comment #2 from Andrew Giese  ---
It appears there is a CWG issue for this:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1835

[Bug testsuite/88454] New: [9 regression] test case gcc.dg/tree-ssa/split-path-5.c fails after r266971

[seurer at gcc dot gnu.org]

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

Bug ID: 88454
   Summary: [9 regression] test case
gcc.dg/tree-ssa/split-path-5.c fails after r266971
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/split-path-5.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -fsplit-paths -fdump-tree-split-paths-details -w
-S -o split-path-5.s
PASS: gcc.dg/tree-ssa/split-path-5.c (test for excess errors)
gcc.dg/tree-ssa/split-path-5.c: pattern found 0 times
FAIL: gcc.dg/tree-ssa/split-path-5.c scan-tree-dump-times split-paths "join
point for if-convertable half-diamond" 1
testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
completed in 0 seconds

=== gcc Summary ===

# of expected passes1
# of unexpected failures1


r266971 | law | 2018-12-10 22:56:54 -0600 (Mon, 10 Dec 2018) | 6 lines

PR tree-optimization/80520
* gimple-ssa-split-paths.c (is_feasible_trace): Recognize half
diamonds that are likely if convertable.

* gcc.dg/tree-ssa/split-path-5.c: Update expected output.
* gcc.dg/tree-ssa/split-path-11.c: New test.

[Bug fortran/88452] gfortran (Gentoo 8.2.0-r5 p1.6) 8.2.0 reports internal error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Reduced testcase.

  subroutine tccdenom(n1,n2)
  implicit none
  integer n1, n2
  real tt1(n1,n2)
  complex ctt1(n1,n2)
  equivalence(tt1(1,1), ctt1(1,1))
  end

Workaround is to remove the dimension in the equivalence statement.
This compiles

  subroutine tccdenom(n1,n2)
  implicit none
  integer n1, n2
  real tt1(n1,n2)
  complex ctt1(n1,n2)
  equivalence(tt1, ctt1)
  end

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[hubicka at ucw dot cz]

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

--- Comment #19 from Jan Hubicka  ---
Yeap, the warnings was written at the time all C++ types had TYPE_NAMEs
and other types used IDENTIFIER_NODE. I have chnaged it for memory use
reaosns so only main variants have IDENTIFIER_NODE.  Usually we want to
just look for main variant and complain about that.  I will look into
it.

Honza

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||ldionne.2 at gmail dot com

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

[Bug c++/88453] GCC pretends that constexpr default-constructible type is nothrow constructible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I think this is another manifestation of PR 87603

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

[Bug c++/86049] Array bindings are not const when initializer is

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Richard, do you know if there's an issue for this yet?

[Bug c++/88453] New: GCC pretends that constexpr default-constructible type is nothrow constructible

[ldionne.2 at gmail dot com]

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

Bug ID: 88453
   Summary: GCC pretends that constexpr default-constructible type
is nothrow constructible
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code does not compile with GCC trunk:


#include 

struct Throwing {
  constexpr Throwing() {}
};

static_assert(!std::is_nothrow_default_constructible::value, "");


It seems like GCC assumes that the default constructor is noexcept since it is
constexpr. Clang does not have this behaviour, and I believe Clang to be
correct in this case.

Live example: https://wandbox.org/permlink/1z1qYQSUDWsYJda1

[Bug c++/86049] Array bindings are not const when initializer is

[tom at kera dot name]

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

Tomalak Geret'kal  changed:

   What|Removed |Added

 CC||tom at kera dot name

--- Comment #3 from Tomalak Geret'kal  ---
I disagree and think that Clang is wrong.

The top-level qualifiers of T (the type of One) should be "cv", and cv is "the
cv-qualifiers in the decl-specifier-seq". The decl-specifier-seq is "auto", not
"const auto". That "auto" will infer "const int" doesn't seem to be relevant.

Discussion on https://stackoverflow.com/q/53726135/560648.

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #14 from Jason Merrill  ---
It would certainly be possible to recognize this situation (all enumerators
handled) and suppress the -Wreturn-type warning even though we can't in general
assume that we can't get other values of the enumeration.  With the ability to
explicitly request warnings in this situation with another flag.  I don't know
how much work that would be.

[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Claudiu: could you test that patch please?  (On the real thing, not just
this testcase :-) )

[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Created attachment 45210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45210=edit
proposed patch

[Bug target/88425] suboptimal code for a

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 11 14:50:22 2018
New Revision: 267023

URL: https://gcc.gnu.org/viewcvs?rev=267023=gcc=rev
Log:
PR target/88425
* config/i386/i386.md (*x86_movcc_0_m1_neg_leu):
New define_insn_and_split.

* gcc.target/i386/pr88425.c: New test.

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

[Bug rtl-optimization/88416] [8/9 Regression] ICE in in df_uses_record, at df-scan.c:3013

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  The problem are targets like x86 which are not AUTO_INC_DEC, but
still have some patterns that use those expressions (pushes/pops).
As for !AUTO_INC_DEC we just called copy_rtx which does pretty much the same
copying/walking as cleanup_auto_inc_dec, except that the latter will handle
those properly, I think the best fix is just to never use copy_rtx here.

[Bug fortran/88452] New: gfortran (Gentoo 8.2.0-r5 p1.6) 8.2.0 reports internal error

[jiri.pitt...@jh-inst.cas.cz]

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

Bug ID: 88452
   Summary: gfortran (Gentoo 8.2.0-r5 p1.6) 8.2.0 reports internal
error
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiri.pitt...@jh-inst.cas.cz
  Target Milestone: ---

Created attachment 45208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45208=edit
source file triggering the bug

GNU Fortran (Gentoo 8.2.0-r5 p1.6) 8.2.0 reported:
> gfortran foo.F
f951: internal compiler error: get_mpz(): Not an integer constant
Please submit a full bug report,
with preprocessed source if appropriate.

The stripped source code reproducing the bug is attached.
It is due to an equivalence declaration, when commented out
the ICE disappears.

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
I guess the middle-end relies on TYPE_NAME to have the TYPE_MAIN_VARIANT type
rather than be qualified.  The question if just here and it is possible to cope
with that, or elsewhere too.

[Bug c/88451] New: No rounding in fixed-point arithmetic (Decimal to fixed-point conversion, multiplication)

[mantas.mikaitis at manchester dot ac.uk]

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

Bug ID: 88451
   Summary: No rounding in fixed-point arithmetic (Decimal to
fixed-point conversion, multiplication)
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mantas.mikaitis at manchester dot ac.uk
  Target Milestone: ---

Hello,

This bug report is about that there is no rounding in various parts of the
fixed-point arithmetic. Here are some cases run on ARM968:

1)

accum x = 0.04k; // This ends up as 0.03997802734375.



2)

double x = 0.04;
accum y = x; // This ends up as 0.03997802734375.



As you can notice, 0.04 is rounded down to 0.03997802734375, however, the
nearest accum to the 0.04 is 0.040008544921875.

3)

Multiplication of two accums results in a 63-bit value which needs to be
shifted right to put the result back to the accum type. Upon a shift, there is
no rounding and 15 bottom bits are truncated.



It seems to be doing binary truncation instead of rounding, which is also
mathematically legal operation, but introduces a larger error. Looking into the
ISO draft standard for fixed-point arithmetic, it specifies that
FX_FULL_PRECISION pragma can be used to obtain full precision:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n968.pdf, but it seems to have
no effect when I turn it on.

I am working with gcc version 6.3.1 20170620 (release) [ARM/embedded-6-branch
revision 249437] (GNU MCU Eclipse ARM Embedded GCC, 64-bits).

Many thanks,
Mantas M.

[Bug sanitizer/88426] [8 Regression] Compiler crash if use special code with command line switch -fsanitize=float-cast-overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] Compiler   |[8 Regression] Compiler
   |crash if use special code   |crash if use special code
   |with command line switch|with command line switch
   |-fsanitize=float-cast-overf |-fsanitize=float-cast-overf
   |low |low

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

[Bug sanitizer/88426] [8/9 Regression] Compiler crash if use special code with command line switch -fsanitize=float-cast-overflow

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 11 13:51:44 2018
New Revision: 267022

URL: https://gcc.gnu.org/viewcvs?rev=267022=gcc=rev
Log:
PR sanitizer/88426
* c-convert.c (convert): Call c_fully_fold before calling
ubsan_instrument_float_cast.

* c-c++-common/ubsan/float-cast-overflow-11.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-11.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-convert.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88446] __builtin_is_constant_evaluated rejects some converted constant expressions.

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The static_assert bug is related to PR86524.

[Bug c++/88446] __builtin_is_constant_evaluated rejects some converted constant expressions.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix for the array type dimensions.

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug bootstrap/88450] New: ICE in stage 2 compiler while configuring libgcc

[sbence92 at gmail dot com]

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

Bug ID: 88450
   Summary: ICE in stage 2 compiler while configuring libgcc
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbence92 at gmail dot com
  Target Milestone: ---

Created attachment 45206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45206=edit
main config.log

Bootstrap fails under Win10 at configuring libgcc in stage2 with
x86_64-w64-mingw32 host/target. Bootstraps succeeds with 9-20181118 snapshot
with same configuration/toolchain and fails at the same point with later
snapshots.
Host: win10, mingw64 with gcc 8.1 + msys2

configure:3745: checking for suffix of object files
configure:3767: /c/data/gcc9_b/./gcc/xgcc -B/c/data/gcc9_b/./gcc/
-L/usr/x86_64-w64-mingw32/lib -L/usr/mingw/lib -isystem
/usr/x86_64-w64-mingw32/include -isystem /usr/mingw/include
-B/usr/x86_64-w64-mingw32/bin/ -B/usr/x86_64-w64-mingw32/lib/ -isystem
/usr/x86_64-w64-mingw32/include -isystem /usr/x86_64-w64-mingw32/sys-include  
-fno-checking -c -g -O2 -pipe -fno-ident  conftest.c >&5
conftest.c: In function 'main':
conftest.c:15:3: internal compiler error: Segmentation fault
   15 |   return 0;
  |   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3771: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/;
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3785: error: in `/c/data/gcc9_b/x86_64-w64-mingw32/libgcc':
configure:3787: error: cannot compute suffix of object files: cannot compile

[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293

[asolokha at gmx dot com]

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

--- Comment #11 from Arseny Solokha  ---
Can this PR be closed now, or are there some issues left?

[Bug tree-optimization/88415] [7/8 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Dec 11 13:00:49 2018
New Revision: 267021

URL: https://gcc.gnu.org/viewcvs?rev=267021=gcc=rev
Log:
2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* gimple.c (gimple_assign_set_rhs_with_ops): Revert previous
change.
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c
trunk/gcc/tree-complex.c

[Bug middle-end/88448] [9 regression] gnat.dg/opt66.adb etc. FAIL

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Dec 11 13:00:49 2018
New Revision: 267021

URL: https://gcc.gnu.org/viewcvs?rev=267021=gcc=rev
Log:
2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* gimple.c (gimple_assign_set_rhs_with_ops): Revert previous
change.
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c
trunk/gcc/tree-complex.c

[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #9 from Nick Clifton  ---
fixed by increasing the recursion limit to 2048.

[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:

[nickc at gcc dot gnu.org]

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

--- Comment #8 from Nick Clifton  ---
Author: nickc
Date: Tue Dec 11 11:59:53 2018
New Revision: 267020

URL: https://gcc.gnu.org/viewcvs?rev=267020=gcc=rev
Log:
Fix a failure in the libiberty testsuite by increasing the demangle recursion
limit to 2048.

PR 88409
* demangle.h (DEMANGLE_RECURSION_LIMIT): Increase to 2048.

Modified:
trunk/include/ChangeLog
trunk/include/demangle.h

[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Segher Boessenkool  ---
Ah yes, I had release checking there.  Confirmed.

[Bug libstdc++/84949] -ffast-math bugged with respect to NaNs

[kretz at kde dot org]

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

--- Comment #7 from Matthias Kretz  ---
Example showing the discrepancy: https://godbolt.org/z/D15m71

Also PR83875 is relevant wrt. giving different answers depending on function
attributes.

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Earnshaw  ---
It seems better to fix this by using an unspec that's specific to the copysign
expansion.  That means we don't need to nobble the other optimizations the
compiler might do on bit-field manipulations.  It's unlikely that copysign will
be followed by other bit-manipulating operations on a FP value, but we'll just
have to live with that if they are.

[Bug libstdc++/84949] -ffast-math bugged with respect to NaNs

[kretz at kde dot org]

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

Matthias Kretz  changed:

   What|Removed |Added

 CC||kretz at kde dot org

--- Comment #6 from Matthias Kretz  ---
I'd like to make a case for numeric_limits::is_iec559 to follow
__STDC_IEC_559__. I.e. the following patch:

--- a/libstdc++-v3/include/std/limits
+++ b/libstdc++-v3/include/std/limits
@@ -1649,7 +1649,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   denorm_min() _GLIBCXX_USE_NOEXCEPT { return __FLT_DENORM_MIN__; }

   static _GLIBCXX_USE_CONSTEXPR bool is_iec559
+#ifdef __STDC_IEC_559__
   = has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+#else
+  = false;
+#endif
   static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
   static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;

@@ -1724,7 +1728,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   denorm_min() _GLIBCXX_USE_NOEXCEPT { return __DBL_DENORM_MIN__; }

   static _GLIBCXX_USE_CONSTEXPR bool is_iec559
+#ifdef __STDC_IEC_559__
   = has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+#else
+  = false;
+#endif
   static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
   static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;

@@ -1799,7 +1807,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   denorm_min() _GLIBCXX_USE_NOEXCEPT { return __LDBL_DENORM_MIN__; }

   static _GLIBCXX_USE_CONSTEXPR bool is_iec559
+#ifdef __STDC_IEC_559__
   = has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+#else
+  = false;
+#endif
   static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
   static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;


The __STDC_IEC_559__ macro is not defined when -ffast-math is active. is_iec559
requires "true if and only if the type adheres to ISO/IEC/IEEE 60559". I don't
have IEC559 at hand, but I believe assuming no NaN, inf, or -0 can occur makes
the floating point types not adhere to IEC559.
And IIUC, if __STDC_IEC_559__ is defined, then has_infinity, has_quiet_NaN and
has_denorm must all be true. So
+#ifdef __STDC_IEC_559__
+  = true;
+#else
+  = false;
+#endif
should be correct.

[Bug c/37369] ice for legal C code

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Dec 11 11:26:15 2018
New Revision: 267019

URL: https://gcc.gnu.org/viewcvs?rev=267019=gcc=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign

The copysign operations will almost always be performed on values in
floating-point registers.  As such, we do not want the compiler to
simplify the operations into code sequences that can only be done
using the general-purpose register set.  Unfortunately, this is what
is currently happening.

Fortunately, it seems quite unlikely that copysign() will be
subsequently followed by other logical operations on the values
involved, so I think it is acceptable to use an unspec here.  This
allows us to preserve the operation in a form that allows the register
allocator to make the right choice later on, without limitation on the
final form of the operation (well, if we do end up using the gp
register bank, we get a dead constant load that we cannot easily
eliminate at a late stage).

PR target/37369
* config/aarch64/iterators.md (sizem1): Add sizes for SFmode and
DFmode.
(Vbtype): Add SFmode mapping.
* config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete.
(copysign3): New expand pattern.
(copysign3_insn): New insn pattern.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/config/aarch64/iterators.md

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Dec 11 11:26:15 2018
New Revision: 267019

URL: https://gcc.gnu.org/viewcvs?rev=267019=gcc=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign

The copysign operations will almost always be performed on values in
floating-point registers.  As such, we do not want the compiler to
simplify the operations into code sequences that can only be done
using the general-purpose register set.  Unfortunately, this is what
is currently happening.

Fortunately, it seems quite unlikely that copysign() will be
subsequently followed by other logical operations on the values
involved, so I think it is acceptable to use an unspec here.  This
allows us to preserve the operation in a form that allows the register
allocator to make the right choice later on, without limitation on the
final form of the operation (well, if we do end up using the gp
register bank, we get a dead constant load that we cannot easily
eliminate at a late stage).

PR target/37369
* config/aarch64/iterators.md (sizem1): Add sizes for SFmode and
DFmode.
(Vbtype): Add SFmode mapping.
* config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete.
(copysign3): New expand pattern.
(copysign3_insn): New insn pattern.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/config/aarch64/iterators.md

[Bug c++/88449] __builtin_is_constant_evaluated misbehaves due to constexpr call caching

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-11
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[segher at gcc dot gnu.org]

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

--- Comment #14 from Segher Boessenkool  ---
And none of the compilers I built crash.  (Most have checking enabled, but some
not, so that's not it either).

[Bug c++/88449] New: __builtin_is_constant_evaluated misbehaves due to constexpr call caching

[jakub at gcc dot gnu.org]

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

Bug ID: 88449
   Summary: __builtin_is_constant_evaluated misbehaves due to
constexpr call caching
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The is-constant-evaluated1.C testcase when
constexpr inline bool
is_constant_evaluated () noexcept
{
  return __builtin_is_constant_evaluated ();
}
is added and all other __builtin_is_constant_evaluated calls are changed to
is_constant_evaluated fails (if it is made dg-do run) due to C++ constexpr call
caching.
Either we can just use the ctx->pretend_constant_evaluated as another
"argument" for the caching purposes (as the patch I'm going to attach does), or
we could do something smarter (remember during constexpr evaluation whether any
__builtin_is_constant_evaluated calls were seen), remember that in the context
and use a tri-state in the constexpr_call hash table - not seen,
pretend_constant_evaluated true or false.  But we'd need to make sure we
propagate it to all the callers right, if it is in the constexpr context,
anytime we create a new context we'd need to or it back afterwards.

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[asolokha at gmx dot com]

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

--- Comment #13 from Arseny Solokha  ---
In decl_address_invariant_p() we hit this break:

 3423 case VAR_DECL:
 3424   if ((TREE_STATIC (op) || DECL_EXTERNAL (op))
 3425   || DECL_THREAD_LOCAL_P (op) 
 3426   || DECL_CONTEXT (op) == current_function_decl   
 3427   || decl_function_context (op) == current_function_decl) 
 3428 return true;  
 3429   break;

and return false, which in the end becomes what is_gimple_min_invariant()
returns. I can provide relevant dumps or gdb session printouts if so desired.
At first glance I didn't notice anything glaringly wrong there, but admittedly
I have no idea what to look at.

[Bug libstdc++/88204] New test case 26_numerics/complex/operators/more_constexpr.cc from r266416 fails

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|powerpc64*-*-*  |powerpc64*-*-*,powerpc-*-ai
   ||x,powerpc*-*-darwin9
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
 CC||iains at gcc dot gnu.org
 Depends on||27964, 19779
 Ever confirmed|0   |1

--- Comment #1 from Iain Sandoe  ---
also on AIX and Darwin

this looks to be the long-standing problem of no constant folding for IBM long
doubles on powerpc platforms that use them.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
[Bug 19779] IBM 128bit long double format is not constant folded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug 27964] Wrong line ends on windows (XP)

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Tue, 11 Dec 2018, asolokha at gmx dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
> 
> --- Comment #10 from Arseny Solokha  ---
> Could your r266973 fix a root cause of this issue?

Unlikely.  I don't see how this assert can fire...

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
AT12.0 however, like on godbolt, does in fact crash.

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[asolokha at gmx dot com]

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

--- Comment #10 from Arseny Solokha  ---
Could your r266973 fix a root cause of this issue?

[Bug fortran/88438] [F08] A pointer function reference can denote a variable in any variable definition context.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
Summary|A pointer function  |[F08] A pointer function
   |reference can denote a  |reference can denote a
   |variable in any variable|variable in any variable
   |definition context. |definition context.
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
At https://gcc.gnu.org/wiki/Fortran2008Status I see

Unimplemented features -- based on the list in the "Introduction" of the F2008
standard
...
A pointer function reference can denote a variable in any variable definition
context.
...

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
I cannot get that to fail either, with a trunk compiler :-/

[Bug fortran/88447] Non-contiguous array argument of some class not passed properly to subroutine

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 6.4 up to trunk (9.0). With 5.5.0 I get at run time

At line 24 of file pr88447_1.f90 (unit = 6, file = 'stdout')
Fortran runtime error: '*' requires at least one associated data descriptor
(a,*(3f12.3," |"))
^

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 11 10:28:39 2018
New Revision: 266974

URL: https://gcc.gnu.org/viewcvs?rev=266974=gcc=rev
Log:
PR lto/86004
* doc/sourcebuild.texi (lto_incremental): Document new effective
target.

* lib/target-supports.exp (check_effective_target_lto_incremental):
New.
* g++.dg/lto/pr69137_0.C: Require lto_incremental effective target.
* g++.dg/lto/pr65316_0.C: Likewise.
* g++.dg/lto/pr85176_0.C: Likewise.
* g++.dg/lto/pr79000_0.C: Likewise.
* g++.dg/lto/pr66180_0.C: Likewise.
* g++.dg/lto/pr65193_0.C: Likewise.
* g++.dg/lto/pr69077_0.C: Likewise.
* g++.dg/lto/pr68057_0.C: Likewise.
* g++.dg/lto/pr66705_0.C: Likewise.
* g++.dg/lto/pr65302_0.C: Likewise.
* g++.dg/lto/20091002-1_0.C: Likewise.
* g++.dg/lto/pr81940_0.C: Likewise.
* g++.dg/lto/pr64043_0.C: Likewise.
* g++.dg/lto/pr65549_0.C: Likewise.
* g++.dg/lto/pr69133_0.C: Likewise.
* gfortran.dg/lto/pr79108_0.f90: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/20091002-1_0.C
trunk/gcc/testsuite/g++.dg/lto/pr64043_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65193_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65302_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65316_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65549_0.C
trunk/gcc/testsuite/g++.dg/lto/pr66180_0.C
trunk/gcc/testsuite/g++.dg/lto/pr66705_0.C
trunk/gcc/testsuite/g++.dg/lto/pr68057_0.C
trunk/gcc/testsuite/g++.dg/lto/pr69077_0.C
trunk/gcc/testsuite/g++.dg/lto/pr69133_0.C
trunk/gcc/testsuite/g++.dg/lto/pr69137_0.C
trunk/gcc/testsuite/g++.dg/lto/pr79000_0.C
trunk/gcc/testsuite/g++.dg/lto/pr81940_0.C
trunk/gcc/testsuite/g++.dg/lto/pr85176_0.C
trunk/gcc/testsuite/gfortran.dg/lto/pr79108_0.f90
trunk/gcc/testsuite/lib/target-supports.exp