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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking,
   ||ice-on-valid-code
   Target Milestone|--- |8.0
Summary|qsort comparator not|[8 Regression] qsort
   |anti-commutative:   |comparator not
   |-2147483648, -2147483648|anti-commutative:
   ||-2147483648, -2147483648

[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 #8 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 30 07:53:31 2017
New Revision: 255267

URL: https://gcc.gnu.org/viewcvs?rev=255267=gcc=rev
Log:
2017-11-30  Richard Biener  

PR tree-optimization/83202
* tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Add
allow_peel argument and guard peeling.
(canonicalize_loop_induction_variables): Likewise.
(canonicalize_induction_variables): Pass false.
(tree_unroll_loops_completely_1): Pass unroll_outer to disallow
peeling from cunrolli.

* gcc.dg/vect/pr83202-1.c: New testcase.
* gcc.dg/tree-ssa/pr61743-1.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr83202-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61743-1.c
trunk/gcc/tree-ssa-loop-ivcanon.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 #9 from Richard Biener  ---
The last commit fixed the testcase incomment #1.

[Bug fortran/83224] New: creating character array from elements shorter than declared does not pad with whitespace properly and aborts

[urbanjost at comcast dot net]

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

Bug ID: 83224
   Summary: creating character array from elements shorter than
declared does not pad with whitespace properly and
aborts
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

I expect this program to produce at the end


 PASS 21
[one  ][two  ][three][four ][five ]
[six  ][seven][eight][nine ][ten[ ]
[eleven   ][twelve   ][thirteen ][fourteen ][fifteen  ]
[sixteen  ][seventeen][eighteen ][nineteen ][twenty   ]
[twentyone]


Instead, I got an abort when the length reached 9 characters, and without
the blank padding I was expecting 


 PASS 16
[onetwttw][twothtth][threeffo][four ffi][five ssi]
[six  sse][seveneei][eightnni][nine tte][ten  eel]
[eleventw][twelveth][thirteen][fourteen][fifteen ]
[sixteen ]


Program received signal SIGABRT: Process abort signal.

I am using gfortran 6.4 on Cygwin, and it was confirmed that it
acts as I thought it would with another Fortran implementation 
(Intel 18.0.1).

program dusty_corner ! exercise f2008 CHARACTER features
implicit none
character(len=:),allocatable :: words(:)
character(len=:),allocatable :: trimmed
integer  :: i,big
character(len=*),parameter   :: data(*)=[character(len=20) :: &
'one','two','three', 'four',  'five', &
'six','seven',  'eight', 'nine',  'ten' , &
'eleven', 'twelve', 'thirteen',  'fourteen',  'fifteen',  &
'sixteen','seventeen',  'eighteen',  'nineteen',  'twenty',   &
'twentyone' ]
words=[character(len=0)::] ! Allocate zero-size array
big=0
INFINITE: do i=1,size(data)
   trimmed=trim(data(i)) ! create variables of various lengths
   big=max(big,len(trimmed)) ! find longest length so far
   ! next, when BIG increases WORDS should be padded with spaces?
   words=[ CHARACTER(LEN=big) :: words, trimmed ]
   write(*,'(a,i0)')'PASS ',i
   write(*,'(5("[",a,"]":))')words
   write(*,'(a)')repeat('=',80)
enddo INFINITE
end program dusty_corner

[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 #13 from Liu Hao  ---
Native TLS requires essential support from LD, which I don't think is going to
be available in foreseeable future.

Without native TLS GCC tries to use emulated TLS, and if it generates code
attempting to use the native one (which does not exist), it is, of course, a
bug.

[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 #12 from Daniel Starke  ---
I am not an expert on this field but your build does not use platform tls
support as mine is supposed to do. Furthermore, I was building all under
Windows. The only difference during the build process was the target
architecture (x86/x64). Using --enable-targets=all produced a compiler able to
build for both architectures. Not specifying --build= should just default to
the base compilers default target (which is, nevertheless, Windows). The only
issue I could possible see here is that the base compiler used to build GCC did
not support platform tls support but GCC still assumed it was available
resulting in a wrong setup. In this sense I was cross compiling (mingw x86 to
mingw-w64 x64).
Nevertheless, building GCC without --enable-tls like you did produces a working
executable for me too as mentioned on 2017-05-26.

[Bug target/83100] [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections

[ian at gcc dot gnu.org]

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

--- Comment #10 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Nov 30 05:03:29 2017
New Revision: 255266

URL: https://gcc.gnu.org/viewcvs?rev=255266=gcc=rev
Log:
compiler: don't make map zero value constant

The map zero value is a common symbol, and it doesn't really make
sense to have a constant common symbol. Current GCC has started to
reject this case, probably as part of the fix for PR 83100.

Reviewed-on: https://go-review.googlesource.com/80877

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/types.cc

[Bug libfortran/81937] stack-buffer-overflow on memcpy in libgfortran/io/unix.c on character(kind=4)

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #3 from Jerry DeLisle  ---
I will get on this one shortly.

[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 #11 from Liu Hao  ---
Diff'ing configure options used to build both GCC produces the following
result:

```
E:\Desktop>gcc-7.1.0-debug-broken-tls\bin\gcc.exe -v 2>&1 | sed "s/ --/\n&/g" >
yours.txt

E:\Desktop>gcc -v 2>&1 | sed "s/ --/\n&/g" > mine.txt

E:\Desktop>gcc-7.1.0-debug-broken-tls\bin\gcc.exe -v 2>&1 | sed "s/ --/\n&/g" >
yours.txt

E:\Desktop>diff --color -U1 mine.txt yours.txt
--- mine.txt2017-11-30 09:42:33.612869600 +0800
+++ yours.txt   2017-11-30 09:42:35.493977200 +0800
@@ -1,47 +1,35 @@
 Using built-in specs.
-COLLECT_GCC=gcc
-COLLECT_LTO_WRAPPER=C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/7.2.1/lto-wrapper.exe
+COLLECT_GCC=gcc-7.1.0-debug-broken-tls\bin\gcc.exe
+COLLECT_LTO_WRAPPER=e:/desktop/gcc-7.1.0-debug-broken-tls/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
 Target: x86_64-w64-mingw32
-Configured with: ../gcc/configure
- --prefix=/mingw64
- --with-local-prefix=/mingw64/local
- --build=x86_64-w64-mingw32
+Configured with: ../../src/gcc-7.1.0/configure
  --host=x86_64-w64-mingw32
- --target=x86_64-w64-mingw32
- --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
- --libexecdir=/mingw64/lib
- --enable-bootstrap
- --with-arch=x86-64
- --with-tune=nocona
- --enable-languages=c,lto,c++
- --enable-shared
+ --enable-languages=c,c++
+ --enable-seh-exceptions
+ --enable-threads=posix
+ --enable-tls
+ --disable-nls
+ --disable-shared
  --enable-static
- --enable-threads=mcf
- --enable-graphite
  --enable-fully-dynamic-string
- --enable-libstdcxx-time=yes
- --disable-libstdcxx-pch
- --disable-libstdcxx-debug
- --disable-isl-version-check
  --enable-lto
+ --enable-plugins
  --enable-libgomp
- --disable-multilib
- --enable-checking=release
- --disable-rpath
+ --with-dwarf2
  --disable-win32-registry
- --enable-nls
- --disable-werror
- --disable-symvers
- --with-libiconv
- --with-system-zlib
- --with-gmp=/mingw64
- --with-mpfr=/mingw64
- --with-mpc=/mingw64
- --with-isl=/mingw64
- --with-pkgversion='gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.'
- --with-bugurl=https://gcc-mcf.lhmouse.com/
- --with-gnu-as
- --with-gnu-ld
- --disable-tls
-Thread model: mcf
-gcc version 7.2.1 20171119 (gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.)
+ --enable-version-specific-runtime-libs
+ --prefix=/mingw64-64
+ --with-sysroot=/mingw64-64
+ --target=x86_64-w64-mingw32
+ --enable-targets=all
+ --enable-checking=release
+ --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
+ --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2
+ --with-mpc=/usr/new-gcc/lib/mpc-0.9
+ --with-isl=/usr/new-gcc/lib/isl-0.18
+ --with-cloog=/usr/new-gcc/lib/cloog-0.18.4
+ --with-host-libstdcxx='-lstdc++ -lsupc++'
+ --disable-cloog-version-check
+ --enable-cloog-backend=isl
+Thread model: posix
+gcc version 7.1.0 (GCC)

E:\Desktop>
```

I notice that:
0) You didn't specify `--build=`.
1) You specified `--enable-targets=all` but I think this does not affect mingw
targets according to  and should be
removed.

Maybe you should try adding `--build=`?

[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 #10 from Liu Hao  ---
Compiling this rather simple program using your gcc:

```
__thread int a = 1;

int get_a(void){
   return a;
}
```

resulted in wrong assembly:

```
E:\Desktop\gcc-7.1.0-debug-broken-tls\bin>gcc E:\Desktop\test.c -S -masm=intel
-O2 -o -
.file   "test.c"
.intel_syntax noprefix
.text
.p2align 4,,15
.globl  get_a
.defget_a;  .scl2;  .type   32; .endef
.seh_proc   get_a
get_a:
.seh_endprologue
mov rax, QWORD PTR fs:0
mov eax, DWORD PTR a@tpoff[rax]
ret
.seh_endproc
.globl  a
.data
.align 4
a:
.long   1
.ident  "GCC: (GNU) 7.1.0"
```

With my working GCC it resulted in:

```
E:\Desktop>gcc E:\Desktop\test.c -S -masm=intel -O2 -o -
.file   "test.c"
.intel_syntax noprefix
.text
.globl  get_a
.defget_a;  .scl2;  .type   32; .endef
.seh_proc   get_a
get_a:
sub rsp, 40
.seh_stackalloc 40
.seh_endprologue
lea rcx, __emutls_v.a[rip]
call__emutls_get_address
mov eax, DWORD PTR [rax]
add rsp, 40
ret
.seh_endproc
.section .rdata,"dr"
.align 4
__emutls_t.a:
.long   1
.globl  __emutls_v.a
.data
.align 32
__emutls_v.a:
.quad   4
.quad   4
.quad   0
.quad   __emutls_t.a
.ident  "GCC: (gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.) 7.2.1 20171119"
.def__emutls_get_address;   .scl2;  .type   32; .endef
```

[Bug c/83223] New: -fconserve-stack outlined code isn't dropped if it's logically unreachable

[george.burgess.iv at gmail dot com]

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

Bug ID: 83223
   Summary: -fconserve-stack outlined code isn't dropped if it's
logically unreachable
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: george.burgess.iv at gmail dot com
  Target Milestone: ---

GCC version: Reproed on godbolt's GCC trunk, 7.2, and 4.9.

Test case (godbolt link, if you'd prefer: https://godbolt.org/g/zxhjPV):

$ echo 'struct data { char foo[64]; };

void complain() __attribute__((warning("oh no!")));
void panic(const char *) __attribute__((noreturn, cold));
void *foo_real(void *, const void *);

void bar(struct data *ptr) {
  char tmp[sizeof(ptr->foo)];
  if (__builtin_object_size(ptr->foo, 0) >= sizeof(ptr->foo)) {
foo_real(ptr->foo, tmp);
  } else {
complain();
panic("");
  }
}

__auto_type v = bar;' | gcc -x c -fconserve-stack -O2 - -o /dev/null -c

: In function ‘bar.part.0’:
:12:5: warning: call to ‘complain’ declared with attribute warning: oh
no!

It looks like the outlined part sticks around if `bar`'s address is taken.
Normally, this isn't a problem. However, it can cause false-positives in code
that uses the warning or error attributes (as shown above).

[Bug c/83222] [ 8 regression] Inconsistent "initializer element is not constant" error

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Ian Lance Taylor  ---
This may be caused by the recent fix for PR 69960.

[Bug c/83222] [ 8 regression] Inconsistent "initializer element is not constant" error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Target Milestone|--- |8.0
   Severity|critical|normal

[Bug c/83222] New: [ 8 regression] Inconsistent "initializer element is not constant" error

[ian at airs dot com]

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

Bug ID: 83222
   Summary: [ 8 regression] Inconsistent "initializer element is
not constant" error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

The handling of this C program recently changed:

const char _expA = 0x42;
void __cgo_f_1_4(void) { static const double x = (double)(_expA); }

With a GCC built on October 10, 2017, I get this:

foo.c: In function ‘__cgo_f_1_4’:
foo.c:2:50: error: initializer element is not constant
 void __cgo_f_1_4(void) { static const double x = (double)(_expA); }
  ^
With this morning's sources (November 29, 2017) the program compiles without
error.

Perhaps that change is OK.  But this similar program still fails:

const char _expA = 0x42;
double __cgodebug_floats[] = {
  _expA,
  1
};

foo1.c:3:3: error: initializer element is not constant
   _expA,
   ^
foo1.c:3:3: note: (near initialization for ‘__cgodebug_floats[0]’)


I think that if we are going to change the behavior for the first program, we
need to change the behavior for the second one.

[Bug target/83156] [8 regression] gcc.target/i386/pr82361-1.c fail

[segher at gcc dot gnu.org]

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

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

URL: https://gcc.gnu.org/viewcvs?rev=255260=gcc=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

[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=gcc=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

[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 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/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/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 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=gcc=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 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 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=gcc=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 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 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=gcc=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 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++/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=gcc=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/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 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 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=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 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 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 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=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 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 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

[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 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 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 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 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=gcc=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 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=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 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 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 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 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=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 #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 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 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 

[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 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 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

[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/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

[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

[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 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 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 

[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 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 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/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 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

[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=gcc=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 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=edit
gcc8-pr83205.patch

Untested fix.

[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 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=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 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 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([i][j]);
v = _mm_mul_pd(v, v);
_mm_storeu_pd([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([i][j]);
v = _mm_mul_pd(v, v);
_mm_storeu_pd([i][j], v);
}
}
}

[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=246866).

[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 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 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 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=gcc=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++/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 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 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 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=edit
Executable async and skip produced by GCC trunk

[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 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 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 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 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/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 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 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 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 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=gcc=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 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=gcc=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 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 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=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 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++/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

[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 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 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

[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/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/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

[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 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.