[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69038 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Eric Botcazou --- Thanks, I can reproduce now, -mcpu=ultrasparc is necessary here.
[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69038 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Investigating.
[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69038 --- Comment #5 from Eric Botcazou --- Created attachment 37142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37142&action=edit Reduced testcase To be compiled with -m64 -mcpu=ultrasparc -O.
[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69038 --- Comment #6 from Eric Botcazou --- Ugh. The nohalo_subdivision function has 37 parameters, among which 21 are double's so this really stretches the register allocator...
[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605 Dominique d'Humieres changed: What|Removed |Added CC||physiker at toast2 dot net --- Comment #18 from Dominique d'Humieres --- *** Bug 69063 has been marked as a duplicate of this bug. ***
[Bug fortran/69063] Internal compiler error, -Wunused-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69063 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Duplicate of pr66605, fixed on trunk at revision r225135. *** This bug has been marked as a duplicate of bug 66605 ***
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-27 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- With the attached "preprocessed" test I get CONTAINS 1 Fatal Error: Can't open module file 'read_nestle_in_mod.mod' for reading at (1): No such file or directory If I remove the useless lines # 1 "src/read_input_mod.f90" # 1 "" # 1 "" # 1 "src/read_input_mod.f90" I get USE READ_NESTLE_IN_MOD 1 Fatal Error: Can't open module file 'read_nestle_in_mod.mod' for reading at (1): No such file or directory which is expected since you did not provide the file containing the module READ_NESTLE_IN_MOD. Could you please provide a test not failing for trivial reasons such as missing modules?
[Bug sanitizer/69055] Internal compiler error -fsanitize=float-cast-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69055 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-27 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 Component|fortran |sanitizer Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- I think this PR is sanitizer bug. Note that the sanitizer options are meant to detect invalid codes!
[Bug sanitizer/69055] Internal compiler error -fsanitize=float-cast-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69055 --- Comment #5 from Dominique d'Humieres --- Reduced test subroutine tstd implicit none integer n real(8) :: b b = huge(1.0D0) n = b end subroutine tstd
[Bug c++/69065] New: [C++11] multiple alignas specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69065
Bug ID: 69065
Summary: [C++11] multiple alignas specifiers
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kukyakya at gmail dot com
Target Milestone: ---
http://en.cppreference.com/w/cpp/language/alignas (quoting it since I don't
have the C++11 standard documents now) states that `alignas` can be used in the
form of `alignas(pack...)`, but both g++ and clang++ fail to compile it.
struct alignas(int, double) test
{ };
So I tried to use multiple `alignas` specifiers, but got unexpected results.
#include
// struct alignas(int, double) test
// { };
struct alignas(int) alignas(double) test1 { };
struct alignas(double) alignas(int) test2 { };
int main()
{
std::cout << "alignof(int) is " << alignof(int) << std::endl;
std::cout << "alignof(double) is " << alignof(double) << std::endl;
// std::cout << "alignof(test) is " << alignof(test) << std::endl;
std::cout << "alignof(test1) is " << alignof(test1) << std::endl;
std::cout << "alignof(test2) is " << alignof(test2) << std::endl;
}
alignof(int) is 4
alignof(double) is 8
alignof(test1) is 8
alignof(test2) is 4
With clang++ I got
alignof(int) is 4
alignof(double) is 8
alignof(test1) is 8
alignof(test2) is 8
I'm not sure if it's okay to give multiple `alignas` specifiers, but I think it
should have the strictest alignment if it's okay. G++ seems to apply only the
latest `alignas` specifier.
[Bug c/69033] [6 regression] many internal compiler errors starting with r231928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69033 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Bill Schmidt --- Thanks, Nathan!
[Bug sanitizer/69055] Internal compiler error -fsanitize=float-cast-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69055
--- Comment #6 from Dominique d'Humieres ---
Similar(?) ICE with C
[Book15] f90/bug% gcc
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
-fsanitize=float-cast-overflow
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c: In function
'test_mult':
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:71:60: internal
compiler error: in gimplify_expr, at gimplify.c:10845
TEST_COMPOUND_ARITH (CMPLX (1.5, 2.5), CMPLX (3.5, 4.5), *);
^
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:15:14: note: in
definition of macro 'TEST_COMPOUND'
if ((a OP##= (RHSVAL)) != (TYPE) ((TYPE) (LHSVAL) OP (RHSVAL))) \
^~
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:71:3: note: in
expansion of macro 'TEST_COMPOUND_ARITH'
TEST_COMPOUND_ARITH (CMPLX (1.5, 2.5), CMPLX (3.5, 4.5), *);
^~~
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:71:60: internal
compiler error: Abort trap: 6
TEST_COMPOUND_ARITH (CMPLX (1.5, 2.5), CMPLX (3.5, 4.5), *);
^
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:15:14: note: in
definition of macro 'TEST_COMPOUND'
if ((a OP##= (RHSVAL)) != (TYPE) ((TYPE) (LHSVAL) OP (RHSVAL))) \
^~
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:71:3: note: in
expansion of macro 'TEST_COMPOUND_ARITH'
TEST_COMPOUND_ARITH (CMPLX (1.5, 2.5), CMPLX (3.5, 4.5), *);
^~~
A list of failing Fortran tests can be obtained by running
make -k check-gfortran
RUNTESTFLAGS="--target_board=unix'{-m32/-fsanitize=float-cast-overflow,-m64/-fsanitize=float-cast-overflow}'"
in the gcc directory:
FAIL: gfortran.dg/PR19754_2.f90 -O0 (internal compiler error)
FAIL: gfortran.dg/alloc_comp_default_init_1.f90 -O0 (internal compiler
error)
FAIL: gfortran.dg/char_result_5.f90 -O0 (internal compiler error)
FAIL: gfortran.dg/char_result_6.f90 -O0 (internal compiler error)
...
[Bug c++/68265] Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265 Mikhail Maltsev changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-27 CC||miyuki at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Mikhail Maltsev --- It looks like after parsing "int (*" we expect an identifier, but for some reason the following error gets discarded: #0 cp_parser_simulate_error (parser=parser@entry=0x77ff5ab0) at /home/miyuki/gcc/src/gcc/cp/parser.c:2879 #1 0x007598b7 in cp_parser_error (parser=parser@entry=0x77ff5ab0, gmsgid=gmsgid@entry=0x1881525 "expected unqualified-id") at /home/miyuki/gcc/src/gcc/cp/parser.c:2741 #2 0x0076f949 in cp_parser_unqualified_id (parser=parser@entry=0x77ff5ab0, template_keyword_p=template_keyword_p@entry=false, check_dependency_p=check_dependency_p@entry=true, declarator_p=declarator_p@entry=true, optional_p=optional_p@entry=false) at /home/miyuki/gcc/src/gcc/cp/parser.c:5755 #3 0x0076fc16 in cp_parser_id_expression (parser=parser@entry=0x77ff5ab0, template_keyword_p=template_keyword_p@entry=false, check_dependency_p=check_dependency_p@entry=false, template_p=template_p@entry=0x0, declarator_p=declarator_p@entry=true, optional_p=false) at /home/miyuki/gcc/src/gcc/cp/parser.c:5430 #4 0x0076fd92 in cp_parser_declarator_id (parser=parser@entry=0x77ff5ab0, optional_p=optional_p@entry=false) at /home/miyuki/gcc/src/gcc/cp/parser.c:19782 #5 0x00771987 in cp_parser_direct_declarator (parser=parser@entry=0x77ff5ab0, dcl_kind=dcl_kind@entry=CP_PARSER_DECLARATOR_NAMED, ctor_dtor_or_conv_p=ctor_dtor_or_conv_p@entry=0x0, member_p=member_p@entry=false, friend_p=friend_p@entry=false) at /home/miyuki/gcc/src/gcc/cp/parser.c:19069 #6 0x00772670 in cp_parser_declarator (parser=parser@entry=0x77ff5ab0, dcl_kind=dcl_kind@entry=CP_PARSER_DECLARATOR_NAMED, ctor_dtor_or_conv_p=ctor_dtor_or_conv_p@entry=0x0, parenthesized_p=parenthesized_p@entry=0x0, member_p=member_p@entry=false, friend_p=friend_p@entry=false) at /home/miyuki/gcc/src/gcc/cp/parser.c:18734 #7 0x007725ac in cp_parser_declarator (parser=parser@entry=0x77ff5ab0, dcl_kind=dcl_kind@entry=CP_PARSER_DECLARATOR_NAMED, ctor_dtor_or_conv_p=ctor_dtor_or_conv_p@entry=0x7fffddf8, parenthesized_p=parenthesized_p@entry=0x0, member_p=member_p@entry=false, friend_p=friend_p@entry=false) at /home/miyuki/gcc/src/gcc/cp/parser.c:18713 #8 0x0077164a in cp_parser_direct_declarator (parser=parser@entry=0x77ff5ab0, dcl_kind=dcl_kind@entry=CP_PARSER_DECLARATOR_NAMED, ctor_dtor_or_conv_p=ctor_dtor_or_conv_p@entry=0x7fffddf8, member_p=member_p@entry=false, friend_p=friend_p@entry=false) at /home/miyuki/gcc/src/gcc/cp/parser.c:18962 #9 0x00772670 in cp_parser_declarator (parser=parser@entry=0x77ff5ab0, dcl_kind=dcl_kind@entry=CP_PARSER_DECLARATOR_NAMED, ctor_dtor_or_conv_p=ctor_dtor_or_conv_p@entry=0x7fffddf8, parenthesized_p=parenthesized_p@entry=0x0, member_p=member_p@entry=false, friend_p=friend_p@entry=false) at /home/miyuki/gcc/src/gcc/cp/parser.c:18734 #10 0x00794d4b in cp_parser_init_declarator (parser=parser@entry=0x77ff5ab0, decl_specifiers=decl_specifiers@entry=0x7fffde80, checks=checks@entry=0x0, function_definition_allowed_p=function_definition_allowed_p@entry=false, member_p=member_p@entry=false, declares_class_or_enum=0, function_definition_p=0x7fffde77, maybe_range_for_decl=0x0, init_loc=0x7fffde78) at /home/miyuki/gcc/src/gcc/cp/parser.c:18281 #11 0x0079592e in cp_parser_simple_declaration (parser=parser@entry=0x77ff5ab0, function_definition_allowed_p=function_definition_allowed_p@entry=false, maybe_range_for_decl=maybe_range_for_decl@entry=0x0) at /home/miyuki/gcc/src/gcc/cp/parser.c:12331 #12 0x0079602b in cp_parser_block_declaration (parser=0x77ff5ab0, statement_p=statement_p@entry=true) at /home/miyuki/gcc/src/gcc/cp/parser.c:12200 #13 0x007960ac in cp_parser_declaration_statement (parser=parser@entry=0x77ff5ab0) at /home/miyuki/gcc/src/gcc/cp/parser.c:11812 #14 0x00769343 in cp_parser_statement (parser=parser@entry=0x77ff5ab0, in_statement_expr=in_statement_expr@entry=, in_compound=in_compound@entry=true, if_p=if_p@entry=0x0, chain=chain@entry=0x0) at /home/miyuki/gcc/src/gcc/cp/parser.c:10494 #15 0x0076956a in cp_parser_statement_seq_opt (parser=parser@entry=0x77ff5ab0, in_statement_expr=in_statement_expr@entry=) at /home/miyuki/gcc/src/gcc/cp/parser.c:10772 #16 0x007696fa in cp_parser_compound_statement (parser=0x77ff5ab0, in_statement_expr=in_statement_expr@entry=, bcs_flags=, function_body=function_body@
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #4 from kottinge at utk dot edu --- Created attachment 37144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37144&action=edit m1
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #3 from kottinge at utk dot edu --- Created attachment 37143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37143&action=edit mod
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #5 from kottinge at utk dot edu --- Created attachment 37145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37145&action=edit m2
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #6 from kottinge at utk dot edu --- Created attachment 37146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37146&action=edit m3
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #7 from kottinge at utk dot edu --- Created attachment 37147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37147&action=edit m4
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #8 from kottinge at utk dot edu --- Created attachment 37148 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37148&action=edit m5
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #9 from kottinge at utk dot edu --- Created attachment 37149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37149&action=edit m6
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #10 from kottinge at utk dot edu --- Created attachment 37150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37150&action=edit m7
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #11 from kottinge at utk dot edu --- Created attachment 37151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37151&action=edit m8
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #12 from kottinge at utk dot edu --- Created attachment 37152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37152&action=edit m9
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #14 from kottinge at utk dot edu --- Created attachment 37154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37154&action=edit m11
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #13 from kottinge at utk dot edu --- Created attachment 37153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37153&action=edit m10
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #15 from kottinge at utk dot edu --- Created attachment 37155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37155&action=edit m12
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #18 from kottinge at utk dot edu --- Created attachment 37158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37158&action=edit m15
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #16 from kottinge at utk dot edu --- Created attachment 37156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37156&action=edit m13
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #17 from kottinge at utk dot edu --- Created attachment 37157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37157&action=edit m14
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #19 from kottinge at utk dot edu --- Created attachment 37159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37159&action=edit m16
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #20 from kottinge at utk dot edu --- Created attachment 37160 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37160&action=edit m17
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #21 from kottinge at utk dot edu --- Created attachment 37161 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37161&action=edit m18
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #23 from kottinge at utk dot edu --- Created attachment 37163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37163&action=edit m20
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #24 from kottinge at utk dot edu --- Created attachment 37164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37164&action=edit m21
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #22 from kottinge at utk dot edu --- Created attachment 37162 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37162&action=edit m19
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #25 from kottinge at utk dot edu --- Created attachment 37165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37165&action=edit m22
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #26 from kottinge at utk dot edu --- Created attachment 37166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37166&action=edit lib
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #27 from kottinge at utk dot edu --- Created attachment 37167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37167&action=edit driver
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 kottinge at utk dot edu changed: What|Removed |Added Attachment #37141|0 |1 is obsolete|| --- Comment #28 from kottinge at utk dot edu --- Created attachment 37168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37168&action=edit source file that has missing variable from only list
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #29 from kottinge at utk dot edu --- Created attachment 37169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37169&action=edit source file with missing variable from only list
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #30 from kottinge at utk dot edu --- Okay, I uploaded files for a working eaxmple. Trying to compile with: gfortran -I/usr/lib/openmpi/include -pthread -I/usr/lib/openmpi/lib -L/usr//lib -L/usr/lib/openmpi/lib -lmpi_f90 -lmpi_f77 -lmpi -ldl -lhwloc -o driver.exe -ggdb -ffree-line-length-none -fcheck=all -fbacktrace -cpp read_input_mod.f90 driver.f90 libread.a
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #31 from Dominique d'Humieres --- Sorry but what you provide is useless for the time I want to spend on this PR (you should use 'tar' for many files, so far son_struct_mod.mod is missing). Please provide a reduced test.
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #32 from kottinge at utk dot edu --- Created attachment 37170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37170&action=edit m26
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #33 from kottinge at utk dot edu --- I uploaded soln_struct_mod.mod I don't want to spend a lot of time on this either, and it's a complicated project and figuring out the minimal code to reproduce the error is likely to take a long time, because of all the dependencies. It specifically says not to use archives when uploading files...
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #34 from Dominique d'Humieres --- No read_input_mod.mod. Please work on a reduced test showing the issue. If you cannot do it at least provide a compressed tar of you project. So far we are both wasting our time!-(
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #35 from kottinge at utk dot edu --- read_input_mod is built from the source file read_input_mod.f90. It's the one with the bug
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #36 from Dominique d'Humieres --- > read_input_mod is built from the source file read_input_mod.f90. > It's the one with the bug I get an ICE when compiling this file SUBROUTINE READ_INPUT(s,input,inp_lines) 1 internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1084
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #37 from kottinge at utk dot edu --- Yeah that's what the bug is. The only problem with the file or at least what prevents it from compiling is the missing variable declaration on line 2648, but instead of saying there is a missing variable it provides some other error.
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #38 from Dominique d'Humieres --- > Yeah that's what the bug is. The only problem with the file or at least > what prevents it from compiling is the missing variable declaration > on line 2648, but instead of saying there is a missing variable it provides > some other error. An ICE may be an unhelpful error message, but it must be reported as such: it is a bug in the compiler code. Could you provide the source defining calc_param_mod and those it depends on? What is the missing variable declaration?
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #39 from kottinge at utk dot edu --- Created attachment 37171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37171&action=edit calc_param_mod
[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #40 from kottinge at utk dot edu --- I attached calc_param_mod.f90 (it's just a bunch of variable declarations). The missing variable declartion is commented out on line 2648 it's max_line_len2
[Bug fortran/69064] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when a variable is missing in "use *, only" list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 Dominique d'Humieres changed: What|Removed |Added Summary|Unhelpful error message |ICE: in |when a module variable was |gfc_typenode_for_spec, at |not included in the only|fortran/trans-types.c:1062 |list|when a variable is missing ||in "use *, only" list --- Comment #41 from Dominique d'Humieres --- Reduced test integer, parameter :: path_len = 50, max_line_len2 = 100 end module calc_param_mod subroutine setup_check_path(path) use calc_param_mod, only: path_len!, max_line_len2 IMPLICIT NONE character(len=path_len),intent(inout)::path character(len=max_line_len2)::line2 end I changed the summary to reflect the real issue.
[Bug fortran/69064] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when a variable is missing in "use *, only" list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #42 from graham.stott at btinternet dot com --- why the torrent of emails (spam)
[Bug fortran/69064] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when a variable is missing in "use *, only" list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #43 from Dominique d'Humieres --- > why the torrent of emails (spam) No spam, but not the best use of bugzilla!-(those who never sin can throw the first stone).
[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when a variable is missing in "use *, only" list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 Dominique d'Humieres changed: What|Removed |Added CC||kargl at gcc dot gnu.org Summary|ICE: in |[5/6 Regression] ICE: in |gfc_typenode_for_spec, at |gfc_typenode_for_spec, at |fortran/trans-types.c:1062 |fortran/trans-types.c:1062 |when a variable is missing |when a variable is missing |in "use *, only" list |in "use *, only" list --- Comment #44 from Dominique d'Humieres --- Up to revision r229283 the reduced test gave the error character(len=max_line_len2)::line2 1 Error: Symbol 'max_line_len2' at (1) has no IMPLICIT type At r229293 I get the ICE, likely revision r229287 or r229288.
[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when a variable is missing in "use *, only" list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #45 from Dominique d'Humieres --- Backtrace frame #10: 0x00010014c798 f951`gfc_typenode_for_spec(spec=0x000142203940) + 136 at trans-types.c:1062 frame #11: 0x00010014cb00 f951`gfc_sym_type(sym=0x000142203920) + 96 at trans-types.c:2158 frame #12: 0x0001000f7d31 f951`gfc_get_symbol_decl(sym=0x000142203920) + 1809 at trans-decl.c:1565 frame #13: 0x0001000fab08 f951`::generate_local_decl(sym=0x000142203920) + 808 at trans-decl.c:5149 frame #14: 0x0001000faf51 f951`(e=, sym=, f=)(gfc_expr *, gfc_symbol *, int *) + 65 at trans-decl.c:5097 frame #15: 0x000100038b9e f951`gfc_traverse_expr(expr=0x000142203df0, sym=0x000142203eb0, func=(f951`(null)(gfc_expr *, gfc_symbol *, int *) at trans-decl.c:5091), f=0)(gfc_expr*, gfc_symbol*, int*), int) + 46 at expr.c:4148 frame #16: 0x0001000fae73 f951`::generate_local_decl(gfc_symbol *) [inlined] generate_expr_decls(e=, sym=0x000142203eb0) + 17 at trans-decl.c:5104 frame #17: 0x0001000fae62 f951`::generate_local_decl(gfc_symbol *) frame #18: 0x0001000fae62 f951`::generate_local_decl(sym=0x000142203eb0) + 1666 frame #19: 0x0001000bf7d3 f951`::do_traverse_symtree(st=, st_func=, sym_func=(f951`::generate_local_decl(gfc_symbol *) at trans-decl.c:5138))(gfc_symtree *), void (*)(gfc_symbol *)) + 195 at symbol.c:3817 frame #20: 0x0001000fb847 f951`gfc_generate_function_code(ns=0x00014281a400) + 391 at trans-decl.c:5339 frame #21: 0x00010008d24c f951`gfc_parse_file() + 1644 at parse.c:5612 frame #22: 0x0001000d2cb6 f951`::gfc_be_parse_file() + 54 at f95-lang.c:201 frame #23: 0x00010097e89a f951`::compile_file() + 58 at toplev.c:464 frame #24: 0x000100d6dcce f951`toplev::main(int, char**) + 1146 at toplev.c:1985 frame #25: 0x000100d6d854 f951`toplev::main(this=, argc=2, argv=0x7fff5fbff318) + 724 frame #26: 0x000100d6f689 f951`main(argc=2, argv=0x7fff5fbff318) + 41 at main.c:39
[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 #6 from Iain Sandoe --- (In reply to Iain Sandoe from comment #5) > (In reply to r...@cebitec.uni-bielefeld.de from comment #4) > > Unfortunately, it doesn't work on Mac OS X 10.11.2: every link test > > FAILs with > > > > FAIL: 17_intro/freestanding.cc (test for excess errors) > > Excess errors: > > ld: warning: object file > > (/var/folders/1d/k16rgv6d5039jhvlj8_dzk4h00021y/T//cc0iIoOX.o) was built for > > newer OSX version (10.11.2) than being linked (10.11) > > > > I've found that while ld strips the micro version passed to > > -mmacosx_version_min, clang does not, resulting in this mess. > > hum. > > Given that ld(1) documents the version number format as ., > > for > > now it seems that gcc should only pass this to as and ld. > > ld < 85.2..ish didn't understand the minor. > > > Looking... So i've drafted a patch that pushes -asm_macosx_version_min=10.xx as a driver-only option and started to test it out as an add-on to your patch. Unfortunately, proving that the assembler accepts -mmacosx-version-min= .. doesn't prove that it ends up in the object. xc-7.2 (10.10, 11) does xc-6.2 (10.9) accepts -mmacosx-version-min= (with -q to invoke the llvm assembler) but the load command is not emitted. xc-5.1.1 (10.8) as per xc-6.2 .. right now I don't know if this is significant (except to my back-ported ld64-253.3) testing a patch, will post here when it's baked.
[Bug target/64402] mep-elf ICE in pre_and_rev_post_order_compute, at cfganal.c:1022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402
--- Comment #3 from Bernd Edlinger ---
Created attachment 37172
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37172&action=edit
Patch to fix ICE and make interrupt restore r0
This patch fixes the ICE and makes interrupt functions
also restore r0, which they did not do currently.
test case:
void __attribute__((interrupt))
intf(void)
{
asm("":::"$0", "$1");
}
$0 and $1 got saved, but only $1 got restored.
This would be fixed with this patch too.
Note that the MEP port is currently proposed to be
deprecated: https://gcc.gnu.org/ml/gcc/2015-12/msg00045.html
So, if you are actually using the mep port better speak up now.
[Bug c++/68926] [4.9/5/6 Regression] decltype and sfinae to check for template instance availability fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68926 --- Comment #3 from Grygoriy Fuchedzhy --- Created attachment 37173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37173&action=edit patch
[Bug c++/68926] [4.9/5/6 Regression] decltype and sfinae to check for template instance availability fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68926 Grygoriy Fuchedzhy changed: What|Removed |Added CC||jason at redhat dot com --- Comment #4 from Grygoriy Fuchedzhy --- Regression was introduced in git commit 6395f98e518629ec25c36a680a3ec080590fa949 (190653 svn). Attached patch fixes it for me. However it is probably not a proper fix for it.
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #34 from Sergei Trofimovich --- Wrote more details on how exactly things were broken: http://trofi.github.io/posts/189-glibc-on-ia64-or-how-relocations-bootstrap.html
[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when a variable is missing in "use *, only" list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #46 from Dominique d'Humieres --- Reverting revision r229287 removes the ICE and restores the error.
[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 Dominique d'Humieres changed: What|Removed |Added Summary|[5/6 Regression] ICE: in|[5/6 Regression] ICE: in |gfc_typenode_for_spec, at |gfc_typenode_for_spec, at |fortran/trans-types.c:1062 |fortran/trans-types.c:1062 |when a variable is missing |when LEN is set to a |in "use *, only" list |variable with no explicit ||type --- Comment #47 from Dominique d'Humieres --- Further reduced test subroutine setup_check_path(path) IMPLICIT NONE character(len=path_len),intent(inout)::path end The ICE has nothing to do with 'USE *, ONLY', updated summary.
[Bug c++/67533] internal compiler error: in build_call_a, at cp/call.c:372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67533
tbsaunde at gcc dot gnu.org changed:
What|Removed |Added
CC||tbsaunde at gcc dot gnu.org
--- Comment #4 from tbsaunde at gcc dot gnu.org ---
minimal test case:
struct Tls {};
void _ZTW5mytls();
thread_local Tls mytls = mytls
It seems like the problem is the c++ fe doesn't expect _ZTW5mytls to be
prototyped by user code.
[Bug c++/69066] New: SFINAE compilation error on lambda with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69066
Bug ID: 69066
Summary: SFINAE compilation error on lambda with trailing
return type
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
auto bound_f = [=](auto... xs) -> decltype(f(x, xs...))
{
return f(x, xs...);
};
return curry_impl{}>::exec(bound_f);
---
`is_zero_callable` is a type-trait like struct making use of `void_t` detection
techniques.
clang++ compiles the code correctly and triggers SFINAE thanks to `bound_f`'s
explicit trailing return type.
g++ fails to compile the code (see godbolt example).
---
Example on gcc.godbolt.org: https://goo.gl/2hWTTN
Additional information: http://stackoverflow.com/a/34484150/598696
[Bug c++/44577] static local variables in class template methods are not optimized-away if not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44577 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from tbsaunde at gcc dot gnu.org --- gcc now removes class_template when optimizing so fixed.
[Bug driver/66657] Feature request - assembly output from lto compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66657 --- Comment #4 from Andrew Pinski --- You can use -save-temps and look at the .s files.
[Bug driver/66657] Feature request - assembly output from lto compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66657 --- Comment #5 from Andrew Pinski --- You can use -save-temps and look at the .s files. >To identify errant calls to printf and puts. For this you can also do use the attribute warning and do it at compile time rather than assembly time. There are other tricks too.
[Bug c++/67461] Multiple atomic stores generate a StoreLoad barrier between each one, not just at the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67461 --- Comment #1 from Andrew Pinski --- Hmm, I think there needs to be a barrier between each store as each store needs to be observed by the other threads.
[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-28 Component|libgomp |c Ever confirmed|0 |1 Severity|normal |enhancement
[Bug target/65128] remove "linux" and "unix" from preprocessor macros from cpp-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65128 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc-5.3.0/cpp/System-specific-Predefined-Macros.html#System-specific-Predefined-Macros The C standard requires that all system-specific macros be part of the reserved namespace. All names which begin with two underscores, or an underscore and a capital letter, are reserved for the compiler and library to use as they wish. However, historically system-specific macros have had names with no special prefix; for instance, it is common to find unix defined on Unix systems. For all such macros, GCC provides a parallel macro with two underscores added at the beginning and the end. If unix is defined, __unix__ will be defined too. There will never be more than two underscores; the parallel of _mips is __mips__. We are slowly phasing out all predefined macros which are outside the reserved namespace. You should never use them in new programs, and we encourage you to correct older code to use the parallel macros whenever you find it. We don't recommend you use the system-specific macros that are in the reserved namespace, either. It is better in the long run to check specifically for features you need, using a tool such as autoconf.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-28 Ever confirmed|0 |1 --- Comment #17 from Andrew Pinski --- Is this working now?
[Bug middle-end/67532] Add -fno-plt=file and -fno-plt=[symbol,...]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67532 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|middle-end Severity|normal |enhancement
[Bug tree-optimization/66264] [untaken optimization] switch & enums without default-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66264
--- Comment #3 from Andrew Pinski ---
enum Foo { A,B,C,D };
int square(Foo f) {
switch (f) {
case A: return 33;
case B: return 24;
case C: return 857;
case D: return 980;
//default: return 0;
};
//return 0; // uncomment this to get the fast code
}
Just in case the goo.gl link goes away.
[Bug tree-optimization/66264] [untaken optimization] switch & enums without default-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66264 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-28 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug c++/64615] Access level check error: g++ thinks the non default ctor is protected while its public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64615 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-28 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/65412] missing control flow optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65412 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-28 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/69067] New: [6 Regression] ICE in get_def_bb_for_const, at graphite-isl-ast-to-gimple.c:1995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69067
Bug ID: 69067
Summary: [6 Regression] ICE in get_def_bb_for_const, at
graphite-isl-ast-to-gimple.c:1995
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
lto1 binary from at least gcc-6.0.0-alpha20151220 and gcc-6.0.0-alpha20151227
ICEs when compiling the following reduced snippet w/ -O[12]
-floop-nest-optimize -flto:
int a1, c1, cr, kt;
int aa[2];
int
ce()
{
while (a1 < 1) {
int g8;
for (g8 = 0; g8 < 3; ++g8)
if (c1 != 0)
cr = aa[a1 * 2] = kt;
for (c1 = 0; c1 < 2; ++c1)
aa[c1] = cr;
++a1;
}
return 0;
}
int
main(void)
{
return ce(aa);
}
% gcc-6.0.0-alpha20151227 -O1 -floop-nest-optimize -flto z1xrkum2.c
z1xrkum2.c: In function 'ce':
z1xrkum2.c:5:1: internal compiler error: in get_def_bb_for_const, at
graphite-isl-ast-to-gimple.c:1995
ce()
^
I guess, LTO infrastructure is really only a trigger here.
[Bug tree-optimization/69068] New: [6 Regression] ICE in bb_contains_loop_phi_nodes, at graphite-isl-ast-to-gimple.c:1279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69068
Bug ID: 69068
Summary: [6 Regression] ICE in bb_contains_loop_phi_nodes, at
graphite-isl-ast-to-gimple.c:1279
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
At least gcc-6.0.0-alpha20151220 and gcc-6.0.0-alpha20151227 ICE when compiling
the following reduced snippet w/ -O1 -floop-nest-optimize:
int qo;
int zh[2];
void
td(void)
{
int ly, en;
for (ly = 0; ly < 2; ++ly)
for (en = 0; en < 2; ++en)
zh[en] = ((qo == 0) || (((qo * 2) != 0))) ? 1 : -1;
}
% gcc-6.0.0-alpha20151227 -O1 -floop-nest-optimize -c kj3xpeme.c
kj3xpeme.c: In function 'td':
kj3xpeme.c:5:1: internal compiler error: in bb_contains_loop_phi_nodes, at
graphite-isl-ast-to-gimple.c:1279
td(void)
^~
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-28 Ever confirmed|0 |1 Severity|minor |enhancement --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug c/67820] Move obscure warning about null pointers into prime time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67820 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- I have almost always seen people use -Wall -W (-W is another name for -Wextra) so it is already in the prime time as far as I know.
[Bug debug/67665] ICE when passing two empty files directly to cc1 with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67665 --- Comment #1 from Andrew Pinski --- This looks like a left over from --combine where cc1 does not reject more than one file.
[Bug debug/67665] ICE when passing two empty files directly to cc1 with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67665 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-28 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- .
[Bug c/67665] ICE when passing two empty files directly to cc1 with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67665 --- Comment #3 from Andrew Pinski --- For C++ we produce: foo.c:1:0: fatal error: inter-module optimizations not implemented for C++ but really this should also be done for C now too.
[Bug c++/67395] It is possible to override c++ access control in case of indirect inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67395
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid,
||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-28
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
I think it is choosing the wrong v.
Here is a testcase which shows why:
#include
using namespace std;
class a {
protected:
int v{0};
};
class b : public a { };
class c : private a { };
class d : public c, public b {
public:
d() {
cout << b::a::v << "\n";
}
};
int main() {
d testcase{};
}
--- CUT ---
Here I qualify which a I am talking about but GCC still says:
t99.cc: In constructor ‘d::d()’:
t99.cc:13:17: error: ‘a’ is an ambiguous base of ‘d’
cout << b::a::v << "\n";
^
Confirmed.
[Bug c/67820] Move obscure warning about null pointers into prime time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67820 --- Comment #2 from David Binderman --- >I have almost always seen people use -Wall -W Doubtful. Looking at a bunch of recent Fedora package builds $ fgrep -l Wextra fedora/pass78/201512*/* | wc -l 35 $ fgrep -l Wall fedora/pass78/201512*/* | wc -l 589 On an earlier and bigger set of builds: $ fgrep -l Wextra fedora/pass77/2015*/* | wc -l 523 $ fgrep -l Wall fedora/pass77/2015*/* | wc -l 5983 $ So about 6% in the first case and 9% in the second case. Even allowing for the -W to -Wextra change, neither of these numbers look to me like "almost always". It looks to me like lots of folks use -Wall, but few folks use -Wextra.
[Bug c/67820] Move obscure warning about null pointers into prime time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67820 --- Comment #3 from Andrew Pinski --- (In reply to David Binderman from comment #2) > >I have almost always seen people use -Wall -W > > Doubtful. Looking at a bunch of recent Fedora package builds > > $ fgrep -l Wextra fedora/pass78/201512*/* | wc -l > 35 > $ fgrep -l Wall fedora/pass78/201512*/* | wc -l > 589 > > On an earlier and bigger set of builds: > > $ fgrep -l Wextra fedora/pass77/2015*/* | wc -l > 523 > $ fgrep -l Wall fedora/pass77/2015*/* | wc -l > 5983 > $ > Did you grep for -W ? Because I bet there are a lot more people who use that instead of -Wextra. Seriously -W has been wildly in use for years (over 20 years now) and people would use that over -Wextra because the code is older than -Wextra was added to GCC.
[Bug c/67665] ICE when passing two empty files directly to cc1 with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67665 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- I have a fix which moves around an error and allows for this to error out now.
