[Bug c++/85400] invalid Local Dynamic TLS relaxation for symbol defined in method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #9 from Pádraig Brady --- Note this isn't sparc specific. I've also seen this when compiling CGAL 4.11 where gcc produced R_X86_64_DTPOFF32 relocations for thread_local vars which lld wasn't happy with at least. Applying this patch to 8.3.0 (on x86_64) fixed the issue. Seems this should be considered for 8.x branch. thanks
[Bug target/89951] Uncorrect instructions flag for Nehalem / westmere arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-04 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Lemme take a look.
[Bug c++/89958] New: ICE and duplicate diagnostic with invalid return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89958
Bug ID: 89958
Summary: ICE and duplicate diagnostic with invalid return value
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic, error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE since GCC 6.1.0,
killing the diagnostic in mid-sentence. In addition, the first part
of the diagnostic is emitted twice:
=
struct A;
constexpr auto foo(A* p)
{
return *p;
}
=
bug.cc: In function 'constexpr auto foo(A*)':
bug.cc:5:11: error: invalid use of incomplete type 'struct A'
5 | return *p;
| ^
bug.cc:1:8: note: forward declaration of 'struct A'
1 | struct A;
|^
bug.cc:5:10: error: invalid use of incomplete type 'struct A'
5 | return *p;
| ^~
bug.cc:1:8: note: forward declaration of 'struct A'
1 | struct A;
|^
bug.cc:3:16: error: invalid return type 'A' of 'constexpr' function 'constexpr
auto foo(A*)'
3 | constexpr auto foo(A* p)
|^~~
bug.cc:1:8: note: 'A' is not literal because:
1 | struct A;
|^
bug.cc:6:1: internal compiler error: Segmentation fault
6 | }
| ^
0xf8203f crash_signal
../../gcc/gcc/toplev.c:326
0x8d0333 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3175
0x8d0333 explain_non_literal_class(tree_node*)
../../gcc/gcc/cp/class.c:5525
0x8d91f0 is_valid_constexpr_fn(tree_node*, bool)
../../gcc/gcc/cp/constexpr.c:239
0x8e8c82 register_constexpr_fundef(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:871
0x92e967 maybe_save_function_definition
../../gcc/gcc/cp/decl.c:15949
0x92e967 finish_function(bool)
../../gcc/gcc/cp/decl.c:16096
0x9cd454 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:27803
0x9ce199 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:27716
0x9ce199 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20295
0x9b049e cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13539
0x9d41c0 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13236
0x9d493c cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4698
0x9d493c c_parse_file()
../../gcc/gcc/cp/parser.c:41180
0xadae9b c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1156
Please submit a full bug report, [etc.]
[Bug tree-optimization/89956] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89956 Martin Liška changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/89956] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89956 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-04 CC||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Known to work||8.3.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #1 from Martin Liška --- Confirmed, started with r260348.
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-04 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Yes, we'll need the pre-processed source file (created with -E option). Please attach it.
[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-04 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957 Martin Sebor changed: What|Removed |Added Keywords||ice-on-invalid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89911 --- Comment #1 from Martin Sebor --- The crashing code (the wi::ltu_p call): if (!TREE_NO_WARNING (exp) && wi::ltu_p (wi::to_wide (maxobjsize), min) && warning_at (loc, OPT_Wstringop_overflow_, "%K%qD specified bound [%wu, %wu] " "exceeds maximum object size %E", exp, func, min.to_uhwi (), max.to_uhwi (), maxobjsize)) TREE_NO_WARNING (exp) = true; The test case was reduced from pr89911.
[Bug middle-end/89957] New: ICE calling strnlen with an int128_t bound in a known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957
Bug ID: 89957
Summary: ICE calling strnlen with an int128_t bound in a known
range
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
$ cat z.c && gcc -c -O2 -Wall z.c
typedef __SIZE_TYPE__ size_t;
extern size_t strnlen ();
size_t foo (__int128_t n)
{
if (n < 0)
n = 0;
return strnlen ("", n);
}
z.c: In function ‘foo’:
z.c:9:23: warning: ‘strnlen’ argument 2 type is ‘__int128’ where ‘long unsigned
int’ is expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
9 | return strnlen ("", n);
| ^
z.c:3:15: note: built-in ‘strnlen’ declared here
3 | extern size_t strnlen ();
| ^~~
during RTL pass: expand
z.c:9:10: internal compiler error: in decompose, at wide-int.h:963
9 | return strnlen ("", n);
| ^~~
0x877bc0 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
/src/gcc/svn/gcc/wide-int.h:963
0x95f62a wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
/src/gcc/svn/gcc/wide-int.h:1013
0x95f5f6 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
/src/gcc/svn/gcc/wide-int.h:788
0x9e15df bool wi::ltu_p >,
generic_wide_int
>(generic_wide_int > const&,
generic_wide_int const&)
/src/gcc/svn/gcc/wide-int.h:1913
0x9c2fea expand_builtin_strnlen
/src/gcc/svn/gcc/builtins.c:3154
0x9d22c9 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/src/gcc/svn/gcc/builtins.c:7533
0xbfc03c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/svn/gcc/expr.c:11029
0xbee2c3 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc/svn/gcc/expr.c:8274
0xbe310a store_expr(tree_node*, rtx_def*, int, bool, bool)
/src/gcc/svn/gcc/expr.c:5673
0xbe143a expand_assignment(tree_node*, tree_node*, bool)
/src/gcc/svn/gcc/expr.c:5436
0xa1ece5 expand_call_stmt
/src/gcc/svn/gcc/cfgexpand.c:2722
0xa226b3 expand_gimple_stmt_1
/src/gcc/svn/gcc/cfgexpand.c:3691
0xa22d6e expand_gimple_stmt
/src/gcc/svn/gcc/cfgexpand.c:3850
0xa22e86 expand_gimple_tailcall
/src/gcc/svn/gcc/cfgexpand.c:3897
0xa2b406 expand_gimple_basic_block
/src/gcc/svn/gcc/cfgexpand.c:5863
0xa2d224 execute
/src/gcc/svn/gcc/cfgexpand.c:6509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #21 from Erik Schnetter --- https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00162.html
[Bug tree-optimization/89956] New: [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89956 Bug ID: 89956 Summary: [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*)) Product: gcc Version: 9.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: --- gfortran-9.0.0-alpha20190331 (r270048) ICEs when compiling the following testcase w/ -O2 (-O3, -Ofast) -fno-code-hoisting -fno-signed-zeros -fno-trapping-math -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-pre: module de contains function zu (az, xx) result (q3) real :: az, xx, q3 q3 = 1.0 - lz (az, xx) - lz (xx, az) end function zu function lz (ho, gh) result (ye) real :: ho, gh, ye ye = sqrt (ho) - ho * gh end function lz end module de % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190331 -O2 -fno-code-hoisting -fno-signed-zeros -fno-trapping-math -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-pre -c xonlkfwo.f90 during GIMPLE pass: widening_mul xonlkfwo.f90:3:0: 3 | function zu (az, xx) result (q3) | internal compiler error: Segmentation fault 0xd83ce6 crash_signal /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/toplev.c:326 0xacbfab gsi_for_stmt(gimple*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/gimple-iterator.c:611 0xefe0b6 convert_mult_to_fma_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/tree-ssa-math-opts.c:2882 0xf03e07 convert_mult_to_fma /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/tree-ssa-math-opts.c:3278 0xf048cb after_dom_children /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/tree-ssa-math-opts.c:3755 0x1463647 dom_walker::walk(basic_block_def*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/domwalk.c:395 0xf03891 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/tree-ssa-math-opts.c:3838 ==20688== Invalid read of size 8 ==20688==at 0xACBFAB: gsi_for_stmt(gimple*) (gimple-iterator.c:611) ==20688==by 0xEFE0B6: convert_mult_to_fma_1(tree_node*, tree_node*, tree_node*) (tree-ssa-math-opts.c:2882) ==20688==by 0xF03E07: convert_mult_to_fma(gimple*, tree_node*, tree_node*, fma_deferring_state*) (tree-ssa-math-opts.c:3278) ==20688==by 0xF048CB: (anonymous namespace)::math_opts_dom_walker::after_dom_children(basic_block_def*) (tree-ssa-math-opts.c:3755) ==20688==by 0x1463647: dom_walker::walk(basic_block_def*) (domwalk.c:395) ==20688==by 0xF03891: (anonymous namespace)::pass_optimize_widening_mul::execute(function*) (tree-ssa-math-opts.c:3838) ==20688==by 0xCABD3C: execute_one_pass(opt_pass*) (passes.c:2487) ==20688==by 0xCAC497: execute_pass_list_1(opt_pass*) (passes.c:2573) ==20688==by 0xCAC4A9: execute_pass_list_1(opt_pass*) (passes.c:2574) ==20688==by 0xCAC4F0: execute_pass_list(function*, opt_pass*) (passes.c:2584) ==20688==by 0x96EC8E: cgraph_node::expand() (cgraphunit.c:2198) ==20688==by 0x97011D: expand_all_functions (cgraphunit.c:2336) ==20688==by 0x97011D: compile (cgraphunit.c:2687) ==20688==by 0x97011D: symbol_table::compile() (cgraphunit.c:2597) ==20688== Address 0x10 is not stack'd, malloc'd or (recently) free'd (While my target here is powerpc, the ICE is not target-specific. One have to add -mfma in order to reproduce it for x86_64.)
[Bug c++/86986] [7/8/9 Regression] Unexpected errors for template parameter pack in a template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86986 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/89911] [9 Regression] ICE in get_attr_nonstring_decl, at calls.c:1502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89911 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug target/89955] New: riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 Bug ID: 89955 Summary: riscv.h improperly defines STARTFILE_PREFIX_SPEC spec Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kallisti5 at unixzen dot com Target Milestone: --- https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/riscv/riscv.h?view=markup#l885 gcc/config/riscv.h defines STARTFILE_PREFIX_SPEC which breaks sysroot's. Under a new platform (Haiku), our bootstrap was failing missing core existing cross-compiled system libraries which were present and accounted for. Eventually I figured out to #undef STARTFILE_PREFIX_SPEC in our gcc/config/riscv/haiku.h header and things magically began working. Since we're cross compiling with a sysroot (which is *not*) at /usr/lib,/lib,etc, it breaks the sysroot functionality. Likely I think STARTFILE_PREFIX_SPEC needs moved to config/riscv/linux.h ?
[Bug fortran/89375] fortran/expr.c:4723:5: warning: logical ‘or’ of equal expressions [-Wlogical-op]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89375 --- Comment #5 from Fritz Reese --- Thanks Dominiq. On Wed, Apr 3, 2019, 05:02 dominiq at lps dot ens.fr < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89375 > > Dominique d'Humieres changed: > >What|Removed |Added > > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #4 from Dominique d'Humieres --- > Fixed. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #17 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #16) > I would guess so. I wonder if the combiner could restrict itself > here? Maybe LUID "distances" are an approximation? Doesn't the > combiner use DF uses so the number of combinations shouldn't increase > with basic-block size but only with the number of uses? Of course > since we don't have SSA the uses probably include those that cross > other defs... Combine doesn't try too many pairs: it tries every def only with its first use, so that is linear in # insns. But the check if a combination is valid uses reg_used_between_p, which is no good for insns a big distance apart. > That said, algorithmically first building up a kind-of-SSA to > restrict things combine will try might help to avoid this kind > of issues. Yup. Not going to happen in stage4, of course :-/ There are a few other things which aren't linear, but this is the worst one (the rest only happens occasionally, or only on successful combinations). > Since combine does a df_analyze we should have a way to record > the number of insns in a block without another IL walk, it could > also fall back to 2->1 and 2->2 insn combinations after visiting > a new PARAM max-combine-bb-insns-3-3 number of insns in an EBB. The 3->1 (or 3->2) isn't really the problem; there just are many more to try than 2->[12]. > Actually it already does two walks over the whole function in > combine_instructions it seems, so recording # insns per EBB should > be possible? (if that's really the key metric causing the issue) The average distance between a set and its first use is the key metric. The numbers make it feel like that is pretty constrained here still (I haven't run numbers on it), but 100 is very much already if there are 1M insns in the block (or whatever). All numbers that aren't terrible, but combines it takes up quite a chunk of time. Combine also makes garbage for every try, and none of that is cleaned up during combine. Maybe we should change that? (I can try next week).
[Bug rtl-optimization/86928] ICE in compute_live, at sel-sched.c:3097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928 --- Comment #6 from Segher Boessenkool --- (In reply to Alexander Monakov from comment #5) > I didn't have any better ideas, so fixed via comment #2. Thanks!
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #10 from 康 珊 --- Hi Martin Liška, I tried to build it with "-O3 -fno-strict-aliasing -falign-functions=32 -fno-math-errno -fno-semantic-interposition -fno-trapping-math", but it still had the issue. Can "-fno-strict-aliasing" work normally with "-O3"?
[Bug target/89954] missed optimization for signed extension for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-04 Component|c |target Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Though AARCH64 does the right thing though: f: adrpx0, c ldrbw0, [x0, #:lo12:c] eor w0, w0, 1 ret
[Bug c/89954] New: missed optimization for signed extension for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954
Bug ID: 89954
Summary: missed optimization for signed extension for x86-64
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ntysdd at qq dot com
Target Milestone: ---
This code snippet
/
char c;
int f()
{
return c ^ 1;
}
/
is compiled into these instructions with options "-O2 -S"
;
movq_c@GOTPCREL(%rip), %rax
movzbl (%rax), %eax
xorl$1, %eax
movsbl %al, %eax
;
Only movsbl is needed because xor by 1 doesn't change high bits.
[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934 JunMa changed: What|Removed |Added CC||JunMa at linux dot alibaba.com --- Comment #5 from JunMa --- similar issue in pr89911
[Bug c++/89937] For example code, which is valid as either C or C++, optimization seems much better for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937 --- Comment #2 from Walt Karas --- (In reply to Andrew Pinski from comment #1) > This is because of the way inline have different semantics between the two > langauges. > > If I change TSFastDbg to be static instead of just inline, then the code > emitted is the same. > In the case of C, since TSFastDbg is not inlined, there exists an out of > line version of it in a different TU. > In the case of C++, TSFastDbg has vague linkage, there for will be emitted > but in a comdat section. > > The options you have turned on for godbolt, hide this fact; turning them off > you get: > > .Ltext0: > .section > .text._Z9TSFastDbgP14TSFastDbgCntl_PKcz,"axG",@progbits, > _Z9TSFastDbgP14TSFastDbgCntl_PKcz,comdat > .p2align 4,,15 > .weak _Z9TSFastDbgP14TSFastDbgCntl_PKcz > .type _Z9TSFastDbgP14TSFastDbgCntl_PKcz, @function > _Z9TSFastDbgP14TSFastDbgCntl_PKcz: > > See how that is a comdat section. Hmmm it seems you are saying that inline (or weak linkage by any other name) in C++ somehow prohibits inlining. I thought that, in C++, a weak linkage function may or may not be inlined. If it isn't, its object code must be in a vague linkage section. But there is no requirement for its object code to appear in a vague linkage section, is there?
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #38 from Andrew Pinski --- (In reply to Andrew Pinski from comment #37) > (In reply to Jeffrey A. Law from comment #36) > > I wonder if we could pass in a scratch register from try_combine down to > > make_field_assignment to facilitate something like this... > > I have found that make_field_assignment needs a lot of work in the past. I > had a few patches to make_field_assignment to improve it in the GCC 4.3 days > but never updated them for newer compiler versions as the code generationg > which I was fixing up was already fixed; it was for some bad generated SRA > issue. > Maybe for GCC 10, I will look into improving make_field_assignment. Also I should mention I tried in the past having make_field_assignment making a sequence of instructions (two) where one was the assignment and the second one was the zero_extract assignment. This was done in the 4.7 days. I could not fix the rest of combine doing the correct thing and had to give up as I was running out of time before a release was needed to be made. I will try again. This was exactly what you were asking to do to make_field_assignment too.
[Bug d/89255] libphobos.unittests multilib handling broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255 Iain Buclaw changed: What|Removed |Added Attachment #46060|0 |1 is obsolete|| Attachment #46069|0 |1 is obsolete|| Attachment #46077|0 |1 is obsolete|| --- Comment #15 from Iain Buclaw --- Created attachment 46086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46086&action=edit patch for pr89255 Tracked down hang in std.net.curl module ctor/dtors inside version(unittest) code are now added to test module info record. Posting new patch with all so far.
[Bug d/89823] Composed message only partially translatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- For now, translation is not required as of r270074.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 89823, which changed state. Bug 89823 Summary: Composed message only partially translatable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331
--- Comment #7 from Stas Sergeev ---
(In reply to Jason Merrill from comment #4)
> But when we're in the middle of the class definition we don't know yet
> whether it's standard-layout, so we can't answer yet. A compiler is allowed
> to reorder fields of a non-standard-layout class.
Thanks, that clears some things for me.
I definitely am not going to turn this ticket
into a forum, but I am still puzzled why the
below works (on gcc at least, not on clang):
---
#include
#include
class L {};
template
struct offset_of {
constexpr operator size_t() const {
return (std::uintptr_t)&(((T*)nullptr)->*M);
}
};
template
struct B {
char aa;
static const int off = offset_of();
};
struct A {
char a;
L _mark[0];
B b;
};
int main()
{
A a;
std::cout << "size " << sizeof(A) << " off " << a.b.off << std::endl;
return 0;
}
---
Here I do 2 emulation tricks.
I use address-of on the zero-sized mark to emulate
offsetof() in the not yet fully defined class.
And I use reinterpret cast in a constexpr to emulate
offsetof() that doesn't want to work with the template
arguments for some reason.
This works perfectly on gcc (I filled a bug report to clang).
So if the emulation works, why doesn't the original?
Are there any possibility to somehow extend __builtin_offsetof()
to cover either of those 2 cases where I currently have
to emulate it? While I understand the problem you described,
why does the above example avoids it?
[Bug fortran/89938] inconsistent wording regarding assumed shape
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938
--- Comment #5 from Dominique d'Humieres ---
gcc/testsuite/gfortran.dg/pdt_4.f03: type(modtype(8,*)) :: mod_r ! {
dg-error "ASSUMED type parameters" }
The test is not part of the attached patch.
[Bug fortran/89938] inconsistent wording regarding assumed shape
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938 --- Comment #4 from Dominique d'Humieres --- Created attachment 46085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46085&action=edit Adjust the tests
[Bug fortran/89938] inconsistent wording regarding assumed shape
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |dominiq at lps dot
ens.fr
--- Comment #3 from Dominique d'Humieres ---
> Hyphen compounds: assumed shape and other related ones
I have found several such compounds and I have added hyphens based on the
pattern
assumed-shape arrays have assumed shape.
I have also done the changes in the comments. This has been done manually and I
may
have made mistakes, so it would be nice if someone looks at the patch.
I know I have missed
gcc/fortran/resolve.c:gfc_error ("The object %qs at %L with ASSUMED type
parameters "
[Bug fortran/89938] inconsistent wording regarding assumed shape
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938 --- Comment #2 from Dominique d'Humieres --- Created attachment 46084 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46084&action=edit Hyphen compounds: assumed shape and other related ones
[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.4 |9.0 --- Comment #6 from Jason Merrill --- Fixed for GCC 9.
[Bug c++/81866] [7/8 Regression] ICE with a default template parameter which is a template class nested in a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81866 Jason Merrill changed: What|Removed |Added Summary|[7/8/9 Regression] ICE with |[7/8 Regression] ICE with a |a default template |default template parameter |parameter which is a|which is a template class |template class nested in a |nested in a template class |template class | --- Comment #5 from Jason Merrill --- Fixed on trunk so far.
[Bug c++/81866] [7/8/9 Regression] ICE with a default template parameter which is a template class nested in a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81866 --- Comment #4 from Jason Merrill --- Author: jason Date: Wed Apr 3 21:51:36 2019 New Revision: 270138 URL: https://gcc.gnu.org/viewcvs?rev=270138&root=gcc&view=rev Log: PR c++/81866 - ICE with member template and default targ. This testcase manages to find a way to look up the partial instantiation of B for the default argument of C before we've created the partial instantiation of B as part of the normal instantiation of the members of A. Which we can deal with, but we were getting confused because the partial instantiation was stored with a RECORD_TYPE specialization rather than TEMPLATE_DECL. * pt.c (tsubst_template_decl): Handle getting a type from retrieve_specialization. Added: trunk/gcc/testsuite/g++.dg/template/memtmpl6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68567 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres --- Fixed.
[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68567 --- Comment #9 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Wed Apr 3 21:32:13 2019 New Revision: 270137 URL: https://gcc.gnu.org/viewcvs?rev=270137&root=gcc&view=rev Log: 2019-04-03 Steven G. Kargl PR fortran/68567 * expr.c (gfc_reduce_init_expr): Add extra check to avoid dereferencing a null pointer. 2019-04-03 Dominique d'Humieres PR fortran/68567 * gfortran.dg/parameter_array_error_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_error_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #37 from Andrew Pinski --- (In reply to Jeffrey A. Law from comment #36) > I wonder if we could pass in a scratch register from try_combine down to > make_field_assignment to facilitate something like this... I have found that make_field_assignment needs a lot of work in the past. I had a few patches to make_field_assignment to improve it in the GCC 4.3 days but never updated them for newer compiler versions as the code generationg which I was fixing up was already fixed; it was for some bad generated SRA issue. Maybe for GCC 10, I will look into improving make_field_assignment.
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #36 from Jeffrey A. Law --- My combiner-fu is old and getting dated. But I wonder if we're writing off zero_extract too quickly. For the first test in insv1 (and I suspect others are similar) we get into make_field_assignment with something *almost* usable. In particular: (set (reg/i:DI 0 x0) (ior:DI (and:DI (reg:DI 95) (const_int -256 [0xff00])) (const_int 3 [0x3]))) The only reason this isn't going to be recognized as a field assignment is because we don't have a RMW. But we can trivially turn that into a RMW by emitting a copy from reg95 to reg0 and changing the source to reg0. That runs afoul of the general direction we're taking WRT hard registers, so another choice might be to use an existing pseudo that we know is going to die -- reg92 in this case which isn't seen in the extraction pattern. So we'd copy reg95 into reg92 before the extraction and change the source & destination in the extraction to reg92. Then copy reg92 into reg0 after the extraction. I wonder if we could pass in a scratch register from try_combine down to make_field_assignment to facilitate something like this...
[Bug c++/81866] [7/8/9 Regression] ICE with a default template parameter which is a template class nested in a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81866 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/89953] New: ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 Bug ID: 89953 Summary: ICE in nothrow_spec_p, at cp/except.c:1244 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rene.r...@fu-berlin.de Target Milestone: --- Using gcc-9 20190331_1 experimental on mac osx causes ICE. The respective code works fine with gcc7 and gcc8. I added the preprocessed source in the attachment. Let me know if you need more information or if I need to reduce it to a minimal code example that triggers the ICE. GCC Version: GNU C++17 (MacPorts gcc9 9-20190331_1) version 9.0.1 20190331 (experimental) (x86_64-apple-darwin18) Here the build log: Using built-in specs. COLLECT_GCC=/opt/local/bin/g++-mp-9 Target: x86_64-apple-darwin18 Configured with: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9-20190331/configure --prefix=/opt/local --build=x86_64-apple-darwin18 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc9 --includedir=/opt/local/include/gcc9 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-9 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-9 --with-gxx-include-dir=/opt/local/include/gcc9/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-tls --with-pkgversion='MacPorts gcc9 9-20190331_1' --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk Thread model: posix gcc version 9.0.1 20190331 (experimental) (MacPorts gcc9 9-20190331_1) COLLECT_GCC_OPTIONS='-I' '/Users/rmaerker/Development/seqan3/seqan3-build/unit/vendor/googletest/googletest/include' '-I' '/Users/rmaerker/Development/seqan3/seqan3-src/test/include' '-I' '/Users/rmaerker/Development/seqan3/seqan3-src/include' '-isystem' '/Users/rmaerker/Development/seqan3/seqan3-src/submodules/sdsl-lite/include' '-isystem' '/Users/rmaerker/Development/seqan3/seqan3-src/submodules/range-v3/include' '-isystem' '/Users/rmaerker/Development/seqan3/seqan3-src/submodules/lemon/include' '-isystem' '/Users/rmaerker/Development/seqan3/seqan3-src/submodules/cereal/include' '-isystem' '/opt/local/include' '-g' '-isysroot' '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' '-Wpedantic' '-Wall' '-Wextra' '-Werror' '-std=c++17' '-fconcepts' '-v' '-save-temps' '-o' 'CMakeFiles/view_get_test.dir/view_get_test.cpp.o' '-c' '-mmacosx-version-min=10.14.0' '-asm_macosx_version_min=10.14' '-shared-libgcc' '-mtune=core2' /opt/local/libexec/gcc/x86_64-apple-darwin18/9.0.1/cc1plus -E -quiet -v -I /Users/rmaerker/Development/seqan3/seqan3-build/unit/vendor/googletest/googletest/include -I /Users/rmaerker/Development/seqan3/seqan3-src/test/include -I /Users/rmaerker/Development/seqan3/seqan3-src/include -D__DYNAMIC__ -isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/sdsl-lite/include -isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/range-v3/include -isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/lemon/include -isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/cereal/include -isystem /opt/local/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk /Users/rmaerker/Development/seqan3/seqan3-src/test/unit/range/view/view_get_test.cpp -fPIC -feliminate-unused-debug-symbols -mmacosx-version-min=10.14.0 -mtune=core2 -std=c++17 -Wpedantic -Wall -Wextra -Werror -fconcepts -g -fworking-directory -fpch-preprocess -o view_get_test.ii ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/opt/local/include" ignoring nonexistent directory "/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.0.1/../../../../../x86_64-apple-darwin18/include" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /Users/rmaerker/Development/seqan3/seqan3-build/unit/vendor/googletest/googletest/include /Users/rmaerker/Development/seqan3/seqan3-src/test/include /Users/rmaerker/Development/seqan3/seqan3-src/include /Users/rmaerker/Development/seqan3/seqan3-src/submodules/sdsl-lite/include /Users/rmaerker/Development/seqan3/seqan3-src/submodules/range-v3/include /Users/
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 Bug 86518 depends on bug 86586, which changed state. Bug 86586 Summary: [7/8/9 Regression] -Wsign-compare affects code generation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/86586] [7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|7.5 |9.0 --- Comment #9 from Jason Merrill --- Fixed for GCC 9 by not folding on this testcase. This doesn't address the general issue, but reduces its scope. Not worth backporting.
[Bug c++/86586] [7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 --- Comment #8 from Jason Merrill --- Author: jason Date: Wed Apr 3 20:12:00 2019 New Revision: 270136 URL: https://gcc.gnu.org/viewcvs?rev=270136&root=gcc&view=rev Log: PR c++/86586 - -fcompare-debug=-Wsign-compare. This patch limits constexpr folding for -Wsign-compare to only cases that we would warn for without considering constant values, avoiding the folding in the testcase in question. gcc/c-family/ * c-warn.c (warn_for_sign_compare): Call fold_for_warn. gcc/cp/ * typeck.c (cp_build_binary_op): Don't fold for -Wsign-compare. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-warn.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/g++.target/i386/mv1.C
[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331 --- Comment #5 from Jason Merrill --- Author: jason Date: Wed Apr 3 20:09:17 2019 New Revision: 270135 URL: https://gcc.gnu.org/viewcvs?rev=270135&root=gcc&view=rev Log: PR c++/89331 - ICE with offsetof in incomplete class. We were aborting when build_base_path returned an error because of the derived class not being complete yet, which wasn't considered by the assert. Fixed by checking for complete type first. The semantics.c change avoids a duplicate error message. * semantics.c (finish_offsetof): Handle error_mark_node. * typeck.c (build_class_member_access_expr): Call complete_type_or_maybe_complain before converting to base. Added: trunk/gcc/testsuite/g++.dg/ext/builtin-offsetof4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/g++.dg/other/offsetof8.C
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #20 from Erik Schnetter --- I have a patch that works for 8.3.0. It doesn't work for 9.0.0 (i.e. an svn checkout); I'm working on this.
[Bug c++/89947] Resolution of base classes fail for some automatic types in template struct functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89947 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-03 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Clang and EDG both accept it. Doesn't seem to be a regression.
[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 Thomas Koenig changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #22 from Thomas Koenig --- This patch Index: trans-decl.c === --- trans-decl.c(Revision 269895) +++ trans-decl.c(Arbeitskopie) @@ -1863,10 +1863,6 @@ gfc_get_symbol_decl (gfc_symbol * sym) if (sym->attr.associate_var) GFC_DECL_ASSOCIATE_VAR_P (decl) = 1; - if (sym->attr.vtab - || (sym->name[0] == '_' && gfc_str_startswith (sym->name, "__def_init"))) -TREE_READONLY (decl) = 1; - return decl; } leads to FAIL: gfortran.dg/gomp/pr52531.f90 -O (test for excess errors) Excess errors: /home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/gomp/pr52531.f90:10:0: Error: '__vtab_test_mod_Test_type' not specified in enclosing 'parallel' /home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/gomp/pr52531.f90:9:0: Error: enclosing 'parallel' where I have no idea if this is just a cosmetic bug which can, for example, be shut up with a check for attr.artificial, or if this points towards a real problem. Jakub, could you maybe shed any light?
[Bug c/89946] [8/9 Regression] ICE in assemble_start_function, at varasm.c:1871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-03
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. The ICE first appeared in r250521 when the attribute was added.
The handler for the attributes does no validation:
static tree
handle_patchable_function_entry_attribute (tree *, tree, tree, int, bool *)
{
/* Nothing to be done here. */
return NULL_TREE;
}
With struct attribute_spec extended to describe basic properties of attribute
arguments besides just their number, basic attribute argument validation could
be done in decl_attributes, similarly to how mutually exclusive attributes are
handled.
[Bug target/89952] S/390: Inconsistent CFI info when restoring frame pointer from fpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952 --- Comment #1 from Andreas Krebbel --- Created attachment 46083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46083&action=edit Experimental patch
[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00149.html
[Bug target/89952] New: S/390: Inconsistent CFI info when restoring frame pointer from fpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952 Bug ID: 89952 Summary: S/390: Inconsistent CFI info when restoring frame pointer from fpr Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Target Milestone: --- Created attachment 46082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46082&action=edit Testcase Compiling the attached testcase with GCC built with checking enabled ICEs: during RTL pass: dwarf2 t.c:10:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2348 } ^ 0x13a7649 maybe_record_trace_start /home/andreas/gcc/gcc/dwarf2cfi.c:2348 0x13a9d6f scan_trace /home/andreas/gcc/gcc/dwarf2cfi.c:2541 0x13aa40b create_cfi_notes /home/andreas/gcc/gcc/dwarf2cfi.c:2694 0x13aa40b execute_dwarf2_frame /home/andreas/gcc/gcc/dwarf2cfi.c:3057 0x13aa40b execute /home/andreas/gcc/gcc/dwarf2cfi.c:3545 There is an edge from very early in the function to right before the call to "j" which is executed as sibcall. In between the hard frame pointer (r11) is saved to and FPR, set to the stack pointer and restored from the FPR. After restoring the hard frame pointer register to its former value the backend misses to set the CFA register back to r15. That's why the sibcall insn can be reached with the CFA register being either r11 or r15.
[Bug fortran/67744] [OOP] polymorphic associating entity is refused TBP invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744 --- Comment #5 from Bader at lrz dot de --- This is still not fixed in current trunk.
[Bug tree-optimization/89730] -flive-patching=inline-only-static should grant always_inline attribute for extern function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89730 --- Comment #2 from qinzhao at gcc dot gnu.org --- Author: qinzhao Date: Wed Apr 3 19:00:25 2019 New Revision: 270134 URL: https://gcc.gnu.org/viewcvs?rev=270134&root=gcc&view=rev Log: 2019-04-03 qing zhao PR tree-optimization/89730 * ipa-inline.c (can_inline_edge_p): Delete the checking for -flive-patching=inline-only-static. (can_inline_edge_by_limits_p): Add the checking for -flive-patching=inline-only-static and grant always_inline even when -flive-patching=inline-only-static is specified. * gcc.dg/live-patching-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/live-patching-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug target/89951] New: Uncorrect flag for Nehalem / westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951 Bug ID: 89951 Summary: Uncorrect flag for Nehalem / westmere Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bratsinot at gmail dot com Target Milestone: --- gcc set uncorrect flags -mavx256-split-unaligned-load and -mavx256-split-unaligned-store when use -march=native or Nehalem / westmere arch. Nehalem / westmere don't have AVX instruction set. So program with these instructions build incorrectly. For example: # gcc -march=westmere -Q --help=target ... | grep avx -mavx [disabled] <...> -mavx256-split-unaligned-load [enabled] -mavx256-split-unaligned-store[enabled] <...>
[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 --- Comment #11 from Dominique d'Humieres --- Frustrating!-(
[Bug fortran/41650] [Cleanup] Use gfc_expr_attr in resolve_allocate_expr/resolve_deallocate_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41650 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Dominique d'Humieres --- > Is this still valid? No answer, closing as INVALID.
[Bug c/89950] New: attribute aligned ignored with attribute vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950
Bug ID: 89950
Summary: attribute aligned ignored with attribute vector_size
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When attribute aligned appears in conjunction with attribute vector_size on the
same declaration and when the former specifies a different alignment than the
latter attribute implies, the alignment specified by the former attribute is
ignored.
However, when attribute aligned is specified on a vector (re)declaration
without attribute vector_size, the alignment is honored.
$ cat z.c && gcc -O2 -S -Wall z.c
void f (void)
{
typedef __attribute__ ((vector_size (1024))) int Vec_1k;
typedef __attribute__ ((aligned (256))) Vec_1k V;
_Static_assert (__alignof__ (V) == 256); // passes
_Static_assert (__builtin_has_attribute (V, aligned (256))); // passes
V v;
_Static_assert (__alignof__ (v) == 256); // passes
_Static_assert (__builtin_has_attribute (v, aligned (256))); // passes
}
void g (void)
{
typedef __attribute__ ((aligned (256), vector_size (1024))) int V;
_Static_assert (__alignof__ (V) == 256); // fails
_Static_assert (__builtin_has_attribute (V, aligned (256))); // fails
V v;
_Static_assert (__alignof__ (v) == 256); // fails
_Static_assert (__builtin_has_attribute (v, aligned (256))); // fails
}
z.c: In function ‘g’:
z.c:17:3: error: static assertion failed
17 | _Static_assert (__alignof__ (V) == 256); //
fails
| ^~
z.c:18:3: error: static assertion failed
18 | _Static_assert (__builtin_has_attribute (V, aligned (256))); //
fails
| ^~
z.c:21:3: error: static assertion failed
21 | _Static_assert (__alignof__ (v) == 256); //
fails
| ^~
z.c:22:3: error: static assertion failed
22 | _Static_assert (__builtin_has_attribute (v, aligned (256))); //
fails
| ^~
[Bug fortran/89646] [7/8/9 Regression] Spurious actual argument might interfere warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646 --- Comment #5 from Dominique d'Humieres --- > I meant "replace the 0". The replacement could be OPT_Wsurprising (-Wsurprising, included in -Wall) or OPT_Wextra (-Wextra) or yet a new option. The warning is tested in gfortran.dg/elemental_dependency_1.f90.
[Bug c++/89949] New: Internal compiler error with lambda as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89949 Bug ID: 89949 Summary: Internal compiler error with lambda as template argument Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- Since C++20 a template parameter type can be any LiteralType that has strong structural equality. Lambdas are classified as a LiteralType since C++17. Reproducible example of the internal compiler error: https://godbolt.org/z/UP3gG2. Relevant cppreference pages: https://en.cppreference.com/w/cpp/language/template_parameters https://en.cppreference.com/w/cpp/named_req/LiteralType
[Bug c++/89948] New: [9 Regression] ICE in fold_convert_loc, at fold-const.c:2430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89948
Bug ID: 89948
Summary: [9 Regression] ICE in fold_convert_loc, at
fold-const.c:2430
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20190217 and 20190224 :
$ cat z1.cc
void f ()
{
int a = 0;
for (;;)
for (;a=+({break;1;});)
{}
}
$ g++-9-20190217 -c z1.cc
$
$ g++-9-20190224 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:5:25: internal compiler error: in fold_convert_loc, at fold-const.c:2430
5 | for (;a=+({break;1;});)
| ^
0x91f287 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2429
0x61f440 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4995
0x6200ac cxx_eval_store_expression
../../gcc/cp/constexpr.c:3678
0x61e18d cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4582
0x6218d4 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:5280
0x623c30 maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:5512
0x62e9b4 cp_fully_fold(tree_node*)
../../gcc/cp/cp-gimplify.c:2165
0x740c5b cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
../../gcc/cp/typeck.c:5539
0x742b1f build_binary_op(unsigned int, tree_code, tree_node*, tree_node*, bool)
../../gcc/cp/typeck.c:4246
0x742b63 cp_truthvalue_conversion(tree_node*)
../../gcc/cp/typeck.c:5866
0x63317e ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/cp/cvt.c:844
0x634247 cp_convert(tree_node*, tree_node*, int)
../../gcc/cp/cvt.c:637
0x634247 cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/cp/cvt.c:656
0x5f7df1 convert_like_real
../../gcc/cp/call.c:7372
0x5f8950 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:11089
0x738a5a condition_conversion(tree_node*)
../../gcc/cp/typeck.c:5878
0x71f1a4 maybe_convert_cond
../../gcc/cp/semantics.c:1010
0x71f1a4 finish_for_cond(tree_node*, tree_node*, bool, unsigned short)
../../gcc/cp/semantics.c:991
0x6d2690 cp_parser_c_for
../../gcc/cp/parser.c:12148
0x6d2690 cp_parser_for
../../gcc/cp/parser.c:12116
[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83655, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83603 --- Comment #3 from Martin Sebor --- See also pr83603 and pr83655 for similar errors. Now that GCC diagnoses calls with incompatible/incorrect arguments to built-ins declared without a prototype the solution suggested in the review of the fix for the latter: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00244.html i.e., using gimple_call_builtin_p(), might be worth revisiting for GCC 10 (though it might be obviated by rejecting the incompatible calls or by replacing them with traps).
[Bug c++/89947] New: Resolution of base classes fail for some automatic types in template struct functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89947
Bug ID: 89947
Summary: Resolution of base classes fail for some automatic
types in template struct functions
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: paolo at luccalug dot it
Target Milestone: ---
Created attachment 46081
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46081&action=edit
A minimal testcase
I'm using G++ 8.2.1 installed with the Arch Linux package `gcc
8.2.1+20181127-1`.
```
$ g++ -v
g++ (GCC) 8.2.1 20181127
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
A minimal source file that triggers the problem is the following:
```
namespace ns {
struct A { void f(){} };
}
template struct B { void f(){} };
struct C : public ns::A, B {};
template struct X { // NOTE: no error if X were not a template
C getC() { return C(); } // NOTE: no error if `getC` were outside of
this class
void f() {
// NOTE: no error if we're running this code from outside of
this class: `x.getC().A...`
getC().A::f(); // ‘A’ has not been declared
auto c4 = getC(); c4.A::f(); // ‘A’ has not been declared
decltype(getC()) c5 = getC(); c5.A::f(); // ‘A’ has not been
declared
C c6 = getC(); c6.A::f(); // this one works
getC().B::f(); // ‘template struct B’ used without
template parameters
auto c1 = getC(); c1.B::f(); // ‘template struct B’
used without template parameters
decltype(getC()) c2 = getC(); c1.B::f(); // ‘template
struct B’ used without template parameters
C c3 = getC(); c3.B::f(); // this one works
}
};
int main() {
X x;
x.f();
return 0;
}
```
G++ fails to build it with default options (and any options I tried):
```
$ g++ test.cpp
test.cpp: In member function ‘void X::f()’:
test.cpp:14:10: error: ‘A’ has not been declared
getC().A::f(); // ‘A’ has not been declared
^
test.cpp:15:24: error: ‘A’ has not been declared
auto c4 = getC(); c4.A::f(); // ‘A’ has not been declared
^
test.cpp:16:36: error: ‘A’ has not been declared
decltype(getC()) c5 = getC(); c5.A::f(); // ‘A’ has not been declared
^
test.cpp:19:10: error: ‘template struct B’ used without template
parameters
getC().B::f(); // ‘template struct B’ used without template
parameters
^
test.cpp:20:24: error: ‘template struct B’ used without template
parameters
auto c1 = getC(); c1.B::f(); // ‘template struct B’ used without
template parameters
^
test.cpp:21:36: error: ‘template struct B’ used without template
parameters
decltype(getC()) c2 = getC(); c1.B::f(); // ‘template struct B’
used without template parameters
```
Clang (8.0.0) gives no error, and I believe that's the expected behavior.
[Bug c/89946] New: [8/9 Regression] ICE in assemble_start_function, at varasm.c:1871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946
Bug ID: 89946
Summary: [8/9 Regression] ICE in assemble_start_function, at
varasm.c:1871
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-8 (and values N < 0) :
$ cat z1.c
__attribute__((patchable_function_entry(-1)))
void f () {}
$ gcc-9-20190331 -c z1.c
during RTL pass: final
z1.c: In function 'f':
z1.c:2:1: internal compiler error: in assemble_start_function, at varasm.c:1871
2 | void f () {}
| ^~~~
0xceabe6 assemble_start_function(tree_node*, char const*)
../../gcc/varasm.c:1871
0x7d8e2f rest_of_handle_final
../../gcc/final.c:4655
0x7d8e2f execute
../../gcc/final.c:4737
[Bug c++/86567] [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||dmalcolm at gcc dot gnu.org Depends on||56856 Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed for GCC 9 by the patch for PR 56856, which removed that call to maybe_constant_value. Not worth backporting. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856 [Bug 56856] -Wformat warnings don't show location *within* format string in C++ FE
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 Bug 86518 depends on bug 86567, which changed state. Bug 86567 Summary: [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/89945] [7/8/9 Regression] ICE in gen_lowpart_general, at rtlhooks.c:63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89945 Andrew Pinski changed: What|Removed |Added Component|c |target Target Milestone|--- |7.5
[Bug c/89945] New: [7/8/9 Regression] ICE in gen_lowpart_general, at rtlhooks.c:63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89945
Bug ID: 89945
Summary: [7/8/9 Regression] ICE in gen_lowpart_general, at
rtlhooks.c:63
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects gcc-7 upwards at -O[s123], gcc-6 compiles it :
$ cat z1.c
void foo ()
{
void *g[] = {&&a, &&b};
for (unsigned c = 0x1F;; c >>= 1)
{
unsigned d = (long)"a";
long e = 8;
while (e)
{
a: goto *g[c&d];
b: e--;
}
}
}
$ gcc-6 -c z1.c -O2
$ gcc-9-20190331 -c z1.c -O0
$
$ gcc-9-20190331 -c z1.c -O2
during RTL pass: split1
z1.c: In function 'foo':
z1.c:14:1: internal compiler error: in gen_lowpart_general, at rtlhooks.c:63
14 | }
| ^
0xa280f8 gen_lowpart_general(machine_mode, rtx_def*)
../../gcc/rtlhooks.c:63
0xf81f7e gen_split_144(rtx_insn*, rtx_def**)
../../gcc/config/i386/i386.md:8612
0x111247f split_17
../../gcc/config/i386/i386.md:1047
0x1117d94 split_insns(rtx_def*, rtx_insn*)
../../gcc/config/i386/i386.md:13199
0x796b11 try_split(rtx_def*, rtx_insn*, int)
../../gcc/emit-rtl.c:3851
0x9ea901 split_insn
../../gcc/recog.c:2901
0x9eea22 split_all_insns()
../../gcc/recog.c:3005
0x9eeb28 execute
../../gcc/recog.c:3905
[Bug target/89399] [7/8/9 Regression] ICE: RTL check: expected code 'set', 'clobber' or 'clobber_high', have 'parallel' in combine_reaching_defs, at ree.c:783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89399 --- Comment #5 from Jeffrey A. Law --- So I think in the immediate term any time we're using PATTERN (cand->insn) we really should be using single_set (cand->insn). We already know we've passed the single_set test when we put the insn onto the candidate list. I haven't audited all the uses of get_sub_rtx, but the ones I have looked at look like it's used on the insn we're modifying rather than the candidate insn (which is the extension we're trying to completely eliminate). I'm going to spin the change to avoid incorrect uses of PATTERN (cand->insn) in my tester.
[Bug c/89944] New: [7/8/9 Regression] ICE in mark_jump_label_1, at jump.c:1152
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89944
Bug ID: 89944
Summary: [7/8/9 Regression] ICE in mark_jump_label_1, at
jump.c:1152
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Gives an ICE down to gcc-4.6, gcc-4.5 (and others) accept it :
$ cat z1.c
void buf ()
{
__builtin_setjmp (buf);
__builtin_longjmp (buf, 1);
}
$ gcc-9-20190331 -c z1.c -O0
$
$ gcc-9-20190331 -c z1.c -O2
during RTL pass: cse1
z1.c: In function 'buf':
z1.c:5:1: internal compiler error: in mark_jump_label_1, at jump.c:1152
5 | }
| ^
0x902146 mark_jump_label_1
../../gcc/jump.c:1152
0x901ec9 mark_jump_label_1
../../gcc/jump.c:1212
0x90243d mark_all_labels
../../gcc/jump.c:305
0x90243d rebuild_jump_labels_1
../../gcc/jump.c:74
0x115faa1 rest_of_handle_cse
../../gcc/cse.c:7687
0x115faa1 execute
../../gcc/cse.c:7721
[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934 Martin Sebor changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Summary|[9 Regression] ICE in |[9 Regression] ICE on a |tree_fits_uhwi_p, at|call with fewer arguments |tree.c:7237 |to strncpy declared without ||prototype --- Comment #2 from Martin Sebor --- Declaring a built-in function with an incompatible signature is unsafe but GCC only diagnoses it with -Wextra (starting with GCC 9). Calling a library function with fewer arguments than it expects is undefined. Calling a built-in function with fewer arguments is invalid and diagnosed (also starting in GCC 9) but not rejected. The call should either be rejected with an error (like Clang does) or replaced with a trap to avoid the undefined behavior at runtime, but it's too late to make that change for GCC 9. Hopefully in GCC 10. In the meantime, let me remove the assumption that the call is valid from the -Wrestrict pass.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #7 from H.J. Lu ---
__attribute__((target("foo"))) can be used in 2 different ways:
1. Enable FOO, which works for both C and C++.
2. Function versioning with FOO, which works only for C++.
2 is a subset of 1. We should improve error message when target
is in 1, but outside of 2.
[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431 --- Comment #18 from Jonathan Wakely --- Proposed new patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00142.html
[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025 Jeffrey A. Law changed: What|Removed |Added Summary|[8/9 Regression] gcc ICE|[8 Regression] gcc ICE |while building glibc for|while building glibc for |MIPS soft-float multi-lib |MIPS soft-float multi-lib |variant |variant --- Comment #18 from Jeffrey A. Law --- Fixed on the trunk. Backporting to gcc-8 would be trivial, but I'm not sure it's worth the effort.
[Bug rtl-optimization/81025] [8/9 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025 --- Comment #17 from Jeffrey A. Law --- Author: law Date: Wed Apr 3 16:03:37 2019 New Revision: 270129 URL: https://gcc.gnu.org/viewcvs?rev=270129&root=gcc&view=rev Log: PR rtl-optimization/81025 * reorg.c (skip_consecutive_labels): Do not skip past a BARRIER. Modified: trunk/gcc/ChangeLog trunk/gcc/reorg.c
[Bug c++/89596] [8/9 regression] Multiple templated conversion operators result in compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89596 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jason Merrill --- Fixed by the patch for 86521. *** This bug has been marked as a duplicate of bug 86521 ***
[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 Jason Merrill changed: What|Removed |Added CC||jleahy+gcc at gmail dot com --- Comment #10 from Jason Merrill --- *** Bug 89596 has been marked as a duplicate of this bug. ***
[Bug c++/89596] [8/9 regression] Multiple templated conversion operators result in compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89596 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-03 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
--- Comment #4 from Jason Merrill ---
(In reply to Stas Sergeev from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > Simplified testcase:
> > struct A { char a; };
> > struct B : public A { static constexpr int b = __builtin_offsetof (B, a); };
> >
> > clang rejects this too, not really sure if it is valid or not.
>
> Thanks for taking a look!
> A slight off-topic: any idea why even this rejects:
> struct A {
> char a;
> static constexpr int b = __builtin_offsetof (A, a);
> };
>
> and is there any work-around when I want to
> pass offsetof value into a template non-type,
> which also rejects:
> struct A {
> char a;
> B<__builtin_offsetof(A, a)> b;
> };
>
> Does the standard explicitly forbids that, of just gcc?
The standard says that for a standard-layout class, the address of the first
member is the same as the address of the class, so offsetof(A,a) will be 0.
But when we're in the middle of the class definition we don't know yet whether
it's standard-layout, so we can't answer yet. A compiler is allowed to reorder
fields of a non-standard-layout class.
[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878 Martin Sebor changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-03 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89833 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html
[Bug c++/89833] [9 Regression] sorry, unimplemented: string literal in function template signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89833 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html
[Bug c++/47488] sorry, unimplemented: string literal in function template signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488 Martin Sebor changed: What|Removed |Added Keywords||patch CC||msebor at gcc dot gnu.org --- Comment #14 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html
[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00108.html
[Bug c++/87770] [8 Regression] ICE in type_dependent_expression_p, at cp/pt.c:25230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87770 Jason Merrill changed: What|Removed |Added CC||roman.s.dubtsov at intel dot com --- Comment #9 from Jason Merrill --- *** Bug 89919 has been marked as a duplicate of this bug. ***
[Bug c++/89919] [8/9 Regression] internal compiler error when building MKL-DNN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89919 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jason Merrill --- Fixed on trunk by the patch for 87770. *** This bug has been marked as a duplicate of bug 87770 ***
[Bug c/89798] excessive vector_size silently accepted and truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00108.html
[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from H.J. Lu --- Is this a dup of PR 59464?
[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68567 --- Comment #8 from Dominique d'Humieres --- Packaging submitted at https://gcc.gnu.org/ml/fortran/2019-04/msg7.html.
[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 --- Comment #16 from Jonathan Wakely --- (In reply to Seyyed Soroosh Hosseinalipour from comment #15) > @jason what is work around for gcc6 ? See comment 6. Name the pack.
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 --- Comment #11 from Дилян Палаузов --- Reported for ld.gold at https://sourceware.org/bugzilla/show_bug.cgi?id=24415 .
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 --- Comment #10 from Дилян Палаузов --- With the patch applied this works: clang -flto -fuse-ld=bfd -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O2 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O1 t.c This does not work: gcc -flto -fuse-ld=gold -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=gold -Wl,--wrap=read -O2 t.c gcc -flto -fuse-ld=gold -Wl,--wrap=read -O1 t.c
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 --- Comment #9 from Дилян Палаузов --- With the patch applied to ld.bfd “clang -flto -fuse-ld=bfd -Wl,--wrap=read t.c” does work.
[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501 --- Comment #31 from Andrey Drobyshev --- (In reply to Jakub Jelinek from comment #30) > in a couple of most common data sections In which sections exactly? If we cover only the most common ones (thus leaving other sections which might need protection uncovered) there always be a case when out patch won't work. On the other hand, if we include all the possible sections which might need protection, the resulting binary would bloat with unneeded sections.
[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582
--- Comment #4 from Richard Biener ---
Looks like LLVM has all the ABI details exposed very early but also in a very
awkward way(?). The vfloat one shows
define { <2 x float>, <2 x float> } @f(<2 x float> %x.coerce0, <2 x float>
%x.coerce1, <2 x float> %y.coerce0, <2 x float> %y.coerce1) #0 {
%1 = alloca %struct.vfloat, align 16
%x = alloca %struct.vfloat, align 16
%y = alloca %struct.vfloat, align 16
%2 = bitcast %struct.vfloat* %x to { <2 x float>, <2 x float> }*
%3 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x
float> }* %2, i32 0, i32 0
store <2 x float> %x.coerce0, <2 x float>* %3, align 16
%4 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x
float> }* %2, i32 0, i32 1
store <2 x float> %x.coerce1, <2 x float>* %4, align 8
%5 = bitcast %struct.vfloat* %y to { <2 x float>, <2 x float> }*
%6 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x
float> }* %5, i32 0, i32 0
store <2 x float> %y.coerce0, <2 x float>* %6, align 16
%7 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x
float> }* %5, i32 0, i32 1
store <2 x float> %y.coerce1, <2 x float>* %7, align 8
for the parameter setup (if I deciper the IL correctly) and
%32 = bitcast %struct.vfloat* %1 to { <2 x float>, <2 x float> }*
%33 = load { <2 x float>, <2 x float> }, { <2 x float>, <2 x float> }* %32,
align 16
ret { <2 x float>, <2 x float> } %33
for the return value.
I was thinking of a way to expose the ABI details to GIMPLE recently
but feared this would look a bit like a mess (also considering
prologue/epilogue expansion target constraints).
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from H.J. Lu --- A linker patch is posted at https://sourceware.org/ml/binutils/2019-04/msg00018.html But it won't work with -O2 since LTO inlines cook before linker can wrap it.
[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 Seyyed Soroosh Hosseinalipour changed: What|Removed |Added CC||soorosh_abi at hotmail dot com --- Comment #15 from Seyyed Soroosh Hosseinalipour --- ITNOA @jason what is work around for gcc6 ? thanks
[Bug c/71598] Wrong optimization with aliasing enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598 --- Comment #15 from Christophe Lyon --- Author: clyon Date: Wed Apr 3 13:17:04 2019 New Revision: 270126 URL: https://gcc.gnu.org/viewcvs?rev=270126&root=gcc&view=rev Log: [testsuite] PR71598: Fix testcases 2019-04-13 Christophe Lyon PR c/71598 * gcc.dg/torture/pr71598-1.c: Skip if short_enums target. * gcc.dg/torture/pr71598-2.c: Skip if not short_enums target. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr71598-1.c trunk/gcc/testsuite/gcc.dg/torture/pr71598-2.c
[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #4 from Jonathan Wakely --- Please leave the bug open, as I said: > It would be good if that assertion was more explanatory, or at least had a > comment saying it will only be reached when given bad input. I'm confirming > this bug as a reminder to improve that some time.
[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> So compared to the already mitigated PR84101 this one returns in
>
> (parallel:TI [
> (expr_list:REG_DEP_TRUE (reg:DF 20 xmm0)
> (const_int 0 [0]))
> (expr_list:REG_DEP_TRUE (reg:DF 21 xmm1)
> (const_int 8 [0x8]))
> ])
>
> so I wonder how targets represent if they return the _same_ value in
> two different locations. I also wonder whether the above is any
> standard form.
From docs of (set ...):
If @var{lval} is a @code{parallel}, it is used to represent the case of
a function returning a structure in multiple registers. Each element
of the @code{parallel} is an @code{expr_list} whose first operand is a
@code{reg} and whose second operand is a @code{const_int} representing the
offset (in bytes) into the structure at which the data in that register
corresponds. The first element may be null to indicate that the structure
is also passed partly in memory.
I guess if the offset is the same (or overlapping) that can handle
multiple locations for the same value.
For the vfloat testcase the return value on x86 is in the following
(note reg:DI pieces vs. reg:V2SF vs. reg:DF for the vdouble case)
(parallel:TI [
(expr_list:REG_DEP_TRUE (reg:DI 20 xmm0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DI 21 xmm1)
(const_int 8 [0x8]))
])
[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|NEW |ASSIGNED
CC||jakub at gcc dot gnu.org,
||law at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
Component|target |tree-optimization
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
So compared to the already mitigated PR84101 this one returns in
(parallel:TI [
(expr_list:REG_DEP_TRUE (reg:DF 20 xmm0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DF 21 xmm1)
(const_int 8 [0x8]))
])
so I wonder how targets represent if they return the _same_ value in
two different locations. I also wonder whether the above is any
standard form.
Covering the above in the same way as PR84101 doesn't prevent vectorization:
t.c:8:14: note: Cost model analysis:
Vector inside of basic block cost: 48
Vector prologue cost: 0
Vector epilogue cost: 36
Scalar cost of basic block: 96
t.c:8:14: note: Basic block will be vectorized using SLP
even though we've added one vector store and two scalar loads to pessimize it.
Here the vector construction from the argument passing comes into play
which also isn't "pessimized" accordingly because the vectorizer thinks it
can perform vector loads from memory here, replacing four scalar loads
(but in fact x.x1, y.x1, x.x2 and y.x2 are readily available in %xmm0 to 3).
Another interesting testcase is
typedef struct {
float x1;
float x2;
float x3;
float x4;
} vfloat __attribute__((aligned(16)));
vfloat f(vfloat x, vfloat y)
{
return (vfloat){x.x1 + y.x1, x.x2 + y.x2, x.x3 + y.x3, x.x4 + y.x4};
}
where the _scalar_ code is really awkward (even though for the vector
case the vectorizer still thinks it is all memory). Passing two
floats in a single 8-bytes is a really odd ABI choice:
f:
.LFB0:
.cfi_startproc
movq%xmm0, %rdi
movq%xmm2, %r9
movq%xmm1, %rdx
movq%xmm3, %rcx
shrq$32, %rdi
addss %xmm2, %xmm0
shrq$32, %r9
shrq$32, %rdx
movd%edi, %xmm5
shrq$32, %rcx
movd%r9d, %xmm6
movd%edx, %xmm7
addss %xmm6, %xmm5
movd%ecx, %xmm4
movaps %xmm1, %xmm6
addss %xmm4, %xmm7
addss %xmm3, %xmm6
movd%xmm5, %eax
movq%rax, %rsi
movd%xmm7, %edx
movd%xmm0, %eax
salq$32, %rsi
salq$32, %rdx
movd%xmm6, %ecx
orq %rsi, %rax
orq %rcx, %rdx
movq%rdx, %xmm1
movq%rax, %xmm0
ret
vs. vectorized:
f:
.LFB0:
.cfi_startproc
movq%xmm1, -32(%rsp)
movq%xmm0, -40(%rsp)
movaps -40(%rsp), %xmm4
movq%xmm2, -24(%rsp)
movq%xmm3, -16(%rsp)
addps -24(%rsp), %xmm4
movaps %xmm4, -40(%rsp)
movq-32(%rsp), %rax
movq-40(%rsp), %xmm0
movq%rax, %xmm1
movq%rax, -24(%rsp)
ret
here the spilling is still bad (STLF penalties) but in the end vectorizing
this makes sense and we want to preserve that.
Lame attempt to handle PARALLELs:
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 270123)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -1076,23 +1076,24 @@ vect_model_store_cost (stmt_vec_info stm
&& !aggregate_value_p (base, cfun->decl))
{
rtx reg = hard_function_value (TREE_TYPE (base), cfun->decl, 0, 1);
- /* ??? Handle PARALLEL in some way. */
+ int nregs = 1;
if (REG_P (reg))
+ nregs = hard_regno_nregs (REGNO (reg), GET_MODE (reg));
+ /* ??? Handle PARALLEL better (see PR89582 for an example). */
+ else if (GET_CODE (reg) == PARALLEL)
+ nregs = XVECLEN (reg, 0);
+ /* Assume that a single reg-reg move is possible and cheap,
+do not account for vector to gp register move cost. */
+ if (nregs > 1)
{
- int nregs = hard_regno_nregs (REGNO (reg), GET_MODE (reg));
- /* Assume that a single reg-reg move is possible and cheap,
-do not account for vector to gp register move cost. */
- if (nregs > 1)
- {
- /* Spill. */
- prologue_cost += record_stmt_cost (cost_vec, ncopies,
-vector_store,
-
[Bug c++/89900] [9 Regression] ICE: Segmentation fault (in check_instantiated_arg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89900 --- Comment #2 from Paolo Carlini --- I think that ultimately this boils down to this code in grokdeclarator: if (type_was_error_mark_node && template_parm_flag) /* FIXME we should be able to propagate the error_mark_node as is for other contexts too. */ type = error_mark_node; else type = integer_type_node; where we use integer_type_node as a catch-all type in case of error. Certainly using error_mark_node avoids this ICE, and many other I suppose, but we are not ready yet to resolve the FIXME (what about GCC-10?!?). We may want to fix this specific ICE in a different way, for the time being.
