[Bug c++/68125] New: std::sqrt prevent use of associative math

[vincenzo.innocente at cern dot ch]

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

Bug ID: 68125
   Summary: std::sqrt prevent use of associative math
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

with -Ofast

the code generated differs
float rsqrt1(float a, float x, float y) {
   return a/std::sqrt(x)/std::sqrt(y);
}

float rsqrt2(float a, float x, float y) {
   return a/sqrtf(x)/sqrtf(y);
}

rsqrt1(float, float, float):
sqrtss  %xmm2, %xmm2
sqrtss  %xmm1, %xmm1
mulss   %xmm2, %xmm1
divss   %xmm1, %xmm0
ret
rsqrt2(float, float, float):
mulss   %xmm1, %xmm2
rsqrtss %xmm2, %xmm1
mulss   %xmm1, %xmm2
mulss   %xmm1, %xmm2
mulss   .LC9(%rip), %xmm1
addss   .LC8(%rip), %xmm2
mulss   %xmm1, %xmm2
mulss   %xmm2, %xmm0
ret

[Bug inline-asm/68095] "cc" clobber with Flag Output Operands

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
"=@ccc"(r) does not output to the "cc" register, it outputs to a general
register.  It clobbers the "cc" register.  Mentioning that more than
once ("=@ccc", the clobber in the asm, and it is default for the x86
target) is no problem and has clear semantics.

The "cc" clobber is not deprecated, not on other targets anyway.
Even on x86 it still serves to mark those asms that really clobber
the flags register, which can be helpful to the reader.

[Bug c/67999] Wrong optimization of pointer comparisons

[joseph at codesourcery dot com]

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

--- Comment #24 from joseph at codesourcery dot com  ---
I suppose that while EXACT_DIV_EXPR on the individual halves of a 
subtraction wouldn't be correct, it would also be correct (given any 
constant element size) to do the (right shift, multiply by reciprocal of 
odd part) combination, that works for exact division without needing a 
multiplication high part, on each pointer, because the subtraction would 
cancel out the matching errors from the two pointers not being divisible 
by the size of the type.

[Bug c++/68094] Compiler segmentation fault

[baqwas at gmail dot com]

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

--- Comment #3 from Matha Goram  ---
For error, please see attachment that has the screen shot.

[Bug c++/68094] Compiler segmentation fault

[baqwas at gmail dot com]

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

--- Comment #2 from Matha Goram  ---
Created attachment 36600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36600&action=edit
Pre-processed source file

Per request to attach pre-processed source file

[Bug target/68124] [6 Regression] Many i386 test failures

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Also

