[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #13 from Eric Gallager ---
(In reply to Segher Boessenkool from comment #11)
> Hi Daniel,
>
> (In reply to Daniel Marjamäki from comment #9)
> > Problems;
> >
> > * Code that performs comparison properly gets a warning.
>
> You get a warning if you compare a signed thing to an unsigned thing, and
> that signed thing is not (necessarily) the same when cast to unsigned (which
> is what will happen, and is what often catches people by surprise, and that
> is exactly what the warning is for).
>
> Do you have examples of perfectly fine code where you get a warning?
>
> > * Code where programmer makes a mistake with a cast does not generate a
> > warning.
>
> Yes. You should not use casts, except in some very specific cases, and
> most of the uses you see "in the wild" are a bad idea. Sometimes I wonder
> if we should have a -Wcast ("Warn for any cast.").
I get the feeling that such a warning would be extremely noisy and that no one
would use it. It would probably be better to go about improving existing
cast-related warnings, or adding new ones for specific cases, rather than
breaking out such a broad hammer. For example, the fixits that David Malcolm
added for -Wold-style-cast are very nice; extending those to apply to more
cast-related warnings would be a good improvement (I've been meaning to open a
separate bug about this). These would all be better, more-specific warnings to
add than an extremely broad -Wcast:
* -Wcast-to-the-same-type (bug 85043)
* -Wcast-variadic-function-type (bug 87379)
* -Wfunctional-cast (bug 69818)
* -Wcast-enum (bug 30357)
* -Wold-style-cast-qual (fixit would suggest using const_cast instead)
* -Wold-style-useless-cast
* Any of clang's cast-related warnings that we currently don't have yet; grep
https://clang.llvm.org/docs/DiagnosticsReference.html for the word "cast" to
find some
>
> > * This warning encourage programmers to cast and when they do make mistakes
> > sometimes there is no warning.
>
> What?
>
> ===
> void g(void);
> void f(long s, unsigned long u) { if (s == u) g(); }
> void f4(unsigned long u) { if (u == 4) g(); }
> void f8(signed char s, unsigned char u) { if (s == u) g(); }
> ===
>
> su.c: In function 'f':
> su.c:2:41: warning: comparison of integer expressions of different
> signedness: 'long int' and 'long unsigned int' [-Wsign-compare]
> 2 | void f(long s, unsigned long u) { if (s == u) g(); }
> | ^~
>
> Where does that encourage programmers to do silly and dangerous things?
> (Also not f4 and f8 don't warn).
>
> > Yet you think this is all fine and you are happy about these problems.
>
> I think that the warning does what it is supposed to do, yes.
>
> > It's safer to shut off this warning and use better tools to find these
> > issues.
>
> It is even safer to use a different programming language that does not
> have these problems. But we don't, we are programming in C here (or C++
> or whatever), and it has these problems, and we have a warning to warn
> about it.
>
> How can we educate people how to write better code, in the warning message,
> or maybe a fixit hint, or some info message?
If gcc can come up with a fixit, yes, that would be good.
(In reply to Daniel Marjamäki from comment #10)
> Well I am just a happy gcc user.. if some gcc maintainer thinks this ticket
> is invalid feel free to close it. I can't expect that everybody will think
> just like me. :-)
>
> As a Cppcheck developer I am dissappointed that all compilers have these
> warnings. And it ruins our chances to find real bugs with proper analysis.
Should we have this block the cppcheck meta-bug (bug 89863) then?
[Bug c++/48920] typename specifier should not ignore non-type names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48920 --- Comment #3 from Eric Gallager --- (In reply to Jonathan Wakely from comment #2) > For the first testcase [basic.scope.class] says no diagnostic required, > doesn't it? ok but what about adding an optional one though?
[Bug c++/56879] -Weffc++ warns about non-virtual base class destructor even if it is protected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56879 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Eric Gallager --- (In reply to alex from comment #2) > (In reply to comment #1) > > Comment on attachment 29827 [details] > > test source code and compiler output > > > > The solution is simple: don't use -Weffc++, it's deeply flawed. Using it > > with > > -Werror is just ridiculous. It's much better to use > > -Wdelete-non-virtual-dtor > > than -Weffc++ > > It is not what we've been using it for (-Wdelete-non-virtual-dtor seems to > be enabled by -Wall already). We'd like to keep other warnings that -Weffc++ > generates: it worked nicely for us until this point. > > > There are lots of known issues with -Weffc++ and noone has been motivated to > > fix them, see e.g. PR 22395 comment 5 and PR 16166 comment 3 for some > > discussion related to this warning. > > Too bad. This one could probably be a one-liner to just disable this warning > since -Wnon-virtual-dtor is already enabled with -Weffc++ (and it does a > better job). But "noone has been motivated" says it all. Anyway, thanks for > the pointers. I went to try to find where the warning came from, but it turns out that g++ no longer warns on the testcase (at least for me)? I guess it might have been fixed at some point, but since I don't feel like bisecting I'll just say WORKSFORME
[Bug c++/81930] [meta-bug] Issues with -Weffc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930 Bug 81930 depends on bug 56879, which changed state. Bug 56879 Summary: -Weffc++ warns about non-virtual base class destructor even if it is protected https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56879 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug c++/22395] -Weffc++ shouldn't warn about non-virtual dtor of private subclasses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22395
--- Comment #6 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #5)
> private inheritance doesn't mean the destructor can't be called with the
> wrong static type
>
> class Foo {
> public:
> ~Foo() {}
> virtual void f() { }
> };
>
> class Bar : private Foo {
> public:
> Foo* get() { return this; }
> };
>
> int main()
> {
> Bar* b = new Bar;
> delete b->get();
> }
>
> as stated in PR 16166 comment 3, the 3rd edition of Effective C++ changes
> the guideline, and -Wdelete-non-virtual-dtor is usually a better option
> anyway
Note that clang goes even farther in splitting up -Wdelete-non-virtual-dtor
into different warnings based on whether the dtor is abstract or not:
https://clang.llvm.org/docs/DiagnosticsReference.html#wdelete-abstract-non-virtual-dtor
Maybe gcc should do likewise?
[Bug c++/16168] -Weffc++ item 14 improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16168 --- Comment #11 from Eric Gallager --- (In reply to Oren Ben-Kiki from comment #10) > All good points, which you could say about many opened bugs. > > The `-Weffc++` flag is a useful tool to keep large code bases working, even > when written by less-than-guru C++ programmers. As someone tending a large > framework used by such developers, this specific bug "has non-trivial impact > on my code base", hence the original comment expressing the need for it to > be fixed. > I agree that an ideal -Weffc++ would be useful, however, the current implementation needs a lot of improvement to get there, which is why I opened a meta-bug for issues related to -Weffc++ (bug 81930) > I assume that the GCC maintainers keep an eye on the bug boards and fix bugs > depending on their impact on people's code. I hope this matched reality :-) I keep an eye on the bug boards, but I mostly just triage them and don't actually fix them... the people who do the actual fixing have their own criteria for which ones they decide to fix. Usually "impact on people's code" is judged more by stuff actually breaking (see the wrong-code and rejects-valid keywords) than by... well, whatever criteria might be applicable here. > > I suppose using the word "annoying", while concise, might have convey > additional unintentional connotations; if so, consider this a clarification > of the original intent.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #12 from Daniel Marjamäki ---
> Do you have examples of perfectly fine code where you get a warning?
So, how would you fix the warning for `f`? Many programmers would "fix" it with
a cast.
Assuming that `s` and `u` can have arbitrary values, here is the proper code:
void f(long s, unsigned long u) { if (s >= 0 && s == u) g(); }
For this correct code, gcc warns.
[Bug c++/55809] g++ doesn't differentiate elaborated type specifier and typename specifier in dependent types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55809 Eric Gallager changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||nathan at gcc dot gnu.org Summary|Doesn't differentiate |g++ doesn't differentiate |elaborated type specifier |elaborated type specifier |and typename specifier in |and typename specifier in |dependent types |dependent types --- Comment #2 from Eric Gallager --- cc-ing C++ FE maintainers for their interpretation
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 --- Comment #12 from Kewen Lin --- FWIW, I did some statistics collection with regression testing on P8 machine, the #hits on early return is 516, while the other # is 1147412. So the conclusion is that early return is useless (at least for those modern CPUs :))
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 Kewen Lin changed: What|Removed |Added Attachment #47325|0 |1 is obsolete|| --- Comment #11 from Kewen Lin --- Created attachment 47328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47328=edit Simplify with VECTOR_UNIT_NONE_P and mode_for_vector Remove if (!TARGET_ALTIVEC && !TARGET_VSX) ...
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 --- Comment #10 from Kewen Lin --- Yes, you are right, it's fine to drop it. Since the previous code will early return if it's under (!TARGET_ALTIVEC && !TARGET_VSX), I was thinking it may be good to put an early return there. I'm fine to remove it.
[Bug c++/92625] New: Internal compiler error accessing element in static constexpr char array in template class using alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92625
Bug ID: 92625
Summary: Internal compiler error accessing element in static
constexpr char array in template class using alias
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoranni at terpmail dot umd.edu
Target Milestone: ---
The internal compiler error can be reproduced by the following minimal example
that I was able to boil down to.
//-- te.cpp
template< typename T >
struct G {
using my_int = char;
static constexpr my_int my_array[1] {0};
};
void work() {
G::my_array[0];
}
//-- end
Compiling command:
g++ -std=c++17 -c -o te.o -save-temps te.cpp
My GCC information (from g++ -v):
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/afs/glue.umd.edu/software/gcc/9.1.0/sys/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure
--prefix=/cell_root/software/gcc/9.1.0/sys --enable-languages=c,c++,fortran
--with-gmp=/usr/local/gmp --with-isl=/usr/local/isl --with-mpfr=/usr/local/mpfr
--with-mpc=/usr/local/mpc --with-as=/usr/local/binutils/2.26/bin/as
--with-ld=/usr/local/binutils/2.26/bin/ld
Thread model: posix
gcc version 9.1.0 (GCC)
My OS information:
Red Hat Enterprise Linux Server release 6.10 (Santiago)
Compiler output:
//-- start output
te.cpp: In instantiation of 'constexpr const my_int G::my_array [1]':
te.cpp:11:16: required from here
te.cpp:6:29: internal compiler error: in tsubst_copy, at cp/pt.c:16155
6 | static constexpr my_int my_array[1] {0};
| ^~~~
0x593dca tsubst_copy
../../src/gcc/cp/pt.c:16155
0x6c8770 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:19611
0x6d0284 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:18241
0x6d0284 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:17917
0x6d260c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15482
0x6d260c tsubst_init
../../src/gcc/cp/pt.c:15486
0x6ce322 regenerate_decl_from_template
../../src/gcc/cp/pt.c:24155
0x6ce322 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.c:24699
0x63be13 maybe_instantiate_decl
../../src/gcc/cp/decl2.c:5300
0x63be13 maybe_instantiate_decl
../../src/gcc/cp/decl2.c:5284
0x63d958 mark_used(tree_node*, int)
../../src/gcc/cp/decl2.c:5456
0x6fa5af finish_id_expression_1
../../src/gcc/cp/semantics.c:3777
0x6fa5af finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../src/gcc/cp/semantics.c:3925
0x6980f9 cp_parser_primary_expression
../../src/gcc/cp/parser.c:5723
0x69becb cp_parser_postfix_expression
../../src/gcc/cp/parser.c:7178
0x6a89f9 cp_parser_unary_expression
../../src/gcc/cp/parser.c:8472
0x68696f cp_parser_cast_expression
../../src/gcc/cp/parser.c:9357
0x68715a cp_parser_binary_expression
../../src/gcc/cp/parser.c:9460
0x687ef7 cp_parser_assignment_expression
../../src/gcc/cp/parser.c:9758
0x68821a cp_parser_expression
../../src/gcc/cp/parser.c:9925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/92611] auto vectorization failed for type promotation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92611
--- Comment #2 from Hongtao.liu ---
(In reply to Richard Biener from comment #1)
> I think Richard laid ground for this to work on x86 (it needs AVX512?),
AVX512 is not needed.
> not sure what is needed in the backend here to make V4QI -> V4SI conversions
> vectorized?
There're many expressions depends on type promotion.
Such like
void foo(int *__restrict dst, char *__restrict src1,
char *__restrict src2)
{
for(int x = 0; x < 4; x++ )
dst[x] = src1[x] + src2[x];
}
And I think it also affects pr92492.
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 --- Comment #9 from Segher Boessenkool --- Oh, and I think you can drop the if (!TARGET_ALTIVEC && !TARGET_VSX) thing? The rest of the code should handle that fine?
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #11 from Segher Boessenkool ---
Hi Daniel,
(In reply to Daniel Marjamäki from comment #9)
> Problems;
>
> * Code that performs comparison properly gets a warning.
You get a warning if you compare a signed thing to an unsigned thing, and
that signed thing is not (necessarily) the same when cast to unsigned (which
is what will happen, and is what often catches people by surprise, and that
is exactly what the warning is for).
Do you have examples of perfectly fine code where you get a warning?
> * Code where programmer makes a mistake with a cast does not generate a
> warning.
Yes. You should not use casts, except in some very specific cases, and
most of the uses you see "in the wild" are a bad idea. Sometimes I wonder
if we should have a -Wcast ("Warn for any cast.").
> * This warning encourage programmers to cast and when they do make mistakes
> sometimes there is no warning.
What?
===
void g(void);
void f(long s, unsigned long u) { if (s == u) g(); }
void f4(unsigned long u) { if (u == 4) g(); }
void f8(signed char s, unsigned char u) { if (s == u) g(); }
===
su.c: In function 'f':
su.c:2:41: warning: comparison of integer expressions of different signedness:
'long int' and 'long unsigned int' [-Wsign-compare]
2 | void f(long s, unsigned long u) { if (s == u) g(); }
| ^~
Where does that encourage programmers to do silly and dangerous things?
(Also not f4 and f8 don't warn).
> Yet you think this is all fine and you are happy about these problems.
I think that the warning does what it is supposed to do, yes.
> It's safer to shut off this warning and use better tools to find these
> issues.
It is even safer to use a different programming language that does not
have these problems. But we don't, we are programming in C here (or C++
or whatever), and it has these problems, and we have a warning to warn
about it.
How can we educate people how to write better code, in the warning message,
or maybe a fixit hint, or some info message?
[Bug middle-end/92624] New: inconsistent folding of strcmp calls with unterminated arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92624
Bug ID: 92624
Summary: inconsistent folding of strcmp calls with unterminated
arrays
Product: gcc
Version: 10.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: ---
This shows an inconsistency in how GCC handles code with undefined behavior
that is easily detectable in all four functions below. But by "taking
shortcuts" in some cases (and folding the result of the call when both
arguments are known to point to the same array) while being more careful in
others (even though the contents of the const arrays are known, they are also
known not to be nul-terminated), it introduces an inconsistency in how the
undefined behavior is handled: in the former case it's safely avoided while in
the latter, by calling the library function, the result is unpredictable.
At the same time, in the latter case the problem can be detected before
expansion and diagnosed by -Wstringop-overflow (once pr88226 is resolved), in
the former it won't be.
This is one of the kinds of problems that will need to be dealt with if/when
more consistency in dealing with undefined behavior is introduced (as has been
discussed).
$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
const char a[] = { '1', '2' };
const char b[] = { '1', '2' };
int f0 (void)
{
const char *p = a, *q = b;
return __builtin_strcmp (p, q); // not folded
}
int f1 (void)
{
const char *p = a, *q = a;
return __builtin_strcmp (p, q); // folded to zero
}
int g0 (void)
{
const char *p = a, *q = b;
return __builtin_strncmp (p, q, 4); // not folded
}
int g1 (void)
{
const char *p = a, *q = a;
return __builtin_strncmp (p, q, 4); // folded to zero
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=2)
f0 ()
{
int _2;
[local count: 1073741824]:
_2 = __builtin_strcmp (, ); [tail call]
return _2;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1937, cgraph_uid=2, symbol_order=3)
f1 ()
{
[local count: 1073741824]:
return 0;
}
;; Function g0 (g0, funcdef_no=2, decl_uid=1942, cgraph_uid=3, symbol_order=4)
g0 ()
{
int _2;
[local count: 1073741824]:
_2 = __builtin_strncmp (, , 4); [tail call]
return _2;
}
;; Function g1 (g1, funcdef_no=5, decl_uid=1947, cgraph_uid=4, symbol_order=5)
g1 ()
{
[local count: 1073741824]:
return 0;
}
[Bug libstdc++/92267] [9 Regression] crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Can this be backported to 9 now, please?
[Bug c++/92402] parsing error in lambda trail return type with decltype, statement expressions and structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92402
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #1 from Will Wray ---
Here's a motivating use case; https://godbolt.org/z/Tt-QmN
This allows to effectively SFINAE on structured binding - a 'missing link'.
Works in Clang since 5.0.
GDB debugging gcc latest trunk build. The parse error occurs here
gcc/cp/parser.c:13869
cp_parser_decomposition_declaration
else if (decl != error_mark_node && DECL_CHAIN (decl2) != prev)
{
/* Ensure we've diagnosed redeclaration if we aren't creating
a new VAR_DECL. */
gcc_assert (errorcount); /*** HERE ***/
decl = error_mark_node;
}
Haven't worked out exactly what is being checked there.
So I tried commenting out that entire else-if block to see what happens.
It then proceeds to mangling and crashes out in contains_struct_check.
Backtrace looks like this:
#0 contains_struct_check gcc/cp/mangle.c "write_closure_type_name"
gcc/tree.h:3386
#1 write_closure_type_name gcc/cp/mangle.c:1641 in write_unqualified_name
#3 write_prefix gcc/cp/mangle.c:1164 in mangle_decomp at gcc/cp/mangle.c:4050
#5 cp_maybe_mangle_decomp gcc/cp/decl.c:8024
#6 cp_parser_decomposition_declaration
[Bug libstdc++/92616] Inconsistency in time between system_clock::now() and time(nullptr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92616 --- Comment #6 from Jonathan Wakely --- https://bugzilla.kernel.org/ but I think they prefer bugs to be reported to distros unless you're actually using the upstream kernel. So report it to Ubuntu (but mention it's also seen in Fedora).
[Bug rtl-optimization/92602] Failure in gcc.target/powerpc/bswap64-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602 --- Comment #5 from Andrew Pinski --- (In reply to seurer from comment #4) > FYI, this also causes an issue when building spec2017 in case anyone else > runs into that. I'll have to change this part to use -fcommon. That was/is PR 92612.
[Bug rtl-optimization/92602] Failure in gcc.target/powerpc/bswap64-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602 --- Comment #4 from seurer at gcc dot gnu.org --- FYI, this also causes an issue when building spec2017 in case anyone else runs into that. I'll have to change this part to use -fcommon. /home/seurer/gcc/install/gcc-test/bin/gcc -m64 -O3 -mcpu=power8 -DSPEC_LP64 -Wno-deprecated-declarations -m64 -Wl,-q -Wl,-rpath=/home/seurer/gcc/install/gcc-test/lib64 ldecod_src/nal.o ldecod_src/mbuffer_mvc.o ldecod_src/image.o ldecod_src/mb_access.o ldecod_src/memalloc.o ldecod_src/mc_prediction.o ldecod_src/mb_prediction.o ldecod_src/intra4x4_pred_mbaff.o ldecod_src/loop_filter_mbaff.o ldecod_src/context_ini.o ldecod_src/configfile.o ldecod_src/cabac.o ldecod_src/sei.o ldecod_src/leaky_bucket.o ldecod_src/filehandle.o ldecod_src/errorconcealment.o ldecod_src/decoder_test.o ldecod_src/img_process.o ldecod_src/mv_prediction.o ldecod_src/fmo.o ldecod_src/output.o ldecod_src/mc_direct.o ldecod_src/rtp.o ldecod_src/nalucommon.o ldecod_src/config_common.o ldecod_src/intra_chroma_pred.o ldecod_src/transform8x8.o ldecod_src/blk_prediction.o ldecod_src/intra8x8_pred_mbaff.o ldecod_src/erc_do_i.o ldecod_src/io_tiff.o ldecod_src/mbuffer.o ldecod_src/block.o ldecod_src/intra4x4_pred.o ldecod_src/transform.o ldecod_src/annexb.o ldecod_src/ldecod.o ldecod_src/macroblock.o ldecod_src/vlc.o ldecod_src/parset.o ldecod_src/loop_filter_normal.o ldecod_src/parsetcommon.o ldecod_src/erc_do_p.o ldecod_src/loopFilter.o ldecod_src/intra16x16_pred_mbaff.o ldecod_src/intra4x4_pred_normal.o ldecod_src/intra16x16_pred_normal.o ldecod_src/win32.o ldecod_src/intra16x16_pred.o ldecod_src/intra8x8_pred_normal.o ldecod_src/io_raw.o ldecod_src/img_io.o ldecod_src/nalu.o ldecod_src/quant.o ldecod_src/intra8x8_pred.o ldecod_src/erc_api.o ldecod_src/header.o ldecod_src/biaridecod.o ldecod_src/input.o -lm -o ldecod_r ldecod_src/decoder_test.o:(.bss+0x0): multiple definition of `cfgparams' ldecod_src/configfile.o:(.bss+0x0): first defined here ldecod_src/config_common.o:(.bss+0x0): multiple definition of `cfgparams' ldecod_src/configfile.o:(.bss+0x0): first defined here collect2: error: ld returned 1 exit status specmake: *** [/home/seurer/gcc/cpu2017/benchspec/Makefile.defaults:337: ldecod_r] Error 1 Error with make.ldecod_r 'specmake --output-sync -j9 build TARGET=ldecod_r':
[Bug tree-optimization/92608] [9/10 Regression] ICE: Segmentation fault (in find_loop_guard)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92608 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Author: prathamesh3492 Date: Thu Nov 21 20:20:36 2019 New Revision: 278598 URL: https://gcc.gnu.org/viewcvs?rev=278598=gcc=rev Log: Use safe_dyn_cast instead of dyn_cast in find_loop_guard to fix PR92608. 2019-11-22 Prathamesh Kulkarni PR tree-optimization/92608 * tree-ssa-loop-unswitch.c (find_loop_guard): Use safe_dyn_cast instead of dyn_cast. testsuite/ * gcc.dg/torture/pr92608.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr92608.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-unswitch.c
[Bug libfortran/92569] [8/9/10 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.0 Known to fail||10.0, 8.3.1, 9.2.1
[Bug libfortran/92569] [8/9/10 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
--- Comment #6 from anlauf at gcc dot gnu.org ---
Something like the following fixes the testcase, but leads to regressions
elsewhere in the testsuite (e.g. direct_io_{9,10}.f):
Index: libgfortran/io/transfer.c
===
--- libgfortran/io/transfer.c (Revision 278593)
+++ libgfortran/io/transfer.c (Arbeitskopie)
@@ -2544,6 +2544,8 @@
while (data)
{
+ if (unlikely (dtp->u.p.current_unit->endfile == AFTER_ENDFILE))
+ return;
dtp->u.p.transfer (dtp, iotype, data, kind, size, tsize);
data += stride0 * tsize;
count[0] += tsize;
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 --- Comment #8 from Segher Boessenkool --- I don't think you need lines 4909..4911. How can we test this? Is there good test coverage for it already?
[Bug testsuite/92619] [10 regression] gcc.dg/gnu2x-attrs-1.c fails starting with r278547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92619 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Sandoe --- should be fixed now.
[Bug testsuite/92619] [10 regression] gcc.dg/gnu2x-attrs-1.c fails starting with r278547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92619 --- Comment #2 from Iain Sandoe --- Author: iains Date: Thu Nov 21 19:56:34 2019 New Revision: 278594 URL: https://gcc.gnu.org/viewcvs?rev=278594=gcc=rev Log: [testsuite] Fix bad dg-error syntax in gnu2x-attrs-1.c. 2019-11-21 Iain Sandoe PR testsuite/92619 * gcc.dg/gnu2x-attrs-1.c: Fix dg-error syntax. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #20 from Aleksey --- (In reply to Segher Boessenkool from comment #19) > '-freorder-blocks' > Reorder basic blocks in the compiled function in order to reduce > number of taken branches and improve code locality. > > Enabled at levels '-O', '-O2', '-O3', '-Os'. > > If you disable this option, you get more taken branches and a less linear > control flow. As documented. If compgoto would have been depended on this option then that would explained observed behavior. But compgoto does not depend on it. And it says: /* Duplicate the blocks containing computed gotos. This basically unfactors computed gotos that were factored early on in the compilation process to speed up edge based data flow. We used to not unfactor them again, which can seriously pessimize code with many computed jumps in the source code, such as interpreters. See e.g. PR15242. */ static void duplicate_computed_gotos (function *fun) "This basically unfactors computed gotos that were factored early" And it works fine until one last predecessor. Why until the last predecessor? That's the point. > > > START - the very first "goto *xxx" - was not optimized, since "bb 5" has > > only 1 predecessor. > > But it's optimized in later step "bbro". That's exactly why option > > "-fno-reorder-blocks" breaks first jump optimization. > > > > Can someone explain why there are such conditions: > > if (single_pred_p (bb)) > > return false; > > > > if (single_pred_p (bb)) > > continue; > > in maybe_duplicate_computed_goto function? > > It duplicates the code, one copy for every predecessor to jump to. I showed that not for every predecessor. > It does not move existing blocks elsewhere. I provided RTL dump, it says that it removes edges. It moves the code. It even says this: /* Duplicates basic block BB and redirects edge E to it. ... basic_block duplicate_block (basic_block bb, edge e, basic_block after, copy_bb_data *id) Edge count in bb decreases, so code is moving. And by answering the question I meant "what are these conditions for". Why bb with one predecessor is not optimized? Why not just optimize it right here right now?
[Bug libfortran/92569] [8/9/10 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Component|fortran |libfortran
--- Comment #5 from anlauf at gcc dot gnu.org ---
Running the failing testcase under the debugger, it appears that the
end-of-file condition is not properly dealt with in the library:
transfer.c:
2542
2543 data = GFC_DESCRIPTOR_DATA (desc);
2544
2545 while (data)
2546{
2547 dtp->u.p.transfer (dtp, iotype, data, kind, size, tsize);
2548 data += stride0 * tsize;
2549 count[0] += tsize;
2550 n = 0;
2551 while (count[n] == extent[n])
(gdb) p dtp->u.p.current_unit->endfile
one gets after the last valid read
$2 = NO_ENDFILE
and after the first attempt pase EOF:
(gdb) p dtp->u.p.current_unit->endfile
$5 = AFTER_ENDFILE
and after the next attempt:
At line 8 of file res.f (unit = 1, file = 'resultav4.dat')
Fortran runtime error: Read past ENDFILE record
So one needs to check and properly catch the ENDFILE condition.
Who knows the right way to deal with such conditions?
[Bug ada/92575] couple of suspicious assignments in expect.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org
[Bug ada/92575] couple of suspicious assignments in expect.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-21 CC||ebotcazou at gcc dot gnu.org Summary|trunk/gcc/ada/expect.c: 2 * |couple of suspicious |suspicious assignments ?|assignments in expect.c Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Ugh.
[Bug testsuite/92623] FAIL: gcc.dg/Wstringop-overflow-17.c on ILP32: missing warning on line 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92623 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-21 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug testsuite/92623] New: FAIL: gcc.dg/Wstringop-overflow-17.c on ILP32: missing warning on line 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92623 Bug ID: 92623 Summary: FAIL: gcc.dg/Wstringop-overflow-17.c on ILP32: missing warning on line 8 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- When compiled with the -m32 option the test fails one assertion in x86_64-linux builds: FAIL: gcc.dg/Wstringop-overflow-17.c (test for warnings, line 8) Also seen on i586-unknown-freebsd11.3: https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01258.html and pru-unknown-elf: https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01241.html
[Bug testsuite/92622] FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92622 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-21 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug testsuite/92622] New: FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92622 Bug ID: 92622 Summary: FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- When compiled with the -m32 option the test fails two assertions in x86_64-linux builds: FAIL: gcc.dg/Warray-bounds-22.c vla (test for warnings, line 67) FAIL: gcc.dg/Warray-bounds-22.c vla (test for warnings, line 69) Also seen on m68k-unknown-linux-gnu: https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01246.html
[Bug fortran/92621] Segmentation fault with assumed rank allocatable intent(out) with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 47327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47327=edit C code
[Bug fortran/92621] New: Segmentation fault with assumed rank allocatable intent(out) with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 Bug ID: 92621 Summary: Segmentation fault with assumed rank allocatable intent(out) with bind(c) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47326=edit Code demonstrating problems. Hi all! Segmentation fault both on: GNU Fortran (GCC) 9.2.1 20191119 and GNU Fortran (GCC) 10.0.0 20191119 (experimental) Seems to be triggered by an erroneous call to free on entry (required by intent(out) *if* allocated) Heisenbug type does not trigger always, does not show under gdb or valgrind. Compiling using the flag "-static-libgfortran" seems to stabilize it, crashing repeatedly, also under gdb, but not under valgrind. The flag "-Wmaybe-uninitialized" generates garbage diagnostics.
[Bug c/92620] Ignored -fno-builtin -fno-builtin-memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92620 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Why do you think this is a bug? > > From https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Standards.html#Standards: > Most of the compiler support routines used by GCC are present in libgcc, but > there are a few exceptions. GCC requires the freestanding environment > provide memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is > used, and the target does not implement the trap pattern, then GCC emits a > call to abort. Note this is about -ffreestanding option but it also applies to -fno-builtin because of: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C-Dialect-Options.html: -ffreestanding Assert that compilation targets a freestanding environment. This implies -fno-builtin
[Bug tree-optimization/90836] Missing popcount pattern matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90836 Tamar Christina changed: What|Removed |Added Status|NEW |RESOLVED CC||tnfchris at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #5 from Tamar Christina --- Fixed on trunk
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90836, which changed state. Bug 90836 Summary: Missing popcount pattern matching https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90836 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/92620] Ignored -fno-builtin -fno-builtin-memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92620 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Why do you think this is a bug? >From https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Standards.html#Standards: Most of the compiler support routines used by GCC are present in libgcc, but there are a few exceptions. GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is used, and the target does not implement the trap pattern, then GCC emits a call to abort.
[Bug libstdc++/92616] Inconsistency in time between system_clock::now() and time(nullptr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92616 --- Comment #5 from Anthony Williams --- Where can I file a bug in the vDSO?
[Bug c/92620] New: Ignored -fno-builtin -fno-builtin-memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92620
Bug ID: 92620
Summary: Ignored -fno-builtin -fno-builtin-memcpy
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
int main()
{
printf("%s", (char[]){'H','e','l','l','o',' ','H','e','l','l','o','
','H','e','l','l','o',' ','H','e','l','l','o',' ','H','e','l','l','o','
','H','e','l','l','o',' ','H','e','l','l','o',' ','H','e','l','l','o','
','H','e','l','l','o',' ','H','e','l','l','o',' ','H','e','l','l','o','
','H','e','l','l','o',' ',0});
}
-Os -fno-builtin -fno-builtin-memcpy
ARM gcc 8.2
main:
str lr, [sp, #-4]!
sub sp, sp, #84
mov r2, #73
ldr r1, .L3
add r0, sp, #4
bl memcpy
add r1, sp, #4
ldr r0, .L3+4
bl printf
mov r0, #0
add sp, sp, #84
ldr pc, [sp], #4
.L3:
.word .LANCHOR0
.word .LC1
.LC1:
.ascii "%s\000"
[Bug testsuite/92619] [10 regression] gcc.dg/gnu2x-attrs-1.c fails starting with r278547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92619 --- Comment #1 from Iain Sandoe --- duh, it looks like I missed a "" in the dg-error .. will sort it out.
[Bug fortran/92569] [8/9/10 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|WAITING |NEW Last reconfirmed|2019-11-19 00:00:00 |2019-11-21 CC||anlauf at gcc dot gnu.org Summary|gfortran read with end |[8/9/10 Regression] |directive does not trigger |gfortran read with end |in gfortran 9.2 |directive does not trigger ||with -ffrontend-optimize --- Comment #4 from anlauf at gcc dot gnu.org --- The bug triggers with -ffrontend-optimize, thus confirmed. The problem shows up with the implied loop over j in the read statement, which runs over the second dimension. Transposing the array and adjusting the code appropriately it does no longer fail. Workaround: compile with -fno-frontend-optimize until a fix is available.
[Bug testsuite/92619] New: [10 regression] gcc.dg/gnu2x-attrs-1.c fails starting with r278547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92619 Bug ID: 92619 Summary: [10 regression] gcc.dg/gnu2x-attrs-1.c fails starting with r278547 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This now fails on powerpc64 Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -std=gnu2x -S -o gnu2x-attrs-1.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -std=gnu2x -S -o gnu2x-attrs-1.s /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:10:1: warning: attribute ignored [-Wattributes] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:10:1: note: an attribute that appertains to a type-specifier is ignored /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c: In function 'f2': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:20:3: warning: 'a' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:19:27: note: declared here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c: In function 'f3': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:27:3: warning: 'a' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:26:7: note: declared here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c: In function 'f4': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:35:3: warning: 'a' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:30:37: note: declared here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c: In function 'f5': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:41:3: warning: 'b' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:30:44: note: declared here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c: In function 'f6': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:49:3: warning: 'E1' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:44:10: note: declared here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c: In function 'f7': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:55:3: warning: 'y' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:53:29: note: declared here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c: In function 'f8': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:63:9: warning: 'u' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:58:27: note: declared here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c: In function 'f9': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:71:8: warning: 'edep' is deprecated [-Wdeprecated-declarations] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/gnu2x-attrs-1.c:66:26: note: declared here FAIL: gcc.dg/gnu2x-attrs-1.c *-*-darwin* (test for errors, line 8) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 10) PASS: gcc.dg/gnu2x-attrs-1.c appertains (test for warnings, line 10) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 20) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 27) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 35) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 41) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 49) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 55) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 63) PASS: gcc.dg/gnu2x-attrs-1.c (test for warnings, line 71) PASS: gcc.dg/gnu2x-attrs-1.c (test for excess errors) testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes11 # of unexpected failures1
[Bug tree-optimization/92526] [10 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:2274 since r278244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92526 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/92526] [10 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:2274 since r278244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92526 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Nov 21 17:45:36 2019 New Revision: 278592 URL: https://gcc.gnu.org/viewcvs?rev=278592=gcc=rev Log: Reject versioning for alignment with different masks (PR 92526) Allowing mixed vector sizes broke the assumption in the following assert, since it's now possible for different accesses to require different levels of alignment: /* FORNOW: use the same mask to test all potentially unaligned references in the loop. The vectorizer currently supports a single vector size, see the reference to GET_MODE_NUNITS (TYPE_MODE (vectype)) where the vectorization factor is computed. */ gcc_assert (!LOOP_VINFO_PTR_MASK (loop_vinfo) || LOOP_VINFO_PTR_MASK (loop_vinfo) == mask); I guess we could try to over-align smaller accesses so that all of them are consistent, or try to support multiple alignment masks, but for now the easiest fix seems to be to turn the assert into a bail-out check. 2019-11-21 Richard Sandiford gcc/ PR tree-optimization/92526 * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Reject versioning for alignment if the accesses do not have a consistent mask, rather than asserting that the masks are consistent. gcc/testsuite/ PR tree-optimization/92526 * gcc.target/aarch64/pr92526.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr92526.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/92543] [10 regression] gcc.dg/vect/vect-alias-check-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92543
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Nov 21 17:43:24 2019
New Revision: 278591
URL: https://gcc.gnu.org/viewcvs?rev=278591=gcc=rev
Log:
Add more markup to vect-alias-check-{1,18}.c (PR 92543)
In vect-alias-check-1.c we unroll the inner loop and then vectorise
the stores at a[c + 1][b]. Since the access has no guaranteed
alignemnt, we need a realignment mechanism or support for unaligned
accesses in order to vectorise.
In vect-alias-check-18.c we use a reverse access and so need
permute support in order to vectorise.
I'm not really sure when this part of the testsuite prefers
{ xfail { ! foo } } and when it prefers { target foo }. xfail
seems like the most common choice for the alignment restriction,
whereas vect_int and vect_perm are mostly dg-require-effective-target
style features, so I went with that combination.
2019-11-21 Richard Sandiford
gcc/testsuite/
PR testsuite/92543
* gcc.dg/vect/vect-alias-check-1.c: XFAIL the alias check message
if there is no realignment support and no support for unaligned
accesses.
* gcc.dg/vect/vect-alias-check-18.c: Restrict the test for the
alias message to targets that have permute support.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-18.c
[Bug tree-optimization/92543] [10 regression] gcc.dg/vect/vect-alias-check-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92543 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from rsandifo at gcc dot gnu.org --- Should be fixed now, please reopen if not.
[Bug tree-optimization/92595] [10 Regression] ICE in related_vector_mode, at stor-layout.c:534 since r278229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92595 --- Comment #1 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Nov 21 17:41:16 2019 New Revision: 278590 URL: https://gcc.gnu.org/viewcvs?rev=278590=gcc=rev Log: Add missing VECTOR_MODE_P checks (PR 92595) This patch fixes some cases in which we weren't checking whether we had a vector mode before calling related_vector_mode or before making vector optab queries. 2019-11-21 Richard Sandiford gcc/ PR tree-optimization/92595 * tree-vect-stmts.c (get_group_load_store_type): Add a VECTOR_MODE_P check. (vectorizable_store, vectorizable_load): Likewise. gcc/testsuite/ PR tree-optimization/92595 * g++.dg/vect/pr92595.cc: New test. Added: trunk/gcc/testsuite/g++.dg/vect/pr92595.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/92595] [10 Regression] ICE in related_vector_mode, at stor-layout.c:534 since r278229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92595 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #19 from Segher Boessenkool --- (In reply to Aleksey from comment #16) > > > It would be helpful if you give the explanation how these options affect > > > "un-factoring". > > > > What options? -fno-reorder-blocks? Those doo the same to this code as > > they do anywhere else: the compiler does not run the reorder-blocks > > pass, so you get worse code. > > This is not an explanation. Of course it is. If you want a motivation instead, then a good argument is that this is consistent with how all other options are handled. '-freorder-blocks' Reorder basic blocks in the compiled function in order to reduce number of taken branches and improve code locality. Enabled at levels '-O', '-O2', '-O3', '-Os'. If you disable this option, you get more taken branches and a less linear control flow. As documented. And not just for duplicating the computed gotos, but in *many* other places. You *need* to have this pass enabled, to get good code. And almost everyone always has; this works both ways. > START - the very first "goto *xxx" - was not optimized, since "bb 5" has > only 1 predecessor. > But it's optimized in later step "bbro". That's exactly why option > "-fno-reorder-blocks" breaks first jump optimization. > > Can someone explain why there are such conditions: > if (single_pred_p (bb)) > return false; > > if (single_pred_p (bb)) > continue; > in maybe_duplicate_computed_goto function? It duplicates the code, one copy for every predecessor to jump to. It does not move existing blocks elsewhere. > One can ask compiler to not reorder > them with option "-fno-reorder-blocks" - that's enough to fulfil the > requirements. This option was used in 2004 in QEMU for similar purposes. It is 15 years later now. If you want a compiler that behaves like GCC did in 2004, you should use a GCC release from 2004 perhaps? > So GCC has enough options to structure the machine code in C (and C++) > language in desired way, there is no need to go into assembler. That is not how things work.
[Bug tree-optimization/91355] [8/9/10 Regression] optimized code does not call destructor while unwinding after exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:21:46 2019 New Revision: 278587 URL: https://gcc.gnu.org/viewcvs?rev=278587=gcc=rev Log: PR tree-optimization/91355 * tree-ssa-sink.c (select_best_block): Use >= rather than > for early_bb scaled count with best_bb count comparison. * g++.dg/torture/pr91355.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr91355.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-sink.c
[Bug middle-end/90840] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90840 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:20:47 2019 New Revision: 278586 URL: https://gcc.gnu.org/viewcvs?rev=278586=gcc=rev Log: Backported from mainline 2019-11-20 Jakub Jelinek PR middle-end/90840 * expmed.c (store_bit_field_1): Handle the case where op0 is not a MEM and has a mode that doesn't have corresponding integral type. * gcc.c-torture/compile/pr90840.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr90840.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/expmed.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug target/90867] [8 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Thu Nov 21 17:20:04 2019
New Revision: 278585
URL: https://gcc.gnu.org/viewcvs?rev=278585=gcc=rev
Log:
Backported from mainline
2019-11-20 Jakub Jelinek
PR target/90867
* config/i386/i386.c (ix86_valid_target_attribute_tree): Don't
clear opts->x_ix86_isa_flags{,2} here...
(ix86_valid_target_attribute_inner_p): ... but here when seeing
arch=. Also clear opts->x_ix86_isa_flags{,2}_explicit.
* gcc.target/i386/pr90867.c: New test.
Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr90867.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/90898] [8 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:18:55 2019 New Revision: 278584 URL: https://gcc.gnu.org/viewcvs?rev=278584=gcc=rev Log: Backported from mainline 2019-11-20 Jakub Jelinek PR c/90898 * tree-ssa-ccp.c (insert_clobber_before_stack_restore): Remove assertion. (insert_clobbers_for_var): Fix a typo in function comment. * gcc.dg/pr90898.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr90898.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-ccp.c
[Bug middle-end/91450] __builtin_mul_overflow(A,B,R) wrong code if product < 0, *R is unsigned, and !(A)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91450 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:18:17 2019 New Revision: 278583 URL: https://gcc.gnu.org/viewcvs?rev=278583=gcc=rev Log: Backported from mainline 2019-11-19 Jakub Jelinek PR middle-end/91450 * internal-fn.c (expand_mul_overflow): For s1 * s2 -> ur, if one operand is negative and one non-negative, compare the non-negative one against 0 rather than comparing s1 & s2 against 0. Otherwise, don't compare (s1 & s2) == 0, but compare separately both s1 == 0 and s2 == 0, unless one of them is known to be negative. Remove tem2 variable, use tem where tem2 has been used before. * gcc.c-torture/execute/pr91450-1.c: New test. * gcc.c-torture/execute/pr91450-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr91450-1.c branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr91450-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/internal-fn.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/92384] [8 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:17:20 2019 New Revision: 278582 URL: https://gcc.gnu.org/viewcvs?rev=278582=gcc=rev Log: Backported from mainline 2019-11-08 Jakub Jelinek PR c++/92384 * function.c (assign_parm_setup_block, assign_parm_setup_stack): Don't copy TYPE_EMPTY_P arguments from data->entry_parm to data->stack_parm slot. (assign_parms): For TREE_ADDRESSABLE parms with TYPE_EMPTY_P type force creation of a unique data.stack_parm slot. * g++.dg/torture/pr92384.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr92384.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/function.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #18 from Aleksey --- (In reply to Andrew Pinski from comment #17) > First off internal documentation is not user documentation. > Second internal documentation is not always in sync with the code. In this > case it seems like it is not fully. I understand that docs not always in sync, so I don't trust the documentation, I trust source code. > Basically BB reordering does the full unfactoring these days. I open gcc/bb-reorder.c and see this comment: /* Duplicate the blocks containing computed gotos. This basically unfactors computed gotos that were factored early on in the compilation process to speed up edge based data flow. We used to not unfactor them again, which can seriously pessimize code with many computed jumps in the source code, such as interpreters. See e.g. PR15242. */ static void duplicate_computed_gotos (function *fun) It says "This basically unfactors computed gotos that were factored early". Is it relevant comment? According to algorithm in this function it does what it says in the comment. I already provided: 1) this is compgoto step, it does not depend on option "-fno-reorder-blocks" 2) it seems it does not work in the edge cases I already provided an example from RTL and stepped through the compgoto steps. I pointed out that the last possible optimization does not take place: BB stays with the last predecessor and compgoto finishes because of this. This last predecessor must be merged too. I'm just asking what the purpose of these conditions if (single_pred_p (bb)) return false; if (single_pred_p (bb)) continue; in maybe_duplicate_computed_goto function? What if these conditions must be removed?
[Bug preprocessor/92296] [8 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:15:56 2019 New Revision: 278581 URL: https://gcc.gnu.org/viewcvs?rev=278581=gcc=rev Log: Backported from mainline 2019-10-31 Jakub Jelinek PR preprocessor/92296 * internal.h (struct def_pragma_macro): Add is_builtin bitfield. (_cpp_restore_special_builtin): Declare. * init.c (_cpp_restore_special_builtin): New function. * directives.c (do_pragma_push_macro): For NT_MACRO with NODE_BUILTIN set is_builtin and don't try to grab definition. (cpp_pop_definition): Use _cpp_restore_special_builtin to restore builtin macros. * c-c++-common/cpp/pr92296-1.c: New test. * c-c++-common/cpp/pr92296-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/c-c++-common/cpp/pr92296-1.c branches/gcc-8-branch/gcc/testsuite/c-c++-common/cpp/pr92296-2.c Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/libcpp/ChangeLog branches/gcc-8-branch/libcpp/directives.c branches/gcc-8-branch/libcpp/init.c branches/gcc-8-branch/libcpp/internal.h
[Bug tree-optimization/85887] [8 Regression] Missing DW_TAG_lexical_block PC range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:15:01 2019 New Revision: 278580 URL: https://gcc.gnu.org/viewcvs?rev=278580=gcc=rev Log: Backported from mainline 2019-10-22 Jakub Jelinek PR tree-optimization/85887 * decl.c (expand_static_init): Drop ECF_LEAF from __cxa_guard_acquire and __cxa_guard_release. Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/decl.c
[Bug c++/92201] [9/10 Regression] ICE: ‘verify_gimple’ failed with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92201 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:14:25 2019 New Revision: 278579 URL: https://gcc.gnu.org/viewcvs?rev=278579=gcc=rev Log: Backported from mainline 2019-10-29 Jakub Jelinek PR c++/92201 * cp-gimplify.c (cp_gimplify_expr): If gimplify_to_rvalue changes the function pointer type, re-add cast to the original one. * g++.dg/other/pr92201.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/other/pr92201.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-gimplify.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/92056] [10 Regression] ice in expr_object_size, at tree-object-si ze.c:675 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92056 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:13:41 2019 New Revision: 278578 URL: https://gcc.gnu.org/viewcvs?rev=278578=gcc=rev Log: Backported from mainline 2019-10-17 Jakub Jelinek PR tree-optimization/92056 * tree-object-size.c (cond_expr_object_size): Return early if then_ processing resulted in unknown size. * gcc.c-torture/compile/pr92056.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr92056.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-object-size.c
[Bug c++/91974] function not sequenced before function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91974 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:12:57 2019 New Revision: 278577 URL: https://gcc.gnu.org/viewcvs?rev=278577=gcc=rev Log: Backported from mainline 2019-10-04 Jakub Jelinek PR c++/91974 * cp-gimplify.c (cp_gimplify_expr) : For -fstrong-eval-order ensure CALL_EXPR_FN side-effects are evaluated before any arguments. Additionally, ensure CALL_EXPR_FN that isn't invariant nor OBJ_TYPE_REF nor SSA_NAME is forced into a temporary. * g++.dg/cpp1z/eval-order5.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/eval-order5.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-gimplify.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/91665] [8 Regression] ICE in build_vector_from_val, at tree.c:1904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91665 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:12:06 2019 New Revision: 278576 URL: https://gcc.gnu.org/viewcvs?rev=278576=gcc=rev Log: Backported from mainline 2019-09-07 Jakub Jelinek PR tree-optimization/91665 * tree-vect-loop.c (vectorizable_reduction): Punt if base has type incompatible with the type of PHI result. * gcc.dg/vect/pr91665.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr91665.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vect-loop.c
[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91001 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:11:19 2019 New Revision: 278575 URL: https://gcc.gnu.org/viewcvs?rev=278575=gcc=rev Log: Backported from mainline 2019-09-06 Jakub Jelinek * function.c (assign_parm_find_data_types): Use RECORD_OR_UNION_TYPE_P before testing TYPE_TRANSPARENT_AGGR. * calls.c (initialize_argument_information, load_register_parameters): Likewise. 2019-09-05 Jakub Jelinek PR middle-end/91001 PR middle-end/91105 PR middle-end/91106 * calls.c (load_register_parameters): For TYPE_TRANSPARENT_AGGR types, use type of their first field instead of type of args[i].tree_value. * gcc.c-torture/compile/pr91001.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr91001.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/calls.c branches/gcc-8-branch/gcc/function.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/91105] internal compiler error: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91105 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:11:19 2019 New Revision: 278575 URL: https://gcc.gnu.org/viewcvs?rev=278575=gcc=rev Log: Backported from mainline 2019-09-06 Jakub Jelinek * function.c (assign_parm_find_data_types): Use RECORD_OR_UNION_TYPE_P before testing TYPE_TRANSPARENT_AGGR. * calls.c (initialize_argument_information, load_register_parameters): Likewise. 2019-09-05 Jakub Jelinek PR middle-end/91001 PR middle-end/91105 PR middle-end/91106 * calls.c (load_register_parameters): For TYPE_TRANSPARENT_AGGR types, use type of their first field instead of type of args[i].tree_value. * gcc.c-torture/compile/pr91001.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr91001.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/calls.c branches/gcc-8-branch/gcc/function.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug target/91106] internal compiler error: output_operand: invalid use of register 'frame'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91106 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:11:19 2019 New Revision: 278575 URL: https://gcc.gnu.org/viewcvs?rev=278575=gcc=rev Log: Backported from mainline 2019-09-06 Jakub Jelinek * function.c (assign_parm_find_data_types): Use RECORD_OR_UNION_TYPE_P before testing TYPE_TRANSPARENT_AGGR. * calls.c (initialize_argument_information, load_register_parameters): Likewise. 2019-09-05 Jakub Jelinek PR middle-end/91001 PR middle-end/91105 PR middle-end/91106 * calls.c (load_register_parameters): For TYPE_TRANSPARENT_AGGR types, use type of their first field instead of type of args[i].tree_value. * gcc.c-torture/compile/pr91001.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr91001.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/calls.c branches/gcc-8-branch/gcc/function.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/91623] [8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:09:57 2019 New Revision: 278574 URL: https://gcc.gnu.org/viewcvs?rev=278574=gcc=rev Log: Backported from mainline 2019-09-01 Jakub Jelinek PR middle-end/91623 * optabs.c (expand_vec_cond_expr): If op0 is a VECTOR_CST and only EQ_EXPR/NE_EXPR is supported, verify that op0 only contains zeros or negative elements and use NE_EXPR instead of LT_EXPR against zero vector. * gcc.target/i386/pr91623.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr91623.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/optabs.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/91401] schedule + dist_schedule clauses rejected on distribute parallel for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91401 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Nov 21 17:08:49 2019 New Revision: 278573 URL: https://gcc.gnu.org/viewcvs?rev=278573=gcc=rev Log: Backported from mainline 2019-08-09 Jakub Jelinek PR c/91401 * c-parser.c (c_parser_omp_clause_dist_schedule): Fix up typos in the check_no_duplicate_clause call. Comment it out, instead emit a warning for duplicate dist_schedule clauses. * parser.c (cp_parser_omp_clause_dist_schedule): Comment out the check_no_duplicate_clause call, instead emit a warning for duplicate dist_schedule clauses. * c-c++-common/gomp/pr91401-1.c: New test. * c-c++-common/gomp/pr91401-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/c-c++-common/gomp/pr91401-1.c branches/gcc-8-branch/gcc/testsuite/c-c++-common/gomp/pr91401-2.c Modified: branches/gcc-8-branch/gcc/c/ChangeLog branches/gcc-8-branch/gcc/c/c-parser.c branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/parser.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/92618] [10 Regression] error: type mismatch in binary expression in reassoc since r273490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92618 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug tree-optimization/92618] [10 Regression] error: type mismatch in binary expression in reassoc since r273490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92618
--- Comment #3 from Jakub Jelinek ---
That optimization seems to ignore completely the involved types.
Consider following testcase instead, where in foo the addition is performed
originally in unsigned long long type and in baz in double type, that reassoc
change happily performs the addition in long long type in both cases.
#if __SIZEOF_LONG_LONG__ == __SIZEOF_DOUBLE__
typedef long long __m128i __attribute__((__may_alias__, __vector_size__(2 *
sizeof (long long;
unsigned long long b[4];
__m128i bar (void);
double e[4];
void
foo (unsigned long long *x)
{
__m128i c = bar ();
__m128i d = bar ();
*(__m128i *) [0] = c;
*(__m128i *) [2] = d;
*x = b[0] + b[1] + b[2] + b[3];
}
void
baz (double *x)
{
__m128i c = bar ();
__m128i d = bar ();
*(__m128i *) [0] = c;
*(__m128i *) [2] = d;
*x = e[0] + e[1] + e[2] + e[3];
}
#endif
[Bug tree-optimization/92618] [10 Regression] error: type mismatch in binary expression in reassoc since r273490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92618
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Testcase in C and with fewer casts, plus portable between -m32/-m64:
typedef long long __m128i __attribute__((__may_alias__, __vector_size__(2 *
sizeof (long long;
void
foo (__m128i *x)
{
__m128i a;
*x = a;
}
void
bar (__m128i *x)
{
foo (x);
foo (x + 1);
}
unsigned long long b[4];
void
baz (long long *x)
{
bar ((__m128i *) b);
*x = b[0] + b[1] + b[2] + b[3];
}
[Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596 rsandifo at gcc dot gnu.org changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #9 from rsandifo at gcc dot gnu.org --- I'll take the second one.
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #17 from Andrew Pinski --- First off internal documentation is not user documentation. Second internal documentation is not always in sync with the code. In this case it seems like it is not fully. Basically BB reordering does the full unfactoring these days.
[Bug c++/92617] Invalid loop optimization: no exit condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617 --- Comment #6 from Andrew Pinski --- In c++ (unlike C) return from a non void function is undefined even if the return value is not used. In c, only of the return value is used it would be undefined.
[Bug c++/92617] Invalid loop optimization: no exit condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617 --- Comment #7 from Andrew Pinski --- Not you can get a runtime error if you use -fsanitizer=undefined.
[Bug tree-optimization/92618] [10 Regression] error: type mismatch in binary expression in reassoc since r273490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92618 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-21 Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Seen in gdal2 package.
[Bug tree-optimization/92618] New: [10 Regression] error: type mismatch in binary expression in reassoc since r273490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92618
Bug ID: 92618
Summary: [10 Regression] error: type mismatch in binary
expression in reassoc since r273490
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: linkw at gcc dot gnu.org
Target Milestone: ---
I see following ICE:
$ cat ice.C
typedef long long __m128i __attribute__((__vector_size__(16)));
void fn1(__attribute__((__vector_size__(2 * sizeof(long long long *p1) {
__m128i a;
*p1 = a;
}
void fn2(int *p1) {
fn1(reinterpret_cast<__m128i *>(p1));
fn1(reinterpret_cast<__m128i *>(reinterpret_cast(p1) + 16));
}
unsigned long b[4];
void fn3(long ) {
fn2(reinterpret_cast(b));
p1 = b[0] + b[1] + b[2] + b[3];
}
$ gcc ice.C -O2
ice.C: In function ‘void fn3(long int&)’:
ice.C:11:6: error: type mismatch in binary expression
11 | void fn3(long ) {
| ^~~
long unsigned int
long long int
long long int
_3 = _17 + _18;during GIMPLE pass: reassoc
ice.C:11:6: internal compiler error: verify_gimple failed
0x10b6811 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5445
0xf9115f execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1983
0xf91f0e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/86504] vectorization failure for a nest loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #12 from Tamar Christina --- Fixed in GCC 10.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 86504, which changed state. Bug 86504 Summary: vectorization failure for a nest loop https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/60243] IPA is slow on large cgraph tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243 --- Comment #27 from Jan Hubicka --- profile_estimate issue is still here, inliner and early inliner issues seems solved. Seems that ipa_profile just orders the nodes for propagation in wrong way - we propagate from callers to callees while toposorter is for propagation opoposite way. operand_scan seems slow too. Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 1237 kB ( 0%) phase parsing : 6.63 ( 9%) 6.77 ( 77%) 13.41 ( 17%) 655497 kB ( 20%) phase opt and generate : 64.47 ( 91%) 2.07 ( 23%) 66.57 ( 83%) 2603397 kB ( 80%) garbage collection : 0.64 ( 1%) 0.00 ( 0%) 0.65 ( 1%) 0 kB ( 0%) dump files : 0.05 ( 0%) 0.01 ( 0%) 0.04 ( 0%) 0 kB ( 0%) callgraph construction : 0.91 ( 1%) 0.01 ( 0%) 0.83 ( 1%) 399235 kB ( 12%) callgraph optimization : 0.37 ( 1%) 0.00 ( 0%) 0.43 ( 1%) 0 kB ( 0%) callgraph functions expansion : 15.98 ( 22%) 1.20 ( 14%) 17.18 ( 21%) 297309 kB ( 9%) callgraph ipa passes : 40.57 ( 57%) 0.40 ( 5%) 40.99 ( 51%) 617751 kB ( 19%) ipa function summary : 0.14 ( 0%) 0.00 ( 0%) 0.14 ( 0%) 1807 kB ( 0%) ipa dead code removal : 0.22 ( 0%) 0.00 ( 0%) 0.24 ( 0%) 0 kB ( 0%) ipa cp : 0.97 ( 1%) 0.03 ( 0%) 1.03 ( 1%) 327514 kB ( 10%) ipa inlining heuristics: 0.72 ( 1%) 0.00 ( 0%) 0.63 ( 1%) 84183 kB ( 3%) ipa function splitting : 0.02 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) ipa various optimizations : 0.69 ( 1%) 0.20 ( 2%) 0.89 ( 1%) 128398 kB ( 4%) ipa reference : 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) ipa profile: 18.24 ( 26%) 0.00 ( 0%) 18.25 ( 23%) 0 kB ( 0%) ipa pure const : 0.45 ( 1%) 0.00 ( 0%) 0.46 ( 1%) 0 kB ( 0%) ipa icf: 0.17 ( 0%) 0.02 ( 0%) 0.17 ( 0%) 0 kB ( 0%) ipa SRA: 0.21 ( 0%) 0.00 ( 0%) 0.21 ( 0%) 102 kB ( 0%) ipa free inline summary: 0.03 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) cfg cleanup: 0.00 ( 0%) 0.01 ( 0%) 0.02 ( 0%) 0 kB ( 0%) trivially dead code: 0.12 ( 0%) 0.03 ( 0%) 0.12 ( 0%) 0 kB ( 0%) df scan insns : 0.85 ( 1%) 0.14 ( 2%) 1.28 ( 2%) 46 kB ( 0%) df multiple defs : 0.30 ( 0%) 0.06 ( 1%) 0.31 ( 0%) 0 kB ( 0%) df reaching defs : 0.69 ( 1%) 0.05 ( 1%) 0.63 ( 1%) 0 kB ( 0%) df live regs : 0.49 ( 1%) 0.02 ( 0%) 0.57 ( 1%) 0 kB ( 0%) df live regs : 0.19 ( 0%) 0.01 ( 0%) 0.12 ( 0%) 0 kB ( 0%) df must-initialized regs : 0.10 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 0 kB ( 0%) df use-def / def-use chains: 0.44 ( 1%) 0.05 ( 1%) 0.40 ( 1%) 0 kB ( 0%) df reg dead/unused notes : 1.35 ( 2%) 0.09 ( 1%) 1.15 ( 1%) 747 kB ( 0%) register information : 0.16 ( 0%) 0.00 ( 0%) 0.18 ( 0%) 0 kB ( 0%) alias analysis : 0.16 ( 0%) 0.00 ( 0%) 0.11 ( 0%) 436 kB ( 0%) alias stmt walking : 0.49 ( 1%) 0.07 ( 1%) 0.67 ( 1%) 0 kB ( 0%) register scan : 0.04 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) rebuild jump labels: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) preprocessing : 2.37 ( 3%) 2.37 ( 27%) 4.49 ( 6%) 383477 kB ( 12%) lexical analysis : 1.88 ( 3%) 2.13 ( 24%) 4.20 ( 5%) 0 kB ( 0%) parser (global): 0.01 ( 0%) 0.01 ( 0%) 0.03 ( 0%) 1442 kB ( 0%) parser function body : 2.19 ( 3%) 2.26 ( 26%) 4.50 ( 6%) 270577 kB ( 8%) early inlining heuristics : 2.80 ( 4%) 0.03 ( 0%) 2.81 ( 4%) 3076 kB ( 0%) inline parameters : 6.43 ( 9%) 0.14 ( 2%) 6.74 ( 8%) 31127 kB ( 1%) integration: 0.17 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 6789 kB ( 0%) tree gimplify : 1.01 ( 1%) 0.03 ( 0%) 1.15 ( 1%) 610970 kB ( 19%) tree eh: 0.50 ( 1%) 0.03 ( 0%) 0.44 ( 1%) 0 kB ( 0%) tree CFG construction : 3.50 ( 5%) 0.02 ( 0%) 3.74 ( 5%) 628087 kB ( 19%) tree CFG cleanup
[Bug tree-optimization/86504] vectorization failure for a nest loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504 --- Comment #11 from Joel Hutton --- Should be fixed on trunk by r277784
[Bug tree-optimization/86504] vectorization failure for a nest loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504 --- Comment #10 from Joel Hutton --- Should be fixed on trunk
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|hubicka at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #38 from Jan Hubicka --- it is GCC10 but I finally managed to implement the incremental update here. Memory use is about 1.1GB but inliner finishes quite quickly: Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 1237 kB ( 0%) phase parsing : 1.29 ( 2%) 1.24 ( 6%) 2.54 ( 3%) 247897 kB ( 6%) phase lang. deferred : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) phase opt and generate : 56.81 ( 98%) 19.35 ( 94%) 76.27 ( 97%) 3859026 kB ( 94%) garbage collection : 0.84 ( 1%) 0.10 ( 0%) 0.93 ( 1%) 0 kB ( 0%) dump files : 3.28 ( 6%) 1.85 ( 9%) 5.30 ( 7%) 0 kB ( 0%) callgraph construction : 0.70 ( 1%) 0.28 ( 1%) 1.07 ( 1%) 99328 kB ( 2%) callgraph optimization : 1.38 ( 2%) 0.74 ( 4%) 2.03 ( 3%) 1026 kB ( 0%) callgraph functions expansion : 47.27 ( 81%) 15.51 ( 75%) 62.89 ( 80%) 2827825 kB ( 69%) callgraph ipa passes : 8.19 ( 14%) 3.26 ( 16%) 11.45 ( 15%) 709147 kB ( 17%) ipa function summary : 0.34 ( 1%) 0.08 ( 0%) 0.43 ( 1%) 97794 kB ( 2%) ipa dead code removal : 0.25 ( 0%) 0.01 ( 0%) 0.27 ( 0%) 0 kB ( 0%) ipa inheritance graph : 0.01 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) ipa devirtualization : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) ipa cp : 0.23 ( 0%) 0.02 ( 0%) 0.27 ( 0%) 7169 kB ( 0%) ipa inlining heuristics: 0.19 ( 0%) 0.00 ( 0%) 0.22 ( 0%) 0 kB ( 0%) ipa function splitting : 0.02 ( 0%) 0.01 ( 0%) 0.06 ( 0%) 0 kB ( 0%) ipa comdats: 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) ipa various optimizations : 0.06 ( 0%) 0.00 ( 0%) 0.06 ( 0%) 0 kB ( 0%) ipa reference : 0.10 ( 0%) 0.00 ( 0%) 0.11 ( 0%) 0 kB ( 0%) ipa profile: 0.07 ( 0%) 0.00 ( 0%) 0.06 ( 0%) 0 kB ( 0%) ipa pure const : 0.45 ( 1%) 0.15 ( 1%) 0.47 ( 1%) 0 kB ( 0%) ipa icf: 0.22 ( 0%) 0.01 ( 0%) 0.23 ( 0%) 0 kB ( 0%) ipa SRA: 0.13 ( 0%) 0.00 ( 0%) 0.14 ( 0%) 5120 kB ( 0%) ipa free lang data : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) ipa free inline summary: 0.08 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 0 kB ( 0%) cfg construction : 0.07 ( 0%) 0.01 ( 0%) 0.19 ( 0%) 0 kB ( 0%) cfg cleanup: 0.73 ( 1%) 0.23 ( 1%) 0.95 ( 1%) 0 kB ( 0%) trivially dead code: 0.30 ( 1%) 0.06 ( 0%) 0.30 ( 0%) 0 kB ( 0%) df scan insns : 0.81 ( 1%) 0.21 ( 1%) 0.93 ( 1%) 3072 kB ( 0%) df multiple defs : 0.28 ( 0%) 0.06 ( 0%) 0.41 ( 1%) 0 kB ( 0%) df reaching defs : 1.48 ( 3%) 0.20 ( 1%) 1.63 ( 2%) 0 kB ( 0%) df live regs : 1.12 ( 2%) 0.26 ( 1%) 1.33 ( 2%) 0 kB ( 0%) df live regs : 0.51 ( 1%) 0.19 ( 1%) 0.66 ( 1%) 0 kB ( 0%) df must-initialized regs : 0.11 ( 0%) 0.06 ( 0%) 0.14 ( 0%) 0 kB ( 0%) df use-def / def-use chains: 0.36 ( 1%) 0.04 ( 0%) 0.43 ( 1%) 0 kB ( 0%) df reg dead/unused notes : 1.69 ( 3%) 0.20 ( 1%) 1.81 ( 2%) 12288 kB ( 0%) register information : 0.38 ( 1%) 0.04 ( 0%) 0.39 ( 0%) 0 kB ( 0%) alias analysis : 0.82 ( 1%) 0.17 ( 1%) 1.15 ( 1%) 36865 kB ( 1%) alias stmt walking : 0.06 ( 0%) 0.04 ( 0%) 0.07 ( 0%) 0 kB ( 0%) register scan : 0.07 ( 0%) 0.03 ( 0%) 0.11 ( 0%) 0 kB ( 0%) rebuild jump labels: 0.16 ( 0%) 0.06 ( 0%) 0.14 ( 0%) 0 kB ( 0%) preprocessing : 0.39 ( 1%) 0.32 ( 2%) 0.49 ( 1%) 44508 kB ( 1%) lexical analysis : 0.32 ( 1%) 0.39 ( 2%) 0.73 ( 1%) 0 kB ( 0%) parser (global): 0.11 ( 0%) 0.08 ( 0%)
[Bug c++/55135] Segfault of gcc on a big file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #30 from Jan Hubicka --- Reconfirmed that we still take ages to build the testcase (early inliner is still running for me) The early inliner issue here is caused by tree-inline removing individual clones one by one. Each time a clone is removed a new clone becomes a root of the clone tree and it takes long time to update all pointers.
[Bug c++/92450] [10 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in cp_parser_member_declaration, at cp/parser.c:25055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92450 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/92450] [10 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in cp_parser_member_declaration, at cp/parser.c:25055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92450 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Thu Nov 21 15:27:46 2019 New Revision: 278570 URL: https://gcc.gnu.org/viewcvs?rev=278570=gcc=rev Log: PR c++/92450 - ICE with invalid nested name specifier. * parser.c (cp_parser_member_declaration): Don't attempt to print erroneous bit-field diagnostic if grokdeclarator returns error_mark_node. * g++.dg/parse/crash71.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/crash71.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/92158] Missed -Wsign-conversion in C++ when -1 enum converted to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
--- Comment #10 from Jonny Grant ---
C++ 'enum class' gives a nice error for conversion to unsigned.
Example:
enum class E { a = 1 } ;
unsigned i = E::a;
I've asked this before, will just write again so it is on a ticket. I
understand C++ allows implicit conversion of enum's, it would be good to
generate a warning with the following example in C++. So I could make the
conversion explicit
enum E { a = 1 } ;
unsigned i = a;
[Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596 --- Comment #8 from Richard Biener --- Author: rguenth Date: Thu Nov 21 15:01:17 2019 New Revision: 278555 URL: https://gcc.gnu.org/viewcvs?rev=278555=gcc=rev Log: 2019-11-21 Richard Biener PR tree-optimization/92596 * tree-vect-slp.c (vect_build_slp_tree): Fix pasto. * gcc.dg/torture/pr92596-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr92596-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug c++/92617] Invalid loop optimization: no exit condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617 --- Comment #5 from Piotr Seweryn --- Obviously there is no return statement and warning was issued, however endless loop isn't the expected result, don't you agree? And falling-through to the next piece of code is even worse, coze we are falling we random arguments and weird things may happen.
[Bug c++/92617] Invalid loop optimization: no exit condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener --- You miss a return stmt.
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 Kewen Lin changed: What|Removed |Added Attachment #47306|0 |1 is obsolete|| --- Comment #7 from Kewen Lin --- Created attachment 47325 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47325=edit Simplify with VECTOR_UNIT_NONE_P and mode_for_vector Updated as mode_for_vector.
[Bug c++/92617] Invalid loop optimization: no exit condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617 --- Comment #3 from Piotr Seweryn --- Similar problem occurs when -O2 or -O3 is used, there is also an endless loop, however different assembler code is generated. I can also provided appropriate .ii and .s files for O2 and O3 case.
[Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> The second testcase still ICEs though, so investigating that.
Which is more fun. We have group_size == vf == 1 here but V2SI as vectype.
t2.c:17:1: note: Build SLP for _1 = b_2(D) == 0;
t2.c:17:1: note: get vectype for scalar type (group size 2): int
t2.c:17:1: note: vectype: vector(2) int
...
t2.c:17:1: note: Final SLP tree for instance:
t2.c:17:1: note: node 0x3721280 (max_nunits=2)
t2.c:17:1: note:stmt 0 a.n[0] = _4;
t2.c:17:1: note:stmt 1 a.n[1] = _4;
t2.c:17:1: note:children 0x38dc8c0
t2.c:17:1: note: node 0x38dc8c0 (max_nunits=2)
t2.c:17:1: note:stmt 0 _4 = (long int) _1;
t2.c:17:1: note:stmt 1 _4 = (long int) _1;
t2.c:17:1: note:children 0x38dcb10
t2.c:17:1: note: node 0x38dcb10 (max_nunits=2)
t2.c:17:1: note:stmt 0 _1 = b_2(D) == 0;
t2.c:17:1: note:stmt 1 _1 = b_2(D) == 0;
t2.c:17:1: note:children 0x370ef50 0x371de80
t2.c:17:1: note: node (external) 0x370ef50 (max_nunits=1)
t2.c:17:1: note:{ b_2(D), b_2(D) }
t2.c:17:1: note: node (constant) 0x371de80 (max_nunits=1)
t2.c:17:1: note:{ 0, 0 }
t2.c:17:1: note: Build SLP for _1 = b_2(D) == 0;
t2.c:17:1: note: get vectype for scalar type (group size 1): int
t2.c:17:1: note: vectype: vector(1) int
t2.c:17:1: note: nunits = 1
...
t2.c:17:1: note: Final SLP tree for instance:
t2.c:17:1: note: node 0x38e3760 (max_nunits=1)
t2.c:17:1: note:stmt 0 a.n[2] = _4;
t2.c:17:1: note:children 0x38e3710
t2.c:17:1: note: node 0x38e3710 (max_nunits=1)
t2.c:17:1: note:stmt 0 _4 = (long int) _1;
t2.c:17:1: note:children 0x38e36c0
t2.c:17:1: note: node 0x38e36c0 (max_nunits=1)
t2.c:17:1: note:stmt 0 _1 = b_2(D) == 0;
t2.c:17:1: note:children 0x3721340 0x38e3670
t2.c:17:1: note: node (external) 0x3721340 (max_nunits=1)
t2.c:17:1: note:{ b_2(D) }
t2.c:17:1: note: node (constant) 0x38e3670 (max_nunits=1)
t2.c:17:1: note:{ 0 }
shoudn't updating of the shared vector type have failed?
Ah, it gets QImode (boolean_type_node). Isn't that a bug?
Anyway, will continue to dig next week unless somebody beats me to it.
[Bug c++/92617] Invalid loop optimization: no exit condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617 --- Comment #2 from Piotr Seweryn --- Created attachment 47324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47324=edit Assembler file
[Bug c++/92617] Invalid loop optimization: no exit condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617 --- Comment #1 from Piotr Seweryn --- Created attachment 47323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47323=edit Pre-processed file
[Bug c++/92617] New: Invalid loop optimization: no exit condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617
Bug ID: 92617
Summary: Invalid loop optimization: no exit condition
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: piotr.seweryn at gmail dot com
Target Milestone: ---
Created attachment 47322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47322=edit
Compilation process stderr output
Consider the following code:
#include
int parseList()
{
int i;
for (i = 0; i < 3; i++) {
printf("DUPA: %d %d\n", i, i);
}
}
int main(int argc, char **argv)
{
printf("start\n");
parseList();
}
Obviously there is no return statement in parseList function and "no return
statement in function returning non-void" warning was issued.
Command used to compile:
gcc -Wall -Wextra -v -save-temps -O1 test.cpp -otest -lstdc++ 1> log.stdout 2>
log.stderr
Expected result:
3 loop iterations, 4 messages displayed to stdout
Actual result:
endless loop
If we take a closer look at the assembler code (output of objdump -S):
0001145 <_Z9parseListv>:
1145: 48 83 ec 08 sub$0x8,%rsp
1149: ba 00 00 00 00 mov$0x0,%edx
114e: be 00 00 00 00 mov$0x0,%esi
1153: 48 8d 3d aa 0e 00 00lea0xeaa(%rip),%rdi# 2004
<_IO_stdin_used+0x4>
115a: b8 00 00 00 00 mov$0x0,%eax
115f: e8 cc fe ff ff callq 1030
1164: ba 01 00 00 00 mov$0x1,%edx
1169: be 01 00 00 00 mov$0x1,%esi
116e: 48 8d 3d 8f 0e 00 00lea0xe8f(%rip),%rdi# 2004
<_IO_stdin_used+0x4>
1175: b8 00 00 00 00 mov$0x0,%eax
117a: e8 b1 fe ff ff callq 1030
117f: ba 02 00 00 00 mov$0x2,%edx
1184: be 02 00 00 00 mov$0x2,%esi
1189: 48 8d 3d 74 0e 00 00lea0xe74(%rip),%rdi# 2004
<_IO_stdin_used+0x4>
1190: b8 00 00 00 00 mov$0x0,%eax
1195: e8 96 fe ff ff callq 1030
119a :
119a: 48 83 ec 08 sub$0x8,%rsp
119e: 48 8d 3d 6c 0e 00 00lea0xe6c(%rip),%rdi# 2011
<_IO_stdin_used+0x11>
11a5: e8 96 fe ff ff callq 1040
11aa: e8 96 ff ff ff callq 1145 <_Z9parseListv>
11af: 90 nop
There is no return instruction at the end of parseList function, so we will
fall-through to main function, then we will call parseList function and
fall-through again to main and so on.
System specification:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)
Debian 10.1 x86_64, updated to newest version.
Problem occurs when optimization O1 is used.
[Bug inline-asm/92615] [8/9/10 Regression] ICE in extract_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92615 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Target Milestone|--- |8.4
