[Bug target/69639] [6/7/8 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c

2017-08-05 Thread nightstrike at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69639

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #9 from nightstrike  ---
This affects 8-trunk on x86_64 cygwin, as well.  The default size of the stack
for cc1 is:

$ peflags -x /tmp/b2/gcc/cc1.exe
/tmp/b2/gcc/cc1.exe: stack reserve size  : 12582912 (0xc0) bytes


Setting it to 0xd0 and 0xe0 also fail.  Setting it to 0xf0 works. 
I didn't go further than that to see where between 14 and 15 megs it starts
working.

Can we just boost the default stack size of cc1.exe by a couple megs for
affected hosts?

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

2017-08-05 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81737

Bug ID: 81737
   Summary: [8 Regression] 164.gzip in SPEC CPU 2000 failed to
build
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: polacek at redhat dot com
  Target Milestone: ---

On x86-64, r81695 caused 164.gzip in SPEC CPU 2000 failed to build:

[hjl@gnu-35 0001]$ /export/gnu/import/git/gcc-test-spec/usr/bin/gcc -c -o
/tmp/zip.o   -DSPEC_CPU2000_LP64 -O2 -ffast-math   unzip.c
In file included from unzip.c:21:0:
unzip.c: In function \u2018unzip\u2019:
gzip.h:253:30: internal compiler error: Segmentation fault
 #define SH(p) ((ush)(uch)((p)[0]) | ((ush)(uch)((p)[1]) << 8))
  ^~~~
gzip.h:254:22: note: in expansion of macro \u2018SH\u2019
 #define LG(p) ((ulg)(SH(p)) | ((ulg)(SH((p)+2)) << 16))
  ^~
unzip.c:113:13: note: in expansion of macro \u2018LG\u2019
  orig_crc = LG(inbuf + LOCCRC);
 ^~
0xd028cf crash_signal
../../src-trunk/gcc/toplev.c:339
0x85f140 tree_check5(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code, tree_code)
../../src-trunk/gcc/tree.h:3164
0xa6b783 fold_indirect_ref_1(unsigned int, tree_node*, tree_node*)
../../src-trunk/gcc/fold-const.c:14110
0xa873fb fold_indirect_ref_loc(unsigned int, tree_node*)
../../src-trunk/gcc/fold-const.c:14171
0xad4821 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:11433
0xad37a4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:11422
0xad3427 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:12049
0xad37a4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:11422
0xad3427 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:12049
0xae357d gimplify_modify_expr
../../src-trunk/gcc/gimplify.c:5510
0xad4afa gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:11320
0xad7c28 gimplify_stmt(tree_node**, gimple**)
../../src-trunk/gcc/gimplify.c:6542
0xad546b gimplify_statement_list
../../src-trunk/gcc/gimplify.c:1732
0xad546b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:11748
0xad7c28 gimplify_stmt(tree_node**, gimple**)
../../src-trunk/gcc/gimplify.c:6542
0xadbd6a gimplify_cond_expr
../../src-trunk/gcc/gimplify.c:4016
0xad4aa8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:11277
0xad7c28 gimplify_stmt(tree_node**, gimple**)
../../src-trunk/gcc/gimplify.c:6542
0xadbd6a gimplify_cond_expr
../../src-trunk/gcc/gimplify.c:4016
0xad4aa8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src-trunk/gcc/gimplify.c:11277
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-35 0001]$

[Bug target/81736] New: Unnecessary save and restore frame pointer with -fno-omit-frame-pointer

2017-08-05 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81736

Bug ID: 81736
   Summary: Unnecessary save and restore frame pointer with
-fno-omit-frame-pointer
   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-64

[hjl@gnu-4 tmp]$ cat y.i
extern int i;

int foo (void)
{
return i;
}

