[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl  ---
On Sat, May 20, 2017 at 04:59:10AM +, jvdelisle at gcc dot gnu.org wrote:
> 
> Yes that will take some frontend magic and we have so few people to support
> gfortran (for free remember) that we may not be able to get to it.
> 
> I don't think the report is invalid at all.
> 

I have thought about this type of issue.

2005-08-21  Steven G. Kargl  

* array.c: Bump GFC_MAX_AC_EXPAND from 100 to 65535.

Good luck.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #12 from Jerry DeLisle  ---
I am going to have to beg to differ here with everyone. First gfortran/gcc is
not crap. Throwing insults back and forth is useless.  It is an extremely
valuable tool for an extremely low cost, as in free. No one has a right to
complain.

With that said. I do think there is a serious implementation issue. I decided
to actually try the code provided and it crapped my machine and required power
down and restart. That is ridiculous.

A better implementation would be that either set a reasonable limit for hard
coded initialization of large arrays and issue a diagnostic if that is
exceeded. That would be easy to do. Or, better yet, don't expand/initialize the
array at compile time.  We should set some sort of global constructor/iterator
that gets finally executed at run time, but at compile time, we know the value
of any aspect of the array as a parameter with out actually needing to expand
it.

Yes that will take some frontend magic and we have so few people to support
gfortran (for free remember) that we may not be able to get to it.

I don't think the report is invalid at all.

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

[peter at cordes dot ca]

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

--- Comment #4 from Peter Cordes  ---
I don't think it's worth anyone's time to implement this in 2017, but using MMX
regs for 64-bit store/load would be faster on really old CPUs that split 128b
vectors insns into two halves, like K8 and Pentium M.  Especially with
-mno-sse2 (e.g. Pentium3 compat) where movlps has a false dependency on the old
value of the xmm reg, but movq mm0 doesn't.  (No SSE2 means we can't MOVQ or
MOVSD to an XMM reg).

MMX is also a saving in code-size: one fewer prefix byte vs. SSE2 integer
instructions.  It's also another set of 8 registers for 32-bit mode.

But Skylake has lower throughput for the MMX versions of some instructions than
for the XMM version.  And SSE4 instructions like PEXTRD don't have MMX
versions, unlike SSSE3 and earlier (e.g. pshufb mm0, mm1 is available, and on
Conroe it's faster than the xmm version).

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
Atom's movd xmm->int is slower (lat=4, rtput=2) than its movd int->xmm (lat=3,
rtput=1), which is opposite of every other CPU (except Silvermont where they're
the same throughput but xmm->int is 1c slower).  So very likely store/reload is
the way to go for -mtune=atom, since store-forwarding is so amazingly fast (1c
latency).  But maybe with SSE4 pextrd, the code-size saving is worth it.

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

[peter at cordes dot ca]

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

--- Comment #2 from Peter Cordes  ---
On most CPUs, psrldq / movd is optimal for xmm[1] -> int without SSE4.  On
SnB-family, movd runs on port0, and psrldq can run on port5, so they can
execute in parallel.  (And the second movd can run the next cycle).

I'd suggest using movd/psrldq/movd for -mtune=generic.  (Or pshuflw to
copy+shuffle if it's useful to not destroy the value in the xmm reg while
extracting to integer.  pshuflw is faster than pshufd on old CPUs, and the same
on current CPUs).

But for some CPUs, this is better:

movd%xmm0, %eax
psrlq   $32, %xmm0
movd%xmm0, %edx

A 64-bit shift by 32 is much better than PSRLDQ on some CPUs, especially
SlowShuffle CPUs (where xmm pshufd is slower than 64-bit granularity shuffles).

* P4: 2c latency instead of 4, and twice the throughput
* Pentium M: 2 uops instead of 4.
* Core2 merom/conroe:  1 uop instead of 2
* K8/K10: same as PSRLDQ

[Bug target/80834] PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2017-05-19
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #2 from Michael Meissner  ---
I guess it is late on a Friday, and I mixed up compilers or options.

I verified that with subversion id 248266 that compiling the attachment with
-mcpu=power9 -O3 -ffast-math DOES NOT generate vector instructions, while
compiling it with -mcpu=power8 -O3 -ffast-math DOES generate vector
instructions.

It also does not generate vector instructions when using the -mcpu=power7 -O3
-ffast-math option.

[Bug target/80834] PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #1 from Michael Meissner  ---
I was posting from my compiler with patches for 80718, and evidently they broke
the vectorization.  If I use an earlier compiler it is fine.  So it is my
problem, not a bug in the current GCC 8.

[Bug target/80834] New: PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables

[meissner at gcc dot gnu.org]

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

Bug ID: 80834
   Summary: PowerPC gcc -mcpu=power9 seems to turn off
vectorization that -mcpu=power8 enables
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41391
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41391=edit
File from spec 2006 milc, compile with -O3 -ffast-math -mcpu=power9

I was working on PR 80718 (which is on ISA 2.07/power8, vec_splat of DFmode
sometimes generates a load to a GPR, direct move, and then a permute, instead
of loading directly to the vector registers).

I was curious to see what code ISA 3.0/power9 generated.  And it looked like
power9 turns off vectorization in this code.

[Bug target/80820] _mm_set_epi64x shouldn't store/reload for -mtune=haswell, Zen should avoid store/reload, and generic should think about it.

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
Also, going the other direction is not symmetric.  On some CPUs, a store/reload
strategy for xmm->int might be better even if an ALU strategy for int->xmm is
best.

Also, the choice can depend on chunk size, since loads are cheap (2 per clock
for AMD since K8 and Intel since SnB).  And store-forwarding works.

Doing the first one with movd and the next with store/reload might be good,
too, on some CPUs. especially if there's some independent work that can happen
for the movd result.

I also discussed some of this at the bottom of the first post in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833.

[Bug target/80820] _mm_set_epi64x shouldn't store/reload for -mtune=haswell, Zen should avoid store/reload, and generic should think about it.

[peter at cordes dot ca]

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

--- Comment #2 from Peter Cordes  ---
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833.

gcc -m32 does an even worse job of getting int64_t into an xmm reg, e.g. as
part of a 64-bit atomic store.

We get a store-forwarding failure from code like this, even with -march=haswell

movl%eax, (%esp)
movl%edx, 4(%esp)
movq(%esp), %xmm0

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

[peter at cordes dot ca]

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

--- Comment #1 from Peter Cordes  ---
See https://godbolt.org/g/krXH9M for the functions I was looking at.

[Bug target/80833] New: 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

[peter at cordes dot ca]

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

Bug ID: 80833
   Summary: 32-bit x86 causes store-forwarding stalls for int64_t
-> xmm
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: i?86-*-*

This affects 64-bit atomic loads/stores, as well as _mm_set_epi64x intrinsics.

gcc -m32 copies int64_t data into xmm registers with the worst possible
strategy: two 32-bit stores and a 64-bit vector load, causing a
store-forwarding stall.

Similarly, for getting 64-bit integers back out of xmm registers, gcc's
store/reload strategy may not be optimal on Intel CPUs.  (But doesn't cause a
store-forwarding stall).


