[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #1 from Tom de Vries  ---
The test-case XPASSes for me for trunk r250889 on Quadro 1200m with 375.66
driver and cuda 7.5:
...
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vprop.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  (test for excess errors)
XPASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vprop.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vprop.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  (test for excess errors)
XPASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vprop.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
...

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #9 from Vincent Lefèvre  ---
Changed back to INVALID (there's a bug in bugzilla, which changes INVALID to
FIXED after a reload + a new comment).

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[vincent-gcc at vinc17 dot net]

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

--- Comment #8 from Vincent Lefèvre  ---
(In reply to Vincent Lefèvre from comment #7)
> Here one gets two different results!

For this latest issue (which is the cause of the error in C), I've reported
PR81746.

[Bug preprocessor/81746] New: a blackslash at the end of a file is not removed

[vincent-gcc at vinc17 dot net]

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

Bug ID: 81746
   Summary: a blackslash at the end of a file is not removed
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

According to https://gcc.gnu.org/ml/gcc-patches/2007-04/msg00504.html each
input file is defined "to end with a newline, whether or not the actual
physical Unix input file did so". This is why the following works:

$ printf '#define FOO' | gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 ""
$

and

$ printf 'int main(void) { return 0; } //' | gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 ""
int main(void) { return 0; }
$

But the following doesn't work:

$ printf 'int main(void) { return 0; } \\' | gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 ""
int main(void) { return 0; } \
$

The backslash should have been removed, just like "//" was removed above. This
yields an error if there is no explicit newline character at the end of the
physical Unix input file:

$ printf 'int main(void) { return 0; } \\' | gcc -xc -std=c99 - && echo OK
:1:30: error: stray ‘\’ in program
$ printf 'int main(void) { return 0; } \\\n' | gcc -xc -std=c99 - && echo OK
:1:30: warning: backslash-newline at end of file
OK
$

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[vincent-gcc at vinc17 dot net]

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

--- Comment #7 from Vincent Lefèvre  ---
And with only the preprocessor:

$ printf 'int main(void) { return 0; } \\' | gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 ""
int main(void) { return 0; } \
$ printf 'int main(void) { return 0; } \\\n' | gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 ""
:1:30: warning: backslash-newline at end of file
int main(void) { return 0; }
$

Here one gets two different results!

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[vincent-gcc at vinc17 dot net]

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

--- Comment #6 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #5)
> Also see http://www.opengroup.org/austin/aardvark/latest/xcubug2.txt
> ERN 76

This is not about the missing newline at the end of a file.

Moreover, GCC doesn't seem to be consistent:

$ printf 'int main(void) { return 0; } \\' | gcc -xc -std=c99 - && echo OK
:1:30: error: stray ‘\’ in program
$ printf 'int main(void) { return 0; } \\\n' | gcc -xc -std=c99 - && echo OK
:1:30: warning: backslash-newline at end of file
OK
$

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Also see http://www.opengroup.org/austin/aardvark/latest/xcubug2.txt
ERN 76

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #3)
> https://gcc.gnu.org/ml/gcc-patches/2007-04/msg00504.html
> 
> See that reasoning there.

"It's really not undefined at all.  gcc would be still be standard
conformant if we defined all input to end with a newline, whether or
not the actual physical Unix input file did so."

OK, but this needs to be documented.

The GCC manual says:


4.2 Environment
===

The behavior of most of these points are dependent on the implementation
of the C library, and are not defined by GCC itself.

   * 'The mapping between physical source file multibyte characters and
 the source character set in translation phase 1 (C90, C99 and C11
 5.1.1.2).'


However, the fact that all input files are regarded to end with a newline is
completely specific to GCC, not part of how the C library works.

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc-patches/2007-04/msg00504.html

See that reasoning there.

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
IIRC There was some discussion before and it was decided that the warning was
not needed.

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
See the thread starting at
https://gcc.gnu.org/ml/gcc-patches/2007-04/msg00457.html .

[Bug preprocessor/81745] New: missing warning with -pedantic when a C file does not end with a newline character

[vincent-gcc at vinc17 dot net]

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

Bug ID: 81745
   Summary: missing warning with -pedantic when a C file does not
end with a newline character
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

The ISO C99 and C11 standards say in 5.1.1.2#2: "A source file that is not
empty shall end in a new-line character". But the following doesn't generate
any warning or error message:

$ printf 'int main(void) { return 0; }' | gcc -xc -std=c99 -pedantic -
$

with all the GCC versions I could test, including a 8.0.0 snapshot [trunk
revision 250749].

Clang generates a warning (implied by -pedantic) as expected:

$ printf 'int main(void) { return 0; }' | clang-4.0 -xc -std=c99 -pedantic -
:1:29: warning: no newline at end of file [-Wnewline-eof]
int main(void) { return 0; }
^
1 warning generated.
$

GCC should do the same thing and use the same warning name -Wnewline-eof.

Note: This bug is apparently a consequence of the fix of PR14331. In the bug
report, it was asked for a new option, but the warning was suppressed
unconditionally:
https://gcc.gnu.org/viewcvs/gcc/trunk/libcpp/lex.c?r1=125212=125211=125212

[Bug testsuite/59971] multilib_flags is placed with the wrong order

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2014-01/msg01891.ht
   ||ml

--- Comment #4 from Andrew Pinski  ---
This patch might make sense since RHEL/CentOS 6 still contains a broken
dejagnu.

[Bug tree-optimization/81744] New: ICE: verify_ssa failed, at tree-ssa.c:1186

[jamrial at gmail dot com]

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

Bug ID: 81744
   Summary: ICE: verify_ssa failed, at tree-ssa.c:1186
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

Created attachment 41942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41942=edit
Preprocessed output created with -freport-bug

[jamrial@ArchVM ~]$ gcc -fno-math-errno -O3 -c ccV0zFt3.i
src/libavfilter/af_compand.c: In function ‘config_output’:
src/libavfilter/af_compand.c:328:12: error: definition in block 78 follows the
use
for SSA_NAME: _519 in statement:
_126 = _519 + 4294967291;
during GIMPLE pass: pcom
src/libavfilter/af_compand.c:328:12: internal compiler error: verify_ssa failed
0xdb534b verify_ssa(bool, bool)
/home/jamrial/gcc-svn/gcc/tree-ssa.c:1186
0xa99527 execute_function_todo
/home/jamrial/gcc-svn/gcc/passes.c:1997
0xa9a442 execute_todo
/home/jamrial/gcc-svn/gcc/passes.c:2044
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[jamrial@ArchVM ~]$ gcc -fno-math-errno -fno-tree-vectorize -O3 -c ccV0zFt3.i
src/libavfilter/af_compand.c: In function ‘config_output’:
src/libavfilter/af_compand.c:328:12: error: definition in block 83 follows the
use
for SSA_NAME: _618 in statement:
_611 = _618 + 4294967291;
during GIMPLE pass: pcom
src/libavfilter/af_compand.c:328:12: internal compiler error: verify_ssa failed
0xdb534b verify_ssa(bool, bool)
/home/jamrial/gcc-svn/gcc/tree-ssa.c:1186
0xa99527 execute_function_todo
/home/jamrial/gcc-svn/gcc/passes.c:1997
0xa9a442 execute_todo
/home/jamrial/gcc-svn/gcc/passes.c:2044
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Doesn't crash if i remove either -fno-math-errno or -O3. Adding
-fno-tree-vectorize only changes the contents of the SSA_NAME error.
This seems to be a regression introduced sometime during the past week.

[Bug target/81743] int __attribute__ ((target("arch=westmere"))) is compiled incorrectly

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
Created attachment 41941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41941=edit
A patch

I am testing this patch on Westmere.

[Bug target/81743] New: int __attribute__ ((target("arch=westmere"))) is compiled incorrectly

[hjl.tools at gmail dot com]

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

Bug ID: 81743
   Summary: int __attribute__ ((target("arch=westmere"))) is
compiled incorrectly
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

For g++.dg/ext/mv16.C, GCC generates:

[hjl@gnu-tools-1 gcc]$
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/g++/../../xg++
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/g++/../../
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv16.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/include/backward
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=gnu++14 -O2
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libitm/
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libitm/.libs
-S

.type   _Z3foov.resolver, @function
_Z3foov.resolver:
.LFB11:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call__cpu_indicator_init
cmpl$13, __cpu_model+8(%rip)
movl$_Z3foov.arch_haswell, %eax
jne .L29
.L19:
addq$8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L29:
.cfi_restore_state
cmpl$14, __cpu_model+8(%rip)
movl$_Z3foov.arch_broadwell, %eax
je  .L19
cmpl$15, __cpu_model+8(%rip)
movl$_Z3foov.arch_skylake, %eax
je  .L19
cmpl$16, __cpu_model+8(%rip)
movl$_Z3foov.arch_skylake_avx512, %eax
je  .L19
cmpl$3, __cpu_model+8(%rip)
movl$_Z3foov.arch_sandybridge, %eax
je  .L19
cmpl$12, __cpu_model+8(%rip)
movl$_Z3foov.arch_ivybridge, %eax
je  .L19
cmpl$3, __cpu_model+4(%rip)
movl$_Z3foov.arch_nehalem, %eax
je  .L19  < This is wrong.  Nehalem and Westmere have
the same CPU type.
cmpl$2, __cpu_model+8(%rip)
movl$_Z3foov, %eax
movl$_Z3foov.arch_westmere, %edx
cmove   %rdx, %rax
jmp .L19
.cfi_endproc
.LFE11:
.size   _Z3foov.resolver, .-_Z3foov.resolver

[Bug c++/81742] New: c++: internal compiler error: Segmentation fault (program cc1plus)

[mebates at hotmail dot com]

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

Bug ID: 81742
   Summary: c++: internal compiler error: Segmentation fault
(program cc1plus)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mebates at hotmail dot com
  Target Milestone: ---

Created attachment 41940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41940=edit
build file

I was following the directions on the web page below. I selected Python3 and
opencv-3.0.0 and opencv_contrib-3.0.0. (I tried opencv-3.2.0 also, but I got a
different error, so I went back to 3.0.0. The 3.2.0 error was regarding a
#pragma that wasn't recognized.) I have executed the procedure that this web
page explains before (2 months ago) and it worked without problems.

http://www.pyimagesearch.com/2015/10/26/how-to-install-opencv-3-on-raspbian-jessie/

///
/ Errors as reported in Terminal Window:
///

 62%] Built target example_tracking_tracker
[ 62%] Built target example_tracking_benchmark
[ 62%] Building CXX object
modules/tracking/CMakeFiles/opencv_test_tracking.dir/test/test_main.cpp.o
[ 63%] Built target opencv_perf_tracking

c++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
modules/tracking/CMakeFiles/opencv_test_tracking.dir/build.make:62: recipe for
target
'modules/tracking/CMakeFiles/opencv_test_tracking.dir/test/test_main.cpp.o'
failed
make[2]: ***
[modules/tracking/CMakeFiles/opencv_test_tracking.dir/test/test_main.cpp.o]
Error 4
CMakeFiles/Makefile2:7813: recipe for target
'modules/tracking/CMakeFiles/opencv_test_tracking.dir/all' failed
make[1]: *** [modules/tracking/CMakeFiles/opencv_test_tracking.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 63%] Built target example_ximgproc_seeds
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
(cv) pi@raspberrypi:~/opencv-3.0.0/build $

[Bug c/81741] New: Misoptimisation : replacing a constant field read access by a function call

[patrick.pelissier at gmail dot com]

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

Bug ID: 81741
   Summary: Misoptimisation : replacing a constant field read
access by a function call
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.pelissier at gmail dot com
  Target Milestone: ---

GCC 7.1.0 generates for the following code:


#include 

typedef struct string_s {
  unsigned long size, alloc;
  char *ptr;
} string_t[1];

# define M_ASSUME(x)\
  (! __builtin_constant_p (!!(x) || !(x)) || (x) ?  \
   (void) 0 : __builtin_unreachable())

int f(string_t s)
{
  M_ASSUME(strlen(s->ptr) == s->size);
  return s->size;
}


the following code on an x86-64 platform (gcc -std=c99 -O2 -S test.c):


f:
subq$8, %rsp
movq16(%rdi), %rdi
callstrlen
addq$8, %rsp
ret


Notice that the field access s->size is replaced by strlen(s->ptr), which is
way slower.

GCC 4.9 doesn't have this issue.

[Bug tree-optimization/81723] [7/8 Regression] fortran build doesn't terminate on 64bit targets

[doko at gcc dot gnu.org]

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

--- Comment #5 from Matthias Klose  ---
same behavior with trunk 20170731

[Bug middle-end/81737] [8 Regression] 164.gzip in SPEC CPU 2000 failed to build

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Untested, but this should fix it:

--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -14107,8 +14107,10 @@ fold_indirect_ref_1 (location_t loc, tree type, tree
op0)
   && type == TREE_TYPE (op00type))
{
  tree type_domain = TYPE_DOMAIN (op00type);
- tree min = TYPE_MIN_VALUE (type_domain);
- if (min && TREE_CODE (min) == INTEGER_CST)
+ tree min;
+ if (type_domain != NULL_TREE
+ && (min = TYPE_MIN_VALUE (type_domain))
+ && TREE_CODE (min) == INTEGER_CST)
{
  offset_int off = wi::to_offset (op01);
  offset_int el_sz = wi::to_offset (TYPE_SIZE_UNIT (type));

[Bug tree-optimization/81723] [7/8 Regression] fortran build doesn't terminate on 64bit targets

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|WAITING |UNCONFIRMED
  Component|fortran |tree-optimization
 Ever confirmed|1   |0

[Bug fortran/81723] [7/8 Regression] fortran build doesn't terminate on 64bit targets

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  ---
Created attachment 41939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41939=edit
original source file

[Bug fortran/81723] [7/8 Regression] fortran build doesn't terminate on 64bit targets

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
Created attachment 41938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41938=edit
preprocessed source

[Bug fortran/81723] [7/8 Regression] fortran build doesn't terminate on 64bit targets

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
this can be worked around with -O2.

gfortran -g -c -O3 -D_FORTIFY_SOURCE=2 -fno-range-check -fno-automatic
-fno-second-underscore -fstack-protector --param=ssp-buffer-size=4
-fno-automatic -I/home/ubuntu/libscan/cernlib-20061220+dfsg3/build/mathlib/gen
-I/home/ubuntu/libscan/cernlib-20061220+dfsg3/src/mathlib/gen
-I/home/ubuntu/libscan/cernlib-20061220+dfsg3/src/mathlib/gen/c
-I/home/ubuntu/libscan/cernlib-20061220+dfsg3/src/include -DCERNLIB_LINUX
-DCERNLIB_UNIX -DCERNLIB_LNX -DCERNLIB_QMGLIBC -DCERNLIB_QMLXIA64
-DCERNLIB_VERBOSE -DCERNLIB_DEBIAN -DDEBIAN_VERSION="20061220+dfsg3-4.3build1"
-DCERNLIB_QGETCWD -DCERNLIB_GFORTRAN -o archive/cwerf64.o
/home/ubuntu/libscan/cernlib-20061220+dfsg3/src/mathlib/gen/c/cwerf64.F

#0  0x768ec98f in __GI___libc_malloc (bytes=24) at malloc.c:2926
#1  0x011b7230 in xrealloc (oldmem=oldmem@entry=0x0,
size=size@entry=24) at ../../src/libiberty/xmalloc.c:177
#2  0x00c5bb95 in va_heap::reserve (exact=true, reserve=2,
v=@0x1f5a0a0: 0x0) at ../../src/gcc/vec.h:288
#3  vec::reserve (exact=true, nelems=2,
this=0x1f5a0a0) at ../../src/gcc/vec.h:1445
#4  vec::reserve_exact (nelems=2, this=0x1f5a0a0) at
../../src/gcc/vec.h:1465
#5  vec::create (nelems=2, this=0x1f5a0a0) at
../../src/gcc/vec.h:1480
#6  vect_create_oprnd_info (group_size=2, nops=2) at
../../src/gcc/tree-vect-slp.c:152
#7  vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0, stmts=...,
group_size=group_size@entry=2, max_nunits=max_nunits@entry=0x7fff6fb8, 
loads=loads@entry=0x7fff6fc8, matches=matches@entry=0x7fffdae0,
npermutes=0x7fffdba0, tree_size=0x7fff6fb4, max_tree_size=293)
at ../../src/gcc/tree-vect-slp.c:959
#8  0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff7138,
loads=loads@entry=0x7fff7148, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#9  0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff72b8,
loads=loads@entry=0x7fff72c8, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#10 0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff7438,
loads=loads@entry=0x7fff7448, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#11 0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff75b8,
loads=loads@entry=0x7fff75c8, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#12 0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff7738,
loads=loads@entry=0x7fff7748, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#13 0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff78b8,
loads=loads@entry=0x7fff78c8, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#14 0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff7a38,
loads=loads@entry=0x7fff7a48, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#15 0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff7bb8,
loads=loads@entry=0x7fff7bc8, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#16 0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff7d38,
loads=loads@entry=0x7fff7d48, matches=matches@entry=0x7fffdae0,
npermutes=, 
tree_size=, max_tree_size=) at
../../src/gcc/tree-vect-slp.c:1001
#17 0x00c5b7a1 in vect_build_slp_tree (vinfo=vinfo@entry=0x1f3dbe0,
stmts=..., group_size=group_size@entry=2, 
max_nunits=max_nunits@entry=0x7fff7eb8,
loads=loads@entry=0x7fff7ec8, matches=matches@entry=0x7fffdae0,