[hjl@gnu-4 tmp]$ gcc -S -O3 y.i -fno-omit-frame-pointer
[hjl@gnu-4 tmp]$ cat y.s
.file   "y.i"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movli(%rip), %eax
movq%rsp, %rbp
.cfi_def_cfa_register 6
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo

There is no need to save and restore frame pointer since stack is untouched.

[Bug fortran/81735] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable

2017-08-05 Thread flashmozzg at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735

--- Comment #2 from Danila  ---
Created attachment 41935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41935=edit
full error/stacktrace

[Bug fortran/81735] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable

2017-08-05 Thread flashmozzg at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735

--- Comment #1 from Danila  ---
Created attachment 41934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41934=edit
code to reproduce this issue

[Bug fortran/81735] New: double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable

2017-08-05 Thread flashmozzg at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735

Bug ID: 81735
   Summary: double free or corruption (fasttop) error (SIGABRT)
with character(:) and custom return type with
allocatable
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: flashmozzg at gmail dot com
  Target Milestone: ---

This error appears at least starting from gfortran 5.4.0 and is present in
gfortran 7.1.0.
I've tested on Ubuntu 16.04. I've also tested on Win10 x64 with gfortran
bundled with MinGW (from Qt installation) with versions 4.9.2 and 5.3.0 and
couldn't reproduce it there.
I compiled using gfortran -std=f2008 -ffree-form -g -Wall -o foo.f95

I've managed to reduce the program to this small sample:

program fooprog
implicit none
type FooType
integer, allocatable :: x
end type FooType

type(FooType), pointer :: bar

bar => foo()

contains
function foo() result(res)
type(FooType), pointer :: res

character(:), allocatable :: rt
rt = ""
res => null()
end function foo
end program fooprog

Compiling and running it results in a SIGABRT with

