https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
--- Comment #3 from Thiago Macieira ---
> But __builtin_strlen *does* get optimized when the input is a string literal.
> Not sure about wcslen though.
It appears not to, in the test above. std::char_trait::length() calls
wcslen() whereas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #27 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #26)
> But I still think the workaround is possible on the callee side.
> Sure, if the DECL_HIDDEN_STRING_LENGTH argument(s) is(are) used in the
> function, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114093
Bug ID: 114093
Summary: Canonicalization of `a == -1 || a == 0`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114092
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114092
--- Comment #1 from Andrew Pinski ---
I should note that LLVM (LLVM does not have __builtin_add_overflow_p) is able
to optimize:
```
_Bool f2(int a, struct d b, unsigned _BitInt(1) t)
{
return __builtin_add_overflow(a, 0, );
}
```
into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114092
Bug ID: 114092
Summary: ADD_OVERFLOW with resulting type of `_Complex
unsigned:1` should be reduced to just `(unsigned)(a)
<= 1`
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114091
--- Comment #2 from Mark Millard ---
(In reply to Andrew Pinski from comment #1)
> This has already been fixed, over 2 weeks ago.
>
> >20240114
>
> You are using a GCC 14 snapshot from a month ago even. Please try a newer
> snapshot before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Andrew Pinski changed:
What|Removed |Added
CC||markmigm at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114091
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114091
Bug ID: 114091
Summary: gcc/config/aarch64/aarch64.cc has code requiring c++14
instead of c++11, so g++14 bootsrap fails in my
example context
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114090
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
--- Comment #1 from Jonathan Wakely ---
GCC built-ins like __builtin_strlen just wrap a libc function. __builtin_wcslen
would generally just be a call to wcslen, which doesn't give you much. I assume
what you want is to recognize wcslen and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114090
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #5 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #7 from Jerry DeLisle ---
There two issues going on here. We do not interpret source code that is UTF-8
encoded. This is why in our current tests for UTF-8 encoding of data files we
us hexidecimal codes.
I will have to see what the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114090
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114090
--- Comment #3 from Jakub Jelinek ---
Both the patterns look wrong for TYPE_OVERFLOW_WRAPS and the first one also for
TYPE_UNSIGNED (the second one is ok for TYPE_UNSIGNED but doesn't make much
sense there, we should have folded it to 0. Of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114090
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114090
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114090
Bug ID: 114090
Summary: forwprop -fwrapv miscompilation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114089
--- Comment #2 from Jakub Jelinek ---
I mean r14-9162 , sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114089
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114089
Bug ID: 114089
Summary: FAIL: gcc.dg/rtl/aarch64/pr113295-1.c (test for excess
errors)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114087
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
Bug ID: 114088
Summary: Please provide __builtin_c16slen and __builtin_c32slen
to complement __builtin_wcslenw
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114087
Bug ID: 114087
Summary: RISC-V optimization on checking certain bits set ((x &
mask) == val)
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696
--- Comment #3 from Richard Sandiford ---
Created attachment 57520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57520=edit
Candidate patch
The attached patch seems to fix it. I'm taking next week off, but I'll run the
patch through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #7 from Jakub Jelinek ---
Now, suppose we optimize the (0x >> x) & 1 case etc. provided suitable
range
of x to x & 1.
For
int
bar3 (int e)
{
if (e <= 15U)
return e & 1;
else
return 0;
}
phiopt optimizes this into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #13 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:0394ae31e832c5303f3b4aad9c66710a30c097f0
commit r14-9165-g0394ae31e832c5303f3b4aad9c66710a30c097f0
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
Jakub Jelinek changed:
What|Removed |Added
Component|middle-end |tree-optimization
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Bug 113988 depends on bug 114073, which changed state.
Bug 114073 Summary: during GIMPLE pass: bitintlower: internal compiler error:
in lower_stmt, at gimple-lower-bitint.cc:5530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5e7a176e88a2a37434cef9b1b6a37a4f8274854a
commit r14-9163-g5e7a176e88a2a37434cef9b1b6a37a4f8274854a
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #5 from Jan Schultke ---
Well, it's not quite equivalent to either of the bit-shifts we've posted. To
account for shifting more than the operand size, it would be:
bool foo (int x)
{
return x > 6 ? 0 : ((85 >> x) & 1);
}
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #4 from Jakub Jelinek ---
But sure, confirmed for both:
int
foo (int e)
{
switch (e)
{
case 1:
case 3:
case 5:
case 7:
case 9:
case 11:
case 13:
return 1;
default:
return 0;
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #3 from Jakub Jelinek ---
And the rest boils down to what code to generate for
bool
foo (int x)
{
return ((682 >> x) & 1);
}
Both that and switch from the #c0 testcase boil down to
_1 = 682 >> x_2(D);
_3 = (_Bool) _1;
or
_6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #2 from Jan Schultke ---
Yeah right, the actual optimal output (which clang finds) is:
> test_switch(E):
> test edi, -7
> sete al
> ret
Testing with -7 also makes sure that the 8-bit and greater are all zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |rtl-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
--- Comment #6 from Jakub Jelinek ---
As in the following patch, which is supposed to track the origin of the 6
something0
variables in bitmasks, bit 1 means it comes (partly) from op0, bit 2 means it
comes (partly) from op1.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
Bug ID: 114086
Summary: Boolean switches could have a lot better codegen,
possibly utilizing bit-vectors
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #5 from Andreas Schwab ---
Enable conditional-move operations even if unsupported by hardware.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
--- Comment #5 from Jakub Jelinek ---
Or perhaps the
if (ok
&& ((var0 != 0) + (var1 != 0)
+ (minus_var0 != 0) + (minus_var1 != 0)
+ (con0 != 0) + (con1 != 0)
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
--- Comment #4 from Jakub Jelinek ---
Though, I must say not really sure why this wouldn't recurse infinitely even
without the casts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
--- Comment #3 from Jakub Jelinek ---
Bet the associate code is really unprepared to have unfolded trees around,
which hasn't been the case before delayed folding has been introduced to C and
C++ FEs.
Unfortunately it isn't complete, because
49 matches
Mail list logo