[Bug ipa/80728] IPA-reference suppresses compiler memory barrier

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
Honza: ping :).  ipa-pure-const might be a better place to mark functions with
compiler memory barriers, as it already computes and propagates "nonfreeing"
property (thus computing "nonbarrier" in ipa-pure-const would allow to use it
in implementation of nonbarrier_call_p).

OTOH ipa-pure-const is optional, so with -fno-ipa-pure-const, ipa-reference
would see most functions as compiler memory barriers.  Although it's possible
to rescan bodies of those functions that ipa-pure-const did not scan, that
seems undesirable.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[dominiq at lps dot ens.fr]

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

--- Comment #62 from Dominique d'Humieres  ---
Created attachment 41937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41937=edit
Log file for ms-sysv.exp

Log file generated with

make -k check-gcc RUNTESTFLAGS="ms-sysv.exp"

[Bug libstdc++/29366] atomics config for sh is weird

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |olegendo at gcc dot 
gnu.org

--- Comment #11 from Eric Gallager  ---
(In reply to Oleg Endo from comment #10)
> (In reply to Eric Gallager from comment #9)
> > 
> > Did this fix things?
> 
> No, not entirely.  The whole config/cpu/sh/atomicity.h header should not be
> required, but because of PR 53579, it is.
> 
> Please do not close any SH related PR's just for the sake of reducing the
> number of PR's.  I keep them open because they are actual issues.

Assigning to you, then, per our discussion in bug 30065 (and since you've
already made a commit towards fixing this one)

[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Oleg Endo from comment #7)
> (In reply to Eric Gallager from comment #6)
> > 
> > Can I change the status to SUSPENDED or assign them to you instead? I'm not
> > so much trying to reduce the number of open PRs as I am trying to just move
> > them out of the WAITING queue. https://gcc.gnu.org/bugs/management.html says
> > bugs are only ever supposed to stay in the WAITING state for 3 months, after
> > all.
> 
> Whatever, as long as it stays open.

OK, thanks.

[Bug c/81740] New: wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[chengniansun at gmail dot com]

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

Bug ID: 81740
   Summary: wrong code at -O3 in both 32-bit and 64-bit modes on
x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v 
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170806 (experimental) [trunk revision 250895] (GCC) 
$ 
$ gcc-trunk -O3 small.c ; ./a.out > O3.txt
$ gcc-trunk -O0 small.c ; ./a.out > O0.txt
$ diff O3.txt O0.txt 
37c37
< 0
---
> 4
$ cat small.c
extern int printf(const char *, ...);
int a[8][10];
short b;
int c, i, d;
int main() {
  a[2][5] = b = 4;
  for (; b; b--) {
c = 0;
for (; c <= 6; c++)
  a[c + 1][b + 2] = a[c][b + 1];
  }
  for (; i < 8; i++) {
d = 0;
for (; d < 10; d++)
  printf("%d\n", a[i][d]);
  }
  return 0;
}
$

[Bug tree-optimization/81739] New: Replace calls to memcmp with more efficient code if possible

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

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

Bug ID: 81739
   Summary: Replace calls to memcmp with more efficient code if
possible
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

In our app we had function which was comparing two uint64 values using memcmp.
As it turned out, it was taking a lot of time. After some googling we found
this link:
https://stackoverflow.com/questions/10996418/efficient-integer-compare-function
After fixing our code using this approach it started working much faster.
Please implement such optimization in gcc itself. I found that it already
optimizes some calls to memcpy, it could do the same with memcmp too.

Code:

#include 
#include 

int cmp1(uint64_t a, uint64_t b)
{
return memcmp(, , sizeof(uint64_t));
}

int cmp2(uint64_t a, uint64_t b)
{
return a < b ? -1 : (a > b);
}

[Bug target/81664] __attribute__((target("movbe"))) does not work

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

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

Daniel Fruzynski  changed:

   What|Removed |Added

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

--- Comment #5 from Daniel Fruzynski  ---
OK, you are right. I assumed that movbe instruction can work on registers.
After compiling your code movbe was generated. I also was mislead by your first
response, I thought that you are talking about movbe instruction support in
general, not about target attribute. So I am closing this issue.

[Bug testsuite/81731] FAIL: gcc.dg/torture/pr78218.c: Call has wrong number of arguments

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #3 from Tom de Vries  ---
Patch for test-case committed.

Marking resolved-fixed.

[Bug testsuite/81731] FAIL: gcc.dg/torture/pr78218.c: Call has wrong number of arguments

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Author: vries
Date: Sun Aug  6 07:54:29 2017
New Revision: 250896

URL: https://gcc.gnu.org/viewcvs?rev=250896=gcc=rev
Log:
Fix call arguments mismatch in gcc.dg/torture/pr78218.c

2017-08-06  Tom de Vries  

PR testsuite/81731
* gcc.dg/torture/pr78218.c (struct v): New type, factored type out of
variable 'a' definition.
(b): Remove unused variable.
(gp): New variable.
(check): Add parameter corresponding to call in main, and handle.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr78218.c

[Bug sanitizer/81579] sanitizer_platform_limits_linux.cc:37:15: error: conflicting declaration ‘typedef __gid_t __kernel_gid_t’

[mfe at live dot de]

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

--- Comment #2 from martin  ---
I used the gcc-7.1.0.tar.gz tarball from the gnu download section

[Bug tree-optimization/81738] gcc.dg/vect/vect-alias-check-6.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/81738] New: gcc.dg/vect/vect-alias-check-6.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 81738
   Summary: gcc.dg/vect/vect-alias-check-6.c FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

Created attachment 41936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41936=edit
sparc-sun-solaris2.11 vect-alias-check-6.c.159t.vect

The new gcc.dg/vect/vect-alias-check-6.c testcase FAILs on Solaris 11/SPARC:

+FAIL: gcc.dg/vect/vect-alias-check-6.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "LOOP VECTORIZED" 2
+FAIL: gcc.dg/vect/vect-alias-check-6.c scan-tree-dump-times vect "LOOP
VECTORIZED" 2

both 32 and 64-bit.

LOOP VECTORIZED only occurs once in the dump, plus

vect-alias-check-6.c:18:3: note: not vectorized: relevant stmt not supported:
_3 = b_9(D)->x[_2];

Dump attached for reference.

According to gcc-testresults the test also FAILs on
powerpc64-unknown-linux-gnu.

  Rainer

[Bug middle-end/81737] [8 Regression] 164.gzip in SPEC CPU 2000 failed to build

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-06
 CC||trippels at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
extern int a[];
void fn1() { (a + 0)[1]; }

[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
(In reply to Eric Gallager from comment #6)
> 
> Can I change the status to SUSPENDED or assign them to you instead? I'm not
> so much trying to reduce the number of open PRs as I am trying to just move
> them out of the WAITING queue. https://gcc.gnu.org/bugs/management.html says
> bugs are only ever supposed to stay in the WAITING state for 3 months, after
> all.

Whatever, as long as it stays open.