[Bug middle-end/92096] [10 Regression] segmentation fault in 'example_labels' building gcc trunk on cygwin

[rogero at howzatt dot demon.co.uk]

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

--- Comment #5 from Roger Orr  ---
Hello Jakub, I've checked; I no longer see this fault.

[Bug lto/89358] [8 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

[rogero at howzatt dot demon.co.uk]

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

--- Comment #23 from Roger Orr  ---
That's good to hear -- thank you very much!

[Bug c/92096] segmentation fault in 'example_labels' building gcc trunk on cygwin

[rogero at howzatt dot demon.co.uk]

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

--- Comment #3 from Roger Orr  ---
A binary chop shows the fault starts with r276878.

[Bug c/92096] segmentation fault in 'example_labels' building gcc trunk on cygwin

[rogero at howzatt dot demon.co.uk]

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

--- Comment #2 from Roger Orr  ---
Hello Richard,
PR92037 appears to be resolved in revision 276804, which precedes the first of
my failing revisions (276902).
FWIW it was still failing last night with 276968

[Bug c/92096] New: segmentation fault in 'example_labels' building gcc trunk on cygwin

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 92096
   Summary: segmentation fault in 'example_labels' building gcc
trunk on cygwin
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

I using this invocation:

../gcc-trunk/configure --disable-bootstrap --enable-languages=c,c++
--enable-threads=posix --prefix=/usr/share/gcc-trunk

make then fails with:
...
In function ‘example_labels’:
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [../../gcc-trunk/gcc/c/Make-lang.in:124: s-selftest-c] Error 1
make[2]: *** Waiting for unfinished jobs
...

If I drill down:
$ cd gcc
$ make selftest
./xgcc -B./ -B/usr/share/gcc-trunk/x86_64-pc-cygwin/bin/ -isystem
/usr/share/gcc-trunk/x86_64-pc-cygwin/include -isystem
/usr/share/gcc-trunk/x86_64-pc-cygwin/sys-include
-L/cygdrive/c/Projects/gcc/build/gcc/../ld -xc -nostdinc /dev/null -S -o
/dev/null -fself-test=../../gcc-trunk/gcc/testsuite/selftests
In function ‘example_labels’:
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [../../gcc-trunk/gcc/c/Make-lang.in:124: s-selftest-c] Error 1

Last clean build was svn revision 276847
First seg fault was svn revision 276902

[Bug c++/68957] Wrong overload resolution for unscoped enums with fixed underlying type

[rogero at howzatt dot demon.co.uk]

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

--- Comment #3 from Roger Orr  ---
Thanks Jon.

[Bug c++/68957] Wrong overload resolution for unscoped enums with fixed underlying type

[rogero at howzatt dot demon.co.uk]

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

Roger Orr  changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #1 from Roger Orr  ---
This is still open with gcc 9.0...looks like it's stalled?

[Bug lto/89358] New: Combining -std=c++14 and -std=c++17 objects gives ODR warnings

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 89358
   Summary: Combining -std=c++14 and -std=c++17 objects gives ODR
warnings
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When object modules compiled with -std=c+14 and -std=c++17 are linked together
with -flto there can be warnings about ODR violations in standard library
headers

Example:
-- main.cpp --
#include 

extern void test();

int main()
{
std::map m;
test();
}
-- test.cpp --
#include 

void test()
{
std::map m;
}
-- ends --

g++ -flto -std=c++17 -c main.cpp
g++ -flto -std=c++14 -c test.cpp
g++ -flto main.o test.o

-- output --

/usr/share/gcc-trunk/include/c++/9.0.0/bits/stl_function.h:381:12: note: type
'struct less' itself violates the C++ One Definition Rule
  381 | struct less : public binary_function<_Tp, _Tp, bool>
  |^
/usr/share/gcc-trunk/include/c++/9.0.0/bits/stl_tree.h:684:9: note: type
'struct _Rb_tree_impl' itself violates the C++ One Definition Rule
  684 |  struct _Rb_tree_impl
  | ^
/usr/share/gcc-trunk/include/c++/9.0.0/bits/stl_map.h:100:11: note: type
'struct _Rep_type' itself violates the C++ One Definition Rule
  100 | class map
  |   ^

With gcc trunk from 2019-01-19 on Cygwin.
Almost identical messages appear on RHEL with devtools-7 and with gcc 7.30 on
WSL

[Bug c++/78948] New: constexpr if instantiating too eagerly

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 78948
   Summary: constexpr if instantiating too eagerly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

The following code fails to compile:

 CODE 
template 
void sizeof_mismatch()
{
static_assert(T == 0, "sizeof mismatch");
}

int main()
{
  if constexpr(sizeof(long long) == sizeof(char*))
;
  else
sizeof_mismatch<sizeof(long long)>();
}
 ENDS 

gcc head 2016-12-19
prog.cc: In instantiation of 'void sizeof_mismatch() [with int T = 8]':
prog.cc:12:40:   required from here
prog.cc:4:5: error: static assertion failed: sizeof mismatch
 static_assert(T == 0, "sizeof mismatch");
 ^

However the instantiation of sizeof_mismatch is not required because it is not
odr-used (6.4.1p2 [stmt.if] it is a 'discarded statement')

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[rogero at howzatt dot demon.co.uk]

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

--- Comment #14 from Roger Orr  ---
Confirmed: valgrind now builds successfully with revision 236769.

[Bug tree-optimization/71252] [7 Regression] ICE: verify_ssa failed : definition in block 7 does not dominate use in block 6

[rogero at howzatt dot demon.co.uk]

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

--- Comment #15 from Roger Orr  ---
Sorry for the noise; I'd not noticed there had been a relevant commit.
I'll re-check against trunk.

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[rogero at howzatt dot demon.co.uk]

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

--- Comment #13 from Roger Orr  ---
Ok, I'll try with trunk (I'd not noticed a relevant change had already been
submitted)

[Bug tree-optimization/71252] [7 Regression] ICE: verify_ssa failed : definition in block 7 does not dominate use in block 6

[rogero at howzatt dot demon.co.uk]

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

--- Comment #13 from Roger Orr  ---
The patch sadly does not appear to fix the (very similar looking) valgrind
compilation failure I posted in pr71269.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269#c7

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[rogero at howzatt dot demon.co.uk]

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

--- Comment #7 from Roger Orr  ---
I've got a very similar problem, building valgrind with trunk revision 236644:

m_mallocfree.c: In function 'sanity_check_malloc_arena':
m_mallocfree.c:1055:13: internal compiler error: Segmentation fault
 static void sanity_check_malloc_arena ( ArenaId aid )
 ^
0xbac3df crash_signal
../../gcc/toplev.c:333
0xd46249 sort_by_operand_rank
../../gcc/tree-ssa-reassoc.c:530
0xd52d83 reassociate_bb
../../gcc/tree-ssa-reassoc.c:5268
0xd51027 reassociate_bb
../../gcc/tree-ssa-reassoc.c:5389
0xd53f7a do_reassoc
../../gcc/tree-ssa-reassoc.c:5503
0xd53f7a execute_reassoc
../../gcc/tree-ssa-reassoc.c:5590
0xd53f7a execute
../../gcc/tree-ssa-reassoc.c:5629
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I've uploaded the preprocessed input and compiler output.

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[rogero at howzatt dot demon.co.uk]

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

--- Comment #6 from Roger Orr  ---
Created attachment 38563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38563=edit
compiler invocation and output

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[rogero at howzatt dot demon.co.uk]

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

Roger Orr  changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #5 from Roger Orr  ---
Created attachment 38562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38562=edit
Preprocessed file

[Bug tree-optimization/71240] [7 Regression] ICE on valid code at -O2 and above on x86_64-linux-gnu: verify_gimple failed

[rogero at howzatt dot demon.co.uk]

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

--- Comment #11 from Roger Orr  ---
Thanks.
I can confirm this also successfully compiles the original code from which I
derived the simplified example.

[Bug c++/71240] ICE on valid code at -O2 and above on x86_64-linux-gnu: verify_gimple failed