FAIL: gcc.dg/gomp/simd-clones-2.c (internal compiler error)
FAIL: gcc.dg/gomp/simd-clones-2.c (test for excess errors)
FAIL: gcc.dg/lto/simd-function c_lto_simd-function_0.o-c_lto_simd-function_0.o
link,  -fopenmp-simd -O3 -ffast-math -mavx2 -flto -flto-partition=max 
(internal compiler error)
FAIL: gcc.dg/vect/pr64421.c -flto -ffat-lto-objects (internal compiler error)
FAIL: gcc.dg/vect/pr64421.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/pr64421.c (internal compiler error)
FAIL: gcc.dg/vect/pr64421.c (test for excess errors)
FAIL: gcc.dg/vect/vect-simd-clone-11.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-11.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-simd-clone-11.c (internal compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-11.c (test for excess errors)
FAIL: gcc.dg/vect/vect-simd-clone-13.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-13.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-simd-clone-13.c (internal compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-13.c (test for excess errors)
FAIL: gcc.dg/vect/vect-simd-clone-14.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-14.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-simd-clone-14.c (internal compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-14.c (test for excess errors)
FAIL: gcc.dg/vect/vect-simd-clone-15.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-15.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-simd-clone-15.c (internal compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-15.c (test for excess errors)
FAIL: gcc.dg/vect/vect-simd-clone-1.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-1.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-simd-clone-1.c (internal compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-1.c (test for excess errors)
FAIL: gcc.dg/vect/vect-simd-clone-6.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-6.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-simd-clone-6.c (internal compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-6.c (test for excess errors)
FAIL: gcc.dg/vect/vect-simd-clone-7.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-7.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-simd-clone-7.c (internal compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-7.c (test for excess errors)
FAIL: gcc.target/i386/avx2-gather-1.c (internal compiler error)
FAIL: gcc.target/i386/avx2-gather-1.c (test for excess errors)
FAIL: gcc.target/i386/avx2-gather-2.c (internal compiler error)
FAIL: gcc.target/i386/avx2-gather-2.c scan-tree-dump-times vect "note:
vectorized 1 loops in function" 16
FAIL: gcc.target/i386/avx2-gather-2.c (test for excess errors)
FAIL: gcc.target/i386/avx2-pr63594-1.c (internal compiler error)
FAIL: gcc.target/i386/avx2-pr63594-1.c (test for excess errors)
FAIL: gcc.target/i386/avx2-pr63594-2.c (internal compiler error)
FAIL: gcc.target/i386/avx2-pr63594-2.c (test for excess errors)
FAIL: gcc.target/i386/avx2-vect-shift.c (internal compiler error)
FAIL: gcc.target/i386/avx2-vect-shift.c (internal compiler error)
FAIL: gcc.target/i386/avx2-vect-shift.c (test for excess errors)
FAIL: gcc.target/i386/avx2-vect-shift.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-pr63594-1.c (internal compiler error)
FAIL: gcc.target/i386/avx512f-pr63594-1.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-pr63594-2.c (internal compiler error)
FAIL: gcc.target/i386/avx512f-pr63594-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vec-init.c (internal compiler error)
FAIL: gcc.target/i386/avx512f-vec-init.c (test for excess errors)
FAIL: gcc.target/i386/pr51235.c (internal compiler error)
FAIL: gcc.target/i386/pr51235.c (test for excess errors)
FAIL: gcc.target/i386/pr51236.c (internal compiler error)
FAIL: gcc.target/i386/pr51236.c (test for excess errors)
FAIL: gcc.target/i386/pr58137.c (internal compiler error)
FAIL: gcc.target/i386/pr58137.c (test for excess errors)
FAIL: gcc.target/i386/pr64110.c (internal compiler error)
FAIL: gcc.target/i386/pr64110.c (internal compiler error)
FAIL: gcc.target/i386/pr64110.c (test for excess errors)
FAIL: gcc.target/i386/pr64110.c (test for excess errors)
FAIL: gcc.target/i386/pr67447.c (internal compiler error)
FAIL: gcc.target/i386/pr67447.c (test for excess errors)
FAIL: g++.dg/vect/simd-clone-1.cc  -std=c++11 (internal compiler error)
FAIL: g++.dg/vect/simd-clone-1.cc  -std=c++11 (test for excess errors)
FAIL: g++.dg/vect/simd-clone-1.cc  -std=c++14 (internal compiler error)
FAIL: g++.dg/vect/simd-clone-1.cc

[Bug c/68119] GCC diagnostic push/pop interfere with control flow statements

[jbrandmeyer at google dot com]

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

--- Comment #3 from Jonathan  ---
I can see how 6.10.6.1 grants GCC very broad latitude in how to treat its own
pragmas.  However, if the implementation is going to define this preprocessing
directive to behave as a statement, then it should at least be documented as
such in the manual.

For the C and C++ front-ends to operate differently with respect to this issue
is especially astonishing.

[Bug c/67999] Wrong optimization of pointer comparisons

[bugdal at aerifal dot cx]

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

--- Comment #23 from Rich Felker  ---
I think you can always do the right-shift first. Pointer subtraction is
undefined unless both pointers point to elements of the same array, and the
addresses of elements of an array will inherently be congruent modulo the size
of an element.

[Bug c/67999] Wrong optimization of pointer comparisons

[joseph at codesourcery dot com]

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

--- Comment #22 from joseph at codesourcery dot com  ---
On Tue, 27 Oct 2015, ch3root at openwall dot com wrote:

> What is missing in the discussion is a cost of support in gcc of objects 
> with size > PTRDIFF_MAX. I guess overhead in compiled code would be 
> minimal while headache in gcc itself is noticable. But I could be wrong.

I think the biggest overhead would include that every single pointer 
subtraction, where the target type is (or might be, in the case or VLAs) 
larger than one byte, would either need to have conditional code for what 
order the pointers are in, or would need to extend to a wider type, 
subtract in that type, divide in that type and then reduce to ptrdiff_t; 
it would no longer be possible to do (ptrdiff_t subtraction, then 
EXACT_DIV_EXPR on ptrdiff_t).  There would be other things, such as 
pointer addition / subtraction of integers needing to handle values 
outside the range of ptrdiff_t, but it's pointer subtraction that I expect 
would have the main runtime overhead.

(On strict alignment targets, for naturally-aligned power-of-two element 
sizes, you could do logical shifts on the pointers before doing a signed 
subtraction, so that case needn't be quite as inefficient as the general 
case.)

[Bug target/68124] [6 Regression] Many i386 test failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
They failed with -mtune=corei7.

[Bug target/68124] [6 Regression] Many i386 test failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #1 from H.J. Lu  ---
It was cased by r229458:

[hjl@gnu-ivb-1 gcc]$ ./xgcc -B./ -march=corei7 -O3 -mavx2 -S
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/pr58137.c
-m32
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/pr58137.c:
In function \u2018more_xrv\u2019:
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/pr58137.c:33:1:
internal compiler error: in gen_reg_rtx, at emit-rtl.c:1031
 }
 ^
0x99ad69 gen_reg_rtx(machine_mode)
../../../../gcc/gcc/emit-rtl.c:1031
0x9bae10 copy_to_reg(rtx_def*)
../../../../gcc/gcc/explow.c:570
0xd26e50 gen_lowpart_general(machine_mode, rtx_def*)
../../../../gcc/gcc/rtlhooks.c:62
0x13fddbb gen_split_392(rtx_insn*, rtx_def**)
../../../../gcc/gcc/config/i386/sse.md:17100
0x15ab55b split_23
../../../../gcc/gcc/config/i386/sse.md:17098
0x15ac314 split_24
../../../../gcc/gcc/config/i386/i386.md:4803
0x15afe7c split_insns(rtx_def*, rtx_insn*)
../../../../gcc/gcc/config/i386/i386.md:15867
0x9a1011 try_split(rtx_def*, rtx_insn*, int)
../../../../gcc/gcc/emit-rtl.c:3666
0xcbce89 split_insn
../../../../gcc/gcc/recog.c:2874
0xcbd161 split_all_insns()
../../../../gcc/gcc/recog.c:2964
0xcbef85 rest_of_handle_split_after_reload
../../../../gcc/gcc/recog.c:3902
0xcbefd6 execute
../../../../gcc/gcc/recog.c:3931
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-ivb-1 gcc]$

[Bug c/68119] GCC diagnostic push/pop interfere with control flow statements

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug c/68119] GCC diagnostic push/pop interfere with control flow statements

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #2 from Andrew Pinski  ---
I don't think this is a bug. #pragma here is being treated as a statement.
There has been a few bugs about this in the last year too. Yes it is confusing
but the c standard allows it.

[Bug c/67999] Wrong optimization of pointer comparisons

[ch3root at openwall dot com]

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

--- Comment #21 from Alexander Cherepanov  ---
On 2015-10-21 06:21, danielmicay at gmail dot com wrote:
>> I think several issues are mixed:
>
> A conforming C implementation requires either fixing both the compiler and 
> libc
> functions to handle > PTRDIFF_MAX objects or preventing them from being
> allocated via standard mechanisms (and *ideally* documenting the restriction).

Yes, but:
1) a practical C implementation is not isolated and have to be able to 
work with external objects (e.g. received from a kernel);
2) a conforming C implementation could be freestanding;
3) the situation is not symmetric. You cannot make a libc be able 
process huge objects until a compiler is able to do it. IOW if the 
compiler supports huge objects then you have a freedom choose whether 
you want your libc to support them or not.

> Since there are many other issues with > PTRDIFF_MAX objects (p - q, 
> read/write
> and similar uses of ssize_t, etc.) and few reasons to allow it, it really 
> makes
> the most sense to tackle it in libc.

Other issues where? In typical user code? Then compiler/libc shouldn't 
create them objects with size > PTRDIFF_MAX. It doesn't mean shouldn't 
be able to deal with them. E.g., I can imagine a libc where malloc 
doesn't create such object by default but have a system-wide, per-user 
or even compile-time option to enable such a feature. Or you can limit 
memory with some system feature (ulimit, cgroups) independently from 
libc (mentioned by Florian Weimer elsewhere).

Lack of compiler's support more or less makes all these possimilities 
impossible.

What is missing in the discussion is a cost of support in gcc of objects 
with size > PTRDIFF_MAX. I guess overhead in compiled code would be 
minimal while headache in gcc itself is noticable. But I could be wrong.

>> How buggy? Are there bugs filed? Searching for PTRDIFF_MAX finds Zarro Boogs.
>
> It hasn't been treated as a systemic issue or considered as something related
> to PTRDIFF_MAX. You'd need to search for issues like ssize_t overflow to find
> them. If you really want one specific example, it looks like there's at least
> one case of `end - start` in stdlib/qsort.c among other places (char *mid = lo
> + size * ((hi - lo) / size >> 1);).

Ok, in this specific example, 'end - start' is divided by a value of 
size_t type and, hence, is casted to an unsigned type giving a right 
thing in the end.

> I don't think fixing every usage of `end -
> start` on arbitrarily sized objects is the right way to go, so it's not
> something I'd audit for and file bugs about.

I was going to try to submit this bug but the code turned out to be 
working fine. Not that the code is valid C but the situation is a bit 
trickier than simple "the function doesn't work for this data".

Another example?

>> For this to work a compiler have to support for working with huge objects, 
>> right?
>
> Well, they might just need a contiguous allocation without the need to 
> actually
> use it all at once. It doesn't necessarily require compiler support, but it
> could easily go wrong without compiler support if the semantics of the
> implementation aren't clearly laid out (and at the moment it's definitely not
> documented).

Exactly! It's a mine field.

[Bug c++/68114] gcc doesn't show error when return type of deleted function is incomplete

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I disagree. According to [dcl.fct] p11 of the current working draft:

"The type of a parameter or the return type for a function definition shall not
be an incomplete (possibly cv-qualified) class type in the context of the
function
definition unless the function is deleted (8.4.3)."

This wording came in via

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1394

Clang does not accept the code example, but that looks like a clang defect to
me.

[Bug target/68124] New: [6 Regression] Many i386 test failures

[hjl.tools at gmail dot com]

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

Bug ID: 68124
   Summary: [6 Regression] Many i386 test failures
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86, r229459 gave

FAIL: gcc.target/i386/avx2-vect-shift.c (internal compiler error)
FAIL: gcc.target/i386/avx2-vect-shift.c (test for excess errors)
FAIL: gcc.target/i386/pr51235.c (internal compiler error)
FAIL: gcc.target/i386/pr51235.c (test for excess errors)
FAIL: gcc.target/i386/pr58137.c (internal compiler error)
FAIL: gcc.target/i386/pr58137.c (test for excess errors)
FAIL: gcc.target/i386/pr64110.c (internal compiler error)
FAIL: gcc.target/i386/pr64110.c (test for excess errors)

r229452 is OK.

[Bug middle-end/68112] [6 Regression] FAIL: gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for excess errors)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
 CC||alalaw01 at gcc dot gnu.org
  Component|testsuite   |middle-end
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It was caused by r229437.

[Bug preprocessor/68118] C preprocessor inserts whitespace after macro parameter substitution

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
Not a bug; the textual output of the preprocessor is intended to be suitable
for relexing as C and producing the correct sequence of preprocessing tokens
from that relexing, which requires spaces to be inserted in some places.  If
you stringize the result of the expansion, you will see that the string
produced does not have the extra space, in accordance with the C standard,
which defines textual output only to the extent that it is stringized.

[Bug c/68119] GCC diagnostic push/pop interfere with control flow statements

[dj at redhat dot com]

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

DJ Delorie  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
 CC||dj at redhat dot com
 Ever confirmed|0   |1

--- Comment #1 from DJ Delorie  ---
Confirmed with git trunk as of today, even with -O0.  Gimple shows:

test1 (unsigned int a)
{
  unsigned int D.1764;

  if (0 != 0) goto ; else goto ;
  :
  a = a + 1;
  :
  a = a + 1;
  D.1764 = a;
  return D.1764;
}

test2 (unsigned int a)
{
  unsigned int D.1768;

  if (0 != 0) goto ; else goto ;
  :
  :
  a = a + 1;
  a = a + 1;
  D.1768 = a;
  return D.1768;
}

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
Thanks to Steven Kargl: confirming that our code completely works again with
gcc's r229446.

[Bug c/68123] GCC vector extension behaves funny with large vector size

[dxin at usc dot edu]

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

--- Comment #1 from Dehuan Xin  ---
compiler info:
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.11 - Linaro GCC
2013.10) 4.8.3 2013 (prerelease)

[Bug c/68123] New: GCC vector extension behaves funny with large vector size

[dxin at usc dot edu]

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

Bug ID: 68123
   Summary: GCC vector extension behaves funny with large vector
size
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dxin at usc dot edu
  Target Milestone: ---

Created attachment 36599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36599&action=edit
test source file

It would complete unroll the loop and produces a huge assembly.
With -O3 the produced assembly is smaller, but compilation takes a lot longer
than no -O3. 

I attached test source file.
With
CFLAGS=-std=gnu11 -O3 -mcpu=cortex-a9 -mfloat-abi=hard -mfpu=neon -fPIE -Wall
-S -fverbose-asm
it compiles to a 57K line assembly and takes about 2min to compile, on a XEON
1245v3 machine.

Tested on "GCC: (crosstool-NG linaro-1.13.1-4.8-2013.11 - Linaro GCC 2013.10)
4.8.3 2013 (prerelease)"

[Bug sanitizer/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm

[larsbj at gullik dot net]

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

--- Comment #1 from Lars Gullik Bjønnes  ---
Command used to call:

gcc -fsanitize=undefined -fgnu-tm tm-thread.c

[Bug sanitizer/68122] New: ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm

[larsbj at gullik dot net]

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

Bug ID: 68122
   Summary: ICE in gcc/toplev.c:353 with -fsanitize=undefined and
-fgnu-tm
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

This program:

int cnt = 0;

int main(void)
{
  __transaction_atomic {
cnt++;
  }
}

Gives

tm-thread.c: In function ‘main’:
tm-thread.c:8:1: internal compiler error: Segmentation fault
 }
 ^
0x98b74f crash_signal
../../gcc/gcc/toplev.c:353
0x98f8e4 is_tm_pure_call
../../gcc/gcc/trans-mem.c:275
0x98ff19 ipa_tm_scan_calls_block
../../gcc/gcc/trans-mem.c:4158
0x993653 ipa_tm_scan_calls_transaction
../../gcc/gcc/trans-mem.c:4211
0x993653 ipa_tm_execute
../../gcc/gcc/trans-mem.c:5385
0x993653 execute
../../gcc/gcc/trans-mem.c:5623

When compiled with

gcc (GCC) 6.0.0 20151022 (experimental)

[Bug c/68121] New: __builtin_constant_p should not warn about integer overflow

[eggert at gnu dot org]

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

Bug ID: 68121
   Summary: __builtin_constant_p should not warn about integer
overflow
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

Compile this with "gcc -S" (x86-64):

  enum {
x = 20,
y = 20,
a = __builtin_constant_p (x + y) ? x : -1,
  };

GCC warns "integer overflow in expression [-Woverflow]" and points to the "+",
even though the "+" is not evaluated. This sort of warning should be disabled
in the argument of __builtin_constant_p, just as it's disabled in the argument
of other expressions like sizeof that do not actually evaluate their arguments.
In the above case, __builtin_constant_p should return 1 without warning about
overflow.

I ran into this problem when using a macro definition like this:

 #define INT_ADD_OVERFLOW(a, b) \
   (__builtin_constant_p ((a) + (b)) \
? _GL_INT_ADD_OVERFLOW (a, b) \
: __builtin_add_overflow (a, b, &(__typeof__ ((a) + (b))) {0}))

where _GL_INT_ADD_OVERFLOW (a, b) expands to a complicated expression that does
not overflow, and that yields 1 if A+B would overflow. GCC incorrectly warned
about (a)+(b) overflowing in the argument of __builtin_constant_p. I worked
around the bug by changing the first "+" to "==" in the macro body, but that's
kinda weird.

[Bug c/68120] New: can't easily deal with integer overflow at compile time

[eggert at gnu dot org]

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

Bug ID: 68120
   Summary: can't easily deal with integer overflow at compile
time
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

This is a followup to Bug#61129, which asked for integer-overflow-detecting
arithmetic intrinsics. We have them now (thanks!) but I'm running into some
problems using them.

The Gnulib intprops module defines macros to check for integer overflow, e.g.,
INT_ADD_OVERFLOW (a, b) returns 1 if the C expression A+B would overflow. These
macros are implemented in portable C. I'm trying to use GCC 5's new
__builtin_add_overflow etc. functions to speed up their runtime execution. This
turns out to be a pain because these macros are used in integer constant
expressions, where __builtin_add_overflow etc. cannot be used.

I am working around the problem with macro definitions like this:

 # define INT_ADD_OVERFLOW(a, b) \
   (__builtin_constant_p ((a) == (b)) \
? _GL_INT_ADD_OVERFLOW (a, b) \
: __builtin_add_overflow (a, b, &(__typeof__ ((a) + (b))) {0}))

where _GL_INT_ADD_OVERFLOW is a complex macro implemented in Standard C and is
a constant expression when its arguments are constant expressions. Although I
think this will work, it is ugly, and the macro _GL_INT_ADD_OVERFLOW is
complicated.

To simplify use of __builtin_add_overflow etc., I suggest extending these
builtins as follows.

First, allow the 3rd argument to be a null pointer constant of type
pointer-to-integer, meaning that the caller only wants to know if the overflow
occurred and does not want the low-order bits of the result. E.g.,
__builtin_add_overflow (a, b, (int *) 0) returns 1 if the mathematical value of
A + B does not fit in 'int'.  This would allow the above macro to be simplified
to:

 # define INT_ADD_OVERFLOW(a, b) \
   __builtin_add_overflow (a, b, (__typeof__ ((a) + (b)) *) 0)

Second, allow the 3rd argument to be omitted, as a shorthand for a null pointer
to the integer type of A+B. This further simplification would allow the above
macro to be simplified to:

  # define INT_ADD_OVERFLOW(a, b) __builtin_add_overflow (a, b)

Third, add a function __builtin_add_wrapv (a, b, c) that acts like
__builtin_add_overflow (a, b, c) except that it returns the value that would be
stored if C were a non-null pointer.  The 3rd argument C is optional here too,
with the same semantics as for __builtin_add_overflow.  This will let the user
get the bottom-order bits of an overflowed value in a constant expression,
something that can't be done with the current primitives.

The basic idea here is that we need intrinsics that deal with values and that
do not require non-null addresses, so that we can use these intrinsics in
constant expressions.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rth at gcc dot gnu.org]

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

--- Comment #32 from Richard Henderson  ---
Author: rth
Date: Tue Oct 27 19:59:41 2015
New Revision: 229458

URL: https://gcc.gnu.org/viewcvs?rev=229458&root=gcc&view=rev
Log:
PR rtl-opt/67609

* config/i386/i386.c (ix86_cannot_change_mode_class): Disallow
narrowing subregs on SSE and MMX registers.
* doc/tm.texi.in (CANNOT_CHANGE_MODE_CLASS): Clarify when subregs that
appear to be sub-words of multi-register pseudos must be rejected.
* doc/tm.texi: Regenerate.
testsuite/
* gcc.target/i386/pr67609-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr67609-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/testsuite/ChangeLog

[Bug c/68119] New: GCC diagnostic push/pop interfere with control flow statements

[jbrandmeyer at google dot com]

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

Bug ID: 68119
   Summary: GCC diagnostic push/pop interfere with control flow
statements
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbrandmeyer at google dot com
  Target Milestone: ---

Created attachment 36598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36598&action=edit
Minimal test case

If the control-flow portion of a control-flow statement is wrapped with #pragma
GCC diagnostic push and pop, the subsequent brace-enclosed block is incorrectly
executed.  It is behaving as if the "diagnostic pop" inserts an additional
hidden semicolon.

In the attached minimal test case, test1 and test2 should both increment a by
1.  However, test2 actually increments a by 2.  Both "if" and "while"
statements are affected.

Observed in GCC 4.8.4 and 4.9.3.  G++ does not suffer from this issue. 
Optimization must be enabled to trigger this bug.  Even -Og is enough.  Despite
the use of -Wtype-limits in the example, other forms are also affected (ie,
-Wunused in that place also triggers this bug).

[Bug preprocessor/68118] New: C preprocessor inserts whitespace after macro parameter substitution

[harry.clauson at hyatt dot com]

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

Bug ID: 68118
   Summary: C preprocessor inserts whitespace after macro
parameter substitution
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: harry.clauson at hyatt dot com
  Target Milestone: ---

The following C macro appears to expand incorrectly:

harry@slack32x:~$ cat test_whitespace.c

#define my_mac(_name,_op,_val) _name _op=_val

my_mac(i,|,4);
my_mac(i,blah,4);

Here is the gcc pre-processor output:

harry@slack32x:~$ gcc -v -E -Wall -Wextra -std=c99 test_whitespace.c
Using built-in specs.
COLLECT_GCC=gcc
Target: i686-pc-linux-gnu
Configured with: ../gcc-5.2.0/configure --prefix=/home/harry/local
--enable-languages=c,c++
Thread model: posix
gcc version 5.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-E' '-Wall' '-Wextra' '-std=c99' '-mtune=generic'
'-march=pentiumpro'
 /home/harry/local/libexec/gcc/i686-pc-linux-gnu/5.2.0/cc1 -E -quiet -v
test_whitespace.c -mtune=generic -march=pentiumpro -std=c99 -Wall -Wextra
ignoring nonexistent directory
"/home/harry/local/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/harry/local/lib/gcc/i686-pc-linux-gnu/5.2.0/include
 /usr/local/include
 /home/harry/local/include
 /home/harry/local/lib/gcc/i686-pc-linux-gnu/5.2.0/include-fixed
 /usr/include
End of search list.
# 1 "test_whitespace.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test_whitespace.c"


i | =4;
i blah=4;


The expansion when _op = | appears to insert whitespace between the parameter
value and the following token (=) which does not appear in the replacement
list.

When _op = blah, the expansion works as expected without inserting whitespace
between the parameter and the following token (=).

Thank you!

[Bug middle-end/68116] [6 Regression] ice in add_expr, at tree.c:7840

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
 CC||trippels at gcc dot gnu.org
  Component|c++ |middle-end
Summary|ice in add_expr, at |[6 Regression] ice in
   |tree.c:7840 |add_expr, at tree.c:7840
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat bug239.cc
class Visitor {
  void visitWinDeclSpec();
  typedef void (Visitor::*visitor_fun_ptr)(int);
  static visitor_fun_ptr b[];
};
Visitor::visitor_fun_ptr Visitor::b[]{
visitor_fun_ptr(&Visitor::visitWinDeclSpec)};

markus@x4 tmp % g++ -c -O2 bug239.cc
bug239.cc: In function ‘void __static_initialization_and_destruction_0(int,
int)’:
bug239.cc:6:26: internal compiler error: in add_expr, at tree.c:7840
 Visitor::visitor_fun_ptr Visitor::b[]{
  ^
0xf27703 inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc/gcc/tree.c:7840
0xf2748f inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc/gcc/tree.c:7852
0xf271bb inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc/gcc/tree.c:7813
0xa8df71 iterative_hash_expr
../../gcc/gcc/tree.h:4610
0xa8df71 gimplify_hasher::hash(gimple_temp_hash_elt const*)
../../gcc/gcc/gimplify.c:10614
0xa8df71 hash_table::find_slot(gimple_temp_hash_elt* const&, insert_option)
../../gcc/gcc/hash-table.h:408
0xa8df71 lookup_tmp_var
../../gcc/gcc/gimplify.c:513
0xa8df71 internal_get_tmp_var
../../gcc/gcc/gimplify.c:548
0xa86b0f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10059
0xa94240 gimplify_modify_expr
../../gcc/gcc/gimplify.c:4644
0xa8794e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:9126
0xa8baa6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5551
0xa87d6d gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5327
0xa87d6d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:9489
0xa8baa6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5551
0xa8823b gimplify_statement_list
../../gcc/gcc/gimplify.c:1474
0xa8823b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:9541
0xa8baa6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5551
0xa902d2 gimplify_cond_expr
../../gcc/gcc/gimplify.c:3173
0xa87bb6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:9082

[Bug middle-end/68117] [6 Regression] ICE: Segmentation fault building Firefox on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Started with r229437.

[Bug middle-end/68117] New: [6 Regression] ICE: Segmentation fault building Firefox on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 68117
   Summary: [6 Regression] ICE: Segmentation fault building
Firefox on ppc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc2-power8 libvorbis % /home/trippels/gcc_test/usr/local/bin/gcc -o
Unified_c_media_libvorbis0.o -c -I../../dist/system_wrappers -include
/home/trippels/gecko-dev/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM
-DAB_CD=en-US -DNO_NSPR_10_SUPPORT -I/home/trippels/gecko-dev/media/libvorbis
-I. -I/home/trippels/gecko-dev/media/libvorbis/lib -I../../dist/include
-I/usr/include/nspr4 -I/home/trippels/moz-build-dir/dist/include/nss
-I/usr/include/pixman-1 -fPIC -include ../../mozilla-config.h -DMOZILLA_CLIENT
-MD -MP -MF .deps/Unified_c_media_libvorbis0.o.pp -Wall
-Wdeclaration-after-statement -Wempty-body -Wpointer-to-int-cast -Wsign-compare
-Wtype-limits -Werror=char-subscripts -Werror=comment -Werror=endif-labels
-Werror=enum-compare -Werror=ignored-qualifiers -Werror=int-to-pointer-cast
-Werror=multichar -Werror=nonnull -Werror=pointer-arith -Werror=pointer-sign
-Werror=return-type -Werror=sequence-point -Werror=trigraphs
-Werror=unknown-pragmas -Wno-unused -Wcast-align -w -ffunction-sections
-fdata-sections -std=gnu99 -fgnu89-inline -fno-strict-aliasing -fno-math-errno
-pthread -pipe -DNDEBUG -DTRIMMED -O3 -fomit-frame-pointer -Wno-uninitialized
/home/trippels/moz-build-dir/media/libvorbis/Unified_c_media_libvorbis0.c
In file included from
/home/trippels/moz-build-dir/media/libvorbis/Unified_c_media_libvorbis0.c:137:0:
/home/trippels/gecko-dev/media/libvorbis/lib/vorbisenc.c: In function
‘get_setup_template’:
/home/trippels/gecko-dev/media/libvorbis/lib/vorbisenc.c:633:20: error: invalid
PHI argument
 static const void *get_setup_template(long ch,long srate,
^
<<< Unknown tree:  >>>
/home/trippels/gecko-dev/media/libvorbis/lib/vorbisenc.c:633:20: internal
compiler error: Segmentation fault
0x107f7e73 crash_signal
../../gcc/gcc/toplev.c:353
0x1084fe44 contains_struct_check
../../gcc/gcc/tree.h:3032
0x1084fe44 verify_gimple_phi
../../gcc/gcc/tree-cfg.c:4669
0x1084fe44 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:4963
0x106f98e3 execute_function_todo
../../gcc/gcc/passes.c:1968
0x106fa5e3 do_per_function
../../gcc/gcc/passes.c:1659
0x106fa8ff execute_todo
../../gcc/gcc/passes.c:2025
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Adding --save-temp to the above makes the issue go away.

Valgrind shows:

/home/trippels/gecko-dev/media/libvorbis/lib/vorbisenc.c:633:20: error: invalid
PHI argument
 static const void *get_setup_template(long ch,long srate,
^
<<< Unknown tree:  >>>
==2662== Invalid read of size 1
==2662==at 0x1084FE44: contains_struct_check (tree.h:3032)
==2662==by 0x1084FE44: verify_gimple_phi (tree-cfg.c:4669)
==2662==by 0x1084FE44: verify_gimple_in_cfg(function*, bool)
(tree-cfg.c:4963)
==2662==by 0x106F98E3: execute_function_todo(function*, void*)
(passes.c:1968)
==2662==by 0x106FA5E3: do_per_function(void (*)(function*, void*), void*)
(passes.c:1659)
==2662==by 0x106FA8FF: execute_todo(unsigned int) (passes.c:2025)
==2662==by 0x106FE287: execute_one_pass(opt_pass*) (passes.c:2357)
==2662==by 0x106FE763: execute_pass_list_1(opt_pass*) (passes.c:2397)
==2662==by 0x106FE77B: execute_pass_list_1(opt_pass*) (passes.c:2398)
==2662==by 0x106FE77B: execute_pass_list_1(opt_pass*) (passes.c:2398)
==2662==by 0x106FE803: execute_pass_list(function*, opt_pass*)
(passes.c:2408)
==2662==by 0x1034A7CF: cgraph_node::expand() (cgraphunit.c:1983)
==2662==by 0x1034C7B7: expand_all_functions (cgraphunit.c:2119)
==2662==by 0x1034C7B7: symbol_table::compile() (cgraphunit.c:2472)
==2662==by 0x1034EEBB: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2562)
==2662==  Address 0x118b0961 is not stack'd, malloc'd or (recently) free'd
==2662==

[Bug fortran/67806] ICE on initialization of type(character) with len null

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
As far as can tell, this is fixed by my patches for PR 67805
and PR 67108.

[Bug target/68102] [5/6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 with float64x1_t @ aarch64

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Oct 27 18:32:37 2015
New Revision: 229455

URL: https://gcc.gnu.org/viewcvs?rev=229455&root=gcc&view=rev
Log:
[AArch64] PR 68102: Check that operand is REG before checking the REGNO in
mov-immediate splitters

PR target/68102
* config/aarch64/aarch64.md (*movsi_aarch64): Check that
operands[0] is a reg before taking its REGNO in split condition.
(*movdi_aarch64): Likewise.

* gcc.target/aarch64/pr68102_1.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr68102_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog

[Bug c/68065] Size calculations for VLAs can overflow

[danielmicay at gmail dot com]

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

Daniel Micay  changed:

   What|Removed |Added

 CC||danielmicay at gmail dot com

--- Comment #9 from Daniel Micay  ---
> VLA also does not detect stack overflows either.

Stack overflows are detected with -fstack-check, or at least they would be if
the option worked properly: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66479
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65958

I've always found it quite bad that well-defined code with GCC can actually be
exploited (arbitrary write vulnerabilities) due to the fact that -fstack-check
is not enabled by default. MSVC++ and Clang on Windows guarantee that stack
overflows from well-defined code (large stack frames, VLAs) will be caught.
However, the switch seems to cause a significant performance hit for functions
where it triggers (which are rare but sometimes performance critical, a good
example is jemalloc's rbtree implementation which uses arrays rather than
recursion) and compatibility issues due to the way it's currently implemented:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265/.

[Bug testsuite/67948] xor-and.c needs updating after r228661

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed now.

[Bug fortran/67933] [5/6 Regression] ICE for array of a derived type with allocatable class in derived type object

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Tue Oct 27 18:03:18 2015
New Revision: 229452

URL: https://gcc.gnu.org/viewcvs?rev=229452&root=gcc&view=rev
Log:
2015-01-27  Paul Thomas  

PR fortran/67933
* gfortran.dg/allocate_with_source_15.f03: New test

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/68116] New: ice in add_expr, at tree.c:7840

[dcb314 at hotmail dot com]

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

Bug ID: 68116
   Summary: ice in add_expr, at tree.c:7840
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For trunk dated 20151025, I get the following error message,
when the attached code is compiled with -O2 -march=native.

/home/dcb/rpmbuild/BUILD/smokegen-4.14.3/parser/visitor.cpp: In function ‘void
_
_static_initialization_and_destruction_0(int, int)’:
/home/dcb/rpmbuild/BUILD/smokegen-4.14.3/parser/visitor.cpp:21:26: internal
comp
iler error: in add_expr, at tree.c:7840
 Visitor::visitor_fun_ptr Visitor::_S_table[AST::NODE_KIND_COUNT] = {
  ^
0x104fce6 inchash::add_expr(tree_node const*, inchash::hash&)
../../src/trunk/gcc/tree.c:7840
0x104fa80 inchash::add_expr(tree_node const*, inchash::hash&)
../../src/trunk/gcc/tree.c:7852
0x104f842 inchash::add_expr(tree_node const*, inchash::hash&)
../../src/trunk/gcc/tree.c:7813
0xb0a231 iterative_hash_expr
../../src/trunk/gcc/tree.h:4610

The machine is x86_64

[Bug fortran/65045] [4.9/5/6 Regression] ICE when using the same name for a block and a variable.

[paul.richard.thomas at gmail dot com]

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

--- Comment #8 from paul.richard.thomas at gmail dot com  ---
I have been working my through my backlog of patches/PRs as you might
have noticed. This one, being a regression is next but two :-)

Cheers

Paul

On 27 October 2015 at 18:30, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045
>
> --- Comment #7 from Dominique d'Humieres  ---
> On Tobias Burnus 2015-03-12 15:59:34 UTC Tobias Burnus wrote:
>> Looks good to me - okay with a test case and a ChangeLog.
>
> What is the status of this patch?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug fortran/65045] [4.9/5/6 Regression] ICE when using the same name for a block and a variable.

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
On Tobias Burnus 2015-03-12 15:59:34 UTC Tobias Burnus wrote:
> Looks good to me - okay with a test case and a ChangeLog.

What is the status of this patch?

[Bug libfortran/68115] New: [6 Regression] Unsatisfied symbol "__sync_lock_test_and_set_4" in file /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl

[danglin at gcc dot gnu.org]

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

Bug ID: 68115
   Summary: [6 Regression] Unsatisfied symbol
"__sync_lock_test_and_set_4" in file
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../
libgfortran/.libs/libgfortran.sl
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

This causes many libgomp testsuite failures:

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
../../../../gcc/
libgomp/testsuite/libgomp.fortran/affinity1.f90
-B/test/gnu/gcc/objdir/hppa64-hp
-hpux11.11/./libgomp/
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/.libs
 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp
-I../../../../gcc/libgomp/
testsuite/../../include -I../../../../gcc/libgomp/testsuite/..
-fmessage-length=
0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp
-B/test/gnu/gcc
/objdir/hppa64-hp-hpux11.11/./libgomp/../libquadmath/.libs/ -O2
-B/test/gnu/gcc/
objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs
-fintrinsic-modules-pa
th=/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp
-L/test/gnu/gcc/objdir/hpp
a64-hp-hpux11.11/./libgomp/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./li
bgomp/../libquadmath/.libs/
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp
/../libgfortran/.libs -lgfortran -lm -o ./affinity1.exe
ld: (Warning) Unsatisfied symbol "__sync_lock_test_and_set_4" in file
/test/gnu/
gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
ld: (Warning) Unsatisfied symbol "__sync_bool_compare_and_swap_8" in file
/test/
gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
2 warnings.
output is:
ld: (Warning) Unsatisfied symbol "__sync_lock_test_and_set_4" in file
/test/gnu/
gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
ld: (Warning) Unsatisfied symbol "__sync_bool_compare_and_swap_8" in file
/test/
gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
2 warnings.

[Bug c/68065] Size calculations for VLAs can overflow

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
I think it's undefined at the point where a type exceeds the limit on the 
size of an object (half the address space minus one byte), whether or not 
sizeof is used or any object with that type is constructed - that is, as 
soon as the language semantics involve evaluation of the array sizes for 
the VLA type in question.  (If the sizes are neither evaluated nor 
required, e.g. sizeof (int (*)[size]), or when replaced by [*] at function 
prototype scope, I don't consider that undefined; if required but not 
evaluated, as in certain obscure cases of conditional expressions, that's 
a different case of undefined behavior.)

[Bug c++/68114] New: gcc doesn't show error when return type of deleted function is incomplete

[vanyacpp at gmail dot com]

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

Bug ID: 68114
   Summary: gcc doesn't show error when return type of deleted
function is incomplete
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

struct z;

z f() = delete; // should be an error here

As I understand, f is a function definition and return type of function
definition must be complete.

[Bug fortran/63865] [OpenACC] support acc cache

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Fixed in r229448.

[Bug fortran/63865] [OpenACC] support acc cache

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Oct 27 16:54:52 2015
New Revision: 229448

URL: https://gcc.gnu.org/viewcvs?rev=229448&root=gcc&view=rev
Log:
[PR fortran/63865] OpenACC cache directive: match Fortran support with C/C++

gcc/fortran/
PR fortran/63865
* openmp.c (resolve_oacc_cache): Remove function.
(gfc_match_oacc_cache): Enable array sections.
(resolve_omp_clauses, gfc_resolve_oacc_directive): Change
accordingly.
* trans-openmp.c (gfc_trans_omp_clauses): Likewise.
gcc/testsuite/
PR fortran/63865
* gfortran.dg/goacc/coarray.f95: Expect the OpenACC cache
directive to work.
* gfortran.dg/goacc/loop-1.f95: Likewise.
* gfortran.dg/goacc/cache-1.f95: Likewise, and extend testing.
* gfortran.dg/goacc/cray.f95: Likewise.
* gfortran.dg/goacc/parameter.f95: Likewise.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/cache-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/coarray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/parameter.f95

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
I've committed a patch that should fix this
regression.  Sorry about the inconvenience.

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Oct 27 16:42:24 2015
New Revision: 229446

URL: https://gcc.gnu.org/viewcvs?rev=229446&root=gcc&view=rev
Log:
2015-10-27  Steven G. Kargl  

PR fortran/68108
* decl.c (char_len_param_value): Check for REF_ARRAY.

2015-10-27  Steven G. Kargl  

PR fortran/68108
* gfortran.dg/pr67805_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr67805_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/68066] [6 Regression]: ICE in max_value, at wide-int.cc

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Was it fixed by the patch?

[Bug middle-end/68066] [6 Regression]: ICE in max_value, at wide-int.cc

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-27
 CC||vries at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ienkovich at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/68068] [6 Regression] ICE: in get_untransformed_body, at cgraph.c:3268

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
 CC||vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from vries at gcc dot gnu.org ---
confirmed.

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||tschwinge at gcc dot gnu.org

--- Comment #6 from Thomas Schwinge  ---
(In reply to Dominique d'Humieres from comment #5)
> Is this fixed after r220189?

No.

[Bug c++/68113] New: VLA+typeof+new -- confusing warning

[ch3root at openwall dot com]

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

Bug ID: 68113
   Summary: VLA+typeof+new -- confusing warning
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Compilation of the program:

int main()
{
  int n = 1;
  int a[n];
  new __typeof__ a;

  return 0;
}

with just `g++ vla-typeof-new.cpp` outputs:

vla-typeof-new.cpp: In function ‘int main()’:
vla-typeof-new.cpp:5:18: warning: non-constant array new length must be
specified without parentheses around the type-id [-Wvla]
   new __typeof__ a;
  ^

Perhaps the code is invalid but the warning is kinda confusing (there are no
parentheses here:-)

[Bug fortran/63865] [OpenACC] support acc cache

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-27
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug testsuite/68112] New: [6 Regression] FAIL: gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for excess errors)

[hjl.tools at gmail dot com]

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

Bug ID: 68112
   Summary: [6 Regression] FAIL:
gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for
excess errors)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com
  Target Milestone: ---

On Linux/x86, r229437 gave

spawn -ignore SIGHUP /export/gnu/import/git/gcc-test-ia32corei7/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-ia32corei7/bld/gcc/
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c
-B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/
-B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/mpxrt
-L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/mpxrt/.libs
-B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/
-B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/mpxwrap
-L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/mpxwrap/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -mavx512ifma -lm -o
./avx512ifma-vpmaddhuq-2.exe^M
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c:
In function 'test_512':^M
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c:41:29:
warning: iteration 4 invokes undefined behavior
[-Waggressive-loop-optimizations]^M
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c:36:3:
note: within this loop^M
output is:
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c:
In function 'test_512':^M
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c:41:29:
warning: iteration 4 invokes undefined behavior
[-Waggressive-loop-optimizations]^M
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c:36:3:
note: within this loop^M

FAIL: gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for excess errors)
Excess errors:
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c:41:29:
warning: iteration 4 invokes undefined behavior
[-Waggressive-loop-optimizations]

r229395 is OK.

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[renlin at gcc dot gnu.org]

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

--- Comment #11 from renlin at gcc dot gnu.org ---
> 
> Hi Martin,
> 
> After the backport patch to branch 5, aarch-none-elf fails to build because
> of the following ICEs.
> 

I mean "aarch64-none-elf" here, sorry for the typo.

[Bug target/67215] -fno-plt needs improvements for x86

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed.

[Bug target/67215] -fno-plt needs improvements for x86

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Oct 27 14:29:31 2015
New Revision: 229444

URL: https://gcc.gnu.org/viewcvs?rev=229444&root=gcc&view=rev
Log:
Properly handle -fno-plt in ix86_expand_call

prepare_call_address in calls.c is the wrong place to handle -fno-plt.
We shoudn't force function address into register and hope that load
function address via GOT and indirect call via register will be folded
into indirect call via GOT, which doesn't always happen.  Also non-PIC
case can only be handled in backend.  Instead, backend should expand
external function call into indirect call via GOT for -fno-plt.

This patch reverts -fno-plt in prepare_call_address and handles it in
ix86_expand_call.  Other backends may need similar changes to support
-fno-plt.  Alternately, we can introduce a target hook to indicate
whether an external function should be called via register for -fno-plt
so that i386 backend can disable it in prepare_call_address.

gcc/

PR target/67215
* calls.c (prepare_call_address): Don't handle -fno-plt here.
* config/i386/i386.c (ix86_expand_call): Generate indirect call
via GOT for -fno-plt.  Support indirect call via GOT for x32.
* config/i386/predicates.md (sibcall_memory_operand): Allow
GOT memory operand.

gcc/testsuite/

PR target/67215
* gcc.target/i386/pr67215-1.c: New test.
* gcc.target/i386/pr67215-2.c: Likewise.
* gcc.target/i386/pr67215-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr67215-1.c
trunk/gcc/testsuite/gcc.target/i386/pr67215-2.c
trunk/gcc/testsuite/gcc.target/i386/pr67215-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug c/68065] Size calculations for VLAs can overflow

[ch3root at openwall dot com]

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

--- Comment #7 from Alexander Cherepanov  ---
On 2015-10-27 03:15, joseph at codesourcery dot com wrote:
>> VLA size overflow is very similar to overflow in "new". Shouldn't it be
>> handled in a similar way?
>
> I'm thinking of it as essentially like stack overflow,

The problem is not limited to stack allocations. The example in comment 
#3 works for VLAs as well. This would a quite elegant way to deal with 
untrusted sizes but it seem you cannot get away without any arithmetic 
check at all:-( Maybe saturated arithmetic for sizes could help but 
that's another can of worms.

Well, the problem in non-stack case seems to be in sizeof. My take: 
sizeof is an operator and C11, 6.5p5 applies to it:

   If an exceptional condition occurs during the evaluation of
   an expression (that is, if the result is not mathematically
   defined or not in the range of representable values for its
   type), the behavior is undefined.

That is, an oversized VLA is fine but taking its sizeof is UB. This is 
somewhat similar to how pointer difference is UB when outside ptrdiff_t 
range.

There could be an argument that sizeof works with unsigned types and 
hence should wrap per C11, 6.2.5p9:

   A computation involving unsigned operands can never overflow,
   because a result that cannot be represented by the resulting
   unsigned integer type is reduced modulo the number that is
   one greater than the largest value that can be represented
   by the resulting type.

But sizeof doesn't directly compute anything with its operand (even if 
it's unsigned). Therefore this rule is not applicable.

It seems I can convince myself that non-stack case is Ok:-)

> where it's
> traditionally been the user's job to bound their stack allocations.

Yes, and it's a pity that there is no diagnostics for stack allocation 
problems by default given it's not UB and the code could be conforming 
according to the C standards.

> I think ubsan should enable all of (VLA size overflow checks,

Yes, catching overflows in "sizeof(int[size])" is definitely nice. But 
catching "_Alignof(int[size])" etc. for huge "size" is probably fine too.

> stack checking
> for fixed-size allocations to ensure the amount of stack space allocated
> in one go is small enough that overflow is guaranteed to be detected,
> similar checks for variable size allocations whether from VLAs or alloca).
> Of course separate options for various cases may make sense as well.

It's not practiced in gcc to track such things via the bug tracker?

[Bug middle-end/67989] [4.9/5/6 Regression] g++ ICE on armel valid code

[costamagnagianfranco at yahoo dot it]

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

--- Comment #16 from Gianfranco  ---
thanks a lot for the help! with this we will finally finish ocaml and llvm
Debian transitions :)

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Testing a patch.

[Bug middle-end/67989] [4.9/5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from ktkachov at gcc dot gnu.org ---
Fixed on all release branches.

[Bug middle-end/67989] [4.9/5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

--- Comment #14 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Oct 27 14:07:04 2015
New Revision: 229443

URL: https://gcc.gnu.org/viewcvs?rev=229443&root=gcc&view=rev
Log:
[optabs.c] Fix PR 67989: Handle const0_rtx target in
expand_atomic_compare_and_swap

Backport from mainline
2015-10-26  Kyrylo Tkachov  

PR middle-end/67989
* optabs.c (expand_atomic_compare_and_swap): Handle case when
ptarget_oval or ptarget_bool are const0_rtx.

* g++.dg/pr67989.C: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr67989.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/optabs.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/67989] [4.9/5/6 Regression] g++ ICE on armel valid code

[ktkachov at gcc dot gnu.org]

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

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Oct 27 14:03:27 2015
New Revision: 229442

URL: https://gcc.gnu.org/viewcvs?rev=229442&root=gcc&view=rev
Log:
[optabs.c] Fix PR 67989: Handle const0_rtx target in
expand_atomic_compare_and_swap

Backport from mainline
2015-10-26  Kyrylo Tkachov  

PR middle-end/67989
* optabs.c (expand_atomic_compare_and_swap): Handle case when
ptarget_oval or ptarget_bool are const0_rtx.

* g++.dg/pr67989.C: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/pr67989.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/optabs.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/66660] [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption

[jakub at jermar dot eu]

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

--- Comment #2 from Jakub Jermar  ---
Has there been any progress on this front?

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Fixed on trunk, GCC 5 and 4.9 branches

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Oct 27 13:52:27 2015
New Revision: 229441

URL: https://gcc.gnu.org/viewcvs?rev=229441&root=gcc&view=rev
Log:
[ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

PR target/67929
* config/arm/arm.c (vfp3_const_double_for_bits): Rewrite.
* config/arm/constraints.md (Dp): Update callsite.
* config/arm/predicates.md (const_double_vcvt_power_of_two): Likewise.

* gcc.target/arm/pr67929_1.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr67929_1.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/arm.c
branches/gcc-4_9-branch/gcc/config/arm/constraints.md
branches/gcc-4_9-branch/gcc/config/arm/predicates.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/68104] [6 Regression] ice in vect_update_misalignment_for_peel with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68104] [6 Regression] ice in vect_update_misalignment_for_peel with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 27 13:48:15 2015
New Revision: 229440

URL: https://gcc.gnu.org/viewcvs?rev=229440&root=gcc&view=rev
Log:
2015-10-27  Richard Biener  

PR tree-optimization/68104
* tree-vect-data-refs.c (vect_compute_data_ref_alignment): Move
strided access check ...
(vect_compute_data_refs_alignment): ... here.

* gcc.dg/torture/pr68104.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr68104.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Oct 27 13:46:15 2015
New Revision: 229439

URL: https://gcc.gnu.org/viewcvs?rev=229439&root=gcc&view=rev
Log:
[ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

PR target/67929
* config/arm/arm.c (vfp3_const_double_for_bits): Rewrite.
* config/arm/constraints.md (Dp): Update callsite.
* config/arm/predicates.md (const_double_vcvt_power_of_two): Likewise.

* gcc.target/arm/pr67929_1.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr67929_1.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm.c
branches/gcc-5-branch/gcc/config/arm/constraints.md
branches/gcc-5-branch/gcc/config/arm/predicates.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Oct 27, 2015 at 10:54:53AM +, mikael at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68108
> 
> --- Comment #3 from Mikael Morin  ---
> (In reply to kargl from comment #1)
> > Tentative patch
> > 
> > Index: decl.c
> > ===
> > --- decl.c  (revision 229390)
> > +++ decl.c  (working copy)
> > @@ -754,7 +754,8 @@ char_len_param_value (gfc_expr **expr, b
> >  
> >gfc_reduce_init_expr (e);
> >  
> > -  if ((e->ref && e->ref->u.ar.type != AR_ELEMENT) 
> > +  if ((e->ref && e->ref->type == REF_ARRAY
> > +  && e->ref->u.ar.type != AR_ELEMENT) 
> >   || (!e->ref && e->expr_type == EXPR_ARRAY))
> 
> There is another unguarded ref->u.ar access a few lines above.
> It doesn't trigger as often, because it's a == condition, but it's still worth
> fixing.
> Otherwise looks good.
> 

Thanks for pointing out the other condition.
I'll commit the fix later today.

[Bug middle-end/65962] Missed vectorization of strided stores

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Ah, great!  More vectorization is good. :)  Thanks for looking into this so
quickly!

Bill

[Bug go/67976] Cgo + Gccgo not working like Cgo + Golang?

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
The patch behind the link in comment 2 fixes the problem.

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Oct 27 12:23:51 2015
New Revision: 229436

URL: https://gcc.gnu.org/viewcvs?rev=229436&root=gcc&view=rev
Log:
[ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

PR target/67929
* config/arm/arm.c (vfp3_const_double_for_bits): Rewrite.
* config/arm/constraints.md (Dp): Update callsite.
* config/arm/predicates.md (const_double_vcvt_power_of_two): Likewise.

* gcc.target/arm/pr67929_1.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr67929_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/constraints.md
trunk/gcc/config/arm/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68097] We should track ranges for floating-point values too

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Oct 27 11:52:54 2015
New Revision: 229423

URL: https://gcc.gnu.org/viewcvs?rev=229423&root=gcc&view=rev
Log:
Move signbit folds to match.pd

Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi.

gcc/
* builtins.c (fold_builtin_signbit): Delete.
(fold_builtin_2): Handle constant signbit arguments here.
* match.pd: Add rules previously handled by fold_builtin_signbit.

gcc/testsuite/
PR tree-optimization/68097
* gcc.dg/torture/builtin-nonneg-1.c: Skip at -O0.  Add
--param max-ssa-name-query-depth=3 to dg-options.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/builtin-nonneg-1.c

[Bug target/68102] [5/6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 with float64x1_t @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-27
 CC||ktkachov at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed.
This needs RTL checking enabled to trigger

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[vogt at linux dot vnet.ibm.com]

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

--- Comment #12 from Dominik Vogt  ---
The test code also crashes on x86_64 with the current gcc-5-branch and the
gcc-6 development branch.

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[renlin at gcc dot gnu.org]

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

renlin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #10 from renlin at gcc dot gnu.org ---
 (In reply to Martin Jambor from comment #9)
> Author: jamborm
> Date: Mon Oct 26 14:36:43 2015
> New Revision: 229367
> 
> URL: https://gcc.gnu.org/viewcvs?rev=229367&root=gcc&view=rev
> Log:
> Also remap SSA_NAMEs of PARM_DECLs in IPA-SRA
> 
> 2015-10-26  Martin Jambor  
> 
>   PR tree-optimization/67794
>   * tree-sra.c (replace_removed_params_ssa_names): Do not distinguish
>   between types of statements but accept original definitions as a
>   parameter.
>   (ipa_sra_modify_function_body): Use FOR_EACH_SSA_DEF_OPERAND to
>   iterate over definitions.
> 
> testsuite/
> * gcc.dg/ipa/ipa-sra-10.c: New test.
> * gcc.dg/torture/pr67794.c: Likewise.
> 
> 
> Added:
> branches/gcc-5-branch/gcc/testsuite/gcc.dg/ipa/ipa-sra-10.c
> branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr67794.c
> Modified:
> branches/gcc-5-branch/gcc/ChangeLog
> branches/gcc-5-branch/gcc/testsuite/ChangeLog
> branches/gcc-5-branch/gcc/tree-sra.c

Hi Martin,

After the backport patch to branch 5, aarch-none-elf fails to build because of
the following ICEs.

gcc/gcc/tree-sra.c: In function ‘tree_node*
replace_removed_params_ssa_names(tree, gimple_statement_base**,
ipa_parm_adjustment_vec)’:
gcc/gcc/tree-sra.c:4609:39: error: cannot convert ‘gimple_statement_base**’ to
‘gimple’ for argument ‘2’ to ‘tree_node* make_ssa_name(tree, gimple)’
gcc/gcc/tree-sra.c: In function ‘bool
ipa_sra_modify_function_body(ipa_parm_adjustment_vec)’:
gcc/gcc/tree-sra.c:4703:73: error: cannot convert ‘gphi*’ to
‘gimple_statement_base**’ for argument ‘2’ to ‘tree_node*
replace_removed_params_ssa_names(tree, gimple_statement_base**,
ipa_parm_adjustment_vec)’
gcc/gcc/tree-sra.c:4772:23: error: cannot convert ‘gimple’ to
‘gimple_statement_base**’ for argument ‘2’ to ‘tree_node*
replace_removed_params_ssa_names(tree, gimple_statement_base**,
ipa_parm_adjustment_vec)’

[Bug middle-end/65962] Missed vectorization of strided stores

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
The main difference is

+/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-62.c:39:3: 
note: LOOP VECTORIZED
+/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-62.c:39:3: 
note: OUTER LOOP VECTORIZED
...
-/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-62.c:9:5:
note: vectorized 1 loops in function.
+/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-62.c:9:5:
note: vectorized 2 loops in function.

so we now vectorize two loops.  The newly vectorized loop is

  /* Multidimensional array. Aligned. The "inner" dimensions
 are invariant in the inner loop. Vectorizable, but the
 vectorizer detects that everything is invariant and that
 the loop is better left untouched. (it should be optimized away). */
  for (i = 0; i < N; i++)
{
  for (j = 0; j < N; j++)
{
   ia[i][1][8] = ib[i];
}
}

on x86_64 the latch block is not empty - for some reason not so on ppc.
I suspect that if we had a cddce pass after loop invariant/store motion
(which should make the inner loop empty) we'd even remove the inner loop
and vectorize this regularly.

Ah, so on x86_64 we PREd ib[0] while on ppc the ib initializer is probably
in a constant pool entry.  Yes:

  :
  ib = *.LC0;

vs.

  :
  ib[0] = 0;
  ib[1] = 3;
  ib[2] = 6;
  ib[3] = 9;
...

The PRE heuristic to not confuse vectorization doesn't fire here.

I have a fix for that (and the testcase).

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin  ---
(In reply to kargl from comment #1)
> Tentative patch
> 
> Index: decl.c
> ===
> --- decl.c  (revision 229390)
> +++ decl.c  (working copy)
> @@ -754,7 +754,8 @@ char_len_param_value (gfc_expr **expr, b
>  
>gfc_reduce_init_expr (e);
>  
> -  if ((e->ref && e->ref->u.ar.type != AR_ELEMENT) 
> +  if ((e->ref && e->ref->type == REF_ARRAY
> +  && e->ref->u.ar.type != AR_ELEMENT) 
>   || (!e->ref && e->expr_type == EXPR_ARRAY))

There is another unguarded ref->u.ar access a few lines above.
It doesn't trigger as often, because it's a == condition, but it's still worth
fixing.
Otherwise looks good.

[Bug go/67976] Cgo + Gccgo not working like Cgo + Golang?

[vogt at linux dot vnet.ibm.com]

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

--- Comment #3 from Dominik Vogt  ---
When do you expect Go 1.5 to be merged?

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from Mikael Morin  ---
*** Bug 68111 has been marked as a duplicate of this bug. ***

[Bug fortran/68111] [6 Regression] 465.tonto in SPEC CPU 2006 failed to build

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #1 from Mikael Morin  ---
Dup.

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

[Bug fortran/68111] [6 Regression] 465.tonto in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/68111] New: [6 Regression] 465.tonto in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 68111
   Summary: [6 Regression] 465.tonto in SPEC CPU 2006 failed to
build
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86-64, r229293 gave

gfortran -c -o textfile.fppized.o -O2 -ffast-math textfile.fppized.f90
textfile.fppized.f90:3745:16:

   character(self%int_width) :: int_string
1
Error: Scalar INTEGER expression expected at (1)
textfile.fppized.f90:3746:16:

   character(self%real_width) :: real_string
1
Error: Scalar INTEGER expression expected at (1)
textfile.fppized.f90:3752:18:

 int_string = string
  1
Error: Symbol 'int_string' at (1) has no IMPLICIT type
textfile.fppized.f90:3749:19:

 real_string = string
   1
Error: Symbol 'real_string' at (1) has no IMPLICIT type
specmake[3]: *** [textfile.fppized.o] Error 1

r229284 is OK.

[Bug testsuite/68063] FAIL: libgomp.c++/member-2.C execution test

[tschwinge at gcc dot gnu.org]

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

--- Comment #5 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Oct 27 10:32:32 2015
New Revision: 229411

URL: https://gcc.gnu.org/viewcvs?rev=229411&root=gcc&view=rev
Log:
[PR testsuite/68063] Add missing private clause in libgomp.c++/member-1.C

PR testsuite/68063
* testsuite/libgomp.c++/member-1.C (A::m1): Add missing private clause.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.c++/member-1.C

[Bug fortran/68101] Provide a way to allocate arrays aligned to 32 bytes

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I would say dependent on an environment variable libgfortran could use
posix_memalign to allocate to a requested alignment.  IIRC it also inlines
some direct malloc calls into the code thus those would need to be adjusted as
well (for those the compiler can take advantage of the extra alignment as
well).
Alternatives are C11 aligned_alloc.

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[vogt at linux dot vnet.ibm.com]

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

--- Comment #11 from Dominik Vogt  ---
Created attachment 36596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36596&action=edit
Minimal test code

The attached test code causes the ICE on s390x and x86_64 using gccgo-5.2.0.

[Bug target/68102] [5/6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 with float64x1_t @ aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Biener  ---
(In reply to Richard Henderson from comment #28)
> (In reply to Richard Biener from comment #26)
> > Hmm, I don't see this documented anywhere.  In fact there is no such
> > thing as a "vector register", there are only vector modes.  And we
> > are using %xmm for plain SF/DFmode all over the place.
> > 
> > Note that in the particular case the mode we subreg is TImode,
> > not a vector mode.
> 
> You're right, my language was sloppy.  The problem I describe is going
> to be true for any register whose reg_raw_mode is larger than word_mode.
> 
> The assumption is that assignment to a word_mode subreg both (1) cannot
> affect bits outside the word_mode and (2) can be simplified to a plain
> hard register post-reload.
> 
> Part deux is impossible when reg_raw_mode is larger than word_mode,
> because the subreg-y assignment result is indistinguishable from a
> normal word_mode assignment.
> 
> > That may be a workaround for x86 but I don't see how this fixes the
> > issue in general given that targets may have general registers larger
> > than word_mode
> 
> It doesn't fix other targets, true.  But I don't see how to do that
> without changes to each target.

Drop (2)?  But that requires to touch every target as well I guess
(and can't be done incrementally).

If we go with your fix can you please amend the documentation to mention
this problem and suggest what targets need (not) to do to not run into
this problem?

> > (is x32 TARGET_64BIT?).
> 
> Yes.

[Bug tree-optimization/68104] [6 Regression] ice in vect_update_misalignment_for_peel with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Richard Biener  ---
I will have a look.

#1  0x0173dc4c in vect_update_misalignment_for_peel (dr=0x2544220, 
dr_peel=0x261e090, npeel=0)
at /space/rguenther/src/svn/trunk/gcc/tree-vect-data-refs.c:871
871   gcc_assert (DR_MISALIGNMENT (dr) / dr_size ==
(gdb) p dr_size
$1 = 1
(gdb) p dr_peel_size
$2 = 2
(gdb) p dr_misalignment (dr)
$3 = -1
(gdb) p dr_misalignment (dr_peel)
$4 = 0

[Bug tree-optimization/68105] optimizing repeated floating point addition to multiplication

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  One thing is that the x + x -> 2*x canonicalization GCC has for
this
purpose is done in fold-const.c only (probably ok, see below).

Second thing is that the reassociation pass does _not_ do this optimization.
Testcase for that:

float foo (float x)
{
  float tem = x + x;
  float tem2 = tem + x;
  tem = tem2 + x;
  tem2 = tem + x;
  tem = tem2 + x;
  tem2 = tem + x;
  return tem2;
}

Sounds like a beginners project - look at undistribute_ops_list and enhance
it to handle the case of implicit * 1 (and maybe multi-use mults on the way).


Then of course when in a loop we don't have final value replacement for
non-integer types as we use SCEV for that.  The SCCP pass needs to be
amended here - I believe there is a duplicate bugreport for this somewhere.


Note that it can't do this w/o -funsafe-math-optimizations as "more accurate"
is only true if you see it mathematically vs. the FP operations.  But GCC
has to adhere to IEEE FP rules here.  It should be guarded with
-ffp-contract=fast rather than -fassociative-math though.

[Bug c/68107] Non-VLA type whose size is half or more of the address space constructed via a pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
 Ever confirmed|0   |1

[Bug target/68109] GCC fails to vectorize popcount on x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
  Component|other   |target
 Blocks||53947
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
Confirmed.  The target would have to provide the neccessary target
builtin/expander.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug fortran/68108] [6 regression] erroneous error message 'scalar integer expression expected'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|[6.0 regression] erroneous  |[6 regression] erroneous
   |error message 'scalar   |error message 'scalar
   |integer expression  |integer expression
   |expected'   |expected'

[Bug target/68110] __builtin_sub_overflow unsigned performance issue

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
value-numbering would need to special-case them via the insertion trick it does
for conversions.  somehow.  not sure if feasible or worthwhile.

[Bug middle-end/66311] [5 Regression] Problems with some integer(16) values

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #22 from Christophe Lyon  ---
I see the testcase fail at execution time for arm* targets, and it passes in
aarch64* targets.

I'm using qemu in both cases, if that matters.

[Bug c/64880] OpenACC gcc/g++ Discrepancy

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Fixed in r229404.

[Bug c/64765] [OpenACC] Bogus "'copy' is not valid for '#pragma acc kernels loop'"

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Fixed in r229404.

[Bug c/64765] [OpenACC] Bogus "'copy' is not valid for '#pragma acc kernels loop'"

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Oct 27 08:39:15 2015
New Revision: 229404

URL: https://gcc.gnu.org/viewcvs?rev=229404&root=gcc&view=rev
Log:
[PR c/64765, c/64880] Support OpenACC Combined Directives in C, C++

gcc/c-family/
PR c/64765
PR c/64880
* c-common.h (c_oacc_split_loop_clauses): Declare function.
* c-omp.c (c_oacc_split_loop_clauses): New function.
gcc/c/
PR c/64765
PR c/64880
* c-parser.c (c_parser_oacc_loop): Add mask, cclauses formal
parameters, and handle these.  Adjust all users.
(c_parser_oacc_kernels, c_parser_oacc_parallel): Merge functions
into...
(c_parser_oacc_kernels_parallel): ... this new function.  Adjust
all users.
* c-tree.h (c_finish_oacc_parallel, c_finish_oacc_kernels): Don't
declare functions.
(c_finish_omp_construct): Declare function.
* c-typeck.c (c_finish_oacc_parallel, c_finish_oacc_kernels):
Merge functions into...
(c_finish_omp_construct): ... this new function.
gcc/cp/
PR c/64765
PR c/64880
* cp-tree.h (finish_oacc_kernels, finish_oacc_parallel): Don't
declare functions.
(finish_omp_construct): Declare function.
* parser.c (cp_parser_oacc_loop): Add p_name, mask, cclauses
formal parameters, and handle these.  Adjust all users.
(cp_parser_oacc_kernels, cp_parser_oacc_parallel): Merge functions
into...
(cp_parser_oacc_kernels_parallel): ... this new function.  Adjust
all users.
* semantics.c (finish_oacc_kernels, finish_oacc_parallel): Merge
functions into...
(finish_omp_construct): ... this new function.
gcc/
* tree.h (OACC_PARALLEL_BODY, OACC_PARALLEL_CLAUSES)
(OACC_KERNELS_BODY, OACC_KERNELS_CLAUSES, OACC_KERNELS_COMBINED)
(OACC_PARALLEL_COMBINED): Don't define macros.  Adjust all users.
gcc/testsuite/
PR c/64765
PR c/64880
* c-c++-common/goacc/loop-1.c: Don't skip for C++.  Don't prune
sorry message.
(PR64765): New function.
* gfortran.dg/goacc/coarray_2.f90: XFAIL.
* gfortran.dg/goacc/combined_loop.f90: Extend.  Don't prune
sorry message.
* gfortran.dg/goacc/cray.f95: Refine prune directive.
* gfortran.dg/goacc/parameter.f95: Likewise.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/combdir-1.c: New file.
* testsuite/libgomp.oacc-fortran/combdir-1.f90: Likewise.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/combdir-1.c
trunk/libgomp/testsuite/libgomp.oacc-fortran/combdir-1.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-omp.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/loop-1.c
trunk/gcc/testsuite/gfortran.dg/goacc/coarray_2.f90
trunk/gcc/testsuite/gfortran.dg/goacc/combined_loop.f90
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/parameter.f95
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree.def
trunk/gcc/tree.h
trunk/libgomp/ChangeLog

[Bug c/64880] OpenACC gcc/g++ Discrepancy

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Oct 27 08:39:15 2015
New Revision: 229404

URL: https://gcc.gnu.org/viewcvs?rev=229404&root=gcc&view=rev
Log:
[PR c/64765, c/64880] Support OpenACC Combined Directives in C, C++

gcc/c-family/
PR c/64765
PR c/64880
* c-common.h (c_oacc_split_loop_clauses): Declare function.
* c-omp.c (c_oacc_split_loop_clauses): New function.
gcc/c/
PR c/64765
PR c/64880
* c-parser.c (c_parser_oacc_loop): Add mask, cclauses formal
parameters, and handle these.  Adjust all users.
(c_parser_oacc_kernels, c_parser_oacc_parallel): Merge functions
into...
(c_parser_oacc_kernels_parallel): ... this new function.  Adjust
all users.
* c-tree.h (c_finish_oacc_parallel, c_finish_oacc_kernels): Don't
declare functions.
(c_finish_omp_construct): Declare function.
* c-typeck.c (c_finish_oacc_parallel, c_finish_oacc_kernels):
Merge functions into...
(c_finish_omp_construct): ... this new function.
gcc/cp/
PR c/64765
PR c/64880
* cp-tree.h (finish_oacc_kernels, finish_oacc_parallel): Don't
declare functions.
(finish_omp_construct): Declare function.
* parser.c (cp_parser_oacc_loop): Add p_name, mask, cclauses
formal parameters, and handle these.  Adjust all users.
(cp_parser_oacc_kernels, cp_parser_oacc_parallel): Merge functions
into...
(cp_parser_oacc_kernels_parallel): ... this new function.  Adjust
all users.
* semantics.c (finish_oacc_kernels, finish_oacc_parallel): Merge
functions into...
(finish_omp_construct): ... this new function.
gcc/
* tree.h (OACC_PARALLEL_BODY, OACC_PARALLEL_CLAUSES)
(OACC_KERNELS_BODY, OACC_KERNELS_CLAUSES, OACC_KERNELS_COMBINED)
(OACC_PARALLEL_COMBINED): Don't define macros.  Adjust all users.
gcc/testsuite/
PR c/64765
PR c/64880
* c-c++-common/goacc/loop-1.c: Don't skip for C++.  Don't prune
sorry message.
(PR64765): New function.
* gfortran.dg/goacc/coarray_2.f90: XFAIL.
* gfortran.dg/goacc/combined_loop.f90: Extend.  Don't prune
sorry message.
* gfortran.dg/goacc/cray.f95: Refine prune directive.
* gfortran.dg/goacc/parameter.f95: Likewise.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/combdir-1.c: New file.
* testsuite/libgomp.oacc-fortran/combdir-1.f90: Likewise.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/combdir-1.c
trunk/libgomp/testsuite/libgomp.oacc-fortran/combdir-1.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-omp.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/loop-1.c
trunk/gcc/testsuite/gfortran.dg/goacc/coarray_2.f90
trunk/gcc/testsuite/gfortran.dg/goacc/combined_loop.f90
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/parameter.f95
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree.def
trunk/gcc/tree.h
trunk/libgomp/ChangeLog