#include 
__m128i combine64(int64_t a, int64_t b) {
  return _mm_set_epi64x(b, a|1);
}

b is loaded directly from memory, but the low half of `a` is modified so it
can't be, letting us observe gcc's int64->xmm strategy.

gcc8-snapshot -m32 -march=haswell -mno-avx -O3 emits:

subl$28, %esp
movl32(%esp), %eax
movl36(%esp), %edx   # the untouched upper half of `a`
orl $1, %eax

# `a` is in integer regs.  The next three lines are gcc's typical
pattern for int64 -> xmm
movl%edx, 12(%esp)
movl%eax, 8(%esp)
movq   8(%esp), %xmm0# guaranteed store-forwarding stall, except
with -mtune=atom

movhps 40(%esp), %xmm0   # store-forwarding stall if the caller used
scalar stores.
addl$28, %esp
ret

A slight improvement would be to  orl $1, 4(%esp)  to do a|1 in-place, instead
of copying it.  But that still has an extra load-store round-trip, so it's not
good even on Atom where it wouldn't cause a store-forwarding stall.

-

For data coming from integer registers, clearly we should use whatever strategy
is optimal for _mm_set_epi32, as discussed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80820).  movd / pinsrd should be
good for -mtune=intel, and Ryzen.

(But in a case like this, with one simple integer operation on data starting in
memory, avoiding integer registers entirely by doing that operation with a
vector-integer instruction is worth considering, see below).



For integers that are coming from memory, it matters a lot whether we expect
them to have been written recently with narrow stores.  Except with
-mtune=atom, which doesn't stall for narrow stores -> wide load.

e.g. -mtune=atom could use

mov$1, %eax
movd %eax, %xmm0   # or load the vector constant from memory
por   4(%esp), %xmm0
ret

If the two integer aren't adjacent, movq / movhps is good.  Other CPUs can use
this, too, if reading memory that we expect wasn't recently written with narrow
stores.

Doing 64-bit integer ops in vector regs is an even bigger win for ops with
carry from low to high, like shift or add.  For example, if it was `a++`
instead of `a|1`:

movq4(%esp), %xmm0   # load `a`
pcmpeqd %xmm1,%xmm1
psubq   %xmm1,%xmm0  # a -= -1.  1 uop vs. 3 for add/adc on Haswell
movhps  12(%esp), %xmm0  # merge in `b`
ret

If we were worried about store-forwarding stalls, then get `a` into xmm0 in two
halves before the psubq.

Scalar 64-bit integer ops in vector regs may be useful in general in 32-bit
code in some cases, especially if it helps with register pressure.



For function args, especially near the start of a function, we should assume
that anything other than separate 32-bit loads will cause a store-forwarding
stall, incurring an extra 10 to 12 cycles of latency beyond the usual
store-forwarding latency, depending on uarch.  i.e. very expensive, and worth
spending a lot of instructions to avoid if it's at all likely, maybe even if
not part of a long dep chain (since out-of-order execution may have trouble
hiding that much latency).

clang4.0 -O3 -march=sandybridge -mno-avx emits this, which is very good if we
have to assume that the function args were recently stored in 32-bit chunks:

movl4(%esp), %eax
orl $1, %eax
movd%eax, %xmm0
pinsrd  $1, 8(%esp), %xmm0   # taking the unmodified half of `a`
directly from the original memory location is a good optimization
pinsrd  $2, 12(%esp), %xmm0
pinsrd  $3, 16(%esp), %xmm0
retl

pinsrd with a memory source is 2 fused-domain uops, but only one of them is an
ALU uop (for the shuffle port).  The other is the load.  It never micro-fuses.

gcc's usual _mm_set_epi32 strategy of doing two 64-bit halves and merging with
a shuffle would also work well with memory source data.



For CPUs where int->xmm is not fast, doing the OR (or whatever other ALU
operation) with a vector instruction is even 

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  ---
Basically to initialize all of the values of a static array, the array is
stored in gfortan memory.  To do a 1GB array, you need at least 32times that
amount of virtual memory available.  Related to bug 56671.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Fri, May 19, 2017 at 08:31:00PM +, gustavo.hime at mpimet dot mpg.de
wrote:
> 
> Are there any maintainers on the gfortran project who can see this? I am going
> to reopen the bug once more, but then I wash my hands. For the record, I'm not
> wasting my time reporting further bugs in gfortran if this is how the
> maintainers deal with the user community. I am one of the few who advocate
> gfortran in favour of the commercial alternatives at my institute,
> but you have seriously shaken my views just now.


There is nothing gfortran can do for you.  You have a
REAL array with 1024**3 elements.  You specifically 
asked gfortran to set ever element of that array to some
value.  gfortran tried to honor your request.  gfortran did
not crash.  Your OS intervened and killed the process,
because you exhausted available memory.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
See https://www.kernel.org/doc/Documentation/vm/overcommit-accounting for more
on what is going on here.  This is not under the gfortran control.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[gustavo.hime at mpimet dot mpg.de]

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

--- Comment #8 from Gustavo Hime  ---

> 
> I understand the issue.  It isn't a problem with gfortran.
> 

You do not understand the issue, which I made quite clear when reporting the
bug. The code compiles, links and runs if no non-zero option is given to
-finit-real. The code generator is probably doing something "silly" like
attempting to fully unroll a loop of e.g. 2^30 iteration for initializing said
array. It is a compiler bug because the compiler runs out of memory. God only
knows how such a "silly" line of code, involving nothing but allocating static
memory space and filling it with a repeated 8-byte constant, can cause a
compiler to run out of memory. Probably not even He knows if this broken code
cannot manifest itself in other situations, perhaps linked to other bugs,
reported or not.

Moreover, a memory allocation request is a safe operation. A program requests
memory and may or may not get it from the OS. It is the program (i.e. compiler)
responsibility to manage denied memory allocations. It is the programmers
responsibility to make sure no unneeded memory is allocated.

> 
> The compiler did not crash.  Your operating system terminated your
> process because you exhausted the virtual memory available to you.
> The error message even tells you what you have done.

The compiler crashed because it terminated abnormally because it attempted to
use more memory than the machine has without regard for systems limitations
and, most important, without a good reason. The error message does not tell the
programmer what caused the error in the program being compiled (there is none)
nor what caused the compiler to exhaust system memory (which it had no reason
for other than bad implementation).

