[Bug middle-end/86575] [7/8 Regression] -Wimplicit-fallthrough affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575 --- Comment #8 from Eric Gallager --- (In reply to Michael Matz from comment #7) > As I stated, it's only fixed in trunk, so it's still a regression in 7 and 8, > as marked in the summary. But you also said you weren't planning on backporting though: (In reply to Michael Matz from comment #5) > Fixed in trunk. Not planning backporting, it's not a very important problem. So, if you're not going to backport to 7 or 8, then, does this bug really need to stay open?
[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593 --- Comment #8 from Eric Gallager --- (In reply to Jerry DeLisle from comment #7) > Author: jvdelisle > Date: Wed Oct 2 02:35:14 2019 > New Revision: 276439 > > URL: https://gcc.gnu.org/viewcvs?rev=276439=gcc=rev > Log: > 2019-10-01 Jerry DeLisle > > PR libfortran/91593 > * io/read.c (read_decimal): Cast constant to size_t to turn off > a bogus warning. > * io/write.c (btoa_big): Use memset in lieu of setting the null > byte in a string buffer to turn off a bogus warning. > > Modified: > trunk/libgfortran/ChangeLog > trunk/libgfortran/io/read.c > trunk/libgfortran/io/write.c Did this fix it?
[Bug c/60591] Report enum conversions as part of Wconversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591 --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > There are several other bugs open like this one, such as bug 78736 This is fixed now. It's probably still worth checking some of the other bugs under its "See Also" section though.
[Bug c++/52763] Warning if compare between enum and non-enum type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-10-19
Ever confirmed|0 |1
--- Comment #11 from Eric Gallager ---
(In reply to Martin Sebor from comment #8)
> Clang warns when an enum object is compared to a constant that's out of the
> most restricted range of the enum's type. The warning is in -Wall. It
> doesn't warn when the object is compared to a constant that doesn't
> correspond to any of the type's enumerators. I can see that being useful to
> some (carefully written) projects but suspect it could be quite noisy for
> many others.
>
> $ cat t.C && clang++ -S -Wall -Wextra t.C
> enum E { NONE = 0, ONE = 1, TWO = 2 };
>
> bool f (E e)
> {
> return e == 3; // no warning here
> }
>
> bool g (E e)
> {
> return e == 4;
> }
>
>
> t.C:10:12: warning: comparison of constant 4 with expression of type 'E' is
> always false [-Wtautological-constant-out-of-range-compare]
> return e == 4;
> ~ ^ ~
> 1 warning generated.
I combined this testcase with the testcase in the original report and can
confirm that there is still no warning even after the addition of
-Wenum-conversion in bug 78736 (when compiling with either the C or C++
frontends)
$ cat 52763.cc
#ifdef __cplusplus
# include
#else
# include
#endif /* __cplusplus */
typedef enum {
NONE = 0, ONE = 1, TWO = 2
} tEnumType;
bool f(tEnumType e)
{
return (e == 3); // no warning here
}
bool g(tEnumType e)
{
return (e == 4);
}
int main(void)
{
tEnumType var1 = TWO;
//Warn here, because we compare an enum to a non-enum type (1)
//should be 'if (var1 == ONE)'
if (var1 == 1)
return f(NONE);
else
return g(ONE);
}
$ /usr/local/bin/g++ -c -S -Wall -Wextra -Wconversion -pedantic 52763.cc
$ /usr/local/bin/gcc -c -S -Wall -Wextra -Wconversion -pedantic
-Wenum-conversion -Wc++-compat -x c 52763.cc
$
(no output)
[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #18 from Eric Gallager ---
(In reply to Jonny Grant from comment #17)
> Hello Joseph
>
> This was the test case I created. There isn't any warning output when 'a_t'
> is converted to 'int'. Or even if it was converted to an 'unsigned int'
>
> https://gcc.gnu.org/ml/gcc-help/2019-07/msg00014.html
>
>
> //-O2 -Wall -Wextra -Wconversion -Werror
>
> #include
> typedef enum
> {
> a = -1
> } a_t;
>
> a_t f()
> {
> return a;
> }
>
> int main()
> {
> int b = f();
> return b;
> }
While it's true that g++ prints no warnings for that testcase, I think that's
material for a separate bug. The original bug here was just to add
-Wenum-conversion for the C front-end, which has now been done, so I'm closing
this. Feel free to open new bugs for any missed cases.
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 78736, which changed state. Bug 78736 Summary: enum warnings in GCC (request for -Wenum-conversion to be added) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/7654] warn if an enum is being assigned a non enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7654
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #12 from Eric Gallager ---
(In reply to Martin Sebor from comment #11)
> I'll confirm this ancient request.
>
> Bug 78736 asks for something similar, and I'm working on enhancing the
> solution there even further (to diagnose assigning constants that don't have
> a corresponding enumerator in the destination type). I'll add that on the
> following slightly modified test case Clang issues the warnings below:
>
> $ cat t.C && clang -S -Wall -Wextra -Weverything -xc t.C
> void f (int i)
> {
> enum e1 { e1a, e1b };
> enum e1 e1v;
> enum e2 { e2a, e2b };
> enum e2 e2v;
>
> e1v = 1; // no warning
> e1v = 3; // warning
> e1v = e1a; // ok
> e2v = e1v; // warning
> i = e1v; // ok I guess
> e2v = i; // warning
> }
> t.C:9:9: warning: integer constant not in range of enumerated type 'enum e1'
> [-Wassign-enum]
> e1v = 3; // warning
> ^
> t.C:11:9: warning: implicit conversion from enumeration type 'enum e1' to
> different enumeration type 'enum e2' [-Wenum-conversion]
> e2v = e1v; // warning
> ~ ^~~
> t.C:13:9: warning: implicit conversion changes signedness: 'int' to 'enum e2'
> [-Wsign-conversion]
> e2v = i; // warning
> ~ ^
> t.C:1:6: warning: no previous prototype for function 'f'
> [-Wmissing-prototypes]
> void f (int i)
> ^
> 4 warnings
gcc now prints:
$ /usr/local/bin/gcc -c -S -Wall -Wextra -Wconversion -Wsign-conversion
-Wmissing-prototypes -pedantic -xc 7654.c
7654.c:1:6: warning: no previous prototype for 'f' [-Wmissing-prototypes]
1 | void f (int i)
| ^
7654.c: In function 'f':
7654.c:11:6: warning: implicit conversion from 'enum e1' to 'enum e2'
[-Wenum-conversion]
11 | e2v = e1v; // warning
| ^
7654.c:6:10: warning: variable 'e2v' set but not used
[-Wunused-but-set-variable]
6 | enum e2 e2v;
| ^~~
$
so, gcc has -Wenum-conversion now, but it is still missing warnings from
-Wassign-enum and -Wsign-conversion on this testcase.
[Bug objc/77404] Add Wobjc-root-class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77404 Eric Gallager changed: What|Removed |Added CC||mikestump at comcast dot net --- Comment #5 from Eric Gallager --- cc-ing other objc maintainer
[Bug target/82240] i386.md & -Wlogical-op in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82240 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-19 Ever confirmed|0 |1 --- Comment #12 from Eric Gallager --- (In reply to Eric Gallager from comment #10) > *** Bug 83863 has been marked as a duplicate of this bug. *** Taking the dup as confirmation
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 --- Comment #12 from Eric Gallager --- (In reply to Jonathan Wakely from comment #11) > (In reply to Eric Gallager from comment #10) > > If this is becoming the meta-bug for all warnings that affect codegen, then > > I'd like to add bug 61579 (-Wwrite-strings) as at least semi-related... (not > > sure if toggling it causes miscompares though) > > That one is *supposed* to affect codegen (so maybe it should be a -f option > instead). hm, I could've sworn there was already an -f option with a similar name, but after checking the manual I can't seem to find it after all, so... I guess making it an -f option could work.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #42 from Eric Gallager --- (In reply to Rich Felker from comment #41) > > Josef Wolf mentioned that he ran into this on the gcc-help mailing list > > here: https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html > > I don't think that's an instance of this issue. Well ok, maybe not THAT message specifically; see the rest of the thread though. > It's normal/expected that __builtin_foo compiles to a call to foo in the > absence of factors that lead to it being optimized to something simpler. > The idiom of using __builtin_foo to get the compiler to emit an optimized > implementation of foo for you, to serve as the public definition of foo, is > simply not valid. That's kinda a shame because it would be nice to be able to > do it for lots of math library functions, but of course in order for this to > be > able to work gcc would have to promise it can generate code for the operation > for all targets, which is unlikely to be reasonable.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Oleg Endo changed: What|Removed |Added Target|sh*-*-* | --- Comment #12 from Oleg Endo --- (In reply to Rich Felker from comment #8) > This issue report is specific to target sh*-*-* I put that in the target field of the PR initially, but I also wrote in the description above that this looks like a target independent issue. So removing the target field now, to be clear. I don't think anybody should have to deal with that on any target in the backend. It should be handled by earlier stages of compilation, if at all. The prerequisite for this optimization is that the integer variable type can be represented by the floating point type of the comparison exactly. If that's the case, there should be no need to touch anything in fenv. If the floating point constant can't be represented exactly as specified by the code (e.g. comment #3 -- 16777216 becomes 16777217), would that still require setting the inexact flag in fenv? (I don't think so)
[Bug tree-optimization/92157] [10 Regression] incorrect strcmp() == 0 result for unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Martin Sebor --- Fixed via r277194.
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 92157, which changed state. Bug 92157 Summary: [10 Regression] incorrect strcmp() == 0 result for unknown strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/92155] strlen(a) not folded after memset(a, 0, sizeof a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155 --- Comment #4 from Martin Sebor --- Author: msebor Date: Fri Oct 18 22:26:39 2019 New Revision: 277194 URL: https://gcc.gnu.org/viewcvs?rev=277194=gcc=rev Log: PR tree-optimization/92157 - incorrect strcmp() == 0 result for unknown strings gcc/testsuite/ChangeLog: PR tree-optimization/92157 * gcc.dg/strlenopt-69.c: Disable test failing due to PR 92155. * gcc.dg/strlenopt-87.c: New test. gcc/ChangeLog: PR tree-optimization/92157 * tree-ssa-strlen.c (handle_builtin_string_cmp): Be prepared for compute_string_length to return a negative result. Added: trunk/gcc/testsuite/gcc.dg/strlenopt-87.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt-69.c trunk/gcc/tree-ssa-strlen.c
[Bug tree-optimization/92157] [10 Regression] incorrect strcmp() == 0 result for unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157 --- Comment #2 from Martin Sebor --- Author: msebor Date: Fri Oct 18 22:26:39 2019 New Revision: 277194 URL: https://gcc.gnu.org/viewcvs?rev=277194=gcc=rev Log: PR tree-optimization/92157 - incorrect strcmp() == 0 result for unknown strings gcc/testsuite/ChangeLog: PR tree-optimization/92157 * gcc.dg/strlenopt-69.c: Disable test failing due to PR 92155. * gcc.dg/strlenopt-87.c: New test. gcc/ChangeLog: PR tree-optimization/92157 * tree-ssa-strlen.c (handle_builtin_string_cmp): Be prepared for compute_string_length to return a negative result. Added: trunk/gcc/testsuite/gcc.dg/strlenopt-87.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt-69.c trunk/gcc/tree-ssa-strlen.c
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #25 from Jakub Jelinek --- The define_insn part of define_insn_and_split needs constraints if it is meant to match during or after reload, the patterns are just written with the assumption that they are split before reload. At least that is my understanding of them.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #24 from Segher Boessenkool --- A dumb question I'm sure, but I don't see it: if the rest of your define_insn doesn't need constraints, why would the match_scratch need some? (A define_split never uses constraints).
[Bug tree-optimization/92155] strlen(a) not folded after memset(a, 0, sizeof a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #3 from Martin Sebor ---
Actually, the memcpy is transformed to MEM_REF and the strlen pass knows how to
deal with a subset of those (small powers of 2). What it doesn't know how to
do yet is deal with other sizes like in the test case below:
extern char a5[5];
int g (void)
{
__builtin_memcpy (a5, (char[sizeof a5]){ }, sizeof a5);
return __builtin_strlen (a5);
}
which results in
D.1933 = {};
MEM [(char * {ref-all})] = MEM
[(char * {ref-all})];
_1 = __builtin_strlen ();
and that's not folded yet either. Handling it is among the outstanding
optimizations mentioned in pr92128.
[Bug tree-optimization/92155] strlen(a) not folded after memset(a, 0, sizeof a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #2 from Martin Sebor ---
The inequality (__builtin_strlen (a4) != 0) is folded into (a4[0] != 0) very
early on during Gimplification so the strlen pass never sees it.
What the strlen pass should be able to do is fold strlen(a4) below to zero:
int g (void)
{
__builtin_memset (a4, 0, sizeof a4);
return __builtin_strlen (a4); // not folded
}
But handle_builtin_memset doesn't have the logic. memcpy does so when the
above is change to the below it works:
int g (void)
{
__builtin_memcpy (a4, (char[sizeof a4]){ }, sizeof a4);
return __builtin_strlen (a4); // folded to zero
}
[Bug tree-optimization/92155] strlen(a) not folded after memset(a, 0, sizeof a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
CC||prathamesh3492 at gcc dot
gnu.org
--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Hi Martin,
Just wondering if it's necessary for 3rd arg to be sizeof ?
IIUC memset (a, 0, n) for valid n, should result in strlen(a) equal to 0 ?
Btw, it seems, the comparison is folded to 0 in following case:
extern char a4[4];
void g ()
{
__builtin_memset (a4, 0, sizeof a4);
if (__builtin_strlen (a4) != 0)
__builtin_abort ();
}
.optimized dump shows only call to memset.
Thanks,
Prathamesh
[Bug tree-optimization/92157] [10 Regression] incorrect strcmp() == 0 result for unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||wrong-code Last reconfirmed||2019-10-18 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Blocks||83819 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92155 Ever confirmed|0 |1 Summary|incorrect strcmp() == 0 |[10 Regression] incorrect |result for unknown strings |strcmp() == 0 result for ||unknown strings --- Comment #1 from Martin Sebor --- The test for the optimization, strlenopt-69.c, actually passes because of the bug, and also because of the missing memset optimization reported in pr92155. The test_empty_string() function calls memset to zero out two arrays, a and b, and expects strcmp(a, b) == 0 to be folded to true. It is folded, but not because the strlen pass knows the strings are the same (the missing optimization), but because of this bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/92157] New: incorrect strcmp() == 0 result for unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
Bug ID: 92157
Summary: incorrect strcmp() == 0 result for unknown strings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The strcmp optimization checked in r276773 doesn't handle the following case
correctly, causing regressions in the arj package.
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
char a[3];
__attribute__ ((noipa)) int f (const char *s)
{
int n = __builtin_strlen (s);
if (__builtin_strcmp (s, a) == 0)
__builtin_abort ();
return n;
}
int main (void)
{
a[0] = '1';
f ("");
}
;; Function f (f, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=1)
__attribute__((noipa, noinline, noclone, no_icf))
f (const char * s)
{
[count: 0]:
__builtin_abort ();
}
;; Function main (main, funcdef_no=1, decl_uid=1935, cgraph_uid=2,
symbol_order=2) (executed once)
main ()
{
[local count: 1073741824]:
a[0] = 49;
f ("");
return 0;
}
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #23 from Jakub Jelinek --- (In reply to Segher Boessenkool from comment #22) > Hrm, I don't see how this is nicer than just adding a scratch in the > pattern? What makes that a worse option? Most of the patterns don't have constraints and don't want to deal with that. See the ugliness I had to play with the enabled attribute in the earlier version of the patch to deal properly with the constraints. Many of them actually don't create any pseudos, just want to be matched only before reload, split there and not match afterwards.
[Bug libstdc++/92156] New: Cannot in-place construct std::any with std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
Bug ID: 92156
Summary: Cannot in-place construct std::any with std::any
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
GCC (and clang, when using libstdc++) claim that the following program is
ill-formed when compiled with "-std=c++17":
#include
int main() {
auto a = std::any(std::in_place_type, 5);
}
[end code]
Both clang with libc++ and MSVC accept this program.
On Compiler Explorer: https://godbolt.org/z/ckzMsg .
The standard says that this is correct. Under
http://eel.is/c++draft/any.cons#itemdecl:5 , the only requirements are that T
be copy-constructible and constructible from the in-place args. std::any is
copy-constructible and constructible from int, so this program should be
well-formed.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #22 from Segher Boessenkool --- Hrm, I don't see how this is nicer than just adding a scratch in the pattern? What makes that a worse option?
[Bug tree-optimization/92155] New: strlen(a) not folded after memset(a, 0, sizeof a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
Bug ID: 92155
Summary: strlen(a) not folded after memset(a, 0, sizeof a)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Now that GCC unrolls memset-like loops with small numbers of iterations
(pr91975) and transforms some of them into MEM_REF, the strlen pass can also
determine the lengths of zeroed-out arrays to be zero. This can be seen in
function f below.
But GCC doesn't yet transform memset calls into the equivalent MEM_REFs, and
the strlen pass for some reason can't figure out that the length of an array
that's been zeroed-out by memset is also zero. This missed optimization can be
seen in function g below.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
extern char a4[4];
extern char b4[4];
void f (void)
{
for (int i = 0; i != sizeof a4; ++i)
a4[i] = 0;
for (int i = 0; i != sizeof b4; ++i)
b4[i] = 0;
if (__builtin_strlen (a4) != __builtin_strlen (b4))
__builtin_abort ();
}
void g (void)
{
__builtin_memset (a4, 0, sizeof a4);
__builtin_memset (b4, 0, sizeof b4);
if (__builtin_strlen (a4) != __builtin_strlen (b4))
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)
f ()
{
[local count: 214748369]:
MEM [(char *)] = 0;
MEM [(char *)] = 0;
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1943, cgraph_uid=2, symbol_order=1)
g ()
{
long unsigned int _1;
long unsigned int _2;
[local count: 1073741824]:
__builtin_memset (, 0, 4);
__builtin_memset (, 0, 4);
_1 = __builtin_strlen ();
_2 = __builtin_strlen ();
if (_1 != _2)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
[Bug debug/91929] missing inline subroutine information in build using sin/cos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929
Dmitry G. Dyachenko changed:
What|Removed |Added
CC||dimhen at gmail dot com
--- Comment #12 from Dmitry G. Dyachenko ---
I see new warnings -Wuninitialized and -Wmaybe-uninitialized after r276993
r276992 no warnings
r276993 warnings
$ cat x_3.i
int *a;
int b, d;
int g() {
int *c;
int e[6];
int f = 1;
if (0)
goto cd;
c = 0;
for (; d; d++)
*e = 1 ^ *(c + 1);
if (f)
for (b = 0;;)
a[0] = e[b];
cd:
return 0;
}
$ ~/arch-gcc/gcc_276993/bin/gcc -fpreprocessed -O2 -Wall -c x_3.i
x_3.i: In function ‘g’:
x_3.i:15:15: warning: ‘e[0]’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
15 | a[0] = e[b];
| ~^~~
$ cat x.i
typedef struct {
int a[0];
} c;
typedef struct {
c d;
} * e;
e a;
void f(void);
void f() {
int c[1];
for (;;) {
unsigned long d[0];
int b, g, h = b = h;
unsigned long *e = d;
for (; g; ++g)
e[g] = 0;
*a->d.a = *c;
}
}
$ ~/arch-gcc/gcc_276993/bin/gcc -fpreprocessed -O2 -Wall -c x.i
x.i: In function ‘f’:
x.i:17:13: warning: ‘c[0]’ is used uninitialized in this function
[-Wuninitialized]
17 | *a->d.a = *c;
| ^~~~
[Bug fortran/69455] [7/8/9/10 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #20 from kargl at gcc dot gnu.org --- Fixed on all open branches and trunk.
[Bug fortran/69455] [7/8/9/10 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455 --- Comment #19 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 18 19:26:22 2019 New Revision: 277193 URL: https://gcc.gnu.org/viewcvs?rev=277193=gcc=rev Log: 2019-10-18 Steven G. Kargl PR fortran/69455 * trans-decl.c (generate_local_decl): Avoid misconstructed intrinsic modules in a BLOCK construct. 2019-10-18 Steven G. Kargl PR fortran/69455 * gfortran.dg/pr69455_1.f90: New test. * gfortran.dg/pr69455_2.f90: Ditto. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr69455_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr69455_2.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-decl.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
(ARM) Wrong conditional codes when paired with tst instruction
The following C code:
unsigned int wrong(unsigned int n){
return (n%2) ? 0 : 42;
}
should return 42 when n is odd and 0 when n is even.
But ARM gcc 8.2 with -O3 produces following assembly:
tst r0, #1
moveq r0, #42
movne r0, #0
bx lr
tst r0,#1 sets Z=1 iff r0 is even, and moveq r0,#42 executes iff Z=1,
therefore
it sets r0 to 42 when r0 is even, which is wrong given the C code above (
it should return 0 ).
[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 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #11 from Harald van Dijk --- (In reply to Rich Felker from comment #10) > On this particular target, and on every target of any modern > relevance, (float)16777217 has well-defined behavior. That was exactly the point of my original comment. I do not understand why you took issue with it.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #10 from Rich Felker --- GCC can choose the behavior for any undefined behavior it wants, and GCC absolutely can make transformations based on behaviors it guarantees or that Annex F guarantees on targets for which it implements the requirements of Annex F. On this particular target, and on every target of any modern relevance, (float)16777217 has well-defined behavior. On ones with floating point environment (most/all hardfloat), it has side effects (inexact), so can't be elided without the flags to make gcc ignore those side effects.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #9 from Harald van Dijk --- (In reply to Rich Felker from comment #8) > So arguments about generality to non-Annex-F C > environments are not relevant to the topic here. The comment it was a reply to suggested (possibly unintentionally) that evaluating (float)16777217 would have undefined behaviour if 16777217 could not be represented by float. A clarification that no, the standard says it only has undefined behaviour if it is out of float's range, so GCC cannot optimise on the assumption that such conversions do not happen, is absolutely relevant to the topic here.
[Bug fortran/69455] [7/8/9/10 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455 --- Comment #18 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 18 18:18:34 2019 New Revision: 277161 URL: https://gcc.gnu.org/viewcvs?rev=277161=gcc=rev Log: 2019-10-18 Steven G. Kargl PR fortran/69455 * trans-decl.c (generate_local_decl): Avoid misconstructed intrinsic modules in a BLOCK construct. 2019-10-18 Steven G. Kargl PR fortran/69455 * gfortran.dg/pr69455_1.f90: New test. * gfortran.dg/pr69455_2.f90: Ditto. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr69455_1.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr69455_2.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-decl.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #8 from Rich Felker --- > Floating point types are not guaranteed to support infinity by the C standard Annex F (IEEE 754 alignment) does guarantee it, and GCC aims to implement this. This issue report is specific to target sh*-*-* which uses either softfloat with IEEE types and semantics or SH4 hardfloat which has IEEE types and semantics. So arguments about generality to non-Annex-F C environments are not relevant to the topic here.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #7 from Harald van Dijk --- (In reply to Rich Felker from comment #6) > > Only if the int is out of float's range. > > float's range is [-INF,INF] (endpoints included). There is no such thing as > "out of float's range". Floating point types are not guaranteed to support infinity by the C standard, and checking GCC sources, it appears to support at least one representation without infinities (VAX).
[Bug fortran/69455] [7/8/9/10 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455 --- Comment #17 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 18 17:59:32 2019 New Revision: 277160 URL: https://gcc.gnu.org/viewcvs?rev=277160=gcc=rev Log: 2019-10-18 Steven G. Kargl PR fortran/69455 * trans-decl.c (generate_local_decl): Avoid misconstructed intrinsic modules in a BLOCK construct. 2019-10-18 Steven G. Kargl PR fortran/69455 * gfortran.dg/pr69455_1.f90: New test. * gfortran.dg/pr69455_2.f90: Ditto. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr69455_1.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr69455_2.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/trans-decl.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/69455] [7/8/9/10 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455 --- Comment #16 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 18 17:27:06 2019 New Revision: 277158 URL: https://gcc.gnu.org/viewcvs?rev=277158=gcc=rev Log: 2019-10-18 Steven G. Kargl PR fortran/69455 * trans-decl.c (generate_local_decl): Avoid misconstructed intrinsic modules in a BLOCK construct. 2019-10-18 Steven G. Kargl PR fortran/69455 * gfortran.dg/pr69455_1.f90: New test. * gfortran.dg/pr69455_2.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pr69455_1.f90 trunk/gcc/testsuite/gfortran.dg/pr69455_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug target/92149] Enefficient x86_64 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Most likely dup of PR92038, which you've already filed yourself.
[Bug middle-end/92153] [10 Regression] ICE / segmentation fault, use-after-free at gcc/ggc-page.c:1159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Should be fixed now, thanks for the report. Most developers test GCC on hosts that do support mmap and thus this went unnoticed for a few days.
[Bug middle-end/92153] [10 Regression] ICE / segmentation fault, use-after-free at gcc/ggc-page.c:1159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Fri Oct 18 17:18:21 2019 New Revision: 277157 URL: https://gcc.gnu.org/viewcvs?rev=277157=gcc=rev Log: PR middle-end/92153 * ggc-page.c (release_pages): Read g->alloc_size before free rather than after it. Modified: trunk/gcc/ChangeLog trunk/gcc/ggc-page.c
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #41 from Rich Felker --- > Josef Wolf mentioned that he ran into this on the gcc-help mailing list here: > https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html I don't think that's an instance of this issue. It's normal/expected that __builtin_foo compiles to a call to foo in the absence of factors that lead to it being optimized to something simpler. The idiom of using __builtin_foo to get the compiler to emit an optimized implementation of foo for you, to serve as the public definition of foo, is simply not valid. That's kinda a shame because it would be nice to be able to do it for lots of math library functions, but of course in order for this to be able to work gcc would have to promise it can generate code for the operation for all targets, which is unlikely to be reasonable.
[Bug middle-end/92153] [10 Regression] ICE / segmentation fault, use-after-free at gcc/ggc-page.c:1159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |10.0
[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154 --- Comment #1 from Jakub Jelinek --- If it has landed upstream already, please post the backport of it to gcc-patches.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #40 from Eric Gallager --- Josef Wolf mentioned that he ran into this on the gcc-help mailing list here: https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #21 from Jakub Jelinek --- Created attachment 47069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47069=edit gcc10-prereload-splitters.patch Ah, apparently we already have for ~ 2 years a property to handle this safely. So perhaps following incremental (so far completely untested) patch? It unfortunately requires the two generic changes, the alternative would be to add a helper function somewhere in i386*.c which would return can_create_pseudo_p () && !(cfun->curr_properties & PROP_rtl_split_insns); declare it in i386-protos.h and just use it in config/i386/*.md instead. Any preferences? From maintainance POV, it might be cleaner to have the wrapper, but then the question is what is the best name for it.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #20 from Segher Boessenkool ---
Ah, okay. So it is either one or two insns (zero can not be handled, but you
can do a noop, a move of a reg to itself, and that will be optimised away just
fine). Three insns is not something combine ever handles at all: it's always
{2,3,4}->{1,2}.
Since some years new pseudos *can* be created during combine, but there are
various problems with that still.
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 --- Comment #19 from Jakub Jelinek --- Created attachment 47068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47068=edit gcc10-pr90231.patch Untested implementation of what I wrote above. The difference on the testcase at -O2 -g is: [local count: 955630224]: # base_17 = PHI # ivtmp.11_20 = PHI - # DEBUG i => NULL + # DEBUG i => (int) ((ivtmp.11_20 - (unsigned long) dst_10(D)) /[ex] 4) # DEBUG base => base_17 # DEBUG BEGIN_STMT _4 = (void *) ivtmp.11_20; MEM[base: _4, offset: 0B] = base_17; # DEBUG BEGIN_STMT - # DEBUG D#1 => NULL + # DEBUG D#1 => (int) ((ivtmp.11_20 - (unsigned long) dst_10(D)) /[ex] 4) + 1 # DEBUG i => D#1 base_13 = base_17 + 15; # DEBUG i => D#1 and in the debugger I can actually see correct i values.
[Bug tree-optimization/60540] Don't convert int to float when comparing int with float (double) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #6 from Rich Felker --- > Only if the int is out of float's range. float's range is [-INF,INF] (endpoints included). There is no such thing as "out of float's range".
[Bug target/12306] GOT pointer (r12) reloaded unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12306 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #8 from Rich Felker --- I think this should be closed as not a bug. There is no contract that, on function entry, the r12 register contain the callee's GOT pointer. Rather it contains the caller's GOT pointer, and the two will only be equal if both reside in the same DSO. (Note that PowerPC64 ELFv2 ABI goes to great lengths to optimize this case with "local entry point" and fancy ABI contract for how the GOT pointer save/load can be elided. I'm not sure the benefits are well-documented though.)
[Bug sanitizer/92154] New: new glibc breaks arm bootstrap due to libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154 Bug ID: 92154 Summary: new glibc breaks arm bootstrap due to libsanitizer Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Target: arm-none-linux-gnueabihf Glibc has recently introduced changes to the mode field in ipc_perm in commit 2f959dfe849e0646e27403f2e4091536496ac0f0. For Arm this means that the mode field no longer has the same size. This causes an assert failure against libsanitizer's internal copy of ipc_perm. Since this change can't be easily detected. I fixed this upstream in https://reviews.llvm.org/D69104. Can the libsanitizer be synched with upstream?
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #19 from Uroš Bizjak --- (In reply to Segher Boessenkool from comment #18) > (In reply to Uroš Bizjak from comment #15) > > Is it possible to lift the limitation from the combine pass, where the > > combine tries to split the insn, but expects exactly two new insn patterns > > to be generated. From the docs: > > > > --q-- > > When the combiner phase tries to split an insn pattern, it is always > > the case that the pattern is _not_ matched by any 'define_insn'. The > > combiner pass first tries to split a single 'set' expression and then > > the same 'set' expression inside a 'parallel', but followed by a > > 'clobber' of a pseudo-reg to use as a scratch register. In these cases, > > the combiner expects exactly two new insn patterns to be generated. It > > will verify that these patterns match some 'define_insn' definitions, so > > you need not do this test in the 'define_split' (of course, there is no > > point in writing a 'define_split' that will never produce insns that > > match). > > --/q-- > > > > Many define_and_split insns in i386.md that use can_create_pseudo_p have > > this unwanted condition in their insn condition just because of the > > mentioned limitation. > > What unwanted condition? What limitation? "unwanted condition" refers to the usage of can_create_pseudo_p in the insn condition. "Limitation" refers to "the combiner expects exactly two new insn patterns to be generated".
[Bug middle-end/92153] New: [10 Regression] ICE / segmentation fault, use-after-free at gcc/ggc-page.c:1159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153 Bug ID: 92153 Summary: [10 Regression] ICE / segmentation fault, use-after-free at gcc/ggc-page.c:1159 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: GC Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: i686-w64-mingw32 x86_64-w64-mingw32 Target: aarch64-none-elf Hi. I suspect that the previous ggc-page commit [1] accidentally created an use-after-free, which will be triggered at least on *-w64-mingw32 hosts. On my systems this is super easy to reproduce when using C++ frontend, C frontend requires orders of magnitude larger input files. I tried disabling any security measures (such as ASLR) and tried this on multiple Windows 10 1903 machines. (The input is not important here, just that release_pages() is called.) $ cat ggc-pagecrash.cpp #include $ g++ -O0 ggc-pagecrash.cpp -wrapper gdb,--args Thread 1 received signal SIGSEGV, Segmentation fault. release_pages () at /gcc/gcc/ggc-page.c:1159 (gdb) bt #0 release_pages () at /gcc/gcc/ggc-page.c:1159 #1 release_pages () at /gcc/gcc/ggc-page.c:1016 #2 0x0069f113 in ggc_collect () at /gcc/gcc/ggc-page.c:2205 (The rest of the stack frames omitted.) gcc/ggc-page.c: 1158 free (g->allocation); 1159 n1 += g->alloc_size; // <-- this line was added I'm not claiming that I would fully understand the page allocation code, but I presume `g->allocation' does reference itself to some extent. At least this is what I'm seeing on one of my systems: 862 allocation = XNEWVEC (char, alloc_size); // allocation=0x1e49b040, alloc_size=2101247, ... 893 group->allocation = allocation; // group=0x1e49bfe0, and, indeed, later on: 1158 free (g->allocation); // allocation=0x1e49b040, 1159 n1 += g->alloc_size; // g=0x1e49bfe0 -> SIGSEGV. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=474507cc277c500e580003f45ed91130adc0bde3
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #18 from Segher Boessenkool --- (In reply to Uroš Bizjak from comment #15) > Is it possible to lift the limitation from the combine pass, where the > combine tries to split the insn, but expects exactly two new insn patterns > to be generated. From the docs: > > --q-- > When the combiner phase tries to split an insn pattern, it is always > the case that the pattern is _not_ matched by any 'define_insn'. The > combiner pass first tries to split a single 'set' expression and then > the same 'set' expression inside a 'parallel', but followed by a > 'clobber' of a pseudo-reg to use as a scratch register. In these cases, > the combiner expects exactly two new insn patterns to be generated. It > will verify that these patterns match some 'define_insn' definitions, so > you need not do this test in the 'define_split' (of course, there is no > point in writing a 'define_split' that will never produce insns that > match). > --/q-- > > Many define_and_split insns in i386.md that use can_create_pseudo_p have > this unwanted condition in their insn condition just because of the > mentioned limitation. What unwanted condition? What limitation? From combine.c: /* If we were combining three insns and the result is a simple SET with no ASM_OPERANDS that wasn't recognized, try to split it into two insns. There are two ways to do this. It can be split using a machine-specific method (like when you have an addition of a large constant) or by combine in the function find_split_point. */ /* See if the MD file can split NEWPAT. If it can't, see if letting it use I2DEST as a scratch register will help. In the latter case, convert I2DEST to the mode of the source of NEWPAT if we can. */ /* ??? Reusing i2dest without resetting the reg_stat entry for it (temporarily, until we are committed to this instruction combination) does not work: for example, any call to nonzero_bits on the register (from a splitter in the MD file, for example) will get the old information, which is invalid. Since nowadays we can create registers during combine just fine, we should just create a new one here, not reuse i2dest. */ Exactly two new insns... Exactly one is also okay. I'll fix the docs.
[Bug other/92152] [10 Regression] Wring code (Resurrection of PR53663)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152 --- Comment #1 from Georg-Johann Lay --- configure: Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-10 --disable-shared --disable-nls --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld --enable-checking=release --enable-languages=c,c++ --with-long-double64 --with-fixed-point=no --disable-gcov Thread model: single Supported LTO compression algorithms: zlib gcc version 10.0.0 20191017 (experimental) (GCC)
[Bug other/92152] New: [10 Regression] Wring code (Resurrection of PR53663)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152 Bug ID: 92152 Summary: [10 Regression] Wring code (Resurrection of PR53663) Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Target: avr The following test case from GCC testsuite runs into abort. https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/torture/pr53663-2.c?view=markup == compile == $ avr-gcc pr53663-2.c -Os -dp -S the generated asm code for main is: main: sts v+1,__zero_reg__ ; 5 [c=4 l=4] *movhi/3 sts v,__zero_reg__ rcall abort ; 6 [c=0 l=1] call_insn/1 i.e. it always calls abort.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #17 from Jakub Jelinek ---
I've tried to change the patch to use define_split instead of
define_insn_and_split, with all of them changed, it creates worse code for
f8/f12/f15 (the last one is expected, because we split into 3 instructions
instead of two), while if I change only the *{add,sub}3_{eq,ne}
define_insn_and_split into define_split and keep the others, those 3 functions
are fixed again, but f5/f6/f7/f9/f10/f11/f13/f14 result in worse code.
[Bug fortran/91941] [8/9/10 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7336
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91941 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-18 Ever confirmed|0 |1
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #16 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #13) > Created attachment 47067 [details] > gcc10-pr92140.patch > > So what about this version then? I've changed back a couple of > to nonimmediate_operand and removed corresponding > force_reg, because it would be in spots where the there is already one > possible immediate which would be in operands[2] rather than operands[1], > changed the eq/ne_0_operator to the define_special_predicate you've > suggested and added testcase coverage. LGTM.
[Bug fortran/91941] [8/9/10 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7336
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91941
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus ---
The crash is due to expr->ts.u.cl->length == NULL for 'adjustl(x)' – which
fails in gfc_conv_expr_descriptor (see backtrace). Changing the condition to
call get_array_charlen() instead of dereferrencing expr->ts.u.cl->length, it
just moves the segfault to that function.
If gfc_conv_intrinsic_adjust is directly called (w/o the 'associate' block), it
takes care of obtaining the string length.
With the associate block, it calls trans_associate_var and never reaches the
point of calling gfc_conv_intrinsic_adjust.
NOTE: Running the program with GCC 7, it shows "abc" - then nothing for two
seconds - and only then "xyz". What is the program doing during those two
seconds?
I think the following patch is sensible – but as string->ts.u.cl->length ==
NULL,
it doesn't change anything regarding this PR.
diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index 53338dda0a7..e0028c30c86 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -224,3 +224,10 @@ gfc_resolve_adjustl (gfc_expr *f, gfc_expr *string)
if (string->ts.u.cl)
-f->ts.u.cl = gfc_new_charlen (gfc_current_ns, string->ts.u.cl);
+{
+ f->ts.u.cl = gfc_new_charlen (gfc_current_ns, string->ts.u.cl);
+ if (string->expr_type == EXPR_CONSTANT)
+ f->ts.u.cl->length = gfc_get_int_expr (gfc_charlen_int_kind, NULL,
+ string->value.character.length);
+ else if (string->ts.u.cl && string->ts.u.cl->length)
+ f->ts.u.cl->length = gfc_copy_expr (string->ts.u.cl->length);
+}
@@ -236,3 +243,10 @@ gfc_resolve_adjustr (gfc_expr *f, gfc_expr *string)
if (string->ts.u.cl)
-f->ts.u.cl = gfc_new_charlen (gfc_current_ns, string->ts.u.cl);
+{
+ f->ts.u.cl = gfc_new_charlen (gfc_current_ns, string->ts.u.cl);
+ if (string->expr_type == EXPR_CONSTANT)
+ f->ts.u.cl->length = gfc_get_int_expr (gfc_charlen_int_kind, NULL,
+ string->value.character.length);
+ else if (string->ts.u.cl && string->ts.u.cl->length)
+ f->ts.u.cl->length = gfc_copy_expr (string->ts.u.cl->length);
+}
[Bug c++/92136] cc1plus segv with CTAD and -fchecking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92136
--- Comment #3 from Marek Polacek ---
Same issue with an explicit deduction guide:
template
class Base {};
template
class Test1 : public Base>
{
public:
Test1() = default;
template typename T>
Test1(Base> const &) {}
};
template typename T>
Test1(Base> const &) -> Test1;
template
class Test2 : public Base> {};
int main()
{
Test2<2> const eps;
Test1 const omega = eps;
Test1 const gamma = eps;
return 0;
}
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #15 from Uroš Bizjak --- (In reply to Segher Boessenkool from comment #12) > (In reply to Uroš Bizjak from comment #10) > > Regarding reliability of pre-reload splitters, IIRC they should be safe, but > > I'll leave the final verdict to RTL experts. > > The *splitters* are just fine; a define_insn with a condition that turns off > in a later pass generally is not. Is it possible to lift the limitation from the combine pass, where the combine tries to split the insn, but expects exactly two new insn patterns to be generated. From the docs: --q-- When the combiner phase tries to split an insn pattern, it is always the case that the pattern is _not_ matched by any 'define_insn'. The combiner pass first tries to split a single 'set' expression and then the same 'set' expression inside a 'parallel', but followed by a 'clobber' of a pseudo-reg to use as a scratch register. In these cases, the combiner expects exactly two new insn patterns to be generated. It will verify that these patterns match some 'define_insn' definitions, so you need not do this test in the 'define_split' (of course, there is no point in writing a 'define_split' that will never produce insns that match). --/q-- Many define_and_split insns in i386.md that use can_create_pseudo_p have this unwanted condition in their insn condition just because of the mentioned limitation.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #14 from Jakub Jelinek --- And as for the define_insn_and_split without constraints that don't expect to be matched post split1, I think we can try to figure out something incrementally and change all of them at once, e.g. a property set by expand pass and cleared by split1 pass, or property set by split1 pass or something similar.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #13 from Jakub Jelinek --- Created attachment 47067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47067=edit gcc10-pr92140.patch So what about this version then? I've changed back a couple of to nonimmediate_operand and removed corresponding force_reg, because it would be in spots where the there is already one possible immediate which would be in operands[2] rather than operands[1], changed the eq/ne_0_operator to the define_special_predicate you've suggested and added testcase coverage. I'm not sure trying to do something here in peephole2 would catch as many cases as the combiner patterns can handle.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #12 from Segher Boessenkool --- (In reply to Uroš Bizjak from comment #10) > Regarding reliability of pre-reload splitters, IIRC they should be safe, but > I'll leave the final verdict to RTL experts. The *splitters* are just fine; a define_insn with a condition that turns off in a later pass generally is not.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #11 from Segher Boessenkool ---
If an insn condition uses can_create_pseudo_p, the insn will suddenly stop
to match after reload --> kaboom.
If your insn always splits ("&& 1"), this means that if any of these:
NEXT_PASS (pass_lower_subreg3);
NEXT_PASS (pass_df_initialize_no_opt);
NEXT_PASS (pass_stack_ptr_mod);
NEXT_PASS (pass_mode_switching);
NEXT_PASS (pass_match_asm_constraints);
NEXT_PASS (pass_sms);
NEXT_PASS (pass_live_range_shrinkage);
NEXT_PASS (pass_sched);
NEXT_PASS (pass_early_remat);
NEXT_PASS (pass_ira);
NEXT_PASS (pass_reload);
passes creates a new such insn, you ICE (or worse, do the wrong thing).
That limits exposure quite a bit, but OTOH it is really hard to prove some
of these passes will not create such insns.
[Bug inline-asm/92151] New: Spurious register copying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92151 Bug ID: 92151 Summary: Spurious register copying Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: gcc at gmch dot uk Target Milestone: --- Created attachment 47066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47066=edit Code to demonstrate the issue. The attached code is a fragment of a larger function. The larger function is a string copy which takes string 's', destination-buffer 'd' and end-of-destination-buffer 'e'. The body of the function is inline asm, The problem I have tripped over is the compiler makes spurious copies of registers. In some cases I have seen it PUSH %RBX in order to do so. Compiling the enclosed with gcc 9.1: 1) with "#define TWITCH 1" produces spurious copying of %rdi 2) with "#define TWITCH 0" produces no spurious copying The results for the two cases are given below, marked up to try to show what is going on. The extra shuffling of registers is ugly as sin, but not I suppose a big overhead, at least until PUSH/POP get added to make a register available for this nonsense :-( For completeness, I tried gcc 8.1 which does some similar (but different) spurious copying -- see Result 3, below. _ Result 1 -- gcc 9.1 -O3 -- #define TWITCH 1 qstpxcpy_asm0: // Arguments: d -- %rdi, s -- %rsi, e -- %rdx //Locals: w, t movq%rdi, %rcx// inserted by compiler -- gcc 9.1 mov (%rsi), %rax // w = *s lea -8(%rdx), %rdx // e -= 8 mov %eax, %r11d// t = w .L2: movq%rcx, %rdi// inserted by compiler mov %rax, (%rcx) // *d = w lea 8(%rdi), %rdi // d += 8 movq%rdi, %rcx// inserted by compiler cmp %rdx, %rdi// "d - e" -- __asm__ goto jae .L3 // quit if d >= e mov %eax, %r11d // t = w cmp $-1, %r11 // check 't' -- __asm__ goto jnz .L4 // j if at end mov %rax, (%rdi) // *d = w lea 8(%rdi), %rdi // d += 8 movq%rdi, %rcx// inserted by compiler cmp %rdx, %rdi// "d - e" -- __asm__ goto jae .L3 // quit if d >= e mov %eax, %r11d // t = w cmp $-1, %r11 // check 't' -- __asm__ goto jz.L2 // j if not at end .L4: lea (%rcx, %r11), %rax// return d + t ret .L3: lea (%rdx, %r11), %rax// return e + t ret _ Result 2 -- gcc 9.1 -O3 -- #define TWITCH 0 qstpxcpy_asm0: // Arguments: d -- %rdi, s -- %rsi, e -- %rdx //Locals: w, t mov (%rsi), %rax // w = *s lea -8(%rdx), %rdx // e -= 8 mov %eax, %r11d// t = w .L2: mov %rax, (%rdi) // *d = w lea 8(%rdi), %rdi // d += 8 cmp %rdx, %rdi// "d - e" -- __asm__ goto jae .L5 // quit if d >= e mov %eax, %r11d // t = w cmp $-1, %r11 // check 't' -- __asm__ goto jnz .L5 // j if at end mov %rax, (%rdi) // *d = w lea 8(%rdi), %rdi // d += 8 cmp %rdx, %rdi// "d - e" -- __asm__ goto jae .L5 // quit if d >= e mov %eax, %r11d // t = w cmp $-1, %r11 // check 't' -- __asm__ goto jz.L5 // j if not at end .L5: lea (%rdx, %r11), %rax// return e + t ret _ Result 3 -- gcc 8.1 -O3 -- #define TWITCH 1 qstpxcpy_asm0: // Arguments: d -- %rdi, s -- %rsi, e -- %rdx //Locals: w, t mov (%rsi), %rax // w = *s lea -8(%rdx), %rdx // e -= 8 mov %eax, %r11d// t = w .L2: movq%rdi, %rcx// inserted by compiler mov %rax, (%rdi) // *d = w lea 8(%rcx), %rcx // d += 8 movq%rcx, %rdi// inserted by compiler cmp %rdx, %rcx// "d - e" -- __asm__ goto jae .L3 // quit if d >= e mov %eax, %r11d // t = w cmp $-1, %r11 // check 't' -- __asm__ goto jnz .L4 // j if at end mov %rax, (%rcx) // *d = w lea 8(%rcx), %rcx // d += 8 movq%rcx, %rdi// inserted by compiler cmp %rdx, %rcx// "d - e" -- __asm__ goto jae .L3 // quit if d >= e mov %eax, %r11d // t = w cmp $-1, %r11 // check 't' -- __asm__ goto jz.L2 // j if not at end .L4: lea (%rdi, %r11), %rax// return d + t ret .L3: lea (%rdx, %r11), %rax// return e + t ret
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #10 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #9) > Created attachment 47065 [details] > gcc10-pr92140-wip.patch > > If pre-reload splitters are reliable, my patch can be greatly simplified and > using the formatting, && can_create_pseudos (), && 1 and + > force_reg ideas from your patch this is the merge of both, which can handle > all f1-f14 plus tst1-3. You can use define_special_predicate to check the mode of the operand inside relational operator. To avoid pattern explosion, maybe compound instructions should be synthesized by peephole pass. Regarding reliability of pre-reload splitters, IIRC they should be safe, but I'll leave the final verdict to RTL experts.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #9 from Jakub Jelinek --- Created attachment 47065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47065=edit gcc10-pr92140-wip.patch If pre-reload splitters are reliable, my patch can be greatly simplified and using the formatting, && can_create_pseudos (), && 1 and + force_reg ideas from your patch this is the merge of both, which can handle all f1-f14 plus tst1-3.
[Bug fortran/91586] [9/10 Regression] ICE in gfc_find_derived_vtab, at fortran/class.c:2245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91586 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED on trunk + GCC 9 branch. Thanks for the report!
[Bug fortran/91586] [9/10 Regression] ICE in gfc_find_derived_vtab, at fortran/class.c:2245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91586 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Fri Oct 18 12:38:26 2019 New Revision: 277154 URL: https://gcc.gnu.org/viewcvs?rev=277154=gcc=rev Log: Fortran] PR91586 Fix ICE on invalid code with CLASS gcc/fortran/ Backport from mainline 2019-10-18 Tobias Burnus PR fortran/91586 * class.c (gfc_find_derived_vtab): Return NULL instead of deref'ing NULL pointer. gcc/testsuite/ Backport from mainline 2019-10-18 Tobias Burnus PR fortran/91586 * gfortran.dg/class_71.f90: New. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/class_71.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/class.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #8 from Jakub Jelinek ---
Comparing the two patches, your patch handles f1-f4 in
/* PR target/92140 */
char c;
int v;
__attribute__((noipa)) void f1 (void) { v += c != 0; }
__attribute__((noipa)) void f2 (void) { v -= c != 0; }
__attribute__((noipa)) void f3 (void) { v += c == 0; }
__attribute__((noipa)) void f4 (void) { v -= c == 0; }
__attribute__((noipa)) void f5 (void) { v += (c != 0) - 26; }
__attribute__((noipa)) void f6 (void) { v -= (c != 0) - 26; }
__attribute__((noipa)) void f7 (void) { v += (c == 0) - 26; }
__attribute__((noipa)) void f8 (void) { v -= (c == 0) - 26; }
__attribute__((noipa)) void f9 (void) { v += (c != 0) + 42; }
__attribute__((noipa)) void f10 (void) { v -= (c != 0) + 42; }
__attribute__((noipa)) void f11 (void) { v += (c == 0) + 42; }
__attribute__((noipa)) void f12 (void) { v -= (c == 0) + 42; }
__attribute__((noipa)) void f13 (int z) { v += (c == 0) + z; }
__attribute__((noipa)) void f14 (int z) { v -= (c == 0) + z; }
int
main ()
{
int i;
for (i = 0; i < 2; i++)
{
v = 15;
if (i == 1)
c = 37;
f1 ();
if (v != 15 + i)
__builtin_abort ();
f2 ();
if (v != 15)
__builtin_abort ();
f3 ();
if (v != 16 - i)
__builtin_abort ();
f4 ();
if (v != 15)
__builtin_abort ();
f5 ();
if (v != 15 + i - 26)
__builtin_abort ();
f6 ();
if (v != 15)
__builtin_abort ();
f7 ();
if (v != 16 - i - 26)
__builtin_abort ();
f8 ();
if (v != 15)
__builtin_abort ();
f9 ();
if (v != 15 + i + 42)
__builtin_abort ();
f10 ();
if (v != 15)
__builtin_abort ();
f11 ();
if (v != 16 - i + 42)
__builtin_abort ();
f12 ();
if (v != 15)
__builtin_abort ();
f13 (173);
if (v != 16 - i + 173)
__builtin_abort ();
f14 (173);
if (v != 15)
__builtin_abort ();
f13 (-35);
if (v != 16 - i - 35)
__builtin_abort ();
f14 (-35);
if (v != 15)
__builtin_abort ();
}
return 0;
}
and all cases in the #c0 testcase, while my patch handles f1-f14 in the above
testcase and only tst1/tst2 in #c0 testcase.
For the pre-reload only splitters, I'm never sure if it is safe. If it is
matched pre-split1 (usually during combine), it is of course fine, but what if
it appears after split1 and before end of reload, do we have a guarantee that
nothing will try to match those? If it is safe, I can of course add the &&
!reload_completed or similar to the conditions (or && can_create_pseudo_p ()).
[Bug c++/92150] New: Partial specializations of class templates with class NTTP fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92150
Bug ID: 92150
Summary: Partial specializations of class templates with class
NTTP fails
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
The following code fails the assert
```
struct X {
int value;
// auto operator==(const X&) = default;
};
template
struct b;
template
inline constexpr bool is_b = false;
template
inline constexpr bool is_b> = true;
using my_b = b;
static_assert(is_b);
```
https://godbolt.org/z/Q8wpC3
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #7 from Uroš Bizjak --- Created attachment 47064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47064=edit Proposed patch with pre-reload splitters Maybe we should use pre-reload splitters as with the attached patch that converts all test cases.
[Bug fortran/91586] [9/10 Regression] ICE in gfc_find_derived_vtab, at fortran/class.c:2245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91586 --- Comment #1 from Tobias Burnus --- Author: burnus Date: Fri Oct 18 12:04:31 2019 New Revision: 277153 URL: https://gcc.gnu.org/viewcvs?rev=277153=gcc=rev Log: Fortran] PR91586 Fix ICE on invalid code with CLASS gcc/fortran/ PR fortran/91586 * class.c (gfc_find_derived_vtab): Return NULL instead of deref'ing NULL pointer. gcc/testsuite/ PR fortran/91586 * gfortran.dg/class_71.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_71.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Oct 18 11:27:31 2019 New Revision: 277151 URL: https://gcc.gnu.org/viewcvs?rev=277151=gcc=rev Log: PR libstdc++/92143 adjust for OS X aligned_alloc behaviour OS X 10.15 adds aligned_alloc but it has the same restriction as the AIX version, namely that alignments smaller than sizeof(void*) are not supported. PR libstdc++/92143 * libsupc++/new_opa.cc (operator new) [__APPLE__]: Increase alignment to at least sizeof(void*). Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/new_opa.cc
[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 --- Comment #7 from Jonathan Wakely --- Fixed on trunk so far, but I'll backport it too.
[Bug target/92149] Enefficient x86_64 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149 --- Comment #3 from Maxim Egorushkin --- System V ABI doesn't seem to require unused bytes to contain any specific value. There is a specific note for _Bool: When a value of type _Bool is returned or passed in a register or on the stack, bit 0 contains the truth value and bits 1 to 7 shall be zero. Other bits are left unspecified, hence the consumer side of those values can rely on it being 0 or 1 when truncated to 8 bit.
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 Jakub Jelinek changed: What|Removed |Added Attachment #47062|0 |1 is obsolete|| --- Comment #6 from Jakub Jelinek --- Created attachment 47063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47063=edit gcc10-pr92140-wip.patch Updated patch that implements that, so when expanded only adds 36 define_insn and 36 define_split rather than 144 each.
[Bug target/92149] Enefficient x86_64 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149 --- Comment #2 from Maxim Egorushkin --- I notice that g++ always zeros out unused high-order bits. Clang++ never does. Both follow the same System V ABI.
[Bug target/92149] Enefficient x86_64 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149 Andrew Pinski changed: What|Removed |Added Keywords||ABI, missed-optimization --- Comment #1 from Andrew Pinski --- What does the ABI say about the top 2 bytes in this case? Are they undefined or needs to be zero?
[Bug target/92149] New: Enefficient x86_64 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
Bug ID: 92149
Summary: Enefficient x86_64 code
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
#include
#include
using std::uint64_t;
using A = std::array;
template
constexpr A pack(T v) {
using C = unsigned char;
return {C(v), C(v >> 8), C(v >> 16), C(v >> 24), C(v >> 32), C(v >>
40)};
}
template
constexpr A pack2(T v) {
A r{};
std::memcpy(r.data(), , 6);
return r;
}
A f(uint64_t a) { return pack(a); }
A f2(uint64_t a) { return pack2(a); }
When compiled with `clang++-9.0 -std=gnu++17 -O3 -march=skylake` produces the
most efficient assembly:
f(unsigned long):
mov rax, rdi
ret
f2(unsigned long):
mov rax, rdi
ret
Whereas when compiled with `g++-9.2 -std=gnu++17 -O3 -march=skylake` the
assembly is inefficient:
f(unsigned long):
mov rax, rdi
shr rax, 32
mov BYTE PTR [rsp-2], al
mov rax, rdi
shr rax, 40
mov BYTE PTR [rsp-1], al
movzx eax, WORD PTR [rsp-2]
sal rax, 32
mov rdx, rax
mov eax, edi
or rax, rdx
ret
f2(unsigned long):
movabs rax, 281474976710655
and rax, rdi
ret
Why does g++ emit such verbose code please?
[Bug modula2/92148] New: gm2: race condition building gm2 on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92148 Bug ID: 92148 Summary: gm2: race condition building gm2 on trunk Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- according to https://buildd.debian.org/status/package.php?p=gcc-snapshot the 1:20191017-1 builds on x86_64-linux-gnu and i686-linux-gnu fail when modula-2 is enabled. The build continues when restarted, and succeeds when modula-2 is disabled. make[5]: *** [../../src/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 127 make[5]: *** Waiting for unfinished jobs rm gfdl.pod gpl.pod cpp.pod gccbrig.pod gccgo.pod gfortran.pod gcc.pod gcov-tool.pod gdc.pod fsf-funding.pod gcov-dump.pod gcov.pod make[5]: Leaving directory '/<>/build/gcc' make[4]: *** [Makefile:4797: all-stage2-gcc] Error 2 make[4]: Leaving directory '/<>/build' make[3]: *** [Makefile:26522: stage2-bubble] Error 2 make[3]: Leaving directory '/<>/build' make[2]: *** [Makefile:26726: bootstrap] Error 2
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #5 from Jakub Jelinek --- The patch adds 144 define_insn and 144 define_split to tmp-mddump.md though, to total 6217 define_insn and 733 define_split. Maybe a better way to deal with it would be to have x86_ne_0_operator and x86_eq_0_operator with a mode-less operand inside of it, where the predicate would ensure the mode of the operand is QI/HI/SI/DI (last one only if TARGET_64BIT) in addition checking it is a ne (resp. eq). Unfortunately there is the problem with the constraints, where !TARGET_64BIT requires q constraint instead of r for the comparison operand, maybe use for that enabled attribute?
[Bug modula2/92147] New: gm2: modula-2 fails to build on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147 Bug ID: 92147 Summary: gm2: modula-2 fails to build on powerpc-linux-gnu Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- as seen at https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=powerpc=1%3A20191017-1=1571363965=0 modula-2 fails to build on powerpc-linux-gnu (32bit big endian): cp -p stage1/gm2/cc1gm2 cc1gm2 bash ../../src/gcc/gm2/tools-src/makeSystem -fpim \ ../../src/gcc/gm2/gm2-libs/SYSTEM.def \ ../../src/gcc/gm2/gm2-libs/SYSTEM.mod \ -I../../src/gcc/gm2/gm2-libs \ "/<>/build/./gcc/xgm2 -B/<>/build/./gcc/" /<>/build/gcc/gm2/gm2-libs/SYS TEM.def bash ../../src/gcc/gm2/tools-src/makeSystem -fiso \ ../../src/gcc/gm2/gm2-libs-iso/SYSTEM.def \ ../../src/gcc/gm2/gm2-libs-iso/SYSTEM.mod \ -I../../src/gcc/gm2/gm2-libs-iso:../../src/gcc/gm2/gm2-libs \ "/<>/build/./gcc/xgm2 -B/<>/build/./gcc/" /<>/build/gcc/gm2/gm2-libs-iso/SYSTEM.def bash ../../src/gcc/gm2/tools-src/makeSystem -fpim \ ../../src/gcc/gm2/gm2-libs-coroutines/SYSTEM.def \ ../../src/gcc/gm2/gm2-libs-coroutines/SYSTEM.mod \ -I../../src/gcc/gm2/gm2-libs-coroutines:../../src/gcc/gm2/gm2-libs-iso:../../src/gcc/gm2/gm2-libs \ "/<>/build/./gcc/xgm2 -B/<>/build/./gcc/" /<>/build/gcc/gm2/gm2-libs-coroutines/SYSTEM.def rm -f stamp-gnatlib2-rts stamp-tools xgm2: internal compiler error: Segmentation fault signal terminated program cc1gm2 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. SYSTEM module creates type: LOC SYSTEM module creates type: WORD SYSTEM module creates type: BYTE SYSTEM module creates type: ADDRESS SYSTEM module creates type: INTEGER8 SYSTEM module creates type: INTEGER16 SYSTEM module creates type: INTEGER32 SYSTEM module creates type: INTEGER64 SYSTEM module creates type: CARDINAL8 SYSTEM module creates type: CARDINAL16 SYSTEM module creates type: CARDINAL32 SYSTEM module creates type: CARDINAL64 SYSTEM module creates type: WORD16 SYSTEM module creates type: WORD32 SYSTEM module creates type: WORD64 SYSTEM module creates type: BITSET8 SYSTEM module creates type: BITSET16 SYSTEM module creates type: BITSET32 SYSTEM module creates type: REAL32 SYSTEM module creates type: REAL64 SYSTEM module creates type: REAL128 SYSTEM module creates type: COMPLEX32 SYSTEM module creates type: COMPLEX64 SYSTEM module creates type: COMPLEX128 SYSTEM module creates type: CSIZE_T SYSTEM module creates type: CSSIZE_T xgm2: internal compiler error: Segmentation fault signal terminated program cc1gm2 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. xgm2: internal compiler error: Segmentation fault signal terminated program cc1gm2 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. SYSTEM module creates type: LOC SYSTEM module creates type: WORD SYSTEM module creates type: BYTE SYSTEM module creates type: ADDRESS SYSTEM module creates type: INTEGER8 SYSTEM module creates type: INTEGER16 SYSTEM module creates type: INTEGER32 SYSTEM module creates type: INTEGER64 SYSTEM module creates type: CARDINAL8 SYSTEM module creates type: CARDINAL16 SYSTEM module creates type: CARDINAL32 SYSTEM module creates type: CARDINAL64 SYSTEM module creates type: WORD16 SYSTEM module creates type: WORD32 SYSTEM module creates type: WORD64 SYSTEM module creates type: BITSET8 SYSTEM module creates type: BITSET16 SYSTEM module creates type: BITSET32 SYSTEM module creates type: REAL32 SYSTEM module creates type: REAL64 SYSTEM module creates type: REAL128 SYSTEM module creates type: COMPLEX32 SYSTEM module creates type: COMPLEX64 SYSTEM module creates type: COMPLEX128 SYSTEM module creates type: CSIZE_T SYSTEM module creates type: CSSIZE_T SYSTEM module creates type: LOC SYSTEM module creates type: ADDRESS SYSTEM module creates type: BYTE SYSTEM module creates type: WORD SYSTEM module creates type: INTEGER8 SYSTEM module creates type: INTEGER16 SYSTEM module creates type: INTEGER32 SYSTEM module creates type: INTEGER64 SYSTEM module creates type: CARDINAL8 SYSTEM module creates type: CARDINAL16 SYSTEM module creates type: CARDINAL32 SYSTEM module creates type: CARDINAL64 SYSTEM module creates type: WORD16 SYSTEM module creates type: WORD32 SYSTEM module creates type: WORD64 SYSTEM module creates type: BITSET8 SYSTEM module creates type: BITSET16 SYSTEM module creates type: BITSET32 SYSTEM module creates type: REAL32 SYSTEM module creates type: REAL64 SYSTEM module creates type: REAL128 SYSTEM module creates type: COMPLEX32 SYSTEM module creates type: COMPLEX64 SYSTEM module creates
[Bug target/92140] clang vs gcc optimizing with adc/sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140 --- Comment #4 from Jakub Jelinek --- Created attachment 47062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47062=edit gcc10-pr92140-wip.patch Slightly extended untested patch, which handles all the cases in the testcase at the start of the file. Originally reported tst3 still unhandled though.
[Bug modula2/92146] New: gm2: the brig, fortran, go and D frontends are missing lang_register_spec_functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92146 Bug ID: 92146 Summary: gm2: the brig, fortran, go and D frontends are missing lang_register_spec_functions Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- Created attachment 47061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47061=edit patch the brig, fortran, go and D frontends are missing lang_register_spec_functions, introduced by gm2.
[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 Jonathan Wakely changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- Thanks for the checking the preprocessor output. (In reply to Daryl Haresign from comment #4) > C11 said: > > The aligned_alloc function allocates space for an object whose alignment is > specified by alignment, whose size is specified by size, and whose value is > indeterminate. The value of alignment shall be a valid alignment supported > by the implementation and the value of size shall be an integral multiple of > alignment. > > So it seems macOS and AIX's implementations are technically conformant. I disagree. The code in comment 2 makes two adjustments when we're using C11 aligned_alloc. The first one is specific to AIX, and increases the alignment to at least sizeof(void*): #if _GLIBCXX_HAVE_ALIGNED_ALLOC # ifdef _AIX /* AIX 7.2.0.0 aligned_alloc incorrectly has posix_memalign's requirement * that alignment is a multiple of sizeof(void*). */ if (align < sizeof(void*)) align = sizeof(void*); # endif This is *not* allowed by POSIX or C11. C11 6.2.8 says "Valid alignments include only those values returned by an _Alignof expression for fundamental types, plus an additional implementation-defined set of values, which may be empty. Every valid alignment shall be a nonnegative integral power of two." _Alignof(char) and _Alignof(short) and _Alignof(int) are valid alignments supported by the implementation, and so aligned_alloc is wrong to reject them. The second part of the code applies to all targets and makes the size adjustment required by C11: /* C11: the value of size shall be an integral multiple of alignment. */ sz = (sz + align - 1) & ~(align - 1); #endif > Perhaps GCC should determine whether the platform supports alignments less > than sizeof(void*) when GCC is built, and put a new macro in c++config.h > (assuming that's how that file is constructed)? That isn't necessarily possible because GCC could be built on a completely different system, so we can't run tests reliably. For this specific case I think the difference between using posix_memalign and aligned_alloc would not be ABI-breaking, so it would not be a problem if a native compiler used one and a cross-compiler used the other, but such a solution would mean the cross-compiler is still broken. So we need to add workarounds on a target-by-target basis anyway. The OS X man page does say: "In addition, aligned_alloc() returns a NULL pointer and sets errno to EINVAL if size is not an integral multiple of alignment, or if alignment is not a power of 2 at least as large as sizeof(void*)." So I'll extend the workaround to apply to OS X too.
[Bug target/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
--- Comment #2 from David Binderman ---
Here is some reduced C code which demonstrates the problem:
a;
union b {
double c;
char d[8]
} e() {
union b b;
memcpy(b.d, a, 8);
f(b);
}
Flag -O2 required.
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Georg-Johann Lay --- Fixed in v7.5, v8.4 and v9.3+
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 --- Comment #10 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 18 09:16:16 2019 New Revision: 277149 URL: https://gcc.gnu.org/viewcvs?rev=277149=gcc=rev Log: Backport from 2019-10-18 trunk r277143. PR target/86040 * config/avr/avr.c (avr_out_lpm): Do not shortcut-return. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/avr/avr.c
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 --- Comment #9 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 18 09:12:34 2019 New Revision: 277148 URL: https://gcc.gnu.org/viewcvs?rev=277148=gcc=rev Log: Backport from 2019-10-18 trunk r277143. PR target/86040 * config/avr/avr.c (avr_out_lpm): Do not shortcut-return. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/avr/avr.c
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 18 09:10:20 2019 New Revision: 277147 URL: https://gcc.gnu.org/viewcvs?rev=277147=gcc=rev Log: Backport from 2019-10-18 trunk r277143. PR target/86040 * config/avr/avr.c (avr_out_lpm): Do not shortcut-return. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/avr/avr.c
[Bug c++/91165] [10 Regression] error: location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165 --- Comment #2 from David Binderman --- Three months later, still broken.
[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 --- Comment #20 from Iain Sandoe --- Author: iains Date: Fri Oct 18 08:42:41 2019 New Revision: 277145 URL: https://gcc.gnu.org/viewcvs?rev=277145=gcc=rev Log: [Darwin] Amend section for constants with relocations. Darwin's linker doesn't like text section relocations (they require special enabling). The Fortran FE, at least, seems to generate cases where the initialiser for a pointer constant can need a relocation. We can handle this by special-casing SECCAT_RODATA when the relocation is present by placing the constant in the .const_data section. gcc/ 2019-10-18 Iain Sandoe Backport from mainline 2019-10-05 Iain Sandoe PR target/59888 * config/darwin.c (darwin_rodata_section): Add relocation flag, choose const_data section for constants with relocations. (machopic_select_section): Pass relocation flag to darwin_rodata_section (). Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/darwin.c
[Bug tree-optimization/91532] [SVE] Redundant predicated store in gcc.target/aarch64/fmla_2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91532 --- Comment #3 from rsandifo at gcc dot gnu.org --- I think it'd be good to add a testcase for this, assuming that it's now fixed.
[Bug target/86753] [9/10 Regression] gcc.target/aarch64/sve/vcond_[45].c fail after recent combine patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86753 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from rsandifo at gcc dot gnu.org --- Fixed.
