[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[hubicka at ucw dot cz]

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

--- Comment #30 from Jan Hubicka  ---
Sorry, with -mno-avx2 I was speaking of the other mt benchmark.  There is no
need for gathers
in matrix multiplication...

Honza

[Bug c/83198] [7/8 regression] ICE internal compiler error: in format_floating, at gimple-ssa-sprintf.c:1900

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.3

[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|FAIL: gdb.base/async.exp &  |[8 Regression] FAIL:
   |gdb.base/skip.exp   |gdb.base/async.exp &
   ||gdb.base/skip.exp

--- Comment #1 from Richard Biener  ---
Are we sure this is not gdbs fault?

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #2 from Andrew Roberts  ---
Correction:

1) This works on gcc 8 snapshot, it doesn't work on gcc-7.2.0

/usr/local/gcc-7.2.0/bin/gcc -march=native -mcpu=cortex-a53  -mfpu=auto -Ofast
-o matrix matrix.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU

2) The current message when you do not select a cpu explicitly, could do with
improving to prompt you to do so.

/usr/local/gcc/bin/gcc -march=native -mfpu=auto -o matrix matrix.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU

Should really prompt user to use -mcpu= to select a cpu

3) This is the gcc version it doesn't work against, I'll check latest gcc-7
snapshot to check if the gcc-8 fix has been backported.

 /usr/local/gcc-7.2.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-7.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-7.2.0/libexec/gcc/armv7l-unknown-linux-gnueabihf/7.2.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-7.2.0/configure --prefix=/usr/local/gcc-7.2.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu
--disable-libstdcxx-pch --enable-install-libiberty --disable-multilib
--disable-libssp --enable-default-pie --enable-default-ssp
--host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-linux-gnueabihf
--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --disable-bootstrap
Thread model: posix
gcc version 7.2.0 (GCC)

[Bug lto/83201] [7/8 Regression] SPEC CPU2017 505.mcf_f produces incorrect output when built with -flto and FDO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.3
Summary|SPEC CPU2017 505.mcf_f  |[7/8 Regression] SPEC
   |produces incorrect output   |CPU2017 505.mcf_f produces
   |when built with -flto and   |incorrect output when built
   |FDO |with -flto and FDO

