invalid initial value for member [of bit struct]
Dear GCC Team!
My name is Gavrilov Vladimir, and I am Associate Professor in Nizhny
Novgorod State University (Russian Federation).
To use in educational process of this university, I wrote lexical
analyzer generator Myauka (source code:
https://github.com/gavr-vlad-s/myauka). This generator is written in
C++14 and generates C++14 text.
I build project Myauka using applied Makefile (this Makefile was
generated my own build system). If I use g++ having version 5.1.0 or
5.4.0, then there are no errors and there are no warnings. But if I
use g++ having version 6.2.0, then I get errors. The output of the
compiler is contained in the file "myauka-build-log-with-g++.6.1.txt".
Moreover, if in lines 46-48 of file 'include/act_expr_parser.h' replace
struct Parser_action_info{
uint8_t kind : 2;
uint8_t arg : 6;
};
with
struct Parser_action_info{
uint8_t kind;
uint8_t arg;
};
then there are no errors and there are no warnings.
Sincerely yours,
Gavrilov Vladimir
pesets@belka:~/projects/myauka$ make
g++ -c src/myauka.cpp -o myauka.o -std=c++14 -Wall
mv myauka.o ./build
g++ -c src/main_parser_data.cpp -o main_parser_data.o -std=c++14 -Wall
mv main_parser_data.o ./build
g++ -c src/search_char.cpp -o search_char.o -std=c++14 -Wall
mv search_char.o ./build
g++ -c src/dfa.cpp -o dfa.o -std=c++14 -Wall
mv dfa.o ./build
g++ -c src/char_conv.cpp -o char_conv.o -std=c++14 -Wall
mv char_conv.o ./build
g++ -c src/attributed_char_trie.cpp -o attributed_char_trie.o -std=c++14 -Wall
mv attributed_char_trie.o ./build
g++ -c src/file_contents.cpp -o file_contents.o -std=c++14 -Wall
mv file_contents.o ./build
g++ -c src/keyword_delimiter_parser.cpp -o keyword_delimiter_parser.o
-std=c++14 -Wall
mv keyword_delimiter_parser.o ./build
g++ -c src/move_by_ext.cpp -o move_by_ext.o -std=c++14 -Wall
mv move_by_ext.o ./build
g++ -c src/list_to_columns.cpp -o list_to_columns.o -std=c++14 -Wall
mv list_to_columns.o ./build
g++ -c src/move_by_ext_from_curr_dir.cpp -o move_by_ext_from_curr_dir.o
-std=c++14 -Wall
mv move_by_ext_from_curr_dir.o ./build
g++ -c src/char_trie.cpp -o char_trie.o -std=c++14 -Wall
mv char_trie.o ./build
g++ -c src/num_str_parser.cpp -o num_str_parser.o -std=c++14 -Wall
mv num_str_parser.o ./build
g++ -c src/categories.cpp -o categories.o -std=c++14 -Wall
mv categories.o ./build
g++ -c src/generalized_char.cpp -o generalized_char.o -std=c++14 -Wall
mv generalized_char.o ./build
g++ -c src/fsize.cpp -o fsize.o -std=c++14 -Wall
mv fsize.o ./build
g++ -c src/ndfa.cpp -o ndfa.o -std=c++14 -Wall
mv ndfa.o ./build
g++ -c src/error_count.cpp -o error_count.o -std=c++14 -Wall
mv error_count.o ./build
g++ -c src/expr_scaner.cpp -o expr_scaner.o -std=c++14 -Wall
mv expr_scaner.o ./build
g++ -c src/get_init_state.cpp -o get_init_state.o -std=c++14 -Wall
mv get_init_state.o ./build
g++ -c src/main_parser.cpp -o main_parser.o -std=c++14 -Wall
mv main_parser.o ./build
g++ -c src/simple_regex_parser.cpp -o simple_regex_parser.o -std=c++14 -Wall
mv simple_regex_parser.o ./build
g++ -c src/create_dir_if_not_exists.cpp -o create_dir_if_not_exists.o
-std=c++14 -Wall
mv create_dir_if_not_exists.o ./build
g++ -c src/detalize_commands.cpp -o detalize_commands.o -std=c++14 -Wall
mv detalize_commands.o ./build
g++ -c src/comments_parser.cpp -o comments_parser.o -std=c++14 -Wall
mv comments_parser.o ./build
g++ -c src/codes_and_newline.cpp -o codes_and_newline.o -std=c++14 -Wall
mv codes_and_newline.o ./build
g++ -c src/size_t_trie.cpp -o size_t_trie.o -std=c++14 -Wall
mv size_t_trie.o ./build
g++ -c src/trie_for_set_of_char.cpp -o trie_for_set_of_char.o -std=c++14 -Wall
mv trie_for_set_of_char.o ./build
g++ -c src/idx_to_string.cpp -o idx_to_string.o -std=c++14 -Wall
mv idx_to_string.o ./build
g++ -c src/main_scaner.cpp -o main_scaner.o -std=c++14 -Wall
mv main_scaner.o ./build
g++ -c src/groupped_dfa.cpp -o groupped_dfa.o -std=c++14 -Wall
mv groupped_dfa.o ./build
g++ -c src/first_chars.cpp -o first_chars.o -std=c++14 -Wall
mv first_chars.o ./build
g++ -c src/act_expr_parser.cpp -o act_expr_parser.o -std=c++14 -Wall
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘kind’
}
^
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘arg’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘kind’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘arg’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘kind’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘arg’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘kind’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘arg’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘kind’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘arg’
src/act_expr_parser.cpp:611:1: error: invalid initial value for member ‘kind’
src/act_expr_parser.cpp:611
[Bug testsuite/78544] FAIL: gcc.dg/tree-prof/section-attr-*.c compilation, -fprofile-generate -D_PROFILE_GENERATE on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78544 --- Comment #1 from Andrew Burgess --- Created attachment 40162 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40162&action=edit Patch to skip the tests As the tests are only going to test anything on a subset of targets, I don't know if we care particularly about having the compile complete on all targets. The attached patch should (if I have the syntax correct) skip the tests on all but the targets that are going to run the test.
[Bug testsuite/78544] FAIL: gcc.dg/tree-prof/section-attr-*.c compilation, -fprofile-generate -D_PROFILE_GENERATE on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78544 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin16 |*-apple-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-27 Host|x86_64-apple-darwin16 |*-apple-darwin* Ever confirmed|0 |1 Build|x86_64-apple-darwin16 |*-apple-darwin* --- Comment #2 from Iain Sandoe --- (In reply to Andrew Burgess from comment #1) > Created attachment 40162 [details] > Patch to skip the tests > > As the tests are only going to test anything on a subset of targets, I don't > know if we care particularly about having the compile complete on all > targets. The attached patch should (if I have the syntax correct) skip the > tests on all but the targets that are going to run the test. The change at r242519 does not seem to be Linux-specific; ISTM that, rather than skipping the tests for non-Linux, they should be extended to cover a reasonable number of other cases? e.g. what about bare-metal targets? However, I guess skipping is better than an apparent pass that actually does nothing. It's on the (very long) TDOD, to examine the output for Darwin and derive appropriate scans.
[Bug c/78548] New: ice on valid C code on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode with -Wall (*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': double free or corru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78548
Bug ID: 78548
Summary: ice on valid C code on x86_64-linux-gnu at -O2 and -O3
in 64-bit mode with -Wall (*** Error in
`/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/
7.0.0/cc1': double free or corruption (fasttop):
0x03c15810 ***)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Target Milestone: ---
The following program crashes gcc in the 64-bit mode, but causes gcc to hang in
the 32-bit mode.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161127 (experimental) [trunk revision 242892] (GCC)
$
$ gcc-trunk -Wall -w -O3 -m64 small.c
*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1':
double free or corruption (fasttop): 0x03c15810 ***
small.c: In function ‘main’:
small.c:6:5: internal compiler error: Aborted
int main ( ) {
^~~~
0xbe8aff crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0xe0ba36 xcallocator::data_free(gimple**)
../../gcc-source-trunk/gcc/hash-table.h:273
0xe0ba36 ~hash_table
../../gcc-source-trunk/gcc/hash-table.h:627
0xe0ba36 ~hash_set
../../gcc-source-trunk/gcc/hash-set.h:25
0xe0ba36 find_def_preds
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:775
0xe0ba36 is_use_properly_guarded
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2375
0xe0c17e find_uninit_use
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2434
0xe0c17e warn_uninitialized_phi
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2504
0xe0c17e execute
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2612
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.
$
$ cat small.c
char a;
int b;
unsigned c, d;
short e;
int main_f;
int main ( ) {
L0:
if ( e ) goto L1;
b = c & d || a;
if ( !c ) printf ( "", ( long long ) main_f );
if ( d || !c ) {
printf ( "%llu\n", ( long long ) main );
goto L2;
}
unsigned g = b;
L1:
b = g;
L2:
if ( b ) goto L0;
return 0;
}
[Bug libfortran/78549] New: Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
Bug ID: 78549
Summary: Very slow formatted internal file output
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mecej4 at operamail dot com
Target Milestone: ---
Created attachment 40163
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40163&action=edit
Program to demonstrate bug
Formatted internal writes to a string variable are very slow in many recent
versions of GFortran, especially the Windows ports. The attached F77 program,
and F95 versions of the same, demonstrate the problem. The heart of the problem
is the slowness of
write (str,'(1P,10E12.3)') x
(where x is a real array of dimension 10), compared to the equivalent call to
sprintf in C. Unlike in some old Gfortran bug reports, there are no issues
related to Windows versus Linux file system and I/O system discrepancies. NO
external FILE I/O is involved.
Here are some timings, in seconds, on two systems.
SYSTEM: Linux, XEON E5-2630, GFortran/GCC 6.1.1/F2C
gfortran -Ofast 6.4
F2C and gcc -Ofast 4.8
gcc -Ofast 1.8
SYSTEM: Windows 10-64 laptop, Haswell i5-4200U CPU
F2C, gcc 6.2 -O2 -march=haswell 7.8
G77 -O2 -march=pentium 12.7
gfortran 5.2 32-bit Cygwin 49.6
gfortran 6.2 Mingw-64, Eq.com 65.6
gcc 6.2 5.2
Ifort 17.0.12.3
Here is the source code of the C program, which I am placing here since I am
allowed only one attachment.
#include
int main(){
char str[121];
float x[10]={ 7.569, 5.556, -1.640, 9.362, 1.057,
-2.385,-9.541, 1.449, -7.885, -1.108};
int i,j;
for(i=0; i<100; i++){
sprintf(str,"%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e",
x[0],x[1],x[2],x[3],x[4],x[5],x[6],x[7],x[8],x[9]);
if((i+1)%20 == 0)printf("%8d %s\n",i+1,str);
}
}
Re: invalid initial value for member [of bit struct]
On 2016.11.27 at 11:50 +0300, Vladimir Gavrilov wrote:
> Dear GCC Team!
> My name is Gavrilov Vladimir, and I am Associate Professor in Nizhny
> Novgorod State University (Russian Federation).
>
> To use in educational process of this university, I wrote lexical
> analyzer generator Myauka (source code:
> https://github.com/gavr-vlad-s/myauka). This generator is written in
> C++14 and generates C++14 text.
>
> I build project Myauka using applied Makefile (this Makefile was
> generated my own build system). If I use g++ having version 5.1.0 or
> 5.4.0, then there are no errors and there are no warnings. But if I
> use g++ having version 6.2.0, then I get errors. The output of the
> compiler is contained in the file "myauka-build-log-with-g++.6.1.txt".
>
> Moreover, if in lines 46-48 of file 'include/act_expr_parser.h' replace
> struct Parser_action_info{
> uint8_t kind : 2;
> uint8_t arg : 6;
> };
> with
> struct Parser_action_info{
> uint8_t kind;
> uint8_t arg;
> };
> then there are no errors and there are no warnings.
>
Hi Vladimir,
this list is normally used for automated bugzilla traffic only.
So please open a bug report here: https://gcc.gnu.org/bugzilla/
You could include this small testcase:
#include
struct A {
int i : 1;
};
std::map ma{{1, {0}}};
--
Markus
[Bug testsuite/78544] FAIL: gcc.dg/tree-prof/section-attr-*.c compilation, -fprofile-generate -D_PROFILE_GENERATE on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78544 Iain Sandoe changed: What|Removed |Added Attachment #40158|0 |1 is obsolete|| --- Comment #3 from Iain Sandoe --- Created attachment 40164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40164&action=edit tentative scan asm changes for Darwin. If the intent of the test is to find that hot/cold partitioning has not been disabled by the section attribs, then this should be sufficient to show that the cold section was invoked on darwin (I don't think the start label will be generated unless the switch happens from final.c) (very lightly tested)
[Bug c++/78550] New: [6/7 Regression] bit field and std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78550
Bug ID: 78550
Summary: [6/7 Regression] bit field and std::initializer_list
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
Gavrilov Vladimir reported the following issue in a direct email to gcc-bugs:
markus@x4 tmp % cat map_bitfield.cpp
#include
struct A {
int i : 1;
};
std::map ma{{1, {0}}};
markus@x4 tmp % g++ -c map_bitfield.cpp
map_bitfield.cpp:5:30: error: invalid initial value for member ‘i’
std::map ma{{1, {0}}};
^
GCC-5 and other compilers accept this code.
A bit further reduced:
markus@x4 tmp % cat map_bitfield2.cpp
#include
template struct A { A(std::initializer_list); };
struct B {
int k : 1;
};
A a{{0}};
markus@x4 tmp % g++ -c map_bitfield2.cpp
map_bitfield2.cpp:6:12: error: invalid initial value for member ‘k’
A a{{0}};
^
Re: invalid initial value for member [of bit struct]
On 2016.11.27 at 13:39 +0100, Markus Trippelsdorf wrote:
> On 2016.11.27 at 11:50 +0300, Vladimir Gavrilov wrote:
> > Dear GCC Team!
> > My name is Gavrilov Vladimir, and I am Associate Professor in Nizhny
> > Novgorod State University (Russian Federation).
> >
> > To use in educational process of this university, I wrote lexical
> > analyzer generator Myauka (source code:
> > https://github.com/gavr-vlad-s/myauka). This generator is written in
> > C++14 and generates C++14 text.
> >
> > I build project Myauka using applied Makefile (this Makefile was
> > generated my own build system). If I use g++ having version 5.1.0 or
> > 5.4.0, then there are no errors and there are no warnings. But if I
> > use g++ having version 6.2.0, then I get errors. The output of the
> > compiler is contained in the file "myauka-build-log-with-g++.6.1.txt".
> >
> > Moreover, if in lines 46-48 of file 'include/act_expr_parser.h' replace
> > struct Parser_action_info{
> > uint8_t kind : 2;
> > uint8_t arg : 6;
> > };
> > with
> > struct Parser_action_info{
> > uint8_t kind;
> > uint8_t arg;
> > };
> > then there are no errors and there are no warnings.
> >
> Hi Vladimir,
>
> this list is normally used for automated bugzilla traffic only.
> So please open a bug report here: https://gcc.gnu.org/bugzilla/
>
> You could include this small testcase:
>
> #include
> struct A {
> int i : 1;
> };
> std::map ma{{1, {0}}};
I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78550
--
Markus
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #45 from Iain Sandoe --- Author: iains Date: Sun Nov 27 14:21:51 2016 New Revision: 242893 URL: https://gcc.gnu.org/viewcvs?rev=242893&root=gcc&view=rev Log: [Darwin, ld64] Make PIC indirections and constant labels linker-visible. Indirections: If we have a situation like: global_weak_symbol: Lnon_weak_local: ld64 will be unable to split this into two atoms (because the "L" makes the second symbol 'invisible'). This means that legitimate direct accesses to the second symbol will appear to be non-allowed direct accesses to an atom of type weak, global which are not allowed. To avoid this, we make the indirections have a leading 'l' (lower-case L) which has a special meaning: linker can see this and use it to determine atoms, but it is not placed into the final symbol table. The implementation here is somewhat heavy-handed in that it will also mark indirections to the __IMPORT,__pointers section the same way which is really unnecessary, since ld64 _can_ split those into atoms as they are fixed size. FIXME: determine if this is a penalty worth extra code to fix. Similarly, with: .const weak_global_constant: LCxx: ... ld64 can't split the second, causing a warning when it's directly accessed. gcc/ 2016-11-27 Iain Sandoe PR target/71767 * config/darwin.c (imachopic_indirection_name): Make data section indirections linker-visible. * config/darwin.h (ASM_GENERATE_INTERNAL_LABEL): Make local constant labels linker-visible. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #46 from Iain Sandoe --- Author: iains Date: Sun Nov 27 14:29:36 2016 New Revision: 242894 URL: https://gcc.gnu.org/viewcvs?rev=242894&root=gcc&view=rev Log: [Darwin, config] Arrange for ld64 to be detected as Darwin's linker. This is an initial patch in a series that converts Darwin's configury to detect ld64 features, rather than the current process of hard-coding them on target system version. A ld64-compatible linker is currently required and assumed by Darwin. If a DEFAULT_LINKER is set via --with-ld= then this will be tested to see if it is ld64. The ld64 version is determined for the chosen ld and this is exported for use in setting a default value for -mtarget-linker (needed for run-time code-gen changes to section choices). The support for -rdynamic is converted to be detected at config time, or by the ld64 version if that is found. gcc/ 2016-11-27 Iain Sandoe PR target/71767 * configure.ac (with-ld64): New var, set for Darwin, set on detection of ld64, gcc_cv_ld64_export_dynamic: New, New test. * config/darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, define. * config/darwin10.h(DEF_LD64): Update for this target version. * config/darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic test. (DEF_LD64): Update for this target version. * configure: Regenerated. * config.in: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/config/darwin.h trunk/gcc/config/darwin10.h trunk/gcc/config/darwin12.h trunk/gcc/configure trunk/gcc/configure.ac
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #47 from Iain Sandoe --- Author: iains Date: Sun Nov 27 14:34:54 2016 New Revision: 242895 URL: https://gcc.gnu.org/viewcvs?rev=242895&root=gcc&view=rev Log: [Darwin] Fix PR71767 - adjust the sections used where necessary. (much) Older Darwin linkers needed separate sections marked "coalesce" to allow for weak symbol coalescing. This has not been needed for some time and is now deprecated, newer assemblers warn if the old coalesced sections are used. gcc/ 2016-11-27 Iain Sandoe PR target/71767 * config/darwin-sections.def (picbase_thunk_section): New. * config/darwin.c (darwin_init_sections): Set up picbase thunk section. (darwin_rodata_section, darwin_objc2_section, machopic_select_section, darwin_asm_declare_constant_name, darwin_emit_weak_or_comdat, darwin_function_section): Don’t use coalesced with newer linkers. (darwin_override_options): Decide on usage of coalesed sections on the basis of the target linker version. * config/darwin.h (MIN_LD64_NO_COAL_SECTS): New. * config/darwin.opt (mtarget-linker): New. * config/i386/i386.c (ix86_code_end): Do not force the thunks into a coalesced section, instead use a thunks section. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-sections.def trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/config/darwin.opt trunk/gcc/config/i386/i386.c
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #48 from Iain Sandoe --- Author: iains Date: Sun Nov 27 14:41:22 2016 New Revision: 242896 URL: https://gcc.gnu.org/viewcvs?rev=242896&root=gcc&view=rev Log: [Testsuite] pr71767 Changes. Update Darwin tests to reflect the differences in symbol names and section usage. gcc/testsuite/ 2016-11-27 Dominique d'Humieres Iain Sandoe PR target/71767 * g++.dg/abi/key2.C: Adjust for changed Darwin sections and linker-visible symbols. * g++.dg/torture/darwin-cfstring-3.C: Likewise. * gcc.dg/const-uniq-1.c: Likewise. * gcc.dg/torture/darwin-cfstring-3.c: Likewise. * gcc.target/i386/pr70799-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/key2.C trunk/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C trunk/gcc/testsuite/gcc.dg/const-uniq-1.c trunk/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c trunk/gcc/testsuite/gcc.target/i386/pr70799-1.c
[Bug target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #30 from Iain Sandoe --- Author: iains Date: Sun Nov 27 14:50:58 2016 New Revision: 242897 URL: https://gcc.gnu.org/viewcvs?rev=242897&root=gcc&view=rev Log: [Darwin] Fix PR57438 by avoiding empty function bodies and trailing labels. A. Empty function bodies causes two problems for Darwin's linker (i) zero-length FDEs and (ii) coincident label addresses that might point to items of differing weakness. B. Trailing local labels can be problematic when they end a function because similarly they might apparently point to a following weak function, leading to the linker concluding that there's a pointer-diff to a weak symbol (which is not allowed). Both conditions arise from __builtin_unreachable() lowering to a barrier. The solution for both is to emit some finite amount of code; in the case of A a trap is emitted, in the case of B a nop. gcc/ 2016-11-27 Iain Sandoe PR target/57438 * config/i386/i386.c (ix86_code_end): Note that we emitted code where the function might otherwise appear empty for picbase thunks. (ix86_output_function_epilogue): If we find a zero-sized function assume that reaching it is UB and trap. If we find a trailing label append a nop. * config/rs6000/rs6000.c (rs6000_output_function_epilogue): If we find a zero-sized function assume that reaching it is UB and trap. If we find a trailing label, append a nop. gcc/testsuite/ 2016-11-27 Iain Sandoe PR target/57438 * gcc.dg/pr57438-1.c: New Test. * gcc.dg/pr57438-2.c: New Test. Added: trunk/gcc/testsuite/gcc.dg/pr57438-1.c trunk/gcc/testsuite/gcc.dg/pr57438-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
libatomic still broken with --disable-dependency-tracking
Hi, I stumbled across an issue recently building gcc and libatomic with --disable-dependency-tracking (in a cross-compiler). It turns out there's an open bug with a patch by Richard Purdie for that at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 and the patch appears to work fine, on gcc 6.2.0: --- gcc-4.8.1.orig/libatomic/Makefile.am2013-01-14 18:16:23.0 + +++ gcc-4.8.1.orig/libatomic/Makefile.am2013-09-22 10:38:18.904064750 + @@ -100,7 +100,8 @@ IFUNC_DEF = -DIFUNC_ALT=$(PAT_S) IFUNC_OPT = $(word $(PAT_S),$(IFUNC_OPTIONS)) -M_DEPS = -MT $@ -MD -MP -MF $(DEPDIR)/$(@F).Ppo +@AMDEP_TRUE@M_DEPS = -MT $@ -MD -MP -MF $(DEPDIR)/$(@F).Ppo +@AMDEP_FALSE@M_DEPS= M_SIZE = -DN=$(PAT_N) M_IFUNC= $(if $(PAT_S),$(IFUNC_DEF) $(IFUNC_OPT)) M_FILE = $(PAT_BASE)_n.c --- gcc-4.8.1.orig/libatomic/Makefile.in2013-05-31 09:09:26.0 + +++ gcc-4.8.1.orig/libatomic/Makefile.in2013-09-22 10:40:42.520059917 + @@ -298,7 +298,8 @@ PAT_S = $(word 3,$(PAT_SPLIT)) IFUNC_DEF = -DIFUNC_ALT=$(PAT_S) IFUNC_OPT = $(word $(PAT_S),$(IFUNC_OPTIONS)) -M_DEPS = -MT $@ -MD -MP -MF $(DEPDIR)/$(@F).Ppo +@AMDEP_TRUE@M_DEPS = -MT $@ -MD -MP -MF $(DEPDIR)/$(@F).Ppo +@AMDEP_FALSE@M_DEPS = M_SIZE = -DN=$(PAT_N) M_IFUNC = $(if $(PAT_S),$(IFUNC_DEF) $(IFUNC_OPT)) M_FILE = $(PAT_BASE)_n.c Is the patch suitable for merging? Thanks, Stephen pgpBGDju9n0ra.pgp Description: OpenPGP digital signature
[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710 --- Comment #13 from Iain Sandoe --- Author: iains Date: Sun Nov 27 15:07:22 2016 New Revision: 242898 URL: https://gcc.gnu.org/viewcvs?rev=242898&root=gcc&view=rev Log: [Darwin] fix PR67710 by updating 'as' specs to handle newer assembler versions. A/ Newer versions of ld64 check the min_version command, and newer versions of the system assembler inserts this in response to "-mmacosx-version-min=" on the assembler line. Unless one makes sensible versions, some object is bound to conflict. B/ Additionally, there's a difference in behaviour between "as" and "ld" when presented with xx.yy.zz (ld truncates to xx.yy, as doesn't); net result is that one needs to pass a truncated version to "as". So (if the assembler supports minversion commands) (a) provide a truncated minversion (as asm_macosx_version_min, which is a driver-only var). (b) pass this to "as" (c) Update tests to determine 'HAVE_AS_MMACOSX_VERSION_MIN_OPTION' (Rainer's patch) (d) For some reason the testcases are "run" (it's not obvious they need to be, they are checking compile-time issues) - anyway, to preserve the status quo, I've left them as exec. However, the minimum version that can be code-gened for is target-dependent (there are no released x86 versions before 10.4, for example). To avoid conflicts where the "as" is assuming some minimum, I've set the testversion to 10.5 (which is supported by all the archs we have) (e) We need to ensure that libgcc and crts are generated with a sufficiently old minversion not to conflict. gcc/ 2016-11-27 Iain Sandoe Rainer Orth PR target/67710 * config.in: Regenerate * config/darwin-driver.c (darwin_driver_init): Emit a version string for the assembler. * config/darwin.h(ASM_MMACOSX_VERSION_MIN_SPEC): New, new tests. * config/darwin.opt(asm_macosx_version_min): New. * config/i386/darwin.h: Handle ASM_MMACOSX_VERSION_MIN_SPEC. * configure: Regenerate * configure.ac: Check for mmacosx-version-min handling. gcc/testsuite/ 2016-11-27 Iain Sandoe Rainer Orth Dominique d'Humieres PR target/67710 * gcc.dg/darwin-minversion-1.c: Update min version check. * gcc.dg/darwin-minversion-2.c: Likewise. * gcc.dg/darwin-minversion-3.c: Likewise. libgcc/ 2016-11-27 Iain Sandoe Rainer Orth PR target/67710 * config/t-darwin: Default builds to 10.5 codegen. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/config/darwin-driver.c trunk/gcc/config/darwin.h trunk/gcc/config/darwin.opt trunk/gcc/config/i386/darwin.h trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/darwin-minversion-1.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-2.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-3.c trunk/libgcc/ChangeLog trunk/libgcc/config/t-darwin
[Bug target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #31 from Mike Stump --- On Nov 6, 2016, at 12:22 PM, iains at gcc dot gnu.org wrote: > I have backports for 6.x and 5.x if wanted. Yes please. I think it is safe enough and the problem is really kinda nasty.
[Bug c++/78551] New: Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551
Bug ID: 78551
Summary: Internal compiler error with constexpr initialization
of union
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlad at petric dot cc
Target Milestone: ---
The following code ICEs:
#include
#include
struct A {
union {
uint64_t s;
char buff[8];
};
constexpr A(const char* str) : s(0) {
if (str == nullptr) return;
size_t i = 0;
for (; i < 8 && str[i] != '\0'; ++i) {
buff[i] = str[i];
}
if (str[i] != '\0') throw std::out_of_range("");
}
};
constexpr std::array array({"long", "longer"});
It doesn't ICE if I do any of the following:
1. Switch the constructor to char[N] (where N is from template)
2. Get rid of constexpr
3. Get rid of the union - just initialize buff
[Bug c++/77771] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #2 from Vlad Petric --- Created attachment 40165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40165&action=edit code that fails
[Bug c++/77771] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #3 from Vlad Petric --- Sorry - accidentally added test case attachment to this bug. The bug I reported is likely related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551
[Bug c++/78551] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 --- Comment #1 from Vlad Petric --- Created attachment 40166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40166&action=edit code that fails as attachment
[Bug c++/78551] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 --- Comment #2 from Vlad Petric --- Created attachment 40167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40167&action=edit Code with constexpr that fails
[Bug fortran/77505] Negative character length not treated as LEN=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77505
--- Comment #9 from Elizebeth Punnoose ---
(In reply to Janne Blomqvist from comment #8)
> (In reply to Elizebeth Punnoose from comment #6)
> > Modified code with the warning message moved behind -fcheck=bounds.
> >
> > Index: trans-array.c
> > ===
> > --- trans-array.c (revision 241960)
> > +++ trans-array.c (working copy)
> > @@ -2226,6 +2226,8 @@
> >gfc_ss_info *ss_info;
> >gfc_expr *expr;
> >gfc_ss *s;
> > + tree neg_len;
> > + char *msg;
> >
> >/* Save the old values for nested checking. */
> >old_first_len = first_len;
> > @@ -2271,6 +2273,27 @@
> > gfc_conv_expr_type (&length_se, expr->ts.u.cl->length,
> > gfc_charlen_type_node);
> > ss_info->string_length = length_se.expr;
> > +
> > + /* Check if the character length is negative,
> > +if so consider it as LEN=0. */
> > + neg_len = fold_build2_loc (input_location, LT_EXPR,
> > + boolean_type_node, ss_info->string_length,
> > + build_int_cst (gfc_charlen_type_node, 0));
> > + /* Print a warning if bounds checking is enabled. */
> > + if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
> > + {
> > + msg = xasprintf ("Negative character length will be treated as
> > LEN=0");
> > + gfc_trans_runtime_check (false, true, neg_len,
> > +&length_se.pre, where, msg);
> > + free(msg);
> > + }
> > + ss_info->string_length = fold_build3_loc (input_location,
> > + COND_EXPR, gfc_charlen_type_node,
> > + neg_len, gfc_index_zero_node,
> > + ss_info->string_length);
> > + ss_info->string_length = gfc_evaluate_now (ss_info->string_length,
> > +&length_se.pre);
> > +
> > gfc_add_block_to_block (&outer_loop->pre, &length_se.pre);
> > gfc_add_block_to_block (&outer_loop->post, &length_se.post);
> > }
>
>
> Shouldn't you have build_int_cst (gfc_charlen_type_node, 0) instead of
> gfc_index_zero_node?
Thank you for your comment. I will make the necessary changes and re-post.
[Bug fortran/78474] gfortran accepts invalid submodule syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78474 --- Comment #7 from Paul Thomas --- Created attachment 40168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40168&action=edit Fix for the PR This patch has been posted to the list. Paul
[Bug fortran/77903] [F08] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77903 --- Comment #8 from Paul Thomas --- (In reply to Damian Rouson from comment #0) > Gfortran accepts invalid code in which an implicitly typed interface body > has the same name as a conflicting, explicitly typed module function > implemented in a submodule. See below. > > Damian > > > $ cat one.f90 > module one_module > implicit none > interface > module function one() > end function > end interface > end module > > submodule(one_module) one_submodule > implicit none > contains > integer module function one() > one = 1 > end function > end submodule > > use one_module > print *,one()," is not ",1 > end > > $ gfortran -std=f2008 -Wall -fcheck=all one.f90 > > $ ./a.out >9.18340949E-41 is not1 > > $ gfortran --version > GNU Fortran (MacPorts gcc6 6.1.0_0) 6.1.0 Interestingly, ifort accepts this and imposes the interface definition to the extent of making the type conversion. I will have to dwell some more on this. Paul
[Bug fortran/78474] gfortran accepts invalid submodule syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78474 --- Comment #8 from Paul Thomas --- Author: pault Date: Sun Nov 27 19:00:00 2016 New Revision: 242900 URL: https://gcc.gnu.org/viewcvs?rev=242900&root=gcc&view=rev Log: 2016-11-27 Paul Thomas PR fortran/78474 * module.c (gfc_match_submodule): If there is more than one colon, it is a syntax error. PR fortran/78331 * module.c (gfc_use_module): If an smod file does not exist it is either because the module does not have a module procedure interface or there is an error in the module. 2016-11-27 Paul Thomas PR fortran/78474 * gfortran.dg/submodule_22.f08: New test. PR fortran/78331 * gfortran.dg/submodule_21.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/submodule_21.f08 trunk/gcc/testsuite/gfortran.dg/submodule_22.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/78331] [F08] Misleading error message from submodule when module has no module procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78331 --- Comment #3 from Paul Thomas --- Author: pault Date: Sun Nov 27 19:00:00 2016 New Revision: 242900 URL: https://gcc.gnu.org/viewcvs?rev=242900&root=gcc&view=rev Log: 2016-11-27 Paul Thomas PR fortran/78474 * module.c (gfc_match_submodule): If there is more than one colon, it is a syntax error. PR fortran/78331 * module.c (gfc_use_module): If an smod file does not exist it is either because the module does not have a module procedure interface or there is an error in the module. 2016-11-27 Paul Thomas PR fortran/78474 * gfortran.dg/submodule_22.f08: New test. PR fortran/78331 * gfortran.dg/submodule_21.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/submodule_21.f08 trunk/gcc/testsuite/gfortran.dg/submodule_22.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug ada/78531] [7 Regression] bootstrap broken with _FORTIFY_SOURCE enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78531 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Sun Nov 27 20:23:31 2016 New Revision: 242901 URL: https://gcc.gnu.org/viewcvs?rev=242901&root=gcc&view=rev Log: PR ada/78531 * namet.h (Max_Line_Length): Define. (struct Bounded_String): Declare Chars with exact size. (namet__get_decoded_name_string): Delete. (Get_Decoded_Name_String): Likewise. (casing__set_all_upper_case): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/namet.h
[Bug ada/78531] [7 Regression] bootstrap broken with _FORTIFY_SOURCE enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78531 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- This should work again.
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #49 from John David Anglin --- (In reply to Iain Sandoe from comment #46) > Author: iains > Date: Sun Nov 27 14:29:36 2016 > New Revision: 242894 > > URL: https://gcc.gnu.org/viewcvs?rev=242894&root=gcc&view=rev > Log: > [Darwin, config] Arrange for ld64 to be detected as Darwin's linker. > > This is an initial patch in a series that converts Darwin's configury > to detect ld64 features, rather than the current process of hard-coding > them on target system version. > > A ld64-compatible linker is currently required and assumed by Darwin. > If a DEFAULT_LINKER is set via --with-ld= then this will be tested to > see if it is ld64. > > The ld64 version is determined for the chosen ld and this is exported for > use in setting a default value for -mtarget-linker (needed for run-time > code-gen changes to section choices). > The support for -rdynamic is converted to be detected at config time, or > by the ld64 version if that is found. > > gcc/ > > 2016-11-27 Iain Sandoe > > PR target/71767 > * configure.ac (with-ld64): New var, set for Darwin, set on > detection of ld64, gcc_cv_ld64_export_dynamic: New, New test. > * config/darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, > define. > * config/darwin10.h(DEF_LD64): Update for this target version. > * config/darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic > test. (DEF_LD64): Update for this target version. > * configure: Regenerated. > * config.in: Regenerated. > > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config.in > trunk/gcc/config/darwin.h > trunk/gcc/config/darwin10.h > trunk/gcc/config/darwin12.h > trunk/gcc/configure > trunk/gcc/configure.ac The change breaks bootstrap on hppa64-*-*. checking linker for compressed debug sections... 0 /xxx/gnu/gcc/gcc/gcc/configure[28336]: Syntax error at line 28360 : `<' is not e xpected.
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #50 from Iain Sandoe --- Created attachment 40169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40169&action=edit configure fix please could you confirm if this fixes bootstrap. very sorry for the breaskage
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 Andreas Tobler changed: What|Removed |Added CC||andreast at gcc dot gnu.org --- Comment #51 from Andreas Tobler --- Fixes the configure for FreeBSD. Thanks, Andreas
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #52 from dave.anglin at bell dot net --- On 2016-11-27, at 4:18 PM, iains at gcc dot gnu.org wrote: > please could you confirm if this fixes bootstrap. Yes, it fixes the configure error on hppa64-hp-hpux11.11. Thanks, Dave -- John David Anglin dave.ang...@bell.net
[Bug ada/78524] [7 regression] failure of ACATS c41104a at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78524 --- Comment #9 from Eric Botcazou --- Author: ebotcazou Date: Sun Nov 27 22:04:13 2016 New Revision: 242902 URL: https://gcc.gnu.org/viewcvs?rev=242902&root=gcc&view=rev Log: PR ada/78524 * gcc-interface/utils.c (max_size) : Add missing conversion to original type in the PLACEHOLDER_EXPR case. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils.c
[Bug ada/78524] [7 regression] failure of ACATS c41104a at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78524 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Eric Botcazou --- .
[Bug libstdc++/78552] New: std::locale::classic() Needless Race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78552 Bug ID: 78552 Summary: std::locale::classic() Needless Race Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gccbza at bluematt dot me Target Milestone: --- I'm not sure whether the standard has any thread-safety requirements for std::local::classic() (I cant seem to find any?), but it seems needlessly race-y: classic() constructs a new locale on top of the global c_locale using the locale(_Impl*) constructor, which only bothers to set _M_impl to the pointer passed in. Thus, every time you call classic() it sets c_locale._M_impl to _S_classic and then returns a const reference to c_locale. This isnt an issue on many (any?) platforms, but helgrind/drd gets very upset and there is seemingly no reason to do this outside of _S_initialize?
[Bug bootstrap/78553] New: GCC 5.3.0 and 5.4.0 segfault during bootstrap when --enable-vtable-verify is enabled on PowerPC musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78553
Bug ID: 78553
Summary: GCC 5.3.0 and 5.4.0 segfault during bootstrap when
--enable-vtable-verify is enabled on PowerPC musl
Product: gcc
Version: 5.4.0
URL: https://bugs.gentoo.org/show_bug.cgi?id=588664
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: awilfox at adelielinux dot org
Target Milestone: ---
Target: powerpc-linux-musl
Created attachment 40170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40170&action=edit
Each crash seen during make -j4 of GCC 5.4.0
I have been able to confirm that passing --enable-vtable-verify to ./configure
causes these GCC versions to segfault during the build of libstdc++-v3 on
PowerPC targets:
5.3.0, no patches
5.3.0, Gentoo patches
5.3.0, musl-cross-make patches
5.4.0, no patches
5.4.0, Adélie patches
5.4.0, Gentoo patches
5.4.0, musl-cross-make patches
In file included from
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/gcc-5.4.0/libstdc++-v3/src/c++98/complex_io.cc:25:0:
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/include/complex:
In function ‘std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::complex<_Tp>&)
[with _Tp = long double; _CharT = wchar_t; _Traits =
std::char_traits]’:
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/include/complex:526:5:
internal compiler error: Segmentation fault
operator<<(basic_ostream<_CharT, _Traits>& __os, const complex<_Tp>& __x)
^
Disabling --enable-vtable-verify allows the build to complete successfully.
This happens to me on PowerPC and PowerPC64 glibc hosts
(powerpc{,64}-linux-gnu), but appears to also occur on x86_64-linux-gnu targets
per the Gentoo bug in the URL field.
Backtrace follows from my PowerPC64 system. I no longer have the .ii file but
I can recreate it if it is needed (it takes about 40 minutes to get to the
failure point).
Starting program:
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/gcc/xgcc
-shared-libgcc
-B/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/./gcc
-nostdinc++
-L/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/src
-L/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/src/.libs
-L/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/libsupc++/.libs
-B/usr/powerpc-foxkit-linux-musl/bin/ -B/usr/powerpc-foxkit-linux-musl/lib/
-isystem /usr/powerpc-foxkit-linux-musl/include -isystem
/usr/powerpc-foxkit-linux-musl/sys-include
-I/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/gcc-5.4.0/libstdc++-v3/../libgcc
-I/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/include/powerpc-foxkit-linux-musl
-I/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/include
-I/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/gcc-5.4.0/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -fno-implicit-templates -fvtable-verify=std
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=complex_io.lo -g -O2
-D_GNU_SOURCE -c
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/gcc-5.4.0/libstdc++-v3/src/c++98/complex_io.cc
-fPIC -DPIC -D_GLIBCXX_SHARED -o complex_io.o
[New process 11748]
process 11748 is executing new program:
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/gcc/cc1plus
Thread 2.1 "cc1plus" received signal SIGSEGV, Segmentation fault.
[Switching to process 11748]
0x1040f2d4 in .symtab_node::ultimate_alias_target(availability*) ()
(gdb) bt
#0 0x1040f2d4 in .symtab_node::ultimate_alias_target(availability*) ()
#1 0x1063adbc in .cgraph_node::ultimate_alias_target(availability*) ()
#2 0x110ed540 in .call_ABI_of_interest(tree_node*) ()
#3 0x110ed8f4 in .init_cumulative_args(rs6000_args*, tree_node*,
rtx_def*, int, int, int, tree_node*, machine_mode) ()
#4 0x105c239c in .expand_call(tree_node*, rtx_def*, int) ()
#5 0x1079ea20 in .expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) ()
#6 0x107949a4 in .expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool) ()
#7 0x1078c0e0 in .store_expr_with_bounds(tree_node*, rtx_def*, int,
bool, tree_node*) ()
#8 0x1078b134 in .expan
[Bug middle-end/78520] missing warning for snprintf with size greater than INT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78520 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-11-28 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/78520] missing warning for snprintf with size greater than INT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78520 Martin Sebor changed: What|Removed |Added Keywords||diagnostic, patch --- Comment #1 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02730.html
[Bug middle-end/78521] [7 Regression] incorrect byte count in -Wformat-length warning with non-constant width or precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78521 --- Comment #1 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02730.html
[Bug c++/77907] [6 Regression] Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907 --- Comment #8 from Jason Merrill --- Author: jason Date: Mon Nov 28 04:00:36 2016 New Revision: 242906 URL: https://gcc.gnu.org/viewcvs?rev=242906&root=gcc&view=rev Log: PR c++/77907 - static init and PMF * constexpr.c (cxx_eval_constant_expression): Use cp_fold_convert. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/g++.dg/cpp0x/pr77907.C
[Bug target/78554] New: Internal Compiler Error in msp430 target with -mlarge, -O{s123}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78554
Bug ID: 78554
Summary: Internal Compiler Error in msp430 target with -mlarge,
-O{s123}
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: awygle at gmail dot com
Target Milestone: ---
When compiling code for an MSP430 using large model (-mlarge) and any
optimization above 0, assigning the address of a global variable to an __int20
unsigned (__UINTPTR_TYPE__) which is part of a structure causes an internal
compiler error, as in the following .i file:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
unsigned char test_val = 0;
typedef __int20 unsigned reg_t;
struct holds_reg {
reg_t r0;
};
struct holds_reg ex = { 0 };
int main() {
ex.r0 = (reg_t)(&test_val);
return 0;
}
The invocation of msp430-elf-gcc:
msp430-elf-gcc -mmcu=msp430fr5969 -mlarge -O1 -save-temps test.c
test.c: In function ‘main’:
test.c:14:1: error: unrecognizable insn:
}
^
(insn 6 5 8 2 (set (mem/c:HI (reg/f:PSI 25) [2 ex.r0+0 S2 A16])
(subreg:HI (symbol_ref:PSI ("test_val") [flags 0x2] ) 0)) test.c:12 -1
(nil))
test.c:14:1: internal compiler error: in extract_insn, at recog.c:2287
0x8aa29a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-6.2.0/gcc/rtl-error.c:108
0x8aa2c9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-6.2.0/gcc/rtl-error.c:116
0x882087 extract_insn(rtx_insn*)
../../gcc-6.2.0/gcc/recog.c:2287
0x6e1ba5 instantiate_virtual_regs_in_insn
../../gcc-6.2.0/gcc/function.c:1582
0x6e1ba5 instantiate_virtual_regs
../../gcc-6.2.0/gcc/function.c:1950
0x6e1ba5 execute
../../gcc-6.2.0/gcc/function.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Some things which don't cause this error include assigning the address of a
variable which is local to main or assigning the address directly to a __int20
unsigned which is not part of a struct. The error does not occur on -msmall or
on -O0.
[Bug target/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at redhat dot com
[Bug target/71629] [7 Regression] ICE in lra_set_insn_recog_data, at lra.c:964 w/ -O2 -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71629 Arseny Solokha changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Arseny Solokha --- Most likely PR78458 fixes this particular issue. *** This bug has been marked as a duplicate of bug 78458 ***
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #1 from Arseny Solokha --- *** Bug 77346 has been marked as a duplicate of this bug. ***
[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346 Arseny Solokha changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Arseny Solokha --- Most likely PR78543 fixes this particular issue. *** This bug has been marked as a duplicate of bug 78543 ***
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #15 from Arseny Solokha --- *** Bug 71629 has been marked as a duplicate of this bug. ***
[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346 Arseny Solokha changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #9 from Arseny Solokha --- (In reply to Arseny Solokha from comment #8) > Most likely PR78543 fixes this particular issue. > > *** This bug has been marked as a duplicate of bug 78543 *** Sorry, too fast.
[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544 Frédéric Leroy changed: What|Removed |Added CC||frederic.le...@b-com.com --- Comment #9 from Frédéric Leroy --- Hello, I wanted to use -finstrument-functions with a software but it fails to link as in the example above. I use gcc from ubuntu 16.04: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 I recompiled the small snippet from mobi in comment 7 and it gave the same error. What need to be done to avoid this error or to fix gcc ?
