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
Snapshot gcc-13-20240224 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20240224/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This file,
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|
Hi,
On Thu, Feb 22, 2024 at 11:57:50AM +0800, YunQiang Su wrote:
> Mark Wielaard 于2024年2月19日周一 06:58写道：
> > So, I did try the regenerate-opt-urls locally, and it did generate the
> > attached diff. Which seems to show we really need this automated.
> >
> > Going over the diff. The
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
On Linux/x86_64,
8a16e06da97f51574cfad17e2cece2e58571305d is the first bad commit
commit 8a16e06da97f51574cfad17e2cece2e58571305d
Author: Richard Sandiford
Date: Fri Feb 23 14:12:54 2024 +
aarch64: Add missing early-ra bookkeeping [PR113295]
caused
FAIL:
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
On Feb 23, 2024, Jason Merrill wrote:
> The problem, as you say, comes when you want to both bootstrap and
> build tools that aren't involved in the bootstrap process.
It's more visible there, because those don't actively refrain from
linking dynamically with libstdc++. But even bootstrapped
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:
> Am 24.02.2024 um 08:44 schrieb Jakub Jelinek :
>
> Hi!
>
> I've searched for some uses of (HOST_WIDE_INT) constant or (unsigned
> HOST_WIDE_INT) constant and turned them into uses of the appropriate
> macros.
> THere are quite a few cases in non-i386 backends but I've left that out
> for
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
> Am 24.02.2024 um 08:40 schrieb Jakub Jelinek :
>
> Hi!
>
> The following patch implements support for VIEW_CONVERT_EXPRs from/to
> large/huge _BitInt to/from vector or complex types or anything else but
> integral/pointer types which doesn't need to live in memory.
>
>
> Am 24.02.2024 um 11:06 schrieb Richard Sandiford :
>
> During its forward pass, the SLP layout code tries to calculate
> the cost of a layout change on an incoming edge. This is taken
> as the minimum of two costs: one in which the source partition
> keeps its current layout (chosen
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;
}
}
Hi Tamar and Richard.
Just try DEF_INTERNAL_INT_EXT_FN as below draft patch, not very sure if
my understanding is correct(mostly reference the popcount implementation) here.
Thanks a lot.
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646442.html
Pan
-Original Message-
From:
From: Pan Li
Hi Richard & Tamar,
Try the DEF_INTERNAL_INT_EXT_FN as your suggestion. By mapping
us_plus$a3 to the RTL representation (us_plus:m x y) in optabs.def.
And then expand_US_PLUS in internal-fn.cc. Not very sure if my
understanding is correct for DEF_INTERNAL_INT_EXT_FN.
I am not
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.
Iain Sandoe writes:
> Hi Gaius,
>
>> On 22 Feb 2024, at 18:06, Gaius Mulley wrote:
>>
>> Iain Sandoe writes:
>>
>>> Right now, AFAIK the only target runtimes used by host tools are
>>> libstdc++, libgcc and libgnat. I agree that might change with rust -
>>> since the rust folks are talking
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
I keep forgetting that gcc.dg/rtl is the one testsuite where
tests in target-specific subdirectories aren't automatically
restricted to that target.
Pushed as obvious after testing on aarch64-linux-gnu & x86_64-linux-gnu.
Richard
gcc/testsuite/
* gcc.dg/rtl/aarch64/pr113295-1.c:
During its forward pass, the SLP layout code tries to calculate
the cost of a layout change on an incoming edge. This is taken
as the minimum of two costs: one in which the source partition
keeps its current layout (chosen earlier during the pass) and
one in which the source partition switches to
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
62 matches
Mail list logo
