[Bug other/67446] libiberty sha1.c:324 sanitizer runtime error: load of misaligned address 0x62f00011847e for type 'const sha1_uint32', which requires 4 byte alignment

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
According to the source, it assumes the input to the sha1_process_block is
aligned correctly.  It might be a bug in ld passing an incorrect aligned block
to that function.

[Bug other/67446] New: libiberty sha1.c:324 sanitizer runtime error: load of misaligned address 0x62f00011847e for type 'const sha1_uint32', which requires 4 byte alignment

[zeccav at gmail dot com]

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

Bug ID: 67446
   Summary: libiberty sha1.c:324 sanitizer runtime error: load of
misaligned address 0x62f00011847e for type 'const
sha1_uint32', which requires 4 byte alignment
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While building the Fedora 21 kernel 4.1.6-100 with a sanitized version of ld
I got the following sanitizer messages (sha1.c compiled with 
gcc -fsanitize=undefined)
This is sha1.c in libiberty

sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f

sha1.c:324 is

x[t] = SWAP (*words);

so it seems that words is not a multiple of four, but it should point to type
sha1_uint32 which is four bytes aligned.
This is on x86-64 building "LD  init/built-in.o" and the command is

ld -m elf_x86_64 --build-id -X -o .tmp_vmlinux1 -T
./arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o
arch/x86/kernel/head64.o arch/x86/kernel/head.o init/built-in.o --start-group
usr/built-in.o arch/x86/built-in.o kernel/built-in.o mm/built-in.o
fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
block/built-in.o lib/lib.a arch/x86/lib/lib.a lib/built-in.o
arch/x86/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o
arch/x86/pci/built-in.o arch/x86/power/built-in.o arch/x86/video/built-in.o
net/built-in.o --end-group

[Bug c/63336] cilkplus array notation ICE in find_rank

[bviyer at gmail dot com]

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

Balaji V. Iyer  changed:

   What|Removed |Added

 CC||bviyer at gmail dot com

--- Comment #4 from Balaji V. Iyer  ---
Hi Tim,
Can you provide me a simple(r) test case for this?

Thanks,

Balaji V. Iyer.

[Bug middle-end/63510] Wrong line number in Wstrict-overflow message

[gang.chen.5i5j at gmail dot com]

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

--- Comment #12 from Chen Gang  ---
The patch passes "make check". I guess, it should be OK.

[Bug c++/56568] std::initializer_list return value contents lost prematurely

[potswa at mac dot com]

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