*** Error in `./foo': double free or corruption (fasttop): 0x01cff0a0
***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fb43f10d7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fb43f11637a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fb43f11a53c]
./foo[0x4008a0]
./foo[0x4008be]
./foo[0x4008f8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fb43f0b6830]
./foo[0x400719]
... etc

Important: if I comment rt = "". the problem doesn't occur.
If res has a basic type, the problem doesn't occur.
If x in FooType is not marked allocatable, the problem doesn't occur.

[Bug middle-end/81734] [7/8 Regression] reference to inline function not emitted with -Os

2017-08-05 Thread doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81734

--- Comment #2 from Matthias Klose  ---
but shouldn't these the same with different optimization levels?

[Bug middle-end/81734] [7/8 Regression] reference to inline function not emitted with -Os

2017-08-05 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81734

--- Comment #1 from Andrew Pinski  ---
Hmm. I don't remember the c11 semantics when it comes to plain inline. This
might not be a bug ...

[Bug middle-end/81734] New: [7/8 Regression] reference to inline function not emitted with -Os

2017-08-05 Thread doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81734

Bug ID: 81734
   Summary: [7/8 Regression] reference to inline function not
emitted with -Os
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/853613]

seen with the gcc-7-branch 

$ cat test4.c
int a;

inline void
builddircommand(void)
{
a++;
}

void test(void)
{
builddircommand();
}

int main() {return 0;}

$ gcc-6 -O2 -Wall test4.c
$ gcc-6 -Os -Wall test4.c
$ gcc-7 -O2 -Wall test4.c
$ gcc-7 -Os -Wall test4.c
/tmp/ccRQcwvp.o: In function `test':
test4.c:(.text+0x1): undefined reference to `builddircommand'
collect2: error: ld returned 1 exit status

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

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81731

--- Comment #1 from Tom de Vries  ---
Created attachment 41933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41933=edit
tentative patch

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

2017-08-05 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81579

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build

--- Comment #1 from Andrew Pinski  ---
Have you reported this upstream or tried GCC 7.1.0?

[Bug fortran/81296] derived type I/o problem

2017-08-05 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81296

--- Comment #3 from Jerry DeLisle  ---
OK, with the alternate form of the format (aka format statement) the frontend
is not building the correct calls to the user defined procedure.

  {
struct __st_parameter_dt dt_parm.9;

dt_parm.9.common.filename = &"pr81296.f03"[1]{lb: 1 sz: 1};
dt_parm.9.common.line = 56;
dt_parm.9.format = &"( DT (20,3) )"[1]{lb: 1 sz: 1};
dt_parm.9.format_len = 13;
dt_parm.9.common.flags = 67112960;
dt_parm.9.common.unit = 6;
_gfortran_st_write (_parm.9);
{
  struct __class_dtio_01_module_Person_t class.10;

  class.10._vptr = (struct __vtype_dtio_01_module_Person * {ref-all})
&__vtab_dtio_01_module_Person;
  class.10._data = _01;
  _gfortran_transfer_derived (_parm.9, , pwf);
}
_gfortran_st_write_done (_parm.9);
  }
  {
struct __st_parameter_dt dt_parm.11;

dt_parm.11.common.filename = &"pr81296.f03"[1]{lb: 1 sz: 1};
dt_parm.11.common.line = 58;
dt_parm.11.format = &"( DT(15,3) )"[1]{lb: 1 sz: 1};
dt_parm.11.format_len = 12;
dt_parm.11.common.flags = 4096;
dt_parm.11.common.unit = 6;
_gfortran_st_write (_parm.11);
{
  struct person * D.3598;

  D.3598 = _01;
  _gfortran_transfer_character_write (_parm.11, >name, 40);
  _gfortran_transfer_integer_write (_parm.11, >age, 4);
}
_gfortran_st_write_done (_parm.11);
  }

[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

2017-08-05 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653

--- Comment #8 from Andrew Pinski  ---
If anything it should be the linker which should error out.  The linker is part
of binutils, report it to them.

[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

2017-08-05 Thread bruno at clisp dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653

--- Comment #7 from Bruno Haible  ---
And what do you think about the fact that it produces crashing code without any
warning?

Is there a chance that 'as' could emit a warning when it produces
R_SPARC_GOT22/R_SPARC_GOT10 relocations instead of the intended
R_SPARC_HI22/R_SPARC_LO10 relocations?

[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

2017-08-05 Thread bruno at clisp dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653

--- Comment #6 from Bruno Haible  ---
> passing -fno-pie seems to be the agreed upon way out here.

My assembly code is located in a library (think at libffcall, libffi, gmp,
...).
Therefore I don't control the final linker options.

So, the only available option the '#ifdef __PIC__' solution from comment 2.

[Bug c++/81634] Some types are incorrectly detected as not standard layout

2017-08-05 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81634

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This has already been fixed

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

[Bug c++/80605] [7/8 Regression] Bad is_standard_layout result with empty base classes

2017-08-05 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80605

Jonathan Wakely  changed:

   What|Removed |Added

 CC||raskolnikov at gnu dot org

--- Comment #12 from Jonathan Wakely  ---
*** Bug 81634 has been marked as a duplicate of this bug. ***

[Bug target/81732] Error: Architecture mismatch on "rd".

2017-08-05 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81732

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
 Target||sparc-linux-gnu
  Component|other   |target

--- Comment #1 from Andrew Pinski  ---
You can use --disable-libcilkrts .

[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

2017-08-05 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Eric Botcazou  ---
OK, thanks, so passing -fno-pie seems to be the agreed upon way out here.

[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

2017-08-05 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653

--- Comment #4 from Jakub Jelinek  ---
Obviously, if you are compiling hand written assembly and linking it into PIEs
the code must be PIC.  So what is written in #c2 is not a workaround, but the
right fix.  If you have assembly that is not PIC compatible and you don't want
to link it into a PIE, either don't configure the compiler with
--enable-default-pie, or compile it with -fno-pie and link with -no-pie.
This isn't any different from any other arch; if you link in non-PIC assembly
into PIEs, either stuff doesn't link, or you get text relocations.

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

2017-08-05 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/81733] New: stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

2017-08-05 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733

Bug ID: 81733
   Summary: stage1 libgcc_s.dylib fails to link on Darwin
11/x86_64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: iains at gcc dot gnu.org, mrs at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-apple-darwin11.4.2

Created attachment 41932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41932=edit
hack to allow the build to finish

Since roughly 20170707, Darwin 11/x86_64 bootstrap is broken.  The stage1
libgcc_s.dylib fails to link with and ld64 assertion failure:

Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-128.2/src/ld/parsers/macho_relocatable_file.cpp,
line 1519.
0  0x10443f1df  __assert_rtn + 79
1  0x10445aae5 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 917
2  0x10444832e  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, unsigned int,
mach_o::relocatable::ParserOptions const&) + 286
3  0x10b2b  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, unsigned int, mach_o::relocatable::ParserOptions
const&) + 91
4  0x10447d6fd  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 653
5  0x10447ecfb  ld::tool::InputFiles::InputFiles(Options&, char const**) + 651
6  0x10443f426  main + 358
7  0x10442f6a4  start + 52
collect2: error: ld returned 1 exit status
make[3]: *** [libgcc_s.dylib] Error 1
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2

The failure is similar to the one from PR target/57438.

When I check the input objects with dwarfdump --eh-frame --verify, I find

2 errors found in EH frame for _addvsi3_s.o (x86_64).
2 errors found in EH frame for _subvsi3_s.o (x86_64).
2 errors found in EH frame for _mulvsi3_s.o (x86_64).
2 errors found in EH frame for _negvsi2_s.o (x86_64).
1 errors found in EH frame for _negvdi2_s.o (x86_64).
1 errors found in EH frame for enable-execute-stack_s.o (x86_64).
10 errors found in EH frame for unwind-dw2_s.o (x86_64).
2 errors found in EH frame for emutls_s.o (x86_64)

Looking at the enable-execute-stack_s.o case, I find:

--
 File: enable-execute-stack_s.o (x86_64)
--
Verifying EH Frame... error: FDE row for address 0xfffb is not in
the FDE address range.

0x0048: FDE
length: 0x0024
   CIE_pointer: 0x
start_addr: 0x005d ___cold_sect_of___enable_execute_stack
range_size: 0x0005 (end_addr = 0x0062)
  Instructions: 0x005d: CFA=rsp+8 rip=[rsp]
DW_CFA_set_loc (0xff9e)
DW_CFA_def_cfa_offset (16)
DW_CFA_offset (rbx, -16)
DW_CFA_nop
DW_CFA_nop
0xfffb: CFA=rsp+16rbx=[rsp]  rip=[rsp+8]



1 errors found in EH frame for enable-execute-stack_s.o (x86_64).

When I compile the corresponding source with -fno-reorder-blocks-and-partition,
the dwarfdump error is gone.

The attached hack allows the build to finish.

  Rainer

[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

2017-08-05 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-05
 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Jakub, you're probably the only one with enough expertise in this area to give
an informed opinion.  What do you think?  How does that work for other targets?

[Bug lto/81686] LTO hardcodes identity host to target charset mapping

2017-08-05 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81686

--- Comment #4 from Eric Botcazou  ---
> I'm quite sure Ada has a way to change the charsets as well?

Probably, although I'm far from being an expert in this area.  But I'm not sure
if this really matters, it's probably entirely handled in the Ada front-end.

[Bug other/81732] New: Error: Architecture mismatch on "rd".

2017-08-05 Thread mfe at live dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81732

Bug ID: 81732
   Summary: Error: Architecture mismatch on "rd".
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mfe at live dot de
  Target Milestone: ---

the exact version of GCC:
gcc-7.1.0

the system type:
NetgearReadyNAS Duo
(http://wiki.dietpc.org/index.php/DIET-PC_on_SPARC_ReadyNAS)

the options given when GCC was configured/built:
gcc-7.1.0-compiled# ../gcc-7.1.0/configure CC=/opt/gcc-4.6/bin/gcc
CXX=/opt/gcc-4.6/bin/g++ --enable-languages=c,c++ --prefix=/opt/gcc-7.1 
--with-cpu=v7 --with-mpc=/usr/local  --with-mpfr=/usr/local
--with-gmp=/usr/local --with-isl=/usr/local/ --disable-libstdcxx-pch
--disable-linux-futex --disable-libsanitizer --enable-__cxa_atexit
--with-system-zlib --enable-nls --enable-clocale=gnu --enable-debug 
--disable-doc

the compiler output (error messages, warnings, etc.);
[...]
/../../gcc-7.1.0/libcilkrts/runtime/config/sparc/os-unix-sysdep.c  -fPIC -DPIC
-o .libs/os-unix-sysdep.o
/tmp/ccmVqkfg.s: Assembler messages:
/tmp/ccmVqkfg.s:15: Error: Architecture mismatch on "rd".
/tmp/ccmVqkfg.s:15:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)
/tmp/ccmVqkfg.s:16: Error: Architecture mismatch on "srlx".
/tmp/ccmVqkfg.s:16:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)
/tmp/ccmVqkfg.s:34: Error: Architecture mismatch on "rd".
/tmp/ccmVqkfg.s:34:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)
/tmp/ccmVqkfg.s:37: Error: Architecture mismatch on "rd".
/tmp/ccmVqkfg.s:37:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)
/tmp/ccmVqkfg.s:40: Error: Architecture mismatch on "rd".
/tmp/ccmVqkfg.s:40:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)
/tmp/ccmVqkfg.s:43: Error: Architecture mismatch on "rd".
/tmp/ccmVqkfg.s:43:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)
make[2]: *** [Makefile:684: os-unix-sysdep.lo] Error 1
make[2]: Leaving directory
'/c/media/gcc-7.1.0-compiled/sparc-unknown-linux-gnu/libcilkrts'
make[1]: *** [Makefile:15512: all-target-libcilkrts] Error 2
make[1]: Leaving directory '/c/media/gcc-7.1.0-compiled'

Is there a way to disable "libcilkrts" ?

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

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81731

Bug ID: 81731
   Summary: FAIL: gcc.dg/torture/pr78218.c: Call has wrong number
of arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
ptxas /tmp/cc3yCTB1.o, line 53; error   : Call has wrong number of parameters^M
ptxas fatal   : Ptx assembly aborted due to errors^M
nvptx-as: ptxas returned 255 exit status^M
compiler exited with status 1
output is:
ptxas /tmp/cc3yCTB1.o, line 53; error   : Call has wrong number of parameters^M
ptxas fatal   : Ptx assembly aborted due to errors^M
nvptx-as: ptxas returned 255 exit status^M

FAIL: gcc.dg/torture/pr78218.c   -O0  (test for excess errors)
...

The test-case has call:
...
  check (a);
...
to:
...
void __attribute__((noinline,noclone))
check ()
...

[Bug target/81730] New: nvptx and finstrument-functions

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81730

Bug ID: 81730
   Summary: nvptx and finstrument-functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Test-case pr78333.c fails to compile, presumable due to -finstrument-functions
...
build-gcc/gcc/xgcc -Bbuild-gcc/gcc/ gcc/testsuite/gcc.dg/pr78333.c
-fno-diagnostics-show-caret -fdiagnostics-color=never
--sysroot=/home/vries/nvptx/mainkernel-2/install/nvptx-none
-finstrument-functions -isystem build-gcc/nvptx-none/./newlib/targ-include
-isystem newlib/libc/include -B build-gcc/nvptx-none/./newlib/
-Lbuild-gcc/nvptx-none/./newlib -mmainkernel -lm -o pr78333.exe^M
ptxas /tmp/ccAiDqeJ.o, line 62; error   : State space mismatch between
instruction and address in instruction 'ld'^M
ptxas /tmp/ccAiDqeJ.o, line 74; error   : State space mismatch between
instruction and address in instruction 'ld'^M
ptxas /tmp/ccAiDqeJ.o, line 62; error   : Unknown symbol '%frame'^M
ptxas /tmp/ccAiDqeJ.o, line 62; error   : Label expected for forward reference
of '%frame'^M
ptxas /tmp/ccAiDqeJ.o, line 74; error   : Unknown symbol '%frame'^M
ptxas /tmp/ccAiDqeJ.o, line 74; error   : Label expected for forward reference
of '%frame'^M
ptxas fatal   : Ptx assembly aborted due to errors^M
nvptx-as: ptxas returned 255 exit status^M
compiler exited with status 1
output is:
ptxas /tmp/ccAiDqeJ.o, line 62; error   : State space mismatch between
instruction and address in instruction 'ld'^M
ptxas /tmp/ccAiDqeJ.o, line 74; error   : State space mismatch between
instruction and address in instruction 'ld'^M
ptxas /tmp/ccAiDqeJ.o, line 62; error   : Unknown symbol '%frame'^M
ptxas /tmp/ccAiDqeJ.o, line 62; error   : Label expected for forward reference
of '%frame'^M
ptxas /tmp/ccAiDqeJ.o, line 74; error   : Unknown symbol '%frame'^M
ptxas /tmp/ccAiDqeJ.o, line 74; error   : Label expected for forward reference
of '%frame'^M
ptxas fatal   : Ptx assembly aborted due to errors^M
nvptx-as: ptxas returned 255 exit status^M

FAIL: gcc.dg/pr78333.c (test for excess errors)
...

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

2017-08-05 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81723

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Could you please post the relevant information.

[Bug target/81729] New: [nvptx] Invalid initial value expression

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81729

Bug ID: 81729
   Summary: [nvptx] Invalid initial value expression
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

A number of test-cases fails with 'nvptx-run: cuLinkAddData failed: no kernel
image is available for execution on the device (CUDA_ERROR_NO_BINARY_FOR_GPU,
209)':
...
$ grep -A1 CUDA_ERROR_NO_BINARY_FOR_GPU build-gcc/gcc/testsuite/gcc/gcc.log |
grep ^FAIL:
FAIL: gcc.c-torture/execute/921110-1.c   -O0  execution test
FAIL: gcc.c-torture/execute/921110-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/921110-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/921110-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/921110-1.c   -Os  execution test
FAIL: gcc.c-torture/execute/930608-1.c   -O0  execution test
FAIL: gcc.c-torture/execute/930608-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/930608-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/930608-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/930608-1.c   -Os  execution test
FAIL: gcc.c-torture/execute/bcp-1.c   -O0  execution test
FAIL: gcc.c-torture/execute/bcp-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/bcp-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/bcp-1.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/bcp-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/bcp-1.c   -Os  execution test
FAIL: gcc.c-torture/execute/struct-ret-1.c   -O0  execution test
FAIL: gcc.c-torture/execute/struct-ret-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/struct-ret-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/struct-ret-1.c   -Os  execution test
FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution,  -Os 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c execution,  -Os 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8f.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8f.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8f.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8f.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8f.c execution,  -Os 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8f.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c execution,  -Os 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/ieee/pr38016.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/pr38016.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/pr38016.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/pr38016.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/pr38016.c execution,  -Os 
FAIL: gcc.c-torture/execute/ieee/pr38016.c execution,  -Og -g 
FAIL: gcc.dg/c11-noreturn-2.c execution test
FAIL: gcc.dg/ipa/iinline-3.c execution test
FAIL: gcc.dg/torture/pr43879_1.c   -O0  execution test
FAIL: gcc.dg/torture/pr43879_1.c   -O1  execution test
FAIL: gcc.dg/torture/pr43879_1.c   -O2  execution test
FAIL: gcc.dg/torture/pr43879_1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr43879_1.c   -Os  execution test
FAIL: gcc.dg/torture/pr55305.c   -O0  execution test
FAIL: gcc.dg/torture/pr55305.c   -O1  execution test
FAIL: gcc.dg/torture/pr55305.c   -O2  execution test
FAIL: gcc.dg/torture/pr55305.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr55305.c   -Os  execution test
FAIL: gcc.dg/tree-ssa/20040326-2.c execution test
...

Looking in more detail at the first, it seems we're generating an Invalid
initial value expression:
...
PASS: 

[Bug target/81728] New: nvptx-run: error getting kernel result: the launch timed out and was terminated

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81728

Bug ID: 81728
   Summary: nvptx-run: error getting kernel result: the launch
timed out and was terminated
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

A test-case fails with launch timeout:
...
PASS: gcc.c-torture/execute/pr78675.c   -O1  (test for excess errors)
spawn nvptx-none-run ./pr78675.exe
nvptx-run: error getting kernel result: the launch timed out and was terminated
(CUDA_ERROR_LAUNCH_TIMEOUT, 702)
FAIL: gcc.c-torture/execute/pr78675.c   -O1  execution test
...

[Bug testsuite/81727] [nvptx] gcc.dg/graphite/{run-id-1,interchange-7}.c failure: not enough stack size

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81727

Tom de Vries  changed:

   What|Removed |Added

Summary|[nvptx] |[nvptx]
   |gcc.dg/graphite/run-id-1.c  |gcc.dg/graphite/{run-id-1,i
   |failure: not enough stack   |nterchange-7}.c failure:
   |size|not enough stack size

--- Comment #1 from Tom de Vries  ---
Same for interchange-7.c:
...
PASS: gcc.dg/graphite/interchange-7.c (test for excess errors)
spawn nvptx-none-run ./interchange-7.exe
nvptx-run: error launching kernel: invalid argument (CUDA_ERROR_INVALID_VALUE,
1)
...

[Bug testsuite/81727] New: [nvptx] gcc.dg/graphite/run-id-1.c failure: not enough stack size

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81727

Bug ID: 81727
   Summary: [nvptx] gcc.dg/graphite/run-id-1.c failure: not enough
stack size
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
PASS: gcc.dg/graphite/run-id-1.c (test for excess errors)
spawn nvptx-none-run ./run-id-1.exe^M
nvptx-run: error launching kernel: invalid argument (CUDA_ERROR_INVALID_VALUE,
1)^M
FAIL: gcc.dg/graphite/run-id-1.c execution test
...

The testcase contains a large stack variable:
...
  int x[1000][1000];
...

nvptx-none-run.exp contains:
...
set_board_info gcc,stack_size 8192
...

[Bug target/81726] New: nvptx-run: error getting kernel result: an illegal instruction was encountered

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81726

Bug ID: 81726
   Summary: nvptx-run: error getting kernel result: an illegal
instruction was encountered
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There is a number of tests that fails with 'nvptx-run: error getting kernel
result: an illegal instruction was encountered (CUDA_ERROR_ILLEGAL_INSTRUCTION,
715)':
...
$ grep -A1 'an illegal instruction' build-gcc/gcc/testsuite/gcc/gcc.log  | grep
^FAIL:
FAIL: gcc.c-torture/execute/strct-stdarg-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/scalar-return-4 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/struct-by-value-11 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: gcc.dg/pr66444.c execution test
FAIL: gcc.dg/sibcall-10.c execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-15.c   -O0  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-15.c   -O0  execution test
FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test
...

[Bug target/81725] New: nvptx -run: error getting kernel result: an illegal memory access was encountered

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81725

Bug ID: 81725
   Summary: nvptx -run: error getting kernel result: an illegal
memory access was encountered
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There is a number of tests that fails with 'nvptx-run: error getting kernel
result: an illegal memory access was encountered (CUDA_ERROR_ILLEGAL_ADDRESS,
700)':
...
$ grep -A1 'an illegal memory' build-gcc/gcc/testsuite/gcc/gcc.log  | grep
^FAIL:
FAIL: gcc.c-torture/execute/builtins/pr22237.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
FAIL: gcc.c-torture/execute/20071029-1.c   -O0  execution test
FAIL: gcc.c-torture/execute/20071029-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/20071029-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/20071029-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/20071029-1.c   -Os  execution test
FAIL: gcc.c-torture/execute/memcpy-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/memcpy-2.c   -O1  execution test
FAIL: gcc.c-torture/execute/memcpy-2.c   -O2  execution test
FAIL: gcc.c-torture/execute/memcpy-2.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/memcpy-2.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr55875.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr55875.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr55875.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr55875.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr55875.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr55875.c   -Os  execution test
FAIL: gcc.c-torture/execute/strcpy-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/strcpy-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/strcpy-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/strcpy-1.c   -Os  execution test
FAIL: gcc.dg/torture/pr35634.c   -O0  execution test
FAIL: gcc.dg/torture/pr56443.c   -Os  execution test
...

[Bug middle-end/81724] New: ICE in expand_stack_vars

2017-08-05 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81724

Bug ID: 81724
   Summary: ICE in expand_stack_vars
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

For nvptx, we see this ICE:
...
FAIL: gcc.dg/memcmp-1.c (internal compiler error)
...

In more detail:
...
during RTL pass: expand
gcc/testsuite/gcc.dg/strcmp-1.c: In function 'test_strcmp_3_1':
gcc/testsuite/gcc.dg/strcmp-1.c:13:13: internal compiler error: RTL check:
expected code 'const_int', have 'reg' in expand_stack_vars, at cfgexpand.c:1186
/home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/strcmp-1.c:331:1:
note: in expansion of macro 'DEF_TEST'
0x54f895 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)^M
gcc/rtl.c:829
0x6ea5e9 expand_stack_vars
gcc/cfgexpand.c:1186
0x6fa3d3 expand_used_vars
gcc/cfgexpand.c:2241
0x6fbee2 execute
gcc/cfgexpand.c:6230
...

The relevant part in expand_stack_vars is this:
...
  /* If there were any variables requiring "large" alignment, allocate  
 space.  */
  if (large_size > 0 && ! large_allocation_done)
{
  HOST_WIDE_INT loffset;
  rtx large_allocsize;

  large_allocsize = GEN_INT (large_size);
  get_dynamic_stack_size (_allocsize, 0, large_align, NULL);
  loffset = alloc_stack_frame_space
(INTVAL (large_allocsize),
 PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT);
  large_base = get_dynamic_stack_base (loffset, large_align);
  large_allocation_done = true;
}
  gcc_assert (large_base != NULL);
...

The ICE happens because get_dynamic_stack_size returns a reg in
large_allocsize: 
...
(gdb) 
#6  0x006ea5ea in expand_stack_vars (pred=pred@entry=0x0,
data=data@entry=0x7fffd440) at
/home/vries/nvptx/mainkernel-2/source-gcc/gcc/cfgexpand.c:1186
1186(INTVAL (large_allocsize),
(gdb) call debug_rtx (large_allocsize)
(reg:DI 61)
...
while INTVAL (large_allocsize) expects an constant int.

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

2017-08-05 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81705

--- Comment #8 from rguenther at suse dot de  ---
On August 5, 2017 12:01:06 AM GMT+02:00, babokin at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81705
>
>--- Comment #7 from Dmitry Babokin  ---
>That's an excellent new! This means UBSAN becomes finally fully
>functional in
>GCC. No known false positives anymore (on quite large test base). Great
>job and
>thank you!

Thank you for reporting the issues!