[rogero at howzatt dot demon.co.uk]

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

--- Comment #1 from Roger Orr  ---
(The example code compiles with gcc revision 236175, dated 20160512)

[Bug c++/71240] New: ICE on valid code at -O2 and above on x86_64-linux-gnu: verify_gimple failed

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 71240
   Summary: ICE on valid code at -O2 and above on
x86_64-linux-gnu: verify_gimple failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

Created attachment 38545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38545=edit
Example code, fails with -O2

With gcc-trunk 236575 (which includes fixes for both these possibly related
PRs:
Bug 70641 - [5 Regression] ICE on valid code at -O1 and above on
x86_64-linux-gnu: verify_gimple failed
Bug 71079 - ICE on valid code at -O1 and above on x86_64-linux-gnu:
verify_gimple failed),
I am still getting an ICE for the attached code.

$ g++ -O2 verify_gimple.cxx

verify_gimple.cxx: In function 'void failure(double)':
verify_gimple.cxx:19:1: error: invalid types in nop conversion
 failure(double a)
 ^~~
unsigned int
double
bswapsrc_7 = (unsigned int) a_2(D);
verify_gimple.cxx:19:1: internal compiler error: verify_gimple failed
0xdc6d66 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5213
0xcbbbc3 execute_function_todo
../../gcc/passes.c:1964
0xcbc54b execute_todo
../../gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/rorr/git/buildkit2/build/gcc/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/rorr/git/buildkit2/build/install
--enable-cloog-backend --enable-lto --enable-languages=c,c++
--enable-libstdcxx-time --enable-gold --enable-plugins --disable-multilib
--enable-werror=no --enable-libstdcxx-dual-abi
--with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 7.0.0 20160523 (experimental) (GCC)

[Bug ipa/71015] [7 Regression] ICE in inline_small_functions, at ipa-inline.c:1881

[rogero at howzatt dot demon.co.uk]

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

Roger Orr  changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #3 from Roger Orr  ---
FWIW I'm getting a very similar problem, but at line 1882 - 1 line further on -
when compiling a different source file at -O2.

I haven't managed to reproduce a small test case yet, I can try to do so if it
would be useful and/or if the fix for this problem doesn't also resolve mine.

[Bug tree-optimization/71059] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "vn_nary_op_insert_into"

[rogero at howzatt dot demon.co.uk]

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

--- Comment #4 from Roger Orr  ---
Thanks, fixes the ICE I had.

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[rogero at howzatt dot demon.co.uk]

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

--- Comment #5 from Roger Orr  ---
Still fails with gcc 6.1

Are there any plans on how (and when) to fix this, fairly serious, fault?

[Bug sanitizer/70712] False positive from AddressSanitizer with use of 'alignas'

[rogero at howzatt dot demon.co.uk]

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

--- Comment #5 from Roger Orr  ---
Thank you.

I can confirm that the fix also resolves the original problem from which I
derived the sample program.

[Bug sanitizer/70712] New: False positive from memory sanitizer with use of 'alignas'

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 70712
   Summary: False positive from memory sanitizer with use of
'alignas'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38302=edit
Sample program demonstrating the false positive

The attached simple program generates a false positive with address sanitizer
on x86_64 Linux. The problem seems to be related to the alignas attribute on
the 'owner' object.

$ g++ -v 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/reactor-buildkit/B2BH-BK2GIT44-2/gcc/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/data/bamboo.agent.home/xml-data/build-dir/B2BH-BKC0-JOB1/build/install
--enable-cloog-backend --enable-lto --enable-languages=c,c++
--enable-libstdcxx-time --enable-gold --enable-plugins --disable-multilib
--enable-werror=no --enable-libstdcxx-dual-abi
--with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 6.0.0 20160413 (experimental) (GCC)

$ g++ -fsanitize=address stack-buffer-overflow.cxx && ./a.out
=
==12917==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffc5bb30020 at pc 0x7f1fede0851c bp 0x7ffc5bb2ff50 sp 0x7ffc5bb2f700
WRITE of size 8 at 0x7ffc5bb30020 thread T0
#0 0x7f1fede0851b in __interceptor_memset
../../../../libsanitizer/asan/asan_interceptors.cc:451
#1 0x4009d9 in Buffer::Buffer(Owner&)
(/home/rorr/test/prX/a.out+0x4009d9)
#2 0x40089a in main (/home/rorr/test/prX/a.out+0x40089a)
#3 0x3b81a1ed5c in __libc_start_main (/lib64/libc.so.6+0x3b81a1ed5c)
#4 0x4006e8  (/home/rorr/test/prX/a.out+0x4006e8)

Address 0x7ffc5bb30020 is located in stack of thread T0 at offset 160 in frame
#0 0x4007e5 in main (/home/rorr/test/prX/a.out+0x4007e5)

  This frame has 2 object(s):
[64, 128) 'owner'
[192, 648) 'buffer' <== Memory access at offset 160 underflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
../../../../libsanitizer/asan/asan_interceptors.cc:451 in __interceptor_memset
Shadow bytes around the buggy address:
  0x1b75dfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1b75dfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1b75dfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1b75dfe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1b75dff0: f1 f1 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00
=>0x1b75e000: f2 f2 f2 f2[f2]f2 f2 f2 00 00 00 00 00 00 00 00
  0x1b75e010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1b75e020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1b75e030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1b75e040: 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x1b75e050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==12917==ABORTING

(Also fails with gcc 5.3.0)

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #60 from Roger Orr  ---
Thanks; I can now confirm that a full build of our application with distcc
works without problems.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #57 from Roger Orr  ---
Created attachment 38232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38232=edit
Stripped down intermediate file

I've managed to reproduce the problem without including any proprietary code -
code replaced with blank lines between the "#" lines (and a slight change in
the number of includes) now provokes the diagnostic.

/var/tmp/gcc-trunk-234481/install/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/cc1plus
-fpreprocessed pr69650.ii -quiet -dumpbase pr69650.ii -mtune=generic
-march=x86-64 -auxbase-strip /var/tmp/pr69650.o -O3 -Werror -std=c++14 -o
/tmp/ccNlrUZ8.s

In file included from
/opt/reactor-buildkit/B2BH-BK2GIT44-1/poco/include/Poco/Net/IPAddress.h:346:0,
 from
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/messaging/rsHintServerBase.hxx:19,
 from
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/src/rsMessaging.cxx:16:
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/hxx/rsEnumMnemonic.hxx:10:165:
error: file
"/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/messaging/rsHintServerBase.hxx"
linemarker ignored due to incorrect nesting [-Werror]
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/hxx/rsEnumMnemonic.hxx:12:154:
error: file
"/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/src/rsMessaging.cxx"
linemarker ignored due to incorrect nesting [-Werror]
cc1plus: all warnings being treated as errors

(234480 compiles cleanly)

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #55 from Roger Orr  ---
Note - I should have added that I am not at all sure the fix above is
*correct*, simply that it prevents accessing the freed entry.

I don't know enough about how the code works to know whether the value obtained
by re-loading via:

maps = LINEMAPS_LAST_ORDINARY_MAP (pfile->line_table);

is reading the the value that _actually_ needs to be verified in the subsequent
code: the logical entry referred to by "LINEMAPS_LAST_ORDINARY_MAP" might have
changed from the one obtained at the start of the function.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #54 from Roger Orr  ---
Unfortunately the patch does not help: the cached 'from' pointer is a pointer
into the old maps entry -- the one which has now been deallocated.

The first test, main_file_p, now (correctly) fails.

The second test, 

(new_file
 && from != NULL
 && filename_cmp (ORDINARY_MAP_FILE_NAME (from), new_file) != 0)

now SEGVs as the memory area 'from' refers has been freed, so
ORDINARY_MAP_FILE_NAME returns a pointer value read from this freed memory,
which now contains 0x5a.

The call stack of the re-allocation is:

