[Bug c++/87427] -Wclass-memaccess improvement for POD with convenience initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87427 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Martin Sebor --- A common C idiom is struct S *p = (struct S*)malloc (sizeof *p); memset (p, 0, sizeof *p); When such code is being ported to C++, or when C programmers are writing analogous code in C++, it's not unusual to make the mistake of assuming that the same code will work unchanged even when struct S has a default constructor (or forget that it does, or add one and forget to change the dynamic initialization). That's not the case with a struct like the one in the example in comment #0, and the warning helps detect this mistake. We would not want to weaken the warning to prevent detecting it. In our view, memset (and other raw memory functions) are low-level primitives designed for manipulating object representation at the byte level. They should not be used with higher-level abstractions. The preferred way to initialize objects of non-trivial types is by using their ctors, and that's what the warning is meant to encourage.
[Bug target/87358] [8/9 Regression] ICE when -mtune=thunderx2t99 applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87358 --- Comment #9 from Lijian Zhang --- Hi Andrew, I only reproduced this issue with gcc-7.3.0, but not able to reproduce the failure with gcc-8.2.0/gcc-8.1.0 But from your description, gcc-8.2.0 still have this issue, and this issue is target to be fixed in gcc-8.3.0? Thanks.
[Bug target/87391] [RISCV] -march=rv32i -mabi=ilp32e is erroneously accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391 --- Comment #3 from Jim Wilson --- Author: wilson Date: Tue Sep 25 01:27:06 2018 New Revision: 264555 URL: https://gcc.gnu.org/viewcvs?rev=264555=gcc=rev Log: RISC-V: Fix problems with ilp32e ABI support. gcc/ PR target/87391 * config/riscv/riscv.h (STACK_BOUNDARY): Test riscv_abi == ABI_ILP32E not TARGET_RVE. (ABI_STACK_BOUNDARY, MAX_ARGS_IN_REGISTERS): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/riscv/riscv.h
[Bug c++/87380] Explicit instantations should use weak symbols on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380 --- Comment #14 from mrs at gcc dot gnu.org --- You can test it if you can dump the ar symbol table, with a assembled .s file. Nothing needs to work except the assembler and ar and the tool to dump the symbol table. In the olden days, there was no entry for the weak symbol. I was wondering around trying to recall which tool dumps the ar symbol table, no well; it seems like I used to know how to dump it, but haven't in years.
[Bug c++/87380] Explicit instantations should use weak symbols on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380 --- Comment #13 from mrs at gcc dot gnu.org --- Ah, yes, likely it would be ar that has changed. Anyway, the ld version is a cheap indirect proxy for bugs in ar. We're likely to get new ar versions with new ld versions. A real config test is fine as well.
[Bug c++/87380] Explicit instantations should use weak symbols on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #12 from mrs at gcc dot gnu.org ---
I changed the test case around, and the linker seems to be able to resolve from
a .a now:
$ ar -q liblib.a lib.o
$ nm -m liblib.a
liblib.a(lib.o):
0020 (__TEXT,__eh_frame) non-external EH_frame1
(__TEXT,__text) external __Z5matchPi
0018 (__DATA,__data) weak external __ZN1AIiE6memberE
$ nm main.o
0018 s EH_frame1
U __ZN1AIiE6memberE
T _main
$ ../gcc/xgcc -B../gcc main.cc -L. -llib -o t -lstdc++
so, I think this is now safe to flip with later linkers. Some type of code
like:
if (darwin_target_linker
&& (strverscmp (darwin_target_linker, "409.12") >= 0))
I think will do it. We just need to figure out when the bug was fixed. I
tested 409.12. This is the linker included with Xcode 10.0, which is the now
current Xcode. Jack or Iain might have access to older systems.
up:t mrs$ cat lib.cc
#define LIB
#include "lib.h"
template class A;
bool match(int* p)
{
return p == ::member;
}
up:t mrs$ cat lib.h
template
struct A {
static T member;
};
template
T A::member;
bool match(int*);
#ifndef LIB
extern template class A;
#endif
up:t mrs$ cat main.cc
#include "lib.h"
extern char _ZN1AIiE6memberE[3];
int main()
{
void *vp = _ZN1AIiE6memberE;
// if (!match(::member))
//throw 1;
}
is the type of test case I tried. This is _with_ the change
TARGET_WEAK_NOT_IN_ARCHIVE_TOC to make it 0. This is required to get the
symbol weak.
[Bug target/87358] [8/9 Regression] ICE when -mtune=thunderx2t99 applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87358 Andrew Pinski changed: What|Removed |Added Version|7.3.0 |8.2.0 Resolution|MOVED |FIXED Target Milestone|--- |8.3 Summary|ICE when|[8/9 Regression] ICE when |-mtune=thunderx2t99 applied |-mtune=thunderx2t99 applied --- Comment #8 from Andrew Pinski --- So there was two crashes, one which was due to Linaro not backporting the fix and the other part was another crash which was just a bug. I Fixed that bug: https://gcc.gnu.org/ml/gcc-cvs/2018-09/msg00525.html https://gcc.gnu.org/ml/gcc-cvs/2018-09/msg00530.html
[Bug target/87391] [RISCV] -march=rv32i -mabi=ilp32e is erroneously accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson --- One can specify an architecture with FP registers, and an ABI that does not use the FP registers. By the same token, it is reasonable to expect that one should be able to specify an rv32i architecture and use an rv32e ABI with it. In both cases, the unused registers all become call clobbered (aka caller saved). If we go with this interpretation, then the issue here is that we have some architecture checks for TARGET_RVE that should instead be ABI checks for riscv_abi == ABI_ILP32E.
[Bug target/87391] [RISCV] -march=rv32i -mabi=ilp32e is erroneously accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-25 Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/87380] Explicit instantations should use weak symbols on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380 --- Comment #11 from Iain Sandoe --- (In reply to m...@gcc.gnu.org from comment #10) > I've related 15428 which has some details for why this is the way it is. > > Unless the underlying bug has been fixed in the linker, changing this will > merely re-introduce the previous bug that was fixed. If we do that, we need > to weigh which feature we want to work and which to break. The previous > answer, was to make static linking work. > > See 2004-06-03 Matt Austern and 2004-03-12 Matt > Austern for the totality of the code. Yup .. I've been looking at that. We already have the linker version, so should be able to make an intelligent choice. However, as I read the original bug (against powerpc-darwin7), it might actually be ar that's the problem - since it's the presence of weak extern symbols in the archive TOC that's the issue. If that's the case, I'm sure we can run a config. test to see if ar meets the criteria. Anyway, trying to work my way back to a cut-off point (I don't have an easy way to test if powerpc-darwin7 will actually bootstrap any recent GCC - but suspect that it will not without an updated as/ld at minimum).
[Bug c++/87380] Explicit instantations should use weak symbols on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380 mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=15428 --- Comment #10 from mrs at gcc dot gnu.org --- I've related 15428 which has some details for why this is the way it is. Unless the underlying bug has been fixed in the linker, changing this will merely re-introduce the previous bug that was fixed. If we do that, we need to weigh which feature we want to work and which to break. The previous answer, was to make static linking work. See 2004-06-03 Matt Austern and 2004-03-12 Matt Austern for the totality of the code.
[Bug c++/87427] New: -Wclass-memaccess improvement for POD with convenience initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87427
Bug ID: 87427
Summary: -Wclass-memaccess improvement for POD with convenience
initializer
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
#include
struct S { int z; S() { z = 1; } } s;
int main() { memset(, 0, sizeof(s)); }
The rationale of -Wclass-memaccess as presented in the manpage ("Modifying the
representation of such objects may violate invariants maintained by member
functions") is sound.
For the 3-liner example though, it could be argued that member functions do not
guarantee any invariant, given all member variables are public and kinda invite
direct access.
Would it be considered worthwhile to have a, say,
-Wclass-memaccess=except-struct, to relax the warning for types that satisfy
(standard_layout && (all members are public) && (all members are non-const))?
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #4 from sameerad at gcc dot gnu.org --- I am having a look at this issue.
[Bug bootstrap/87417] [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417 Gerald Pfeifer changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||i386-unknown-freebsd10.4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-24 CC||gerald at pfeifer dot com Host|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||i386-unknown-freebsd10.4 Ever confirmed|0 |1 Build|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||i386-unknown-freebsd10.4 --- Comment #7 from Gerald Pfeifer --- Same for i386-unknown-freebsd10.4.
[Bug bootstrap/87417] [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417 --- Comment #6 from Ilya Leoshkevich --- Candidate patch here: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01382.html
[Bug bootstrap/87417] [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417 --- Comment #5 from Ilya Leoshkevich --- Ok, makes sense. I've just made a patch that adds the 5th, but it had to be special-cased for GENERATOR_FILE, and thus doesn't look too nice. FORMAT[0] == 'w' looks much cleaner.
[Bug bootstrap/87417] [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Ilya Leoshkevich from comment #3) > Apparently allocated EQ_ATTR_ALT is smaller than I expect: 16 bytes are > clearly not enough to contain rtx_def and 2 HOST_WIDE_INTs. Yeah, the rtx_code_size[] definition in rtl.c needs to handle EQ_ATTR_ALT. Sorry for missing that in the review. Originally that test only handled two codes. Now that there are five it needs to handle, it might more sense to use: FORMAT[0] == 'w' instead of specific code checks, since there's a requirement that either all fields must be 'w' or none can be.
[Bug c/87392] UBSAN behavior on left-shifting 1 into the sign bit is dependent on C standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87392 --- Comment #5 from Eugeniu Rosca --- Hi Andrew, Thanks for the much more satisfying answer. > In C90, it was implemented defined behavior (while in C99 and above it is > undefined behavior). I trust you, but why not giving a reference to the source? Based on my reading of the C89 draft, it should be based on Chapter "A.6.3 Implementation-defined behavior", more specifically subchapter "A.6.3.4 Integers" saying: * The results of bitwise operations on signed integers (3.3). > See the thread which added undefined santizer: > https://gcc.gnu.org/ml/gcc-patches/2013-06/msg00275.html That turned to be a useful reference. +1. > YES there is a huge difference between the languages It's helpful to see you putting such an emphasis on the difference between the standards. > which cannot be changed now as that would be requiring to change C90. IMHO a valid scenario would also be not touching C89/C90, but correcting C11 so that "left-shifting into the sign bit" becomes defined or implementation-defined. To my knowledge, such kind of step actually exists in the form of DR463 entry in the "Defect Report Summary for C11" (see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_463 ), which tried "Harmonizing left-shift with C++14". The latter considers "left-shifting into the sign bit" as defined behavior. >> ANSI C > ANSI C is ISO C. ANSI is a member of ISO. I think you meant to write ANSI > C89 there :). By "ANSI C" I mean C89/C90 and so do references [14-16], so it's quite surprising we are not on the same page. Before I consider this topic closed, I kindly ask you to provide below feedback which I will share with U-Boot people: - Since U-Boot is compiled using '-std=gnu11' and since UBSAN reports (1 << 31) as undefined behavior and since C11 standard says that encountering an UB the compiler may "ignore the situation completely with unpredictable results", what are there real-life issues expected from shifting signed integers into (*not past*) the sign bit? What to expect in the worst case? - Is it possible to provide a sample code which would showcase that "left-shifting into the sign bit" can lead to program behavior being erroneous, unexpected or dependent on the gcc optimization level? For example, we know [17] that "(a + 1 > a)" can lead to surprising results depending on whether the program is compiled with "-fwrapv" or not. Are there any similar examples involving '<<' ? This would be of extreme help for U-Boot community. - What would be your personal choice between '-std=gnu89' (still used by Linux kernel) and '-std=gnu11' (used in U-Boot/coreboot), given your GCC experience gathered so far? Thank you in advance. Best regards, Eugeniu. [14] https://en.wikipedia.org/wiki/ANSI_C This (C89) version of the language is often referred to as "ANSI C" [15] https://stackoverflow.com/a/3783805/2381750 In common parlance, the phrase "ANSI C" usually refers to C89. [16] https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/C-Dialect-Options.html#C-Dialect-Options In C mode, this (-ansi) is equivalent to -std=c90. [17] http://thiemonagel.de/2010/01/signed-integer-overflow/
[Bug c/80868] "Duplicate const" warning emitted in `const typeof(foo) bar;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868 --- Comment #5 from Nick Desaulniers --- Oh, note in the typedef case: typedef const int t; const t x; It seems that for -std=c89 (non pedantic, non GNU), GCC does not warn. That seems to violate C90 6.5.3 constraints: "The same type qualifier shall not appear more than once in the same specifier-list or qualifier-list, either directly or via one or more typedefs."
[Bug c/87426] c_parser_unary_expression ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87426
--- Comment #1 from SztfG at yandex dot ru ---
reduced testcase
int arr[1] ={ 0 };
int test(int a)
{
return (arr[abs(a)]);
}
[Bug bootstrap/87417] [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417 --- Comment #3 from Ilya Leoshkevich --- Valgrind has found an issue: ==12738== Invalid write of size 4 ==12738==at 0x804CC48: attr_rtx_1 (genattrtab.c:518) ==12738==by 0x804CC48: attr_rtx(rtx_code, ...) (genattrtab.c:588) ==12738==by 0x804EA6D: mk_attr_alt (genattrtab.c:2406) ==12738==by 0x804EA6D: check_attr_test(file_location, rtx_def*, attr_desc*) (genattrtab.c:709) ==12738==by 0x804EBBF: check_attr_value(file_location, rtx_def*, attr_desc*) (genattrtab.c:945) ==12738==by 0x804A0AA: check_defs (genattrtab.c:1108) ==12738==by 0x804A0AA: main (genattrtab.c:5253) ==12738== Address 0x6d79aa0 is 0 bytes after a block of size 16 alloc'd ==12738==at 0x402E27C: malloc (vg_replace_malloc.c:299) ==12738==by 0x8064FD3: xmalloc (xmalloc.c:147) ==12738==by 0x805233E: ggc_internal_alloc (ggc.h:130) ==12738==by 0x805233E: ggc_alloc_rtx_def_stat (ggc.h:275) ==12738==by 0x805233E: rtx_alloc_stat_v(rtx_code, int) (rtl.c:209) ==12738==by 0x805236D: rtx_alloc(rtx_code) (rtl.c:233) ==12738==by 0x804CC39: attr_rtx_1 (genattrtab.c:516) ==12738==by 0x804CC39: attr_rtx(rtx_code, ...) (genattrtab.c:588) ==12738==by 0x804EA6D: mk_attr_alt (genattrtab.c:2406) ==12738==by 0x804EA6D: check_attr_test(file_location, rtx_def*, attr_desc*) (genattrtab.c:709) ==12738==by 0x804EBBF: check_attr_value(file_location, rtx_def*, attr_desc*) (genattrtab.c:945) ==12738==by 0x804A0AA: check_defs (genattrtab.c:1108) ==12738==by 0x804A0AA: main (genattrtab.c:5253) Apparently allocated EQ_ATTR_ALT is smaller than I expect: 16 bytes are clearly not enough to contain rtx_def and 2 HOST_WIDE_INTs.
[Bug c/87426] New: c_parser_unary_expression ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87426
Bug ID: 87426
Summary: c_parser_unary_expression ICE
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: SztfG at yandex dot ru
Target Milestone: ---
testcase:
#include
#include
//#include
static const uint32_t pow2[511] ={ 0 }; // doesnt matter
#define SQR(x) pow2[x]
uint16_t mul8b(uint8_t a, uint8_t b)
{
return (SQR((uint16_t)a+(uint16_t)b) - SQR(abs((int16_t)a-(int16_t)b))) >>
2;;
}
prog.c: In function 'mul8b':
prog.c:12:46: warning: implicit declaration of function 'abs'
[-Wimplicit-function-declaration]
12 | return (SQR((uint16_t)a+(uint16_t)b) - SQR(abs((int16_t)a-(int16_t)b)))
>> 2;;
| ^~~
prog.c:8:21: note: in definition of macro 'SQR'
8 | #define SQR(x) pow2[x]
| ^
prog.c:12:3: internal compiler error: Segmentation fault
12 | return (SQR((uint16_t)a+(uint16_t)b) - SQR(abs((int16_t)a-(int16_t)b)))
>> 2;;
| ^~
0xa31cbf crash_signal
../../source/gcc/toplev.c:325
0x5f8606 warn_for_abs
../../source/gcc/c/c-parser.c:9226
0x5f8606 c_parser_postfix_expression_after_primary
../../source/gcc/c/c-parser.c:9318
0x5ea523 c_parser_postfix_expression
../../source/gcc/c/c-parser.c:9006
0x5f2f27 c_parser_unary_expression
../../source/gcc/c/c-parser.c:7266
0x5f416f c_parser_cast_expression
../../source/gcc/c/c-parser.c:7110
0x5f43e6 c_parser_binary_expression
../../source/gcc/c/c-parser.c:6913
0x5f52f5 c_parser_conditional_expression
../../source/gcc/c/c-parser.c:6647
0x5f5830 c_parser_expr_no_commas
../../source/gcc/c/c-parser.c:6564
0x5f5a82 c_parser_expression
../../source/gcc/c/c-parser.c:9460
0x5f7fb7 c_parser_postfix_expression_after_primary
../../source/gcc/c/c-parser.c:9272
0x5ea523 c_parser_postfix_expression
../../source/gcc/c/c-parser.c:9006
0x5f2f27 c_parser_unary_expression
../../source/gcc/c/c-parser.c:7266
0x5f416f c_parser_cast_expression
../../source/gcc/c/c-parser.c:7110
0x5f4580 c_parser_binary_expression
../../source/gcc/c/c-parser.c:7036
0x5f52f5 c_parser_conditional_expression
../../source/gcc/c/c-parser.c:6647
0x5f5830 c_parser_expr_no_commas
../../source/gcc/c/c-parser.c:6564
0x5f5a82 c_parser_expression
../../source/gcc/c/c-parser.c:9460
0x5ea67b c_parser_postfix_expression
../../source/gcc/c/c-parser.c:7968
0x5f2f27 c_parser_unary_expression
../../source/gcc/c/c-parser.c:7266
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/87425] New: [9 Regression] ICE with virtual assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87425
Bug ID: 87425
Summary: [9 Regression] ICE with virtual assignment operator
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, mpolacek at gcc dot gnu.org
Target Milestone: ---
The following valid code snippet (compiled with "-std=c++2a") triggers an ICE
on trunk:
=
struct A
{
virtual A& operator= (int);
};
struct B
{
A a;
B() { a = 0; }
};
=
bug.cc: In constructor 'B::B()':
bug.cc:9:14: internal compiler error: Segmentation fault
9 | B() { a = 0; }
| ^
0xed7eef crash_signal
../../gcc/gcc/toplev.c:325
0x8760fc tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3112
0x8760fc cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4821
0x8791be cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:5018
0x87c6fc maybe_constant_init_1
../../gcc/gcc/cp/constexpr.c:5366
0x8914f0 cp_get_fndecl_from_callee(tree_node*, bool)
../../gcc/gcc/cp/cvt.c:967
0x8915fb maybe_warn_nodiscard
../../gcc/gcc/cp/cvt.c:1016
0x891ea7 convert_to_void(tree_node*, impl_conv_void, int)
../../gcc/gcc/cp/cvt.c:1398
0x9c15a0 finish_expr_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:686
0x93e977 cp_parser_statement
../../gcc/gcc/cp/parser.c:10963
0x93fe98 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11302
0x93ff7f cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11256
0x956100 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21930
0x956100 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21967
0x956970 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26982
0x9585ec cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:27862
0x94b1ff cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22906
0x94c1eb cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22932
0x94c1eb cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16920
0x958d19 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13757
Please submit a full bug report, [etc.]
This seems to be related to PR87398.
[Bug bootstrap/87417] [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417 --- Comment #2 from Ilya Leoshkevich --- Fails on i686-linux-gnu: *** Error in `build/genattrtab': malloc(): memory corruption: 0x08e56da0 *** === Backtrace: = /lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xf755c38a] /lib/i386-linux-gnu/libc.so.6(+0x6dfc7)[0xf7562fc7] /lib/i386-linux-gnu/libc.so.6(+0x6ff82)[0xf7564f82] /lib/i386-linux-gnu/libc.so.6(__libc_malloc+0xc5)[0xf7566bf5] build/genattrtab[0x8064fd4] build/genattrtab[0x805233f] build/genattrtab[0x805236e] build/genattrtab[0x804cc3a] build/genattrtab[0x804ea6e] build/genattrtab[0x804ebc0] build/genattrtab[0x804a0ab] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xf750d286] build/genattrtab[0x804ba27] === Memory map: 08048000-08091000 r-xp 00:21 29450225 /Users/beep/ibm/gcc/host-x86_64-pc-linux-gnu/gcc/build/genattrtab 08092000-08093000 r--p 00049000 00:21 29450225 /Users/beep/ibm/gcc/host-x86_64-pc-linux-gnu/gcc/build/genattrtab 08093000-08097000 rw-p 0004a000 00:21 29450225 /Users/beep/ibm/gcc/host-x86_64-pc-linux-gnu/gcc/build/genattrtab 08097000-0809b000 rw-p 00:00 0 08452000-08eef000 rw-p 00:00 0 [heap] f710-f7121000 rw-p 00:00 0 f7121000-f720 ---p 00:00 0 f72af000-f73b1000 rw-p 00:00 0 f73ce000-f73ea000 r-xp 00:2b 74 /lib/i386-linux-gnu/libgcc_s.so.1 f73ea000-f73eb000 r--p 0001b000 00:2b 74 /lib/i386-linux-gnu/libgcc_s.so.1 f73eb000-f73ec000 rw-p 0001c000 00:2b 74 /lib/i386-linux-gnu/libgcc_s.so.1 f73f1000-f74f5000 rw-p 00:00 0 f74f5000-f76a6000 r-xp 00:2b 43 /lib/i386-linux-gnu/libc-2.24.so f76a6000-f76a8000 r--p 001b 00:2b 43 /lib/i386-linux-gnu/libc-2.24.so f76a8000-f76a9000 rw-p 001b2000 00:2b 43 /lib/i386-linux-gnu/libc-2.24.so f76a9000-f76ac000 rw-p 00:00 0 f76ac000-f76ff000 r-xp 00:2b 88 /lib/i386-linux-gnu/libm-2.24.so f76ff000-f770 r--p 00052000 00:2b 88 /lib/i386-linux-gnu/libm-2.24.so f770-f7701000 rw-p 00053000 00:2b 88 /lib/i386-linux-gnu/libm-2.24.so f7705000-f7709000 rw-p 00:00 0 f7709000-f770b000 r--p 00:00 0 [vvar] f770b000-f770c000 r-xp 00:00 0 [vdso] f770c000-f772f000 r-xp 00:2b 36 /lib/i386-linux-gnu/ld-2.24.so f772f000-f773 r--p 00022000 00:2b 36 /lib/i386-linux-gnu/ld-2.24.so f773-f7731000 rw-p 00023000 00:2b 36 /lib/i386-linux-gnu/ld-2.24.so fffc5000-fffe7000 rw-p 00:00 0 [stack]
[Bug target/87414] -mindirect-branch=thunk produces thunk with incorrect CFI on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87414 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-24 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 44744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44744=edit gcc9-pr87414.patch Untested fix.
[Bug tree-optimization/87424] New: inlining context absent from missing nul warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87424
Bug ID: 87424
Summary: inlining context absent from missing nul warnings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The "missing terminating nul" warning newly issued by GCC 9 is missing inlining
context, making it difficult to determine which strlen call is the cause of the
problem.
$ cat d.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout d.c
static inline int f (const char *s)
{
return __builtin_strlen (s); // absent from diagnostic output
}
const char a[3] = { '1', '2', '3' };
int g (void)
{
return f (a);
}
d.c: In function ‘g’:
d.c:10:13: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
10 | return f (a);
| ^
d.c:6:12: note: referenced argument declared here
6 | const char a[3] = { '1', '2', '3' };
|^
;; Function g (g, funcdef_no=1, decl_uid=1910, cgraph_uid=2, symbol_order=2)
g ()
{
long unsigned int _2;
int _3;
[local count: 1073741824]:
_2 = __builtin_strlen ();
_3 = (int) _2;
return _3;
}
[Bug bootstrap/87417] [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417 --- Comment #1 from Ilya Leoshkevich --- Ouch! Somehow s2 got corrupted (the 2nd value can be either 0 or 1). I'm looking at this now.
[Bug tree-optimization/87422] duplicate warning for strcpy of an unterminated character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87422 Martin Sebor changed: What|Removed |Added CC||law at redhat dot com --- Comment #1 from Martin Sebor --- Jeff, this seems to have crept in during the integration of my original patch (it issues just a single instance of the warning).
[Bug c++/87406] Implement -Wconstant-conversion and -Wbitfield-constant-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87406
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to Jonathan Wakely from comment #1)
> We do warn about this, but only with -Wconversion which is not in -Wall or
> -Wextra
>
> c.cc:1:24: warning: conversion to ‘char’ from ‘int’ may alter its value
> [-Wconversion]
> char f(int i) { return i; }
This is not the "constant" case. A testcase would be:
char foo(void) {
return 132;
}
: In function 'char square()':
:3:12: warning: conversion from 'int' to 'char' changes value from
'132' to ''\3777604'' [-Wconversion]
return 132;
^~~
I think the constant case should be safe for -Wall. It is a just a matter of
adding more specific flags.
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #29 from Eric Botcazou --- > gnatlink is _never_ a shell script though but, yes, it's apparently the > usual mess with Unix paths on Windows. It seems that some paths are properly translated though, for example the library paths. Do you know why? It would be nice to have the gnatlink command line that gave rise to the invocation quoted in the dump screen.
[Bug target/87421] GCC generates unaligned movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421 Yuxuan Shui changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Yuxuan Shui --- Sorry, you are totally right. I misunderstood the ABI definition.
[Bug c++/87407] Enhance -Wunused-function to handle also inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87407 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #12 from Manuel López-Ibáñez --- (In reply to Richard Biener from comment #11) > I agree that we can warn for static inline declarations with locations that > are not in any included file (not sure how exactly to verify that). MAIN_FILE_P() ?
[Bug tree-optimization/87423] New: missing warning for strcpy of an unterminated member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87423
Bug ID: 87423
Summary: missing warning for strcpy of an unterminated member
array
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC 9 issues a warning for a strcpy call with an unterminated constant array
but fails to issue the same warning when the array is a member of a const
object as shown in the test case below. (The duplicate warning in the subject
of bug 87422).
$ cat c.c && gcc -O2 -S -Wall -Wextra -Wpedantic c.c
const char a[3] = { '1', '2', '3' };
const struct { char a[3]; } x = { { '1', '2', '3' } };
int f (void)
{
return __builtin_strlen (a); // warning (good)
}
int g (void)
{
return __builtin_strlen (x.a); // missing warning
}
c.c: In function ‘f’:
c.c:7:29: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
7 | return __builtin_strlen (a); // warning (good)
| ^
c.c:1:12: note: referenced argument declared here
1 | const char a[3] = { '1', '2', '3' };
|^
c.c:7:29: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
7 | return __builtin_strlen (a); // warning (good)
| ^
c.c:1:12: note: referenced argument declared here
1 | const char a[3] = { '1', '2', '3' };
|^
[Bug tree-optimization/87422] New: duplicate warning for strcpy of an unterminated character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87422
Bug ID: 87422
Summary: duplicate warning for strcpy of an unterminated
character array
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC issues two instances of the same warning for the following simple test
case:
$ cat c.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout c.c
const char a[3] = { '1', '2', '3' };
int f (void)
{
return __builtin_strlen (a); // duplicate warning
}
c.c: In function ‘f’:
c.c:5:29: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
5 | return __builtin_strlen (a); // duplicate warning
| ^
c.c:1:12: note: referenced argument declared here
1 | const char a[3] = { '1', '2', '3' };
|^
c.c:5:29: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
5 | return __builtin_strlen (a); // duplicate warning
| ^
c.c:1:12: note: referenced argument declared here
1 | const char a[3] = { '1', '2', '3' };
|^
[Bug target/87421] GCC generates unaligned movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2 from Florian Weimer --- What's your exact target? On x86-64-pc-linux-gnu, on function entry, %rsp + 8 is a multiple of 16, so %rbp is a multiple of 16 throughout the function. This means that %rbp - 48 is a multiple of 16 as well, and the movdqa load is 16-byte-aligned.
[Bug testsuite/87339] [9 Regression] gcc.dg/warn-abs-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87339 --- Comment #6 from Martin Jambor --- Well, I did not quite manage on Friday, but I have submitted the patch now: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01374.html
[Bug target/87421] GCC generates unaligned movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421 --- Comment #1 from Yuxuan Shui --- FYI, clang/llvm correctly generates movups instruction for the read.
[Bug c/87347] ICE in warn_for_abs at gcc/c/c-parser.c:9226 since r264368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87347 --- Comment #2 from Martin Jambor --- So I did not manage to do so last week but I have submitted it today: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01373.html
[Bug target/87421] New: GCC generates unaligned movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421
Bug ID: 87421
Summary: GCC generates unaligned movdqa
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yshuiv7 at gmail dot com
Target Milestone: ---
C++ Test case:
struct A {
unsigned int a1;
long a5;
unsigned int a6;
};
int fun(A *res);
int fun2(A *desc)
{
A resource;
fun();
*desc = resource;
return 0;
}
Target: amd64
Compiler flags:
g++ test.cc -c -O2 -fno-omit-frame-pointer -std=gnu++11
Compiles to:
<_Z4fun2P1A>:
// Assuming 16 bytes stack alignment
0: 55 push %rbp // rsp now aligns to
16 bytes + 8 bytes
1: 48 89 e5mov%rsp,%rbp // rbp also aligns to
16 + 8
4: 53 push %rbx
5: 48 89 fbmov%rdi,%rbx
8: 48 8d 7d d0 lea-0x30(%rbp),%rdi
c: 48 83 ec 28 sub$0x28,%rsp
10: 64 48 8b 04 25 28 00mov%fs:0x28,%rax
17: 00 00
19: 48 89 45 e8 mov%rax,-0x18(%rbp)
1d: 31 c0 xor%eax,%eax
1f: e8 00 00 00 00 callq 24 <_Z4fun2P1A+0x24>
24: 48 8b 45 e0 mov-0x20(%rbp),%rax
28: 66 0f 6f 45 d0 movdqa -0x30(%rbp),%xmm0 // rbp-0x30 is not
aligned to 16 bytes
2d: 48 89 43 10 mov%rax,0x10(%rbx)
31: 0f 11 03movups %xmm0,(%rbx)
34: 48 8b 55 e8 mov-0x18(%rbp),%rdx
38: 64 48 33 14 25 28 00xor%fs:0x28,%rdx
3f: 00 00
41: 75 09 jne4c <_Z4fun2P1A+0x4c>
43: 48 83 c4 28 add$0x28,%rsp
47: 31 c0 xor%eax,%eax
49: 5b pop%rbx
4a: 5d pop%rbp
4b: c3 retq
4c: e8 00 00 00 00 callq 51 <_Z4fun2P1A+0x51>
[Bug fortran/87359] [9 regression] pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359 --- Comment #36 from Dominique d'Humieres --- > The test succeeds with r264348+patch of r264485, but not with r264349+patch. I make a mistake in my bissection: r264349+patch is OK as well as r264357+patch, but not r264358+patch.
[Bug tree-optimization/87420] New: missing warning for strcpy of an unterminated array with variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87420
Bug ID: 87420
Summary: missing warning for strcpy of an unterminated array
with variable offset
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When the source array involves a variable index/offset, GCC 9 issues a warning
for a strcpy call with a single-dimensional unterminated array but fails to
issue the same warning when the array has multiple dimensions, as shown in the
test case below:
$ cat c.c && gcc -O2 -S -Wall -Wextra -Wpedantic c.c
const char a[] = { '1', '2', '3' };
const char b[][3] = { { '1', '2' }, { '1', '2', '3' } };
void f (char *d, int i)
{
__builtin_strcpy (d, [i]); // warning (good)
}
void g (char *d, int i)
{
__builtin_strcpy (d, [1][i]); // missing warning
}
c.c: In function ‘f’:
c.c:6:3: warning: ‘strcpy’ argument missing terminating nul
[-Wstringop-overflow=]
6 | __builtin_strcpy (d, [i]); // warning (good)
| ^~~
c.c:1:12: note: referenced argument declared here
1 | const char a[] = { '1', '2', '3' };
|^
[Bug target/87414] -mindirect-branch=thunk produces thunk with incorrect CFI on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87414 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think we want to emit .cfi_def_cfa_offset 16 after .LIND1: label, because the call acts as a pushm so the caller (of the thunk) is no longer at $sp+8 after the call, but at $sp+16.
[Bug c++/85070] [8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85070 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|nathan at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #8 from Paolo Carlini --- Fixed for 8.3.
[Bug c++/85070] [8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85070 --- Comment #7 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 24 17:44:02 2018 New Revision: 264542 URL: https://gcc.gnu.org/viewcvs?rev=264542=gcc=rev Log: /cp 2018-09-24 Paolo Carlini PR c++/85070 * method.c (lazily_declare_fn): During error-recovery add_method may return false. /testsuite 2018-09-24 Paolo Carlini PR c++/85070 * g++.dg/cpp0x/pr85070.C: New. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/pr85070.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/method.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/85070] [8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85070 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 24 17:42:45 2018 New Revision: 264541 URL: https://gcc.gnu.org/viewcvs?rev=264541=gcc=rev Log: /cp 2018-09-24 Paolo Carlini PR c++/85070 * method.c (lazily_declare_fn): During error-recovery add_method may return false. /testsuite 2018-09-24 Paolo Carlini PR c++/85070 * g++.dg/cpp0x/pr85070.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr85070.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87418] [9 Regression] Failure in coarray_lib_alloc_4.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87418 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Thomas Koenig --- Uh, I just saw that this was out of sync. Sorry for the noise.
[Bug target/82699] ENDBR isn't generated at function entrance (with -mfentry)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82699 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Sep 24 17:20:58 2018 New Revision: 264540 URL: https://gcc.gnu.org/viewcvs?rev=264540=gcc=rev Log: i386: Insert ENDBR before the profiling counter call ENDBR must be the first instruction of a function. This patch queues ENDBR if we need to put the profiling counter call before the prologue and generate ENDBR before the profiling counter call. gcc/ PR target/82699 * config/i386/i386.c (rest_of_insert_endbranch): Set endbr_queued_at_entrance to true and don't insert ENDBR if x86_function_profiler will be called. (x86_function_profiler): Insert ENDBR if endbr_queued_at_entrance is true. * config/i386/i386.h (machine_function): Add endbr_queued_at_entrance. gcc/testsuite/ PR target/82699 * gcc.target/i386/pr82699-1.c: New file. * gcc.target/i386/pr82699-2.c: Likewise. * gcc.target/i386/pr82699-3.c: Likewise. * gcc.target/i386/pr82699-4.c: Likewise. * gcc.target/i386/pr82699-5.c: Likewise. * gcc.target/i386/pr82699-6.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr82699-1.c trunk/gcc/testsuite/gcc.target/i386/pr82699-2.c trunk/gcc/testsuite/gcc.target/i386/pr82699-3.c trunk/gcc/testsuite/gcc.target/i386/pr82699-4.c trunk/gcc/testsuite/gcc.target/i386/pr82699-5.c trunk/gcc/testsuite/gcc.target/i386/pr82699-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/testsuite/ChangeLog
[Bug target/87419] New: -mfentry generates assembly codes as string instead of RTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87419 Bug ID: 87419 Summary: -mfentry generates assembly codes as string instead of RTL Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: wei3.xiao at intel dot com, xuepeng.guo at intel dot com Target Milestone: --- Target: i386,x86-64 FUNCTION_PROFILER, aka x86_function_profiler, used by -mfentry, generates assembly codes as strings. It is better for -mfentry to generate RTLs instead.
[Bug fortran/87401] [9 Regression] Runtime segfault with associated intent(out) variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87401 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Thomas Koenig --- Fixed, closing.
[Bug fortran/87397] Clobbering intent(out) variables caused regression in OpenCoarrays testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87397 --- Comment #4 from Thomas Koenig --- Author: tkoenig Date: Mon Sep 24 17:12:34 2018 New Revision: 264539 URL: https://gcc.gnu.org/viewcvs?rev=264539=gcc=rev Log: 2018-09-24 Thomas Koenig PR fortran/87397 * gfc_conv_procedure_call: Do not add clobber on INTENT(OUT) for variables in an associate statement. 2018-09-24 Thomas Koenig PR fortran/87401 * gfortran.dg/intent_out_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intent_out_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87401] [9 Regression] Runtime segfault with associated intent(out) variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87401 --- Comment #3 from Thomas Koenig --- Author: tkoenig Date: Mon Sep 24 17:12:34 2018 New Revision: 264539 URL: https://gcc.gnu.org/viewcvs?rev=264539=gcc=rev Log: 2018-09-24 Thomas Koenig PR fortran/87397 * gfc_conv_procedure_call: Do not add clobber on INTENT(OUT) for variables in an associate statement. 2018-09-24 Thomas Koenig PR fortran/87401 * gfortran.dg/intent_out_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intent_out_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87418] [9 Regression] Failure in coarray_lib_alloc_4.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87418 Thomas Koenig changed: What|Removed |Added CC||cesar at gcc dot gnu.org Target Milestone|--- |9.0
[Bug fortran/87418] New: [9 Regression] Failure in coarray_lib_alloc_4.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87418 Bug ID: 87418 Summary: [9 Regression] Failure in coarray_lib_alloc_4.f90 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- I'm seeing failures of the kind FAIL: gfortran.dg/coarray_lib_alloc_4.f90 -O0 scan-tree-dump-times original "_gfortran_caf_is_present \\(xx\\.token, 2 - \\(integer\\(kind=4\\)\\) xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)|_gfortran_caf_is_present \\(xx\\.token, 2 - xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)" 10 FAIL: gfortran.dg/coarray_lib_alloc_4.f90 -O1 scan-tree-dump-times original "_gfortran_caf_is_present \\(xx\\.token, 2 - \\(integer\\(kind=4\\)\\) xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)|_gfortran_caf_is_present \\(xx\\.token, 2 - xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)" 10 FAIL: gfortran.dg/coarray_lib_alloc_4.f90 -O2 scan-tree-dump-times original "_gfortran_caf_is_present \\(xx\\.token, 2 - \\(integer\\(kind=4\\)\\) xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)|_gfortran_caf_is_present \\(xx\\.token, 2 - xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)" 10 FAIL: gfortran.dg/coarray_lib_alloc_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions scan-tree-dump-times original "_gfortran_caf_is_present \\(xx\\.token, 2 - \\(integer\\(kind=4\\)\\) xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)|_gfortran_caf_is_present \\(xx\\.token, 2 - xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)" 10 FAIL: gfortran.dg/coarray_lib_alloc_4.f90 -O3 -g scan-tree-dump-times original "_gfortran_caf_is_present \\(xx\\.token, 2 - \\(integer\\(kind=4\\)\\) xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)|_gfortran_caf_is_present \\(xx\\.token, 2 - xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)" 10 FAIL: gfortran.dg/coarray_lib_alloc_4.f90 -Os scan-tree-dump-times original "_gfortran_caf_is_present \\(xx\\.token, 2 - \\(integer\\(kind=4\\)\\) xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)|_gfortran_caf_is_present \\(xx\\.token, 2 - xx\\.dim\\[0\\]\\.lbound, _ref\\.[0-9]+\\)" 10 This must be very recent, r264536 ?
[Bug fortran/87401] [9 Regression] Runtime segfault with associated intent(out) variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87401
--- Comment #2 from Thomas Koenig ---
Quite clear what is going on. The tree dump shows
assoc_intent_out ()
{
static void sub (real(kind=4) & restrict);
real(kind=4) r;
{
real(kind=4) * o;
o =
o = {CLOBBER};
sub (o);
L.1:;
}
}
which is not the way to go :-)
[Bug bootstrap/87417] [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug bootstrap/87417] New: [9 regression] Internal error: abort in attr_alt_intersection, at genattrtab.c:2357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417
Bug ID: 87417
Summary: [9 regression] Internal error: abort in
attr_alt_intersection, at genattrtab.c:2357
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: iii at linux dot ibm.com
Target Milestone: ---
Host: i386-pc-solaris2.11, sparc-sun-solaris2.11
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11
Build: i386-pc-solaris2.11, sparc-sun-solaris2.11
Between 20180922 (r264503) and 20180924 (r264537), both Solaris/SPARC and
Solaris/x86
bootstrap got broken (already in stage1):
genattrtab: Internal error: abort in attr_alt_intersection, at
genattrtab.c:2357
make[3]: *** [Makefile:2364: s-attrtab] Error 1
This is obviously due to
2018-09-24 Ilya Leoshkevich
* genattrtab.c (mk_attr_alt): Use alternative_mask.
(attr_rtx_1): Adjust caching to match the new EQ_ATTR_ALT field
types.
(check_attr_test): Use alternative_mask.
(get_attr_value): Likewise.
(compute_alternative_mask): Use alternative_mask and XWINT.
(make_alternative_compare): Use alternative_mask.
(attr_alt_subset_p): Use XWINT.
(attr_alt_subset_of_compl_p): Likewise.
(attr_alt_intersection): Use alternative_mask and XWINT.
[...]
Thread 2 hit Breakpoint 1, fancy_abort (
file=0x80708fc "/vol/gcc/src/hg/trunk/local/gcc/genattrtab.c", line=2357,
func=0x8072444
"attr_alt_intersection") at /vol/gcc/src/hg/trunk/local/gcc/errors.c:133
133 internal_error ("abort in %s, at %s:%d", func, trim_filename (file),
line);
(gdb) where
#0 fancy_abort (
file=0x80708fc "/vol/gcc/src/hg/trunk/local/gcc/genattrtab.c", line=2357,
func=0x8072444
"attr_alt_intersection") at /vol/gcc/src/hg/trunk/local/gcc/errors.c:133
#1 0x0808442e in attr_alt_intersection (s1=0xa062950, s2=0x8deac68)
at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:2357
#2 0x080847ed in simplify_test_exp (exp=0xa062968, insn_code=2757,
insn_index=3021) at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:2447
#3 0x08083fe1 in simplify_test_exp_in_temp (exp=0xa062968, insn_code=2757,
insn_index=3021) at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:2282
#4 0x080832b5 in insert_right_side (code=AND, exp=0xa062950, term=0x8deac68,
insn_code=2757, insn_index=3021)
at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:1863
#5 0x0808371a in evaluate_eq_attr (exp=0x8c87c00, attr=0x8c87d88,
value=0x8361260, insn_code=2757, insn_index=3021)
at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:2015
#6 0x080855f7 in simplify_test_exp (exp=0x8c87c00, insn_code=2757,
insn_index=3021) at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:2736
#7 0x08083fe1 in simplify_test_exp_in_temp (exp=0x8c87c00, insn_code=2757,
insn_index=3021) at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:2282
#8 0x08082ce7 in simplify_cond (exp=0x81018a8, insn_code=2757,
insn_index=3021) at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:1680
#9 0x08085c41 in optimize_attrs (num_insn_codes=7443)
at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:2961
#10 0x0808b004 in main (argc=7, argv=0xfeffd964)
at /vol/gcc/src/hg/trunk/local/gcc/genattrtab.c:5271
(gdb) p s1
$3 = (rtx) 0xa062950
(gdb) pr
warning: Expression is not an assignment (and might have no effect)
(eq_attr_alt/s/i 28 [0x1c] 1 [0x1])
(gdb) p s2
$4 = (rtx) 0x8deac68
(gdb) pr
warning: Expression is not an assignment (and might have no effect)
(eq_attr_alt/s/i 128 [0x80] 1537 [0x601])
[Bug c/80868] "Duplicate const" warning emitted in `const typeof(foo) bar;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868 --- Comment #4 from Nick Desaulniers --- We can close this bug. LLVM will match GCC here: https://reviews.llvm.org/D52248
[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66639 Martin Sebor changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #12 from Martin Sebor --- *** Bug 87399 has been marked as a duplicate of this bug. ***
[Bug c++/87399] Inconsistent determination of what is usable in a constant expression with __PRETTY_FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87399 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Martin Sebor --- I think this is essentially a duplicate of pr66639 requesting to treat __PRETTY_FUNCTION__ as constexpr. *** This bug has been marked as a duplicate of bug 66639 ***
[Bug tree-optimization/87416] New: [8/9 Regression] switchconv: detect identity lookup arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87416
Bug ID: 87416
Summary: [8/9 Regression] switchconv: detect identity lookup
arrays
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Starting from gcc-8 the following function is no longer optimized to a simple
register copy:
int foo(int how)
{
switch (how) {
case 0: how = 0; break;
case 1: how = 1; break;
case 2: how = 2; break;
}
return how;
}
The reason is now switchconv pass manages to transform this to an array lookup
(nice!), but misses that the array is trivial. Previously switchconv didn't
touch the switch, and late gimple passes managed to simplify it.
I think it's not too costly to have a check in switchconv that helper array is
holding an identity map and emit a copy/conversion instead of array lookup.
Although the test looks artificial, such code appears in Python (and similar
code may appear elsewhere). In posixmodule.c it has:
/* Turn 0, 1, 2 into SEEK_{SET,CUR,END} */
switch (how) {
case 0: how = SEEK_SET; break;
case 1: how = SEEK_CUR; break;
case 2: how = SEEK_END; break;
}
and in fileio.c it has a more elaborate hand-optimized variant:
/* Turn 0, 1, 2 into SEEK_{SET,CUR,END} */
switch (whence) {
#if SEEK_SET != 0
case 0: whence = SEEK_SET; break;
#endif
#if SEEK_CUR != 1
case 1: whence = SEEK_CUR; break;
#endif
#if SEEK_END != 2
case 2: whence = SEEK_END; break;
#endif
}
[Bug c++/87413] strlen accepted in array declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87413 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-24 Blocks||83819 Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- Let me confirm this for the missing pedantic warning. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug c++/78986] [7/8/9 Regression] template inner classes are not affected by access specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-09-24
CC||msebor at gcc dot gnu.org
Summary|template inner classes are |[7/8/9 Regression] template
|not affected by visibility |inner classes are not
|specifiers |affected by access
||specifiers
Ever confirmed|0 |1
Known to fail||4.8.3, 4.9.3, 5.3.0, 7.2.0,
||8.2.0, 9.0
--- Comment #1 from Martin Sebor ---
Confirmed. The test case in comment #0 has never been diagnosed by G++. The
following slightly modified test case, however, is rejected by G++ 5 but
accepted by 6 and later.
class B { struct T {}; };
class D: B { template struct U: T {}; };
D::U d;
Bisection points to r231354 as the cause of the regression:
r231354 | jason | 2015-12-06 23:35:14 -0500 (Sun, 06 Dec 2015) | 4 lines
Fix parse/no-type-defn1.C with -std=c++1z.
* parser.c (struct tentative_firewall): New.
(cp_parser_template_id, cp_parser_decltype_expr): Use it.
[Bug c++/87413] strlen accepted in array declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87413
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=80265
--- Comment #3 from Martin Sebor ---
As Jonathan already mentioned, treating __builtin_strlen("string") (among other
string function calls) as a constant integer expression is a useful extension
accepted by several C++ compilers, including Clang and ICC 18 (see also
pr80265).
G++ accepts the test case in C++ 11 mode and later, but rejects it with an
error in C++ 98 mode. Since C++ requires array bounds to be constant
expressions and calls to functions are not such expressions, it might be worth
issuing a pedantic warning on the strlen case in C++ 11 mode and later.
[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 --- Comment #1 from Will Schmidt --- Author: willschm Date: Mon Sep 24 15:47:22 2018 New Revision: 264538 URL: https://gcc.gnu.org/viewcvs?rev=264538=gcc=rev Log: [testsuite] 2018-09-24 Will Schmidt PR testsuite/86952 * gcc.target/powerpc/p8-vec-xl-xst-v2.c: Add and update expected codegen Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c
[Bug tree-optimization/87415] New: wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87415
Bug ID: 87415
Summary: wrong code at -O1 and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
It appears to be a recent regression.
$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20180924 (experimental) [trunk revision 264537] (GCC)
$
$ gcctk -O0 small.c; ./a.out
$
$ gcctk -O1 small.c
$ ./a.out
Segmentation fault (core dumped)
$
--
struct A
{
int b:1;
};
int c[1], d;
int main ()
{
struct A e = { 0 };
if (!d)
e.b = -1;
if (!e.b)
c[1000] = 0;
return 0;
}
[Bug c++/87399] Inconsistent determination of what is usable in a constant expression with __PRETTY_FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87399 --- Comment #3 from eric-bugs at omnifarious dot org --- *** Bug 87381 has been marked as a duplicate of this bug. ***
[Bug c++/87381] clang 6.0 will compile this constexpr construct, but gcc 8.2.1 will not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381 eric-bugs at omnifarious dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from eric-bugs at omnifarious dot org --- Someone filed a bug in response to a StackOverflow question I asked, and their bug is much more succinct and clear than this one is. Marking this one as a dupe. *** This bug has been marked as a duplicate of bug 87399 ***
[Bug fortran/72709] Incorrect assignment of allocatable character array used as component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72709 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #8 from Paul Thomas --- This fixed by the patch for PR70752, which I will be submitting tomorrow. I am not sure that it is a duplicate even though it is fixed by the referred to patch. Paul
[Bug c++/87399] Inconsistent determination of what is usable in a constant expression with __PRETTY_FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87399 eric-bugs at omnifarious dot org changed: What|Removed |Added CC||eric-bugs at omnifarious dot org --- Comment #2 from eric-bugs at omnifarious dot org --- This bug is far more succinct than the one I filed. I'll mark mine as the dupe even though this one was filed later.
[Bug c++/87413] strlen accepted in array declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87413 --- Comment #2 from Jonathan Wakely --- It's a GNU extension in C++, so we can decide whether it's valid or not.
[Bug target/87414] New: -mindirect-branch=thunk produces thunk with incorrect CFI on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87414
Bug ID: 87414
Summary: -mindirect-branch=thunk produces thunk with incorrect
CFI on x86_64
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
CC: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86_64
GCC 9.0.0 (20180924) generates these thunks on x86-64:
__x86_indirect_thunk_rdi:
.LFB1:
.cfi_startproc
call.LIND1
.LIND0:
pause
lfence
jmp .LIND0
.LIND1:
mov %rdi, (%rsp)
ret
.cfi_endproc
.LFE1:
I don't think the CFI is correct. At the ret instruction, the CFI
indicates that the return address is at the top of the stack. The
unwinder will use this return address and subtract one because it's a
non-signal handler frame. But the resulting address is located before
the start of the function, so it will locate an incorrect FDE based on
it.
Indeed I see this when si-stepping through the execution with GDB:
(gdb) disas
Dump of assembler code for function __x86_indirect_thunk_rdi:
0x004004a5 <+0>: callq 0x4004b1 <__x86_indirect_thunk_rdi+12>
0x004004aa <+5>: pause
0x004004ac <+7>: lfence
0x004004af <+10>:jmp0x4004aa <__x86_indirect_thunk_rdi+5>
0x004004b1 <+12>:mov%rdi,(%rsp)
=> 0x004004b5 <+16>:retq
0x004004b6 <+17>:nopw %cs:0x0(%rax,%rax,1)
(gdb) bt
#0 0x004004b5 in __x86_indirect_thunk_rdi ()
#1 0x00400490 in frame_dummy () at /tmp/cfi.c:16
#2 0x0040038e in main () at /tmp/cfi.c:16
End of assembler dump.
(gdb) print f2
$1 = {int (void)} 0x400490
Note the “frame_dummy” instead of “f2” in the backtrace.
Test program:
__attribute__ ((weak))
int
f1 (int (*f2) (void))
{
return f2 ();
}
int
f2 (void)
{
}
int
main (void)
{
f1 (f2);
}
We had a bit of an internal debate whether it's actually possible to produce
correct CFI for this. I think we can reflect the stack pointer adjustment
after the thunk-internal call in the CFI, so that the unwinder continues to see
the original caller of the thunk. Due to the address decrement, this needs to
happen for the jmp instruction, not after the .LIND1 label.
As an alternative, it would be possible to error out when
-mindirect-branch=thunk is used with -fasynchronous-unwind-tables, but since
the latter is the default, this would be a bit harsh.
[Bug c++/87407] Enhance -Wunused-function to handle also inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87407 --- Comment #11 from Richard Biener --- It's probably inconvenient for C indeed (pre-dating C99 inline). Even GCC has too many static inlines in headers. I agree that we can warn for static inline declarations with locations that are not in any included file (not sure how exactly to verify that).
[Bug c++/87413] strlen accepted in array declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87413 --- Comment #1 from Bernd Edlinger --- so current trunk accepts the variant test1.c with __builtin_strlen both C and C++: $ gcc -Wall -S test1.c $ gcc -x c++ -Wall -S test1.c Don't know it that is valid.
[Bug tree-optimization/87402] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87402 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-24 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug fortran/87401] [9 Regression] Runtime segfault with associated intent(out) variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87401 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/87399] Inconsistent determination of what is usable in a constant expression with __PRETTY_FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87399 --- Comment #1 from Richard Biener --- IIRC there's a duplicate about __PRETTY_FUNCTION__ and constexpr.
[Bug c/82272] RFE: request a warning for ( == ) etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272 --- Comment #7 from Martin Sebor --- (In reply to Eric Gallager from comment #6) The proposal was discussed at the spring 2018 WG14 meeting in Brno. There was strong support for making the change (the details of the discussion and the straw poll are in the meeting minutes: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2239.pdf).
[Bug c++/87393] [8/9 Regression] gcc/cp/parser.c:13967:37:Unused Entity Issue: expression result unused: -Wunused-value since r251026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87393 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug c++/87413] New: strlen accepted in array declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87413
Bug ID: 87413
Summary: strlen accepted in array declaration
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
$ cat test.c
#include
char x[strlen("test")];
int test ()
{
return sizeof(x);
}
$ gcc -Wall -S test.c
test.c:2:6: error: variably modified 'x' at file scope
2 | char x[strlen("test")];
| ^
which is okay.
But:
$ gcc -S -x c++ -Wall test.c
$ cat test.s
.file "test.c"
.text
.globl x
.bss
.type x, @object
.size x, 4
x:
.zero 4
.text
.globl _Z4testv
.type _Z4testv, @function
_Z4testv:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$4, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
This was previously rejected:
$ gcc-4.8 -x c++ -S test.c
test.c:2:22: error: array bound is not an integer constant before ‘]’ token
char x[strlen("test")];
^
test.c: In function ‘int test()’:
test.c:5:17: error: ‘x’ was not declared in this scope
return sizeof(x);
^
I think this should be invalid.
Interestingly, this modified example was accepted as C and rejected as C++
by gcc-4.8
$ cat test1.c
char x[__builtin_strlen("test")];
int test ()
{
return sizeof(x);
}
$ gcc-4.8 -S test.c
$ gcc-4.8 -x c++ -S test.c
test.c:2:22: error: array bound is not an integer constant before ‘]’ token
char x[strlen("test")];
^
test.c: In function ‘int test()’:
test.c:5:17: error: ‘x’ was not declared in this scope
return sizeof(x);
^
[Bug c++/87386] [8/9 Regression] Error message for static_assert show wrong range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87386 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629 --- Comment #8 from Matthew Woehlke --- Given what -Wreturn-type is trying to accomplish, I wonder if a "delayed issuance" strategy would be in order? IOW, have the front end "trigger" the warning, as now, but stuff it in a queue or such, continue on with optimization, then go back and check the queue to see if the warning still looks legitimate, and only *then* emit it. Where this gets sticky is that at -O0, we still may not know that the warning is spurious. We might, ideally, want to perform optimization anyway on a function with a "pending" -Wreturn-type warning, but throw out the result.
[Bug middle-end/87370] Regression in return struct code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370
H.J. Lu changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot
com
--- Comment #3 from H.J. Lu ---
For
f2 ()
{
struct B D.2315;
;; basic block 2, loop depth 0
;;pred: ENTRY
D.2315 = {};
return D.2315;
;;succ: EXIT
}
C++ front-end generates:
(insn 5 2 6 2 (set (mem/j/c:TI (plus:DI (reg/f:DI 78 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 D.2315+0 S16 A128])
(const_int 0 [0])) "x.ii":8 -1
(nil))
(insn 6 5 7 2 (set (reg:DI 85)
(mem/j/c:DI (plus:DI (reg/f:DI 78 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 D.2315+0 S8 A128]))
"x.
ii":8 -1
(nil))
(insn 7 6 8 2 (set (reg:DI 86)
(mem/j/c:DI (plus:DI (reg/f:DI 78 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 D.2315+8 S8 A64]))
"x.ii
":8 -1
(nil))
(insn 8 7 9 2 (set (reg:DI 83 [ ])
(reg:DI 85)) "x.ii":8 -1
(nil))
(insn 9 8 13 2 (set (reg:DI 84 [ +8 ])
(reg:DI 86)) "x.ii":8 -1
(nil))
(insn 13 9 14 2 (set (reg:DI 0 ax)
(reg:DI 83 [ ])) "x.ii":9 -1
(nil))
(insn 14 13 15 2 (set (reg:DI 1 dx)
(reg:DI 84 [ +8 ])) "x.ii":9 -1
(nil))
(insn 15 14 16 2 (use (reg:DI 0 ax)) "x.ii":9 -1
(nil))
(insn 16 15 0 2 (use (reg:DI 1 dx)) "x.ii":9 -1
(nil))
Why can't C++ front-end generate better RTL?
[Bug target/87374] [8/9 Regression] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87374 Richard Biener changed: What|Removed |Added Target||arm Target Milestone|--- |8.3
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373 Richard Biener changed: What|Removed |Added Target||arm Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #27 from Richard Biener --- There doesn't seem to be any bug here just discussion belonging to gcc-help.
[Bug target/82699] ENDBR isn't generated at function entrance (with -mfentry)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82699 --- Comment #7 from H.J. Lu --- (In reply to Florian Weimer from comment #6) > What's the status of this bug? My patch is still unreviewed: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01341.html
[Bug target/87412] -fcf-protection and -mindirect-branch=thunk are incompatible on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87412 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-24 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- (In reply to Florian Weimer from comment #0) > > Suggested fix is to error out when both options are specified at the same > time. Yes, -fcf-protection and -mindirect-branch=thunk should be disallowed when used together.
[Bug middle-end/87370] Regression in return struct code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* i?86-*-* CC||hjl at gcc dot gnu.org --- Comment #2 from Richard Biener --- I belive there's a duplicate for this.
[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0 Summary|Regression on |[9 Regression] Regression |aarch64/copysign-bsl.c |on aarch64/copysign-bsl.c |since r264264 |since r264264
[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080 --- Comment #15 from iii at gcc dot gnu.org --- Author: iii Date: Mon Sep 24 14:21:03 2018 New Revision: 264535 URL: https://gcc.gnu.org/viewcvs?rev=264535=gcc=rev Log: S/390: Fix conditional returns on z196+ S/390 epilogue ends with (parallel [(return) (use %r14)]) instead of the more usual (return) or (simple_return). This sequence is not recognized by the conditional return logic in try_optimize_cfg (). This was introduced for processors older than z196, where it is sometimes profitable to use call-clobbered register for returning instead of %r14. On newer processors we always return via %r14, for which the fact that it's used is already reflected by EPILOGUE_USES. In this case a simple (return) suffices. This patch changes return_use () to emit simple (return)s when returning via %r14. The resulting sequences are recognized by the conditional return logic in try_optimize_cfg (). gcc/ChangeLog: 2018-09-24 Ilya Leoshkevich PR target/80080 * config/s390/s390.c (s390_emit_epilogue): Do not use PARALLEL RETURN+USE when returning via %r14. gcc/testsuite/ChangeLog: 2018-09-24 Ilya Leoshkevich PR target/80080 * gcc.target/s390/risbg-ll-3.c: Expect conditional returns. * gcc.target/s390/zvector/vec-cmp-2.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/s390/risbg-ll-3.c trunk/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c
[Bug target/83970] -mindirect-branch=thunk -fno-plt generates CET-incompatible thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970 --- Comment #1 from Florian Weimer --- Bug 87412 is a related issue, but without -fno-plt.
[Bug target/87412] New: -fcf-protection and -mindirect-branch=thunk are incompatible on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87412
Bug ID: 87412
Summary: -fcf-protection and -mindirect-branch=thunk are
incompatible on x86_64
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
Consider this test program:
__attribute__ ((weak))
int
f1 (int (*f2) (void))
{
return f2 ();
}
int
f2 (void)
{
}
int
main (void)
{
f1 (f2);
}
Compiled with “-O2 -mindirect-branch=thunk -fcf-protection -c”, we get an
object file which has:
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x0010 NT_GNU_PROPERTY_TYPE_0
Properties: x86 feature: IBT, SHSTK
But also:
<__x86_indirect_thunk_rdi>:
0: e8 07 00 00 00 callq c <__x86_indirect_thunk_rdi+0xc>
5: f3 90 pause
7: 0f ae e8lfence
a: eb f9 jmp5 <__x86_indirect_thunk_rdi+0x5>
c: 48 89 3c 24 mov%rdi,(%rsp)
10: c3 retq
The retq will trap on CET-capable hardware because the shadow stack says it
should return to address 7, and not to the address in %rdi.
Seen with: xgcc (GCC) 9.0.0 20180924 (experimental)
Suggested fix is to error out when both options are specified at the same time.
[Bug target/87411] -fcf-protection -mindirect-branch=thunk incorrectly marked as CET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87411 Florian Weimer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Summary|-fcf-protection |-fcf-protection |-mindirect-branch=thunk |-mindirect-branch=thunk |incorrectly |incorrectly marked as CET --- Comment #1 from Florian Weimer --- Hit submit too soon.
[Bug target/87411] New: -fcf-protection -mindirect-branch=thunk incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87411 Bug ID: 87411 Summary: -fcf-protection -mindirect-branch=thunk incorrectly Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Target: x86_64
[Bug target/82699] ENDBR isn't generated at function entrance (with -mfentry)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82699 Florian Weimer changed: What|Removed |Added Summary|ENDBR isn't generated at|ENDBR isn't generated at |function entrance |function entrance (with ||-mfentry) --- Comment #6 from Florian Weimer --- What's the status of this bug?
[Bug c++/87410] New: internal compiler error: in fold_convert_loc, at fold-const.c:2530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87410 Bug ID: 87410 Summary: internal compiler error: in fold_convert_loc, at fold-const.c:2530 Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 44743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44743=edit XZ archive of preprocessed source Self-contained repro attached - g++ -std=c++17 repro.cpp is enough to trigger it
[Bug testsuite/70230] 11 test regressions when building GCC 6 with --enable-default-ssp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-09-24
Ever confirmed|0 |1
--- Comment #4 from H.J. Lu ---
I also saw
FAIL: gcc.target/i386/cleanup-1.c execution test
FAIL: gcc.target/i386/cleanup-2.c execution test
on trunk with --enable-default-ssp. They contain asm statements which
aren't compatible with -fstack-protector. Adding -fno-stack-protector:
diff --git a/gcc/testsuite/gcc.target/i386/cleanup-1.c
b/gcc/testsuite/gcc.target/i386/cleanup-1.c
index dcfcc4edb5f..4a74ec2fb0f 100644
--- a/gcc/testsuite/gcc.target/i386/cleanup-1.c
+++ b/gcc/testsuite/gcc.target/i386/cleanup-1.c
@@ -1,5 +1,5 @@
/* { dg-do run { target *-*-linux* *-*-gnu* } } */
-/* { dg-options "-fexceptions -fnon-call-exceptions
-fasynchronous-unwind-tables -O2" } */
+/* { dg-options "-fno-stack-protector -fexceptions -fnon-call-exceptions
-fasynchronous-unwind-tables -O2" } */
/* Test complex CFA value expressions. */
#include
diff --git a/gcc/testsuite/gcc.target/i386/cleanup-2.c
b/gcc/testsuite/gcc.target/i386/cleanup-2.c
index 7e60323373b..d4cf30984e4 100644
--- a/gcc/testsuite/gcc.target/i386/cleanup-2.c
+++ b/gcc/testsuite/gcc.target/i386/cleanup-2.c
@@ -1,5 +1,5 @@
/* { dg-do run { target { *-*-linux* && { ! ia32 } } } } */
-/* { dg-options "-fexceptions -fnon-call-exceptions
-fasynchronous-unwind-tables -O2" } */
+/* { dg-options "-fno-stack-protector -fexceptions -fnon-call-exceptions
-fasynchronous-unwind-tables -O2" } */
/* Test complex CFA value expressions. */
#include
fixed them.
[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
Richard Biener changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #15)
> So with all this (the patch) LTO debuginfo looks much nicer (and is smaller)
> but that doesn't help gdb to consume less memory or be faster at startup.
> *sigh*
>
> I guess that the DW_TAG_imported_unit DIEs causes it to pull in everything
> up-front somehow while w/o LTO much more debuginfo is processed lazily.
> Well, wild guessing...
>
> Anyhow, testing a patch to inlined_function_outer_scope_p for the original
> issue (looking at BLOCK_ABSTRACT_ORIGIN rather than BLOCK_SOURCE_LOCATION).
Bah - NOTE_INSN_INLINE_ENTRY throws a wrench into this...
The only option looks like assigning a proper location to the call stmt
in the first place. The BUILTINS_LOCATION hack wouldn't work either there.
Well, just record the BLOCK directly for NOTE_INSN_INLINE_ENTRY ... somehow.
I was talking about doing the following:
Index: gcc/tree.h
===
--- gcc/tree.h (revision 264534)
+++ gcc/tree.h (working copy)
@@ -4749,7 +4749,8 @@ function_args_iter_next (function_args_i
static inline bool
inlined_function_outer_scope_p (const_tree block)
{
- return LOCATION_LOCUS (BLOCK_SOURCE_LOCATION (block)) != UNKNOWN_LOCATION;
+ return (BLOCK_ABSTRACT_ORIGIN (block)
+&& TREE_CODE (BLOCK_ABSTRACT_ORIGIN (block)) == FUNCTION_DECL);
}
/* Loop over all function arguments of FNTYPE. In each iteration, PTR is set
The only "sensible" location for the call to the split part I can statically
come up with is DECL_SOURCE_LOCATION given we already use DECL_INITIAL for
its block ... "better" would likely be a location/block from somewhere around
the split region.
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #28 from Eric Botcazou --- > Aaahh Yes, and now I understand what the problem is.. as > https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408660810 > points out, gnatlink is a shell script on non-Windows but on Windows it's a > program. this means it's interpreting the unix paths incorrectly `/home` is > then interpreted by the Windows API. I hadn't understood the comment fully > until now that I knew how it's supposed to work... gnatlink is _never_ a shell script though but, yes, it's apparently the usual mess with Unix paths on Windows.
[Bug c++/87406] Implement -Wconstant-conversion and -Wbitfield-constant-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87406
--- Comment #1 from Jonathan Wakely ---
We do warn about this, but only with -Wconversion which is not in -Wall or
-Wextra
c.cc:1:24: warning: conversion to ‘char’ from ‘int’ may alter its value
[-Wconversion]
char f(int i) { return i; }
^
[Bug c++/87406] Implement -Wconstant-conversion and -Wbitfield-constant-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87406 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-24 Ever confirmed|0 |1 Severity|normal |enhancement