Are there any maintainers on the gfortran project who can see this? I am going
to reopen the bug once more, but then I wash my hands. For the record, I'm not
wasting my time reporting further bugs in gfortran if this is how the
maintainers deal with the user community. I am one of the few who advocate
gfortran in favour of the commercial alternatives at my institute, but you have
seriously shaken my views just now.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
(In reply to Steve Kargl from comment #6)
> On Fri, May 19, 2017 at 08:07:17PM +, pinskia at gcc dot gnu.org wrote:
> >  Status|RESOLVED|REOPENED
> >  Resolution|INVALID |---
> > 
> > --- Comment #5 from Andrew Pinski  ---
> > >A compiler that crashes
> > 
> > Actually in this case, the kernel is killing it.  There is not much the
> > compiler could do from preventing the kernel from causing the crash.
> > 
> 
> Why did you re-open this bug?.  You even acknowledge that
> the OS kills the process.  This is not a compiler issue.

Woops, I thought I submitted my comments only :(

[Bug c/80806] gcc does not warn if local array is memset only

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01493.html

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Fri, May 19, 2017 at 08:07:17PM +, pinskia at gcc dot gnu.org wrote:
>  Status|RESOLVED|REOPENED
>  Resolution|INVALID |---
> 
> --- Comment #5 from Andrew Pinski  ---
> >A compiler that crashes
> 
> Actually in this case, the kernel is killing it.  There is not much the
> compiler could do from preventing the kernel from causing the crash.
> 

Why did you re-open this bug?.  You even acknowledge that
the OS kills the process.  This is not a compiler issue.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from Andrew Pinski  ---
>A compiler that crashes

Actually in this case, the kernel is killing it.  There is not much the
compiler could do from preventing the kernel from causing the crash.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Gustavo Hime from comment #3)
> I (In reply to kargl from comment #2)
> > The reported error message "virtual memory exhausted: Cannot allocate 
> > memory"
> > is fairly descriptive.  Allocating a 1 GB static array is a rather silly
> > thing for a programmer to do.
> 
> Please mind your tone. And refrain from arbitrarily closing a bug just
> because you cannot understand the gravity of it.

I understand the issue.  It isn't a problem with gfortran.

> A compiler that crashes, no matter how preposterous the source code that led
> it to crash, is trash. Any software that crashes ungraciously is trash.
> Either work for improving the GCC suite or keep quiet.

The compiler did not crash.  Your operating system terminated your
process because you exhausted the virtual memory available to you.
The error message even tells you what you have done.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[gustavo.hime at mpimet dot mpg.de]

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

Gustavo Hime  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from Gustavo Hime  ---
I (In reply to kargl from comment #2)
> The reported error message "virtual memory exhausted: Cannot allocate memory"
> is fairly descriptive.  Allocating a 1 GB static array is a rather silly
> thing for a programmer to do.

Please mind your tone. And refrain from arbitrarily closing a bug just because
you cannot understand the gravity of it.

A compiler that crashes, no matter how preposterous the source code that led it
to crash, is trash. Any software that crashes ungraciously is trash. Either
work for improving the GCC suite or keep quiet.

I was lucky to have discovered the bug because of a typo. I wonder it had
triggered because of some constellation of preprocessed constants set inside a
perl build script combined with parameters scattered over several source files
in different directories - and then after years successfully building your
1000+ source file project suddenly somebody in the other side of the planet
changes one such number and your the code no longer compiles. That would indeed
be silly.

[Bug c++/79549] [c++1z] ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
The reported error message "virtual memory exhausted: Cannot allocate memory"
is fairly descriptive.  Allocating a 1 GB static array is a rather silly
thing for a programmer to do.

[Bug c++/70167] Some const array prvalues are incorrectly treated as lvalues

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #5 from Jason Merrill  ---
Fixed for gcc 8.

[Bug c++/80178] Class with deleted copy and move constructors uses wrong argument passing ABI

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for gcc 8.

[Bug c/80832] New: GCC_COLORS

[Retyopiy at mail dot ru]

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

Bug ID: 80832
   Summary: GCC_COLORS
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Retyopiy at mail dot ru
  Target Milestone: ---

GCC_COLORS can contain "locus=" to colorize path to file, ":", line number,
":", column number and ":", but expected separate values:
- "file=" to colorize path to file (without ":");
- "line=" to colorize line number (without ":");
- "column=" to colorize column number (without ":");
- "colon=" to colorize ":".

GCC_COLORS can contain "error=", "warning=" and "note=" to colorize strings
"error:". "warning:" and "note:", but expected colorize strings without ":" and
use "colon=" to colorize ":".

Documentation page, like

https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Language-Independent-Options.html

contain text "SGR substring for caret line", but term "caret line" is not
described. What is "caret line"?

Summary:
- implement "file=", "line=", "column=", "colon=";
- describe term "caret line".

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.2 |5.5

--- Comment #10 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/70118] UBSan claims misaligned access in SSE instrinsics

[ubizjak at gmail dot com]

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

Bug 80799 Summary: [7/8 Regression] x86-32 bits generates MMX without EMMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799

   What|Removed |Added

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

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri May 19 18:08:19 2017
New Revision: 248297

URL: https://gcc.gnu.org/viewcvs?rev=248297=gcc=rev
Log:
Backport from mainline
2017-05-18  Uros Bizjak  

PR target/80799
* config/i386/mmx.md (*mov_internal): Enable
alternatives 11, 12, 13 and 14 also for 32bit targets.
Remove alternatives 15, 16, 17 and 18.
* config/i386/sse.md (vec_concatv2di): Change
alternative (!x, *y) to (x, ?!*Yn).

testsuite/ChangeLog:

Backport from mainline
2017-05-18  Uros Bizjak  

PR target/80799
* g++.dg/other/i386-11.C: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/other/i386-11.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/mmx.md
branches/gcc-5-branch/gcc/config/i386/sse.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/80831] New: internal compiler error: Segmentation fault with -fsyntax-only

[holger.hopp at sap dot com]

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

Bug ID: 80831
   Summary: internal compiler error: Segmentation fault with
-fsyntax-only
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.hopp at sap dot com
  Target Milestone: ---

Following code throws internal compiler error: Segmentation fault with
g++ -c t.cpp --std=c++11 -fsyntax-only

(gcc Releases 6 and 7, gcc 5 is ok)


class A
{
public:
virtual ~A() { }
};

class B { };

class C : public A { };

template
class D : public C
{
public:
D() { }
~D() { }
};

class E
{
public:
static E& p();
B q();
template
B q(void (J::*r)())
{
new D();
return q();
}
};

void t()
{
  class F
  {
  public:
virtual void s() { }
  };
  E& x = E::p();
  B y = x.q(::s);
}


$ g++ -c t.cpp --std=c++11 -fsyntax-only
t.cpp:41:1: internal compiler error: Segmentation fault
 }
 ^
0xb045cf crash_signal
/gcc/gnu/gcc-7-branch/gcc/gcc/toplev.c:337
0x642c4c c_parse_final_cleanups()
/gcc/gnu/gcc-7-branch/gcc/gcc/cp/decl2.c:4710
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/80829] Use of constexpr constructors with base type instantiation fails compilation

[bbannier+gcc_bugs at gmail dot com]

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

--- Comment #1 from Benjamin Bannier  ---
We believe this code is legal C++11 (AFAICT no explicit restrictions on
implicit conversions of `constexpr` vars), and was compiling successfully with
e.g., 6.3, so we strongly suspect a GCC regression.

[Bug c++/80830] ice in tsubst_copy, at cp/pt.c:14569

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced code, although it doesn't look like legal C++ to me:

class a;
template < b > void operator<<(a , ;

class {friend operator<<(a , ;  
template < int = 3 > class c { 
friend operator<<<>(, c ;   

c<> d({

[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
This is now fixed on trunk. The patch fixes both READ and WRITE traversal of
arrays of class objects using User Defined Derived Type I/O in NAMELISTs. This
could be a slick feature for "serializing" CLASS objects.

Will back port to 7 in a few days if no new problems pop up.

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri May 19 15:51:10 2017
New Revision: 248294

URL: https://gcc.gnu.org/viewcvs?rev=248294=gcc=rev
Log:
Backport from mainline
2017-05-18  Uros Bizjak  

PR target/80799
* config/i386/mmx.md (*mov_internal): Enable
alternatives 11, 12, 13 and 14 also for 32bit targets.
Remove alternatives 15, 16, 17 and 18.
* config/i386/sse.md (vec_concatv2di): Change
alternative (!x, *y) to (x, ?!*Yn).

testsuite/ChangeLog:

Backport from mainline
2017-05-18  Uros Bizjak  

PR target/80799
* g++.dg/other/i386-11.C: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/other/i386-11.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/mmx.md
branches/gcc-6-branch/gcc/config/i386/sse.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri May 19 15:48:35 2017
New Revision: 248293

URL: https://gcc.gnu.org/viewcvs?rev=248293=gcc=rev
Log:
2017-05-19  Paul Thomas  

PR fortran/80333
* trans-io.c (nml_get_addr_expr): If we are dealing with class
type data set tmp tree to get that address.
(transfer_namelist_element): Set the array spec to point to the
the class data.

2017-05-19  Paul Thomas  
Jerry DeLisle  

PR fortran/80333
* list_read.c (nml_read_obj): Compute pointer into class/type
arrays from the nl->dim information. Update it for each iteration
of the loop for the given object.

2017-05-19  Jerry DeLisle  

PR libgfortran/80333
* gfortran.dg/dtio_30.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_30.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
> Huh?  So you can blatantly ignore it there too?  Not only is that completely
> asinine, it contradicts the hint on the "add attachment" link: "proposed
> *patch*, testcase, etc."  Surely, it is much more logical to have patches
> attached to the problem report to which they relate?

See https://gcc.gnu.org/contribute.html

[Bug c/78503] -Wint-in-bool-context false positive on unsigned multiplication

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-19
 CC||edlinger at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirming based on comment #1.  I CC the author of the warning for his input.

[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> Do you agree with the change in comment 0? If yes, I can do the testing and
> packaging.

Yes, that's fine by me.

Thanks

Paul

[Bug sanitizer/80800] UBSAN: yet another false positive

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed.

[Bug sanitizer/80800] UBSAN: yet another false positive

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 19 15:30:54 2017
New Revision: 248291

URL: https://gcc.gnu.org/viewcvs?rev=248291=gcc=rev
Log:
PR sanitizer/80800
* fold-const.c (extract_muldiv_1) : Add
TYPE_OVERFLOW_WRAPS checks.

* c-c++-common/ubsan/pr80800.c: New test.
* c-c++-common/Wduplicated-branches-1.c: Adjust an expression.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr80800.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-1.c

[Bug c/80806] gcc does not warn if local array is memset only

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Right, const could be used in lieu of an "in" attribute for warnings.  It can't
be used for the same thing for optimization because constness can be cast away.
 Bug 10138 has a good discussion on the subject.

Let me see if I can prototype something.

[Bug rtl-optimization/80754] [8 Regression][LRA] Invalid smull instruction generated in lra-remat

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Wilco from comment #3)
> Patch here https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01364.html

Thanks for working on the problem, Wilco.

I'll review the patch and give you an answer on Wednesday (May 24).

[Bug c++/80830] New: ice in tsubst_copy, at cp/pt.c:14569

[dcb314 at hotmail dot com]

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

Bug ID: 80830
   Summary: ice in tsubst_copy, at cp/pt.c:14569
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 41390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41390=edit
gzipped C++ source code

The attached C++ code, when compiled by recent gcc trunk, does this:

../results.248178/bin/gcc
../results.248260/bin/gcc
/usr/include/wfmath-1.0/wfmath/ball.h:75:24: internal compiler error: in
tsubst_copy, at cp/pt.c:14569
$

So the bug seems to exist between revisions 248178 and 248260.

I'll have a go at reducing the code.

[Bug c/80793] three signed conversion warnings for the same expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
See also bug 60083 for an example where the duplicate conversion warnings are a
source of user complaints.

[Bug c/60083] Duplicate conversion warnings from negative integer to unsigned type (gcc-4.3 emits only one warning)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
It's useful to compare GCC output to Clang's (with no options):

t.c:3:44: warning: ^ has lower precedence than ==; == will be evaluated first
  [-Wparentheses]
  unsigned short s = ~0x4578ADBCAA1DE677LL ^ a == 0;
   ^~~~
t.c:3:44: note: place parentheses around the '==' expression to silence this
  warning
  unsigned short s = ~0x4578ADBCAA1DE677LL ^ a == 0;
   ^
 ( )
t.c:3:44: note: place parentheses around the ^ expression to evaluate it first
  unsigned short s = ~0x4578ADBCAA1DE677LL ^ a == 0;
   ^
 ()
t.c:3:44: warning: implicit conversion from 'long long' to 'unsigned short'
  changes value from -5005942011641849463 to 6537 [-Wconstant-conversion]
  unsigned short s = ~0x4578ADBCAA1DE677LL ^ a == 0;
 ~   ~~^~~~
2 warnings generated.

[Bug c++/80829] New: Use of constexpr constructors with base type instantiation fails compilation

[aaron.wood at verizon dot com]

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

Bug ID: 80829
   Summary: Use of constexpr constructors with base type
instantiation fails compilation
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron.wood at verizon dot com
  Target Milestone: ---

Created attachment 41389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41389=edit
Small reproducer

GCC 7.1 fails to compile programs where a type extends another type, both types
have constexpr constructors, and instantiating is done like so: constexpr A a =
B(10);

This produces: error: 'B(10).B::' is not a constant expression
because it refers to an incompletely initialized variable
constexpr A a = B(10);

The fix/workaround is to not use the base type: constexpr B b = B(10);

I've attached a small program that shows the A and B types I'm using here and
easily reproduces this issue on 7.1.

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Also the three cases:
  /* If the left segment does not extend beyond the start of the
 right segment the new segment length is that of the right
 plus the segment distance.  */
  if (tree_fits_uhwi_p (dr_a1->seg_len)
  && compare_tree_int (dr_a1->seg_len, diff) <= 0)
{
  dr_a1->seg_len = size_binop (PLUS_EXPR, dr_a2->seg_len,
   size_int (diff));
  do_remove = true;
}
  /* Generally the new segment length is the maximum of the
 left segment size and the right segment size plus the distance.
 ???  We can also build tree MAX_EXPR here but it's not clear this
 is profitable.  */
  else if (tree_fits_uhwi_p (dr_a1->seg_len)
   && tree_fits_uhwi_p (dr_a2->seg_len))
{
  unsigned HOST_WIDE_INT seg_len_a1 = tree_to_uhwi
(dr_a1->seg_len);
  unsigned HOST_WIDE_INT seg_len_a2 = tree_to_uhwi
(dr_a2->seg_len);
  dr_a1->seg_len = size_int (MAX (seg_len_a1, diff + seg_len_a2));
  do_remove = true;
}
  /* Now we check if the following condition is satisfied:

 DIFF - SEGMENT_LENGTH_A < SEGMENT_LENGTH_B

 where DIFF = DR_A2_INIT - DR_A1_INIT.  However,
 SEGMENT_LENGTH_A or SEGMENT_LENGTH_B may not be constant so we
 have to make a best estimation.  We can get the minimum value
 of SEGMENT_LENGTH_B as a constant, represented by MIN_SEG_LEN_B,
 then either of the following two conditions can guarantee the
 one above:

 1: DIFF <= MIN_SEG_LEN_B
 2: DIFF - SEGMENT_LENGTH_A < MIN_SEG_LEN_B  */
  else
{
  unsigned HOST_WIDE_INT min_seg_len_b
= (tree_fits_uhwi_p (dr_b1->seg_len)
   ? tree_to_uhwi (dr_b1->seg_len)
   : factor);

  if (diff <= min_seg_len_b
  || (tree_fits_uhwi_p (dr_a1->seg_len)
  && diff - tree_to_uhwi (dr_a1->seg_len) < min_seg_len_b))
{
  dr_a1->seg_len = size_binop (PLUS_EXPR,
   dr_a2->seg_len, size_int
(diff));
  do_remove = true;
}
}

Can be merged together.  the merged dr_a1->seg_len is dr_a2->seg_len + diff,
with an exception checking MAX (seg_len_a1, diff + seg_len_a2).

Of course, negative step still needs to be handled.

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Author: wschmidt
Date: Fri May 19 14:30:02 2017
New Revision: 248287

URL: https://gcc.gnu.org/viewcvs?rev=248287=gcc=rev
Log:
2017-05-19  Bill Schmidt  

Backport from mainline
2016-08-11  Bill Schmidt  

PR target/72863
* vsx.md (vsx_load_): For P8LE, emit swaps at expand time.
(vsx_store_): Likewise.


Modified:
branches/ibm/gcc-5-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-5-branch/gcc/REVISION
branches/ibm/gcc-5-branch/gcc/config/rs6000/vsx.md

[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-19
 CC||jvdelisle at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Do you agree with the change in comment 0? If yes, I can do the testing and
packaging.

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #6 from Dominique d'Humieres  ---
> I removed the trailing exclamation mark on trunk in r248283 (PR 79852).

The translation issue is covered by pr79842. Closing as FIXED.

[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__

[keith.marshall at mailinator dot com]

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

--- Comment #3 from Keith Marshall  ---
(In reply to Eric Botcazou from comment #1)
> Patches should be posted on the gcc-patches mailing-list.

Huh?  So you can blatantly ignore it there too?  Not only is that completely
asinine, it contradicts the hint on the "add attachment" link: "proposed
*patch*, testcase, etc."  Surely, it is much more logical to have patches
attached to the problem report to which they relate?

[Bug c/60083] Duplicate conversion warnings from negative integer to unsigned type (gcc-4.3 emits only one warning)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Started with r139049.

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri May 19 14:09:45 2017
New Revision: 248284

URL: https://gcc.gnu.org/viewcvs?rev=248284=gcc=rev
Log:
Backport from mainline
2017-05-18  Uros Bizjak  

PR target/80799
* config/i386/mmx.md (*mov_internal): Enable
alternatives 11, 12, 13 and 14 also for 32bit targets.
Remove alternatives 15, 16, 17 and 18.
* config/i386/sse.md (vec_concatv2di): Change
alternative (!x, *y) to (x, ?!*Yn).

testsuite/ChangeLog:

Backport from mainline
2017-05-18  Uros Bizjak  

PR target/80799
* g++.dg/other/i386-11.C: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/other/i386-11.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/mmx.md
branches/gcc-7-branch/gcc/config/i386/sse.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug libobjc/54720] libobjc install-strip target not populated

[keith.marshall at mailinator dot com]

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

--- Comment #3 from Keith Marshall  ---
And, more than 4 years later, this issue persists in GCC-6.3.0

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #5 from David Malcolm  ---
I removed the trailing exclamation mark on trunk in r248283 (PR 79852).

[Bug fortran/79852] diagnostics should not end with exclamation mark

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed on trunk by r248283.

[Bug fortran/79852] diagnostics should not end with exclamation mark

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Fri May 19 13:52:14 2017
New Revision: 248283

URL: https://gcc.gnu.org/viewcvs?rev=248283=gcc=rev
Log:
fortran: remove trailing exclamation mark from various diagnostics (PR
fortran/79852)

gcc/fortran/ChangeLog:
PR fortran/79852
* bbt.c (insert): Remove trailing exclamation mark from message.
* decl.c (gfc_match_final_decl): Likewise.
* dump-parse-tree.c (show_expr): Likewise.
* module.c (gfc_use_module): Likewise.
* primary.c (build_actual_constructor): Likewise.
(gfc_convert_to_structure_constructor): Likewise.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/bbt.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/primary.c

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Context is:
>
>   gfc_fatal_error ("Can't USE the same %smodule we're building!",
>  p->state == COMP_SUBMODULE ? "sub" : "");
>
> Possible i18n issue here; are "module" / "submodule" to be translated;
> if so, the "sub"-prefixiing could be problematic

This is pr79842.

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
Context is:

  gfc_fatal_error ("Can't USE the same %smodule we're building!",
   p->state == COMP_SUBMODULE ? "sub" : "");

Possible i18n issue here; are "module" / "submodule" to be translated; if so,
the "sub"-prefixiing could be problematic

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0).

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Even the unchanged code is almost acceptable with -fno-var-tracking-assignments

 TOTAL : 357.361.11   359.181206964 kB

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
Looking at callgrind profile shows that early inlining is the TV_INTEGRATION
culprit with expand_call_inline -> cgraph_node::remove -> .. ->
cgraph_node::find_replacement () being the culript showing

  /* Update clone_of pointers.  */
  n = new_clones;
  while (n)
{
  n->clone_of = next_inline_clone;
  n = n->next_sibling_clone;
}

as hottest.  The whole function looks like having bad complexity if there are a
lot of inline clones (we call the same function very many times and likely
inline all of them).  I suspect handling this higher up in the chain would be
more
efficient than doing this in expand_call_inline ...

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Using -fno-var-tracking-assignments helps too.

Inserting the right type:

 TOTAL: 291.541.14   293.251237034 kB

Range-insert from an array of the right type:

 TOTAL:  98.590.7599.54 821507 kB

[Bug target/52991] attribute packed broken on mingw32?

[krakonos at krakonos dot org]

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

Ladislav Láska  changed:

   What|Removed |Added

 CC||krakonos at krakonos dot org

--- Comment #21 from Ladislav Láska  ---
Hi!

I'm still seeing this problem on recent release 6.3.1, and it seems to be
enabled by default on at least some builds (msys2 for example). 

Can I help somehow to get this into trunk sooner?

Thanks!

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
FWIW using -O1 -g -ftime-report on the original code with GCC 5.4.1 gives:

 TOTAL   :1387.175.14   1462.362427702 kB

And also prints the -fvar-tracking-assignments note.

[Bug c++/80593] [7 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] GCC 7, |[7 Regression] GCC 7,
   |aligned_storage and |aligned_storage and
   |“dereferencing type-punned  |“dereferencing type-punned
   |pointer will break  |pointer will break
   |strict-aliasing rules”  |strict-aliasing rules”

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c++/80593] [7/8 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri May 19 12:34:54 2017
New Revision: 248269

URL: https://gcc.gnu.org/viewcvs?rev=248269=gcc=rev
Log:
2017-05-19  Richard Biener  

PR c++/80593
* c-warn.c (strict_aliasing_warning): Do not warn for accesses
to alias-set zero memory.

* g++.dg/warn/Wstrict-aliasing-bogus-char-2.C: New testcase.
* g++.dg/warn/Wstrict-aliasing-6.C: Adjust expected outcome.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-char-2.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-6.C

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I don't know why it's so slow, or if it's possible to change the libstdc++ code
to help the c++98 case (I doubt it).

But it helps a lot if you insert the correct type:

mMap.insert (std::pair("1", 1));

The value_type of map is pair not pair. Inserting the
wrong type means the compiler instantiates two different specializations of
std::pair and has to convert from one to the other.

With -O1 the time-report for that is:
 TOTAL  : 348.27 2.37   351.291595960 kB

That's still slow, but not "making the box unusable" slow.

It helps a bit more if you create an array of pairs and insert from that:

std::pair pairs[] = {
std::pair("1", 1),
...
};

int n = sizeof(pairs)/sizeof(pairs[0]);
std::map mMap(pairs, pairs + n);

With -O1 the time-report for that is:
 TOTAL  : 178.28 1.66   180.501071340 kB


Both runs print:

m.cc:6:5: note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without

[Bug c++/80593] [7/8 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||s-beyer at gmx dot net

--- Comment #6 from Richard Biener  ---
*** Bug 80827 has been marked as a duplicate of this bug. ***

[Bug c++/80827] False strict-aliasing warning with certain settings

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Fixed by the patch for PR80593.

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

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.2

--- Comment #6 from Jonathan Wakely  ---
Fixed for GCC 7.2

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Fri May 19 12:28:28 2017
New Revision: 248267

URL: https://gcc.gnu.org/viewcvs?rev=248267=gcc=rev
Log:
PR libstdc++/80796 Add new std::search overload for C++17

PR libstdc++/80796
* include/bits/stl_algo.h (search): Add new overload for C++17.
* testsuite/25_algorithms/search/searcher.cc: New.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/25_algorithms/search/searcher.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/stl_algo.h

[Bug middle-end/80823] [8 Regression] ICE: verify_flow_info failed

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #2 from Peter Bergner  ---
Sigh, mine.

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri May 19 12:11:31 2017
New Revision: 248266

URL: https://gcc.gnu.org/viewcvs?rev=248266=gcc=rev
Log:
PR libstdc++/80796 Add new std::search overload for C++17

PR libstdc++/80796
* include/bits/stl_algo.h (search): Add new overload for C++17.
* testsuite/25_algorithms/search/searcher.cc: New.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/search/searcher.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

[d25fe0be at outlook dot com]

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

--- Comment #3 from d25fe0be@  ---
Oh, my bad. 

I did't know about p0433r2, but at least I should have checked n4659
(make_xxx_searcher has already been removed there) before submitting.

My apologize. And thanks for pointing out this.

[Bug driver/80828] New: Command line option -e not documented

[sirl at gcc dot gnu.org]

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

Bug ID: 80828
   Summary: Command line option -e not documented
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

I couldn't find (also grepping under trunk/gcc/doc) any documentation on the -e
commandline option. It seems the option and it's argument are directly passed
to the linker, similar to -T (which is documented in invoke.texi).

[Bug c++/80827] New: False strict-aliasing warning with certain settings

[s-beyer at gmx dot net]

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

Bug ID: 80827
   Summary: False strict-aliasing warning with certain settings
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s-beyer at gmx dot net
  Target Milestone: ---

Hi,

$ cat foo.cc 
#include 

template
void foo() {
std::istringstream ss("a\nb\nc");
std::string attr;
while (std::getline(ss, attr));
}
$ g++-7 -Wall -O2 -c foo.cc   # warning with -O2
foo.cc: In function ‘void foo()’:
foo.cc:7:30: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
  while (std::getline(ss, attr));
  ^
$ g++-7 -Wall -O1 -c foo.cc  # works with -O1
$ g++-7 --version
g++-7 (Debian 7.1.0-5) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Interestingly, when using a function instead of a function template,
it works:

$ cat foo.cc 
#include 

void foo() {
std::istringstream ss("a\nb\nc");
std::string attr;
while (std::getline(ss, attr));
}
$ g++-7 -Wall -O2 -c foo.cc

Btw it works with 6.3.0

Best
  Stephan

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2017-05-19
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Ah, but the extra overload of std::search is missing. It should have been added
by r240093.

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
That's intentional, because they're not in the C+17 draft.

They were removed by
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0433r2.html

[Bug tree-optimization/80821] genmatch conflicting predicates

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri May 19 11:13:48 2017
New Revision: 248264

URL: https://gcc.gnu.org/viewcvs?rev=248264=gcc=rev
Log:
2017-05-19  Richard Biener  

PR build/80821
* genmatch.c (dt_node::gen_kids_1): Add missing scope around
predicate evaluation.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/genmatch.c

[Bug tree-optimization/80821] genmatch conflicting predicates

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gufideg at gmail dot com

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

[Bug c++/80795] Cannot take the address of call operator of a variadic lambda when parameter pack length differs from 1

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Yup, dup. Thanks.

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

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #2)
> On Fri, 19 May 2017, amker at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815
> > 
> > --- Comment #1 from amker at gcc dot gnu.org ---
> > GCC uses vect_factor as minimal segment length for dr_b when merging alias
> > pairs, I think it could be relaxed to vect_factor * abs (DR_STEP (dr_b)). 
> > Below test shows this change can merge additional alias checks:
> 
> But it would make cases aliasing that are not (that's always a trade off
> between more precise result and less runtime checking).

Hmm, it only does compilation time (and still conservative) check if segment
dr_b resides in the gap between dr_a1 and dr_a2.  the overall effect would be
equal to checking ,  and ?

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
For GCC 7 most time is spent in inlining.  I suspect C++14 helps with constexpr
evaluation doing some of the stuff in the frontend.

 integration :  21.73 (39%) usr   0.33 (23%) sys  22.02 (39%) wall 
234388 kB (23%) ggc

C++14:

 integration :   1.78 (14%) usr   0.16 (17%) sys   1.95 (14%) wall 
 99264 kB (17%) ggc

one likely reason is that early optimization is not good at reducing
abstraction with loops (not sure if std::map insertion involves loops that are
optimizable).

Maybe libstdc++ could still use features that make it faster with c++98 and
only restrict its interface?

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Fri, 19 May 2017, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815
> 
> --- Comment #1 from amker at gcc dot gnu.org ---
> GCC uses vect_factor as minimal segment length for dr_b when merging alias
> pairs, I think it could be relaxed to vect_factor * abs (DR_STEP (dr_b)). 
> Below test shows this change can merge additional alias checks:

But it would make cases aliasing that are not (that's always a trade off
between more precise result and less runtime checking).

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|Red Hat 7 Linux x86 64bit   |
 Status|UNCONFIRMED |NEW
Version|4.8.5   |5.4.1
   Keywords||compile-time-hog,
   ||memory-hog
   Last reconfirmed||2017-05-19
  Component|c++ |libstdc++
   Host|Red Hat 7 Linux x86 64bit   |
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
GCC 6 and GCC 7 (even with -std=c++98) behave more reasonably here.  -std=c++14
helps reducing memory use and compile-time (still uses 700MB and a couple of
seconds for the compile though).

GCC 5 takes a long time with c++98 (didn't wait long enough to get an idea
on memory use), it's reasonable with -std=c++14 here as well.

Note even GCC 4.8 with -std=c++14 behaves reasonably (but c++98 seems to behave
as GCC 5 does).

Thus confirmed for GCC 5 (which is the oldest release we still care for btw).

I think memory use and compile-time is still unreasonable for GCC 6 and 7.

clang 3.8 also uses more than 10GB with -std=c++98 (had to interrupt here).
c++14 doesn't help clang.  Using libc++ helps it (with c++14), so changing
component.

In the end it might be your fault (in using C++ ...) ;)

[Bug c++/80826] Compilation Time for many of std::map insertions

[seanthesheep1 at hotmail dot com]

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

--- Comment #1 from seanthesheep1 at hotmail dot com ---
I had to stop the compilation as it was close to consuming 100% of the memory
and making the box unusable:

Cpu(s):  0.0%us,  6.3%sy,  0.0%ni, 88.0%id,  5.8%wa,  0.0%hi,  0.0%si, 
0.0%st
Mem:  37043164k total, 36949996k used,93168k free,  460k buffers
Swap: 16450520k total, 16394764k used,55756k free,12308k cached

PID USER  PR  NI  VIRT SWAP  RES CODE DATA  SHR S %CPU %MEMTIME+ 
COMMAND
11174 me18   0 50.3g  15g  34g 6416  50g 9644 D 14.0 98.9  40:21.26
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -quiet -D_GNU_SOURCE
test.cpp -quiet -dumpbase test.cpp -mtune=generic -auxbase test -g -O1
-ftime-report -o /tmp/ccgPeF5L.s

[Bug tree-optimization/80821] genmatch conflicting predicates

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 248263)
+++ gcc/genmatch.c  (working copy)
@@ -3005,6 +3013,8 @@ dt_node::gen_kids_1 (FILE *f, int indent
   expr *e = as_a  (preds[i]->op);
   predicate_id *p = as_a  (e->operation);
   preds[i]->get_name (kid_opname);
+  fprintf_indent (f, indent, "{\n");
+  indent += 2;
   fprintf_indent (f, indent, "tree %s_pops[%d];\n", kid_opname, p->nargs);
   fprintf_indent (f, indent, "if (%s_%s (%s, %s_pops%s))\n",
   gimple ? "gimple" : "tree",
@@ -3020,6 +3030,8 @@ dt_node::gen_kids_1 (FILE *f, int indent
}
   preds[i]->gen_kids (f, indent + 4, gimple);
   fprintf (f, "}\n");
+  indent -= 2;
+  fprintf_indent (f, indent, "}\n");
 }

   for (unsigned i = 0; i < others.length (); ++i)

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
GCC uses vect_factor as minimal segment length for dr_b when merging alias
pairs, I think it could be relaxed to vect_factor * abs (DR_STEP (dr_b)). 
Below test shows this change can merge additional alias checks:

#include 

int arr[2048];

int
foo (int *a, int *b, int len)
{
  int i;
  int *a1 = a;
  int *a0 = a1 - 4;
  for (i = 0; i < len; i++)
{
  *b = *a0 + *a1;
  b--;
  a0++;
  a1++;
}
  return 0;
}

int main (void)
{
  int *a = [1027];
  int *b = [1024];

  int i;
  for (i = 0; i < 2048; i++)
arr[i] = i;

  foo (a, b, 500);

  for (i = 0; i < 2048; i++)
fprintf (stdout, "%d: %d\n", i, arr[i]);

  return 0;
}

$ ./gcc -Ofast -fno-inline ./z.c -o z.exe -fdump-tree-vect-details

Of course, alias check should fail and vectorized loop in foo should never be
executed.
Thanks,

[Bug c++/80826] New: Compilation Time for many of std::map insertions

[seanthesheep1 at hotmail dot com]

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

Bug ID: 80826
   Summary: Compilation Time for many of std::map insertions
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seanthesheep1 at hotmail dot com
  Target Milestone: ---

Created attachment 41388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41388=edit
test code

Hi,

I have some code, which I am attempting to generate from file, which creates a
std::map and inserts 6000+ pairs into it.

Here is sample code what I mean:

#include 
#include 
#include 
#include 

int main ()
{

std::map mMap;
mMap.insert (std::pair("1", 1));
mMap.insert (std::pair("2", 2));
mMap.insert (std::pair("3", 3));
mMap.insert (std::pair("4", 4));
mMap.insert (std::pair("5", 5));
mMap.insert (std::pair("6", 6));
mMap.insert (std::pair("7", 7));
mMap.insert (std::pair("8", 8));
mMap.insert (std::pair("9", 9));
mMap.insert (std::pair("10", 10));
mMap.insert (std::pair("11", 11));
mMap.insert (std::pair("12", 12));
mMap.insert (std::pair("13", 13));
mMap.insert (std::pair("14", 14));
//...
mMap.insert (std::pair("6105", 6105));
mMap.insert (std::pair("6106", 6106));
mMap.insert (std::pair("6107", 6107));
mMap.insert (std::pair("6108", 6108));
mMap.insert (std::pair("6109", 6109));
mMap.insert (std::pair("6110", 6110));
mMap.insert (std::pair("6111", 6111));
}

Note: the values above are for demonstration purposes and not what I am
actually using.

The g++ compilation time for this with no optimization is ~13 seconds, which is
surprising long. 

$ time g++ -g -ftime-report  test.cpp

Execution times (seconds)
 garbage collection:   0.73 ( 6%) usr   0.00 ( 0%) sys   0.73 ( 6%)
wall   0 kB ( 0%) ggc
 callgraph construction:   0.55 ( 5%) usr   0.04 ( 7%) sys   0.60 ( 5%)
wall   12476 kB ( 2%) ggc
 callgraph optimization:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 cfg cleanup   :   0.41 ( 3%) usr   0.00 ( 0%) sys   0.41 ( 3%)
wall   0 kB ( 0%) ggc
 trivially dead code   :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.08 ( 1%)
wall   0 kB ( 0%) ggc
 life analysis :   0.61 ( 5%) usr   0.01 ( 2%) sys   0.62 ( 5%)
wall   16256 kB ( 2%) ggc
 life info update  :   0.29 ( 2%) usr   0.00 ( 0%) sys   0.29 ( 2%)
wall3439 kB ( 0%) ggc
 alias analysis:   0.20 ( 2%) usr   0.00 ( 0%) sys   0.20 ( 2%)
wall4102 kB ( 1%) ggc
 register scan :   0.07 ( 1%) usr   0.00 ( 0%) sys   0.07 ( 1%)
wall   0 kB ( 0%) ggc
 rebuild jump labels   :   0.11 ( 1%) usr   0.00 ( 0%) sys   0.10 ( 1%)
wall   0 kB ( 0%) ggc
 preprocessing :   0.11 ( 1%) usr   0.07 (12%) sys   0.19 ( 2%)
wall1452 kB ( 0%) ggc
 parser:   0.77 ( 7%) usr   0.18 (31%) sys   0.86 ( 7%)
wall  123814 kB (18%) ggc
 name lookup   :   0.14 ( 1%) usr   0.10 (17%) sys   0.30 ( 2%)
wall8390 kB ( 1%) ggc
 inline heuristics :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 integration   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 tree gimplify :   0.23 ( 2%) usr   0.01 ( 2%) sys   0.25 ( 2%)
wall   17802 kB ( 3%) ggc
 tree eh   :   0.21 ( 2%) usr   0.03 ( 5%) sys   0.23 ( 2%)
wall   89644 kB (13%) ggc
 tree CFG construction :   0.21 ( 2%) usr   0.02 ( 3%) sys   0.23 ( 2%)
wall   83144 kB (12%) ggc
 tree CFG cleanup  :   0.26 ( 2%) usr   0.00 ( 0%) sys   0.26 ( 2%)
wall 512 kB ( 0%) ggc
 expand:   1.58 (13%) usr   0.03 ( 5%) sys   1.60 (13%)
wall  204964 kB (29%) ggc
 varconst  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall  97 kB ( 0%) ggc
 jump  :   0.31 ( 3%) usr   0.01 ( 2%) sys   0.34 ( 3%)
wall   29427 kB ( 4%) ggc
 branch prediction :   0.13 ( 1%) usr   0.00 ( 0%) sys   0.14 ( 1%)
wall   0 kB ( 0%) ggc
 flow analysis :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.10 ( 1%)
wall   0 kB ( 0%) ggc
 mode switching:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 local alloc   : 

[Bug c/80806] gcc does not warn if local array is memset only

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

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

--- Comment #3 from Daniel Fruzynski  ---
"in" attribute is similar to "const", I am not sure if we need another one for
this.

"out" attribute would be handy. I recall than in the past I was looking for it.
gcc can print warning that uninitialized variable is passed to function. Now
one has to initialize that variable before passing it to function. With this
attribute initialization would not be necessary. Beside silenced warning this
also would produce a bit faster executable.

BTW, C# provides "out" parameter modifier, but no "in".

[Bug c/78503] -Wint-in-bool-context false positive on unsigned multiplication

[jbeulich at novell dot com]

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

jbeulich at novell dot com changed:

   What|Removed |Added

 CC||jbeulich at novell dot com

--- Comment #1 from jbeulich at novell dot com ---
We have something similar in the Xen hypervisor sources:

#define __compat_access_ok(d, addr, size) \
__compat_addr_ok(d, (unsigned long)(addr) + ((size) ? (size) - 1 : 0))

#define compat_access_ok(addr, size) \
__compat_access_ok(current->domain, addr, size)

#define compat_array_access_ok(addr,count,size) \
(likely((count) < (~0U / (size))) && \
 compat_access_ok(addr, (count) * (size)))

Instead of != 0 (which seems rather strange to not have the same effect of
producing a warning) for now we're adding in zero, but the example shows
clearly that replacing * by && is not an option here just like in the original
example.

Assuming that there's no intention to eliminate such false positives, could we
at least get a workaround allowing to suppress the warning which is going to be
usable also on future compiler versions (just like I'd expect the
presence/absence of != 0 to make not difference, I could imagine the + 0 to get
eliminated before inspecting the expression for whether to emit the warning).

Disabling the warning altogether does not seem to be desirable.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Daniel,

> Would you be so kind as to test this on Solaris for me please?  I don't have
> access to a Solaris machine and I've never set it up before, so I wouldn't 
> even
> know where to start to try to build an OpensSolaris VM.

sure, though there's no need at all (except for the .struct part) to do
the testing on Solaris.  I believe there are ready-made Solaris/x86
VirtualBox images, though.  For the multilib problem, you can easily
configure gcc for i686-pc-linux-gnu with --enable-targets=all on a
Linux/x86_64 box (with a few necessary 32-bit development packages
added), so the default multilib is non-x86_64, while the x86_64 multilib
is only used with -m64.

I gave your patch a quick whirl on i386-pc-solaris2.12 (with /bin/as),
and just that multilib problem is still unfixed.  For the (default)
32-bit multilib, the test is skipped as should be, but for the 64-bit
multilib, compilations still lack the required -m64, so they fail with

spawn /var/gcc/regression/trunk/12-gcc/build/gcc/xgcc
-B/var/gcc/regression/trunk/12-gcc/build/gcc/
-I/var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc/ms-sysv
-I/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -Wall -c -o
/var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc/ms-sysv/ms-sysv.o
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c^M
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:62:3:
error: #error Test only valid on x86_64^M
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:102:5:
error: unknown type name '__uint128_t'^M
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:234:34:
error: unknown type name '__uint128_t'^M
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:234:56:
error: unknown type name '__uint128_t'^M
WARNING: Could not build
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c.
FAIL: gcc.target/x86_64/abi/ms-sysv CFLAGS="-O2" generator_args="-p0-5"

as before.  To check how things were otherwise, I just manually
assembled/compiled do-test.S and ms-sysv.c with -m64, linked them into
ms-sysv.exe, which ran successfully, so it seems were getting closer.

However, I still don't understand why you are jumping through all these
hoops in ms-sysv.exp doing the compilations etc. manually rather than
just relying on dg-runtest or similar.  This would avoid all this
multilib trouble nicely, and massivly reduce ms-sysv.exp.

One or two nits about PR management, btw.: it is good practice to take
the PR if you're working on it.  And just add the URL to the patch
submissing into the URL field.

Thanks.

Rainer

[Bug target/78962] i386: Missed optimization: unaligned SSE movs with force_align_arg_pointer

[daniel.santos at pobox dot com]

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

Daniel Santos  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Santos  ---
Fixed

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e67d3d383449dc4680615e44098577f45944e4dc

[Bug target/80819] [5/6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-19
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_set_epi64x (long long __q1, long long __q0)
{
  return __extension__ (__m128i)(__v2di){ __q0, __q1 };
}

so we should go via the vector construction expander.

Confirmed with GCC 7.  GCC 4.8 with -O2 -msse4 yields

combine64:
.LFB638:
.cfi_startproc
movq%rdi, -16(%rsp)
movq-16(%rsp), %xmm0
pinsrq  $1, %rsi, %xmm0
ret

so the dead store is not here.

[Bug target/80820] _mm_set_epi64x shouldn't store/reload for -mtune=haswell, Zen should avoid store/reload, and generic should think about it.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-19
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We need to revisit a lot of the little details for generic tuning
for recent GCC.

[Bug tree-optimization/80821] genmatch conflicting predicates

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-19
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
oops.  will fix (looks like just a missing scope {}).

[Bug middle-end/80764] [8 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in verify_loop_structure, at cfgloop.c:1644)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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