--- Comment #3 from Richard Biener  ---
(In reply to Pat Haugen from comment #2)
> (In reply to Pat Haugen from comment #0)
> > 
> > It appears to work fine with r254943. I'll start a bisect and post results.
> 
> My bisect showed that r254946 was where it started failing on trunk. And
> yes, it fails with current GCC 7 branch too.

Probably a bogus bisect point, for a few revisions inlining was broken so it's
probably broken a bit earlier as well.

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

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 29 08:40:13 2017
New Revision: 255226

URL: https://gcc.gnu.org/viewcvs?rev=255226&root=gcc&view=rev
Log:
PR target/80819
* config/i386/sse.md (vec_concatv2di): Remove * from (=Yr,0,*rm)
alternative.

* gcc.target/i386/pr80819-1.c: New test.
* gcc.target/i386/pr80819-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr80819-1.c
trunk/gcc/testsuite/gcc.target/i386/pr80819-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 regression] Useless  |[6/7 regression] Useless
   |store to the stack  in  |store to the stack  in
   |_mm_set_epi64x with SSE4|_mm_set_epi64x with SSE4
   |-mno-avx|-mno-avx

--- Comment #12 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #31 from Andrew Roberts  ---
of for mt19937ar with -mno-avx2

/usr/local/gcc/bin/gcc -march=$amarch -mtune=$amtune -mno-avx2 -O3 -o mt199
37ar mt19937ar.c

Top 2:
mt19937ar took 358493 clocks -march=silvermont -mtune=bdver1
mt19937ar took 359933 clocks -march=corei7 -mtune=btver2

Top znver1:
mt19937ar took 363177 clocks -march=znver1 -mtune=k8-sse3
mt19937ar took 373751 clocks -march=slm -mtune=znver1
mt19937ar took 379094 clocks -march=znver1 -mtune=znver1

Worst cases:
mt19937ar took 683339 clocks -march=bdver3 -mtune=btver1
mt19937ar took 687566 clocks -march=btver2 -mtune=haswell
mt19937ar took 695629 clocks -march=athlon64-sse3 -mtune=sandybridge
mt19937ar took 697349 clocks -march=k8-sse3 -mtune=knl
mt19937ar took 697831 clocks -march=knl -mtune=core2
mt19937ar took 798283 clocks -march=opteron -mtune=athlon64-sse3

Running just for: -march=znver1 -mtune=znver1  -Ofast
mt19937ar took 445136 clocks
mt19937ar took 449784 clocks
mt19937ar took 460105 clocks

Running just for: -march=znver1 -mtune=znver1 -mno-avx2 -Ofast
mt19937ar took 416937 clocks
mt19937ar took 389458 clocks
mt19937ar took 389154 clocks

So -mno-avx2 gives 13-14% gain depending on how you look at it.

[Bug tree-optimization/83202] Try joining operations on consecutive array elements during tree vectorization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-29
 Blocks||53947
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
wiht += 4 the inner loop doesn't iterate so it's effectively

void test(double data[4][4])
{
  for (int i = 0; i < 4; i++)
  {
data[i][i] = data[i][i] * data[i][i];
data[i][i+1] = data[i][i+1] * data[i][i+1];
  }
}

we fail to SLP here because we get confused by the computed group size of 5
as there's a gap of three elements between the first stores of each iteration.

When later doing BB vectorization we fail to analyze dependences, likely
because
not analyzing refs as thoroughly as with loops.

For your second example we fail to loop vectorize this because we completely
peel the inner loop in cunrolli, leaving control flow inside the loop...
I have a patch for that one.


Referenced Bugs:

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

[Bug fortran/83209] New: Failure of allocation of a coarray with a pointer component

[pault at gcc dot gnu.org]

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

Bug ID: 83209
   Summary: Failure of allocation of a coarray with a pointer
component
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
CC: vehre at gmx dot de
  Target Milestone: ---

Created attachment 42740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42740&action=edit
tree dump of failing test

integer, target :: tgt = 45
  type :: t
integer, pointer :: i => tgt
  end type
  type(t), allocatable :: c(:)[:]

  allocate(c(10)[*])
  deallocate(c)
end

fails with:

[pault@pc30 pr83076]$ ~/irun/bin/gfortran -static-libgfortran test.f90 
-fdump-tree-original -O3 -fcoarray=lib -lcaf_single -g
[pault@pc30 pr83076]$ ./a.out
At line 8 of file test.f90
Fortran runtime error: Attempt to DEALLOCATE unallocated 'c'

Error termination. Backtrace:
#0  0x4029f4 in MAIN__
at /home/pault/prs/pr83076/test.f90:8
#1  0x4029f4 in main
at /home/pault/prs/pr83076/test.f90:9


The tree dump is attached.

The version with an allocatable component works as expected.

Paul

[Bug target/83210] New: __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[lh_mouse at 126 dot com]

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

Bug ID: 83210
   Summary: __builtin_mul_overflow() generates suboptimal code
when exactly one argument is the constant 2
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

This snippet illustrates the problem:



```
bool mul_and_check(unsigned *dst, unsigned src){
return __builtin_mul_overflow(src, 2, dst);
}
```

With `g++ -O3`, this compiles to:

```
mul_and_check(unsigned int*, unsigned int):
  mov eax, esi
  mov edx, 2
  xor ecx, ecx
  mul edx
  mov esi, eax
  jo .L5
.L2:
  mov eax, ecx
  mov DWORD PTR [rdi], esi
  and eax, 1
  ret
.L5:
  mov ecx, 1
  jmp .L2
```

This is very suboptimal. GCC could have used a bitwise shift operation instead,
as follows:

```
mul_and_check(unsigned int*, unsigned int):
  xor eax, eax # EAX  = 0
  shl esi, 1   # CF   = MSB(src)
   # src  = src * 2;
  rol eax, 1   # EAX  = CF
  mov dword ptr[rdi], esi  # *dst = src
  ret
```

[Bug driver/83207] On ARM -mcpu=native does not detect ARM big/little cpu combinations correctly (armv7l-unknown-linux-gnueabihf)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-29
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. The arm port doesn't know how to detect big.LITTLE combinations in
its native CPU detection logic

[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-29
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|Inefficient int to avx2 |[8 Regression] Inefficient
   |vector conversion   |int to avx2 vector
   ||conversion
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  On trunk we even genrate

foo:
.LFB5186:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
movq%rdi, -8(%rsp)
vmovq   -8(%rsp), %xmm1
vmovq   %xmm1, %xmm0
vmovdqa %xmm0, %xmm0
leave

huh...

We expand from

foo (long int x)
{
  __m256i _2;

   [100.00%]:
  _2 = {x_1(D)};
  return _2;

that's a regression on trunk (gcc7 code confirmed).  Probably caused by
the vec_init expansion reorg?

[Bug c++/83204] [6/7/8 Regression] c++ -std=c++14 ICE in maybe_undo_parenthesized_ref, at cp/semantics.c:1694

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug target/83208] [arm-linux-gnueabi-gcc] wrong code at optimization level -O2 and -O3 for union assignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm-linux-gnueabi-gcc

--- Comment #1 from Richard Biener  ---
GCC 5 is no longer maintained, can you try GCC 6 or newer?

[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from Thomas Preud'homme  ---
(In reply to Richard Biener from comment #1)
> Are we sure this is not gdbs fault?

GDB version was fixed when I did my bisect. That said, I don't know what sort
of change happened in DWARF so it may well be that the new DWARF is correct but
GDB just cannot deal with it.

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[lh_mouse at 126 dot com]

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

--- Comment #1 from Liu Hao  ---
FWIW, it can still be improved when the constant is something other than 2.

For example:

```
bool mul_8_and_check(unsigned *dst, unsigned src){
return __builtin_mul_overflow(src, 8, dst);
}
```

can be rewritten as:

bool mul_8_and_check(unsigned *dst, unsigned src){
unsigned res = src << 3;
*dst = res;
return (res >> 3) != src; // The result will have been truncated if
  // dividing the result by 8 does not yield
  // the original value.
}
```

[Bug target/83208] [arm-linux-gnueabi-gcc] wrong code at optimization level -O2 and -O3 for union assignment

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
The union here does not matter.

You are violating C aliasing rules.

You store via a long and then load via an int.  And not through an union.

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(res >> 3) != src;

Why not just (src>>(sizeof (res)*8-3))!=0.

Seems shorter and might be faster.

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> (res >> 3) != src;
> 
> Why not just (src>>(sizeof (res)*8-3))!=0.
> 
> Seems shorter and might be faster.

And for the original case
Src>>31!=0 Just becomes src>>31. :)

[Bug target/83208] [arm-linux-gnueabi-gcc] wrong code at optimization level -O2 and -O3 for union assignment

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
The testcase is "fixed" by using -fno-strict-aliasing.
In this example pointers c and d alias each other, they are of incompatible
types and they are both dereferenced, so the testcase has undefined behaviour.

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[lh_mouse at 126 dot com]

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

--- Comment #4 from Liu Hao  ---
(In reply to Andrew Pinski from comment #2)
> (res >> 3) != src;
> 
> Why not just (src>>(sizeof (res)*8-3))!=0.
> 
> Seems shorter and might be faster.

What if the second operand is not a power of 2? `(res * 5 / 5 != src)` will
always work, but bitwise shifting might not.

[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

 CC||jan.kratochvil at redhat dot 
com

--- Comment #3 from Jan Kratochvil  ---
Addresses are missing when the function is inlined.
But these testfiles do not use -O optimization so I find wrong if GCC has
inlined anything.
Sorry I have not built trunk GCC (moreover on arm) to check it, maybe submitter
can attach the binary files here?

[Bug c++/83211] New: Warning: ignoring incorrect section type for .init_array.00200

[rdiezmail-gcc at yahoo dot de]

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

Bug ID: 83211
   Summary: Warning: ignoring incorrect section type for
.init_array.00200
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rdiezmail-gcc at yahoo dot de
  Target Milestone: ---

I recently upgraded my embedded ARM Cortex-M4 toolchain from GCC 6.3 to GCC
6.4, and Binutils from 2.28 to 2.29.1 (among other minor component upgrades).

My C++ code is using the following for a static routine:

  __attribute__ ((constructor (200)))

After the upgrade I am getting this warning now:

  /tmp/cc79zoMV.s: Assembler messages:
  /tmp/cc79zoMV.s:5079: Warning: ignoring incorrect section type for
.init_array.00200
  /tmp/cc79zoMV.s:5112: Warning: ignoring incorrect section type for
.fini_array.00200


Normally, GCC emits this kind of section statements during compilation:

.section.init_array,"aw",%init_array

But for the "__attribute__ ((constructor (200)))" code, it emits this instead:

.section.init_array.00200,"aw",%progbits

Binutils saw this change recently:

https://sourceware.org/bugzilla/show_bug.cgi?id=21287

So I am guessing that is what is causing the new warning.

I suppose that GCC needs an update to match that Binutils change.

[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
The only change has been that with -gcolumn-info which is now the default GCC
emits extra attributes: DW_AT_decl_column and DW_AT_call_column, and emits .loc
with column numbers rather than always hardcoded 0.

[Bug c/83213] New: peephole bug with -O2

[dcb314 at hotmail dot com]

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

Bug ID: 83213
   Summary: peephole bug with -O2
   Product: gcc
   Version: 8.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 42741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42741&action=edit
gzipped C source code

The attached C code, when compiled by recent gcc trunk and flag -O2,
does this:

zend_vm_execute.h:63744:1: error: No region crossing jump at section boundary
in bb 2545
 }

It compiled fine without the -O2 flag.

I'll have a go at finding a range of gcc revisions where
the problem seems to occur and I'll have a go at reducing the code.

I make this the 400th bug I've reported since Oct 2010.

[Bug fortran/83209] [7/8 Regression] Failure of allocation of a coarray with a pointer component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-29
  Known to work||6.4.0
   Target Milestone|--- |7.3
Summary|Failure of allocation of a  |[7/8 Regression] Failure of
   |coarray with a pointer  |allocation of a coarray
   |component   |with a pointer component
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Could be caused by r244196 (pr78781).

[Bug middle-end/80929] [6/7/8 Regression] Division with constant no more optimized to mult highpart

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 29 10:31:36 2017
New Revision: 255228

URL: https://gcc.gnu.org/viewcvs?rev=255228&root=gcc&view=rev
Log:
PR middle-end/80929
* rtlanal.c (seq_cost): For non-single_set insns try to use insn_cost.

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

[Bug middle-end/83185] [8 Regression] ICE with -fsanitize=address in build_simple_mem_ref_loc, at tree.c:4696

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 29 10:33:06 2017
New Revision: 255229

URL: https://gcc.gnu.org/viewcvs?rev=255229&root=gcc&view=rev
Log:
PR middle-end/83185
* tree.c (build_simple_mem_ref_loc): Handle
get_addr_base_and_unit_offset returning a MEM_REF.

* gcc.dg/asan/pr83185.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/asan/pr83185.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c/83213] peephole bug with -O2

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Bug seems to occur between revisions 253840 and 253974.

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
(In reply to Liu Hao from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > (res >> 3) != src;
> > 
> > Why not just (src>>(sizeof (res)*8-3))!=0.
> > 
> > Seems shorter and might be faster.
> 
> What if the second operand is not a power of 2? `(res * 5 / 5 != src)` will
> always work, but bitwise shifting might not.

Division is something we need to avoid.  If any of the * 5 or / 5 ends up being
actual multiplication, it doesn't make sense either.  And otherwise it will
just be very long.  So the only thing that IMHO makes sense is unsigned
overflow multiply with constant power of two.  I can handle that.  No plans to
do anything else.

[Bug middle-end/83185] [8 Regression] ICE with -fsanitize=address in build_simple_mem_ref_loc, at tree.c:4696

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/80929] [6/7/8 Regression] Division with constant no more optimized to mult highpart

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #11 from Jakub Jelinek  ---
On the trunk the backend can deal with this using a hook.  So it is a target
issue if anything else needs solving.

[Bug gcov-profile/83214] New: [8 regression] FAIL: g++.dg/gcov/gcov-8.C -std=gnu++11 gcov failed

[sudi.das at arm dot com]

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

Bug ID: 83214
   Summary: [8 regression] FAIL: g++.dg/gcov/gcov-8.C
-std=gnu++11  gcov failed
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi.das at arm dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

On arm-none-linux-gnueabihf:

FAIL: g++.dg/gcov/gcov-8.C  -std=gnu++11  gcov failed
FAIL: g++.dg/gcov/gcov-8.C  -std=gnu++14  gcov failed
FAIL: g++.dg/gcov/gcov-8.C  -std=gnu++98  gcov failed

Failing at least from r255140

[Bug middle-end/83185] [8 Regression] ICE with -fsanitize=address in build_simple_mem_ref_loc, at tree.c:4696

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Started with r250031 btw.

[Bug tree-optimization/83202] Try joining operations on consecutive array elements during tree vectorization

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
For the other case the issue is I think that the SLP instance group size is not
the number of scalar stmts but somehow set to the group-size.  Changing that
has quite some ripple-down effects though.

-> GCC 9.

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #3 from Andrew Roberts  ---
ok confirmed, this bug is still present on the gcc-7 branch, with the current
snapshot:

/usr/local/gcc-7.2.1/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-7.2.1/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-7.2.1/bin/../libexec/gcc/armv7l-unknown-linux-gnueabihf/7.2.1/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-7.3.0/configure --prefix=/usr/local/gcc-7.3.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu
--disable-libstdcxx-pch --enable-install-libiberty --disable-multilib
--disable-libssp --enable-default-pie --enable-default-ssp
--host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-linux-gnueabihf
--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --disable-bootstrap
Thread model: posix
gcc version 7.2.1 20171123 (GCC)

/usr/local/gcc-7.2.1/bin/gcc -march=native -mcpu=cortex-a53  -mfpu=auto -Ofast
-o matrix matrix.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU

Also the gcc man pages for 7.2.1 lack documentation for the -mfpu=auto option,
although it is accepted as an argument (gcc 8 does document it)

On 7.2.1 man page: 
  -mfpu=name
   This specifies what floating-point hardware (or hardware emulation)
   is available on the target.  Permissible names are: vfpv2, vfpv3,
   vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16,
   neon-vfpv3, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4,
   fpv5-d16, fpv5-sp-d16, fp-armv8, neon-fp-armv8 and
   crypto-neon-fp-armv8.  Note that neon is an alias for neon-vfpv3
   and vfp is an alias for vfpv2.

On 8.0.0 man page:
   -mfpu=name
   This specifies what floating-point hardware (or hardware emulation)
   is available on the target.  Permissible names are: auto, vfpv2,
   vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd,
   vfpv3xd-fp16, neon-vfpv3, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16,
   neon-vfpv4, fpv5-d16, fpv5-sp-d16, fp-armv8, neon-fp-armv8 and
   crypto-neon-fp-armv8.  Note that neon is an alias for neon-vfpv3
   and vfp is an alias for vfpv2.

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|8.0 |7.2.1
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #4 from Richard Earnshaw  ---
Implementation of -mfpu=auto wasn't complete in GCC-7, which is why it isn't in
the main documentation.  Some of the implementation was there though, which is
why it leaks into the --help information.

As you've noted it's fixed in gcc-8.

It's unlikely that this will be fixed on the release branch.

[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
Created attachment 42742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42742&action=edit
Executable async and skip produced by GCC trunk

[Bug gcov-profile/83214] [8 regression] FAIL: g++.dg/gcov/gcov-8.C -std=gnu++11 gcov failed

[sudi.das at arm dot com]

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

--- Comment #1 from Sudakshina Das  ---
Sorry I am bit confused with this. Not failing anymore on my bootstrapped build
from trunk this morning!

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[lh_mouse at 126 dot com]

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

--- Comment #8 from Liu Hao  ---
I cannot reproduce this problem on either i686-w64-mingw32 or
x86_64-w64-mingw32 with --enable-tls.


On line 677 in libgomp.h there is a call to `gomp_thread()` which is supposed
to return a pointer to a __thread object. However, from your first post, it is
weird that for i686 GCC generates code referring the GS segment register, since
GS is unused by x86 Windows.

On x86 Windows, TLS is indirected from the FS register. It is Microsoft's
rocket science, hence GCC still relies on the emutls solution. The GS register
is known to be utilized by x64 Windows and Linux AFAICT.

I presume that your GCC generated Linux code for Windows targets. If you are
cross-compiling for example it may becaused by GCC scripts mistaking the host
for the build. This still requires investigation.

Reference: 

[Bug c++/83205] ICE on structured binding with ill-formed negative std::tuple_size::value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-29
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

[Bug c++/83187] [8 regression] internal compiler error: in get_alias_set, at alias.c:923

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov 29 13:22:44 2017
New Revision: 255231

URL: https://gcc.gnu.org/viewcvs?rev=255231&root=gcc&view=rev
Log:
[PATCH] complex type canonicalization


https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02453.html
PR c++/83817
* tree.c (build_complex_type): Fix canonicalization.  Only fill in
type if it is new.

PR c++/83187
* g++.dg/opt/pr83187.C: New.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr83187.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/83187] [8 regression] internal compiler error: in get_alias_set, at alias.c:923

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
fixed r255231.

[Bug gcov-profile/83214] [8 regression] FAIL: g++.dg/gcov/gcov-8.C -std=gnu++11 gcov failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Thus fixed/worksforme.

[Bug rtl-optimization/83213] [8 Regression] peephole bug with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-*-*, i?86-*-*
  Component|c   |rtl-optimization
   Target Milestone|--- |8.0
Summary|peephole bug with -O2   |[8 Regression] peephole bug
   ||with -O2

[Bug middle-end/83215] New: C++: struct with char-array assumed to alias with everything

[dominik.infuehr at gmail dot com]

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

Bug ID: 83215
   Summary: C++: struct with char-array assumed to alias with
everything
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominik.infuehr at gmail dot com
  Target Milestone: ---

TBAA seems to be more conservative for C++ in the following example since GCC
7:

struct mytest {
  float a;
#ifdef WITH_BUFFER
  char buf[256];
#endif
};

int foo(mytest *m, int *i) {
  int tmp = *i; // first load
  m->a = 10.0f;
  return tmp + *i; // second load since GCC 7
}

Since GCC 7 this code generates two loads with -DWITH_BUFFER, without buf in
the struct there is just one load. buf isn't touched at all in this function.
This only affects C++-code, not the C-frontend.

TYPE_TYPLESS_STORAGE is set for this struct, aggregates with this flag set are
assumed to alias with everything in gcc/alias.c(get_alias_set).

Seems to be introduced with revision 246866
(https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=246866).

[Bug tree-optimization/83202] Try joining operations on consecutive array elements during tree vectorization

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

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

--- Comment #4 from Daniel Fruzynski  ---
One more case. Code has to process diagonal half of matrix and uses SSE
intrinsics - see test1() below. When n is constant like in test2() below, gcc
unrolls loops. However more more transform could be performed, replace pairs of
SSE instructions with one AVX one.

#include 
#include "immintrin.h"

void test1(double data[100][100], unsigned int n)
{
for (int i = 0; i < n; i++)
{
for (int j = 0; j < i; j += 2)
{
__m128d v = _mm_loadu_pd(&data[i][j]);
v = _mm_mul_pd(v, v);
_mm_storeu_pd(&data[i][j], v);
}
}
}

void test2(double data[100][100])
{
const unsigned int n = 6;
for (int i = 0; i < n; i++)
{
for (int j = 0; j < i; j += 2)
{
__m128d v = _mm_loadu_pd(&data[i][j]);
v = _mm_mul_pd(v, v);
_mm_storeu_pd(&data[i][j], v);
}
}
}

[Bug c++/83205] ICE on structured binding with ill-formed negative std::tuple_size::value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug fortran/82605] [PDT] ICE in insert_parameter_exprs, at fortran/decl.c:3154

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
Created attachment 42743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42743&action=edit
A fix for the problem

With the attached patch, now produces the error:

[pault@pc30 pr82605]$ ~/irun/bin/gfortran -static-libgfortran pr*.f90 
-fdump-tree-original
pr82065.f90:7:21:

type(t(8, :)) :: x
 1
Error: The object ‘x’ at (1) has a deferred LEN parameter ‘b’ and is neither
allocatable nor a pointer

Giving x either attribute allows compilation and correct execution. (I assume
that x%a, being a KIND parameter, is OK in a KIND specification?

With the tweak to pdt_4.f03, it bootstraps and regtests OK.

Paul

[Bug middle-end/83215] C++: struct with char-array assumed to alias with everything

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
What I've wondered here is because we know the offset and size of the m->a
access, even when the containing structure is TYPE_TYPELESS_STORAGE, we could
prove that this offset/size in the structure doesn't and can't overlap with any
area of the aggregate that has or could have TYPE_TYPELESS_STORAGE array, and
ignore the TYPE_TYPELESS_STORAGE for that access.

[Bug c++/83205] ICE on structured binding with ill-formed negative std::tuple_size::value

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 42744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42744&action=edit
gcc8-pr83205.patch

Untested fix.

[Bug tree-optimization/83202] Try joining operations on consecutive array elements during tree vectorization

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 29 14:38:06 2017
New Revision: 255233

URL: https://gcc.gnu.org/viewcvs?rev=255233&root=gcc&view=rev
Log:
2017-11-29  Richard Biener  

PR tree-optimization/83202
* tree-vect-slp.c (scalar_stmts_set_t): New typedef.
(bst_fail): Use it.
(vect_analyze_slp_cost_1): Add visited set, do not account SLP
nodes vectorized to the same stmts multiple times.
(vect_analyze_slp_cost): Allocate a visited set and pass it down.
(vect_analyze_slp_instance): Adjust.
(scalar_stmts_to_slp_tree_map_t): New typedef.
(vect_schedule_slp_instance): Add a map recording the SLP node
representing the vectorized stmts for a set of scalar stmts.
Avoid code-generating redundancies.
(vect_schedule_slp): Allocate map and pass it down.

* gcc.dg/vect/costmodel/x86_64/costmodel-pr83202.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr83202.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/83202] Try joining operations on consecutive array elements during tree vectorization

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
There are multiple issues reflected in this bug.  The last commit addressed the
SLP cost model thing (not fixing any testcase on its own).

[Bug tree-optimization/83202] Try joining operations on consecutive array elements during tree vectorization

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 29 Nov 2017, bugzi...@poradnik-webmastera.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83202
> 
> --- Comment #4 from Daniel Fruzynski  ---
> One more case. Code has to process diagonal half of matrix and uses SSE
> intrinsics - see test1() below. When n is constant like in test2() below, gcc
> unrolls loops. However more more transform could be performed, replace pairs 
> of
> SSE instructions with one AVX one.

GCC currently does not "vectorize" already vectorized code so
this is a much farther away "goal" apart from eventually pattern-matching
some very simple cases.

[Bug rtl-optimization/83213] [8 Regression] peephole bug with -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That is weird, because already e.g. r25 ICEs with:
internal compiler error: in to_reg_br_prob_base, at profile-count.h:189
and so does r253842.
It is true that r253974 ICEs differently, as you wrote.

[Bug tree-optimization/83216] New: [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[thopre01 at gcc dot gnu.org]

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

Bug ID: 83216
   Summary: [8 regression] FAIL: gcc.dg/graphite/interchange-3.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

The following tests started to fail on arm-none-eabi targets after commit
r253809:

PASS->FAIL: gcc.dg/graphite/interchange-3.c scan-tree-dump graphite "tiled"
PASS->FAIL: gcc.dg/graphite/interchange-7.c scan-tree-dump graphite "tiled"
PASS->FAIL: gcc.dg/graphite/interchange-9.c scan-tree-dump graphite "tiled"
PASS->FAIL: gcc.dg/graphite/uns-interchange-9.c scan-tree-dump graphite "tiled"

GCC was configured with:

--target=arm-none-eabi --with-newlib --with-mode=thumb --with-cpu=cortex-m3

Failure can be observed when targeting Arm Cortex-M0, Cortex-M3, Cortex-M4 and
Cortex-M7 at least.

Best regards.

[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So for VARYING | 1 we go using the may_be_nonzero stuff in



  else if (code == BIT_IOR_EXPR)
{
  max = wide_int_to_tree (expr_type,
  may_be_nonzero0 | may_be_nonzero1);
  wide_int wmin = must_be_nonzero0 | must_be_nonzero1;
  /* If the input ranges contain only positive values we can
 truncate the minimum of the result range to the maximum
 of the input range minima.  */
  if (int_cst_range0 && int_cst_range1
  && tree_int_cst_sgn (vr0.min) >= 0
  && tree_int_cst_sgn (vr1.min) >= 0)
{
  wmin = wi::max (wmin, wi::to_wide (vr0.min),
  TYPE_SIGN (expr_type));
  wmin = wi::max (wmin, wi::to_wide (vr1.min),
  TYPE_SIGN (expr_type));
}
  /* If either input range contains only negative values
 we can truncate the minimum of the result range to the
 respective minimum range.  */
  if (int_cst_range0 && tree_int_cst_sgn (vr0.max) < 0)
wmin = wi::max (wmin, wi::to_wide (vr0.min),
TYPE_SIGN (expr_type));
  if (int_cst_range1 && tree_int_cst_sgn (vr1.max) < 0)
wmin = wi::max (wmin, wi::to_wide (vr1.min),
TYPE_SIGN (expr_type));
  min = wide_int_to_tree (expr_type, wmin);

but for [MIN, MAX] we go

  /* For op & or | attempt to optimize:
 [x, y] op z into [x op z, y op z]
 if z is a constant which (for op | its bitwise not) has n
 consecutive least significant bits cleared followed by m 1
 consecutive bits set immediately above it and either
 m + n == precision, or (x >> (m + n)) == (y >> (m + n)).
 The least significant n bits of all the values in the range are
 cleared or set, the m bits above it are preserved and any bits
 above these are required to be the same for all values in the
 range.  */
  if (vr0p && range_int_cst_p (vr0p))
{
  wide_int w = wi::to_wide (vr1p->min);
  int m = 0, n = 0;
  if (code == BIT_IOR_EXPR)
w = ~w;
  if (wi::eq_p (w, 0))
 ...

and both cases produce a different outcome (as we see).

I don't see how we can do better.  Well, we can choose to handle
| CST with least significant bit set as ~[0, 0] consistently. Or
we can add a predicate effectively_varying_p () and guard the 2nd case
above with it.

The "proper" result for [MIN,MAX] | 1 is of course a set of every odd number...

[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers

[mgulick at mathworks dot com]

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

--- Comment #2 from Mike Gulick  ---
I have made some progress in determining the cause of this bug.  This issue
occurs when the current source_location is > LINE_MAP_MAX_LOCATION_WITH_COLS
and when a #include is the last line in the file (with a terminating newline).

The corruption occurs when _cpp_stack_include decrements
ptable->line_table->highest_location.  It does this so that highest_location
refers to the *current* line in the file, not the next line.  For the case
where a #include is *not* the last line in the file, this works correctly. 
However when the the source location is > LINE_MAP_MAX_LOCATION_WITH_COLS and
the current #include line being processed is the last line in the file, the
highest_location value already refers to the current line in the file, as there
is no next line.  Thus this decrement sets highest_location to the previous
line in the file, which causes the corruption.

Consider an include file with two #includes:

  #include "foo.h"
  #include "bar.h"
  EOF

Consider when do_include_common() processes the final '#include "bar.h"'.  This
initially calls parse_include().  This calls check_eol(), which eventually
calls _cpp_lex_direct() via the following call stack:

  0 _cpp_lex_direct
  1 _cpp_lex_token
  2 cpp_get_token_1
  3 cpp_get_token
  4 check_eol_1
  5 check_eol
  6 parse_include
  7 do_include_common
  8 do_include
  9 _cpp_handle_directive
  10 _cpp_lex_token
  11 cpp_get_token_1
  12 cpp_get_token_with_location
  13 scan_translation_unit
  14 preprocess_file

_cpp_lex_direct parses the current buffer one character at a time.  In the case
of the line "#include bar.h", the buffer looks like:

  #include "bar.h"\n\n

Note that the second '\n' is added to the buffer when the file is initially
read in.  It doesn't exist in the file.

After parsing the '#include "bar.h", the buffer is sitting at the first '\n'.

  #include "bar.h"\n\n
   ^ ^
  buffer.cur---/ |
 |
  buffer.rlimit--/ 

buffer.rlimit is a pointer to the end of the buffer.  It points to the final
newline that was added to the end of the buffer when the file was read.

_cpp_lex_direct() reads the buffer one character at a time, e.g.

  c = *buffer->cur++
  ...
  switch (c)
{
...
case '\n':
  if (buffer->cur < buffer->rlimit)
CPP_INCREMENT_LINE (pfile, 0)
  buffer->need_line = true;
  goto fresh_line;
...

Under normal circumstances (i.e. if the #include is *not* the last line in the
file), when the '\n' is detected, CPP_INCREMENT_LINE increments the
line_maps->highest_line.  However for this last #include, buffer->cur ==
buffer->rlimit, so CPP_INCREMENT_LINE is not called.

Thus if the #include token has source_location 1610612807, highest_location in
the line_maps structure also has 1610612807.  Remember that we are past
LINE_MAP_MAX_LOCATION_WITH_COLS, so column numbers are not tracked, thus each
increment of a source_location value refers to a new line number and
potentially a new source file.

Continue stepping through do_include_common to _cpp_stack_include.  This
function has the following comment:

  /* Compensate for the increment in linemap_add that occurs if
  _cpp_stack_file actually stacks the file.  In the case of a
 normal #include, we're currently at the start of the line
 *following* the #include.  A separate source_location for this
 location makes no sense (until we do the LC_LEAVE), and
 complicates LAST_SOURCE_LINE_LOCATION.  This does not apply if we
 found a PCH file (in which case linemap_add is not called) or we
 were included from the command-line.  */

Under normal circumstances, the comment stating "we're currently at the start
of the line *following* the include is correct.  However in this case, this is
not true because we did not increment highest_line, thus highest_location still
refers to the current line.  Thus when we decrement highest_line, this makes
highest_line actually refer to the *previous* line map location, not the
current.  _cpp_stack_file then ultimately calls linemap_add, which sets
start_location to highest_location + 1.  This is assumed to be a new, unused
location, but in this case it actually already refers to an existing line map. 
Note that the linemap_assert in linemap_add will not catch this even if linemap
assertions are enabled.  This is because it only asserts if the new
start_location is less than the source_location of last line in the line map,
however in this case it is equal to the source_location of the last line.

We fix this by no longer decrementing pfile->line_table->highest_location if it
is less than or equal to the source_location of the current include header. 
The purpose of this decrement is to ensure that
pfile->line_table->highest_location still refers to the current line, so if it
already refers to the current line, there is no need to decrement it (and doing
so would be wrong).

[Bug middle-end/83215] C++: struct with char-array assumed to alias with everything

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
The key here is that "mytest" has alias-set zero.  It has that because
aggregate copying of it has to transfer whatever is in 'buf'.  But if "mytest"
has alias-set zero that means any component of it has that as well.

So this correctness fix is really tied to how we need to handle aggregate
copying
of structs.

I don't like that (and I simply blame the C++ standards commitee).  It's a
really bad choice for optimization.

Note making the C++ FE do sth "special" for aggregate copying works only
sofar as the middle-end also sometimes generates such copying (argument
copying during inlining, etc).

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
Note the testcases are not really testing anything (just the dump scanning...).

Well - let me have a very quick look.

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-29
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Can't reproduce 

What ISL version are you using?

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
(In reply to Richard Biener from comment #2)
> Can't reproduce 
> 
> What ISL version are you using?

ISL 0.15.

Also my apologies but I haven't tried on Arm Cortex-M7 yet actually, typed it
in as a force of habit.

Best regards.

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
For x86_64-pc-linux-gnu I see

FAIL: gcc.dg/stack-layout-dynamic-1.c scan-assembler-not cfi_def_cfa_register
FAIL: gcc.dg/graphite/interchange-3.c scan-tree-dump graphite "tiled"
FAIL: gcc.dg/graphite/interchange-7.c scan-tree-dump graphite "tiled"
FAIL: gcc.dg/graphite/interchange-9.c scan-tree-dump graphite "tiled"
FAIL: gcc.dg/graphite/uns-interchange-9.c scan-tree-dump graphite "tiled"

at https://gcc.gnu.org/ml/gcc-testresults/2017-11/msg02353.html.

[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Richard Biener from comment #2)
> The "proper" result for [MIN,MAX] | 1 is of course a set of every odd
> number...

Sadly, while we track may-be-nonzero bits in CCP (maybe with the VRP reorg
there will be a chance to merge it somehow?), we do not track must-be-nonzero
bits.

Note that the original testcase is completely artificial. I needed something
known to be nonzero, and at the time x|1 worked so I used that, but it should
not be used as if it was an important real-world code that heuristics need to
be tuned for.

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On November 29, 2017 4:35:12 PM GMT+01:00, "thopre01 at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83216
>
>--- Comment #3 from Thomas Preud'homme 
>---
>(In reply to Richard Biener from comment #2)
>> Can't reproduce 
>> 
>> What ISL version are you using?
>
>ISL 0.15.

That's outdated. Can you try 0.18?

Richard. 

>Also my apologies but I haven't tried on Arm Cortex-M7 yet actually,
>typed it
>in as a force of habit.
>
>Best regards.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

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

--- Comment #9 from Daniel Starke  ---
This was a native build.
I have added the GCC build in question to
https://sourceforge.net/projects/gcc-win64/files/7.1.0/gcc-7.1.0-debug-broken-tls.7z

[Bug testsuite/83131] c-c++/common/attr-nonstring-3 failure for strcmp tests on PowerPC

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
The new test case was added in r255031.

Here are the warnings it is complaining about:

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -Wc++-compat -O2
-Wattributes -Wstringop-overflow -ftrack-macro-expansion=0 -S -o
attr-nonstring-3.s
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c: In
function 'test_printf':
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:71:3:
warning: 'printf' argument 1 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:51:6:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:74:3:
warning: 'printf' argument 1 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:54:7:
note: argument 'parr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:77:3:
warning: 'printf' argument 1 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:59:8:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c: In
function 'test_puts':
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:84:3:
warning: 'puts' argument 1 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:51:6:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:87:3:
warning: 'puts' argument 1 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:54:7:
note: argument 'parr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:90:3:
warning: 'puts' argument 1 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:59:8:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c: In
function 'test_snprintf':
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:97:3:
warning: 'snprintf' argument 3 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:51:6:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:100:3:
warning: 'snprintf' argument 3 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:54:7:
note: argument 'parr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:103:3:
warning: 'snprintf' argument 3 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:59:8:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c: In
function 'test_sprintf':
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:110:3:
warning: 'sprintf' argument 2 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:51:6:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:113:3:
warning: 'sprintf' argument 2 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:54:7:
note: argument 'parr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:116:3:
warning: 'sprintf' argument 2 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:59:8:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c: In
function 'test_vsnprintf':
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:123:3:
warning: 'vsnprintf' argument 3 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:51:6:
note: argument 'arr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:126:3:
warning: 'vsnprintf' argument 3 declared attribute 'nonstring'
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:54:7:
note: argument 'parr' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/attr-nonstring-3.c:129:3:
warning: 'vsnprintf' argument 3 declared

[Bug c++/82760] Incorrect code generated for aligned new

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #32 from Andrew Roberts  ---
For what its worth, here's what the latest and greatest from the competition
has to offer:

/usr/local/llvm-5.0.1-rc2/bin/clang -march=znver1 -mtune=znver1 -O3 matrix.c -o
matrix
mult took 887141 clocks

/usr/local/llvm-5.0.1-rc2/biznver1 -O3 mt19937ar.c -o mt19937ar
mt19937ar took 402282 clocks

/usr/local/llvm-5.0.1-rc2/bin/clang -march=znver1 -mtune=znver1 -Ofast matrix.c
-o matrix
mult took 760913 clocks

/usr/local/llvm-5.0.1-rc2/bin/clang -march=znver1 -mtune=znver1 -Ofast
mt19937ar.c -o mt19937ar
mt19937ar took 392527 clocks


current gcc-8 snapshot:
/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1  -Ofast matrix.c -o matrix
mult took 364775 clocks

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1  -Ofast -o mt19937ar
mt19937ar.c
mt19937ar took 430804 clocks

current gcc-8 snapshot + extra opts to improve znver1 performance
/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-mno-fma -Ofast matrix.c -o matrix
mult took 130329 clocks

/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mno-avx2 -Ofast -o
mt19937ar mt19937ar.c
mt19937ar took 387728 clocks

So gcc loses on mt19937ar.c without -mno-avx2
But gcc wins big on matrix.c, especially with -mprefer-vector-width=none
-mno-fma

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-29
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Jakub Jelinek  ---
Created attachment 42745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42745&action=edit
gcc8-pr83210.patch

Untested patch.

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #33 from Andrew Roberts  ---
That second llvm command line should read:

/usr/local/llvm-5.0.1-rc2/bin/clang -march=znver1 -mtune=znver1 -Ofast
mt19937ar.c -o mt19937ar

[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp

[jan.kratochvil at redhat dot com]

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

--- Comment #6 from Jan Kratochvil  ---
The Comment 5 binaries SEGV and do not start on Fedora 26 armv7l.
But I do not see some wrong DWARF there.

(In reply to Jan Kratochvil from comment #3)
> Addresses are missing when the function is inlined.
> But these testfiles do not use -O optimization so I find wrong if GCC has
> inlined anything.

I was sure wrong here, in this case the address is not displayed when it
matches the first instruction of a source line.

It could be rather bugreported to GDB how to make it reproducible (I haven't
built GCC trunk on that Fedora 26 armv7l, though).

[Bug c++/83217] New: Compiler segfault: structured binding by reference to a templated type via a pointer

[emadwilliam92 at gmail dot com]

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

Bug ID: 83217
   Summary: Compiler segfault: structured binding by reference to
a templated type via a pointer
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emadwilliam92 at gmail dot com
  Target Milestone: ---

The following code produces a compiler segmentation fault. 

```
template 
struct Object
{
T a;
};

int main()
{
Object *it;
auto & [k] = *it;
}
```

I'm getting the same error with g++ 7.1 and 7.2, with --std=c++1z on x86. 

Here's the compiler error:

```
: In function 'int main()':
10 : :10:19: internal compiler error: Segmentation fault
 auto & [k] = *it;
   ^~
mmap: Cannot allocate memory
```

[Bug fortran/82606] [PDT] ICE in gfc_extract_int, at fortran/expr.c:641

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Created attachment 42746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42746&action=edit
A fix for the problem

The component initializers were being supplied to the derived type components
in the order of the type_spec_list. Thus, a got a null expression, while b got
the expression for '8'.

Bootstraps and regtests.

Paul

[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 29 17:38:54 2017
New Revision: 255247

URL: https://gcc.gnu.org/viewcvs?rev=255247&root=gcc&view=rev
Log:
PR tree-optimization/83195
* gcc.dg/pr82929.c: Don't check for "Merging successful" on arm.
* gcc.dg/pr82929-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr82929-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr82929.c

[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug testsuite/83131] c-c++/common/attr-nonstring-3 failure for strcmp tests on PowerPC

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Confirmed with the following test case.

  extern char arr[] __attribute__ ((nonstring));
  extern char str[];

  int f (void)
  {
return __builtin_strcmp (arr, str);
  }

The expected output is:

  $ gcc -O2 -S -Wall -Wextra -Wpedantic a.c
  a.c: In function ‘f’:
  a.c:6:10: warning: ‘__builtin_strcmp’ argument 1 declared attribute
‘nonstring’ [-Wstringop-overflow=]
 return __builtin_strcmp (arr, str);
^~~
  a.c:1:13: note: argument ‘arr’ declared here
   extern char arr[] __attribute__ ((nonstring));
   ^~~

With a powerpc64le-linux GCC, there is no warning.

The strcmp call is expanded in builtins.c and never reaches expand_call in
calls.c where the checking is done.  Something similar can happen for strlen on
x86_64 and there it's being handled by also checking in builtins.c (in
expand_builtin_strlen).  So strcmp and other string functions will need the
same treatment.

[Bug fortran/83218] New: gforttran command fails to compile if fortran file is present inside folder "%+@"

[sanket.karnik.s at gmail dot com]

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

Bug ID: 83218
   Summary: gforttran command fails to compile if fortran file is
present inside folder "%+@"
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sanket.karnik.s at gmail dot com
  Target Milestone: ---

I was trying to compile a Fortran file which was present inside a directory
called "%+@". This works fine with gfortran 4.9, however, when I tried to do
the same using gfortran 6.3 I get an error. I tried to compile a simple "Hello
world" program but even that code failed to compile.

Output for version:
gfortran --version
GNU Fortran (MW GCC 6.3.0-GLIBC2.11) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Reproduction steps from any directory:
1. % mkdir %+@
2. %gedit %+@/hello_world.f90
3. copy following code and save the file:
program hello
print *, "Hello World!"
end program hello
4. gfortran %+@/hello_world.f90

This should produce an error.

[Bug fortran/83218] gforttran command fails to compile if fortran file is present inside folder "%+@"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-29
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME on x86_64-apple-darwin17.

[Bug other/83219] New: [8 regression] c-c++-common/ubsan/unreachable-2.c fails starting with r255201

[seurer at gcc dot gnu.org]

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

Bug ID: 83219
   Summary: [8 regression] c-c++-common/ubsan/unreachable-2.c
fails starting with r255201
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Saw this on powerpc64 both LE and BE.

This test case is looking for a specific failure

c-c++-common/ubsan/unreachable-2.c:11:41: runtime error: execution reached a
__builtin_unreachable() call

but after this revision it no longer occurs.

Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/ubsan/unreachable-2.c   
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0  
-O2  -fsanitize=unreachable   
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/

-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/

-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs

-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs

-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs

-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libitm/.libs
-lm  -o ./unreachable-2.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/ubsan/unreachable-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -O2
-fsanitize=unreachable
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/
-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs
-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libitm/.libs
-lm -o ./unreachable-2.exe
PASS: c-c++-common/ubsan/unreachable-2.c   -O2  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-trunk/gcc:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:.:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-trunk/gcc:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs:/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-trunk/./gmp/.libs:/home/seurer/gcc/build/gcc-trunk/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-trunk/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-trunk/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-trunk/./mpc/src/.libs:/home/seurer/gcc/build/gcc-trunk/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-trunk/./isl/.libs:/home/seurer/gcc/build/gcc-trun

[Bug c/83220] New: modification of a global register variable while the function only reads from it

[stefan at potyra dot de]

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

Bug ID: 83220
   Summary: modification of a global register variable while the
function only reads from it
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan at potyra dot de
  Target Milestone: ---

Hi,

thanks for your work on gcc!

>> gcc --version
gcc (Debian 7.2.0-16) 7.2.0

(amd64 environment)

Compiling the following program code results in modification of rbp, even
though the function should only read from it:


struct cpssp {
union {
long double d;
unsigned long long mmx[2];
} fpregs[8];
unsigned int fpstt;
};
#define ST0(cpssp)(cpssp->fpregs[cpssp->fpstt].d)
#define ST(cpssp, n)  (cpssp->fpregs[(cpssp->fpstt + (n)) & 7].d)

register struct cpssp *env asm ("rbp");
unsigned int PARAM1;

void op_fxchg_ST0_STN(void)
{
long double tmp;
tmp = ST(env, PARAM1);
ST(env, PARAM1) = ST0(env);
ST0(env) = tmp;
}

>> objdump -d test.o  

test.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   8b 95 80 00 00 00   mov0x80(%rbp),%edx
   6:   8b 05 00 00 00 00   mov0x0(%rip),%eax# c

   c:   01 d0   add%edx,%eax
   e:   48 c1 e2 04 shl$0x4,%rdx
  12:   83 e0 07and$0x7,%eax
  15:   48 c1 e0 04 shl$0x4,%rax
  19:   48 01 e8add%rbp,%rax
  1c:   48 01 d5add%rdx,%rbp
  1f:   db 28   fldt   (%rax)
  21:   db 6d 00fldt   0x0(%rbp)
  24:   db 38   fstpt  (%rax)
  26:   db 7d 00fstpt  0x0(%rbp)
  29:   c3  retq   


At offset 1c, rbp is modified, while the code should not change it.

Can you take a look?

If you need more information please ask.

P.S.: This is a (simplified) portion of code found in FAUmachine and Volkmar
Sieh found the actual problem. If you have a workaround, I am very happy to
hear it.

Cheers,
  Stefan.

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[hainque at gcc dot gnu.org]

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

--- Comment #10 from Olivier Hainque  ---
Created attachment 42747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42747&action=edit
[patch] don't emit .cfi_personality/.cfi_lsda for !dwarf2 eh

We had a patch for something of this kind we had
observed with local versions of gcc-6. We just recently
observed the same failure/correction on gcc-7 and I
was about to propose the patch for inclusion.

The issue is differences in the generation of
some data items between -g and -g2, visible with
LDFCM labels in particular.

These are somehow related to the emission of
.cfi_personality and .cfi_lsda by dwarf2out_do_cfi_startproc
which aren't needed for SEH anyway.

The proposed patch just prevents the generation of
those .cfi notes if the target eh format isn't dwarf2.

[Bug bootstrap/83096] Bootstrap on darwin x86_64-apple-darwin15.6.0 (revision 254990) fails

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #2 from Aldy Hernandez  ---
Fixed by:

commit b39d9a350c613cde6d8cd15a4d0db082cd904ef2
Author: gerald 
Date:   Mon Nov 27 17:29:06 2017 +

* hash-set.h (DEFINE_DEBUG_HASH_SET): Remove static qualifier
from explicit instantiation of debug_helper.
* vec.h (DEFINE_DEBUG_VEC): Ditto.


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

Closing.

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[hubicka at ucw dot cz]

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

--- Comment #34 from Jan Hubicka  ---
> So gcc loses on mt19937ar.c without -mno-avx2
> But gcc wins big on matrix.c, especially with -mprefer-vector-width=none
> -mno-fma

It is because llvm does not use vgather at all unless avx512 is present.  I
will
look into the vgather cost model tomorrow.

Honza

[Bug tree-optimization/83221] New: qsort comparator not anti-commutative: -2147483648, -2147483648

[babokin at gmail dot com]

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

Bug ID: 83221
   Summary: qsort comparator not anti-commutative: -2147483648,
-2147483648
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 42748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42748&action=edit
reproducer

gcc trunk rev255248, x86_64.

> time g++ -std=c++11 -w -O2 -o gcc_skx_opt_func.o -c 
> func_reduced_gcc_skx_opt.cpp
func_reduced_gcc_skx_opt.cpp: In function ‘void tf_4_foo()’:
func_reduced_gcc_skx_opt.cpp:250:14: error: qsort comparator not
anti-commutative: -2147483648, -2147483648
 void tf_4_foo () {
  ^~~~
during GIMPLE pass: reassoc
func_reduced_gcc_skx_opt.cpp:250:14: internal compiler error: qsort checking
failed
0x8f5c3a qsort_chk_error
../../gcc/gcc/vec.c:222
0x8f5ca5 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
../../gcc/gcc/vec.c:276
0x7db30b vec::qsort(int (*)(void const*,
void const*))
../../gcc/gcc/vec.h:1050
0x7db30b vec::qsort(int (*)(void const*, void
const*))
../../gcc/gcc/vec.h:1812
0x7db30b reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5831
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/83120] [8 Regression] ext/special_functions/hyperg failure on AIX

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
FWIW this also fails on powerpc64 both LE and BE starting with r254924.

[Bug fortran/82605] [PDT] ICE in insert_parameter_exprs, at fortran/decl.c:3154

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Created attachment 42743 [details]
> A fix for the problem
>
> With the attached patch, now produces the error:

The patch works as expected.

> Error: The object ‘x’ at (1) has a deferred LEN parameter ‘b’ and
> is neither allocatable nor a pointer
>
> Giving x either attribute allows compilation and correct execution.
> (I assume that x%a, being a KIND parameter, is OK in a KIND specification?

I see something strange with/without the patch:

program p
   type t(a, b)
  integer, kind :: a
  integer, len :: b
  real(a) :: r(b)
   end type
   type(t(8, 10)) :: x
   real(x%a) :: y
   print *, kind(x%r), kind(y)
end

prints

   8   8

while

program p
   type t(a, b)
  integer, kind :: a
  integer, len :: b
  real(a) :: r(b)
   end type
   type(t(8, :)), allocatable :: x
   real(x%a) :: y
   print *, kind(x%a), kind(y)
end

prints

   4   8

In addition with the last test, I did not find a way to do any allocation.

[Bug c++/82760] Incorrect code generated for aligned new

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Nov 29 21:01:23 2017
New Revision: 255253

URL: https://gcc.gnu.org/viewcvs?rev=255253&root=gcc&view=rev
Log:
PR c++/82760 - memory corruption with aligned new.

* call.c (build_operator_new_call): Update *args if we add the
align_arg.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/aligned-new8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug fortran/82606] [PDT] ICE in gfc_extract_int, at fortran/expr.c:641

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Created attachment 42746 [details]
> A fix for the problem

This fix the test in comment 0, but not the one in comment 1.

[Bug c++/82293] [8 Regression] ICE in nonlambda_method_basetype at gcc/cp/lambda.c:886

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Nov 29 21:54:18 2017
New Revision: 255254

URL: https://gcc.gnu.org/viewcvs?rev=255254&root=gcc&view=rev
Log:
/cp
2017-11-29  Paolo Carlini  

PR c++/82293
* lambda.c (nonlambda_method_basetype): Don't use LAMBDA_TYPE_P
on a null type.

/testsuite
2017-11-29  Paolo Carlini  

PR c++/82293
* g++.dg/cpp0x/lambda/lambda-ice24.C: New.

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

[Bug c++/82293] [8 Regression] ICE in nonlambda_method_basetype at gcc/cp/lambda.c:886

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #3 from Paolo Carlini  ---
Fixed.

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Author: jamborm
Date: Wed Nov 29 22:13:34 2017
New Revision: 255256

URL: https://gcc.gnu.org/viewcvs?rev=255256&root=gcc&view=rev
Log:
Be conservative with arithmetic jmp-function types

2017-11-29  Martin Jambor  

PR ipa/82808
* tree.c (expr_type_first_operand_type_p): New function.
* tree.h (expr_type_first_operand_type_p): Declare it.
* ipa-cp.c (ipa_get_jf_pass_through_result): Use it.

testsuite/
* gcc.dg/ipa/pr82808.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/ipa/pr82808.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/ipa-cp.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree.c
branches/gcc-7-branch/gcc/tree.h

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Jambor  ---
Fixed.

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Nov 29 22:19:25 2017
New Revision: 255258

URL: https://gcc.gnu.org/viewcvs?rev=255258&root=gcc&view=rev
Log:
2017-11-29  Vladimir Makarov  

PR rtl-optimization/80818
* lra.c (collect_non_operand_hard_regs): New arg insn.  Pass it
recursively.  Use insn code for clobber.
(lra_set_insn_recog_data): Pass the new arg to
collect_non_operand_hard_regs.
(add_regs_to_insn_regno_info): Pass insn instead of uid.  Use insn
code for clobber.
(lra_update_insn_regno_info): Pass insn to
add_regs_to_insn_regno_info.


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

[Bug tree-optimization/81018] [8 regression] gfortran.dg/graphite/pr14741.f90 FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/83176] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug rtl-optimization/82621] [6/7 Regression] wrong code with -Og -fgcse -fweb

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
Author: segher
Date: Wed Nov 29 22:42:37 2017
New Revision: 255260

URL: https://gcc.gnu.org/viewcvs?rev=255260&root=gcc&view=rev
Log:
combine: Do not throw away unneeded arms of parallels (PR83156)

The fix for PR82621 makes us not split an I2 if one of the results of
those SETs is unused, since combine does not handle that properly.  But
this results in degradation for i386 (or more in general, for any
target that does not have patterns for parallels with an unused result
as a CLOBBER instead of a SET for that result).

This patch instead makes us not split only if one of the results is set
again before I3.  That fixes PR83156 and also fixes PR82621.

Unfortunately it undoes the nice optimisations that the previous patch
did on powerpc.


PR rtl-optimization/83156
PR rtl-optimization/82621
* combine.c (try_combine): Don't split an I2 if one of the dests is
set again before I3.  Allow unused dests.

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