[Bug testsuite/86153] [8 regression] test case g++.dg/pr83239.C fails starting with r261585

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[8/9 regression] test case  |[8 regression] test case
   |g++.dg/pr83239.C fails  |g++.dg/pr83239.C fails
   |starting with r261585   |starting with r261585

--- Comment #14 from Alexandre Oliva  ---
Fixed in the trunk

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #24 from Alexandre Oliva  ---
Fixed in the trunk

[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #11 from Alexandre Oliva  ---
Fixed in the trunk

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
> Hmm.  I must be looking in the wrong place for documentation; are these
> explained somewhere?  
> 
> At https://gcc.gnu.org/install/configure.html I see a description of 
>--target
> and a brief mention of 
>--host
> but no definition.  There doesn't seem to be a description for --build.

OK, then I wrongly interpreted the previous quoted sentence, which was more
incomplete than wrong.  It should probably be completed with something like
"But on native systems supporting several architectures, it might be necessary
to explicitly select one by means of the --build switch".

[Bug testsuite/86153] [8/9 regression] test case g++.dg/pr83239.C fails starting with r261585

[aoliva at gcc dot gnu.org]

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

--- Comment #13 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Dec 19 06:51:41 2018
New Revision: 267252

URL: https://gcc.gnu.org/viewcvs?rev=267252=gcc=rev
Log:
[PR86153] simplify more overflow tests in VRP

PR 86153 was originally filed when changes to the C++11's
implementation of vector resize(size_type) limited inlining that were
required for testsuite/g++.dg/pr83239.C to verify that we did not
issue an undesired warning.

That was worked by increasing the limit for inlining, but that in turn
caused the C++98 implementation of vector resize, that is
significantly different, to also be fully inlined, and that happened
to issue the very warnings the test was meant to verify we did NOT
issue.

The reason we issued the warnings was that we failed to optimize out
some parts of _M_fill_insert, used by the C++98 version of vector
resize, although the call of _M_fill_insert was guarded by a test that
could never pass: test testcase only calls resize when the vector size
is >= 3, to decrement the size by two.  The limitation we hit in VRP
was that the compared values could pass as an overflow test, if the
vector size was 0 or 1 (we knew it wasn't), but even with dynamic
ranges we failed to decide that the test result could be determined at
compile time, even though after the test we introduced ASSERT_EXPRs
that required a condition known to be false from earlier ones.

I pondered turning ASSERT_EXPRs that show impossible conditions into
traps, to enable subsequent instructions to be optimized, but I ended
up finding an earlier spot in which an overflow test that would have
introduced the impossible ASSERT_EXPR can have its result deduced from
earlier known ranges and resolved to the other path.

Although such overflow tests could be uniformly simplified to compares
against a constant, the original code would only perform such
simplifications when the test could be resolved to an equality test
against zero.  I've thus avoided introducing compares against other
constants, and instead added code that will only simplify overflow
tests that weren't simplified before when the condition can be
evaluated at compile time.


for  gcc/ChangeLog

PR testsuite/86153
PR middle-end/83239
* vr-values.c
(vr_values::vrp_evaluate_conditional_warnv_with_ops): Extend
simplification of overflow tests to cover cases in which we
can determine the result of the comparison.

for  gcc/testsuite/ChangeLog

PR testsuite/86153
PR middle-end/83239
* gcc.dg/vrp-overflow-1.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/vrp-overflow-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vr-values.c

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[aoliva at gcc dot gnu.org]

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

--- Comment #23 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Dec 19 06:51:41 2018
New Revision: 267252

URL: https://gcc.gnu.org/viewcvs?rev=267252=gcc=rev
Log:
[PR86153] simplify more overflow tests in VRP

PR 86153 was originally filed when changes to the C++11's
implementation of vector resize(size_type) limited inlining that were
required for testsuite/g++.dg/pr83239.C to verify that we did not
issue an undesired warning.

That was worked by increasing the limit for inlining, but that in turn
caused the C++98 implementation of vector resize, that is
significantly different, to also be fully inlined, and that happened
to issue the very warnings the test was meant to verify we did NOT
issue.

The reason we issued the warnings was that we failed to optimize out
some parts of _M_fill_insert, used by the C++98 version of vector
resize, although the call of _M_fill_insert was guarded by a test that
could never pass: test testcase only calls resize when the vector size
is >= 3, to decrement the size by two.  The limitation we hit in VRP
was that the compared values could pass as an overflow test, if the
vector size was 0 or 1 (we knew it wasn't), but even with dynamic
ranges we failed to decide that the test result could be determined at
compile time, even though after the test we introduced ASSERT_EXPRs
that required a condition known to be false from earlier ones.

I pondered turning ASSERT_EXPRs that show impossible conditions into
traps, to enable subsequent instructions to be optimized, but I ended
up finding an earlier spot in which an overflow test that would have
introduced the impossible ASSERT_EXPR can have its result deduced from
earlier known ranges and resolved to the other path.

Although such overflow tests could be uniformly simplified to compares
against a constant, the original code would only perform such
simplifications when the test could be resolved to an equality test
against zero.  I've thus avoided introducing compares against other
constants, and instead added code that will only simplify overflow
tests that weren't simplified before when the condition can be
evaluated at compile time.


for  gcc/ChangeLog

PR testsuite/86153
PR middle-end/83239
* vr-values.c
(vr_values::vrp_evaluate_conditional_warnv_with_ops): Extend
simplification of overflow tests to cover cases in which we
can determine the result of the comparison.

for  gcc/testsuite/ChangeLog

PR testsuite/86153
PR middle-end/83239
* gcc.dg/vrp-overflow-1.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/vrp-overflow-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vr-values.c

[Bug c++/87012] [7/8/9 Regression] ICE in verify_unstripped_args_1

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Dec 19 06:51:30 2018
New Revision: 267251

URL: https://gcc.gnu.org/viewcvs?rev=267251=gcc=rev
Log:
[PR87012] canonicalize ref type for tmpl arg

When binding an object to a template parameter of reference type, we
take the address of the object and dereference that address.  The type
of the address may still carry (template) typedefs, but
verify_unstripped_args_1 rejects such typedefs other than in the top
level of template arguments.

Canonicalizing the type we want to convert to right after any
substitutions or deductions avoids that issue.


for  gcc/cp/ChangeLog

PR c++/87012
* pt.c (convert_template_argument): Canonicalize type after
tsubst/deduce.

for  gcc/testsuite/ChangeLog

PR c++/87012
* g++.dg/cpp0x/pr87012.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr87012.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014

[aoliva at gcc dot gnu.org]

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

--- Comment #10 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Dec 19 06:51:19 2018
New Revision: 267250

URL: https://gcc.gnu.org/viewcvs?rev=267250=gcc=rev
Log:
[PR c++/88146] do not crash synthesizing inherited ctor(...)

This patch started out from the testcase in PR88146, that attempted to
synthesize an inherited ctor without any args before a varargs
ellipsis and crashed while at that, because of the unguarded
dereferencing of the parm type list, that usually contains a
terminator.  The terminator is not there for varargs functions,
however, and without any other args, we ended up dereferencing a NULL
pointer.  Oops.

Guarding accesses to parm would be easy, but not necessary.  In
do_build_copy_constructor, non-inherited ctors are copy-ctors, that
always have at least one parm, so parm needs not be guarded when we
know the access will only take place when we're dealing with an
inherited ctor.  The only other problematic use was in the cvquals
initializer, a variable only used in a loop over fields, that we
skipped individually in inherited ctors.  I've guarded the cvquals
initialization and the entire loop over fields so they only run for
copy-ctors.

Avoiding the crash from unguarded accesses was easy, but I thought we
should still produce the sorry message we got in other testcases that
passed arguments through the ellipsis in inherited ctors.  I put a
check in, and noticed the inherited ctors were synthesized with the
location assigned to the class name, although they were initially
assigned the location of the using declaration.  I decided the latter
was better, and arranged for the better location to be retained.

Further investigation revealed the lack of a sorry message had to do
with the call being in a non-evaluated context, in this case, a
noexcept expression.  The sorry would be correctly reported in other
contexts, so I rolled back the check I'd added, but retained the
source location improvement.

I was still concerned about issuing sorry messages while instantiating
template ctors even in non-evaluated contexts, e.g., if a template
ctor had a base initializer that used an inherited ctor with enough
arguments that they'd go through an ellipsis.  I wanted to defer the
instantiation of such template ctors, but that would have been wrong
for constexpr template ctors, and already done for non-constexpr ones.
So, I just consolidated multiple test variants into a single testcase
that explores and explains various of the possibilities I thought of.


for  gcc/cp/ChangeLog

PR c++/88146
* method.c (do_build_copy_constructor): Guard cvquals init and
loop over fields to run for non-inherited ctors only.
(synthesize_method): Retain location of inherited ctor.

for  gcc/testsuite/ChangeLog

PR c++/88146
* g++.dg/cpp0x/inh-ctor32.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor32.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/88549] gcc doesn't install iso_c_binding.mod

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> There isn't an installed iso_c_binding.mod, and there
> never will be.  It is generated and stored in memory
> when needed by gfortran.

Just noticed your error message is from flang.
flang is not gfortran.

[Bug fortran/88549] gcc doesn't install iso_c_binding.mod

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
There isn't an installed iso_c_binding.mod, and there
never will be.  It is generated and stored in memory
when needed by gfortran.

[Bug fortran/88549] New: gcc doesn't install iso_c_binding.mod

[yuri at tsoft dot com]

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

Bug ID: 88549
   Summary: gcc doesn't install iso_c_binding.mod
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yuri at tsoft dot com
  Target Milestone: ---

gcc doesn't install iso_c_binding.mod, and the pcmsolver project
(https://github.com/PCMSolver/pcmsolver) fails:

> F90-F-0004-Unable to open MODULE file iso_c_binding.mod 
> (/wrkdirs/usr/ports/science/pcmsolver/work/pcmsolver-1.2.1/src/metal/metal_sphere.F90:
>  26)
> F90/x86-64 FreeBSD Flang - 1.5 2017-05-01: compilation aborted

Googling iso_c_binding.mod finds some more instances of a similar problem.

See log:
http://beefy6.nyi.freebsd.org/data/120amd64-default/487722/logs/pcmsolver-1.2.1_2.log

FreeBSD 12 amd64

[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Eric Gallager  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> > --- Comment #8 from Jonathan Wakely  ---
> > Jay, is the original problem on SunOS still happening?
> >
> > Rainer, any insight into that build failure? Are some Solaris patches 
> > needed?
> 
> I don't think so: both in Solaris 10 FCS and in current Solaris 11.4,
>  declares strsignal alike:
> 
> extern char *strsignal(int);
> 
> And for me, both HAVE_STRSIGNAL and HAVE_DECL_STRSIGNAL are defined as 1
> in gcc/auto-host.h.
> 
> Jay needs to look at gcc/config.log in more detail to find why the
> corresponding autoconf tests fail for him while they work here.

Well, since Jay hasn't done so within 3 months of this having been put in
WAITING, I'm closing this. Jay, feel free to reopen if you ever do find the
additional details requested.

[Bug bootstrap/56954] Bootstrap failure: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive]

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||build
 Status|WAITING |NEW
   Last reconfirmed|2018-09-07 00:00:00 |2018-09-11 0:00

--- Comment #4 from Eric Gallager  ---
I guess the dups are confirmation that it still happens.

[Bug translation/80191] diagnostic placeholder "new initializer" must be marked for translation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Eric Gallager  ---
(In reply to Eric Gallager from comment #8)
> (In reply to Eric Gallager from comment #7)
> > Changing component to translation, but leaving UNCONFIRMED since there seems
> > to be disagreement
> 
> Putting in WAITING in the hopes that someone else will decide one way or
> another whether this bug is valid or not.

No reply; closing per Jonathan in comment #6

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #13 from Eric Gallager  ---
(In reply to Eric Gallager from comment #11)
> (In reply to Marc Glisse from comment #10)
> > IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the
> > optimization level (even at -O3), it has too many false positives that are
> > all but impossible to work around (thus violating the definition of -Wall),
> > -Wextra is good enough for it. We could keep -Wuninitialized though (it
> > requires changing the dependency between these 2 warnings).
> 
> I think I remember at least 1 other bug where we came to this conclusion; I
> forget its number right now though...

Right, it was bug 80635

[Bug middle-end/65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #13 from Eric Gallager  ---
Bug 78394 is also about -Wmaybe-uninitialized with -Og

[Bug c/88546] Copy attribute unusable for weakrefs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-19
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  The warnings should be easy enough to suppress in the attribute
copy handler.  Attribute weakref on extern symbols has been rejected since
r108074 (GCC 4.1 seems fine with it).  I have no idea it would take to accept
them with the correct semantics.

[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target

[mateuszb at poczta dot onet.pl]

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

--- Comment #8 from mateuszb at poczta dot onet.pl ---
My proposition is:

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 267245)
+++ gcc/config/i386/i386.c  (working copy)
@@ -9063,6 +9063,13 @@
  && !COMPLEX_MODE_P (mode))
regno = FIRST_SSE_REG;
  break;
+   case 8:
+   case 4:
+ if (valtype != NULL_TREE && AGGREGATE_TYPE_P (valtype))
+   break;
+ if (mode == SFmode || mode == DFmode)
+   regno = FIRST_SSE_REG;
+ break;
default:
  break;
 }

which gives:

$ cat t.c
float fun1(void)
{
return 4.14f;
}

typedef struct {float x;} Float;

Float fun2(void)
{
Float v;
v.x = 4.14f;
return v;
}

Mateusz@Mateusz-i7 /c/temp
$ gcc -c -O2 -o t.o t.c

Mateusz@Mateusz-i7 /c/temp
$ objdump -dr t.o

t.o: file format pe-x86-64


Disassembly of section .text:

 :
   0:   f3 0f 10 05 00 00 00movss  0x0(%rip),%xmm0# 8 
   7:   00
4: R_X86_64_PC32.rdata
   8:   c3  retq
   9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)

0010 :
  10:   8b 05 00 00 00 00   mov0x0(%rip),%eax# 16 
12: R_X86_64_PC32   .rdata
  16:   c3  retq
  17:   90  nop
  18:   90  nop
  19:   90  nop
  1a:   90  nop
  1b:   90  nop
  1c:   90  nop
  1d:   90  nop
  1e:   90  nop
  1f:   90  nop

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[mailboxnotfound at yahoo dot com]

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

--- Comment #12 from john henning  ---
Summary:
   Eric's advice worked as prescribed.

Detail: 

On a SPARC Solaris 11.4 system, with a /usr/bin/gcc
that by default produces 64-bit objects, this worked for 
an 8.2.0 bootstrap build:

  export CC="gcc -m64"
  export CXX="g++ -m64"

  /export/home/johnh/gcc/build/gcc-8.2.0/configure \
 --enable-languages=c,c++,fortran --enable-lto \
 --without-system-zlib --with-included-gettext \
\
 --build=sparcv9-sun-solaris2.11\
\
 --disable-libvtv \
 --with-gnu-as --with-as=/usr/gnu/bin/as \
 --without-gnu-ld --with-ld=/usr/bin/ld \
 --with-pkgversion=johnh-18-Dec-2018 \
 --prefix=/export/GCC/gcc-8.2.0 \
--with-local-prefix=/export/GCC

   gmake -j200  bootstrap && gmake install

and in particular, dwarf2out.o matches exactly for
stage 2 and 3:

$ file */dwarf2out.o
gcc/dwarf2out.o:ELF 64-bit MSB relocatable SPARCV9 Version 1
prev-gcc/dwarf2out.o:   ELF 64-bit MSB relocatable SPARCV9 Version 1
stage1-gcc/dwarf2out.o: ELF 64-bit MSB relocatable SPARCV9 Version 1
$ md5sum */dwarf2out.o
9648da8ac96c68bc929b5a23f9174889  gcc/dwarf2out.o
9648da8ac96c68bc929b5a23f9174889  prev-gcc/dwarf2out.o
e482bf6aeef8753c6f5eac01bfb5f061  stage1-gcc/dwarf2out.o
$

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law  ---
Whether or not to fix as well as whether or not to warn at -O0 are a topic of
debate.  I'm not sure I'm up for re-opening that can of worms right now.

I strongly believe -Wmaybe-uninitialized should continue to be enabled by
-Wall.   They tend to either point out obscure ways objects are uninitialized
or they point out missed optimizations.  Both are critical in my mind.

[Bug c++/88548] [9 Regression] this accepted in static member functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Target Milestone|--- |9.0

[Bug c++/88548] New: [9 Regression] this accepted in static member functions

[mpolacek at gcc dot gnu.org]

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

Bug ID: 88548
   Summary: [9 Regression] this accepted in static member
functions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Since r266224, we accept this program:

struct S {
  int a;
  static void fn() noexcept(noexcept(this->a)) { }
};

but because fn is static, this should be ill-formed.

[Bug c/88544] ICE on ARM Cortex A7

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-12-18
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
we need a testcase which we can use to reliably reproduce a bug.  There's not
much we can do without that...

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[mailboxnotfound at yahoo dot com]

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

--- Comment #11 from john henning  ---
> There are 3 different switches: --build, --host and --target.

Hmm.  I must be looking in the wrong place for documentation; are these
explained somewhere?  

At https://gcc.gnu.org/install/configure.html I see a description of 
   --target
and a brief mention of 
   --host
but no definition.  There doesn't seem to be a description for --build.

[Bug target/88547] New: missed optimization for vector comparisons

[rth at gcc dot gnu.org]

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

Bug ID: 88547
   Summary: missed optimization for vector comparisons
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

typedef signed svec __attribute__((vector_size(16)));
typedef unsigned uvec __attribute__((vector_size(16)));

svec les(svec x, svec y) {
return x <= y;
}

uvec leu(uvec x, uvec y) {
return x <= y;
}

currently assemble to 

les:
vpcmpgtd  %xmm1, %xmm0, %xmm0
vpcmpeqd  %xmm1, %xmm1, %xmm1
vpandn%xmm1, %xmm0, %xmm0

leu:
vmovdqa64 .LC0(%rip), %xmm2
vpsubd%xmm2, %xmm1, %xmm1
vpsubd%xmm2, %xmm0, %xmm0
vpcmpgtd  %xmm1, %xmm0, %xmm0
vpcmpeqd  %xmm1, %xmm1, %xmm1
vpandn%xmm1, %xmm0, %xmm0

By using the transformation min(x, y) == x we can produce

les:
vpminsd   %xmm1, %xmm0, %xmm1
vpcmpeqd  %xmm1, %xmm0, %xmm0

leu:
vpminud   %xmm1, %xmm0, %xmm1
vpcmpeqd  %xmm0, %xmm1, %xmm0

This can be used to reduce unsigned comparisons without requiring
the use of a constant bias vector.  At least when the given min insn
is available in the architecture.

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> Is that switch similar to or different from the switch '--target=something',
> which http://gcc.gnu.org/install/configure.html discourages from use?  

There are 3 different switches: --build, --host and --target.

> It says: "GCC has code to correctly determine the correct value for target
> for nearly all native systems. Therefore, we highly recommend you do not
> provide a configure target when configuring a native compiler." 

Well, that's wrong for SPARC/Solaris and probably most multi-arch systems.

[Bug tree-optimization/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply

[anlauf at gmx dot de]

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

--- Comment #9 from Harald Anlauf  ---
(In reply to Richard Biener from comment #8)
> Created attachment 45252 [details]
> patch
> 
> Even though the patch doesn't hoist the invariant condition the speed is
> back with it.
> 
> Can you verify that?

I tried this just this patch on top of the 9-revision previously used and
get:

baseline + -funroll-loops -fcheck=bounds :

7: 1.56
8: 1.56
9: 1.93 (unmodified)
9: 1.63 (patched)

baseline + -O3 -funroll-loops -fcheck=bounds :

7: 1.56
8: 1.39
9: 1.57 (unmodified)
9: 1.38 (patched)

Yes, the speed is back for the testcase.

Thanks for the quick fix!

[Bug rtl-optimization/87759] [8/9 Regression] ICE in lra_assign, at lra-assigns.c:1624, or ICE: Maximum number of LRA assignment passes is achieved (30), or compile-time hog

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 18 21:48:59 2018
New Revision: 267245

URL: https://gcc.gnu.org/viewcvs?rev=267245=gcc=rev
Log:
PR rtl-optimization/87759
* gcc.target/i386/pr87759.c: Require int128 effective target.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr87759.c

[Bug c/88546] Copy attribute unusable for weakrefs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Or another option would be to allow leaf attribute on the weakrefs, but we
haven't allowed that for a couple of releases already.
E.g.
extern int foo (void) __attribute__((leaf));
static __typeof (foo) bar __attribute__((weakref ("foo"), leaf));

static int a;

int
baz (void)
{
  a = 1;
  foo ();
  return a;
}

int
qux (void)
{
  a = 1;
  bar ();
  return a;
}
isn't optimized in qux because leaf attribute isn't on the weakref.
Weakrefs are a weird thing, they are static because it is an alias affecting
the local TU only, but they are effectively external calls most of the time.

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[mailboxnotfound at yahoo dot com]

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

--- Comment #9 from john henning  ---
Eric, thank you for the explicit advice, although I note that both your
examples say '--build=something'.  

Is that switch similar to or different from the switch '--target=something',
which http://gcc.gnu.org/install/configure.html discourages from use?  

It says: "GCC has code to correctly determine the correct value for target for
nearly all native systems. Therefore, we highly recommend you do not provide a
configure target when configuring a native compiler." 

That is, would you expect it would work to just say:
   CC="gcc -m32" CXX="g++ -m32" ./configure
and
   CC="gcc -m64" CXX="g++ -m64" ./configure

[Bug rtl-optimization/87759] [8/9 Regression] ICE in lra_assign, at lra-assigns.c:1624, or ICE: Maximum number of LRA assignment passes is achieved (30), or compile-time hog

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Dec 18 21:20:16 2018
New Revision: 267244

URL: https://gcc.gnu.org/viewcvs?rev=267244=gcc=rev
Log:
2018-12-18  Vladimir Makarov  

PR rtl-optimization/87759
* lra-assigns.c (lra_split_hard_reg_for): Recalculate
non_reload_pseudos.

2018-12-18  Vladimir Makarov  

PR rtl-optimization/87759
* gcc.target/i386/pr87759.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr87759.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> Yes, same for a bootstrap.  You can bootstrap the latter with the former if
> you correctly configure the bootstrap, with explicit --build and CC="gcc
> -m32".

To be more explicit: if you want to bootstrap the 32-bit compiler with the
64-bit system compiler, you must configure like this:

CC="gcc -m32" CXX="g++ -m32" ./configure --build=sparc-sun-solaris2.11

Conversely, if you want to bootstrap the 64-bit compiler with the 32-bit one:

CC="gcc -m64" CXX="g++ -m64" ./configure --build=sparcv9-sun-solaris2.11

[Bug c/88546] New: Copy attribute unusable for weakrefs

[jakub at gcc dot gnu.org]

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

Bug ID: 88546
   Summary: Copy attribute unusable for weakrefs
   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: ---

I've tried following patch to quiet the hundreds of warnings we get during
bootstrap due to -Wmissing-attributes:
2018-12-18  Jakub Jelinek  

* gthr-posix.h (__gthrw2): Add __copy__ argument.

--- libgcc/gthr-posix.h.jj  2018-01-03 10:42:56.133763484 +0100
+++ libgcc/gthr-posix.h 2018-12-18 15:16:03.720109264 +0100
@@ -87,7 +87,8 @@ typedef struct timespec __gthread_time_t
 #  define __gthrw_pragma(pragma)
 # endif
 # define __gthrw2(name,name2,type) \
-  static __typeof(type) name __attribute__ ((__weakref__(#name2))); \
+  static __typeof(type) name \
+  __attribute__ ((__weakref__(#name2), __copy__(type))); \
   __gthrw_pragma(weak type)
 # define __gthrw_(name) __gthrw_ ## name
 #else

but unfortunately that patch just trades one set of warnings like:
../../libgcc/gthr-default.h:99:32: warning: ‘__gthrw_pthread_equal’ specifies
less restrictive attributes than its target ‘pthread_equal’: ‘const’, ‘leaf’,
‘nothrow’ [-Wmissing-attributes]
   99 | #define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name)
  |^~~~
etc. for:
../../libgcc/gthr-default.h:237:1: warning: ‘leaf’ attribute has no effect on
unit local functions [-Wattributes]
  237 | __gthrw2(__gthrw_(__pthread_key_create),
  | ^~~~
../../libgcc/gthr-default.h:100:32: warning: ‘__gthrw_pthread_equal’ specifies
less restrictive attribute than its target ‘pthread_equal’: ‘leaf’
[-Wmissing-attributes]
  100 | #define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name)
  |^~~~

So, probably leaf attribute shouldn't be copied if the decl on which it is is
unit local (weakrefs are) and -Wmissing-attributes needs to be fixed not to
emit the bogus diagnostics about leaf.

[Bug libstdc++/88545] New: std::find compile to memchr in trivial random access cases (patch)

[gcc at gms dot tf]

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

Bug ID: 88545
   Summary: std::find compile to memchr in trivial random access
cases (patch)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at gms dot tf
  Target Milestone: ---

Created attachment 45259
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45259=edit
specialize std::find to memchr for character searches in continous memory

If std::find() is called with continuous random access iterators and a trivial
char sized value, then calling memchr() is much more efficient than calling
into the generic __find_if().

The attached patch implements this optimization.

That means it specializes a std::find helper on the iterator category and the
value and calls __builtin_memchr() if possible.

I've tested it on Fedora 27 and Fedora 29 (libstdc++-8.2.1-5.fc29.x86_64), but
it should apply to the master branch as well.

Note that the patch uses techniques similar to what is already used for other
algorithms in bits/stl_algo.h and bits/stl_algobase.h for detecting continuous
random access iterators and specializations (e.g. std::equal calling memcmp if
possible, other algorithms calling memmove, etc.).

I benchmarked some memchr()/std::find() implementations and one relevant result
was that glibc's memchr() outperforms libstc++'s std::find() status-quo
implementation (which does some manual loop unrolling in the find_if helper) by
a factor of 1.5 or so (it always outperforms std::find(), but the factors vary
between different CPU families). Also, on many CPUs, std::find() is even slower
than a simple loop. (i.e. when using it for character searches)

See also: https://gms.tf/stdfind-and-memchr-optimizations.html#measurements

Trophex Show 2k19

[Helen Stovall via gcc-bugs]

Hi,

 

I am following up to check if you're company is interested in acquiring
Attendees List of " The Trophex Show 2019" and the Total count will be
7,500.

 

We have Special discount price for Christmas & New Year.

 

Data Fields includes: Company name, Contact name, Title, Email address,
Website, Industry, Telephone number, etc. 

 

 Note: The counts given above are GDPR complaint with all the rules and
regulations with 100% opt-in contacts

 

Awaiting your reply

 

Thanks & Regards,

Helen Stovall

Demand Generator

 

To opt out, please reply with Leave Out in the Subject Line.

 

[Bug target/88541] VPCLMULQDQ 256-bit inline function unavailable with optimization but without enabled AVX512VL support

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
But looking at 319433-030.pdf there indeed is a VEX encoded insn that just
needs VPCLMULQDQ ISA and i386-builtins.def has that same requirement (avx +
vpclmulqdq).  Testing a patch.

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Eric Botcazou  ---
>> I wonder if the configure or make process should defend against the
>> possibility that the host compiler and the compiler that we are building
>> today have differing defaults for -m32 vs -m64.
>
> The problem is that we don't correctly detect the cross configuration here.

That's because, as I suspected, config.guess doesn't distinguish sparc
and sparcv9 configurations of Solaris, unlike the i386/x86_64 case.

[Bug c/88477] Variable with type completed in initializer not allowed.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Anders Granlund  ---
The standard is a bit unclear, but that seems like a reasonable interpretation
of it.

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> I wonder if the configure or make process should defend against the
> possibility that the host compiler and the compiler that we are building
> today have differing defaults for -m32 vs -m64.

The problem is that we don't correctly detect the cross configuration here.

> (Note: Although the defaults differ, both the above are perfectly happy to
> build the non-default version if you are explicit for -m32 or -m64).

Yes, same for a bootstrap.  You can bootstrap the latter with the former if you
correctly configure the bootstrap, with explicit --build and CC="gcc -m32".

[Bug c/88526] gcc accepts ill-formed program with sizeof (int [*])

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
This is not a bug in gcc. It is clang that has the incorrect behaviour.

[Bug c/88544] New: ICE on ARM Cortex A7

[ynezz at true dot cz]

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

Bug ID: 88544
   Summary: ICE on ARM Cortex A7
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ynezz at true dot cz
  Target Milestone: ---

Hi,

while build testing new 4.19.9 kernel in OpenWrt for arm_cortex-a7+neon-vfpv4
target, I've hit following ICE:

In file included from ./include/linux/kernel.h:207:0,
 from ./include/linux/list.h:9,
 from ./include/linux/preempt.h:11,
 from ./include/linux/hardirq.h:5,
 from ./include/net/sock.h:43,
 from net/l2tp/l2tp_netlink.c:19:
./arch/arm/include/asm/div64.h:1:0: internal compiler error: Illegal
instruction
 /* SPDX-License-Identifier: GPL-2.0 */

  CC [M]  drivers/usb/storage/datafab.o
  CC [M]  drivers/usb/serial/keyspan.o
0x9e090f crash_signal
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/toplev.c:337
0x103a203 munge
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/mkdeps.c:61
0x103a4c5 deps_add_dep(deps*, char const*)
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/mkdeps.c:258
0x102ce0f _cpp_stack_file
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/files.c:912
0x102d06c _cpp_stack_include
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/files.c:1049
0x102449a do_include_common
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/directives.c:858
0x1024fcf _cpp_handle_directive
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/directives.c:547
0x1032f2c _cpp_lex_token
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/lex.c:2566
0x1038ecf cpp_get_token_1
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/macro.c:2523
0x618c8e c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c-family/c-lex.c:398
0x5b5410 c_lex_one_token
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.c:251
 
0x5d95c2 c_parser_peek_token
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.c:435
0x5d95c2 c_parser_next_token_is
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.h:161
0x5d95c2 c_parser_next_token_is_not
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.h:170
0x5d95c2 c_parser_translation_unit
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.c:1346
0x5d95c2 c_parse_file()
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.c:18183
0x61e992 c_common_parse_file()
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c-family/c-opts.c:1161
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
  CC [M]  fs/xfs/xfs_buf.o
  CC [M]  drivers/usb/host/xhci-pci.o
scripts/Makefile.build:309: recipe for target 'net/l2tp/l2tp_netlink.o' failed
make[7]: *** [net/l2tp/l2tp_netlink.o] Error 1
scripts/Makefile.build:544: recipe for target 'net/l2tp' failed
make[6]: *** [net/l2tp] Error 2
Makefile:1052: recipe for target 'net' failed
make[5]: *** [net] Error 2
make[5]: *** Waiting for unfinished jobs

It happens from time to time, I'm not able to reproduce it reliably, sorry.

[Bug c/88525] gcc thinks that C11 program does not declare anything but it does.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Anders Granlund  ---
This is a defect in the standard.

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[mailboxnotfound at yahoo dot com]

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

--- Comment #5 from john henning  ---
Thank you for the response.  

I wonder if the configure or make process should defend against the possibility
that the host compiler and the compiler that we are building today have
differing defaults for -m32 vs -m64.

Consider below, where the /usr/bin compiler is provided by the OS, and the 8.2
is from a build without bootstrap.   

   $ echo "int main(){}" > tmp.c
   $ /usr/bin/gcc tmp.c
   $ file a.out
   a.out:  ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped, no debugging information
   available
   $
   $ /export/GCC/gcc-8.2.0/bin/gcc tmp.c
   $ file a.out
   a.out:  ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, dynamically linked, not stripped, no debugging
   information available
   $

Notice the differing output when one is silent about -m32 / -m64.
(Note: Although the defaults differ, both the above are perfectly happy to
build the non-default version if you are explicit for -m32 or -m64).


Details for the system compiler:

   $ /usr/bin/gcc -v
   Using built-in specs.
   COLLECT_GCC=/usr/bin/gcc
   COLLECT_LTO_WRAPPER=/usr/gcc/7/lib/gcc/sparcv9-solaris2.11/7.3.0/lto-wrapper
   Target: sparcv9-solaris2.11
   Configured with: 
  
/builds/ulhg/workspace/Solaris_11u4/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/configure
   --prefix=/usr/gcc/7 --mandir=/usr/gcc/7/share/man --bindir=/usr/gcc/7/bin
--sbindir=/usr/gcc/7/sbin 
   --libdir=/usr/gcc/7/lib --infodir=/usr/gcc/7/share/info
--libexecdir=/usr/gcc/7/lib 
   --enable-languages=c,c++,fortran,objc --enable-shared
--enable-initfini-array --disable-rpath 
   --with-system-zlib --with-build-config=no --with-gmp-include=/usr/include
--with-mpfr-include=/usr/include 
   --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as
--with-as=/usr/gnu/bin/as
   --disable-bootstrap 'BOOT_CFLAGS=-g -O2' sparcv9-solaris2.11
   Thread model: posix
   gcc version 7.3.0 (GCC) 
   $ 

And for the 8.2 without bootstrap:

   $ /export/GCC/gcc-8.2.0/bin/gcc -v
   Using built-in specs.
   COLLECT_GCC=/export/GCC/gcc-8.2.0/bin/gcc
  
COLLECT_LTO_WRAPPER=/export/GCC/gcc-8.2.0-try1/bin/../libexec/gcc/sparc-sun-solaris2.11/8.2.0/lto-wrapper
   Target: sparc-sun-solaris2.11
   Configured with: /export/home/johnh/gcc/build/gcc-8.2.0/configure
--enable-languages=c,c++,fortran 
   --enable-lto --without-system-zlib --with-included-gettext --disable-libvtv
--disable-bootstrap 
   --with-gnu-as --with-as=/usr/gnu/bin/as --with-gnu-ld
--with-ld=/usr/gnu/bin/ld 
   --with-pkgversion=johnh-14-Dec-2018 --prefix=/export/GCC/gcc-8.2.0
--with-local-prefix=/export/GCC
   Thread model: posix
   gcc version 8.2.0 (johnh-14-Dec-2018) 
   $

[Bug tree-optimization/88464] AVX-512 vectorization of masked scatter failing with "not suitable for scatter store"

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 18 18:41:26 2018
New Revision: 267239

URL: https://gcc.gnu.org/viewcvs?rev=267239=gcc=rev
Log:
PR target/88464
* config/i386/i386-builtin-types.def
(VOID_FTYPE_PDOUBLE_QI_V8SI_V4DF_INT,
VOID_FTYPE_PFLOAT_QI_V4DI_V8SF_INT,
VOID_FTYPE_PLONGLONG_QI_V8SI_V4DI_INT,
VOID_FTYPE_PINT_QI_V4DI_V8SI_INT,
VOID_FTYPE_PDOUBLE_QI_V4SI_V2DF_INT,
VOID_FTYPE_PFLOAT_QI_V2DI_V4SF_INT,
VOID_FTYPE_PLONGLONG_QI_V4SI_V2DI_INT,
VOID_FTYPE_PINT_QI_V2DI_V4SI_INT): New builtin types.
* config/i386/i386.c (enum ix86_builtins): Add
IX86_BUILTIN_SCATTERALTSIV4DF, IX86_BUILTIN_SCATTERALTDIV8SF,
IX86_BUILTIN_SCATTERALTSIV4DI, IX86_BUILTIN_SCATTERALTDIV8SI,
IX86_BUILTIN_SCATTERALTSIV2DF, IX86_BUILTIN_SCATTERALTDIV4SF,
IX86_BUILTIN_SCATTERALTSIV2DI and IX86_BUILTIN_SCATTERALTDIV4SI.
(ix86_init_mmx_sse_builtins): Fix up names of IX86_BUILTIN_GATHERALT*,
IX86_BUILTIN_GATHER3ALT* and IX86_BUILTIN_SCATTERALT* builtins to
match the IX86_BUILTIN codes.  BuildIX86_BUILTIN_SCATTERALTSIV4DF,
IX86_BUILTIN_SCATTERALTDIV8SF, IX86_BUILTIN_SCATTERALTSIV4DI,
IX86_BUILTIN_SCATTERALTDIV8SI, IX86_BUILTIN_SCATTERALTSIV2DF,
IX86_BUILTIN_SCATTERALTDIV4SF, IX86_BUILTIN_SCATTERALTSIV2DI and
IX86_BUILTIN_SCATTERALTDIV4SI decls.
(ix86_vectorize_builtin_scatter): Expand those new builtins.

* gcc.target/i386/avx512f-pr88464-5.c: New test.
* gcc.target/i386/avx512f-pr88464-6.c: New test.
* gcc.target/i386/avx512f-pr88464-7.c: New test.
* gcc.target/i386/avx512f-pr88464-8.c: New test.
* gcc.target/i386/avx512vl-pr88464-5.c: New test.
* gcc.target/i386/avx512vl-pr88464-6.c: New test.
* gcc.target/i386/avx512vl-pr88464-7.c: New test.
* gcc.target/i386/avx512vl-pr88464-8.c: New test.
* gcc.target/i386/avx512vl-pr88464-9.c: New test.
* gcc.target/i386/avx512vl-pr88464-10.c: New test.
* gcc.target/i386/avx512vl-pr88464-11.c: New test.
* gcc.target/i386/avx512vl-pr88464-12.c: New test.
* gcc.target/i386/avx512vl-pr88464-13.c: New test.
* gcc.target/i386/avx512vl-pr88464-14.c: New test.
* gcc.target/i386/avx512vl-pr88464-15.c: New test.
* gcc.target/i386/avx512vl-pr88464-16.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr88464-5.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr88464-6.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr88464-7.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr88464-8.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-10.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-11.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-12.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-13.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-14.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-15.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-16.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-5.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-6.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-7.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-8.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88464-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-builtin-types.def
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/88542] Optimize symmetric range check

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-18
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

[Bug target/88541] VPCLMULQDQ 256-bit inline function unavailable with optimization but without enabled AVX512VL support

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=clmul=641,675,674
says for _mm256_clmulepi64_epi128 that it is AVX512VL + VPCLMULQDQ.  So why do
you think it is incorrect?

[Bug c++/84080] [6/7/8 Regression] the compiler crashes when compiling the following sample file

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||archivio.rp at gmail dot com

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

[Bug c++/88543] ICE template function specialization with auto returning type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[Bug fortran/79524] [7/8/9 Regression] valgrind error for gcc/testsuite/gfortran.dg/fimplicit_none_2.f90

[dominiq at lps dot ens.fr]

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

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

[Bug fortran/81531] Multiple Invalid reads seen by valgrind on an invalid test-case

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Duplicate of pr79524.

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

[Bug other/86656] Issues found with -fsanitize=address

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 81531, which changed state.

Bug 81531 Summary: Multiple Invalid reads seen by valgrind on an invalid 
test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81531

   What|Removed |Added

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

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  ---
> Does this do it for you?

Jakub's patch regtested cleanly. I'll test yours later this evening.

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Comment on attachment 45258
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45258
A slightly more elaborate version of Jakub's patch

So, what will happen if there is more than one INQUIRY reference?  The first
iteration will set *newp to some expression and the next iteration will
overwrite (memory leak) it with something different, so the last one wins?

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #13 from Paul Thomas  ---
Created attachment 45258
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45258=edit
A slightly more elaborate version of Jakub's patch

Dominique,

Does this do it for you?

Cheers

Paul

[Bug rtl-optimization/84101] [7/8/9 Regression] -O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
But that is exactly the kind of thing lower-subreg is supposed to do?

[Bug rtl-optimization/84101] [7/8/9 Regression] -O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #6)
> I think subreg should deal with this.  What do you mean "there aren't
> any half of TImode subregs"?  insn 10 has it split at the start, and
> insn 18 at the end wants it split, too.

By that I mean that there aren't any (subreg:DI (reg:TI) [08]) destinations or
similar.  Admittedly lower-subreg also handles shifts, and a few others, but
not vec_concat etc.
Plus
V2DI move: original cost 4, split cost 4 * 2
so it decides not to do anything about V2DImode (generally the right thing).

So, we'd need to pattern recognize a vec_concat from scalar modes (integral
only) and the result used (single use) in a subreg to twice that big integral
mode and
handle it as if it was setting the two halves of the wider reg.

[Bug c++/88543] New: ICE template function specialization with auto returning tipe

[archivio.rp at gmail dot com]

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

Bug ID: 88543
   Summary: ICE template function specialization with auto
returning tipe
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: archivio.rp at gmail dot com
  Target Milestone: ---

I was simply testing the templates specialization for a function in order to
convert a string into a number. The following code should produce an error,
while the compiler crashes with a segmentation error:

#include 
#include 
#include 

using namespace std;


template
Type to_number(const string& str) {
Type v;
stringstream buff(str);
buff >> v;
return v;
}

// Specializations
template<> int to_number(const string& str) { return stoi(str); }
template<> auto to_number(const string& str) { return stof(str); }
...

as shown here:
---
toNumber.cc: In function ‘Type to_number(const string&) [with Type = auto]’:
toNumber.cc:18:66: internal compiler error: Segmentation fault
 template<> auto to_number(const string& str) { return stof(str); }
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
---

I have compiled the code with different versions:

gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
gcc version 7.4.0 (Debian 7.4.0-1)
gcc version 7.3.0 (Windows - 10 + Cynwin)
gcc version 8.2.0 (Debian 8.2.0-12)

and only the last one works correctly.

[Bug middle-end/88542] Optimize symmetric range check

[bugzi...@poradnik-webmastera.com]

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

--- Comment #2 from Daniel Fruzynski  ---
No, code with -ffast-math is the same.

BTW, fabs(NaN) is NaN, so result is the same as before (false).

[Bug rtl-optimization/84101] [7/8/9 Regression] -O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
#c4 has another thing:
struct S { float a, b; };
struct S
foo (float x)
{
  return (struct S) { x, x };
}
where we generate bad code mainly because we have DImode as DECL_MODE of the
RESULT_DECL, even when it is a structure containing two floats.  Not sure what
we'd get e.g. if we treated it like V2SFmode instead, but that is problematic
because it is MMX-ish mode, or if it would be possible to combine it into a
vec_concatv2sf somehow.  Though, that should be really tracked in a different
PR.

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
> And here is a massive clue which I had missed until Rainer pointed it out:
> 
> $ file stage*gcc/dwarf2out.o
> stage1-gcc/dwarf2out.o: ELF 64-bit MSB relocatable SPARCV9 Version 1
> stage2-gcc/dwarf2out.o: ELF 32-bit MSB relocatable SPARC32PLUS Version 1,
> V8+ Required
> stage3-gcc/dwarf2out.o: ELF 32-bit MSB relocatable SPARC32PLUS Version 1,
> V8+ Required

Indeed, you're trying to bootstrap a cross-compiler, this simply cannot work.

The 32-bit and the 64-bit configuration are 2 distinct native platforms so they
cannot be cross bootstrapped; use a 32-bit compiler to bootstrap the 32-bit
one.

[Bug rtl-optimization/84101] [7/8/9 Regression] -O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
I think subreg should deal with this.  What do you mean "there aren't
any half of TImode subregs"?  insn 10 has it split at the start, and
insn 18 at the end wants it split, too.

[Bug middle-end/88542] Optimize symmetric range check

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
I think it depends on if max is a nan or not.  Does -ffast-math make it work?

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 45257 [details]
> gcc9-pr87881.patch
> 
> Untested fix.  simplify_const_ref is similar, but actually iterates p->ref
> and thus properly stops immediately after handling the REF_INQUIRY,
> returning true,
> because it has no further refs.  simplify_ref_chain is weird in that it is
> passed two arguments, one ref and one p, where in all callers do pass p->ref
> and  to those arguments, so if for REF_INQUIRY we replace *p with
> something different, all the references are freed and we need to stop
> iterating.

Hi Jakub,

That's absolutely right - thanks!

I have modified find_inquiry_ref to allow for the possibility of there being
two inquiry part references and return true in simplify ref_chain.

It's just now regtesting.

Cheers

Paul

[Bug c/88542] New: Optimize symmetric range check

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 88542
   Summary: Optimize symmetric range check
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

[code]
#include 

bool test1(double d, double max)
{
return (d < max) && (d > -max);
}

bool test2(double d, double max)
{
return fabs(d) < max;
}
[/code]

When code checks if some number d is in (or outside of) symmetric range like
(-max, max), code from test1() can be replaced with one from test2(). This of
course assumes that expression does not produce any side effects. This can be
done nicely for floating point numbers stored in IEEE format, what leads to
faster code:

[asm]
test1(double, double):
vcomisd xmm1, xmm0
jbe .L6
vxorpd  xmm1, xmm1, XMMWORD PTR .LC0[rip]
vcomisd xmm0, xmm1
setaal
ret
.L6:
xor eax, eax
ret
test2(double, double):
vandpd  xmm0, xmm0, XMMWORD PTR .LC1[rip]
vcomisd xmm1, xmm0
setaal
ret
[/asm]

For integer types stored in two's complement format similar change gives slower
code. However on platforms which uses different integer format with dedicated
sign bit this optimizations may be beneficial.

[Bug rtl-optimization/84101] [7/8/9 Regression] -O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I actually don't think the right way to fix this is not to SLP vectorize it,
but rather be able to undo it during RTL optimizations.
The user could have written it that way already, e.g. as:
#include 

struct S { long long a, b; };
typedef long long v2di __attribute__((vector_size (16)));

struct S
foo (int x)
{
  struct S p;
  v2di q = { x << 1, x >> 1 };
  memcpy (, , sizeof (p));
  return p;
}

or similar.

We have:
(insn 10 9 11 2 (set (reg:V2DI 92)
(vec_concat:V2DI (reg:DI 94)
(reg:DI 96))) "pr84101-3.c":8:8 4110 {vec_concatv2di}
 (nil))
(insn 11 10 12 2 (set (reg/v:TI 89 [ p ])
(subreg:TI (reg:V2DI 92) 0)) "pr84101-3.c":9:3 65 {*movti_internal}
 (nil))
(insn 12 11 13 2 (set (reg:TI 88 [ D.1915 ])
(reg/v:TI 89 [ p ])) "pr84101-3.c":10:10 65 {*movti_internal}
 (nil))
(insn 13 12 14 2 (clobber (reg/v:TI 89 [ p ])) -1
 (nil))
(insn 14 13 18 2 (set (reg:TI 90 [  ])
(reg:TI 88 [ D.1915 ])) "pr84101-3.c":10:10 65 {*movti_internal}
 (nil))
(insn 18 14 19 2 (set (reg/i:TI 0 ax)
(reg:TI 90 [  ])) "pr84101-3.c":11:1 65 {*movti_internal}
 (nil))
(insn 19 18 0 2 (use (reg/i:TI 0 ax)) "pr84101-3.c":11:1 -1
 (nil))
and because there aren't any half of TImode subregs, the subreg1 pass does
nothing.  Combiner already sees
(insn 10 9 18 2 (set (reg:V2DI 92)
(vec_concat:V2DI (reg:DI 94)
(reg:DI 96))) "pr84101-3.c":8:8 4110 {vec_concatv2di}
 (expr_list:REG_DEAD (reg:DI 96)
(expr_list:REG_DEAD (reg:DI 94)
(nil
(insn 18 10 19 2 (set (reg/i:TI 0 ax)
(subreg:TI (reg:V2DI 92) 0)) "pr84101-3.c":11:1 65 {*movti_internal}
 (expr_list:REG_DEAD (reg:V2DI 92)
(nil)))
but (because of the hard register destination?) decides not to combine anything
into insn 18.  The RA isn't able to cope with this because V2DImode is not
HARD_REGNO_MODE_OK in GPRs (but TImode is).
So, where do you think we should deal with it?

[Bug target/88541] New: VPCLMULQDQ 256-bit inline function unavailable with optimization but without enabled AVX512VL support

[jbeulich at novell dot com]

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

Bug ID: 88541
   Summary: VPCLMULQDQ 256-bit inline function unavailable with
optimization but without enabled AVX512VL support
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbeulich at novell dot com
  Target Milestone: ---

As per the specification, and just like is the case for VAES, it should be
usable with just AVX (or perhaps better AVX2) support enabled. The function is
preceded by

#pragma GCC target("vpclmulqdq,avx512vl")

though. Perhaps simply a copy-and-paste mistake from the 128-bit variant (when
that was still there).

[Bug c/88540] New: Issues with vectorization of min/max operations

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 88540
   Summary: Issues with vectorization of min/max operations
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

1st issue:

[code]
#define SIZE 2

void test(double* __restrict d1, double* __restrict d2, double* __restrict d3)
{
for (int n = 0; n < SIZE; ++n)
{
d3[n] = d1[n] < d2[n] ? d1[n] : d2[n];
}
}
[code]

When this is compiled with for SSE2, gcc produces non vectorized code:

[asm]
test(double*, double*, double*):
vmovsd  xmm0, QWORD PTR [rdi]
vminsd  xmm0, xmm0, QWORD PTR [rsi]
vmovsd  QWORD PTR [rdx], xmm0
vmovsd  xmm0, QWORD PTR [rdi+8]
vminsd  xmm0, xmm0, QWORD PTR [rsi+8]
vmovsd  QWORD PTR [rdx+8], xmm0
ret
[/asm]

When SIZE is changed to 3 or greater, code gets vectorized properly. I thought
that this may be some workaround for old CPU which was slower there, but this
also happen when compiling with "-O3 -march=skylake". I also checked with SIZE
6, and got 1 AVX op and 2 scalar SSE ones. Looks that this is an off-by-one
bug.

The same happen for code with other relational operators (>, <=, >=).

2nd issue: when compiling for AVX512, gcc does not use new instructions which
use ZMM registers, it still generates code for YMM ones.

[Bug c++/88538] parse error with class nontype template parameter

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  It's never worked, not a regression.

[Bug tree-optimization/84362] [7/8/9 Regression] Auto-vectorization regression when accessing member variable through getter/accessor

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The MEM_REF is in there because we first create a _ZNK3vec4sizeEv.isra.0 clone
which takes unsigned int argument and just passes it through.
So, does LIM need to fold the MEM_EXPRs in a similar way to how PRE folds them
to figure out it is the same thing as v.size?

[Bug libstdc++/71044] Optimize std::filesystem implementation

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> Several member functions of path construct a path from their argument, but
> could be done without any allocations, e.g. path::compare(string_view)

This is done in r267235.

[Bug target/88213] ICE in change_address_1, at emit-rtl.c:2286

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-18
 Ever confirmed|0   |1

--- Comment #4 from Segher Boessenkool  ---
Confirmed now.

[Bug target/88213] ICE in change_address_1, at emit-rtl.c:2286

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Godbolt now has the C compiler frontend as well, without -xc shenanigans, fwiw.

[Bug debug/88534] [9 Regression] internal compiler error: in tree_add_const_value_attribute, at dwarf2out.c:20246

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
A short test from Bug 88537

struct pair {
unsigned a;
unsigned b;
constexpr pair(unsigned _a, unsigned _b) noexcept: a{_a}, b{_b} { }
};

template  void fnc() {

}

void f() {
fnc();
}

[Bug c++/88537] class nontype template parameter debug mode crash in dwarf2out.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
This is a dup, but the testcase is very nice, so let's use it.

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

[Bug debug/88534] [9 Regression] internal compiler error: in tree_add_const_value_attribute, at dwarf2out.c:20246

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||hanicka at hanicka dot net

--- Comment #5 from Marek Polacek  ---
*** Bug 88537 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/84362] [7/8/9 Regression] Auto-vectorization regression when accessing member variable through getter/accessor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This broke with r236440.

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[mailboxnotfound at yahoo dot com]

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

--- Comment #3 from john henning  ---
Rainer points out that a key here seems to be that the host system compiler had
been configured with sparcv9-solaris2.11 but the 8.2.0 build did not request
the same.  In my case, the host system compiler was 7.3; Rainer reproduced with
7.4.0.

And here is a massive clue which I had missed until Rainer pointed it out:

$ file stage*gcc/dwarf2out.o
stage1-gcc/dwarf2out.o: ELF 64-bit MSB relocatable SPARCV9 Version 1
stage2-gcc/dwarf2out.o: ELF 32-bit MSB relocatable SPARC32PLUS Version 1, V8+
Required
stage3-gcc/dwarf2out.o: ELF 32-bit MSB relocatable SPARC32PLUS Version 1, V8+
Required
$

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

Untested fix.  simplify_const_ref is similar, but actually iterates p->ref and
thus properly stops immediately after handling the REF_INQUIRY, returning true,
because it has no further refs.  simplify_ref_chain is weird in that it is
passed two arguments, one ref and one p, where in all callers do pass p->ref
and  to those arguments, so if for REF_INQUIRY we replace *p with something
different, all the references are freed and we need to stop iterating.

[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features

[manfred99 at gmx dot ch]

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

--- Comment #7 from Manfred Schwarb  ---
Thanks Jakub for the debug hint, and thanks Dominique for finding the
duplicate.
Indeed, my backtrace also points to simplify_ref_chain:

# gdb --quiet `/usr/local/gcc-trunk-32bit/bin/gcc -print-prog-name=f951`
Reading symbols from
/usr/local/gcc-trunk-32bit/libexec/gcc/i686-linux/9.0.0/f951...done.
(gdb) run /tmp/gcc-trunk-source/gcc/gcc/testsuite/gfortran.dg/pr87945_1.f90
Starting program: /usr/local/gcc-trunk-32bit/libexec/gcc/i686-linux/9.0.0/f951
/tmp/gcc-trunk-source/gcc/gcc/testsuite/gfortran.dg/pr87945_1.f90
/tmp/gcc-trunk-source/gcc/gcc/testsuite/gfortran.dg/pr87945_1.f90:5:13:

5 |data a%len /1/   ! { dg-error "parameter cannot appear in" }
  | 1
Error: Inquiry parameter cannot appear in a data-stmt-object-list at (1)

Program received signal SIGSEGV, Segmentation fault.
0x083debd5 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
414   gcc_assert (lo < hi);
(gdb) bt
#0  0x083debd5 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#1  0x083de5bc in gfc_simplify_expr(gfc_expr*, int) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#2  0x08435f2b in gfc_match_varspec(gfc_expr*, int, bool, bool) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#3  0x08436719 in match_variable(gfc_expr**, int, int) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#4  0x083c1fa7 in var_element(gfc_data_variable*) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#5  0x083c3e98 in gfc_match_data() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#6  0x08428b4a in match_word () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#7  0x0842a5ea in decode_statement() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#8  0x0842d0a5 in next_statement() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#9  0x0842e9ff in parse_spec(gfc_statement) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#10 0x08430eaa in parse_progunit(gfc_statement) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#11 0x08432153 in gfc_parse_file() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#12 0x08479649 in gfc_be_parse_file() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#13 0x0897ce7d in compile_file() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#14 0x083a01cf in toplev::main(int, char**) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#15 0x083a3c31 in main () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414

[Bug demangler/88539] A memory leak issue was discovered in cplus-dem.c

[wcventure at 126 dot com]

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

--- Comment #1 from Cheng Wen  ---
Created attachment 45256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45256=edit
POC2

[Bug demangler/88539] New: A memory leak issue was discovered in cplus-dem.c

[wcventure at 126 dot com]

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

Bug ID: 88539
   Summary: A memory leak issue was discovered in cplus-dem.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wcventure at 126 dot com
  Target Milestone: ---

Created attachment 45255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45255=edit
POC1

Hi there,

A memory leak issue was discovered in cplus-dem.c, as distributed in GNU
Binutils 2.31. 
In demangle_template function in cplus-dem.c, the are many heap allocations.
But these heap allocations didn't deallocate in the end. 

Please use the "./cxxfilt -t < $POC" to reproduce the bug.
To reproduce this bug. You need to build bintuils-2.31 with ASAN, setting
following Command:

> export ASAN_OPTIONS=abort_on_error=1:symbolize=1:detect_leaks=1


The Leak Sanitizer dumps the stack trace as follows:

> =
> ==16096==ERROR: LeakSanitizer: detected memory leaks
> 
> Direct leak of 8 byte(s) in 1 object(s) allocated from:
> #0 0x7f1c50822602 in malloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
> #1 0x8247c9 in xmalloc xmalloc.c:147
> #2 0x7cf501 in demangle_template cplus-dem.c:2228
> #3 0x7cb3a5 in demangle_signature cplus-dem.c:1691
> #4 0x7d39fd in iterate_demangle_function cplus-dem.c:2743
> #5 0x7d5e9e in demangle_prefix cplus-dem.c:2971
> #6 0x7c6dfa in internal_cplus_demangle cplus-dem.c:1253
> #7 0x7c4464 in cplus_demangle cplus-dem.c:918
> #8 0x4033b3 in demangle_it binutils-2.31_ASAN/binutils/cxxfilt.c:62
> #9 0x403f1f in main binutils-2.31_ASAN/binutils/cxxfilt.c:276
> #10 0x7f1c4f4cf82f in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
> 
> Indirect leak of 2 byte(s) in 1 object(s) allocated from:
> #0 0x7f1c50822602 in malloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
> #1 0x8247c9 in xmalloc xmalloc.c:147
> #2 0x7d0439 in demangle_template cplus-dem.c:2327
> #3 0x7cb3a5 in demangle_signature cplus-dem.c:1691
> #4 0x7d39fd in iterate_demangle_function cplus-dem.c:2743
> #5 0x7d5e9e in demangle_prefix cplus-dem.c:2971
> #6 0x7c6dfa in internal_cplus_demangle cplus-dem.c:1253
> #7 0x7c4464 in cplus_demangle cplus-dem.c:918
> #8 0x4033b3 in demangle_it binutils-2.31_ASAN/binutils/cxxfilt.c:62
> #9 0x403f1f in main binutils-2.31_ASAN/binutils/cxxfilt.c:276
> #10 0x7f1c4f4cf82f in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
> 
> SUMMARY: AddressSanitizer: 10 byte(s) leaked in 2 allocation(s).

[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Indeed:
==8241== Invalid read of size 8
==8241==at 0x873E24: simplify_ref_chain(gfc_ref*, int, gfc_expr**)
(expr.c:1943)
==8241==by 0x8744C0: gfc_simplify_expr(gfc_expr*, int) (expr.c:2164)
==8241==by 0x8F366B: gfc_match_varspec(gfc_expr*, int, bool, bool)
(primary.c:2287)
==8241==by 0x8F756B: match_variable(gfc_expr**, int, int) (primary.c:3971)
==8241==by 0x8F75BC: gfc_match_variable(gfc_expr**, int) (primary.c:3986)
==8241==by 0x84C5E6: var_element(gfc_data_variable*) (decl.c:280)
==8241==by 0x84C794: top_var_list(gfc_data*) (decl.c:332)
==8241==by 0x84CFD1: gfc_match_data() (decl.c:617)
==8241==by 0x8E2361: match_word(char const*, match (*)(), locus*)
(parse.c:65)
==8241==by 0x8E360C: decode_statement() (parse.c:468)
==8241==by 0x8E7A6B: next_free() (parse.c:1235)
==8241==by 0x8E8028: next_statement() (parse.c:1467)
==8241==  Address 0x6351ba8 is 728 bytes inside a block of size 736 free'd
==8241==at 0x4C2DD18: free (vg_replace_malloc.c:530)
==8241==by 0x870ACB: gfc_free_ref_list(gfc_ref*) (expr.c:606)
==8241==by 0x870869: free_expr0(gfc_expr*) (expr.c:505)
==8241==by 0x870AF8: gfc_replace_expr(gfc_expr*, gfc_expr*) (expr.c:616)
==8241==by 0x873DF7: simplify_ref_chain(gfc_ref*, int, gfc_expr**)
(expr.c:1970)
==8241==by 0x8744C0: gfc_simplify_expr(gfc_expr*, int) (expr.c:2164)
==8241==by 0x8F366B: gfc_match_varspec(gfc_expr*, int, bool, bool)
(primary.c:2287)
==8241==by 0x8F756B: match_variable(gfc_expr**, int, int) (primary.c:3971)
==8241==by 0x8F75BC: gfc_match_variable(gfc_expr**, int) (primary.c:3986)
==8241==by 0x84C5E6: var_element(gfc_data_variable*) (decl.c:280)
==8241==by 0x84C794: top_var_list(gfc_data*) (decl.c:332)
==8241==by 0x84CFD1: gfc_match_data() (decl.c:617)
==8241==  Block was alloc'd at
==8241==at 0x4C2EA1E: calloc (vg_replace_malloc.c:711)
==8241==by 0x2149D20: xcalloc (xmalloc.c:162)
==8241==by 0x8F288F: is_inquiry_ref(char const*, gfc_ref**)
(primary.c:1964)
==8241==by 0x8F3292: gfc_match_varspec(gfc_expr*, int, bool, bool)
(primary.c:2199)
==8241==by 0x8F756B: match_variable(gfc_expr**, int, int) (primary.c:3971)
==8241==by 0x8F75BC: gfc_match_variable(gfc_expr**, int) (primary.c:3986)
==8241==by 0x84C5E6: var_element(gfc_data_variable*) (decl.c:280)
==8241==by 0x84C794: top_var_list(gfc_data*) (decl.c:332)
==8241==by 0x84CFD1: gfc_match_data() (decl.c:617)
==8241==by 0x8E2361: match_word(char const*, match (*)(), locus*)
(parse.c:65)
==8241==by 0x8E360C: decode_statement() (parse.c:468)
==8241==by 0x8E7A6B: next_free() (parse.c:1235)

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[mailboxnotfound at yahoo dot com]

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

john henning  changed:

   What|Removed |Added

 CC||mailboxnotfound at yahoo dot 
com

--- Comment #2 from john henning  ---
Thank you Rainer for reproducing this and filing the bug.  As the originator of
the complaint, I (john henning) add a few more points. 

All of my attempts were with gcc 8.2.0; failures were observed on 2 different
SPARC Solaris 11 systems, one with 11.4 and one with 11.5.

(1) dwarf2out.o is the only object that differs.

(2) output_file_names is the only routine within dwarf2out.o to have a
differing size (according to nm)

(3) An early difference (possibly the first) seems to be the code that is
generated for dwarf2out.c line 12301

   $ cat -n ../gcc-8.2.0/gcc/dwarf2out.c | head -12312 | tail -17 
12296  /* If there are more than 65536 directories, we have to use 
12297 DW_FORM_udata, DW_FORM_data2 can't refer to them. 
12298 Otherwise, compute what space would occupy if all the indexes 
12299 used DW_FORM_udata - sum - and compare that to how large would 
12300 be DW_FORM_data2 encoding, and pick the more efficient one.  */ 
12301  else if (ndirs + idx_offset <= 65536) 
12302{ 
12303  unsigned HOST_WIDE_INT sum = 1; 
12304  for (i = 0; i < numfiles; i++) 
12305{ 
12306  int file_idx = backmap[i]; 
12307  int dir_idx = dirs[files[file_idx].dir_idx].dir_idx; 
12308  sum += size_of_uleb128 (dir_idx); 
12309} 
12310  if (sum >= HOST_WIDE_INT_UC (2) * (numfiles + 1)) 
12311idx_form = DW_FORM_data2; 
12312   

Here are the first 40 instructions for that line, according to gdb
(shrunk/excerpted to fit a small number of columns for ease of side-by-side
viewing):

$ gdb -q stage2-gcc/lto1  $ gdb -q stage3-gcc/lto1
. break dwarf2out.c:12301 . break dwarf2out.c:12301
Breakpoint 1 at 0x435fb8: fileBreakpoint 1 at 0x435fb0: file 
gcc-8.2.0/gcc/dwarf2out.c, line 12301 gcc-8.2.0/gcc/dwarf2out.c, line 12301
. x/40i 0x435fb8  . x/40i 0x435fb0
 sethi  %hi(0x1), %g1  sethi  %hi(0x1), %g1
 cmp  %l0, %g1 cmp  %l0, %g1
 bg  %icc, 0x436164  smul  %g1, 0x14, %g1
 sra  %o1, 0x1f, %o0   add  %i2, %g1, %g1
 addcc  %l1, %o0, %l1  ld  [ %g1 + 0x10 ], %g1
 sra  %o0, 0x1f, %i2   smul  %g1, 0x14, %g1
 add  %l7, 4, %l7  add  %l4, %g1, %g1
 addc  %l0, %i2, %l0   ld  [ %g1 + 0x10 ], %o1
 cmp  %l7, %l5 call  0x40af94 

[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
Duplicate of pr87881. Not really a duplicate.

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

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||manfred99 at gmx dot ch

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

[Bug c++/88538] New: parse error with class nontype template parameter

[hanicka at hanicka dot net]

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

Bug ID: 88538
   Summary: parse error with class nontype template parameter
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hanicka at hanicka dot net
  Target Milestone: ---

Created attachment 45254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45254=edit
parser error on line 12

Compiler should be able to parse attached code in C++2a mode with Class Nontype
Template Arguments, instead it's giving me error "parse error in template
argument list"

Using built-in specs.
COLLECT_GCC=g++-HEAD
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/HEAD-0edf78b/libexec/gcc/x86_64-apple-darwin18.2.0/9.0.0/lto-wrapper
Target: x86_64-apple-darwin18.2.0
Configured with: ../configure --build=x86_64-apple-darwin18.2.0
--prefix=/usr/local/Cellar/gcc/HEAD-0edf78b
--libdir=/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran,d
--program-suffix=-HEAD --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC HEAD-0edf78b'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
gcc version 9.0.0 20181212 (experimental) (Homebrew GCC HEAD-0edf78b) 
COLLECT_GCC_OPTIONS='-std=c++2a' '-v' '-mmacosx-version-min=10.14.0'
'-asm_macosx_version_min=10.14' '-shared-libgcc' '-mtune=core2'

/usr/local/Cellar/gcc/HEAD-0edf78b/libexec/gcc/x86_64-apple-darwin18.2.0/9.0.0/cc1plus
-quiet -v -D__DYNAMIC__ gcc9parse-error.cpp -fPIC -quiet -dumpbase
gcc9parse-error.cpp -mmacosx-version-min=10.14.0 -mtune=core2 -auxbase
gcc9parse-error -std=c++2a -version -o
/var/folders/dv/kkg4z5lj0g52m8q8mm0wk6rwgn/T//ccoEsrny.s
GNU C++17 (Homebrew GCC HEAD-0edf78b) version 9.0.0 20181212 (experimental)
(x86_64-apple-darwin18.2.0)
compiled by GNU C version 9.0.0 20181212 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory
"/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../../../../../x86_64-apple-darwin18.2.0/include"
ignoring nonexistent directory
"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../../../../../include/c++/9.0.0

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../../../../../include/c++/9.0.0/x86_64-apple-darwin18.2.0

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../../../../../include/c++/9.0.0/backward

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/include

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
End of search list.
GNU C++17 (Homebrew GCC HEAD-0edf78b) version 9.0.0 20181212 (experimental)
(x86_64-apple-darwin18.2.0)
compiled by GNU C version 9.0.0 20181212 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6936071dc75afe7297cddcec7cf6ee71
gcc9parse-error.cpp: In function 'void f()':
gcc9parse-error.cpp:12:5: error: parse error in template argument list
   12 | fnc<{10,20}>();
  | ^~~~
gcc9parse-error.cpp:12:9: error: expected ';' before '{' token
   12 | fnc<{10,20}>();
  | ^
  | ;
gcc9parse-error.cpp:12:5: error: statement cannot resolve address of overloaded
function
   12 | fnc<{10,20}>();
  | ^~~~
gcc9parse-error.cpp:12:16: error: expected primary-expression before '>' token
   12 | fnc<{10,20}>();
  |^
gcc9parse-error.cpp:12:18: error: expected primary-expression before ')' token
   12 | fnc<{10,20}>();
  |  ^

[Bug c++/88537] New: class nontype template parameter debug mode crash in dwarf2out.c

[hanicka at hanicka dot net]

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

Bug ID: 88537
   Summary: class nontype template parameter debug mode crash in
dwarf2out.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hanicka at hanicka dot net
  Target Milestone: ---

Created attachment 45253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45253=edit
minimal example which will crash with enabled debug symbols

I found that gcc is crashing in

gcc9crash.cpp:13:1: internal compiler error: in tree_add_const_value_attribute,
at dwarf2out.c:20243

when I tried to emit debug symbols in a program with a "class nontype template
parameter"

Crashing code is attached. You can see it also here:
https://gcc.godbolt.org/z/NOkj54

Compilation with:

g++-HEAD gcc9crash.cpp -std=c++2a -ggdb -v

Using built-in specs.
COLLECT_GCC=g++-HEAD
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/HEAD-0edf78b/libexec/gcc/x86_64-apple-darwin18.2.0/9.0.0/lto-wrapper
Target: x86_64-apple-darwin18.2.0
Configured with: ../configure --build=x86_64-apple-darwin18.2.0
--prefix=/usr/local/Cellar/gcc/HEAD-0edf78b
--libdir=/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran,d
--program-suffix=-HEAD --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC HEAD-0edf78b'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
gcc version 9.0.0 20181212 (experimental) (Homebrew GCC HEAD-0edf78b) 
COLLECT_GCC_OPTIONS='-std=c++2a' '-ggdb' '-v' '-mmacosx-version-min=10.14.0'
'-asm_macosx_version_min=10.14' '-shared-libgcc' '-mtune=core2'

/usr/local/Cellar/gcc/HEAD-0edf78b/libexec/gcc/x86_64-apple-darwin18.2.0/9.0.0/cc1plus
-quiet -v -D__DYNAMIC__ gcc9crash.cpp -fPIC -quiet -dumpbase gcc9crash.cpp
-mmacosx-version-min=10.14.0 -mtune=core2 -auxbase gcc9crash -ggdb -std=c++2a
-version -o /var/folders/dv/kkg4z5lj0g52m8q8mm0wk6rwgn/T//ccQG2L7F.s
GNU C++17 (Homebrew GCC HEAD-0edf78b) version 9.0.0 20181212 (experimental)
(x86_64-apple-darwin18.2.0)
compiled by GNU C version 9.0.0 20181212 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory
"/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../../../../../x86_64-apple-darwin18.2.0/include"
ignoring nonexistent directory
"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../../../../../include/c++/9.0.0

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../../../../../include/c++/9.0.0/x86_64-apple-darwin18.2.0

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../../../../../include/c++/9.0.0/backward

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/include

/usr/local/Cellar/gcc/HEAD-0edf78b/lib/gcc/HEAD/gcc/x86_64-apple-darwin18.2.0/9.0.0/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
End of search list.
GNU C++17 (Homebrew GCC HEAD-0edf78b) version 9.0.0 20181212 (experimental)
(x86_64-apple-darwin18.2.0)
compiled by GNU C version 9.0.0 20181212 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6936071dc75afe7297cddcec7cf6ee71
gcc9crash.cpp:13:1: internal compiler error: in tree_add_const_value_attribute,
at dwarf2out.c:20243
   13 | }
  | ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Created attachment 45252
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45252=edit
patch

Even though the patch doesn't hoist the invariant condition the speed is back
with it.

Can you verify that?

[Bug tree-optimization/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
OK, so I can add heuristic that avoids copying BBs with exit conditions based
on non-IVs/non-invariants but that doesn't fix this testcase since the
fourth condition in the loop is based on the load from 'ja':

do j=1,n! Outer loop j: columns of A
!CDIR ALTCODE=LOOPCNT
!CDIR NODEP
!DIR$ IVDEP
  do k = ia(j), ia(j+1)-1   ! Inner loop i: rows of (sparse) A
i = ja(k)   ! (the i's are distinct for different j's)
y(i) = y(i) + a(k) * x(j)
  end do
end do

so we copy the header check for the ia(j), ia(j+1)-1 range (together with
its bounds checks) plus the bounds check for ja(k) but _not_ the bounds
check on 'i' which is strictly ordered before the invariant bounds check
for j on x(j).

I could relax the heuristic further but I think changing
gcc.dg/tree-ssa/copy-headers-5.c to

int is_sorted(int *a, int n)
{
  for (int i = 0; i < n - 1; i++)
if (a[i] > 0)
  return 0;
  return 1;
}

shouldn't rotate the loop beyond hoisting the initial 0 < n - 1 check.

But we are now asking for exactly that to be able to hoist a further down
conditional that is invariant by means of rotating the loop.

That said, I have a patch restoring originally intended behavior (albeit
in a somewhat awkward way).

[Bug c++/87934] [8/9 regression] struct with NSDMI of enum makes initialization a non-constant expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
cxx_eval_constant_expression doesn't fold this, because {.bar=BAR} CONSTRUCTOR
is TREE_CONSTANT, but not reduced_constant_expression_p, as it contains the
CONST_DECL in it and we have:
4684  if (TREE_CONSTANT (t))
4685{
4686  /* Don't re-process a constant CONSTRUCTOR, but do fold it to
4687 VECTOR_CST if applicable.  */
4688  verify_constructor_flags (t);
4689  if (TREE_CONSTANT (t))
4690return fold (t);
4691}
4692  r = cxx_eval_bare_aggregate (ctx, t, lval,
4693   non_constant_p, overflow_p);
So, to fix this, we either need to make sure that the CONSTRUCTOR is cp_folded
when it is being created, or to check above reduced_constant_expression_p
instead of in addition to TREE_CONSTANT, or change fold in fold-const.c, so
that if it sees CONST_DECLs in there, they are folded too.  But it would need
to do it recursively.

To me changing cxx_eval_const_expression looks easiest, but dunno if it is
correct thing to do.

[Bug rtl-optimization/87273] [8/9 Regression] ICE in merge_fences, at sel-sched-ir.c:708

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Andrey, can you please have a look?

[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I don't see these in my i686-linux bootstraps either (Fedora distro).
Can you run gdb on it?
gdb `gcc -print-prog-name=f951` -quiet pr87945_1.f90
run
bt
?

[Bug tree-optimization/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply

[rguenth at gcc dot gnu.org]

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

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  ---
So we do rely on loop header copying (our single "loop rotation" pass) to hoist
invariant conditions out of loops.

As said determining whether a condition is invariant or not is a bit awkward
at the point of CH.  But reverting the revision in question and
re-instantiating the effect on the added testcase by adding heuristic to
should_duplicate_loop_header_p should hopefully work.

[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features

[manfred99 at gmx dot ch]

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

--- Comment #3 from Manfred Schwarb  ---
BTW, the build logs (*README.txt) are here:
http://gfortran.meteodat.ch/download/i686/nightlies/

[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features

[manfred99 at gmx dot ch]

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

--- Comment #2 from Manfred Schwarb  ---
./gfortran -v output:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-trunk-32bit/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk-32bit/bin/../libexec/gcc/i686-linux/9.0.0/lto-wrapper
Target: i686-linux
Configured with: ../gcc-trunk-source/gcc/configure
--enable-languages=c,c++,fortran --enable-checking=yes,extra
--disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=gold --prefix=/usr/local/gcc-trunk-32bit i686-linux
Thread model: posix
gcc version 9.0.0 20181218 (experimental) [trunk revision 267225] (GCC) 

This build of the 32bit compiler is made in an OpenSuse 11.4 x86_64 environment
using glibc 2.11.3

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
So that means host gcc 7 when defaulting to -m64 miscompiles stage1 in a way
that it miscompiles stage2 but that miscompilation does not affect stage3. 
That'll be "interesting" to track down :/

[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Target Milestone|--- |9.0
Summary|i686 testsuite errors for   |[9 Regression] i686
   |%re, %im, %len and %kind|testsuite errors for %re,
   |features|%im, %len and %kind
   ||features

--- Comment #1 from Richard Biener  ---
I don't see these on x86_64 when testing with -m32.  Can you paste your exact
configuration (gfortran -v)?

[Bug tree-optimization/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2018-12-18
  Component|fortran |tree-optimization
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |9.0

--- Comment #5 from Richard Biener  ---
OK, so the issue is starting with GCC 9 we have one more conditional branch
inside the loop checking the outer loop induction variable against some
ubound.  In previous GCC loop-header copying essentially peeled off
an entire iteration exposing the invariant condition as redundant.

GCC 9 does not perform any copying because doing so doesn't make the
loop any more "do-while".  I have added

  /* Make sure to stop copying after we copied the first exit test.
 Without further heuristics we do not want to rotate the loop
 any further.  */
  if (loop_exits_from_bb_p (loop, exit->src))
break;

which stops header-copying after copying the first check.  This was done
in r259754 to not de-optimize some cases.

I guess we could amend the heuristics so that we only ever copy blocks
with IV tests.  It's not that simple though since for example invariant
motion did not yet take place so it's difficult to identify the case
we wanted to avoid with r259754.

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

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Thus, it would be interesting to know where exactly you get the segfault under
debugger, because it is otherwise impossible to debug without access to MS Win.

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The commit doesn't affect non-mingw x86, because MAX_STACK_ALIGNMENT is in that
case very large (1 << 28 bytes), but apparently for mingw if TARGET_SEH
MAX_STACK_ALIGNMENT is only 128 bits.