#0  __memset_x86_64 () at ../sysdeps/x86_64/memset.S:1229
#1  0x00b1d595 in ggc_free (p=0x718b2000) at
../../gcc/ggc-page.c:1611
#2  0x00d5019d in ggc_realloc (x=0x718b2000, size=524288) at
../../gcc/ggc-common.c:162
#3  0x010ce764 in realloc_for_line_map (ptr=0x718b2000, len=524288)
at ../../gcc/toplev.c:939
#4  0x01b223aa in new_linemap (set=0x77ffc000, reason=LC_RENAME) at
../../libcpp/line-map.c:427
#5  0x01b2264b in linemap_add (set=0x77ffc000, reason=LC_RENAME,
sysp=2,
to_file=0x2c9ba00
"/opt/reactor-buildkit/B2BH-BK2GIT44-1/poco/include/Poco/Net/IPAddress.h",
to_line=344) at ../../libcpp/line-map.c:500
#6  0x01b22d2d in linemap_line_start (set=0x77ffc000, to_line=344,
max_column_hint=256) at ../../libcpp/line-map.c:748
#7  0x01b22f1a in linemap_position_for_column (set=0x77ffc000,
to_column=162) at ../../libcpp/line-map.c:809
#8  0x01b2066f in _cpp_lex_direct (pfile=0x2b20310) at
../../libcpp/lex.c:2730
#9  0x01b1f0f2 in _cpp_lex_token (pfile=0x2b20310) at
../../libcpp/lex.c:2202
#10 0x01b29956 in cpp_get_token_1 (pfile=0x2b20310, location=0x0) at
../../libcpp/macro.c:2439
#11 0x01b29d9b in cpp_get_token (pfile=0x2b20310) at
../../libcpp/macro.c:2581
#12 0x01b0cec6 in do_linemarker (pfile=0x2b20310) at
../../libcpp/directives.c:1009
#13 0x01b0bf65 in _cpp_handle_directive (pfile=0x2b20310, indented=0)
at ../../libcpp/directives.c:510
#14 0x01b1f142 in _cpp_lex_token (pfile=0x2b20310) at
../../libcpp/lex.c:2214
#15 0x01b29956 in cpp_get_token_1 (pfile=0x2b20310,
location=0x7fffd144) at ../../libcpp/macro.c:2439
#16 0x01b29dc0 in cpp_get_token_with_location (pfile=0x2b20310,
loc=0x7fffd144) at ../../libcpp/macro.c:2625
#17 0x00ae8d90 in c_lex_with_flags (value=0x7fffd148,
loc=0x7fffd144, cpp_flags=0x7fffd142 "@▒▒S▒\034", lex_flags=2)
at ../../gcc/c-family/c-lex.c:391
#18 0x0099 in cp_lexer_get_preprocessor_token
(lexer=0x71f2b480, token=0x7fffd140) at ../../gcc/cp/parser.c:792
#19 0x008ffcb4 in cp_lexer_new_main () at ../../gcc/cp/parser.c:656
#20 0x0090349b in cp_parser_new () at ../../gcc/cp/parser.c:3689
#21 0x00952055 in c_parse_file () at ../../gcc/cp/parser.c:37405
#22 0x00af45f8 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1064
#23 0x010cdb41 in compile_file () at ../../gcc/toplev.c:465
#24 0x010d00e9 in do_compile () at ../../gcc/toplev.c:1988
#25 0x010d036e in toplev::main (this=0x7fffd260, argc=16,
argv=0x7fffd368) at ../../gcc/toplev.c:2096
#26 0x01ae22ce in main (argc=16, argv=0x7fffd368) at
../../gcc/main.c:39

and the arguments to memset() are:
void *s = 0x718b2000
int c = 0xa5a
size_t n = 131782

In frame 12, from = 0x718d0c20, which is within this range and so the
contents are set to 0x5a.

I've tried out this patch, re-reading the potentially changed maps value from
pfile->line_table, and it seems to work for me:

*** ../../gcc-trunk-234481-original/libcpp/directives.c 2016-04-07
12:46:40.0 +0100
--- directives.c2016-04-11 11:54:18.0 +0100
*** do_linemarker (cpp_reader *pfile)
*** 1048,1053 
--- 1048,1056 

