[Bug tree-optimization/71921] missed vectorization optimization

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

  Component|libstdc++   |tree-optimization

--- Comment #3 from Marc Glisse  ---
That's not a libstdc++ issue, more likely tree-optimization, rtl-optimization
or target. The compiler already notices that the if/return construct is
equivalent to the ?: one (ifcvt). And the loop is vectorized (cmpltps+andnps).
Now gimple passes and the target (or some RTL pass) don't seem to agree on when
it is safe to replace ?: with MAX (or maybe the target is inconsistent between
scalars and vectors).

[Bug rtl-optimization/66795] Incorrect and missed optimizations of __builtin_frame_address

[luto at kernel dot org]

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

--- Comment #2 from Andy Lutomirski  ---
(In reply to Andrew Pinski from comment #1)
> The code below is invalid as __builtin_frame_address is only for reading
> from the current frame.

If this code is invalid, then what exactly is valid code that uses
__builtin_frame_address?  This is way outside the scope of the C standard. 
Apparently one cannot reliably write to pointers derived from
__builtin_frame_address?  Can one reliably *read* them?

What I'm trying to do is actually the most well-defined think I can think of to
do with __builtin_frame_address.  Roughly:

__attribute__((externally_visible)) void func(void)
{
unsigned long *ptr = (unsigned long *)__builtin_frame_address(0) - 2;
*ptr = some_other_value;
}

pushq some_value
call func
; the top of the stack should now contain some_other_value

As it stands, gcc can't usefully compile this because the store is deleted.  

> Also -O2 enables -fomit-frame-pointer which might
> cause the frame pointer to go away.

It's the other way around.  Using __builtin_frame_address(0) prevents the frame
pointer from being omitted.  This is an unnecessary constraint, at least for my
use case.  If __builtin_frame_pointer(0) returned a pointer to the stack one
slot below the saved return address regardless of whether the frame pointer
exists, it would work for me.

Would it make sense to add a new, well-defined intrinsic that returns the
address of the current function's return address?  As long as the function is
noinline, this would have sensible semantics.  (Arguably it should be an error
to use such an intrinsic in a function that isn't either noinline or forcibly
inlined.)

[Bug c/71926] wrong location for -Wparentheses warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-19
Summary|wrong -Wparentheses warning |wrong location for
   ||-Wparentheses warning
 Ever confirmed|0   |1
  Known to fail||4.4.5, 6.1.0

--- Comment #1 from Andrew Pinski  ---
The location for the warning is incorrect.

Confirmed.

[Bug c/71926] New: wrong -Wparentheses warning

[izaberina at gmail dot com]

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

Bug ID: 71926
   Summary: wrong -Wparentheses warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izaberina at gmail dot com
  Target Milestone: ---

int main() {
  int a = 1, b = 2, c = 3, d = 4;
  if (a = 2 || (b != 3 &&
  c != 4 && d != 5)) return 1;
  return 0;
}


-Wparentheses produces the following warning:

gccfail.c:4:23: warning: suggest parentheses around assignment used as truth
value [-Wparentheses]
   c != 4 && d != 5)) return 1;
   ^



gcc found the problem, but the warning is pretty misleading: i was about to
ignore it because it looked like a bogus warning

[Bug middle-end/64143] Add option -felide-aliases

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
How about loop versioning based on aliasing.  Right now that happens for the
vectorizer but we could do that in general (though maybe doing it for unrolling
sounds like a better idea).

[Bug c++/64142] Add option, -felide-copies

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
C++17 changes the rules about elide-copies and actually forces to do it rather
than just allowing it.

[Bug target/71493] [6/7 regression] accidental ABI change for structure return on PowerPC

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #7 from Michael Meissner  ---
Trunk fixed in subversion id 238454. GCC-6-branch fixed in subversion id
238455.

[Bug target/71493] [6/7 regression] accidental ABI change for structure return on PowerPC

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  ---
Author: meissner
Date: Tue Jul 19 03:39:34 2016
New Revision: 238455

URL: https://gcc.gnu.org/viewcvs?rev=238455=gcc=rev
Log:
[gcc]
2016-07-18  Michael Meissner  

Back port from mainline
2016-07-18  Michael Meissner  

PR target/71493
* config/rs6000/rs6000.c (rs6000_function_value): Fix
unintentional System V.4 structure return breakage for structures
with a single floating point element.

[gcc/testsuite]
2016-07-18  Michael Meissner  

Back port from mainline
2016-07-18  Michael Meissner  

PR target/71493
* gcc.target/powerpc/pr71493-1.c: New test.
* gcc.target/powerpc/pr71493-2.c: Likewise.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr71493-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr71493-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/71493] [6/7 regression] accidental ABI change for structure return on PowerPC

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Tue Jul 19 03:31:48 2016
New Revision: 238454

URL: https://gcc.gnu.org/viewcvs?rev=238454=gcc=rev
Log:
[gcc]
2016-07-18  Michael Meissner  

PR target/71493
* config/rs6000/rs6000.c (rs6000_function_value): Fix
unintentional System V.4 structure return breakage for structures
with a single floating point element.

[gcc/testsuite]
2016-07-18  Michael Meissner  

PR target/71493
* gcc.target/powerpc/pr71493-1.c: New test.
* gcc.target/powerpc/pr71493-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr71493-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr71493-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11