--- Comment #5 from David Krauss  ---
(In reply to fuzzyTew from comment #4)

The original testcase is invalid. initializer_list is special in that it
behaves like a reference, so adding && doesn't make a difference.

I'm working on an ISO proposal (http://bit.ly/genlife) to fix some such cases
in C++17, but all it would do for return values is allow the compiler to
produce a warning. The way initializer_list works, the sequence is
intrinsically incapable of escaping the current scope, much less the current
function.

[Bug c++/56568] std::initializer_list return value contents lost prematurely

[fuzzyTew at gmail dot com]

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

--- Comment #4 from fuzzyTew at gmail dot com ---
I'm not as experienced in the details.  I think perhaps my example is invalid
as you state but the original testcase is not (see &&).

[Bug c++/56568] std::initializer_list return value contents lost prematurely

[fuzzyTew at gmail dot com]

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

--- Comment #3 from fuzzyTew at gmail dot com ---
The definition of initializer_list is that the array backing it contains copies
of the listed values and has the same lifetime as the list itself.

If the return value is bound into the object assigned to it, the backing array
should stick around as long as the return value does.

[Bug libgcc/62097] t-hardfp requires GNU sed

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-03
 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Oops, didn't mean to remove myself from the bug completely.
I'd assumed bugzilla would keep me on cc:.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #11 from mrs at gcc dot gnu.org  ---
I'd endorse that step forward.  The export list I think is also doable in some
fashion, but we can leave that for another day.

[Bug fortran/34392] BOZ diagnost invalid Fortran 2003 use with -std=f2003 warnings

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||20585

--- Comment #2 from Dominique d'Humieres  ---
> FLOAT takes the same code path as REAL (w/o kind argument). With -std=f2003
> a BOZ in FLOAD should be rejected.

For 4.6 up to trunk (6.0) with -std=f2003 I get

 print *, float(Z'3FFF0080')
   1
Error: GNU Extension: non-default INTEGER kind argument to float intrinsic at
(1)

> For SNGL: It will probably solved by PR 34505, which should allow only
> real arguments for SNGL.

and

 print *, sngl(Z'3FFF0080')
  1
Error: 'a' argument of 'sngl' intrinsic at (1) must be REAL

4.3.1 up to 4.5 gives

print *, sngl(Z'3FFF0080')
 1
Error: Type of argument 'a' in call to 'sngl' at (1) should be REAL(8), not
INTEGER(16)

What is missing?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
[Bug 20585] [meta-bug] Fortran 2003 support

[Bug c++/67445] New: New warning: returning std::initializer_list bound to temporary

[redi at gcc dot gnu.org]

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

Bug ID: 67445
   Summary: New warning: returning std::initializer_list bound to
temporary
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

It would be useful if -Wreturn-local-addr warned for the following:

std::initializer_list f() {
  return { 1, 2, 3};
}

This creates a temporary array, then returns a std::initializer_list containing
a dangling pointer.

[Bug c++/56568] std::initializer_list return value contents lost prematurely

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to fuzzyTew from comment #1)
> Here's an example I ran into using a plain int:
> http://coliru.stacked-crooked.com/a/1dfad4e209339aa1

That's undefined behaviour. You create a temporary array with one element, then
return an initializer_list which is bound to that local array, which goes out
of scope.

Your example and the original testcase are equivalent to:

const int& f() {
  long i = 0;
  return i;
}

which creates a temporary and binds a reference to it, resulting in a dangling
reference.

std::initializer_list is not a container, don't try to do clever things with
it, you will get burnt.

[Bug c++/56568] std::initializer_list return value contents lost prematurely

[fuzzyTew at gmail dot com]

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

fuzzyTew at gmail dot com changed:

   What|Removed |Added

 CC||fuzzyTew at gmail dot com

--- Comment #1 from fuzzyTew at gmail dot com ---
Here's an example I ran into using a plain int:
http://coliru.stacked-crooked.com/a/1dfad4e209339aa1

[Bug fortran/45170] [F2003] allocatable character lengths

[dominiq at lps dot ens.fr]

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

Bug 51976 Summary: [F2003] Support deferred-length character components of 
derived types (allocatable string length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976

   What|Removed |Added

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

[Bug fortran/56138] Deferred-length character RESULT: ICE in gfc_add_modify_loc

[dominiq at lps dot ens.fr]

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

Bug 51976 Summary: [F2003] Support deferred-length character components of 
derived types (allocatable string length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976

   What|Removed |Added

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

[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #18 from Dominique d'Humieres  ---
> I think the last issues in comment 16 can be tracked by pr54070 and
> this PR closed as FIXED.

No answer since more than a year and a half. Closing as FIXED. Please open new
PRs for new issues.

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

  Known to work||4.8.0
 Blocks||20585
  Known to fail||4.8.1

--- Comment #18 from Dominique d'Humieres  ---
> I found it fixed in 5.2.0

This PR contains 5 tests. Let me label them a, b, and c for the ones in comment
0, d for the one in comment 4 and e for the one in comment 7.

As for today I find that a, c, and e are still giving an ICE with 4.9 up to
trunk (6.0), b compiles with 4.9 up to trunk, and d compiles with 5.2 and
trunk, but still gives an ICE with 4.9.4.

I confirm that revision r188654 compiles a, c, d, and e, but not b.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
[Bug 20585] [meta-bug] Fortran 2003 support

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
FWIW, homebrew has a formula for building libgccjit on OS X:
 https://github.com/Homebrew/homebrew/blob/master/Library/Formula/gcc.rb

Currently it applies this patch:

diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in
index 44d0750..4df2a9c 100644
--- a/gcc/jit/Make-lang.in
+++ b/gcc/jit/Make-lang.in
@@ -85,8 +85,7 @@ $(LIBGCCJIT_FILENAME): $(jit_OBJS) \
 $(jit_OBJS) libbackend.a libcommon-target.a libcommon.a \
 $(CPPLIB) $(LIBDECNUMBER) $(LIBS) $(BACKENDLIBS) \
 $(EXTRA_GCC_OBJS) \
--Wl,--version-script=$(srcdir)/jit/libgccjit.map \
--Wl,-soname,$(LIBGCCJIT_SONAME)
+-Wl,-install_name,$(LIBGCCJIT_SONAME)

 $(LIBGCCJIT_SONAME_SYMLINK): $(LIBGCCJIT_FILENAME)
ln -sf $(LIBGCCJIT_FILENAME) $(LIBGCCJIT_SONAME_SYMLINK)

along with this patch:
  https://gcc.gnu.org/ml/jit/2015-q3/msg00148.html
which is in:
  trunk as r226882.
  gcc-5-branch as r226883.

[Bug fortran/64777] CO_BROADCAST: Finalization/dealloc of alloc components missing

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-09-03
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Test case?

[Bug fortran/37336] [F03] Finish derived-type finalization

[fxcoudert at gcc dot gnu.org]

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

Bug 43849 Summary: Add _gfortran_finalize function to close down the library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug libfortran/43849] Add _gfortran_finalize function to close down the library

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #10 from Francois-Xavier Coudert  ---
Closing as WONTFIX for now. If a real use case (for example co-open array
related) is raised, we can export cleanup() in the future.

[Bug libfortran/43849] Add _gfortran_finalize function to close down the library

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> IMHO, no there isn't a real use case for exporting the cleanup() function.

Does it mean that this PR could be closed? FIXED or WONTFIX?

[Bug libfortran/43849] Add _gfortran_finalize function to close down the library

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist  ---
(In reply to Dominique d'Humieres from comment #7)
> > So, to summarize: we already have a finalization function, cleanup().
> > Should we export it? I am not so sure, unless we have a real use case.
> 
> Could someone answer the question?

IMHO, no there isn't a real use case for exporting the cleanup() function.

[Bug libstdc++/66902] _S_debug_messages is unneccessary public

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Sep  3 19:05:15 2015
New Revision: 227466

URL: https://gcc.gnu.org/viewcvs?rev=227466&root=gcc&view=rev
Log:
PR libstdc++/66902
* src/c++11/debug.cc (_S_debug_messages): Make array const.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/debug.cc

[Bug c/67435] Large performance drop on apparently unrelated changes (potential cause : critical loop instruction alignment)

[yann.collet.73 at gmail dot com]

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

--- Comment #8 from Yann Collet  ---
Thanks for the link.
It's a very good read, and indeed, completely in line with my recent
experience.
Recommended solution seems to be the same : "-falign-loops=32"


The article also mentions that the issue is valid for Sandy Bridge cpus.
This broadens the scope : it's not just about Broadwell, but also Haswell, Ivy
Bridge and sandy Bridge. All new cpus from Intel since 2011. It looks like a
large enough installed base to care about.

However, for some reason, in the table provided, both Sandy Bridge and Haswell
get a default loop alignment value of 16. not 32.

Is there a reason for that choice ?


> Optimizing for just one specific model will negatively affect performance on 
> an other.

Well, this issue is apparently important for more than one architecture.
Moreover, being inlined on 32 imply being inlined on 16 too, so it doesn't
introduce drawback for older siblings.


Since then, I could find a few other complaints about the same issue. One
example here : https://software.intel.com/en-us/forums/topic/479392

and a close cousin here :
http://stackoverflow.com/questions/9881002/is-this-a-gcc-bug-when-using-falign-loops-option


This last one introduce a good question : while it's possible to use
"-falign-loops=32" to set the preference for the whole program, it seems not
possible to set it precisely for a single loop.

It looks like a good feature request, as this loop-alignment issue can have a
pretty large impact on performance (~20%), but only matters for a few selected
critical loops. The programmer is typically in good position to know which loop
matters the most. Hence, we don't necessarily need *all* loops to be 32-bytes
aligned, just a handful ones.

Less precise but still great, having the ability to set this optimization
parameter for a function or a section code would be great. But my experiment
seem to show that using #pragma or __attribute__ with align-loops does not
work, as if the optimization setting was simply ignored.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[egall at gwmail dot gwu.edu]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Eric Gallager from comment #8)
> So anyways... for some reason I also had to add
> "-Wl,-undefined,dynamic_lookup" due to the "environ" symbol being missing,
> which makes no sense to me, because it should be there... But that got it to
> build for me though.
> 

Actually disregard that part; turns out that that was bug 63758...

[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #7 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #4)
> Created attachment 34311 [details]
> Updated patch to catch another use.
> 
> I'm taking this bug, if that's OK 
> I'd like to post the revised patch to @patches
> ... but Roland can you confirm that's OK with you?

Re: the location of the "environ.h" added: could you put it in the include/
directory instead of in the libiberty/ directory, so that other directories in
the tree can use it more easily? libgcj, for instance, could use it, too, to
solve bug 38812, apparently...

[Bug libgcj/38812] gcj-built executables don't run after strip (libgcj erroneously references _environ)

[egall at gwmail dot gwu.edu]

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

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> There's also some places where environ is used as an extern variable in
> libiberty that would need similar fixes; specifically in pex-unix.c and
> xmalloc.c.

...and it turns out that that is bug 63758, for reference... (sorry for the
digression; I hadn't seen the other one previously...)

[Bug middle-end/67438] [6 Regression] ~X op ~Y pattern relocation causes loop performance degradation on 32bit x86

[miyuki at gcc dot gnu.org]

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

--- Comment #6 from Mikhail Maltsev  ---
(In reply to rguent...@suse.de from comment #5)
> For the case above, why is a_14 = ~_13 not sunk to the edge
> 3->4 and b_18 = ~_17 to the edge 3->5?  (yes, this creates
> additional BBs)  This would reduce register pressure.

I think, because a_14 and b_18 are used in the next bb. Actually I wrote only
part of bb6. The full dump looks like this:

  :
  # d_4 = PHI 
  out_26 = out_3 + 1;
  *out_3 = a_14;
  out_29 = &MEM[(void *)out_3 + 2B];
  MEM[(char *)out_3 + 1B] = b_18;
  out_32 = &MEM[(void *)out_3 + 3B];
  MEM[(char *)out_3 + 2B] = c_22;
  out_35 = &MEM[(void *)out_3 + 4B];
  MEM[(char *)out_3 + 3B] = d_4;

  :
  # n_1 = PHI 
  # in_2 = PHI 
  # out_3 = PHI 
  n_10 = n_1 + -1;
  if (n_10 != 0)
goto ;
  else
goto ;

  :
  return;


> Maybe this kind of scheduling can be considered when register pressure
> is high (does -fsched-pressure -fschedule-insns help?)

Not much. With -fsched-pressure -fschedule-insns we generate 2 insns less:

.L7:
movzbl  0(%ebp), %edi   # MEM[base: in_70, offset: 0B], D.1940
addl$3, %ebp#, in
movzbl  -2(%ebp), %esi  # MEM[base: in_70, offset: 1B], D.1940
movl%edi, %eax  # D.1940, a
movzbl  -1(%ebp), %edx  # MEM[base: in_30, offset: 4294967295B],
MEM[base: in_30, offset: 4294967295B]
notl%eax# a
movb%al, (%ebx) # a, MEM[base: out_71, offset: 0B]
movl%esi, %ecx  # D.1940, b
notl%ecx# b
movb%cl, 1(%ebx)# b, MEM[base: out_71, offset: 1B]
notl%edx# c
movb%dl, 2(%ebx)# c, MEM[base: out_71, offset: 2B]
cmpb%dl, %al# c, a
cmovg   %edx, %eax  # d,, c, d
cmpb%dl, %cl# c, b
movb%al, 4(%esp)# tmp277, %sfp
cmovle  %ecx, %edx  # b,, d
movl%esi, %eax  # D.1940, D.1940
movl%edi, %ecx  # D.1940, D.1940
addl$4, %ebx#, out
cmpb%al, %cl# D.1940, D.1940
movzbl  4(%esp), %eax   # %sfp, d
cmovg   %eax, %edx  # d,, d
cmpl8(%esp), %ebp   # %sfp, in
movb%dl, -1(%ebx)   # d, MEM[base: out_11, offset: 4294967295B]
jne .L7 #,

I wonder, whether a transformation like this could help:

bb1:
  x = min(a, c)
  goto bb3
bb2:
  y = min(b, c)
  goto bb3
bb3:
  z = phi(x, y) // x and y are single-use

--->

bb1:
  x = a
  goto bb3
bb2:
  y = b
  goto bb3
bb3:
  z' = phi(x, y)
  z = min(z', c)

Though if we don't simplify phi(x, y), we would increase register pressure even
more.

[Bug c/66516] missing diagnostic on taking the address of a builtin function

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Sep  3 16:23:11 2015
New Revision: 227458

URL: https://gcc.gnu.org/viewcvs?rev=227458&root=gcc&view=rev
Log:
gcc/ChangeLog
2015-09-03  Martin Sebor  

PR c/66516
* doc/extend.texi (Other Builtins): Document when the address
of a built-in function can be taken.

gcc/c-family/ChangeLog
2015-09-03  Martin Sebor  

PR c/66516
* c-common.h (c_decl_implicit, reject_gcc_builtin): Declare new
functions.
* c-common.c (reject_gcc_builtin): Define.

gcc/c/ChangeLog
2015-09-03  Martin Sebor  

PR c/66516
* c/c-typeck.c (convert_arguments, parser_build_unary_op)
(build_conditional_expr, c_cast_expr, convert_for_assignment)
(build_binary_op, _objc_common_truthvalue_conversion): Call
reject_gcc_builtin.
(c_decl_implicit): Define.

gcc/cp/ChangeLog
2015-09-03  Martin Sebor  

PR c/66516
* cp/cp-tree.h (mark_rvalue_use, decay_conversion): Add new
argument(s).
* cp/expr.c (mark_rvalue_use): Use new argument.
* cp/call.c (build_addr_func): Call decay_conversion with new
argument.
* cp/pt.c (convert_template_argument): Call reject_gcc_builtin.
* cp/typeck.c (decay_conversion): Use new argument.
(c_decl_implicit): Define.

gcc/testsuite/ChangeLog
2015-09-03  Martin Sebor  

PR c/66516
* g++.dg/addr_builtin-1.C: New test.
* gcc.dg/addr_builtin-1.c: New test.

Added:
trunk/gcc/builtins.c.orig
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/expr.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug fortran/67444] RHS in assignment of polymorphic types not finalized

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-03
 Blocks||37336
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk (6.0). I have marked this PR as blocking
pr37336. I have also added several other PRs to the list blocking pr37336.
Could you please check that this PR is not a duplicate of one of them (being
OOP challenged I have no idea of what finalization is doing)?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

[Bug fortran/66291] [OOP] Incorrect compile time warning for final procedure in gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Dup.

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

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

[dominiq at lps dot ens.fr]

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

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

[Bug fortran/37336] [F03] Finish derived-type finalization

[dominiq at lps dot ens.fr]

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

Bug 66291 Summary: [OOP] Incorrect compile time warning for final procedure in 
gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66291

   What|Removed |Added

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

[Bug fortran/66291] [OOP] Incorrect compile time warning for final procedure in gfortran

[casey.webster at gmail dot com]

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

--- Comment #2 from Casey Webster  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed from 4.9 up to trunk (6.0). Note that I did not try the patch (it
> should be submitted to fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org with
> a ChangeLog entry.

I'll doublecheck the patch works against trunk and submit it.

[Bug libstdc++/62258] [4.9/5 Regression] uncaught_exception() equals to `true' after rethrow_exception()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #21 from Jonathan Wakely  ---
Fixed in 4.9.4, 5.3 and 6.0

[Bug libfortran/43849] Add _gfortran_finalize function to close down the library

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||37336

--- Comment #7 from Dominique d'Humieres  ---
> So, to summarize: we already have a finalization function, cleanup().
> Should we export it? I am not so sure, unless we have a real use case.

Could someone answer the question?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

[Bug fortran/66291] [OOP] Incorrect compile time warning for final procedure in gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-03
 Blocks||37336
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk (6.0). Note that I did not try the patch (it
should be submitted to fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org with a
ChangeLog entry.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

[Bug libstdc++/62258] [4.9/5 Regression] uncaught_exception() equals to `true' after rethrow_exception()

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
Author: redi
Date: Thu Sep  3 16:02:07 2015
New Revision: 227456

URL: https://gcc.gnu.org/viewcvs?rev=227456&root=gcc&view=rev
Log:
Backport fix for PR libstdc++/62258 from mainline

2015-04-27  Dmitry Prokoptsev  
Michael Hanselmann  

PR libstdc++/62258
* libsupc++/eh_ptr.cc (rethrow_exception): Increment count of
uncaught exceptions.
* testsuite/18_support/exception_ptr/62258.cc: New.

Added:
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/18_support/exception_ptr/62258.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/libsupc++/eh_ptr.cc

[Bug libstdc++/66998] not_fn invocation is not SFINAE friendly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/67374] std::cbegin can't call valarray range access functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 5.3

[Bug libstdc++/66855] codecvt wrong endianness in UTF-16 conversions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 5.3 and 6.0

[Bug libstdc++/66998] not_fn invocation is not SFINAE friendly

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Thu Sep  3 15:10:52 2015
New Revision: 227455

URL: https://gcc.gnu.org/viewcvs?rev=227455&root=gcc&view=rev
Log:
Make std::experimental::not_fn SFINAE-friendly.

PR libstdc++/66998
* include/experimental/functional (_Not_fn): Add exception
specifications and non-deduced return types.
(not_fn): Add exception specification and wrap pointer-to-member.
* testsuite/experimental/functional/not_fn.cc: Test in SFINAE context
and test pointer-to-member.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/experimental/functional
   
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/functional/not_fn.cc

[Bug libstdc++/67374] std::cbegin can't call valarray range access functions

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Sep  3 15:10:42 2015
New Revision: 227454

URL: https://gcc.gnu.org/viewcvs?rev=227454&root=gcc&view=rev
Log:
Backport libstdc++/67374 fix from mainline

2015-08-27  Jonathan Wakely  

PR libstdc++/67374
* include/bits/range_access.h (valarray, begin, end): Declare.
* testsuite/26_numerics/valarray/range_access.cc: Test const
overloads.
* testsuite/26_numerics/valarray/range_access2.cc: New.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/26_numerics/valarray/range_access2.cc
  - copied, changed from r227453,
branches/gcc-5-branch/libstdc++-v3/testsuite/26_numerics/valarray/range_access.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/range_access.h
   
branches/gcc-5-branch/libstdc++-v3/testsuite/26_numerics/valarray/range_access.cc

[Bug libstdc++/62258] [4.9/5 Regression] uncaught_exception() equals to `true' after rethrow_exception()

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
Author: redi
Date: Thu Sep  3 15:10:25 2015
New Revision: 227451

URL: https://gcc.gnu.org/viewcvs?rev=227451&root=gcc&view=rev
Log:
Backport fix for PR libstdc++/62258 from mainline

2015-04-27  Dmitry Prokoptsev  
Michael Hanselmann  

PR libstdc++/62258
* libsupc++/eh_ptr.cc (rethrow_exception): Increment count of
uncaught exceptions.
* testsuite/18_support/exception_ptr/62258.cc: New.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/18_support/exception_ptr/62258.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/libsupc++/eh_ptr.cc

[Bug libstdc++/66855] codecvt wrong endianness in UTF-16 conversions

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Sep  3 15:10:32 2015
New Revision: 227452

URL: https://gcc.gnu.org/viewcvs?rev=227452&root=gcc&view=rev
Log:
Backport PR libstdc++/66855 fix from mainline

2015-07-13  Jonathan Wakely  

PR libstdc++/66855
* src/c++11/codecvt.cc (__codecvt_utf8_utf16_base::do_in): Override
endianness bit in mode.
* testsuite/22_locale/codecvt/codecvt_utf8_utf16/66855.cc: New.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8_utf16/66855.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/src/c++11/codecvt.cc

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #24 from Vladimir Makarov  ---
(In reply to Fredrik Hederstierna from comment #23)
> Thanks for your patch, I tried it out, and it solves the small example fine,
> the code now is similar to GCC 4.8 for this particular example.
> 
> Though when I ran the full CSiBE benchmark, the code size unfortunately grew
> approx +150 bytes overall for the full suite. So the patch did not solve the
> generic root problem with code size increase unfortunately.
> 
> This is strange and I'm thinking of how to continue from here, this issue
> has diverged a bit too much (mostly because of my own fault) with several
> examples etc. Do you think we should create separate issues for different
> small examples that compiles bad perhaps? but on the same time we need to
> keep track on the 'generic' overall code size issue as eg. CSiBE points out.
> 

Either way will work for me.  The most important is to have test cases
somewhere in Bigzilla on which I could work.

I did not expect that the patch solves CSiBE code size degradation.  Therefore
I wrote "a patch for" instead of "patch solving the problem".

I expect it will be a long work to solve the problem.

> Here's is another small example I tested yesterday that also gives
> unnecessary moves, both for arm7tdmi, arm966e-s and cortex-m0 tested.
> 

Thanks.  I'll will investigate it.

[Bug libstdc++/62039] concept checking for std::prev

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
done for both std::next and std::prev

[Bug libstdc++/66998] not_fn invocation is not SFINAE friendly

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Sep  3 14:36:03 2015
New Revision: 227448

URL: https://gcc.gnu.org/viewcvs?rev=227448&root=gcc&view=rev
Log:
Make std::experimental::not_fn SFINAE-friendly.

PR libstdc++/66998
* include/experimental/functional (_Not_fn): Add exception
specifications and non-deduced return types.
(not_fn): Add exception specification and wrap pointer-to-member.
* testsuite/experimental/functional/not_fn.cc: Test in SFINAE context
and test pointer-to-member.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/functional
trunk/libstdc++-v3/testsuite/experimental/functional/not_fn.cc

[Bug libstdc++/62039] concept checking for std::prev

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Sep  3 14:35:43 2015
New Revision: 227447

URL: https://gcc.gnu.org/viewcvs?rev=227447&root=gcc&view=rev
Log:
Add concept checks to std::next and std::prev.

PR libstdc++/62039
* include/bits/stl_iterator_base_funcs.h (next, prev): Add concept
checks.
* testsuite/24_iterators/operations/prev_neg.cc: New.
* testsuite/24_iterators/operations/next_neg.cc: New.

Added:
trunk/libstdc++-v3/testsuite/24_iterators/operations/next_neg.cc
trunk/libstdc++-v3/testsuite/24_iterators/operations/prev_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_iterator_base_funcs.h

[Bug fortran/67444] RHS of overloaded assignment not finalized

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Severity|blocker |normal

[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Nick Clifton from comment #5)
> Ping ?
> 
> The patch works for us, and fixes a problem that a customer was having, so
> we would really like to see it checked in.

If I don't hear anything by the weekend, I'll post a rebased patch to @patches
(it's been in my local tree since ….)

[Bug target/67439] [4.9/5/6 Regression]ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/67439] [4.9/5/6 Regression]ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
-mrestrict-it was introduced in 4.9 but it's enabled by default for
-march=armv8-a -mthumb. So, while -mrestrict-it did not exist for 4.8, this is
a regression from 4.8 as far as compiling with -march=armv8-a -mthumb is
concerned

[Bug target/67439] [4.9/5/6 Regression]ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target|arm-unknown-linux-gnueabi   |arm*
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
Summary|ICE: unrecognizable insn|[4.9/5/6 Regression]ICE:
   |compiling arm-fp16  |unrecognizable insn
   |testcases with  |compiling arm-fp16
   |-march=armv7-a and  |testcases with
   |-mrestrict-it   |-march=armv7-a and
   ||-mrestrict-it

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Mine.

[Bug fortran/67444] New: RHS of overloaded assignment not finalized

[baradi09 at gmail dot com]

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

Bug ID: 67444
   Summary: RHS of overloaded assignment not finalized
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

Created attachment 36291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36291&action=edit
Fortran file demonstrating the issue

Dear developer,

Thank you for your continuous effort to provide a free Fortran compiler with
OOP-features.

In my oppinion, Gfortran behaves incorrectly, when instances of polymorphic
types with user defined constructors are assigned to each other. Having an
assignment of the type

a = MyType()

where also "a" is type(MyType) I'd expect expect following calling sequence:

* Constructor for MyType() producing the LHS
* Destructor (final procedure) of MyType finalizing instance "a"
* Assignment of MyType
* Destructor for MyType to finalize the RHS of the assignment.

According to the attached example, however, the last step is missing. I've
checked the example with two other compilers, they all produced the sequence as
given above. With gfortran, I get the output

Starting using Basic:
initBasic START
initBasic END
Destructing Basic -1
assignBasic START
assignBasic END
Values in basic:  43
Destructing Basic 43

while the correct one (with the additional line 7) should be.

Starting using Basic:
initBasic START
initBasic END
Destructing Basic -1
assignBasic START
assignBasic END
Destructing Basic 42
Values in basic:  43
Destructing Basic 43

[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #5 from Nick Clifton  ---
Ping ?

The patch works for us, and fixes a problem that a customer was having, so we
would really like to see it checked in.

Cheers
  Nick

[Bug target/67439] ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||4.9.4, 5.2.1, 6.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Ok, I think I see the problem here.
*arm32_movhf should not just have a !arm_restrict_it in its predicate, it
should disable the alternatives in a smarter way.
I'll see what I can do.

[Bug libstdc++/67434] std::chrono::duration acts like static even if instantiated every time

[sthlm58 at gmail dot com]

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

--- Comment #2 from sthlm58 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Michal Kucharski from comment #0)
> > std::chrono::duration benchmark( ) 
> > {
> >   std::random_device rd;
> > 
> >   std::chrono::duration total;
> 
> You have not initialized this variable.
> 
> >   
> >   for (int i = 0; i < 100; i++) 
> >   {
> >  auto t1 = std::chrono::high_resolution_clock::now();
> >  auto t2 = std::chrono::high_resolution_clock::now();
> >  total += std::chrono::duration_cast>(t2 -
> > t1);
> 
> This has undefined behaviour because you are performing addition on an
> uninitialized value. You could have found this with valgrind.

In other words, here 'total' was default-initialized (hence unspecified) thus
causing undefined behavior. It it were value-initialized e.g. with '{}' the
problem would not happen.

[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from vries at gcc dot gnu.org ---
patch series committed to trunk, with testcases (made possible by the
introduction of --param parloops-chunk-size)

[Bug target/67439] ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-03
 CC||alalaw01 at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
I can reproduce the ICE with -mthumb, both "-mfloat-abi=hard -mfpu=neon" and
"-mfloat-abi=soft", but only with -mrestrict-it in both cases.
"-mfloat-abi=hard -mfpu=neon-fp16" is OK with and without -mrestrict-it.

I note the movhf patterns in vfp.md are only usable with neon-fp16; in other
cases, we appear to be using arm32_movhf in arm.md.

[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested

[vries at gcc dot gnu.org]

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

--- Comment #13 from vries at gcc dot gnu.org ---
Author: vries
Date: Thu Sep  3 11:01:14 2015
New Revision: 227437

URL: https://gcc.gnu.org/viewcvs?rev=227437&root=gcc&view=rev
Log:
Fix inner loop phi in expand_omp_for_static_chunk

2015-09-03  Tom de Vries  

PR tree-optimization/65637
* omp-low.c (find_phi_with_arg_on_edge): New function.
(expand_omp_for_static_chunk): Fix inner loop phi.

* testsuite/libgomp.c/autopar-2.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/autopar-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/libgomp/ChangeLog

[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested

[vries at gcc dot gnu.org]

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

--- Comment #14 from vries at gcc dot gnu.org ---
Author: vries
Date: Thu Sep  3 11:01:22 2015
New Revision: 227438

URL: https://gcc.gnu.org/viewcvs?rev=227438&root=gcc&view=rev
Log:
Handle 2 preds for fin_bb in expand_omp_for_static_chunk

2015-09-03  Tom de Vries  

PR tree-optimization/65637
* omp-low.c (expand_omp_for_static_chunk): Handle case that fin_bb has
2
predecessors.

* gcc.dg/autopar/reduc-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/reduc-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
Author: vries
Date: Thu Sep  3 11:01:05 2015
New Revision: 227436

URL: https://gcc.gnu.org/viewcvs?rev=227436&root=gcc&view=rev
Log:
Fix gcc_assert in expand_omp_for_static_chunk

2015-09-03  Tom de Vries  

PR tree-optimization/65637
* omp-low.c (expand_omp_for_static_chunk): Fix gcc_assert for the case
that head is NULL.

* gcc.dg/autopar/pr46099-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr46099-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Assert triggers through

/space/rguenther/src/svn/trunk2/gcc/testsuite/g++.dg/tree-ssa/pr49911.C:8:22:
internal compiler error: in wide_int_to_tree, at tree.c:1398^M
0xf49a69 wide_int_to_tree(tree_node*,
generic_wide_int > const&)^M
/space/rguenther/src/svn/trunk2/gcc/tree.c:1398^M
0xcab4e4 set_min_and_max_values_for_integral_type(tree_node*, int, signop)^M
/space/rguenther/src/svn/trunk2/gcc/stor-layout.c:2645^M
0x62c701 finish_enum_value_list(tree_node*)^M
/space/rguenther/src/svn/trunk2/gcc/cp/decl.c:13267^M

-fstrict-enums related.  set_min_and_max_values_for_integral_type
doesn't handle differing sgn correctly.

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[jiwang at gcc dot gnu.org]

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

--- Comment #4 from Jiong Wang  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> cc1 is invoked like this for a 32-bit-default configuration:
> 
> $ cc1 -quiet wide-shift-64.c -mcpu=v9 -O2 -fdump-rtl-combine -o
> wide-shift-64.s
> 
>   Rainer

Thanks, I basically understand where is the problem. By some option combination
sparc will enable target private wide shift pattern to override the middle-end
generic optimization, as the generic optimization honor target private
mechanism by the follow checking at expr.c:

 && ! have_insn_for (ASHIFT, mode)  

although the target private wide shift generate worse code.

I can't reproduce this issue by the following configure on trunk

../gcc-git-official/configure --enable-tls --target=sparc-linux
--enable-languages=c,c++

While after search sparc source code, I found sparc defined target private wide
shift, but it's only enabled when "TARGET_ARCH64 || TARGET_V8PLUS", then only
used when "! TARGET_ARCH64"

(define_expand "ashldi3"
  "TARGET_ARCH64 || TARGET_V8PLUS"
{
  if (! TARGET_ARCH64)

So, the testcase failed when I pass -mv8plus and -mcpu=v9 at the same time
which enable sparc target wide shift under 32bit.

[FAIL]./cc1 -quiet wide-shift-64.c -O2 -fdump-rtl-combine -nostdinc -mv8plus
-mcpu=v9

Jeff was suggesting we add cost check in generic code to make better decision
whether generic code should honor target private pattern.

Currently, I think we can just skip sparc for this testcase as I haven't found
good way in dejagnu to just skip when "-mv8plus" specified.

gcc-bugs@gcc.gnu.org

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
As stated above, there is no way to fix this right now, and the current
behaviour is allowed by the standard.

[Bug tree-optimization/67351] Missed optimisation on 64-bit field compared to 32-bit

[naveenh at gcc dot gnu.org]

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

--- Comment #9 from naveenh at gcc dot gnu.org ---
Author: naveenh
Date: Thu Sep  3 10:20:03 2015
New Revision: 227432

URL: https://gcc.gnu.org/viewcvs?rev=227432&root=gcc&view=rev
Log:
2015-09-03  Naveen H.S  

PR middle-end/67351

gcc/ChangeLog: 
* fold-const.c (fold_binary_loc) : Move 
Transform (x >> c) << c into x & (-1<> c into x & ((unsigned)-1 >> c) for unsigned
types using simplify and match.
* match.pd (lshift (rshift @0 INTEGER_CST@1) @1) : New simplifier.
(rshift (lshift @0 INTEGER_CST@1) @1) : New Simplifier.

gcc/testsuite/ChangeLog: 
* g++.dg/pr66752-2.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/pr67351.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/67440] pretty-printing of a const set fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-03
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
We've had so many problems relating to that find_type function, but the change
looks good (assuming all the existing tests still pass with it :-)

Please post it to gcc-patches@ + libstdc++@ and go ahead and commit it, thanks.

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Bootstrap finished with that assert and the fix (c,c++,fortran only, expanding
that now).  I'm going to commit the varasm.c change if testing is fine.

[Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #17 from Richard Biener  ---
Comment 4 is also fixed, the original testcase as well.

[Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Mikhail Maltsev from comment #14)
> Another reproducer:
> 
> $ cat genmodes.cc 
> inline char *strchr(const char *, int) __asm("strchr");
> inline char *strchr(const char *, int)
> {
>   return __builtin_strchr(0, 0);
> }
> 
> int make_complex_modes()
> {
>   if (strchr(0, 0))
> return 1;
> }
> 
> $ cc1plus -O -flto genmodes.cc -quiet -o - | as -o genmodes.o
> $ lto1 genmodes.o -g -o /dev/null -quiet
> genmodes.cc: In function 'make_complex_modes':
> genmodes.cc:11:1: internal compiler error: in gen_inlined_subroutine_die, at
> dwarf2out.c:19910

This one i fixed recently.

[Bug target/67439] ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alan.lawrence at arm dot com,
   ||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Is -mrestrict-it needed to reproduce this?

[Bug ipa/66705] [5/6 Regression] section is missing linker error with -flto -fipa-pta

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||5.2.0

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

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
/space/rguenther/src/svn/trunk2/gcc/genmatch.c:4640:1: internal compiler
error:in wide_int_to_tree, at tree.c:1398
 }
 ^
0x12cfa95 wide_int_to_tree(tree_node*,
generic_wide_int > const&)
/space/rguenther/src/svn/trunk2/gcc/tree.c:1398
0x133cd51 output_constant
/space/rguenther/src/svn/trunk2/gcc/varasm.c:4702

so we don't get very far.  Of course

  else if (TREE_CODE (exp) == INTEGER_CST)
exp = wide_int_to_tree (saved_type, exp);

is just a stupid way to write fold_convert (saved_type, exp).  Or not, if
the special wide_int_to_tree behavior was desired.

Seems we get a bit further with the above "fixed".

[Bug ipa/66705] [5/6 Regression] section is missing linker error with -flto -fipa-pta

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Sep  3 09:25:35 2015
New Revision: 227431

URL: https://gcc.gnu.org/viewcvs?rev=227431&root=gcc&view=rev
Log:
2015-09-03  Richard Biener  

PR ipa/66705
* tree-ssa-structalias.c (ctor_for_analysis): New function.
(create_variable_info_for_1): Use ctor_for_analysis instead
of get_constructor.
(create_variable_info_for): Likewise.

* g++.dg/lto/pr66705_0.C: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/lto/pr66705_0.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-ssa-structalias.c

[Bug ipa/66705] [5/6 Regression] section is missing linker error with -flto -fipa-pta

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Sep  3 09:24:51 2015
New Revision: 227430

URL: https://gcc.gnu.org/viewcvs?rev=227430&root=gcc&view=rev
Log:
2015-09-03  Richard Biener  

PR ipa/66705
* tree-ssa-structalias.c (ctor_for_analysis): New function.
(create_variable_info_for_1): Use ctor_for_analysis instead
of get_constructor.
(create_variable_info_for): Likewise.

* g++.dg/lto/pr66705_0.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr66705_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug rtl-optimization/67441] Scheduler unable to disambiguate memory references in unrolled loop

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The unroller should at least set MEM_OFFSET_KNOWN_P to false.

[Bug rtl-optimization/67441] Scheduler unable to disambiguate memory references in unrolled loop

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Hum - it's a bug that the unroller leaves the same MEM_EXPRs because now the
later load/store does not seem to alias one with an adjusted MEM, like for

 for (i = 0; i < SIZE; i++)
  {
x[i] = x[i] + 1.0;
x[i+1] = x[i+1] + 2.0;
  }

we'd get invalid non-alias answers from the orcale for an unrolled body.

Not sure if there is any transform that would result in invalid code though
(well, scheduling, of course...).

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

  Attachment #36275|0   |1
is obsolete||

--- Comment #3 from Rainer Orth  ---
Created attachment 36290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36290&action=edit
wide-shift-64.c.219r.combine

32-bit dump

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Jiong Wang  ---
> (In reply to Rainer Orth from comment #0)
>> Created attachment 36275 [details]
>> wide-shift-64.c.219r.combine
>> 
>> The new gcc.dg/wide-shift-64.c testcase FAILs on SPARC for the 64-bit
>> multilib
>> only:
>> 
>> FAIL: gcc.dg/wide-shift-64.c scan-rtl-dump-not combine "ior"
>> 
>> I'm attaching the dump.
>
> Rainer,
>
>   I am trying to reproduce this on my cross environment while I can't.
>
>   And searching in your dump file, I haven't found "ior" so the testcase 
> should
> have passed. 

I just noticed I must have been dreaming when submitting this bug
report: it's the *32-bit* case that fails, not the 64-bit one.  I'm
attaching the correct dump this time.

>   Can you please have a quick looks at the compile options used when testing
> this testcase in your multi-lib environment, then I can reproduce in my local
> sparc x86 cross env where I only have cc1 configured with 
> --target=sparc-linux.

cc1 is invoked like this for a 32-bit-default configuration:

$ cc1 -quiet wide-shift-64.c -mcpu=v9 -O2 -fdump-rtl-combine -o wide-shift-64.s

Rainer

[Bug fortran/61960] internal compiler error: in gfc_conv_component_ref

[geertjan.bex at uhasselt dot be]

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

--- Comment #5 from Geert Jan Bex  ---
Dear,

Sorry, this is too long ago, I've lost the context of this.

I guess it is okay to consider the issue solved.

Thanks, best regards, -gjb-

On Sun, Aug 30, 2015 at 5:28 PM, dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61960
>
> --- Comment #4 from Dominique d'Humieres  ---
> > Is not this PR fixed by revision r220899?
>
> PING! Without answer I'll close this PR as FIXED.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Ok, so fold_convert_const_int_from_int makes sure to use a widest_int.  So
the fold code in question should do the same?  But then I suppose overflow
detection doesn't work anymore.

Un-assigning for now, I'm going to be on vacation starting from tomorrow.

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Ok, truncation also should work, thus

  gcc_assert (prec <= pcst.get_precision ());

(trying to see how far bootstrap goes with that)

[Bug c++/67337] [4.9/5/6 Regression] Segmentation fault on a template class

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |trippels at gcc dot 
gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
Patch was posted https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01402.html.
But I think that Jason (the C++ maintainer) currently is enjoying his
holidays...

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
I wonder how many bugs of this kind we have lurking in the tree... It works
fine when type has the same signedness as pcst of course, but as we don't
know pcst sign we can't check for that case...  The only way to get all
places that need auditing is to assert the precisions match :(

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
That is,

tree
wide_int_to_tree (tree type, const wide_int_ref &pcst)
{
...
  unsigned int prec = TYPE_PRECISION (type);
  signop sgn = TYPE_SIGN (type);
...
  wide_int cst = wide_int::from (pcst, prec, sgn);

is according to its docs "The value is extended from its precision according to
the sign of the type", but that isn't what anyone would expect.  IIRC
the wide_int_ref doesn't have a "sign", so we can't do the correct thing.

So IMHO we should require pcst.get_precision () == prec and maybe offer an
overload

tree
wide_int_to_tree (tree type, const wide_int_ref &pcst, signop sgn);

that can specify the sign of pcst (or maybe require that always...).

[Bug c++/67337] [4.9/5/6 Regression] Segmentation fault on a template class

[bastien.noverraz at gmail dot com]

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

--- Comment #3 from Bastien Noverraz  ---
The proposed fix work for Synthese on a Debian 8 with GCC 4.9.2

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
tree built by

0x009f4f2a in associate_trees (loc=0, t1=0x769ea230, 
t2=0x769e9378, code=MULT_EXPR, type=0x768d09d8)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:919
919   return build2_loc (loc, code, type, fold_convert_loc (loc, type,
t1),
920  fold_convert_loc (loc, type, t2));

#1  0x00a1870e in fold_binary_loc (loc=0, code=MULT_EXPR, 
type=0x768d09d8, op0=0x769ea208, op1=0x769fe0e0)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:9565
#2  0x00a2653c in fold_build2_stat_loc (loc=0, code=MULT_EXPR, 
type=0x768d09d8, op0=0x769ea208, op1=0x769fe0e0)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12422
#3  0x00a09f78 in extract_muldiv_1 (t=0x769ea1b8, 
c=0x768e9318, code=MULT_EXPR, wide_type=0x768d09d8, 
strict_overflow_p=0x7fffc747)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:6153
#4  0x00a088d9 in extract_muldiv (t=0x769ea1b8, c=0x768e9318, 
code=MULT_EXPR, wide_type=0x768d09d8, strict_overflow_p=0x7fffc747)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:5877

so extract_muldiv goes berzerk somewhere (ugh, how I hate this beast...)

Hmm, no, it looks wide-int related:

  /* If these are the same operation types, we can associate them
 assuming no overflow.  */
  if (tcode == code)
{
  bool overflow_p = false;
  bool overflow_mul_p;
  signop sign = TYPE_SIGN (ctype);
  wide_int mul = wi::mul (op1, c, sign, &overflow_mul_p);
  overflow_p = TREE_OVERFLOW (c) | TREE_OVERFLOW (op1);
  if (overflow_mul_p
  && ((sign == UNSIGNED && tcode != MULT_EXPR) || sign == SIGNED))
overflow_p = true;
  if (!overflow_p)
return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
wide_int_to_tree (ctype, mul));

so we have op1 == -2, c == 2, both 'int' but ctype is unsinged long.  What
wide_int_to_tree does now is _not_ sign-extend mul properly!?

Richard?

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Seems this started with r210113 - wide_int merge.

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
Version|unknown |5.2.0
   Keywords||wrong-code
   Last reconfirmed||2015-09-03
  Component|target  |middle-end
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|GCC 5.2.0 on x86_64 creates |[5/6 Regression] GCC 5.2.0
   |invalid address on specific |on x86_64 creates invalid
   |array index calculation |address on specific array
   |through pointer |index calculation through
   ||pointer
   Target Milestone|--- |5.3
  Known to fail||5.2.0, 6.0

--- Comment #1 from Richard Biener  ---
Confirmed on x86_64 and the 5 branch with -O1 even:

main:
.LFB0:
.cfi_startproc
movabsq $foo+4294967408, %rax
movswl  (%rax), %eax
ret

.original has:

  short int value = *(bar + (sizetype) (((long unsigned int) i * (long unsigned
int) j) * 4294967292 + 16));

works correctly with -fstrict-overflow (or -O2).  Some bug in folding
somewhere.

4.8 and 4.9 have

  short int value = *(bar + (sizetype) (((long unsigned int) i * (long unsigned
int) j) * 18446744073709551612 + 16));

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3
Summary|[5 regression] DSE removes  |[5/6 regression] DSE
   |required store instruction  |removes required store
   ||instruction

[Bug middle-end/67438] [6 Regression] ~X op ~Y pattern relocation causes loop performance degradation on 32bit x86

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 3 Sep 2015, miyuki at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67438
> 
> Mikhail Maltsev  changed:
> 
>What|Removed |Added
> 
>  CC||miyuki at gcc dot gnu.org
> 
> --- Comment #4 from Mikhail Maltsev  ---
> I looked at gimple dumps. The only difference looks like this. In the "good"
> revision after forwprop1:
> 
>   :
>   _13 = *in_2;
>   a_14 = ~_13;
>   _17 = MEM[(char *)in_2 + 1B];
>   b_18 = ~_17;
>   in_20 = &MEM[(void *)in_2 + 3B];
>   _21 = MEM[(char *)in_2 + 2B];
>   c_22 = ~_21;
>   if (a_14 < b_18)
> goto ;
>   else
> goto ;
> 
> In the "bad" revision this basic block is simplified:
> 
>   :
>   _13 = *in_2;
>   a_14 = ~_13;
>   _17 = MEM[(char *)in_2 + 1B];
>   b_18 = ~_17;
>   in_20 = &MEM[(void *)in_2 + 3B];
>   _21 = MEM[(char *)in_2 + 2B];
>   c_22 = ~_21;
>   if (_13 > _17)
> goto ;
>   else
> goto ;
> 
> Next BB's are:
> 
>   : d_23 = MIN_EXPR ;
>   : d_24 = MIN_EXPR ;
>   : # d_4 = PHI 
> 
> The condition of "if" is not altered throughout all other passes (it gets
> if-converted and vectorized).
> 
> Another small difference: VRP adds assertions in bb 4 (a_12 lt_expr b_14, b_14
> gt_expr a_12) and bb5 (a_12 ge_expr b_14, b_14 le_expr a_12). For some reason
> this does not happen in the "bad" revision.
> 
> As I understand, the problem is that if we do not fold the condition, values
> _13 and _17 are killed after we calculate a_14 = ~_13 and b_18 = ~_17. But if
> we do fold, they are still live (because they are used in the condition), 
> thus,
> register pressure increases.

Yes.  Note that because of :s implementation details "fixing"

/* Fold ~X op ~Y as Y op X.  */
(for cmp (simple_comparison)
 (simplify
  (cmp (bit_not @0) (bit_not @1))
  (cmp @1 @0)))

with :s on the bit_not's is not going to help (because we still allow
a single-stmt result as we are just replacing one with another).  So
:s cannot be used to guard against register pressure increase but
only to guard against undoing CSE.

For the case in this bug the user might have written the testcase
in the way we transform it now and thus what is desirable is a pass
that can reduce register pressure by expressing values in a different
way.

For the case above, why is a_14 = ~_13 not sunk to the edge
3->4 and b_18 = ~_17 to the edge 3->5?  (yes, this creates
additional BBs)  This would reduce register pressure.  Maybe
this kind of scheduling can be considered when register pressure
is high (does -fsched-pressure -fschedule-insns help?)

[Bug rtl-optimization/67443] New: DSE removes required store instruction

[krebbel at gcc dot gnu.org]

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

Bug ID: 67443
   Summary: DSE removes required store instruction
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36289&action=edit
Autoreduced testcase

This bug has been reported on the Debian mailing list. It occurs when building
the mozilla javascript engine with GCC 5 on S/390:

https://lists.debian.org/debian-s390/2015/08/msg6.html

Bisecting shows that the failure occurred after this commit:

commit 90f3e775d6b7bec70e883579beb49b456c135a09
Author: wmi 
Date:   Thu Jan 22 17:59:23 2015 +

2015-01-22  Wei Mi  

PR rtl-optimization/64557
* dse.c (record_store): Call get_addr for mem_addr.
(check_mem_read_rtx): Likewise.

Building the attached testcase with GCC before and after the commit shows that
a single stc (store character) instruction is missing after the patch.

Build options: -O2 -march=z900 -fPIC -std=gnu++11

[Bug c/67435] Large performance drop on apparently unrelated changes (potential cause : critical loop instruction alignment)

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
(In reply to Yann Collet from comment #6)
> The issue seems in fact related to _instruction alignment_.
> More precisely, to alignment of some critical loop.
> 
> That's basically why adding some code in the file would just "pushes" some
> other code into another position, potentially into a less favorable path
> (hence the appearance of "random impact").
> 
> 
> The following GCC command saved the day :
> -falign-loops=32
> 
> Note that -falign-loops=16 doesn't work.
> I'm suspecting it might be the default value, but can't be sure.
> I'm also suspecting that -falign-loops=32 is primarily useful for Broadwell
> cpu.

Here are the default values (from gcc/config/i386/i386.c):

 2540 /* Processor target table, indexed by processor number */ 
 2541 struct ptt
 2542 { 
 2543   const char *const name;   /* processor name  */ 
 2544   const struct processor_costs *cost;   /* Processor costs */ 
 2545   const int align_loop; /* Default alignments. 
*/  
 2546   const int align_loop_max_skip;  
 2547   const int align_jump;   
 2548   const int align_jump_max_skip;  
 2549   const int align_func;   
 2550 };
 2551   
 2552 /* This table must be in sync with enum processor_type in i386.h.  */ 
 2553 static const struct ptt processor_target_table[PROCESSOR_max] =   
 2554 { 
 2555   {"generic", &generic_cost, 16, 10, 16, 10, 16}, 
 2556   {"i386", &i386_cost, 4, 3, 4, 3, 4},
 2557   {"i486", &i486_cost, 16, 15, 16, 15, 16},   
 2558   {"pentium", &pentium_cost, 16, 7, 16, 7, 16},   
 2559   {"iamcu", &iamcu_cost, 16, 7, 16, 7, 16},   
 2560   {"pentiumpro", &pentiumpro_cost, 16, 15, 16, 10, 16},   
 2561   {"pentium4", &pentium4_cost, 0, 0, 0, 0, 0},
 2562   {"nocona", &nocona_cost, 0, 0, 0, 0, 0},
 2563   {"core2", &core_cost, 16, 10, 16, 10, 16},  
 2564   {"nehalem", &core_cost, 16, 10, 16, 10, 16},
 2565   {"sandybridge", &core_cost, 16, 10, 16, 10, 16},
 2566   {"haswell", &core_cost, 16, 10, 16, 10, 16},
 2567   {"bonnell", &atom_cost, 16, 15, 16, 7, 16}, 
 2568   {"silvermont", &slm_cost, 16, 15, 16, 7, 16},   
 2569   {"knl", &slm_cost, 16, 15, 16, 7, 16},  
 2570   {"intel", &intel_cost, 16, 15, 16, 7, 16},  
 2571   {"geode", &geode_cost, 0, 0, 0, 0, 0},  
 2572   {"k6", &k6_cost, 32, 7, 32, 7, 32}, 
 2573   {"athlon", &athlon_cost, 16, 7, 16, 7, 16}, 
 2574   {"k8", &k8_cost, 16, 7, 16, 7, 16}, 
 2575   {"amdfam10", &amdfam10_cost, 32, 24, 32, 7, 32},
 2576   {"bdver1", &bdver1_cost, 16, 10, 16, 7, 11},
 2577   {"bdver2", &bdver2_cost, 16, 10, 16, 7, 11},
 2578   {"bdver3", &bdver3_cost, 16, 10, 16, 7, 11},
 2579   {"bdver4", &bdver4_cost, 16, 10, 16, 7, 11},
 2580   {"btver1", &btver1_cost, 16, 10, 16, 7, 11},
 2581   {"btver2", &btver2_cost, 16, 10, 16, 7, 11} 
 2582 };  

As you can see only AMD's k6 and amdfam10 default to align_loop=32.

> Now, the problem is, `-falign-loops=32` is a gcc-only command line parameter.
> It seems not possible to apply this optimization from within the source file,
> such as using :
> #pragma GCC optimize ("align-loops=32")
> or the function targeted :
> __attribute__((optimize("align-loops=32")))
> 
> None of these alternatives does work.

I don't think this makes much sense for a binary that should run on
any X86 processor anyway. Optimizing for just one specific model will
negatively affect performance on an other.
If you want maximal performance you need to offer different binaries for
different CPUs.

See also (for a similar issue):
http://pzemts

[Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[jussi.judin at ericsson dot com]

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

Bug ID: 67442
   Summary: GCC 5.2.0 on x86_64 creates invalid address on
specific array index calculation through pointer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jussi.judin at ericsson dot com
  Target Milestone: ---

GCC 5.2.0 and the current git version
(ae436f3bdc66153005b7a260e0239521679f3965) create invalid address to access
array index calculated in specific way on x86_64 platform:

short foo[100];

int main()
{
short* bar = &foo[50];
short i = 1;
short j = 1;
short value = bar[8 - i * 2 * j];
return value;
}

$ ~/local/gcc-bin/bin/gcc -v -save-temps -Wall -Wextra -g3 -ggdb tst.c
$ ./a.out
Segmentation fault (core dumped)
$ gdb a.out core
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x004004d5 in main () at tst.c:8
8   short value = bar[8 - i * 2 * j];
(gdb) disassemble /m 0x004004d5
8   short value = bar[8 - i * 2 * j];
   0x004004ae <+24>:movswq -0xa(%rbp),%rdx
   0x004004b3 <+29>:movswq -0xc(%rbp),%rax
   0x004004b8 <+34>:imul   %rax,%rdx
   0x004004bc <+38>:mov%rdx,%rax
   0x004004bf <+41>:shl$0x1e,%rax
   0x004004c3 <+45>:sub%rdx,%rax
   0x004004c6 <+48>:shl$0x2,%rax
   0x004004ca <+52>:lea0x10(%rax),%rdx
   0x004004ce <+56>:mov-0x8(%rbp),%rax
   0x004004d2 <+60>:add%rdx,%rax
=> 0x004004d5 <+63>:movzwl (%rax),%eax
   0x004004d8 <+66>:mov%ax,-0xe(%rbp)
(gdb) p &bar[8 - i * 2 * j]
$3 = (short *) 0x600970 
(gdb) p/x $rax
$2 = 0x100600970

So there is 0x1 added somewhere to the address that is used for the
actual array access. I have seen value 0x5 added in the production code
I encountered this issue. It seems to need following parts to trigger:
reference to an array (&foo[50], foo could also be on stack, but it creates
more nasty addresses), array index access through pointer by [const1 - var1 *
const2 * var2], where const1 > 0 and const2 > 1. I just used values 8 and 2 to
demonstrate that we don't access negative indexes, whereas the actual signal
processing code I encountered this does.

If I assign this array index to a variable and use it to access the array
through pointer, then GCC creates correct binary. Also if I use -m32 to compile
for x86, this does not result in segmentation fault. So it looks like it's
x86_64 specific issue.

The system I used to compile this GCC is x86_64 Ubuntu 14.04 based one. GCC
returns following information about itself:

$ ~/local/gcc-bin/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/ejusjud/local/gcc-bin/bin/gcc
COLLECT_LTO_WRAPPER=/local/ejusjud/gcc-bin/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/ejusjud/local/gcc-bin
Thread model: posix
gcc version 6.0.0 20150902 (experimental) (GCC) 


And about the tools and other libraries during the compilation:


GNU C11 (GCC) version 6.0.0 20150902 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.0.0 20150902 (experimental), GMP version
5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 6.0.0 20150902 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.0.0 20150902 (experimental), GMP version
5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 2b4ce747c000701038232915f15d53af
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-g3' '-ggdb'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o tst.o tst.s
GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.24