if (reason == LC_LEAVE)
  {
+   // reload map in case re-allocation has occurred
+   const line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP
(pfile->line_table);
+
const line_map_ordinary *from;
if (MAIN_FILE_P (map)
  || (new_file

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #52 from Roger Orr  ---
Ah - added print of *pfile->line_table  at line 978 and compared with the value
when we error.

978   struct line_maps *line_table = pfile->line_table;
$3702 = {info_ordinary = {maps = 0x7fffec65d000, allocated = 4096, used = 4096,
cache = 4095}, info_macro = {maps = 0x0, allocated = 0, used = 0, cache = 0},
depth = 8,
  trace_includes = false, highest_location = 511461984, highest_line =
511461856, max_column_hint = 128, reallocator = 0x25409c0
,
  round_alloc_size = 0x11bf0fa ,
location_adhoc_data_map = {htab = 0x60b0ad80, curr_loc = 4884, allocated =
8192, data = 0x7fffeb7ab000},
  builtin_location = 1, seen_line_directive = true, default_range_bits = 5,
num_optimized_ranges = 500030, num_unoptimized_ranges = 4884}

(gdb) p *pfile->line_table
$3703 = {info_ordinary = {maps = 0x7fffec993000, allocated = 16384, used =
4097, cache = 4096}, info_macro = {maps = 0x0, allocated = 0, used = 0, cache =
0}, depth = 8,
  trace_includes = false, highest_location = 511470272, highest_line =
511470272, max_column_hint = 256, reallocator = 0x25409c0
,
  round_alloc_size = 0x11bf0fa ,
location_adhoc_data_map = {htab = 0x60b0ad80, curr_loc = 4885, allocated =
8192, data = 0x7fffeb7ab000},
  builtin_location = 1, seen_line_directive = true, default_range_bits = 5,
num_optimized_ranges = 500031, num_unoptimized_ranges = 4885}


The 'mapos' address has changed and the allocated size has changed from 4096 to
16384. The 'map' variable points 0x1ffe0 bytes beyond the *old* value of maps.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #51 from Roger Orr  ---
Thanks, I hope to try that on Monday.
The function gets called multiple times, so I need to identify the last time.

The memory must have changed *during* the call to do_linemarker as the new_file
variable is set from map on line 981:

  const char *new_file = ORDINARY_MAP_FILE_NAME (map);

but the same call executed now fails:

(gdb) p ORDINARY_MAP_FILE_NAME (map)
$3 = 0xa5a5a5a5a5a5a5a5 

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #49 from Roger Orr  ---
Alas, valgrind finds nothing untoward.

make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" clean-stage1
make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" all-stage1

valgrind /var/tmp/gcc-trunk-234481/build/gcc/cc1plus -fpreprocessed direct.ii
-quiet -dumpbase direct.ii -mtune=generic -march=x86-64 -auxbase direct -O3
-Werror -std=c++14 -fmax-errors=1 -o /tmp/ccGReQOF.s

I've also tried a build with -fsanitize=address,undefined but this too reports
no problems.

Running under gdb and breaking at libcpp/directives.c:1057 I can see the
following:

(gdb) p MAIN_FILE_P(map)
$17 = true

# This is the reason why it is trying to print the message

  if (reason == LC_LEAVE)
{
  const line_map_ordinary *from;
  if (MAIN_FILE_P (map)
  || (/*...*/))
  {
cpp_warning ( // ...


(gdb) p map
$18 = (const line_map_ordinary *) 0x7fffec6ddfe0

(gdb) p *map
$19 = { = {start_location = 2779096485, reason = 165}, to_file =
0xa5a5a5a5a5a5a5a5 ,
to_line = 2779096485,
  included_from = -1515870811, sysp = 165 '▒', m_column_and_range_bits = 165,
m_range_bits = 165}

# These values look concerning ... what do they mean and where do they come
from?!

'map' comes from line 979:

const line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP (line_table);

(gdb) p line_table
$20 = (line_maps *) 0x7fffecf8b000
(gdb) p *line_table
$21 = {info_ordinary = {maps = 0x7fffec9f4000, allocated = 16384, used = 4097,
cache = 4096}, info_macro = {maps = 0x0, allocated = 0, used = 0, cache = 0},
depth = 3,
  trace_includes = false, highest_location = 485446816, highest_line =
485446816, max_column_hint = 256, reallocator = 0x25409c0
,
  round_alloc_size = 0x11bf0fa ,
location_adhoc_data_map = {htab = 0x60b0ad80, curr_loc = 4140, allocated =
8192, data = 0x7fffeb80c000},
  builtin_location = 1, seen_line_directive = true, default_range_bits = 5,
num_optimized_ranges = 486644, num_unoptimized_ranges = 4140}

This code is unknown to me, so I am not sure where to look next ...

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #47 from Roger Orr  ---
Sorry, I wasn't clear enough. I'm unfortunately not at present able to post the
whole source file.

The file I posted *only* contains the line directives, so people can confirm
whether there were any problems with them. (That file compiles fine for me too)

There seems to be some interaction with some other part of the compilation, I'm
trying to get a example I can post but this is proving troublesome.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #45 from Roger Orr  ---
While investigating the problem I am experiencing I have found it is stable
across g++ builds - I have tried a build using revision 234741 which has the
identical diagnostic output from the compilation.

However, small changes to the source code -- such as changing the length of the
directory paths involved -- can change whether or not the diagnostic is
produced.

In the example I posted, if I change path "/home/rorr/linuxdev109ws_9119/..."
to "/home/rorr/..." in the line directives of the ii file the compilation
succeeds without problem.

Hence it is not clear to me whether this diagnostic is the root problem or
merely a symptom of a different problem - possibly a memory overwrite or use of
an uninitialised variable whose value depends on the history of the memory
location.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #44 from Roger Orr  ---
Created attachment 38218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38218=edit
Intermediate file

I am as yet unable to upload the code for an example.

However, I've attached a file containing the generated line directives using

grep "#" rsMessaging.cxx.ii > lineDirectives

from one of the troublesome pre-processsed output files (rsMessaging.cxx.ii).

As far as I can tell the directives are correct.

The .ii file generates the following diagnostic when compiled:

$ /var/tmp/gcc-trunk-234481/install/bin/g++ -std=c++14 -O3 -Werror -c
rsMessaging.cxx.ii
In file included from
/opt/reactor-buildkit/B2BH-BK2GIT44-1/poco/include/Poco/Net/IPAddress.h:379:0,
 from
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/messaging/rsHintServerBase.hxx:18,
 from
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/src/rsMessaging.cxx:15:
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/hxx/rsEnumMnemonic.hxx:117:165:
error: file
"/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/messaging/rsHintServerBase.hxx"
linemarker ignored due to incorrect nesting [-Werror]

   
   
 ^
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/hxx/rsEnumMnemonic.hxx:212:154:
error: file
"/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/src/rsMessaging.cxx"
linemarker ignored due to incorrect nesting [-Werror]
cc1plus: all warnings being treated as errors

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #41 from Roger Orr  ---
I have seen the message before: for example from a build with revision 

line-map.c: file "/usr/include/asm/sockios.h" left but not entered

I've only noticed it with builds from gcc-trunk, which I tested with back in
Dec/Jan. I saw this message from some compilation but it seemed benign...

I have not seen this message with builds from gcc 5.3.0 and before, but it is
possible I've simply not noticed as it does gets a bit buried in the build
logs.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #39 from Roger Orr  ---
The resolution of this issue causes a problem for me as it results in
compilation errors in our build.

We are compiling with distcc which AIUI distributes the pre-processed
intermediate output.

With revision 234480 we get no warnings logged and clean compilation.

With revision 234481 we get a number of warnings logged - but this interacts
unfortunately with -Werror (which we also set) and so quite a number of our
compilations fail.

(I cannot as yet detect a pattern with which compilations are affected, but the
set is consistent on a rebuild.)

I can reproduce the distcc problem by using -E to generate pre-processed source
and compiling this.
Note: the pre-processed intermediate output does not change between 234480 and
234481, it's the compilation of this pre-processed output that fails.

Unfortunately the failing code is proprietary so I am not at liberty to upload
the pre-processed output, I have attempted to produce some smaller examples but
so far with no success.

Could the generation of the warning be made dependent upon a more specific
warning flag?

[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds

[rogero at howzatt dot demon.co.uk]

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

--- Comment #3 from Roger Orr  ---
Tested: bootstrap build on cygwin with your patch completed successfully.

I used:
../gcctrunk/configure --enable-languages=c,c++ --prefix=/usr/share/gcc-trunk
make -j5
make install

Thank you :-)

[Bug c++/69487] New: Unexpected VLA initialization of char[] from ""

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 69487
   Summary: Unexpected VLA initialization of char[] from ""
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

The initialization of a VLA char array from a string literal in C++ mode is
surprising: the code appears to copy a string literal starting with the NUL
character into the dynamically-sized buffer.

This is different from the (standard C/C++) treatment of the same syntax for a
fixed-size array.

--- vla-init.cxx ---
#include 
#include 
#include 
#include 

void testfixed()
{
const int size = 6;
char buffer[size] = "";
for (int i = 0; i != size; ++i)
{
printf("Fixed: buffer[%i] = %2.2x\n", i, buffer[i] & 0xff);
}
}

int size = 6;

void testvariable()
{
char buffer[size] = "";
for (int i = 0; i != size; ++i)
{
printf("Variable: buffer[%i] = %2.2x\n", i, buffer[i] & 0xff);
}
}


int main()
{
testfixed();
testvariable();
}
--- ends ---

Sample output:

Fixed: buffer[0] = 00
Fixed: buffer[1] = 00
Fixed: buffer[2] = 00
Fixed: buffer[3] = 00
Fixed: buffer[4] = 00
Fixed: buffer[5] = 00
Variable: buffer[0] =00
Variable: buffer[1] =00
Variable: buffer[2] =00
Variable: buffer[3] =00
Variable: buffer[4] =01
Variable: buffer[5] =1b

[Bug c++/69487] Unexpected VLA initialization of char[] from ""

[rogero at howzatt dot demon.co.uk]

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

--- Comment #2 from Roger Orr  ---
A braced initializer of characters appears to work consistently with both
compile time and run time arrays.

char buffer[size] = { 'a', 'b' };

produces a buffer with 'a', 'b' and zero padded whether size is a compile time
constant or a runtime value.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rogero at howzatt dot demon.co.uk]

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

--- Comment #32 from Roger Orr  ---
(In reply to Nick Clifton from comment #26)
> Hi Roger,
> 
> > I've tried the patch (applied to 232400 as trunk seems to have other
> > problems on cygwin) and the build now completes successfully.
> 
> Including libstdc++-v3 ?

Yes, the build included libstdc++-v3

...

> Oh actually - Roger - could you check one more thing for me please ?  Does
> the patched compiler compile the test case in PR 68601 correctly ?

I'm not sure how to compile the Instructions.ii -- a naive
$ /usr/share/gcc-trunk/bin/g++ -O2 -fno-inline Instructions.ii
errors with:

In file included from
c:\msys64\home\administrator\julia\usr\x86_64-w64-mingw32\sys-root\mingw\lib\gcc\x86_64-w64-mingw32\5.2.0\include\c++\utility:75:0,
 from
c:\msys64\home\administrator\julia\usr\x86_64-w64-mingw32\sys-root\mingw\lib\gcc\x86_64-w64-mingw32\5.2.0\include\c++\algorithm:60,
 from
C:/msys64/home/Administrator/julia/deps/srccache/llvm-svn/include/llvm/ADT/StringRef.h:14,
 from
C:/msys64/home/Administrator/julia/deps/srccache/llvm-svn/include/llvm/ADT/StringMap.h:17,
 from
C:/msys64/home/Administrator/julia/deps/srccache/llvm-svn/include/llvm/Support/Host.h:17,
 from
C:/msys64/home/Administrator/julia/deps/srccache/llvm-svn/include/llvm/ADT/Hashing.h:49,
 from
C:/msys64/home/Administrator/julia/deps/srccache/llvm-svn/include/llvm/ADT/ArrayRef.h:13,
 from
C:/msys64/home/Administrator/julia/deps/srccache/llvm-svn/include/llvm/IR/Instructions.h:19,
 from
C:/msys64/home/Administrator/julia/deps/srccache/llvm-svn/lib/IR/Instructions.cpp:16:
c:\msys64\home\administrator\julia\usr\x86_64-w64-mingw32\sys-root\mingw\lib\gcc\x86_64-w64-mingw32\5.2.0\include\c++\initializer_list:47:11:
fatal error: definition of std::initializer_list does not match #include

[Bug bootstrap/69506] check-in 232454 seems to cause problems with cygwin builds

[rogero at howzatt dot demon.co.uk]

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

--- Comment #1 from Roger Orr  ---
See also http://permalink.gmane.org/gmane.os.cygwin/156987

[Bug bootstrap/69506] New: check-in 232454 seems to cause problems with cygwin builds

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 69506
   Summary: check-in 232454 seems to cause problems with cygwin
builds
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

A complete build of gcc on cygwin, with change 232071 backed out (see pr66655),
works with revision 232453 but fails with revision 232454.

The stage-1 build of libstdc++-v3 fails with undefined symbols:
'_ITM_RU1'
'transaction clone for operator new[](unsigned long)'
'_ITM_memcpyRnWt'
'_ITM_RU8'

--

Using cygwin, with bison 2.7 installed:

This completes stage1, stage2 and stage3 of the build:

svn co -r 232453 svn://gcc.gnu.org/svn/gcc/trunk gcc-trunk-232453
cd gcc-trunk-232453
# see pr66655
svn up -r 232070 gcc/config/i386/cygming.h
./contrib/download_prerequisites
mkdir ../build-232453
cd ../build-232453
../gcc-trunk-232453/configure --enable-languages=c,c++
--prefix=/usr/share/gcc-trunk
make -j4

Changing the revision from 232453 to 232454 the make command fails.

Failing command:

libtool: link:  /cygdrive/c/projects/gcc/build-232454/./gcc/xgcc -shared-libgcc
-B/cygdrive/c/projects/gcc/build-232454/./gcc -nostdinc++
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/.libs
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/share/gcc-trunk-232454/x86_64-unknown-cygwin/bin/
-B/usr/share/gcc-trunk-232454/x86_64-unknown-cygwin/lib/ -isystem
/usr/share/gcc-trunk-232454/x86_64-unknown-cygwin/include -isystem
/usr/share/gcc-trunk-232454/x86_64-unknown-cygwin/sys-include-shared
-nostdlib /cygdrive/c/projects/gcc/build-232454/./gcc/crtbeginS.o 
.libs/compatibility.o .libs/compatibility-debug_list.o
.libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o
.libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o
.libs/compatibility-chrono.o .libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive 
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/.libs
-L/usr/lib/w32api -L/cygdrive/c/projects/gcc/build-232454/./gcc -L/lib/../lib
-L/usr/lib/../lib -lgcc_s -lgcc -lcygwin -ladvapi32 -lshell32 -luser32
-lkernel32 -lgcc_s -lgcc /cygdrive/c/projects/gcc/build-232454/./gcc/crtend.o 
-Wl,-O1 -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver   -o
.libs/cygstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
-Xlinker .libs/libstdc++.dll.a

Errors reported:

../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function
`_txnal_cow_string_C1_for_exceptions(void*, char const*, void*)':
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:242:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU1'
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:254:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x39):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`transaction clone for operator new[](unsigned long)'
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:273:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x5d):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_memcpyRtWn'
../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function
`txnal_read_ptr':
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:284:(.text$_Z23_txnal_cow_string_c_strPKv+0x1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:284:(.text$_Z23_txnal_sso_string_c_strPKv+0x1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:284:(.text

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rogero at howzatt dot demon.co.uk]

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

--- Comment #24 from Roger Orr  ---
Thanks Nick.

I've tried the patch (applied to 232400 as trunk seems to have other problems
on cygwin) and the build now completes successfully.

Additionally, the test case no longer crashes.

$ /usr/share/gcc-trunk/bin/g++ -O2 -fno-inline pr66655.C pr66655_1.cc
$ ./a.exe
$ /usr/share/gcc-trunk/bin/g++ -O2 -fno-inline pr66655_1.cc pr66655.C
$ ./a.exe

$ /usr/share/gcc-trunk/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/share/gcc-trunk/bin/g++
COLLECT_LTO_WRAPPER=/usr/share/gcc-trunk/libexec/gcc/x86_64-unknown-cygwin/6.0.0/lto-wrapper.exe
Target: x86_64-unknown-cygwin
Configured with: ../gcc-trunk-232400/configure --enable-languages=c,c++
--prefix=/usr/share/gcc-trunk
Thread model: single
gcc version 6.0.0 20160115 (experimental) (GCC)

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rogero at howzatt dot demon.co.uk]

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

--- Comment #18 from Roger Orr  ---
What is the correct way forward with this issue?
Should we reopen this issue, or open a fresh one? (I'm not familiar enough with
the gcc use of bugzilla to know.)

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rogero at howzatt dot demon.co.uk]

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

--- Comment #17 from Roger Orr  ---
As you say, there seems to be another, unrelated, problem with the current
trunk and cygwin.

However, I have now successfully built gcc version 232300 under cygwin with
this patch. 

Unfortunately, if I try to compile and execute the test program:

$ g++ -O2 -fno-inline pr66655.C pr66655_1.cc
$ ./a.exe

it produces a segmentation fault, just as reported with the mingw build.

So it does seem that cygwin needs the problem fixed, just like mingw, but that
the orginal fix has other, unfortunate, consequences.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rogero at howzatt dot demon.co.uk]

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

--- Comment #14 from Roger Orr  ---
I don't know I'm afraid: I'm a very occasional mingw user and I haven't
(yet...) tried building gcc on mingw...

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rogero at howzatt dot demon.co.uk]

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

Roger Orr  changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #12 from Roger Orr  ---
Alas, revision 232071 appears to break the cygwin full build of gcc.

$ cd /cygdrive/c/projects/gcc/gcctrunk
$ svn update -r 232071
$ ./contrib/download_prerequisites
$ mkdir ../build
$ cd ../build
$ ../gcctrunk/configure --enable-languages=c,c++ --prefix=/usr/share/gcctrunk
$ make -j4 2>&1 | tee /var/tmp/build.log
...
libtool: link:  /cygdrive/c/projects/gcc/build/./gcc/xgcc -shared-libgcc
-B/cygdrive/c/projects/gcc/build/./gcc -nostdinc++
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src/.libs
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/share/gcctrunk/x86_64-unknown-cygwin/bin/
-B/usr/share/gcctrunk/x86_64-unknown-cygwin/lib/ -isystem
/usr/share/gcctrunk/x86_64-unknown-cygwin/include -isystem
/usr/share/gcctrunk/x86_64-unknown-cygwin/sys-include-shared -nostdlib
/cygdrive/c/projects/gcc/build/./gcc/crtbeginS.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive 
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src/.libs
-L/usr/lib/w32api -L/cygdrive/c/projects/gcc/build/./gcc -L/lib/../lib
-L/usr/lib/../lib -lgcc_s -lgcc -lcygwin -ladvapi32 -lshell32 -luser32
-lkernel32 -lgcc_s -lgcc /cygdrive/c/projects/gcc/build/./gcc/crtend.o  -Wl,-O1
-Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver   -o
.libs/cygstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
-Xlinker .libs/libstdc++.dll.a
.libs/compatibility.o: In function `std::basic_istream<char,
std::char_traits >::ignore(long)':
/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src/../../../../gcctrunk/libstdc++-v3/src/c++98/compatibility.cc:67:
undefined reference to `std::basic_istream<char, std::char_traits
>::sentry::sentry(std::basic_istream<char, std::char_traits >&, bool)'

(many similar errors elided)...

../src/c++11/.libs/libc++11convenience.a(wstring-inst.o):/cygdrive/c/projects/gcc/gcctrunk/libstdc++-v3/include/bits/basic_string.h:196:
more undefined references to `void std::__cxx11::basic_string<wchar_t,
std::char_traits, std::allocator >::_M_construct(wchar_t const*, wchar_t const*, std::forward_iterator_tag)' follow
collect2: error: ld returned 1 exit status
Makefile:606: recipe for target 'libstdc++.la' failed
make[6]: *** [libstdc++.la] Error 1
make[6]: Leaving directory
'/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src'
Makefile:638: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
'/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src'
Makefile:507: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
'/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3'
Makefile:414: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory
'/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3'
Makefile:16346: recipe for target 'all-stage1-target-libstdc++-v3' failed
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/cygdrive/c/projects/gcc/build'
Makefile:21374: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/cygdrive/c/projects/gcc/build'
Makefile:916: recipe for target 'all' failed
make: *** [all] Error 2

[Bug sanitizer/67515] crash from ubsan for non-virtual call in initializer list with an invalid vtable

[rogero at howzatt dot demon.co.uk]

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

--- Comment #10 from Roger Orr  ---
Hello Yury, yes the problem with boost was reported as 
https://svn.boost.org/trac/boost/ticket/11632
and the ticket contains a proposed solution.

[Bug libstdc++/68982] [6 Regression] Missing explicit qualification for std::forward in functional

[rogero at howzatt dot demon.co.uk]

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

--- Comment #5 from Roger Orr  ---
Thank you ;-)

[Bug c++/69000] New: regression: internal compiler error: Segmentation fault

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 69000
   Summary: regression: internal compiler error: Segmentation
fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

Created attachment 37093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37093=edit
ice-example.cpp: Example program demonstrating the fault

I've an ICE (segfault) with gcc trunk that compiles without fault using gcc
5.3.0 and earlier.

I attach a stripped down example that fails with the same symptoms as the
original source file.


On Redhat Linux 2.6.32-573.3.1.el6.x86_64 using gcc-trunnk as at 2015-12-11:

0xcfe20f crash_signal
../../gcc/toplev.c:334
0x93ab64 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3252
0x93ab64 symbol_table::decl_assembler_name_hash(tree_node const*)
../../gcc/symtab.c:80
0x93fe20 symtab_node::get_for_asmname(tree_node const*)
../../gcc/symtab.c:924
0x93ff6d symtab_node::verify_base()
../../gcc/symtab.c:994
0x940aef symtab_node::verify()
../../gcc/symtab.c:1172
0x940bef symtab_node::verify_symtab_nodes()
../../gcc/symtab.c:1190
0x9533bb symtab_node::checking_verify_symtab_nodes()
../../gcc/cgraph.h:602
0x9533bb symbol_table::compile()
../../gcc/cgraphunit.c:2364
0x955932 symbol_table::compile()
../../gcc/cgraphunit.c:2520
0x955932 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2546

It also fails on wandbox http://melpon.org/wandbox/
using 'gcc HEAD 6.0.0 20151220' showing a slightly different call stack:

Start
prog.cc:16:1: internal compiler error: Segmentation fault
 }
 ^

0xaa1bbf crash_signal
/home/heads/gcc/gcc-source/gcc/toplev.c:334
0xccc002 make_decl_rtl(tree_node*)
/home/heads/gcc/gcc-source/gcc/varasm.c:1350
0xccf57b assemble_variable(tree_node*, int, int, int)
/home/heads/gcc/gcc-source/gcc/varasm.c:2144
0xcd3400 varpool_node::assemble_decl()
/home/heads/gcc/gcc-source/gcc/varpool.c:583
0x7af053 output_in_order
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2220
0x7af3bd symbol_table::compile()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2457
0x7b1432 symbol_table::compile()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2527
0x7b1432 symbol_table::finalize_compilation_unit()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2553
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
1
Finish

[Bug c++/69000] regression: internal compiler error: Segmentation fault

[rogero at howzatt dot demon.co.uk]

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

--- Comment #2 from Roger Orr  ---
Thanks: apologies that my bugzilla-fu failed to find the duplicate.

[Bug c++/66808] tree check fail in symbol_table::decl_assembler_name_hash

[rogero at howzatt dot demon.co.uk]

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

--- Comment #8 from Roger Orr  ---
Thank you.
I've tested the fix and it successfully compiles works both the sample program
uploaded to my duplicate pr69000 and also my original presenting case.

[Bug libstdc++/68982] New: Missing explicit qualification for std::forward in functional

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 68982
   Summary: Missing explicit qualification for std::forward in
functional
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

I notice that  is no longer consistently prefixing forward with
std:: and this means ADL gets invoked, which causes trouble when the argument
is from boost namespace and boost::forward is available.

As an example, consider libstdc++-v3/include/std/functional at r229290, line
616:

operator()(_Tp&& __obj) const
noexcept(noexcept(std::__invoke(_M_pm, forward<_Tp>(__obj
-> decltype(std::__invoke(_M_pm, std::forward<_Tp>(__obj)))
{ return std::__invoke(_M_pm, std::forward<_Tp>(__obj)); }

This can produce compiler errors when, for instance, the instantiating type _Tp
is boost::shared_ptr.

I get failures building proprietary code, have not yet produced a simple
standa-alone example.

[Bug libstdc++/68982] Missing explicit qualification for std::forward in functional

[rogero at howzatt dot demon.co.uk]

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

--- Comment #2 from Roger Orr  ---
Created attachment 37082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37082=edit
Example of failure, against code using boost 1.57.0

[Bug other/66259] Combined gcc and binutils build from git-master fails, with gas/as-new not existing

[rogero at howzatt dot demon.co.uk]

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

Roger Orr  changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #11 from Roger Orr  ---
I can confirm, as at 2015-12-11, that this is fixed in gcc-trunk.

I can complete a combined binutils + gcc build when using either of these
pairings:

gcc-trunk and binutils-2.25
gcc-5.3.0 and binutils-2.24

Both the other pairings:

gcc-trunk and binutils-2.24
gcc-5.3.0 and binutils-2.25

fail.

On examination intl/config.log contains, for example:

/var/tmp/gcc-5.3.0-binutils-2.25/build/./prev-gcc/as: line 106:
/var/tmp/gcc-5.3.0-binutils-2.25/build/./gas/as-new: No such file or directory
/var/tmp/gcc-5.3.0-binutils-2.25/build/./prev-gcc/as: line 106: exec:
/var/tmp/gcc-5.3.0-binutils-2.25/build/./gas/as-new: cannot execute: No such
file or directory

-- testing methodology ---

Execute: 

cd /var/tmp
mkdir gcc-5.3.0-binutils-2.24
cd gcc-5.3.0-binutils-2.24
tar xjf ~/zips/binutils-2.24.tar.bz2
mkdir combined
cd combined
for dir in bfd binutils gas gprof gold ld opcodes ; do ln -s
../binutils-2.24/$dir . ; done
tar xjf ~/zips/gcc-5.3.0.tar.bz2 --strip-components=1 --overwrite
./contrib/download_prerequisites
mkdir ../build
cd ../build
../combined/configure --enable-languages=c,c++ --disable-multilib
--enable-werror=no >config.log 2>&1
make -j4 MAKEINFO=true >build.log 2>&1

Repeat with 2.24 changed to 2.25. (First case succeeds, second one fails.)

Using a svn snapshot of gcc-trunk in ~/gcc-trunk-2015-12-11

Execute:

cd /var/tmp
mkdir gcc-trunk-binutils-2.24
cd gcc-trunk-binutils-2.24
tar xjf ~/zips/binutils-2.24.tar.bz2
mkdir combined
cd combined
for dir in bfd binutils gas gprof gold ld opcodes ; do ln -s
../binutils-2.24/$dir . ; done
cp -pR ~/gcc-trunk-2015-12-11/* .
./contrib/download_prerequisites
mkdir ../build
cd ../build
../combined/configure --enable-languages=c,c++ --disable-multilib
--enable-werror=no >config.log 2>&1
make -j4 MAKEINFO=true >build.log 2>&1

Repeat with 2.24 changed to 2.25. (First case fails, second one succeeds.)

[Bug sanitizer/67515] New: "invalid vptr" false positive or crash from ubsan for non-virtual call in initializer list

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 67515
   Summary: "invalid vptr" false positive or crash from ubsan for
non-virtual call in initializer list
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36312
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36312=edit
Sample program showing the false positive and the seg fault

ubsan produces a warning at runtime from the attached code and then crashes.

The crash is provoked by performing a placement new with a pre-populated
buffer, but can occur 'in the wild' depending on what the memory contents are
at runtime.

Fails with trunk (as at 2015-09-08 using http://melpon.org/wandbox/) and gcc
5.2.0

(This may possibly be related to pr67258)

[Bug sanitizer/67515] "invalid vptr" false positive or crash from ubsan for non-virtual call in initializer list

[rogero at howzatt dot demon.co.uk]

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

--- Comment #4 from Roger Orr  ---
Ah - apologies -- I'd got the example by stripping down a call in boost::format
and didn't do a full enough check that the code was well formed: I'll report
that UB to boost.

However as Markus says the seg fault remains troublesome.

[Bug lto/67357] -Wodr warnings from types in anonymous namespace

[rogero at howzatt dot demon.co.uk]

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

--- Comment #3 from Roger Orr rogero at howzatt dot demon.co.uk ---
The following code block also gives an ODR violation with the same versions of
gcc; in this case only a *single* translation unit is involved.

$ cat test.cxx
#include memory

templatetypename T
class D : public T {
using mfn_t = void (D::*)();
std::tuplemfn_t data{D::foo};
public:
void foo() {
std::get0(data);
}
};

namespace {
struct S {};
}

int main() {
DS obj;
}

$ /opt/gcc-5.2.0/bin/g++ -flto -Wodr -std=c++11 test.cxx
test.cxx:5:32: warning: type 'struct mfn_t' violates one definition rule
[-Wodr]
 using mfn_t = void (D::*)();
^
/opt/gcc-5.2.0/include/c++/5.2.0/tuple:764:21: note: a different type is
defined in another translation unit
   typedef _Head type;
 ^
test.cxx:5:32: note: the first difference of corresponding definitions is field
'__pfn'
 using mfn_t = void (D::*)();
^
test.cxx:5:32: note: a field of same name but different type is defined in
another translation unit
lto1: note: type mismatch in parameter 1
test.cxx:4:20: note: type 'struct D' defined in anonymous namespace can not
match type 'struct D'
 class D : public T {
^
test.cxx:4:7: note: the incompatible type defined in anonymous namespace in
another translation unit
 class D : public T {
   ^

(Giving the anonymous namespace a name removes the warnings.)

[Bug lto/67357] New: -Wodr warnings from types in anonymous namespace

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 67357
   Summary: -Wodr warnings from types in anonymous namespace
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

The following code generates -Wodr warnings wih gcc 5.2.0

$ cat common.hxx
template typename T
struct values{
typedef T const CT;
};

$ cat test1.cxx
#include common.hxx

extern void test2();

namespace {
struct P {
bool One;
};
}

valuesP test1;

int main() { }

$ cat test2.cxx
#include common.hxx

namespace {
struct P {
int Two;
};
}

valuesP test2;

$ /opt/gcc-5.2.0/bin/g++ -flto -Wodr test1.cxx test2.cxx
common.hxx:3:21: warning: type 'const struct CT' violates one definition rule
[-Wodr]
 typedef T const CT;
 ^
common.hxx:3:21: note: a different type is defined in another translation unit
 typedef T const CT;
 ^
test1.cxx:7:14: note: the first difference of corresponding definitions is
field 'One'
 bool One;
  ^
test2.cxx:5:13: note: a field with different name is defined in another
translation unit
 int Two;

Where

$ /opt/gcc-5.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-5.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure --prefix=/opt/gcc-5.2.0
--enable-cloog-backend --enable-lto --enable-languages=c,c++
--enable-libstdcxx-time --enable-gold --enable-plugins --disable-multilib
Thread model: posix
gcc version 5.2.0 (GCC)

Note: this maybe related to 66180 although (a) this is a gcc 5.2.0 problem and
(b) the sample code in comment 5 of that ticket does compile and link cleanly
with gcc 5.2.0

[Bug lto/67357] -Wodr warnings from types in anonymous namespace

[rogero at howzatt dot demon.co.uk]

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

--- Comment #2 from Roger Orr rogero at howzatt dot demon.co.uk ---
The fault still occurs on gcc-5-branch, does not occur on gcc trunk.

I have also found that making a small change to the example in comment 5 of PR
66180 makes that fail with gcc 5.2.0: adding const to the type used for the
unique pointers.

The modified example becomes:

$ cat foo1.cpp
#include memory
namespace {
class A {
  int i;
};
}
class G {
  std::unique_ptrconst A foo() const;
};
std::unique_ptrconst A G::foo() const { return std::make_uniqueconst A(); }

$ cat foo2.cpp
#include memory
namespace {
class A {
  bool a;
};
}
class H {
  std::unique_ptrconst A bar() const;
};
std::unique_ptrconst A H::bar() const { return std::make_uniqueconst A(); }

$ /opt/gcc-5-branch/bin/g++ -std=c++14 -flto foo1.cpp foo2.cpp
/opt/gcc-5-branch/include/c++/5.2.1/bits/unique_ptr.h:151:41: warning: type
'const struct element_type' violates one definition rule [-Wodr]
   typedef _Tp   element_type;
 ^
/opt/gcc-5-branch/include/c++/5.2.1/bits/unique_ptr.h:151:41: note: a different
type is defined in another translation unit
   typedef _Tp   element_type;
 ^
foo1.cpp:4:7: note: the first difference of corresponding definitions is field
'i'
   int i;
   ^
foo2.cpp:4:8: note: a field with different name is defined in another
translation unit
   bool a;
^
/usr/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

whereas:

$ /opt/gcc-trunk/bin/g++ -flto -std=c++14 -flto foo1.cpp foo2.cpp
/usr/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

[Bug sanitizer/66343] Error: .Lubsan_type3 already defined with UBSan and precompiled headers

[rogero at howzatt dot demon.co.uk]

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

--- Comment #1 from Roger Orr rogero at howzatt dot demon.co.uk ---
Fails for me (with a very slightly different label: Lubsan_type0) on gcc-trunk
(as of 2015-08-22) without needing the -m32:

$ /usr/share/gcc-trunk/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/share/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/usr/share/gcc-trunk/libexec/gcc/x86_64-unknown-cygwin/6.0.0/lto-wrapper.exe
Target: x86_64-unknown-cygwin
Configured with: /cygdrive/c/projects/gcc/objdir/../gcctrunk/configure
--enable-languages=c,c++ --prefix=/usr/share/gcc-trunk : (reconfigured)
../gcctrunk/configure --prefix=/usr/share/gcc-trunk/ : (reconfigured)
../gcctrunk/configure --prefix=/usr/share/gcc-trunk/ --enable-languages=c,c++
Thread model: single
gcc version 6.0.0 20150822 (experimental) (GCC)

$ /usr/share/gcc-trunk/bin/g++ -o stdc++.h.gch -x c++-header /usr/share/gcc-tru
nk/include/c++/6.0.0/x86_64-unknown-cygwin/bits/stdc++.h -fsanitize=undefined

$ /usr/share/gcc-trunk/bin/g++ -o test test.cpp -I. -include stdc++.h
 -fsanitize=undefined -Winvalid-pch   gwin
/tmp/ccJdB2eu.s: Assembler messages:
/tmp/ccJdB2eu.s:171: Error: symbol `.Lubsan_type0' is already defined

[Bug c++/65152] Several friend function definitions break lookup

[rogero at howzatt dot demon.co.uk]

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

--- Comment #3 from Roger Orr rogero at howzatt dot demon.co.uk ---
Note that this has been fixed in gcc-trunk (tested 22-Aug-2015)

[Bug c++/66364] New: poor optimization of packed structs containing bitfields

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 66364
   Summary: poor optimization of packed structs containing
bitfields
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---
Target: x86_64-redhat-linux

Created attachment 35667
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35667action=edit
Simple program demonstrating the issue

Code accessing bitfields in packed structures seem to load the value a byte at
a time and build the value up using shifts and ors even with -O3.

On x64 it could load the value using a single mov instruction as it does when
the struct is not packed or when the field is not a bitfield.

[Bug c++/64181] 'noexcept' on a lambda sometimes appears to get optimised away at -O2 (or above).

[rogero at howzatt dot demon.co.uk]

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

--- Comment #1 from Roger Orr rogero at howzatt dot demon.co.uk ---
The optimization is also broken in the 5.0 head (5.0.0.20150328)

[Bug c++/65525] [5 Regression] ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)

[rogero at howzatt dot demon.co.uk]

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

--- Comment #7 from Roger Orr rogero at howzatt dot demon.co.uk ---
Thanks!

[Bug c++/64181] New: 'noexcept' on a lambda sometimes appears to get optimised away at -O2 (or above).

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 64181
   Summary: 'noexcept' on a lambda sometimes appears to get
optimised away at -O2 (or above).
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk

Created attachment 34188
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34188action=edit
Demonstration of the problem

In some cases a program containing noexcept on a lambda allows exceptions
thrown inside the body of the lambda to propagate out of the lambda.

We have managed to simplify the problem down to a small test case (attached as
noexcept_optimisation_bug.cpp) - the issue seems to occur when the lambda is
called inside a virtual function and in turns calls a virtual function.

The example contains a 'volatile' pointer -- the original code used a shared
pointer here, it seems that you just need enough here to prevent the
optimiser remove the function completely.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[rogero at howzatt dot demon.co.uk]

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

Roger Orr rogero at howzatt dot demon.co.uk changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #13 from Roger Orr rogero at howzatt dot demon.co.uk ---
I am also affected by this problem.
What is the status of the idea Jonathan made (2013-07-02 11:26:53 UTC):

  ... and I think we can make a change for targets where we know the behaviour
is OK ...

[Bug sanitizer/63627] New: thread sanitizer does not instrument __atomic_test_and_set or __atomic_clear

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 63627
   Summary: thread sanitizer does not instrument
__atomic_test_and_set or __atomic_clear
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Created attachment 33791
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33791action=edit
EXample using __atomic_test_and_set that causes tsan positives

When compiling code using atomic instrinsics with -fsanitize=thread some of the
functions - in particular __atomic_test_and_set and __atomic_clear are not
instrumented.

Hence tsan reports false positives when spin-locking with
__atomic_test_and_set/__atomic_clear but not when using
__atomic_exchange_n/__atomic_store_n.

(This also affects std:atomic_flag as it uses the problematic operations in its
implementation.)

[Bug sanitizer/63627] thread sanitizer does not instrument __atomic_test_and_set or __atomic_clear

[rogero at howzatt dot demon.co.uk]

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

--- Comment #1 from Roger Orr rogero at howzatt dot demon.co.uk ---
Created attachment 33792
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33792action=edit
Example using __atomic_exchange_n that does not generate tsan warnings

[Bug sanitizer/63559] New: -fsanitize=thread sets no preprocessor flags

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 63559
   Summary: -fsanitize=thread sets no preprocessor flags
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

When -fsanitize=address is supplied the builtin __SANITIZE_ADDRESS__ is
defined. There does not appear to be an equivalent for -fsanitize=thread, which
could be used for conditionally compiling code to avoid tsan reporting false
positives.

[Bug sanitizer/63559] -fsanitize=thread sets no preprocessor flags

[rogero at howzatt dot demon.co.uk]

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

--- Comment #2 from Roger Orr rogero at howzatt dot demon.co.uk ---
Hi Dmitry,
the false positives I've investigated seem to be down to spin-locked queues and
use of intel tbb concurrency data structures - AFAICT we don't have source for
the latter so I wouldn't expect tsan to resolve either of them.

[Bug c++/60361] New: unexpected 'use of parameter outside function body' error

[rogero at howzatt dot demon.co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361

Bug ID: 60361
   Summary: unexpected 'use of parameter outside function body'
error
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk

When declaring a variable with a bracketed constructor call, and using the same
external name for the first argument and a template instantiation used as the
second argument, the delaration can fail to compile.

- registration.cpp -
struct Helper
{
  Helper(int a, void (*pfunc)());
};

template int I void function();

const int A = 1;
const int B = 2;

Helper testOk(A, functionA);

Helper testOk2(int(A), functionB);

Helper testOk3((int(A)), functionA);

// Why does (only) this one fail?
Helper testFail(int(A), functionA);
- ends -

registration.cpp:18:34: error: use of parameter 'A' outside function body
 Helper testFail(int(A), functionA);
  ^
registration.cpp:18:34: error: use of parameter 'A' outside function body
registration.cpp:18:34: error: use of parameter 'A' outside function body
registration.cpp:18:36: error: no matching function for call to
'Helper::Helper(int, unresolved overloaded function type)'
 Helper testFail(int(A), functionA);
^
registration.cpp:18:36: note: candidates are:
registration.cpp:3:3: note: Helper::Helper(int, void (*)())
   Helper(int a, void (*pfunc)());
   ^
registration.cpp:3:3: note:   no known conversion for argument 2 from
'unresolved overloaded function type' to 'void (*)()'
registration.cpp:1:8: note: Helper::Helper(const Helper)
 struct Helper
^
registration.cpp:1:8: note:   candidate expects 1 argument, 2 provided


Fails with g++ 4.9.0 and 4.8.1
Works with g++ 4.2.3, Clang 3.2, ICC 13.0 and MSVC 8 thru 12.

[Bug c++/58071] New: Premature instantiation of default argument

[rogero at howzatt dot demon.co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58071

Bug ID: 58071
   Summary: Premature instantiation of default argument
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk

If a function is declared with a default argument of a template type the
compiler fails if the constructor cannot be instantiated at the point of
definition of the function.

As I understand it 8.3.6p5 states The names in the default argument are
bound, and the semantic constraints are checked, at the point where the default
argument appears.

So the compiler can instantiate the *class* definition but I do not believe it
should be instantiating the constructor body unless and until the default
argument is actually *used*.

The code below compiles and links with Clang and icc (and msvc)

Example:


template typename T
class generic
{
public:
  generic() { T p; test(p); }
  generic(T *) {}
};

class Foo {};

void f(genericFoo const  = genericFoo());

int main() {}


g++ -Wall -Wextra 8.3.6p5.cpp
8.3.6p5.cpp: In instantiation of 'genericT::generic() [with T = Foo]':
8.3.6p5.cpp:11:44:   required from here
8.3.6p5.cpp:5:20: error: 'test' was not declared in this scope

[Bug c++/57973] New: incorrect access check for protected member of template base with using

[rogero at howzatt dot demon.co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973

Bug ID: 57973
   Summary: incorrect access check for protected member of
template base with using
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk

Created attachment 30547
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30547action=edit
sample program -- I believe this should compile.

In a template class where a protected member of a template base class is the
subject of a using declaration, atempting to form pointer-to-member fails.

I have tested with:
   mingw g++ (niXman build) 4.7.0 20120203 (experimental)
   www.ideone.com (gcc 4.7.2)
   www.godbolt.com (gcc  4.4.7, 4.5.3, 4.6.4, 4.7.3, 4.8.1)

the program fails to compile on each with these errors:

prog.cpp: In instantiation of ‘bool DT::testB() const [with T = int]’:
prog.cpp:37:12:   required from here
prog.cpp:22:17: error: ‘using BT::bptr’ is inaccessible
prog.cpp:25:18: error: within this context

I beleive the code is correct, and it is accepted by:

clang 3.0.6
icc 13.0
msvc 12

[Bug c++/57973] incorrect access check for protected member of template base with using

[rogero at howzatt dot demon.co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973

--- Comment #2 from Roger Orr rogero at howzatt dot demon.co.uk ---
Thank you. Aoplogies for the noise.