[Bug other/44435] gengtype: don't test undefined value after vasprintf failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435 Eric Gallager changed: What|Removed |Added CC||dj at redhat dot com, ||joseph at codesourcery dot com --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to jos...@codesourcery.com from comment #5) > > Subject: Re: gengtype: don't test undefined value after > > vasprintf failure > > > > On Mon, 7 Jun 2010, dj at redhat dot com wrote: > > > > > > If the libiberty maintainers won't review the xvasprintf patch, > > > > > > I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html > > > > That's a review of an older version. The URLs I gave were of a version a > > different person updated to take account of your original review comments. > > Has the updated version been reviewed yet? Joseph, do you remember what happened with this, if anything?
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 --- Comment #3 from Hongtao.liu --- (In reply to Hongtao.liu from comment #2) > It seems such code generation is r254855's intention. > > /* Use 256-bit AVX instructions instead of 512-bit AVX > instructions > 4695in the auto-vectorizer. */ > 4696 if (ix86_tune_features[X86_TUNE_AVX256_OPTIMAL] > 4697 && !(opts_set->x_ix86_target_flags & > OPTION_MASK_PREFER_AVX256)) > 4698 opts->x_ix86_target_flags |= OPTION_MASK_PREFER_AVX256; > > I know there is a frequency reduction issue when many zmm registers are > used, but i don't know what exact situation did r254855 deal with? But it should generate assemble like what g++ did which also use ymm instead of zmm.
[Bug fortran/90218] New: [PDT] ICE: tree check: expected array_type, have record_type in gfc_conv_array_initializer, at fortran/trans-array.c:6071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90218 Bug ID: 90218 Summary: [PDT] ICE: tree check: expected array_type, have record_type in gfc_conv_array_initializer, at fortran/trans-array.c:6071 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Created attachment 46236 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46236=edit Testcase gfortran-9.0.0-alpha20190421 snapshot (r270485) ICEs, and 8.2 demonstrates a memory hog when compiling the attached testcase copied from [1]: % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190421 -c nag-20180205a.f90 nag-20180205a.f90:21:0: 21 | end | internal compiler error: tree check: expected array_type, have record_type in gfc_conv_array_initializer, at fortran/trans-array.c:6071 0x6a3d1c tree_check_failed(tree_node const*, char const*, int, char const*, ...) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree.c:9900 0x56293c tree_check(tree_node*, char const*, int, char const*, tree_code) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree.h:3176 0x56293c gfc_conv_array_initializer(tree_node*, gfc_expr*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/trans-array.c:6068 0x88a342 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/trans-expr.c:7384 0x88a823 gfc_conv_structure(gfc_se*, gfc_expr*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/trans-expr.c:8286 0x88a317 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/trans-expr.c:7419 0x866499 gfc_emit_parameter_debug_info /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/trans-decl.c:5409 0x866499 gfc_emit_parameter_debug_info /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/trans-decl.c:5341 0x82a652 do_traverse_symtree /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/symbol.c:4166 0x8741b2 gfc_generate_function_code(gfc_namespace*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/trans-decl.c:6821 0x7f2714 translate_all_program_units /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:6134 0x7f2714 gfc_parse_file() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/parse.c:6337 0x84064e gfc_be_parse_file /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/fortran/f95-lang.c:204 (While my target is powerpc here, the ICE is not target-specific.) [1] https://github.com/nncarlson/fortran-compiler-tests/blob/bee34a692422e8c6dba49d3e7ac3fd9629fda068/nag-bugs/nag-20180205a.f90
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 --- Comment #2 from Hongtao.liu --- It seems such code generation is r254855's intention. /* Use 256-bit AVX instructions instead of 512-bit AVX instructions 4695 in the auto-vectorizer. */ 4696 if (ix86_tune_features[X86_TUNE_AVX256_OPTIMAL] 4697 && !(opts_set->x_ix86_target_flags & OPTION_MASK_PREFER_AVX256)) 4698 opts->x_ix86_target_flags |= OPTION_MASK_PREFER_AVX256; I know there is a frequency reduction issue when many zmm registers are used, but i don't know what exact situation did r254855 deal with?
[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89735 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Iain Buclaw --- Tests that were problematic on bigendian were fixed in r270523. I can't see any more reported issues, so marking resolved.
[Bug d/88431] link errors on build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88431 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- Fixed in r270531.
[Bug d/88431] link errors on build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88431 --- Comment #4 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Wed Apr 24 02:04:04 2019 New Revision: 270531 URL: https://gcc.gnu.org/viewcvs?rev=270531=gcc=rev Log: libphobos: Fix link build errors when compiling with unsupported options The first compilation test to get baseline warnings was getting more messages due to a missing object.d file, compared to later configure tests where libphobos is in the include paths. Because there must always be an object module during compilation, let the tests themselves be an empty object module instead. libphobos/ChangeLog: 2019-04-24 Iain Buclaw PR d/88431 * configure: Regenerate. * m4/libtool.m4 (lt_simple_compile_test_code): Update to not have dependencies on libphobos. (lt_simple_link_test_code): Likewise. (GDCFLAGS): Don't override for D compiler tests. Modified: trunk/libphobos/ChangeLog trunk/libphobos/configure trunk/libphobos/m4/libtool.m4
[Bug c++/90217] New: Greater optimization of C++ Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90217 Bug ID: 90217 Summary: Greater optimization of C++ Code Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stevexiong98 at hotmail dot com Target Milestone: --- Hi, This is not so much a bug, but more of an enhancement. There are 2 pieces of code I have listed below which should translate to identical assembly instructions at high levels of compiler optimization (level 3) but currently do not. https://godbolt.org/z/Zn7FMK https://godbolt.org/z/wB8eZd Using ARM GCC 8.2, the code in the second link involves the stack pointer and extra load/store operations to the newly-created stack space. There are more assembly instructions in link 2's code than in link 1's code. However, in Godbolt if you switch the compiler to Clang, at optimization 3 both pieces of code manage to compile down to the same minimal Assembly instructions. Switching the compiler to x86-64 GCC (trunk), the code in the second link also has a few extra operations compared the first link's code. Is it possible to set ARM GCC and x86-64 GCC to a particular optimization setting that allows both links' code to have matching assembly instructions? If not, is it possible that in a future release, both compilers could apply enough optimizations so that the assembly in link 1 matches link 2? Thanks
[Bug translation/90117] Replace %<%s%> with %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117 --- Comment #2 from Roland Illig --- (In reply to Martin Liška from comment #1) > Makes sense, I'll integrate that to our linter. I've already integrated that into the linter, see the latest attachment in bug 90176.
[Bug translation/90176] diagnostics should generally contain underscore only inside quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176 Roland Illig changed: What|Removed |Added Attachment #46234|0 |1 is obsolete|| --- Comment #5 from Roland Illig --- Created attachment 46235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46235=edit linter with check for bug 90117
[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183 --- Comment #9 from Roland Illig --- Is there already someone who wants to fix the remaining messages? Jakub, you fixed some of them already in https://gcc.gnu.org/viewcvs?rev=258154=gcc=rev in March 2018. There are still some messages that use fmtwarn instead of fmtwarn_n and still contain "%wu bytes" or its close relative "%wu or more bytes". Another even trickier message is "between %wu and %wu bytes". This one uses a range of numbers, and in Arabic the rules for the correct word form are quite numerous: https://www.unicode.org/cldr/charts/33/supplemental/language_plural_rules.html#ar If GCC wants to be the project demonstrating best practices in translation, it should even handle this case correctly. I'm not sure though whether gettext supports this at all. Current state: #c0 is fixed #c1 is fixed in 2 out of 3 cases #c6 is fixed
[Bug middle-end/90216] Stack Pointer decrementing even when not loading extra data to stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90216 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-23 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed, part of the problem is union is forced to memory early on but then optimized out but the object still exist in memory even though it is dead. I am working on an optimization which improves this by the lowering of bit-fields. But it won't go in until post GCC 9 (released next year).
[Bug c++/90216] New: Stack Pointer decrementing even when not loading extra data to stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90216 Bug ID: 90216 Summary: Stack Pointer decrementing even when not loading extra data to stack. Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stevexiong98 at hotmail dot com Target Milestone: --- Hi, Using ARM GCC 8.2, when I instantiate an object the corresponding Assembly instructions involve a decrementing, then incrementing of the stack pointer. However, no values are being transferred between the registers and the empty stack space. Please check out this link for details, lines 5 and 7 in the Assembly panel show how the stack pointer is decremented/incremented unnecessarily. https://godbolt.org/z/h-H7Ox In the C++ panel when you comment out line 53 and uncomment the line below, the Assembly instructions involving the stack pointer disappear. The same is true if you uncomment just line 55. Can you please explain why the stack pointer inc/dec operations are not optimized out in the first line of code (line 53)? Can you please try to release a patch where this unnecessary stack pointer inc/dec is no longer an issue? Thanks
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205 Tavian Barnes changed: What|Removed |Added CC||tavianator at gmail dot com --- Comment #8 from Tavian Barnes --- Maybe "argument 2 has type 'double' (promoted from 'float')"?
[Bug c++/86044] noexcept(false) of constexpr member function ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86044 --- Comment #3 from Jonathan Wakely --- Yes, this was a duplicate of PR 87603.
[Bug translation/90119] Merge translation msgids that only differ in placeholders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119 --- Comment #7 from Roland Illig --- I didn't want to sound that harsh in my previous comment. What I wanted to say is: to make the linter reliable and be able to handle the full syntax of .po files, it's better to use an exising library that is well-tested instead of parsing .po files ad-hoc using regular expressions and raw string functions. That way the code of the linter becomes easy to read since it uses the standard terminology of the .po structures, and it is easy to access all gettext features (such as plurals or other formats) without modifying the parser code. It also becomes easier to add new checks to the linter. The diagnostics of the linter now follow more closely the GCC Guidelines for Diagnostics, by offering guidance and saying what the actual possible problem is, instead of only pointing to the problematic message. This of course requires a bit more code than the current linter. I have checked that my rewrite preserves all existing features of the linter. I don't think adding new features to the current architecture of the linter makes sense since it requires more work than absolutely necessary. To add a new linter check, it shouldn't be necessary to modify any .po file format parser. Therefore I think replacing the current linter with the latest suggested code from bug 90176 actually makes sense.
[Bug translation/90176] diagnostics should generally contain underscore only inside quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176 Roland Illig changed: What|Removed |Added Attachment #46212|0 |1 is obsolete|| --- Comment #4 from Roland Illig --- Created attachment 46234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46234=edit linter uses polib and checks for several new inconsistencies
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #7 from Eric Gallager ---
(In reply to Jonny Grant from comment #6)
> Wondering if it is also worth the message making clear the type was promoted?
>
> eg:
>
> :5:14: warning: format '%d' expects argument of type 'int', but
> argument 2 has type 'float' automatically promoted to 'double', for which
> '%f' is required [-Wformat=]
>
> 5 | printf("%d", i);
> | ~^ ~
> | | |
> | int float
> | %f
Maybe, but the message would be getting pretty long by that point...
[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Iain Buclaw --- It ended up being a little more work, as the proposed patch had a bug in it. But it's now done in r270514.
[Bug c++/68092] [C++1z] error: Two symbols with same comdat_group are not linked by the same_comdat_group list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68092
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment #7 from S. Davis Herring ---
Created attachment 46233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46233=edit
ICE output from variable template test
This simple test case produces a similar ICE (with current trunk at Compiler
Explorer):
int i;
template extern const int v=i++;
void f();
const int j=v;
int g() {
void f();
return v;
}
Making v have internal linkage makes it go away. If this should be a separate
bug, please let me know.
[Bug translation/90119] Merge translation msgids that only differ in placeholders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119 --- Comment #6 from Roland Illig --- (In reply to Martin Liška from comment #5) > Thank you Roland for working on that. Can you please integrate your script > with: > contrib/check-internal-format-escaping.py No, I cannot. Integrating it doesn't make sense. In bug 90176 I posted the most recent version of my work. Reading the gcc.pot file line by line doesn't make sense anymore, since that prevents the more interesting linter checks (such as the one checking for structurally equivalent msgids) from working. I converted the existing program to using polib exactly for the purpose of having more advanced checks than are possible with the current code base. To the best of my knowledge I have preserved all current linter checks.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #59 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #58) > If we don't want to go with #c35 at least for GCC 9, would the #c44 patch be > still useful without it (does it ever trigger say on the kernel where it > didn't trigger before)? The patch in comment 44 is obviously good, it improves the size by 0.090% as noted (this is a kernel build, multi_v5_defconfig iirc). I'd say it is perfectly safe for GCC 9, but I'm not an Arm maintainer :-)
[Bug c++/86044] noexcept(false) of constexpr member function ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86044 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Resolved by my r270320.
[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 --- Comment #6 from Alexandre Oliva --- What's confusing to me is that, as far as I know, GDB pays no attention to is_stmt yet. So I think we should focus on what, if any, changes to the line number program are brought about by enabling or disabling the SFN option. That said, markers at increments and conditions, besides loop headers, is definitely something we should have. I'm more than surprised they aren't there.
[Bug c++/86044] noexcept(false) of constexpr member function ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86044 Casey Carter changed: What|Removed |Added CC||Casey at Carter dot net --- Comment #1 from Casey Carter --- In C++14, this is conforming behavior per N4140 [expr.unary.noexcept]/3: """ 3. The result of the noexcept operator is false if in a potentially-evaluated context the expression would contain 3.1 - a potentially-evaluated call to a function, member function, function pointer, or member function pointer that does not have a non-throwing exception-specification, unless the call is a constant expression, [...] """ In C++17 and later, it is not conforming per [expr.unary.noexcept]/3: """ 3 The result of the noexcept operator is true unless the expression is potentially-throwing ([except.spec]). "" and [except.spec]/6 which defines "potentially-throwing" and includes no mention of constant expressions (I won't duplicate the full text here).
[Bug c++/90215] ICE with lambda in fold expression over comma and assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code, ||needs-reduction Target Milestone|--- |8.4 --- Comment #2 from Marek Polacek --- The ICE started with r251433. Before: 90215.C: In lambda function: 90215.C:22:20: error: parameter packs not expanded with ‘...’: 90215.C:22:20: note: ‘__ys’
[Bug c++/90215] ICE with lambda in fold expression over comma and assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-23 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/90215] New: ICE with lambda in fold expression over comma and assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215
Bug ID: 90215
Summary: ICE with lambda in fold expression over comma and
assignment
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
The following code
#include
template
struct X
{
template
void f(F f)
{
f(0);
}
};
template
void bug(X... xs)
{
std::tuple t;
std::apply([&](auto&... ys)
{
(xs.f([&](auto y)
{
ys = y;
}), ...);
}, t);
}
int main()
{
bug(X{});
}
produces an ICE with g++ trunk (version 9.0.1 20190422):
:22:16: internal compiler error: in tsubst_copy, at cp/pt.c:15551
22 | ys = y;
| ~~~^~~
The bug can be reproduced on godbolt.org here:
https://gcc.godbolt.org/z/NNLI5p
[Bug rtl-optimization/90209] codegen regression (x < 0 ? -x : x) results in branch instead of single instruction on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90209 Vegard Nossum changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Vegard Nossum --- x < 0 will be false for x == -0. and therefore the return value will be -0., which it won't be with just the "andpd". Closing as invalid
[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197
--- Comment #5 from Jakub Jelinek ---
__attribute__((noipa))
void
test (unsigned int *dst, unsigned int base, int count)
{
int i = 0;
while (i < count)
dst[i++] = (base += 15);
}
int
main (void)
{
unsigned int dst[100];
test (dst, 0x4000, 100);
}
and
__attribute__((noipa))
void
test (unsigned int *dst, unsigned int base, int count)
{
int i = 0;
do
dst[i++] = (base += 15);
while (i < count);
}
int
main (void)
{
unsigned int dst[100];
test (dst, 0x4000, 100);
}
show that too. For the do while loop, not sure if we shouldn't have something
also one recommended location at the start of the do/while loop on do line,
then of course in the body and then on the while condition. For while loop at
the start of the condition. Also, in C++ we have range-for loops that need
some thinking too.
[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 --- Comment #4 from Jakub Jelinek --- For the for loop, we emit a DEBUG_BEGIN_STMT, which maps to DWARF: is_stmt 'A boolean indicating that the current instruction is a recommended breakpoint location. A recommended breakpoint location is intended to “represent” a line, a statement and/or a semantically distinct subpart of a statement.' I would think that for a C/C++ normal for loop we should emit a recommanded breakpoint location not just at the start of the whole statement (== at the start of the init expression), but also at the start of the increment expression and maybe also at the start of the condition (though not sure about that, perhaps it is enough to have just one on the increment expression and cover the condition through the recommended breakpoint location at the start of the whole for loop and before the increment expression. Wonder about other loop constructs too.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #58 from Jakub Jelinek --- If we don't want to go with #c35 at least for GCC 9, would the #c44 patch be still useful without it (does it ever trigger say on the kernel where it didn't trigger before)?
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205
--- Comment #6 from Jonny Grant ---
Wondering if it is also worth the message making clear the type was promoted?
eg:
:5:14: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'float' automatically promoted to 'double', for which '%f'
is required [-Wformat=]
5 | printf("%d", i);
| ~^ ~
| | |
| int float
| %f
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #57 from Jeffrey A. Law --- So what's actually left to do with this BZ? ie, what tests are still regressing?
[Bug c++/90212] [8/9 Regression] by-ref capture of constexpr class object rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-23 CC||jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 kelvin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from kelvin at gcc dot gnu.org --- Patch has been committed to trunk and backported to gcc8 and gcc7.
[Bug tree-optimization/90078] [7/8 Regression] ICE with deep templates caused by overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] ICE with |[7/8 Regression] ICE with |deep templates caused by|deep templates caused by |overflow [PATCH]|overflow Known to fail|9.0 | --- Comment #10 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- This changed with r255569. Using -gno-statement-frontiers helps here even with recent-ish trunk.
[Bug inline-asm/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #7 from Segher Boessenkool --- (In reply to nfxjfg from comment #6) > Yes, it's clear that that the constraint can't be _just_ the register name, > since they'll clash with builtin constraints now or with future > architectures (which may add arbitrary register names). The proposed > "*registername" is pretty nice, though. Having this would be great. Hrm, "*" already has a meaning with current GCC (it essentially is ignored in inline asm)... It might be better to have some new syntax that gives an error with older GCC. > I didn't find a RISC-V builtin for ecall (maybe I looked in the wrong > place). That wouldbn't be sufficient anyway. Right, you would need a builtin for every calling convention for syscalls. The aren't too many of those though? > Another situation where I > wanted to specify many fixed register constraints was a piece of inline code > that did some syscalls without touching the stack (it needed all inputs as > registers, and in specific registers, and have some registers for free use > by the asm code itself). A biggish piece of asm like that might be better as actual assembler code than as inline asm, you may want to consider that?
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-23 CC||hjl.tools at gmail dot com, ||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org Component|c |target Target Milestone|--- |8.4 Summary|[8 Regression] C code is|[8/9 Regression] C code is |optimized worse than C++|optimized worse than C++ Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r257505. A smaller regression happened already earlier with r254855. Before the latter, we emitted: pushq %rbp movq%rdi, %rax movq%rsp, %rbp andq$-64, %rsp vmovdqu32 16(%rbp), %zmm1 vpaddd 80(%rbp), %zmm1, %zmm0 vmovdqa64 %zmm0, -64(%rsp) vmovdqa64 -64(%rsp), %xmm2 vmovdqa64 -48(%rsp), %xmm3 vmovdqa64 -32(%rsp), %xmm4 vmovdqa64 -16(%rsp), %xmm5 vmovups %xmm2, (%rdi) vmovups %xmm3, 16(%rdi) vmovups %xmm4, 32(%rdi) vmovups %xmm5, 48(%rdi) vzeroupper leave ret r254855 then changed it into: pushq %rbp movq%rsp, %rbp andq$-32, %rsp movq%rdi, %rax vmovdqu32 16(%rbp), %ymm2 vpaddd 80(%rbp), %ymm2, %ymm0 vmovq %xmm0, %rdx vmovdqa64 %ymm0, -64(%rsp) vmovdqu32 48(%rbp), %ymm3 vpaddd 112(%rbp), %ymm3, %ymm0 vmovdqa64 %ymm0, -32(%rsp) movq%rdx, (%rdi) movq-56(%rsp), %rdx movq%rdx, 8(%rdi) movq-48(%rsp), %rdx movq%rdx, 16(%rdi) movq-40(%rsp), %rdx movq%rdx, 24(%rdi) vmovq %xmm0, 32(%rax) movq-24(%rsp), %rdx movq%rdx, 40(%rdi) movq-16(%rsp), %rdx movq%rdx, 48(%rdi) movq-8(%rsp), %rdx movq%rdx, 56(%rdi) vzeroupper leave ret After the r257505 we seem to be versioning for alignment or so, that can't be right for a loop with just 16 iterations.
[Bug c++/90212] [8/9 Regression] by-ref capture of constexpr class object rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.4
[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90172 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90172
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
So, I guess the rejects-valid part is a P2 8/9 regression (if the testcase is
really valid) and the ICE is error recovery regression for that (9 only).
For the latter, I guess something like:
--- gcc/cp/pt.c.jj 2019-04-22 16:03:23.0 +0200
+++ gcc/cp/pt.c 2019-04-23 17:21:01.898950417 +0200
@@ -18869,7 +18869,8 @@ tsubst_copy_and_build (tree t,
/* We aren't going to do normal overload resolution, so force the
template-id to resolve. */
function = resolve_nondeduced_context (function, complain);
- for (unsigned i = 0; i < nargs; ++i)
+ unsigned int n_call_args = call_args->length ();
+ for (unsigned i = 0; i < n_call_args; ++i)
{
/* In a thunk, pass through args directly, without any
conversions. */
@@ -18881,9 +18882,10 @@ tsubst_copy_and_build (tree t,
if (thisarg)
{
/* Shift the other args over to make room. */
- vec_safe_push (call_args, (*call_args)[nargs-1]);
- for (int i = nargs-1; i > 0; --i)
- (*call_args)[i] = (*call_args)[i-1];
+ tree last_arg = (*call_args)[n_call_args - 1];
+ vec_safe_push (call_args, last_arg);
+ for (int i = n_call_args - 1; i > 0; --i)
+ (*call_args)[i] = (*call_args)[i - 1];
(*call_args)[0] = thisarg;
}
ret = build_call_a (function, call_args->length (),
could do the job, nargs doesn't take into account if there are more arguments
in call_args due to some pack expansion and also the vec_safe_push is broken
because (*call_args)[nargs-1] is just a reference and trying to push it if it
needs to reallocate is broken.
I have no idea if n_call_args could be 0 and thisarg non-NULL, if yes, we need
to just vec_safe_push (call_args, thisarg); in that case instead of moving
anything.
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 --- Comment #4 from Avi Kivity --- Since constexpr constructors do send the variable into the .data (or .tls) section, perhaps gcc can attempt to evaluate the initializer as if it (and any functions it calls) was marked constexpr. If it fails it can emit the guard and initialization calls, but if it succeeds, we save some runtime to check those guards.
[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079 --- Comment #5 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Tue Apr 23 15:19:55 2019 New Revision: 270514 URL: https://gcc.gnu.org/viewcvs?rev=270514=gcc=rev Log: PR d/90079 libphobos: Fix SEGV in _aaKeys, _aaValues on 32-bit SPARC Merges upstream druntime b43203a1 Reviewed-on: https://github.com/dlang/druntime/pull/2572 Modified: trunk/libphobos/libdruntime/MERGE trunk/libphobos/libdruntime/object.d
[Bug d/90130] gdc.test/runnable/test12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- I think it should be done in r270485.
[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90172
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
This used to be accepted before r251433, which started rejecting it.
Before r257018, the diagnostics has been:
pr90172.C: In instantiation of ‘fooV(Ts ...) [with Ts = {const char*, int,
double, char, float, short int, unsigned int}]:: [with
auto:1 = {fooV(Ts ...) [with Ts = {const char*, int, double, char, float, short
int, unsigned int}]::, const char*, int, double, char,
float, short int, unsigned int}]’:
pr90172.C:8:13: required from ‘int fooV(Ts ...) [with Ts = {const char*, int,
double, char, float, short int, unsigned int}]’
pr90172.C:13:65: required from here
pr90172.C:3:10: error: use ‘...’ to expand argument pack
auto M = [](decltype(a) ... b) -> void {
^
pr90172.C:5:12: error: unable to deduce lambda return type from ‘M’
return M;
^
but in r257018 and onwards:
pr90172.C: In instantiation of ‘int fooV(Ts ...) [with Ts = {const char*, int,
double, char, float, short int, unsigned int}]’:
pr90172.C:13:65: required from here
pr90172.C:3:10: error: expansion pattern ‘decltype (#‘nontype_argument_pack’
not supported by dump_expr#)’ contains no argument packs
auto M = [](decltype(a) ... b) -> void {
^
and finally starting with r268377 we also ICE during error recovery.
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 --- Comment #4 from Richard Earnshaw --- (In reply to Ramana Radhakrishnan from comment #3) > Seems to have been "fixed" by the commit to fix PR87369, > > Richard, is this something to backport ? Prima-facie , it appears not and we > will need an appropriate fix for the release branches. Given that the patch for PR87369 eliminates the ICE, it's probably preferable for backporting to a separate patch that is only used on the release branches. That patch has now been soaking on trunk for a while now, so is likely to be pretty safe. I am a bit worried however, that the patch papers over a likely trunk ICE that isn't really fixed. It would be nice to investigate further if some additional mitigation is warranted.
[Bug middle-end/90191] [9 regression] incorrect -Wformat-overflow with --param max-jump-thread-duplication-stmts=17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90191 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- This particular warning is a late warning during optimizations, and as such has the issues other late warnings have, various false positives, sometimes more, sometimes less depending on how much jump threading is done; in some cases more jump threading causes more false positives, in other cases fewer.
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||dmalcolm at gcc dot gnu.org
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #5 from Jakub Jelinek ---
I've been thinking about something like:
--- gcc/c/c-format.c.jj 2019-02-26 00:43:18.0 +0100
+++ gcc/c/c-format.c2019-04-23 16:44:54.552064471 +0200
@@ -1060,7 +1060,7 @@ static void check_format_types (const su
vec *arglocs);
static void format_type_warning (const substring_loc _loc,
location_t param_loc,
-format_wanted_type *, tree,
+format_wanted_type *, tree, tree,
tree,
const format_kind_info *fki,
int offset_to_type_start,
@@ -3109,7 +3109,7 @@ check_format_types (const substring_loc
if (!cur_param)
{
format_type_warning (fmt_loc, UNKNOWN_LOCATION, types, wanted_type,
- NULL, fki, offset_to_type_start,
+ NULL, NULL, fki, offset_to_type_start,
conversion_char);
continue;
}
@@ -3197,8 +3197,8 @@ check_format_types (const substring_loc
}
else
{
- format_type_warning (fmt_loc, param_loc,
- types, wanted_type, orig_cur_type, fki,
+ format_type_warning (fmt_loc, param_loc, types, wanted_type,
+ orig_cur_type, NULL, fki,
offset_to_type_start, conversion_char);
break;
}
@@ -3268,7 +3268,7 @@ check_format_types (const substring_loc
continue;
/* Now we have a type mismatch. */
format_type_warning (fmt_loc, param_loc, types,
- wanted_type, orig_cur_type, fki,
+ wanted_type, orig_cur_type, cur_param, fki,
offset_to_type_start, conversion_char);
}
}
@@ -3339,7 +3339,7 @@ test_get_modifier_for_format_len ()
Wformat type errors where the argument has type ARG_TYPE. */
static bool
-matching_type_p (tree spec_type, tree arg_type)
+matching_type_p (tree spec_type, tree arg_type, tree cur_param)
{
gcc_assert (spec_type);
gcc_assert (arg_type);
@@ -3353,14 +3353,29 @@ matching_type_p (tree spec_type, tree ar
spec_type = TYPE_CANONICAL (spec_type);
arg_type = TYPE_CANONICAL (arg_type);
+ if (spec_type == arg_type)
+return true;
+
if (TREE_CODE (spec_type) == INTEGER_TYPE
&& TREE_CODE (arg_type) == INTEGER_TYPE
&& (TYPE_UNSIGNED (spec_type)
? spec_type == c_common_unsigned_type (arg_type)
: spec_type == c_common_signed_type (arg_type)))
-return true;
+{
+ if (!warn_format_signedness)
+ return true;
+ if (TYPE_UNSIGNED (spec_type)
+ && cur_param != NULL_TREE
+ && TREE_CODE (cur_param) == NOP_EXPR)
+ {
+ tree t = TREE_TYPE (TREE_OPERAND (cur_param, 0));
+ if (TYPE_UNSIGNED (t)
+ && spec_type == lang_hooks.types.type_promotes_to (t))
+ return true;
+ }
+}
- return spec_type == arg_type;
+ return false;
}
/* Subroutine of get_format_for_type.
@@ -3380,7 +3395,7 @@ matching_type_p (tree spec_type, tree ar
static char *
get_format_for_type_1 (const format_kind_info *fki, tree arg_type,
- char conversion_char)
+ tree cur_param, char conversion_char)
{
gcc_assert (arg_type);
@@ -3402,7 +3417,7 @@ get_format_for_type_1 (const format_kind
const format_type_detail *ftd = >types[i];
if (!ftd->type)
continue;
- if (matching_type_p (*ftd->type, effective_arg_type))
+ if (matching_type_p (*ftd->type, effective_arg_type, cur_param))
{
const char *len_modifier
= get_modifier_for_format_len (fki->length_char_specs,
@@ -3439,7 +3454,7 @@ get_format_for_type_1 (const format_kind
static char *
get_format_for_type (const format_kind_info *fki, tree arg_type,
-char conversion_char)
+tree cur_param, char conversion_char)
{
gcc_assert (arg_type);
gcc_assert (conversion_char);
@@ -3447,13 +3462,14 @@ get_format_for_type (const format_kind_i
/* First pass: look for a format_char_info containing CONVERSION_CHAR
If we find one, then presumably the length modifier was incorrect
(or absent). */
- char *result = get_format_for_type_1 (fki, arg_type, conversion_char);
+ char
[Bug c/90167] invalid example in GCC documentation wrt. effective type rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90167
--- Comment #3 from Segher Boessenkool ---
But you are not accessing as the union type. You do the access with the
type of one of its members. And that is UB.
The part of the standard you quote is about things like
union a_union f(double *p) { return *(union a_union *)p; }
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 Ramana Radhakrishnan changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan --- Seems to have been "fixed" by the commit to fix PR87369, Richard, is this something to backport ? Prima-facie , it appears not and we will need an appropriate fix for the release branches.
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |ASSIGNED CC||ramana at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot gnu.org --- Comment #2 from Ramana Radhakrishnan --- I'll take a look.
[Bug d/88238] libphobos compile problems on Solaris 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> (In reply to Rainer Orth from comment #0)
[...]
>> *
>>
>> symbol not found: dl_iterate_phdr
>> (libdruntime/.libs/libgdruntime.so)
>>
>> Unlike Solaris 11, dl_iterate_phdr support was only backported to a late
>> Solaris 10 update and even so only lives in libdl, not in libc. Not yet
>> fixed.
>>
>
> So does dlopen and dl_iterate_phdr live in separate libraries? I would have
In Solaris 10, dlopen lives in libc, but is just a filter on ld.so.1
(the runtime linker), while dl_iterate_phdr only exists in libdl.so.1.
In Solaris 11, OTOH, both exist in libc as filter on ld.so.1.
> thought that DRUNTIME_LIBRARIES_DLOPEN would correctly add -ldl to the driver
> spec file.
Since no separate library is needed for dlopen, -ldl isn't added to $LIBS.
This could certainly be fixed by augmenting the autoconf test.
>> *
>>
>> symbol not found: getprogname
>> (libdruntime/.libs/libgdruntime.so)
>>
>> Solaris 10 lacks getprogname or equivalent; for now I'm faking this by just
>> returning "a.out".
>>
>
> There's the following function in rt/dmain2.d
>
> extern (C) string[] rt_args();
>
> Would the basename() of argv[0] be a suitable fallback? Looking at illumos,
Sure. As an initial hack, I even used a hardcoded "a.out".
> they use dlinfo(RTLD_SELF, RTLD_DI_ARGSINFO) and strrchr(argv0, '/').
True, and that dlinfo request already exists in Solaris 10.
>> *
>> symbol not found: posix_memalign
>> (src/.libs/libgphobos.so)
>>
>> Also missing from Solaris 10. I've not yet checked what to do here. One
>> might be able to use pagealign_alloc from gnulib instead?
>
> If the OS version can be obtained from the compiler, same as FBSD_MAJOR, then
Right now, it can't. However, the Studio compilers predefine
__SunOS_RELEASE, and gcc could be changed to mimic that. Of course, the
test could always be made in configure one way or the other and the
outcome used in libdruntime, similarly to OS_Have_Dlpi_Tls_Modid.
> one option would be to provide posix_memalign internally in druntime.
>
> extern(D) int posix_memalign(void** ptr, size_t alignment, size_t size)
> {
> // ...
> }
>
> extern(D) so that it won't conflict with extern(C) function of the same name.
>
> Though whether it is worth the effort, I'm not so sure. As you've said that
> Solaris10 will be removed before.
Exactly: I've had a look at the open issues on Solaris 10. The ones
above can certainly be worked around or avoided some way or another, but
there's a showstopper, I believe: the 64-bit x86 problem worked around
by ld -z relax=transtls also exists on Solaris 10, but the workaround
does not. This means that we're either left with a 32-bit-only Solaris
10/x86 port or one that is only usable with gld. While Solaris 10/SPARC
wouldn't be affected, SPARC is in considerably worse shape right now,
and I'm pretty certain our time would be far better spent fixing Solaris
11 issues: this will benefit way more users. I doubt there are many
considering upgrading to gcc 9 on Solaris 10, let alone trying a new
language.
My suggestion would be to close the PR as WONTFIX. Should there really
be demand, one could still apply Solaris 10 fixes to the GCC 9 branch
after the 9.1.0 release: there's considerable leeway for changes like
this and a new language.
[Bug rtl-optimization/87979] ICE in compute_split_row at modulo-sched.c:2393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87979 Roman Zhuykov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Roman Zhuykov --- Fixed.
[Bug rtl-optimization/87979] ICE in compute_split_row at modulo-sched.c:2393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87979 --- Comment #3 from Roman Zhuykov --- Author: zhroma Date: Tue Apr 23 13:14:57 2019 New Revision: 270512 URL: https://gcc.gnu.org/viewcvs?rev=270512=gcc=rev Log: modulo-sched: prevent division by zero (PR87979) PR rtl-optimization/87979 * modulo-sched.c (sms_schedule): Start ii value "mii" should not equal zero. testsuite: PR rtl-optimization/87979 * gcc.dg/pr87979.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr87979.c Modified: trunk/gcc/ChangeLog trunk/gcc/modulo-sched.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84032 Roman Zhuykov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |zhroma at gcc dot gnu.org --- Comment #6 from Roman Zhuykov --- Fixed.
[Bug tree-optimization/90208] [7/8/9 Regression] error: EH landing pad label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90208 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|sanitizer |tree-optimization Ever confirmed|0 |1
[Bug tree-optimization/90208] [7/8/9 Regression] error: EH landing pad label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90208 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 46232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46232=edit gcc9-pr90208.patch Untested fix.
[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84032 --- Comment #5 from Roman Zhuykov --- Author: zhroma Date: Tue Apr 23 12:53:43 2019 New Revision: 270511 URL: https://gcc.gnu.org/viewcvs?rev=270511=gcc=rev Log: modulo-sched: fix branch scheduling issue (PR84032) PR rtl-optimization/84032 * modulo-sched.c (ps_insn_find_column): Change condition so that branch will always be the last insn in a row inside partial schedule. testsuite: PR rtl-optimization/84032 * gcc.dg/pr84032.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr84032.c Modified: trunk/gcc/ChangeLog trunk/gcc/modulo-sched.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 --- Comment #17 from Martin Liška --- > Could you open separate PRs for the new tests? We could perhaps > have a meta-bug for ubsan failures too, if we don't already. I did so: PR90213 and PR90214.
[Bug libstdc++/90165] std::variant constructs wrong alternative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90165 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Known to work||9.0 Target Milestone|--- |8.4 Known to fail||8.3.0 --- Comment #4 from Jonathan Wakely --- Fixed on trunk so far.
[Bug rtl-optimization/90214] New: UBSAN: signed integer overflow: 162675373468811328 - -9060696663385964544 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90214
Bug ID: 90214
Summary: UBSAN: signed integer overflow: 162675373468811328 -
-9060696663385964544 cannot be represented in type
'long int'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Following fails:
$ cat ubsan2.c
long b[1][9];
typedef long V __attribute__((vector_size (16), may_alias));
void
foo ()
{
V *c = (V *) ((char *) b + -9060696663385964544);
*c = (V) { 1, 1 };
long __attribute__((may_alias)) *d = (long *) ((char *) b +
162675373468811328);
*d = 1;
}
$ ~/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/xgcc -B
~/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/ ubsan2.c -c -O
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/poly-int.h:944:5:
runtime error: signed integer overflow: 162675373468811328 -
-9060696663385964544 cannot be represented in type 'long int'
#0 0x4335e62 in poly_int<1u, poly_result::result_kind>::type> operator-<1u, long,
long>(poly_int_pod<1u, long> const&, poly_int_pod<1u, long> const&)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/poly-int.h:944
#1 0x4335e62 in record_store
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:1573
#2 0x43393d2 in scan_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:2568
#3 0x43393d2 in dse_step1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:2680
#4 0x43393d2 in rest_of_handle_dse
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:3597
#5 0x43393d2 in execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/dse.c:3655
#6 0x1c6d018 in execute_one_pass(opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2487
#7 0x1c70921 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2573
#8 0x1c70964 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2574
#9 0x1c70a18 in execute_pass_list(function*, opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2584
#10 0xdb211d in cgraph_node::expand()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2198
#11 0xdb64ab in expand_all_functions
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2336
#12 0xdb64ab in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2687
#13 0xdc0d5b in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2599
#14 0xdc0d5b in symbol_table::finalize_compilation_unit()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2865
#15 0x2148fc4 in compile_file
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:481
#16 0x7bf43a in do_compile
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:2205
#17 0x7bf43a in toplev::main(int, char**)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:2340
#18 0x83062e in main
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/main.c:39
#19 0x77976b7a in __libc_start_main ../csu/libc-start.c:308
#20 0x834749 in _start
(/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/cc1+0x834749)
[Bug libstdc++/90165] std::variant constructs wrong alternative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90165 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Tue Apr 23 12:48:18 2019 New Revision: 270509 URL: https://gcc.gnu.org/viewcvs?rev=270509=gcc=rev Log: PR libstdc++/90165 constrain variant(T&&) constructor Also refactor some constraints slightly to be more readable. PR libstdc++/90165 * include/std/variant (variant::__not_self): New helper for the is_same_v, variant>==false constraints. (variant::__to_type_impl): Remove. (variant::__to_type): Add default argument to check pack size, instead of using __to_type_impl. (variant::__accepted_type): Add default argument using __not_self. (variant::__is_in_place_tag, variant::__not_in_place_tag): New helpers for variant(T&&) constructor constraint. (variant::variant(T&&)): Use __not_in_place_tag in constraints. Extract __accepted_type into a named template parameter for reuse in other constraints and in the exception specification. (variant::variant(in_place_type_t, Args&&...)) (variant::variant(in_place_type_t, initializer_list, Args&&...)) (variant::variant(in_place_index_t, Args&&...)) (variant::variant(in_place_index_t, initializer_list, Args&&...)) (variant::operator=T&&)): Remove redundant && from trait arguments. * testsuite/20_util/variant/compile.cc: Check variant(T&&) constructor isn't used for in_place_type or in_place_index arguments. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/variant trunk/libstdc++-v3/testsuite/20_util/variant/compile.cc
[Bug tree-optimization/90213] New: UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213
Bug ID: 90213
Summary: UBSAN: signed integer overflow: -5621332293356458048 *
8 cannot be represented in type 'long int'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Fails for:
$ cat ubsan.c
int a[4];
void f()
{
long int b = 7818038963515661296;
a[0xA699ECD2C348A3A0] = a[b];
}
$ ~/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/xgcc -B
~/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/ ubsan.c -c -O
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/poly-int.h:753:21:
runtime error: signed integer overflow: -5621332293356458048 * 8 cannot be
represented in type 'long int'
#0 0x139a5ef in if_nonpoly,
poly_int_traits::is_poly>::type& poly_int<1u, long>::operator*=(int
const&)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/poly-int.h:753
#1 0x139a5ef in fold_const_aggregate_ref_1(tree_node*, tree_node*
(*)(tree_node*))
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/gimple-fold.c:6992
#2 0x139bfd0 in gimple_fold_stmt_to_constant_1(gimple*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/gimple-fold.c:6426
#3 0x25df8ec in ccp_fold
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:1257
#4 0x25df8ec in evaluate_stmt
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:1785
#5 0x25e449c in visit_assignment
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:2355
#6 0x284805d in ssa_propagation_engine::simulate_stmt(gimple*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-propagate.c:230
#7 0x284900c in ssa_propagation_engine::simulate_block(basic_block_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-propagate.c:337
#8 0x284ddc1 in ssa_propagation_engine::ssa_propagate()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-propagate.c:802
#9 0x25c726f in do_ssa_ccp
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:2474
#10 0x25c726f in execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/tree-ssa-ccp.c:2518
#11 0x1c6d018 in execute_one_pass(opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2487
#12 0x1c70921 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2573
#13 0x1c70964 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2574
#14 0x1c70a18 in execute_pass_list(function*, opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2584
#15 0x1c67cd6 in do_per_function_toporder(void (*)(function*, void*),
void*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:1705
#16 0x1c72d7d in execute_ipa_pass_list(opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/passes.c:2932
#17 0xdb75c8 in ipa_passes
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2484
#18 0xdb75c8 in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2620
#19 0xdc0d5b in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2599
#20 0xdc0d5b in symbol_table::finalize_compilation_unit()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/cgraphunit.c:2865
#21 0x2148fc4 in compile_file
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:481
#22 0x7bf43a in do_compile
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:2205
#23 0x7bf43a in toplev::main(int, char**)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/toplev.c:2340
#24 0x83062e in main
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/main.c:39
#25 0x77976b7a in __libc_start_main ../csu/libc-start.c:308
#26 0x834749 in _start
(/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/objdir/gcc/cc1+0x834749)
[Bug middle-end/90139] [7/8 Regression] ICE in emit_block_move_hints, at expr.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Jakub Jelinek --- > That is a 7/8 regression though then. Or do you have a testcase that still > fails on the trunk? No: it seems the original testcase produces the same ICE in different places on gcc 7, 8, and 9. I'm not certain about the regression part, TBH: when I tried the original (preprocessed) testcase with gcc [876].1.0, it ICEd on all of them, but it wouldn't even compile on gcc 5.1.0. So I don't have a gcc release where it worked.
[Bug libstdc++/90165] std::variant constructs wrong alternative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90165 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > because we talk to apply this constraint: s/talk/fail/
[Bug c/90167] invalid example in GCC documentation wrt. effective type rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90167
--- Comment #2 from Laszlo Ersek (RH) ---
(In reply to Segher Boessenkool from comment #1)
> The code accesses d, of type double, as an int. That is not a
> compatible type.
Agreed; I didn't claim it was.
> It does not matter how it got there, what pointer casts trickery with
> unions it did.
I disagree, and in my opinion, the standard disagrees too.
> You can access a union type as the type of any of its members. But a
> double is not a union type.
I didn't claim it was.
The standard writes,
An object [the double] shall have its stored value accessed only by
an lvalue expression that has one of the following types:
[...]
- a [...] union type that includes [a type compatible with the
effective type of the [double] object] among its members
It says we can access a "double" through a union which has a "double"
member.
union u {
int i;
double d1;
};
double d2;
The expression (*(union u *)) is an lvalue expression that has a
union type that includes a double among its members.
To me this seems to follow from the letter of the standard. If my
interpretation is incorrect, or the standard is unclear or incorrect,
please show that. Thanks.
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 --- Comment #16 from Vittorio Zecca --- On Saturday afternoon I had a power failure that probably damaged my disk, so I cannot help you now.
[Bug middle-end/90139] [7/8 Regression] ICE in emit_block_move_hints, at expr.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139 Jakub Jelinek changed: What|Removed |Added Summary|[9 Regression] ICE in |[7/8 Regression] ICE in |emit_block_move_hints, at |emit_block_move_hints, at |expr.c:1601 |expr.c:1601 --- Comment #10 from Jakub Jelinek --- That is a 7/8 regression though then. Or do you have a testcase that still fails on the trunk?
[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Rainer Orth --- Reopening as explained in Comment 7.
[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139 --- Comment #8 from Rainer Orth --- Created attachment 46231 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46231=edit gcc 8 reduced testcase
[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139 --- Comment #7 from Rainer Orth --- While my original testcase fails on gcc 7, 8, and 9, the one reduced using gcc 9 only failed on trunk. I've now ran creduce with the original testcase against both gcc 7 and 8. Each run produced a different reduced testcase, neither of which is fixed by applying the trunk patch to the branches.
[Bug middle-end/90139] [9 Regression] ICE in emit_block_move_hints, at expr.c:1601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139 --- Comment #6 from Rainer Orth --- Created attachment 46230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46230=edit gcc 7 reduced testcase
[Bug tree-optimization/90211] [8/9 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90211 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-23 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 46229 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46229=edit gcc9-pr90211.patch Untested fix.
[Bug middle-end/90191] [9 regression] -Wformat-overflow depends on --param max-jump-thread-duplication-stmts=17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90191 --- Comment #2 from Dmitry G. Dyachenko --- (In reply to Richard Biener from comment #1) > So is the warning good or bad? That it now depends on the param suggests a > change in default optimization behavior. Sorry not to be clear Warning with --param ... is incorrect. And creduced testcase has "dead" code: "if(0) goto ...;" May be some pass (jump-threading?) cant simplify it? If so then smth like 90037 probably will be the root PR
[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 --- Comment #2 from Richard Biener --- Just to say I used gdb 8.2 for my investigation.
[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Version|unknown |8.3.1
Keywords||wrong-debug
Last reconfirmed||2019-04-23
CC||aoliva at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Target Milestone|--- |8.4
--- Comment #1 from Richard Biener ---
Confirmed. The issue is that the line number program only contains line number
6
and the consumer (gdb) doesn't handle a jump in a stmt sequence as "ending"
a line, thus 'next' advances to after the loop. We expand from
[local count: 118111600]:
[t.c:5:3] # DEBUG BEGIN_STMT
[t.c:5:8] # DEBUG BEGIN_STMT
[t.c:5:12] # DEBUG i => 0
# DEBUG i => 0
# DEBUG base => base_7(D)
[t.c:5:3] if (count_9(D) > 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 105119324]:
ivtmp.10_4 = (unsigned long) dst_10(D);
_14 = (unsigned int) count_9(D);
_15 = _14 * 15;
_21 = base_7(D) + _15;
[local count: 955630224]:
# base_17 = PHI
# ivtmp.10_6 = PHI
# DEBUG i => NULL
# DEBUG base => base_17
[t.c:6:5] # DEBUG BEGIN_STMT
_16 = (void *) ivtmp.10_6;
[t.c:6:12] MEM[base: _16, offset: 0B] = base_17;
[t.c:5:30] # DEBUG i => D#1
[t.c:5:40] base_13 = base_17 + 15;
[t.c:5:40] # DEBUG base => base_13
# DEBUG i => D#1
# DEBUG base => base_13
ivtmp.10_5 = ivtmp.10_6 + 4;
[t.c:5:3] if (base_13 != _21)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111601]:
[t.c:7:1] return;
notice how the only stmt marker inside the loop body is for t.c:6.
gimplification shows
test (unsigned int * dst, unsigned int base, int count)
[t.c:4:1] {
[t.c:5:3] # DEBUG BEGIN_STMT
[t.c:5:3] {
int i;
[t.c:5:8] # DEBUG BEGIN_STMT
[t.c:5:12] i = 0;
[t.c:5:3] goto ;
:
[t.c:6:5] # DEBUG BEGIN_STMT
[t.c:6:8] _1 = (long unsigned int) i;
[t.c:6:8] _2 = _1 * 4;
[t.c:6:8] _3 = dst + _2;
[t.c:6:12] [t.c:6:8] *_3 = base;
[t.c:5:30] i = i + 1;
[t.c:5:40] base = base + 15;
:
[t.c:5:3] if (i < count) goto ; else goto ;
:
so the debug begin_stmt for the loop is attached before the IV
initialization. Not sure if that has consequences.
The testcase behaves as expected with -gno-statement-frontiers
Alex?
[Bug c++/90212] New: [8/9 Regression] by-ref capture of constexpr class object rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212
Bug ID: 90212
Summary: [8/9 Regression] by-ref capture of constexpr class
object rejected
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Target Milestone: ---
template struct tuple {
constexpr tuple(T&& t) : t(t) { }
int t;
};
void foo() {
constexpr tuple v1{1};
constexpr auto v2 = v1;
[&]{ constexpr auto v2 = v1; };
}
Since r256842 GCC 8 and trunk reject this:
a.cc: In lambda function:
a.cc:9:30: error: lambda capture of ‘v1’ is not a constant expression
[&]{ constexpr auto v2 = v1; };
^~
Clang and icc accept it, and I think it's valid.
[Bug middle-end/90191] [9 regression] -Wformat-overflow depends on --param max-jump-thread-duplication-stmts=17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90191 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |9.0 --- Comment #1 from Richard Biener --- So is the warning good or bad? That it now depends on the param suggests a change in default optimization behavior.
[Bug c++/90172] [9 Regression] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90172 Richard Biener changed: What|Removed |Added Keywords|error-recovery |ice-on-valid-code Target Milestone|--- |9.0 --- Comment #2 from Richard Biener --- If previous compilers didn't ICE but still reject the testcase this PR would be P4, if we correctly accepted the code before it would be P1.
[Bug c++/90170] [7/8/9 Regression] ICE in unify, at cp/pt.c:22209
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90170 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.5
[Bug tree-optimization/90211] [8/9 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90211
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |8.4
--- Comment #1 from Jakub Jelinek ---
Started with r255267.
Cleaned up testcase:
/* PR tree-optimization/90211 */
/* { dg-do compile } */
/* { dg-require-effective-target pthread } */
/* { dg-options "-O3 -fassociative-math -ftree-parallelize-loops=2
-fno-signed-zeros -fno-trapping-math -fno-tree-copy-prop" } */
double
foo (int x)
{
double a, b = 0.0;
while (x < 3)
{
int c;
a = 0.0;
c = 0;
while (c < x)
{
a += 1.0;
++c;
}
b += 1.0;
++x;
}
return a + b;
}
[Bug c++/90210] [C++17] CTAD forbidding explicit deduction guide for copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90210 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-23 Ever confirmed|0 |1
[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 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #24 from Jonathan Wakely --- Fixed again, I hope.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #6)
> Or would you prefer:
> --- gcc/config/i386/i386.c.jj 2019-04-16 10:40:15.077091789 +0200
> +++ gcc/config/i386/i386.c2019-04-23 11:55:59.397227347 +0200
> @@ -23712,7 +23712,10 @@ ix86_expand_sse_fp_minmax (rtx dest, enu
>else
> {
>code = is_min ? SMIN : SMAX;
> - tmp = gen_rtx_fmt_ee (code, mode, if_true, if_false);
> + rtx operands[3] = { dest, if_true, if_false };
> + ix86_fixup_binary_operands_no_copy (code, mode, operands);
> + tmp = gen_rtx_fmt_ee (code, mode, operands[1], operands[2]);
> + dest = operands[0];
> }
>
>emit_insn (gen_rtx_SET (dest, tmp));
> instead? I think a switch on mode to handle all the possible modes in there
> and assign the different gen_{smin,smax}* in those cases would be too large.
No, the proposed patch that forces if_true operand to a register should be
enough. It doesn't make much difference calling ix86_fixup_binary_operands_*
without memory output operand.
[Bug tree-optimization/90211] New: [8/9 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90211
Bug ID: 90211
Summary: [8/9 Regression] ICE: tree check: expected ssa_name,
have real_cst in first_readonly_imm_use, at
ssa-iterators.h:351
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: ---
gcc-9.0.0-alpha20190421 snapshot (r270485) ICEs when compiling the following
testcase w/ -O3 (-Ofast) -fassociative-math -ftree-parallelize-loops=2
-fno-signed-zeros -fno-trapping-math -fno-tree-copy-prop:
double
yk (int d9)
{
double vy, q4 = 0.0;
while (d9 < 3)
{
int tc;
vy = 0.0;
tc = 0;
while (tc < d9)
{
vy += 1.0;
++tc;
}
q4 += 1.0;
++d9;
}
return vy + q4;
}
% gcc-9.0.0-alpha20190421 -O3 -fassociative-math -ftree-parallelize-loops=2
-fno-signed-zeros -fno-trapping-math -fno-tree-copy-prop -c vnd2w3xt.c
during GIMPLE pass: parloops
vnd2w3xt.c: In function 'yk':
vnd2w3xt.c:2:1: internal compiler error: tree check: expected ssa_name, have
real_cst in first_readonly_imm_use, at ssa-iterators.h:351
2 | yk (int d9)
| ^~
0x6f1e75 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree.c:9900
0x69d256 tree_check(tree_node*, char const*, int, char const*, tree_code)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree.h:3176
0x69d256 first_readonly_imm_use
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/ssa-iterators.h:351
0x69d256 try_create_reduction_list
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree-parloops.c:2817
0x69d256 parallelize_loops
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree-parloops.c:3392
0xe0583d execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree-parloops.c:3506
0xe0583d execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/tree-parloops.c:3485
[Bug c++/90101] [P0732] Error using non-type template parameter in a template template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90101
Benjamin Buch changed:
What|Removed |Added
CC||benni.buch at gmail dot com
--- Comment #1 from Benjamin Buch ---
simplified test case:
template
struct A{};
template>
struct B {};
$ g++ -std=c++2a test.cpp
test.cpp:4:17: error: invalid use of incomplete type 'struct A'
4 | template>
| ^~~
test.cpp:2:8: note: declaration of 'struct A'
2 | struct A{};
|^
$ g++ --version
g++ (Compiler-Explorer-Build) 9.0.1 20190422 (experimental)
Copyright (C) 2019 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.
https://godbolt.org/z/kdDPaO
[Bug debug/90131] wrong debug info at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Apr 23 10:10:10 2019 New Revision: 270505 URL: https://gcc.gnu.org/viewcvs?rev=270505=gcc=rev Log: 2019-04-23 Richard Biener PR debug/90131 * tree-cfgcleanup.c (move_debug_stmts_from_forwarder): Add dest_single_pred_p argument. (remove_forwarder_block): Adjust. (remove_forwarder_block_with_phi): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfgcleanup.c
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P4 CC||ebotcazou at gcc dot gnu.org, ||ian at gcc dot gnu.org --- Comment #79 from Jakub Jelinek --- Fixed for all languages but Ada and Go, neither of them is release critical.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #78 from Jakub Jelinek ---
Author: jakub
Date: Tue Apr 23 10:03:41 2019
New Revision: 270504
URL: https://gcc.gnu.org/viewcvs?rev=270504=gcc=rev
Log:
PR target/89093
* config/arm/arm.c (aapcs_vfp_is_call_or_return_candidate): Diagnose
if used with general-regs-only.
(arm_conditional_register_usage): Don't add non-general regs if
general-regs-only.
(arm_valid_target_attribute_rec): Handle general-regs-only.
* config/arm/arm.h (TARGET_HARD_FLOAT): Return false if
general-regs-only.
(TARGET_HARD_FLOAT_SUB): Define.
(TARGET_SOFT_FLOAT): Define as negation of TARGET_HARD_FLOAT_SUB.
(TARGET_REALLY_IWMMXT): Add && !TARGET_GENERAL_REGS_ONLY.
(TARGET_REALLY_IWMMXT2): Likewise.
* config/arm/arm.opt: Add -mgeneral-regs-only.
* doc/extend.texi: Document ARM general-regs-only target.
* doc/invoke.texi: Document ARM -mgeneral-regs-only.
libgcc/
* config/arm/pr-support.c: Add #pragma GCC target("general-regs-only").
* config/arm/unwind-arm.c: Likewise.
* unwind-c.c (PERSONALITY_FUNCTION): Add general-regs-only target
attribute for ARM.
libobjc/
* exception.c (PERSONALITY_FUNCTION): Add general-regs-only target
attribute for ARM.
libphobos/
* libdruntime/gcc/deh.d: Import gcc.attribute.
(personality_fn_attributes): New enum.
(scanLSDA, CONTINUE_UNWINDING, gdc_personality, __gdc_personality):
Add @personality_fn_attributes.
libstdc++-v3/
* libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Add
general-regs-only target attribute for ARM.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h
trunk/gcc/config/arm/arm.opt
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/libgcc/ChangeLog
trunk/libgcc/config/arm/pr-support.c
trunk/libgcc/config/arm/unwind-arm.c
trunk/libgcc/unwind-c.c
trunk/libobjc/ChangeLog
trunk/libobjc/exception.c
trunk/libphobos/ChangeLog
trunk/libphobos/libdruntime/gcc/deh.d
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_personality.cc
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187
--- Comment #6 from Jakub Jelinek ---
Or would you prefer:
--- gcc/config/i386/i386.c.jj 2019-04-16 10:40:15.077091789 +0200
+++ gcc/config/i386/i386.c 2019-04-23 11:55:59.397227347 +0200
@@ -23712,7 +23712,10 @@ ix86_expand_sse_fp_minmax (rtx dest, enu
else
{
code = is_min ? SMIN : SMAX;
- tmp = gen_rtx_fmt_ee (code, mode, if_true, if_false);
+ rtx operands[3] = { dest, if_true, if_false };
+ ix86_fixup_binary_operands_no_copy (code, mode, operands);
+ tmp = gen_rtx_fmt_ee (code, mode, operands[1], operands[2]);
+ dest = operands[0];
}
emit_insn (gen_rtx_SET (dest, tmp));
instead? I think a switch on mode to handle all the possible modes in there
and assign the different gen_{smin,smax}* in those cases would be too large.
[Bug c++/90210] New: [C++17] CTAD forbidding explicit deduction guide for copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90210
Bug ID: 90210
Summary: [C++17] CTAD forbidding explicit deduction guide for
copy-list-initialization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tyker at outlook dot com
Target Milestone: ---
gcc currently allows the following code:
template struct tuple { tuple(T); };
template explicit tuple(T t) -> tuple;
tuple t = { 1 };
this should fail to compile because the deduction guide is marked explicit.
the issue may come from the implicit deduction guide not being overridden by
the user defined one.
example from other compilers:
https://godbolt.org/z/M198L5
the standard says in [over.match.list]:
"In copy-list-initialization, if an explicit constructor is chosen, the
initialization is ill-formed."
[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 #23 from Jonathan Wakely ---
Author: redi
Date: Tue Apr 23 09:55:33 2019
New Revision: 270502
URL: https://gcc.gnu.org/viewcvs?rev=270502=gcc=rev
Log:
Fix std::variant regression caused by never-valueless optimization
A regression was introduced by the recent changes to provide the strong
exception safety guarantee for "never valueless" types that have O(1),
non-throwing move assignment. The problematic code is:
else if constexpr (__detail::__variant::_Never_valueless_alt())
{
// This construction might throw:
variant __tmp(in_place_index<_Np>, __il,
std::forward<_Args>(__args)...);
// But _Never_valueless_alt means this won't:
*this = std::move(__tmp);
}
When the variant is not assignable, the assignment is ill-formed, so
should not be attempted. When the variant has a copy assignment operator
but not a move assignment operator, the assignment performs a copy
assignment and that could throw, so should not be attempted.
The solution is to only take that branch when the variant has a move
assignment operator, which is determined by the _Traits::_S_move_assign
constant. When that is false the strong exception safety guarantee is
not possible, and so the __never_valueless function should also depend
on _S_move_assign.
While testing the fixes for this I noticed that the partial
specialization _Never_valueless_alt> incorrectly
assumed that is_nothrow_move_constructible> is
always true, but that's wrong for fully-dynamic COW strings. Fix the
partial specialization, and improve the comment describing
_Never_valueless_alt to be clear it depends on move construction as well
as move assignment.
Finally, I also observed that _Variant_storage::_M_valid()
was not taking advantage of the __never_valueless() function to
avoid a runtime check. Only the _Variant_storage::_M_valid()
function was using __never_valueless. That is also fixed.
PR libstdc++/87431
* include/bits/basic_string.h (_Never_valueless_alt): Make partial
specialization also depend on is_nothrow_move_constructible.
* include/std/variant (__detail::__variant::__never_valueless()):
Only true if the variant would have a move assignment operator.
(__detail::__variant::_Variant_storage::_M_valid()):
Check __never_valueless().
(variant::emplace): Only perform non-throwing move assignments
for never-valueless alternatives if the variant has a move assignment
operator.
* testsuite/20_util/variant/compile.cc: Check that never-valueless
types can be emplaced into non-assignable variants.
* testsuite/20_util/variant/run.cc: Check that never-valueless types
don't get copied when emplaced into non-assignable variants.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/basic_string.h
trunk/libstdc++-v3/include/std/variant
trunk/libstdc++-v3/testsuite/20_util/variant/compile.cc
trunk/libstdc++-v3/testsuite/20_util/variant/run.cc
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 --- Comment #5 from Jakub Jelinek --- Created attachment 46228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46228=edit gcc9-pr90187.patch Untested fix.
[Bug c++/90173] [9 Regression] ICE: Segmentation fault (in strip_declarator_types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |9.0 --- Comment #2 from Paolo Carlini --- Mine.
[Bug rtl-optimization/90209] codegen regression (x < 0 ? -x : x) results in branch instead of single instruction on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90209 --- Comment #1 from Uroš Bizjak --- Try with -fno-signed-zeros.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- That is not what I see. I see that vcondv2dfv2df is being expanded, and that one has general_operand and vector_operand predicates which do allow MEM. That calls ix86_expand_sse_fp_minmax which doesn't ensure both operands aren't MEM.
[Bug c++/90196] std:: types unused without warnings but simple type not affected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90196 --- Comment #6 from Jonathan Wakely --- (In reply to Максим Прохоренко from comment #3) > Allocate GiB of unused memory and don't warn about it? But 1 simple double - > it is a big problem. Nobody said that. But the warning has to be driven by simple rules. An unused double is easy to detect and warn about. Knowing if a complex type exists for some reason that the compiler can't infer is harder to do. > For std:: objects with side effect - OK! > But for simple unused vector or set or map??? Destroying elements and deallocating memory is a side effect. The compiler doesn't do arbitrarily complex analysis of what a destructor does, it just considers a non-trivial destructor to be doing something.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187
--- Comment #3 from Uroš Bizjak ---
It looks like middle-end is bypassing sminv2df3 expander and constructs RTX by
hand. This should not be done, since the expander decides whether IEEE or
non-IEEE variant should be used.
Please note that there is also an issue with {smax,smin}{sf,df}3, where
&& !(MEM_P (operands[1]) && MEM_P (operands[2]))
is (intentionally?) missing, and we depend on RA to fix invalid RTX.