[pinskia at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic, documentation

--- Comment #14 from Martin Sebor  ---
*** Bug 71925 has been marked as a duplicate of this bug. ***

[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #14 from Martin Sebor  ---
*** Bug 71925 has been marked as a duplicate of this bug. ***

[Bug c/71925] poor -Wvla phrasing in C99 mode and later, documentation misleading

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Bug 67243 already tracks both of these problems.

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

[Bug c/71925] New: poor -Wvla phrasing in C99 mode and later, documentation misleading

[msebor at gcc dot gnu.org]

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

Bug ID: 71925
   Summary: poor -Wvla phrasing in C99 mode and later,
documentation misleading
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This report points out two minor problems with the -Wvla warning:

1) The text of the warning says that "ISO C90 forbids variable length array." 
That is relevant in C90 mode but not in C99 or C11 modes.  In those modes (and
for simplicity's sake, perhaps also in C90 mode) the warning should simply say
that a VLA has been declared.

$ cat walloca.c && /build/gcc-walloca/gcc/xgcc -B /build/gcc-walloca/gcc -S
-Wvla walloca.c
void f (int n)
{
  int a [n];
  (void)a;
}
walloca.c: In function ‘f’:
walloca.c:3:3: warning: ISO C90 forbids variable length array ‘a’ [-Wvla]
   int a [n];
   ^~~

2) The manual states this about the option:

Warn if variable length array is used in the code. -Wno-vla prevents the
-Wpedantic warning of the variable length array. 

Yet the warning is only enabled by -Wpedantic in C90 mode and not in C99 or C11
modes.  Since C11 is the default mode, the documentation is misleading and the
interaction of -Wpedantic, -Wvla, and the language mode should be clarified.

$ cat walloca.c && /build/gcc-walloca/gcc/xgcc -B /build/gcc-walloca/gcc -S
-Wall -Wextra -Wpedantic walloca.c
void f (int n)
{
  int a [n];
  (void)a;
}
$

[Bug c++/70977] [6/7 Regression] Out of memory during compilation of facebook/wangle (flag c++0x works, flag c++14 fails).

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #11 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/70824] [6/7 Regression] cc1plus consumes all available memory on specific template code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||aleksandergajewski at gmail 
dot co
   ||m

--- Comment #6 from Markus Trippelsdorf  ---
*** Bug 70977 has been marked as a duplicate of this bug. ***

[Bug c/71924] missing -Wreturn-local-addr returning alloca result

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Returning [the address of] a compound literal, or any indirectly referenced
object (such as those in comment #1), suffers from the same limitation. 
Compiling the program with -O2 (but not -O1) does produce the expected
warnings.  Since the effect of optimization is not documented, a "fix" might be
as simple as updating the manual to mention the dependency.

[Bug libgcc/71890] when using setjmp do context switch, libgcc crash the process when do unwind in thread cancel signal handler on X86_64

[wgkun at hotmail dot com]

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

--- Comment #2 from wgkun at hotmail dot com ---
(In reply to Andrew Pinski from comment #1)
> I don't think this is a valid thing to do with setjmp and longjmp.
> 
> Why are you not using makecontext/setcontext/getcontext/swapcontext instead?
> 
> Also why do you think this is a libgcc bug because if you try to unwind the
> stack using gdb, you will get the same behavior because the stack was that
> one thread is now on the other one but the that thread has now exited.

Thanks. I turn to makecontext/swapcontext and works well.

But, back to this problem, I still think it is something wrong in the tool
chain, gcc or libgcc.
gcc generate the asynchronous-unwind-tables and libgcc use them to do unwind.
As my understanding, when do unwind for a thread, you shall not visit other
context not belong to this thread now.
And why this only happens on X86_64? Is it related to the special definition of
unwind tables according to the X86_64 ABI which has some difference with formal
DWARF?

[Bug libstdc++/71921] missed vectorization optimization

[arjan at linux dot intel.com]

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

--- Comment #2 from Arjan van de Ven  ---
I tried with <= and it doesn't seem all to eager to be vectorized that way
either; fast-math works either way

[Bug c/71924] missing -Wreturn-local-addr returning alloca result

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I expect we also miss:
void* foo1 (void)
{
  char a [4];
  char *b = a;
  return b;
}

void* foo2 (void)
{
  char *b = (char[4]){0, 0, 0, 0};
  return b;
}

Basically we don't do any flow analysis for this warning.

[Bug c/71924] missing -Wreturn-local-addr returning alloca result

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c/71924] New: missing -Wreturn-local-addr returning alloca result

[msebor at gcc dot gnu.org]

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

Bug ID: 71924
   Summary: missing -Wreturn-local-addr returning alloca result
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

All three functions defined in the following example return an address of a
stack object, but GCC only issues a -Wreturn-local-addr warning for two of them
and not for the one where alloca was used to allocated the stack object.  The
warning should be issued for all three functions.

Note that the warning comes and goes with the value of the size argument, and
is not issued when the argument is not constant (the warning is, however,
issued for VLAs).

Also, the note printed following the second warning is wrong (the object isn't
declared) and points to the wrong location (to be useful, it should point to
the line containing either the declaration of the local object or the
invocation of the alloca function).

$ cat walloca.c && /build/gcc-walloca/gcc/xgcc -B /build/gcc-walloca/gcc -S
-Wall -Wextra -Wpedantic walloca.c
void* foo (void)
{
  char a [4];
  return a;
}

void* bar (void)
{
  void *a = __builtin_alloca (4);
  return a;
}

void* baz (void)
{
  void *a = __builtin_alloca_with_align (4, 8);
  return a;
}

walloca.c: In function ‘foo’:
walloca.c:4:10: warning: function returns address of local variable
[-Wreturn-local-addr]
   return a;
  ^
walloca.c: In function ‘baz’:
walloca.c:16:10: warning: function returns address of local variable
[-Wreturn-local-addr]
   return a;
  ^
walloca.c:17:1: note: declared here
 }
 ^

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[thaines.astro at gmail dot com]

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

Tim Haines  changed:

   What|Removed |Added

 CC||thaines.astro at gmail dot com

--- Comment #46 from Tim Haines  ---
(In reply to Marek Polacek from comment #45)
> Patches posted .

Thank you for putting in the work to make this happen! Does the current patch
allow calling a [[noreturn]] function without the need to follow it with a call
to __builtin_fallthrough()? Something like

int i = ...;
switch (i) {
case 1:
std::abort();
// don't warn about fallthrough here
case 2:
std::cout << "Hello world!\n";
break;
}

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
If anything this might be a binutils bug and not a GCC bug based on your
description and should be reported there (http://sourceware.org/bugzilla/ )
instead of here.

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
More to the point GCC just outputs:
.globl FUNC
.type FUNC, @gnu_indirect_function
.set FUNC, __resolve_FUNC

How did you configure GCC?

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[dimitry at google dot com]

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

--- Comment #6 from dimitry  ---
ok one correction - this is objdump of the .so file, not the object file. What
I expected to see here is branch to ptl (which uses result of ARM_IRELATIVE
reloc) This does not seem to be the case. (the reloc itself is in place and
looks good)

(I am taking another look at .o files for arm/arm64)

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
What is gcc producing wrong then? Because if you are part of the bionic team
you should understand how relocs work. If it is a wrong relocation then
binutils might be causing the issue rather thanot gcc. Please use -save-temps
and look at the assembly output and then look at the object file to see what as
produces and then look at the relocations in the executable.

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[dimitry at google dot com]

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

--- Comment #4 from dimitry  ---
(I am from the bionic team)

I do not have access to arm ld-linux.so.

The problem here is that code generated by gcc is incorrect for arm.

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #3 from Andrew Pinski  ---
Does the program work with glibc's ld.so ?  If so then I would report this bug
to bionic team.

Actually I would report it to them anyways as GCC ifunc support is minimal, in
that it just creates small assembly code.

[Bug c++/70977] [6/7 Regression] Out of memory during compilation of facebook/wangle (flag c++0x works, flag c++14 fails).

[romain.geissler at amadeus dot com]

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

--- Comment #10 from Romain Geissler  ---
This is actually a dup of #70824 which was just fixed in trunk.

[Bug tree-optimization/71923] New: Two consecutive "rep ret" instruction in assembly output of recursive function

[SztfG at yandex dot ru]

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

Bug ID: 71923
   Summary: Two consecutive "rep ret" instruction in assembly
output of recursive function
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

function

unsigned int fact( unsigned int n) { return n < 1 ? 1 : n*fact(n-1); }

produces

fact:
.LFB0:
.cfi_startproc
testl   %edi, %edi
movl$1, %eax
je  .L4
.p2align 4,,10
.p2align 3
.L3:
imull   %edi, %eax
subl$1, %edi
jne .L3
rep ret # <-- this instruction can be removed
.L4:
rep ret
.cfi_endproc
.LFE0:
.size   fact, .-fact
.section.text.unlikely

can be easily reproduced at http://gcc.godbolt.org/

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[dimitry at google dot com]

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

--- Comment #2 from dimitry  ---
The test is failing at runtime. which was the reason I started looking at
objdump

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm*-*
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
>which seems to be wrong.


No they are most likely iWMMX instructions which are invalid for your objdump
usage (not using the correct options).

Is this testcase failing at runtime or just when you look at the executable
using objdump?

[Bug c/71922] New: arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

[dimitry at google dot com]

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

Bug ID: 71922
   Summary: arm: ifuncs are broken in for arm (gcc generates
incorrect code in object file)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitry at google dot com
  Target Milestone: ---

This is code in question:
https://android.googlesource.com/platform/bionic/+/master/tests/libs/dlopen_testlib_ifunc.c

This library is used to test ifunc functionality in android-linker.

after compiling an object file looks like this...

0948 :
 948:   f001 bb2e   b.w 1fa8
<_ZN9libunwind13Registers_arm19restoreiWMMXControlEPj+0x14>

1fa8:   46c04778;  instruction:
0x46c04778
1fac:   e59fc000ldr ip, [pc]; 1fb4
<_ZN9libunwind13Registers_arm19restoreiWMMXControlEPj+0x20>
1fb0:   e08cf00fadd pc, ip, pc
1fb4:   e96d;  instruction:
0xe96d
1fb8:   46c04778;  instruction:
0x46c04778
1fbc:   e59fc000ldr ip, [pc]; 1fc4
<_ZN9libunwind13Registers_arm19restoreiWMMXControlEPj+0x30>
1fc0:   e08cf00fadd pc, ip, pc
1fc4:   e7c4;  instruction:
0xe7c4
1fc8:   46c04778;  instruction:
0x46c04778
1fcc:   e59fc000ldr ip, [pc]; 1fd4
<_ZN9libunwind13Registers_arm19restoreiWMMXControlEPj+0x40>
1fd0:   e08cf00fadd pc, ip, pc
1fd4:   ff4c;  instruction:
0xff4c
1fd8:   46c04778;  instruction:
0x46c04778
1fdc:   e59fc000ldr ip, [pc]; 1fe4
<_ZN9libunwind13Registers_arm19restoreiWMMXControlEPj+0x50>
1fe0:   e08cf00fadd pc, ip, pc
1fe4:   ffac;  instruction:
0xffac


which seems to be wrong.

Note that other platforms work fine and generate correct code for this - tested
arm64/x86/x86_64

[Bug libstdc++/71921] missed vectorization optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |libstdc++

--- Comment #1 from Andrew Pinski  ---
The problem is:
  _7 = _5 < 0.0 ? 0.0 : _5;


Is not converted into MAX_EXPR which it does with -ffast-math (and you get the
vectorized version with maxps).

The question now becomes should:
  template
_GLIBCXX14_CONSTEXPR
inline const _Tp&
max(const _Tp& __a, const _Tp& __b)
{
  // concept requirements
  __glibcxx_function_requires(_LessThanComparableConcept<_Tp>)
  //return  __a < __b ? __b : __a;
  if (__a < __b)
return __b;
  return __a;
}


Be <= or < ?
Then this becomes a libstdc++ question :).

[Bug target/71493] [6/7 regression] accidental ABI change for structure return on PowerPC

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Created attachment 38924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38924=edit
Proposed patch to fix the problem

I'm testing this patch right now.  The patch applies to both the trunk and the
GCC 6.x branches.

[Bug tree-optimization/71921] New: missed vectorization optimization

[arjan at linux dot intel.com]

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

Bug ID: 71921
   Summary: missed vectorization optimization
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arjan at linux dot intel.com
  Target Milestone: ---

program below does not auto-vectorize to use the x86 "maxps" instruction even
though gcc is smart enough to know there is a "maxss" instruction...


gcc -O3 -ftree-vectorize -fopt-info-vec -fopt-info-vec-missed -march=westmere
test.cpp -S -o test.S

does not show any use of maxps in test.S



#include 

void relu(float * __restrict__ output, const float * __restrict__ input, int
size)
{
int i;
int s2;

s2 = size / 4;
for (i = 0; i < s2 * 4; i++) {
float t;
t = input[i];
output[i] = std::max(t, float(0));
}
}

[Bug c++/71919] Redefinition of user-defined conversions (via typedef) shouldn't compile

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-18
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |4.9.4
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, both clang and ICC produce the warning/error.

[Bug lto/71920] request to backport commit trunk@234239 to gcc 4.9 and 5

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-18
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I'll do that.

[Bug lto/71920] New: request to backport commit trunk@234239 to gcc 4.9 and 5

[pageexec at gmail dot com]

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

Bug ID: 71920
   Summary: request to backport commit trunk@234239 to gcc 4.9 and
5
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pageexec at gmail dot com
  Target Milestone: ---

i encountered a crash while building recent linux kernels (v4.5+) in LTO mode.
when i tracked down the root cause it turned out that the underlying bug had
already been fixed by the following commit on trunk (and gcc 6) therefore i'd
like to request that it be backported to the still maintained branches.

commit 523f8924db2793abae1b981137b42da8b6c54878
Author: rth 
Date:   Tue Mar 15 23:08:45 2016 +

Fix compiling large files

  * line-map.c (new_linemap): Make alloc_size a size_t.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@234239
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index a2cb02f68a56..89b582d75402 100644
--- a/libcpp/ChangeLog
+++ b/libcpp/ChangeLog
@@ -1,3 +1,7 @@
+2016-03-15  Richard Henderson  
+
+   * line-map.c (new_linemap): Make alloc_size a size_t.
+
 2016-03-14  Jason Merrill  

* expr.c (cpp_classify_number): Hex floats are new in C++1z.
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 1fb634af5bf3..80d4e6b83921 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -376,7 +376,7 @@ new_linemap (struct line_maps *set,
   if (LINEMAPS_USED (set, macro_map_p) == LINEMAPS_ALLOCATED (set,
macro_map_p))
 {
   /* We ran out of allocated line maps. Let's allocate more.  */
-  unsigned alloc_size;
+  size_t alloc_size;

   /* Cast away extern "C" from the type of xrealloc.  */
   line_map_realloc reallocator = (set->reallocator

[Bug c++/70869] [6 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 18 18:45:18 2016
New Revision: 238444

URL: https://gcc.gnu.org/viewcvs?rev=238444=gcc=rev
Log:
PR c++/70869
PR c++/71054
* cp-gimplify.c (cp_genericize_r): Revert the 2016-07-07 change.
* tree.c (cp_walk_subtrees): For DECL_EXPR on DECL_ARTIFICIAL
non-static VAR_DECL, walk the decl's DECL_INITIAL, DECL_SIZE and
DECL_SIZE_UNIT.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/tree.c

[Bug c++/71054] [6/7 Regression] ICE: in expand_expr_real_2, at expr.c:8097

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 18 18:45:18 2016
New Revision: 238444

URL: https://gcc.gnu.org/viewcvs?rev=238444=gcc=rev
Log:
PR c++/70869
PR c++/71054
* cp-gimplify.c (cp_genericize_r): Revert the 2016-07-07 change.
* tree.c (cp_walk_subtrees): For DECL_EXPR on DECL_ARTIFICIAL
non-static VAR_DECL, walk the decl's DECL_INITIAL, DECL_SIZE and
DECL_SIZE_UNIT.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/tree.c

[Bug c++/71835] [6/7 Regression] ICE on invalid C++ code with ambiguous overloaded operators: tree check: expected tree that contains ‘decl minimal’ structure, have ‘pointer_type’ in convert_like_real

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 18 18:44:51 2016
New Revision: 238443

URL: https://gcc.gnu.org/viewcvs?rev=238443=gcc=rev
Log:
PR c++/71835
* call.c (build_op_call_1): Use convert_like_with_context only
if cand->fn is a decl.

* g++.dg/conversion/ambig3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/conversion/ambig3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71828] [6/7 regression] ICE on valid C++11 code with constexpr __Complex int variable declaration: in operand_equal_p, at fold-const.c:2790

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 18 18:43:19 2016
New Revision: 238442

URL: https://gcc.gnu.org/viewcvs?rev=238442=gcc=rev
Log:
PR c++/71828
* constexpr.c (cxx_eval_constant_expression) :
For lval don't use cxx_eval_unary_expression and instead recurse
and if needed rebuild the reference.

* g++.dg/cpp0x/constexpr-71828.C: New test.

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

[Bug c++/71826] [7 Regression] ICE on valid C++ code with ambiguous member lookup: tree check: expected baselink, have error_mark in tsubst_baselink, at cp/pt.c:13737

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 18 18:42:24 2016
New Revision: 238441

URL: https://gcc.gnu.org/viewcvs?rev=238441=gcc=rev
Log:
PR c++/71826
* pt.c (tsubst_baselink): Only set BASELINK_OPTYPE for BASELINK_P.

* g++.dg/template/pr71826.C: New test.

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

[Bug c++/71822] [6/7 Regression] ICE: in gimplify_expr, at gimplify.c:11025

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 18 18:40:12 2016
New Revision: 238440

URL: https://gcc.gnu.org/viewcvs?rev=238440=gcc=rev
Log:
PR c++/71822
* cp-gimplify.c (cp_gimplify_expr) : Recursively
fold *expr_p before genericizing it.

* g++.dg/template/defarg21.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/defarg21.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71734] [7 Regression] FAIL: libgomp.fortran/simd4.f90 -O3 -g execution test

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #6 from Bill Seurer  ---
Looks like the simd3/4 tests now work with this patch but
g++.dg/vect/pr70729.cc now fails:

FAIL: g++.dg/vect/pr70729.cc  -std=c++98 (test for excess errors)
FAIL: g++.dg/vect/pr70729.cc  -std=c++11 (test for excess errors)
FAIL: g++.dg/vect/pr70729.cc  -std=c++14 (test for excess errors)

In the log I see

/tmp/cc3mxFhd.s: Assembler messages:
/tmp/cc3mxFhd.s:29: Error: unrecognized opcode: `xsxexpdp'
compiler exited with status 1

and also

/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/vect/pr70729.cc:7:10: fatal
error: xmmintrin.h: No such file or directory
compilation terminated.
compiler exited with status 1


Maybe some of the options you removed weren't really redundant?

[Bug c++/71919] New: Redefinition of user-defined conversions (via typedef) shouldn't compile

[jmgao at google dot com]

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

Bug ID: 71919
   Summary: Redefinition of user-defined conversions (via typedef)
shouldn't compile
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmgao at google dot com
  Target Milestone: ---

GCC does not emit an error (or warning) when two user-defined conversion
functions are defined inline with the same type via typedef. When one or more
of the functions don't have inline definitions, an error happens as expected.

Example (also at https://godbolt.org/g/YYOqja):
  typedef int foo;
  struct bar {
operator int() { return 0; }
operator foo() { return 0; }
  };

[Bug c/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[woodard at redhat dot com]

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

--- Comment #2 from Ben Woodard  ---
This is about as simple of a reproducer as I have been able to come up with:

#define _GNU_SOURCE
#include 
#include 
#include 

void
m4_error (int status, int errnum, const char *format, ...)
{
  va_list args;
  char *result;

  va_start (args, format);

  vasprintf (, format, args);

  va_end (args);
}

[Bug c++/71871] ICE on mixing templates and vector extensions ternary operator

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 18 17:44:48 2016
New Revision: 238439

URL: https://gcc.gnu.org/viewcvs?rev=238439=gcc=rev
Log:
PR c++/71871
* typeck.c (build_x_conditional_expr): Revert the 2012-10-25 change.

* g++.dg/ext/vector31.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/vector31.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
(In reply to Ville Voutilainen from comment #2)
> I dislike the #ifdef parts.

I'm sorry for my misleading proposal. My extended proposal is not suggesting to
add this macro. I was using this macro solely for experimentation purposes. My
intended question was solely whether we would prefer to have the more reduced
set of requirements as defined in my original proposal or the more complete
requirement set that would result if you consider the macro
EXT_BOOLEAN_TESTABLE_OPS defined (but without the #ifdef logic of that macro).
This more complete set corresponds more strictly to the current BooleanTestable
requirement set.

[Bug debug/71906] [6/7 Regression] Fortran allocatable strings debug info type size regression

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 38923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38923=edit
gcc7-pr71906-wip.patch

Untested WIP patch, that should fix the vara, varb and vare cases at -O0, for
optimized builds the DW_OP_call4 isn't the best thing to do, if the _var*/.var*
argument/variable doesn't live in memory.  I'll try tomorrow adjusting it
during late debug when we have location info for the variable/parameter.

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Martin Sebor from comment #6)
> I didn't know that GCC considers attribute warn_unused_result part of the
> function type.  When you say that most of these attributes apply to the
> function type, which others are you referring to?

Other attributes that apply to a function type: nonnull, returns_nonnull,
sentinel, alloc_size, alloc_align, assume_aligned, format, format_arg.

I don't know why they were defined this way; I imagine it was to support using
them on function pointers.

[Bug c++/71912] [6/7 regression] flexible array in struct in union rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-07-18
  Known to work||5.4.0
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|flexible array in union |[6/7 regression] flexible
   ||array in struct in union
   ||rejected
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #4 from Martin Sebor  ---
I confirm the code in the test case is meant to be accepted by G++ for
compatibility with GCC but is rejected due to a bug in the find_flexarrays
function in class.c.

That said, it's not completely clear that the code is valid according to the C
definition of a flexible array member:

  As a special case, the last element of a structure with more than one named
member may have an incomplete array type; this is called a /flexible array
member/.

Although C doesn't define the term element, I think it means the last declared
subobject of an object.

In the test case, neither of the two flexible array members is the last element
of struct xyyzy (the last element is the subobject u).  Within the member u of
struct xyyzy, the flexible array member f.s is not the last element of the
structure xyyzy (b.t is the last element).

Even though GCC with -Wpedantic silently accepts the equivalent definition of
struct xyyzy, it issues a diagnostic for baz supporting the interpretation
above:

  warning: invalid use of structure with flexible array member

Since the struct definitions are equivalent, it seems that either they both
should be diagnosed or neither should be.

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
I dislike the #ifdef parts. It seems to me both modes of operation
could be provided without resorting to the preprocessor. I'm also
not a fan of the name boolean_testable - perhaps boolean_like would
be better? The rationale being that there are "boolean testable" types
that work in cases where a contextual conversion to bool is performed,
but those types are otherwise not "boolean-like". Sure, we could
go with boolean_testable and potentially contextually_boolean_testable
or some such. It seems to me that both of those facilities are useful.

I do wonder why we even bother supporting e.g. comparison operators that
don't just return bool, although that's in some ways a separate matter.

[Bug tree-optimization/71769] Invalid warning from -Wunsafe-loop-optimizations for a finite loop

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
This is fixed by below change:
r238336 | hubicka | 2016-07-14 14:52:21 +0100 (Thu, 14 Jul 2016) | 6 lines

* gimple.h (stmt_can_terminate_bb_p): New function.
* tree-cfg.c (need_fake_edge_p): Rename to ...
(stmt_can_terminate_bb_p): ... this; return true if stmt can
throw external; handle const and pure calls.
* tree-ssa-loop-niter.c (loop_only_exit_p): Use it.

[Bug c++/71918] Internal compiler error: Illegal instruction

[jordyruiz at hotmail dot fr]

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

--- Comment #9 from jordyruiz at hotmail dot fr ---
Alright then, thanks for the troubleshooting guys. Will be more careful when
sharing libraries on different machines.

[Bug c++/69515] partial specialization of variable templates is broken

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |6.2

--- Comment #8 from Jason Merrill  ---
Fixed for 6.2.

[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |6.2

--- Comment #9 from Jason Merrill  ---
Fixed for 6.2.

[Bug c++/70095] [C++14] Link error on partially specialized variable template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
(In reply to Tom Honermann from comment #2)
> The change in comment 1 introduced a regression.  The following test passes
> with r234230, but fails with r234231:
> 
> $ cat t.cpp
> template 
> constexpr bool b = false;
> template
> constexpr bool b = true;
> int main() {
> b;
> b;
> }
> 
> $ g++ -std=c++14 t.cpp -o t
> /tmp/ccJTAQId.s: Assembler messages:
> /tmp/ccJTAQId.s:27: Error: symbol `_ZL1b' is already defined

I think this was fixed by the patch for 69515.  In any case, it works now.

[Bug c++/55576] Fails to compile a call to template member function

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
Looking at the standard again, I notice

When the name of a member template specialization appears after . or -> in a
postfix-expression or after a nested-name-specifier in a qualified-id, and the
object expression of the postfix-expression is type-dependent or the
nested-name-specifier in the qualified-id refers to a dependent type, but the
name is not a member of the current instantiation (14.6.2.1), the member
template name must be prefixed by the keyword template.

This suggests that the 'template' keyword specifies that the following name is
a *member* template, and that we shouldn't look in the current scope at all.

It seems like the main change needed is passing template_keyword_p into
cp_parser_nested_name_specifier_opt.

[Bug c++/71918] Internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to jordyruiz from comment #6)
> > Also this is most likely GMP not compiled for generic but a specific CPU and
> > you don't have a compatible CPU.
> > 
> > Did you compile GMP yourself or did you get it from a distro?  If you got it
> > from a distro, you should report the bug to that distro.
> 
> I compiled GMP myself, on a different machine. So you probably found the
> cause of the issue.

If you don't disable the assembly code in GMP, GMP defaults to basically doing
-march=native .  You need to configure GMP correctly if you are going to use it
across different machines which are different processor types.

[Bug c++/71918] Internal compiler error: Illegal instruction

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #7 from Markus Trippelsdorf  ---
It is as Andrew said: Your gmp library was compiled with BMI2 instructions
enabled (only available on Haswell and newer).

Not a gcc bug.

[Bug c++/71918] Internal compiler error: Illegal instruction

[jordyruiz at hotmail dot fr]

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

--- Comment #6 from jordyruiz at hotmail dot fr ---
> Also this is most likely GMP not compiled for generic but a specific CPU and
> you don't have a compatible CPU.
> 
> Did you compile GMP yourself or did you get it from a distro?  If you got it
> from a distro, you should report the bug to that distro.

I compiled GMP myself, on a different machine. So you probably found the cause
of the issue.


(In reply to Markus Trippelsdorf from comment #5)
> 
> Yes.
> 
>  set follow-fork-mode child
>  run
>  disass
> (and please also post the backtrace)
>  bt

(gdb)  disass
Dump of assembler code for function __gmpn_mul_1:
   0x7750b460 <+0>: push   %rbx
   0x7750b461 <+1>: push   %rbp
   0x7750b462 <+2>: push   %r12
   0x7750b464 <+4>: mov%rdx,%rbp
   0x7750b467 <+7>: shr$0x2,%rbp
   0x7750b46b <+11>:test   $0x1,%dl
   0x7750b46e <+14>:jne0x7750b4b6 <__gmpn_mul_1+86>
   0x7750b470 <+16>:test   $0x2,%dl
   0x7750b473 <+19>:mov%rcx,%rdx
   0x7750b476 <+22>:jne0x7750b492 <__gmpn_mul_1+50>
   0x7750b478 <+24>:mulx   (%rsi),%r9,%r8
   0x7750b47d <+29>:mulx   0x8(%rsi),%r11,%r10
   0x7750b483 <+35>:mulx   0x10(%rsi),%rcx,%r12
   0x7750b489 <+41>:lea-0x20(%rdi),%rdi
   0x7750b48d <+45>:jmpq   0x7750b530 <__gmpn_mul_1+208>
   0x7750b492 <+50>:mulx   (%rsi),%rcx,%r12
   0x7750b497 <+55>:mulx   0x8(%rsi),%rbx,%rax
   0x7750b49d <+61>:lea-0x10(%rdi),%rdi
   0x7750b4a1 <+65>:test   %rbp,%rbp
   0x7750b4a4 <+68>:je 0x7750b550 <__gmpn_mul_1+240>
   0x7750b4aa <+74>:mulx   0x10(%rsi),%r9,%r8
   0x7750b4b0 <+80>:lea0x10(%rsi),%rsi
   0x7750b4b4 <+84>:jmp0x7750b516 <__gmpn_mul_1+182>
   0x7750b4b6 <+86>:test   $0x2,%dl
   0x7750b4b9 <+89>:mov%rcx,%rdx
   0x7750b4bc <+92>:jne0x7750b4dc <__gmpn_mul_1+124>
=> 0x7750b4be <+94>:mulx   (%rsi),%rbx,%rax
   0x7750b4c3 <+99>:lea-0x18(%rdi),%rdi
   0x7750b4c7 <+103>:   test   %rbp,%rbp
   0x7750b4ca <+106>:   je 0x7750b557 <__gmpn_mul_1+247>
   0x7750b4d0 <+112>:   mulx   0x8(%rsi),%r9,%r8
   0x7750b4d6 <+118>:   lea0x8(%rsi),%rsi
   0x7750b4da <+122>:   jmp0x7750b51d <__gmpn_mul_1+189>
   0x7750b4dc <+124>:   mulx   (%rsi),%r11,%r10
   0x7750b4e1 <+129>:   mulx   0x8(%rsi),%rcx,%r12
   0x7750b4e7 <+135>:   mulx   0x10(%rsi),%rbx,%rax
   0x7750b4ed <+141>:   lea-0x8(%rdi),%rdi
   0x7750b4f1 <+145>:   test   %rbp,%rbp
   0x7750b4f4 <+148>:   je 0x7750b549 <__gmpn_mul_1+233>
   0x7750b4f6 <+150>:   lea0x18(%rsi),%rsi
   0x7750b4fa <+154>:   jmp0x7750b50a <__gmpn_mul_1+170>
   0x7750b4fc <+156>:   nopl   0x0(%rax)
   0x7750b500 <+160>:   lea0x20(%rdi),%rdi
   0x7750b504 <+164>:   mov%r9,(%rdi)
   0x7750b507 <+167>:   adc%r8,%r11
   0x7750b50a <+170>:   mulx   (%rsi),%r9,%r8
   0x7750b50f <+175>:   mov%r11,0x8(%rdi)
   0x7750b513 <+179>:   adc%r10,%rcx
   0x7750b516 <+182>:   mov%rcx,0x10(%rdi)
   0x7750b51a <+186>:   adc%r12,%rbx
   0x7750b51d <+189>:   mulx   0x8(%rsi),%r11,%r10
   0x7750b523 <+195>:   adc%rax,%r9
   0x7750b526 <+198>:   mulx   0x10(%rsi),%rcx,%r12
   0x7750b52c <+204>:   mov%rbx,0x18(%rdi)
   0x7750b530 <+208>:   mulx   0x18(%rsi),%rbx,%rax
   0x7750b536 <+214>:   lea0x20(%rsi),%rsi
   0x7750b53a <+218>:   dec%rbp
   0x7750b53d <+221>:   jne0x7750b500 <__gmpn_mul_1+160>
   0x7750b53f <+223>:   lea0x20(%rdi),%rdi
   0x7750b543 <+227>:   mov%r9,(%rdi)
   0x7750b546 <+230>:   adc%r8,%r11
   0x7750b549 <+233>:   mov%r11,0x8(%rdi)
   0x7750b54d <+237>:   adc%r10,%rcx
   0x7750b550 <+240>:   mov%rcx,0x10(%rdi)
   0x7750b554 <+244>:   adc%r12,%rbx
   0x7750b557 <+247>:   mov%rbx,0x18(%rdi)
   0x7750b55b <+251>:   adc$0x0,%rax
   0x7750b55f <+255>:   pop%r12
   0x7750b561 <+257>:   pop%rbp
   0x7750b562 <+258>:   pop%rbx
---Type  to continue, or q  to quit---


(gdb) bt
#0  0x7750b4be in __gmpn_mul_1 () from
/home/jruiz/.local/lib/libgmp.so.10
#1  0x7fffd240 in ?? ()
#2  0x000a in ?? ()
#3  0x0061 in ?? ()
#4  0x7751687d in __gmpn_bc_set_str () from
/home/jruiz/.local/lib/libgmp.so.10
#5  0x77516ce7 in __gmpn_set_str () from
/home/jruiz/.local/lib/libgmp.so.10
#6  0x77798923 in 

[Bug fortran/71703] [4.9/5/6/7 Regression] ICE in wide_int_to_tree, at tree.c:1488

[tom.k.cook at gmail dot com]

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

Tom  changed:

   What|Removed |Added

 CC||tom.k.cook at gmail dot com

--- Comment #4 from Tom  ---
This bug appears to be in the GFortran 5.3.1 released in Ubuntu 16.04, where it
manifests as:

   A_WVSTR%rSurface = 0.0
   1
  internal compiler error: in wide_int_to_tree, at tree.c:1464

A_WVSTR is a function parameter, rSurface is a 3-dimensional allocatable array
of real(kind=4).  Apologies that I am unable to provide full source for the
offending module.

Is there a known work-around that can be used in the source that triggers this
problem?  We build the same source with a GFortran 5.3.0 which we built
ourselves without problems.

Regards,
Tom

[Bug c++/71918] Internal compiler error: Illegal instruction

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to jordyruiz from comment #2)
> > Hi,
> > 
> > I have managed to output a cvc4_operand_visitor.ii file, but it's 77182
> > lines long, I'm afraid this may not be what you're looking for.
> > 
> > I use an Intel Core 2 Duo CPU E6850 @ 3.00GHz.
> > 
> > I ran gcc under gdb but I don't see any information about which illegal
> > instruction was hit, sorry. Could you tell me how I could extract that info?
> >
> 
> Most likely you need to follow fork in gdb and then disassemble $pc,$pc+0x10
> .

Yes.

 set follow-fork-mode child
 run
 disass
(and please also post the backtrace)
 bt

[Bug c++/71918] Internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Also this is most likely GMP not compiled for generic but a specific CPU and
you don't have a compatible CPU.

Did you compile GMP yourself or did you get it from a distro?  If you got it
from a distro, you should report the bug to that distro.

[Bug c++/71918] Internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to jordyruiz from comment #2)
> Hi,
> 
> I have managed to output a cvc4_operand_visitor.ii file, but it's 77182
> lines long, I'm afraid this may not be what you're looking for.
> 
> I use an Intel Core 2 Duo CPU E6850 @ 3.00GHz.
> 
> I ran gcc under gdb but I don't see any information about which illegal
> instruction was hit, sorry. Could you tell me how I could extract that info?
>

Most likely you need to follow fork in gdb and then disassemble $pc,$pc+0x10 .

[Bug c++/71918] Internal compiler error: Illegal instruction

[jordyruiz at hotmail dot fr]

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

--- Comment #2 from jordyruiz at hotmail dot fr ---
Hi,

I have managed to output a cvc4_operand_visitor.ii file, but it's 77182 lines
long, I'm afraid this may not be what you're looking for.

I use an Intel Core 2 Duo CPU E6850 @ 3.00GHz.

I ran gcc under gdb but I don't see any information about which illegal
instruction was hit, sorry. Could you tell me how I could extract that info?

Greetings

[Bug c++/71910] ICE on invalid OpenMP code

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
Created attachment 38922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38922=edit
preprocessed testcase

I can also reproduce this on 5.4 and trunk with a cross-compiler configured
with --target=x86_64-w64-mingw32, using a preprocessed input. I've modified the
testcase like this (attaching preprocessed source):

#include 
extern "C" void exit(int);
int main(void)
{
std::vector vec(10);
#pragma omp parallel
exit(0);
}

The backtrace on trunk at the point of segfault is:

t.cc: In function ‘int main()’:
t.cc:12:1: internal compiler error: Segmentation fault
0xd8b11f crash_signal
../../gcc/gcc/toplev.c:335
0xbb2e1e inline_edge_summary
../../gcc/gcc/ipa-inline.h:285
0xbb2e1e estimate_function_body_sizes
../../gcc/gcc/ipa-inline-analysis.c:2698
0xbb734e compute_inline_parameters(cgraph_node*, bool)
../../gcc/gcc/ipa-inline-analysis.c:3030
0xe6ca08 convert_callers_for_node
../../gcc/gcc/tree-sra.c:5112
0xe72628 cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/gcc/cgraph.h:3137
0xe72628 convert_callers
../../gcc/gcc/tree-sra.c:5127
0xe72628 modify_function
../../gcc/gcc/tree-sra.c:5183
0xe7bad3 ipa_early_sra
../../gcc/gcc/tree-sra.c:5411
0xe7bad3 execute
../../gcc/gcc/tree-sra.c:5458

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/71918] New: Internal compiler error: Illegal instruction

[jordyruiz at hotmail dot fr]

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

Bug ID: 71918
   Summary: Internal compiler error: Illegal instruction
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jordyruiz at hotmail dot fr
  Target Milestone: ---

Hello,

I get this error on compiling.
It's asking me to report a bug report.
Is this of any interest? If so, what files would you need to troubleshoot this?

Using gcc version 6.1.1 20160621 (Red Hat 6.1.1-3) (GCC) 
Target: x86_64-redhat-linux


Thanks.




[ 1/24] [1] c++ src/cvc4/cvc4_smt.cpp
[ 2/24] [2] c++ src/cvc4/cvc4_operand_visitor.cpp
In file included from
/home/***/system/include/cvc4/util/integer_gmp_imp.h:25:0,
 from /home/***/system/include/cvc4/util/integer.h:38,
 from /home/***/system/include/cvc4/util/cardinality.h:26,
 from /home/***/system/include/cvc4/expr/type.h:27,
 from /home/***/system/include/cvc4/expr/expr_manager.h:55,
 from src/cvc4/cvc4_operand_visitor.cpp:1:
/usr/include/c++/6.1.1/limits:1598:7: internal compiler error: Illegal
instruction
   min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
   ^~~
In file included from
/home/***/system/include/cvc4/util/integer_gmp_imp.h:25:0,
 from /home/***/system/include/cvc4/util/integer.h:38,
 from /home/***/system/include/cvc4/util/cardinality.h:26,
 from /home/***/system/include/cvc4/expr/type.h:27,
 from
/home/***/system/include/cvc4/util/uninterpreted_constant.h:21,
 from /home/***/system/include/cvc4/expr/expr.h:55,
 from /home/***/system/include/cvc4/expr/command.h:31,
 from src/cvc4/cvc4_smt.cpp:4:
/usr/include/c++/6.1.1/limits:1598:7: internal compiler error: Illegal
instruction
   min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
   ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/71918] Internal compiler error: Illegal instruction

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-18
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
The preprocessed cvc4_operand_visitor.ii file.
What processor do you use? Which illegal instruction do you hit?
(Run gcc under gdb and look at the disassembly.)

[Bug debug/71906] [6/7 Regression] Fortran allocatable strings debug info type size regression

[jan.kratochvil at redhat dot com]

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

--- Comment #3 from Jan Kratochvil  ---
Could you attach here the ICC .s file if you have it handy?  Thanks.

[Bug middle-end/71734] [7 Regression] FAIL: libgomp.fortran/simd4.f90 -O3 -g execution test

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Mon Jul 18 14:30:20 2016
New Revision: 238435

URL: https://gcc.gnu.org/viewcvs?rev=238435=gcc=rev
Log:
gcc/

2016-07-18  Yuri Rumyantsev  

PR tree-optimization/71734
* tree-ssa-loop-im.c (ref_indep_loop_p_1): Add REF_LOOP argument which
contains REF, use it to check safelen, assume that safelen value
must be greater 1, fix style.
(ref_indep_loop_p_2): Add REF_LOOP argument.
(ref_indep_loop_p): Pass LOOP as additional argument to
ref_indep_loop_p_2.

gcc/testsuite/

2016-07-18  Yuri Rumyantsev  

PR tree-optimization/71734
* g++.dg/vect/pr70729.cc: Delete redundant dg options, fix style.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/vect/pr70729.cc
trunk/gcc/tree-ssa-loop-im.c

[Bug debug/71906] [6/7 Regression] Fortran allocatable strings debug info type size regression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Better testcase that shows more cases:

program pr71906
  character(len=8) :: vard
  character(len=:), allocatable :: vare
  type t
character(len=:), allocatable :: f
  end type
  type(t) :: varf
  allocate(character(len=10) :: vare)
  allocate(character(len=9) :: varf%f)
  vare = 'foo'
  call foo (vard, vare, varf)
contains
  subroutine foo (vara, varb, varc)
character(len=*) :: vara
character(len=:), allocatable :: varb
type(t) :: varc
vara = 'bar'
varb = 'baz'
varc%f = 'str'
  end subroutine
end program pr71906

The problem is that DW_AT_string_length attribute allows just exprloc or
loclistptr classes.  Even GCC 5.x doesn't handle here the varb case, and
varc/varf case.  For varb the string length is *.varb (.varb being an
artificial argument), for varc/varf the struct has fields f and _f_length.

With the early debug changes, nothing works anymore.

While DW_AT_upper_bound etc. allows a DIE ref, so even with early debug we can
put something (the DIE ref) into the attribute, for DW_AT_string_length we only
have a decl (VAR_DECL/PARM_DECL/FIELD_DECL) or INDIRECT_REF of it, the DIE for
it might not be created yet and even if it is, obviously it has no location
information yet (that only appears when we actually compile corresponding
function).

I've tried to use DW_OP_call4 in DW_AT_string_length, but I bet that will only
work if the artificial length vars have a DWARF expression in their
DW_AT_location (or DWARF expression in their DW_AT_location location list for
the current location), having something that ends up with DW_OP_stack_value
etc. is not valid DWARF I bet.

Another thing is the type of the f field.
The string length in that case is present in the same aggregate, but is not
necessarily adjacent to the f field (e.g. if one puts integer :: i field after
f, then the order is f, i, _f_length).
Not sure what to emit in those DW_AT_string_length for it at all right now.

Looking for what ICC emits, it doesn't emit anything useful for f, but for
varb and vare it emits
DW_OP_push_object_address; DW_OP_constu: 8; DW_OP_plus
as DW_AT_string_length.  It is unclear what they expect to be
DW_OP_push_object_address here, and what/if anything GDB expands it.  Is it the
address of the object that has the string type, or the address of the object
that has DW_TAG_pointer_type to DW_TAG_string_type, something else?

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[matthew.fortune at imgtec dot com]

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

Matthew Fortune  changed:

   What|Removed |Added

 CC||matthew.fortune at imgtec dot 
com

--- Comment #2 from Matthew Fortune  ---
Hi Rainer,

Sorry for the bugs, I am however tempted to say this will turn out to be a
libffi bug. You have described the same failure mode as I fixed for MIPS but
libjava is now following the ffi return type rules so my assumption is that it
is sparc ffi that is not. I've had a quick read of sparc ffi code and it seems
there is a chance that integer return types are not being promoted to word
size. I.e. following the ffi rule that integers smaller than a word are
returned as type ffi_arg.

Do you know if the two new testcases fail if built against a gij built without
my changes to java/lang/reflect/natVMProxy.cc and interpret-run.cc? I suspect
they may actually pass before but for the wrong reasons.

Does 64-bit sparc have problems with other codebases using ffi? libguile,
python being some notable examples?

Matthew

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
The failures are obviously caused by

2016-07-13  Matthew Fortune  

* java/lang/reflect/natVMProxy.cc (unbox): Use ffi_arg for
integer return types smaller than a word.
* testsuite/libjava.jar/ReturnInvocationHandler.java: New file.
* testsuite/libjava.jar/ReturnProxyTest.jar: Likewise.
* testsuite/libjava.jar/ReturnProxyTest.java: Likewise.
* testsuite/libjava.jar/ReturnProxyTest.out: Likewise.
* testsuite/libjava.jar/ReturnProxyTest.xfail: Likewise.
* testsuite/libjava.jar/ReturnTypes.java: Likewise.
* testsuite/libjava.jar/ReturnTypesImpl.java: Likewise.

2016-07-13  Matthew Fortune  

* interpret-run.cc: Use ffi_arg for FFI integer return types.
* testsuite/libjava.jar/arraysort.java: New file.
* testsuite/libjava.jar/arraysort.jar: New file.
* testsuite/libjava.jar/arraysort.out: New file.
* testsuite/libjava.jar/arraysort.xfail: New file.

[Bug rtl-optimization/71793] Volatile local variable passed by value is (wrongly?) optimised away, but the containing loop is not

[db0451 at gmail dot com]

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

--- Comment #4 from DB  ---
(In reply to Richard Biener from comment #3)
> Well, if you look at the out-of-line copies of the function then he is
> correct.
> But the inline copy in main() does not have this constraint and is still
> mishandled.  Note I didn't yet investigate closer what is going on.

For the out-of-line copies, surely they are not allowed to leave a declared as
volatile argument in a register and thereby break volatility? That seems
contrary to the requirements of the storage class. I'd expect special handling
to allocate a value on the stack prior to calling and refer to that in the
function instead.

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug java/71917] New: [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 71917
   Summary: [7 regression] libjava.jar/ReturnProxyTest.jar etc.
FAIL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: mpf at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Between 20160708 and 20160714, three new testsuite failures occured on 64-bit
Solaris/SPARC:

FAIL: libjava.jar/ReturnProxyTest.jar output - gij test
FAIL: libjava.jar/arraysort.jar output - gij test
FAIL: calls output - gij test

The failures appear both with 32-bit and 64-bit compilers, but only for the
64-bit multilib.

The first two are new tests, but the third is a regression from gcc 6.

For libjava.jar/ReturnProxyTest.jar, the output has NUL bytes instead of a.

For libjava.jar/arraysort.jar, the output has

Array of string, after:
[0] a
[1] c
[2] b
[3] d

instead of

Array of string, after:
[0] a
[1] b
[2] c
[3] d

For calls, the output has

void
fail

instead of

void

  Rainer

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-18
 CC||marxin at gcc dot gnu.org
Summary|gcc ICE at -O3 on valid |[6/7 Regression] ICE at -O3
   |code on x86_64-linux-gnu in |on valid code on
   |"maybe_record_trace_start"  |x86_64-linux-gnu in
   ||"maybe_record_trace_start"
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, it's GCC 6 regression.

[Bug rtl-optimization/71793] Volatile local variable passed by value is (wrongly?) optimised away, but the containing loop is not

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to DB from comment #2)
> Thanks Richard! About this -
> 
> > RTL expansion expands x as register copy for some reason
> 
> - is this person's explanation about this originating in the ABI accurate?
> http://stackoverflow.com/a/38248847/2757035
> 
> If so - again not that I expect anyone really to use this pattern! - but
> from a Standard perspective, I'm interested whether it forbids such register
> allocation, and whether any workaround is feasible. In practical terms, a
> very academic exercise :-) but valuable for its implications wrt the
> Standard and ABI

Well, if you look at the out-of-line copies of the function then he is correct.
But the inline copy in main() does not have this constraint and is still
mishandled.  Note I didn't yet investigate closer what is going on.

[Bug tree-optimization/71916] New: gcc ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[helloqirun at gmail dot com]

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

Bug ID: 71916
   Summary: gcc ICE at -O3 on valid code on x86_64-linux-gnu in
"maybe_record_trace_start"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at only -O3 on x86_64-linux-gnu in 64-bit mode. The 32-bit mode works fine.

It appears to be a 7 regression.

It might be related to PR71109, but that testcase cannot crash the current
trunk any more.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160717 (experimental) [trunk revision 238419] (GCC)


$ gcc-trunk -O3 abc.c
abc.c: In function ‘fn2’:
abc.c:35:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2284
 }
 ^
0x7e0d80 maybe_record_trace_start
../../gcc/gcc/dwarf2cfi.c:2284
0x7e1085 create_trace_edges
../../gcc/gcc/dwarf2cfi.c:2376
0x7e31d1 scan_trace
../../gcc/gcc/dwarf2cfi.c:2590
0x7e3cca create_cfi_notes
../../gcc/gcc/dwarf2cfi.c:2616
0x7e3cca execute_dwarf2_frame
../../gcc/gcc/dwarf2cfi.c:2974
0x7e3cca execute
../../gcc/gcc/dwarf2cfi.c:3454
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ cat abc.c
int a, b, c, d, f, g;
short h;
short (fn1) (short p1)
{
  return a >= 2 || p1 > 7 >> a ? p1 : p1 << a;
}

void fn2 ()
{
  for (;;)
{
  int j[3];
  int i;
  h = b >= 2 ? d : d >> b;
  if (fn1 (f > h ^ c))
{
  d = 0;
  for (; f <= 2;)
{
  char k[2];
  for (;; i++)
k[i] = 7;
}
}
  else
for (;;)
  {
int l = j[2];
g = l;
  }
  if (g)
for (;;)
  ;
}
}

[Bug rtl-optimization/71634] Invalid write with in mark_loops_for_removal (ira-build.c:2256) with --param ira-max-loops-num=0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
Summary|[4.9//5/6 Regression]   |Invalid write with in
   |Invalid write with in   |mark_loops_for_removal
   |mark_loops_for_removal  |(ira-build.c:2256) with
   |(ira-build.c:2256) with |--param ira-max-loops-num=0
   |--param ira-max-loops-num=0 |

--- Comment #6 from Martin Liška  ---
Fixed on all active branches.

[Bug rtl-optimization/71634] [4.9//5/6 Regression] Invalid write with in mark_loops_for_removal (ira-build.c:2256) with --param ira-max-loops-num=0

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Mon Jul 18 13:01:12 2016
New Revision: 238431

URL: https://gcc.gnu.org/viewcvs?rev=238431=gcc=rev
Log:
Fix PR rtl-optimization/71634

Backported from mainline
2016-07-12  Martin Liska  

* ira-build.c (mark_loops_for_removal): Properly iterate
loops.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ira-build.c

[Bug rtl-optimization/71634] [4.9//5/6 Regression] Invalid write with in mark_loops_for_removal (ira-build.c:2256) with --param ira-max-loops-num=0

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Mon Jul 18 12:59:10 2016
New Revision: 238430

URL: https://gcc.gnu.org/viewcvs?rev=238430=gcc=rev
Log:
Fix PR rtl-optimization/71634

Backported from mainline
2016-07-12  Martin Liska  

* ira-build.c (mark_loops_for_removal): Properly iterate
loops.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ira-build.c

[Bug rtl-optimization/71634] [4.9//5/6 Regression] Invalid write with in mark_loops_for_removal (ira-build.c:2256) with --param ira-max-loops-num=0

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Mon Jul 18 12:57:25 2016
New Revision: 238429

URL: https://gcc.gnu.org/viewcvs?rev=238429=gcc=rev
Log:
Fix PR rtl-optimization/71634

Backported from mainline
2016-07-12  Martin Liska  

* ira-build.c (mark_loops_for_removal): Properly iterate
loops.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ira-build.c

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #9 from Aurelien Jarno  ---
(In reply to ramana.radhakrishnan from comment #8)
> On 14/07/16 12:15, aurelien at aurel32 dot net wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833
> > 
> > --- Comment #7 from Aurelien Jarno  ---
> > (In reply to Ramana Radhakrishnan from comment #6)
> >> (In reply to Aurelien Jarno from comment #5)
> >>> (In reply to Ramana Radhakrishnan from comment #4)
>  Need to apply Aurelien's patch - looks like that's slipped through the
>  cracks.
> >>>
> >>> What was missing to the patch was a testcase which compiles on all 
> >>> platform.
> >>> This has happened recently, as part of the testcase for PR61441. I 
> >>> therefore
> >>> guess this patch can now be applied.
> >>
> >> Do you mind pinging it after another round of testing ? 
> >>
> > 
> > I have just done a another round on testing on trunk:
> > - The patch is still necessary.
> > - The patch still applies, but with fuzz. I'll resend an update patch.
> > - The patch still works as expected.
> > - The testcase for PR61441 does not seems to work for this bug as it is
> > compiled with -O1. GCC 6 does constant propagation and the resulting binary 
> > do
> > not call aeabi_f2d. With GCC 5 or with -O0 the testcase also work for his 
> > bug.
> > Is there a way to specify that a test should run with both -O0 and -O1? That
> > would avoid writing an almost identical testcase.
> 
> An option might be to move the test into gcc.c-torture/execute and then it
> will torture over all optimization levels and add the option needed with
> dg-additional-options ?

Ok, in that case, i'll add a patch specific for this bug. I am currently doing
a test rebuild, I'll send a new version of the patch in the next days.

Aurelien

[Bug target/71903] Wrong opcode using x86 SSE _mm_cmpge_ps intrinsics

[carlosrafael.prog at gmail dot com]

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

--- Comment #5 from Carlos Rafael  ---
(In reply to Mikael Pettersson from comment #3)
> No worries.  As the reporter you should be able to resolve it as "invalid".

Ok! Thanks!

[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange

[dhowells at redhat dot com]

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

--- Comment #11 from dhowells at redhat dot com  ---
I applied the patch to the Fedora cross-gcc-6.1.1 rpm with one minor fixup. 
Using the example code I added in bug 70825 I now see:

 :
   0:   ba 2a 00 00 00  mov$0x2a,%edx
   5:   b8 17 00 00 00  mov$0x17,%eax
   a:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
   e:   c3  retq   

there's now no extraneous store before the locked instruction.  And:

000f :
   f:   ba 2a 00 00 00  mov$0x2a,%edx
  14:   b8 17 00 00 00  mov$0x17,%eax
  19:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
  1d:   c3  retq   

it now just passes the return value of cmpxchg back directly without
potentially putting on and off the stack and maybe jumping round that bit. 
And:

0043 :
  43:   ba 2a 00 00 00  mov$0x2a,%edx
  48:   b8 17 00 00 00  mov$0x17,%eax
  4d:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
  51:   c3  retq   

where it makes no difference changing how the the return-statements are
contructed in C.

I've also booted a kernel built with the patched compiler.

[Bug debug/71906] [6/7 Regression] Fortran allocatable strings debug info type size regression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-18
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|Fortran allocatable strings |[6/7 Regression] Fortran
   |debug info type size|allocatable strings debug
   |regression  |info type size regression
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Broken by r224161.

[Bug c++/71912] flexible array in union

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
This changed with r231665.  I'll let Martin argue whether this is intentional
or not and why.

[Bug c++/71912] flexible array in union

[drepper.fsp+rhbz at gmail dot com]

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

--- Comment #2 from drepper.fsp+rhbz at gmail dot com  ---
If it is accepted that this code should work (as I also expect) then this bug
should also be marked as a regression to 5.x.  6.1 at least is broken, I don't
know when it stopped working.

[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-18
 CC||segher at gcc dot gnu.org
  Known to work||4.9.1
 Ever confirmed|0   |1
  Known to fail||5.1.0

--- Comment #1 from Segher Boessenkool  ---
Confirmed.

Instead of disabling the current code that generates .machine, it would
work better to extend that code to handle more CPUs.  ".machine ppc"
works fine for all instructions GCC generates itself, but not for asm
code, as you found out.

As a workaround, you can code the desired SPR number manually.

[Bug tree-optimization/71769] Invalid warning from -Wunsafe-loop-optimizations for a finite loop

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to nightstrike from comment #0)
> Created attachment 38834 [details]
> Testcase
> 
> In the attached testcase, function f compiles without warning for -O[023],
> but function g warns for -O[0123].  The warning is "warning: cannot optimize
> possibly infinite loops [-Wunsafe-loop-optimizations]".  The functions are
> very similar, and I don't think it should warn in either case, as the
> conditionals verify that the loop isn't infinite.
> 
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/opt/gcc6/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.1.0/
> lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-6.1.0/configure --prefix=/gcc6
> --enable-libstdcxx-time=rt --disable-multilib
> --enable-languages=all,ada,obj-c++ --enable-plugins --with-gnu-as
> --with-gnu-ld
> Thread model: posix
> gcc version 6.1.0 (GCC)
> 
> $ gcc -c -std=gnu99 a.c -Wunsafe-loop-optimizations -O3
> 
> a.c: In function ‘g’:
> a.c:18:2: warning: cannot optimize possibly infinite loops
> [-Wunsafe-loop-optimizations]
>   for(int i = a; i <= b; ++i)
>   ^~~
> 
> $ cat a.c
> // Warning with -Wunsafe-loop-optimizations and -O1 only
> void f(int * x, int a, int b) {
>   if (b < a) b = a;
>   if (a < 1) return;
> 
>   for (int i = a; i <= b; ++i)
>   x[i] += 1;
> }
> 
> struct S {
> unsigned int * data;
> unsigned int * d2;
> };
> 
> // Warning with -Wunsafe-loop-optimizations and -O1 or above
> void g(struct S * x, int a, int b) {
> if (b < a) b = a;
> if (a < 1) return;
> 
> for(int i = a; i <= b; ++i)
> __builtin_memcpy(x->data, x->d2, 5);
> }

Well, the two loops have subtle difference here.  Because function call
__bultin_memcpy has side effect and could exit the loop directly, it's possible
for variable "b" equals to MAX_VALUE_OF(int) int the second loop without
triggering any undefined overflow behavior.  From loop niter analyzer's point
of view, it has to analyze the loop with assumption that "b !=
MAX_VALUE_OF(int)".  Unfortunately, GCC in effect doesn't use niter information
with assumptions in various loop optimizations.  
This could be seen as a missed optimization opportunities.  Currently GCC
computes exit_must_be_taken in loop_only_exit_p and considers side-effect
function calls.  There is one way around, we could accept side-effect function
calls and analyze the loop as normal ones.  In this case, the user of niter
information needs to take the responsibility deciding the niter information can
be used in code transform.  IVOPT has already done this in iv elimination.  

Having this said, I tend to keep the current behavior because:
1) It might not be very useful.  One application would be in ivcanon pass, but
I can't come up other optimizer that can benefit from this.

2) This complicates customers of niter analyzer.  They need to check if new
undefined overflow behavior is introduced.  Might be easier to handle it in
niter analyzer, with a little cost of missed ivcanon (or some other
optimizations?)

[Bug middle-end/71907] [6/7 regression] missing buffer overflow warnings with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
We can stream a fake abstract origin, refering to $self.  That fixes the issue
but I'm not sure of all the side-effects.

Testing that.

[Bug c++/71909] [4.9/5/6/7 Regression] g++ accepts an unreachable function catch block that lacks a corresponding try

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/71879] Error in unevaluated context breaks SFINAE

[inadgob at yahoo dot com]

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

bogdan  changed:

   What|Removed |Added

 CC||inadgob at yahoo dot com

--- Comment #2 from bogdan  ---
(In reply to Jonathan Wakely from comment #1)
> Taking the address of Foo::foo instantiates it, which results in an
> error outside the immediate context, so you get an error not a substitution
> failure.

Yes, GCC tries to instantiate the definition of the specialization, but I don't
think it should.

[temp.inst]/3: Unless a function template specialization has been explicitly
instantiated or explicitly specialized, the function template specialization is
implicitly instantiated when the specialization is referenced in a context that
requires a function definition to exist. [...]

[temp.inst]/8: An implementation shall not implicitly instantiate a function
template, a variable template, a member template, a non-virtual member
function, a member class, or a static data member of a class template that does
not require instantiation. [...]

I don't think forming a pointer to a member function as an operand to decltype
like in this example should, by itself, require the function's definition to
exist; after all, we're only interested in the type. In this case, determining
it doesn't require deduction of any placeholder type or evaluation of any
constant expression. I don't see how the definition could influence the
resulting type.

In terms of odr-use, the template-id for the specialization appears as a
subexpression of an unevaluated operand, so it's not potentially evaluated, so
[basic.def.odr] doesn't require a definition.

The example works on Clang, EDG and MSVC, so none of them attempts to
instantiate the definition.

[Bug middle-end/71907] [6/7 regression] missing buffer overflow warnings with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
So the issue is that the BLOCK of the call is one w/o an abstract origin (its
supercontext is the inline-BLOCK).  This is because LTO drops all abstract
origins but FUNCTION_DECLs (aka inlined_function_outer_scope_p).

This has been this way in GCC 5 as well but I suppose we were lucky to drop
the inner BLOCK there for some reason.  In fact the situation was the same
there we just failed to preserve the in-system-header bit of the location:

In function ‘strcpy’,
inlined from ‘main’ at /tmp/t.c:5:5:
/usr/include/bits/string3.h:104:10: warning: call to __builtin___memcpy_chk
will always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
  ^