https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51030
--- Comment #5 from Andrew Pinski ---
Created attachment 56317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56317=edit
First set of patches
Note the last patch is still being worked on really.
Note the first patch is just a small speed
When 2 vectors are equal, kmask is allones and kortest will set CF,
else CF will be cleared.
So CF bit can be used to check for the result of the comparison.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
Before:
vmovdqu (%rsi), %ymm0
vpxorq (%rdi),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51030
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #7 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #3)
> First off does this even make sense to vectorize but rather do some kind of
> scalar reduction with respect to j = j^1 here . Filed PR 112104 for that.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #6 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #5)
> Oh this is the original code:
> https://github.com/kdlucas/byte-unixbench/blob/master/UnixBench/src/whets.c
>
Yes, it's from unixbench.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
Alibek Omarov changed:
What|Removed |Added
CC||a1ba.omarov at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112104
--- Comment #1 from Andrew Pinski ---
This shows up in a really really bad benchmark:
https://github.com/kdlucas/byte-unixbench/blob/master/UnixBench/src/whets.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #5 from Andrew Pinski ---
Oh this is the original code:
https://github.com/kdlucas/byte-unixbench/blob/master/UnixBench/src/whets.c
HEHEHEHEHEHEHEHEH. Basically after optimizing:
_9 = j_19 != 1;
_14 = (long int) _9;
Over to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #4 from Andrew Pinski ---
Is there a non-reduced testcase here? Or does the loop really just do j = j^1 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112104
Bug ID: 112104
Summary: loop of ^1 should just be reduced to ^(n&1)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #17 from Andrew Pinski ---
*** Bug 111833 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111833
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103861
--- Comment #15 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:7eed861e8ca3f533e56dea6348573caa09f16f5e
commit r14-4964-g7eed861e8ca3f533e56dea6348573caa09f16f5e
Author: liuhongt
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111318
Lehua Ding changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111833
--- Comment #5 from Hongtao.liu ---
It's the same issue as PR111820, thus should be fixed.
> -Original Message-
> From: Jiang, Haochen
> Sent: Friday, October 27, 2023 10:52 AM
> To: Jiang, Haochen ; gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com; Gerald Pfeifer
>
> Subject: RE: [PATCH] [gcc-wwwdocs]gcc-13/14: Mention Intel new ISA and
> march support
>
> >
> -Original Message-
> From: Haochen Jiang
> Sent: Monday, October 23, 2023 10:18 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ger...@pfeifer.com; ubiz...@gmail.com; Liu, Hongtao
>
> Subject: [gccwwwdocs PATCH] gcc-13/14: Mention Intel new ISA and march
> support
>
> Hi all,
>
> This patch
> -Original Message-
> From: Gcc-patches bounces+haochen.jiang=intel@gcc.gnu.org> On Behalf Of Haochen Jiang
> via Gcc-patches
> Sent: Monday, July 17, 2023 11:34 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] [gcc-wwwdocs]gcc-13/14: Mention
Thanks Richard S for comments.
> In other words, I don't think simply removing the test from the vectoriser
> is correct. It needs to be replaced by something more selective.
Does it mean we need to check if the internal fun allow different modes/sizes
here?
For example, standard name
+cc maintainers.
On 2023/10/26 11:25, Xionghu Luo wrote:
Fix the long lasting issue of `gcov-tool overlap xxx yyy`,
divide to 0 caused the output shows a lot of nans, another problem
is the counts in file are never acculated leads to incorrect results.
Signed-off-by: Xionghu Luo
Hi,
Compare with previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632399.html
This verion supports TI/VEC mode of the access.
There are a few PRs (meta-bug PR101926) on various targets.
The root causes of them are similar: the aggeragte param/
returns are passed by
On 10/26/23 17:37, Patrick Palka wrote:
On Thu, 26 Oct 2023, Patrick Palka wrote:
On Thu, 26 Oct 2023, Jason Merrill wrote:
On 10/25/23 14:55, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Now that we don't have to worry
On 9/18/23 13:21, Jakub Jelinek wrote:
Here is an updated version of the patch.
Compared to the last version, based on the discussion in the PR, the patch
1) warns (but only that) if size()/data() methods aren't declared
constexpr/consteval (or implicitly constexpr)
The language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #15 from Hongtao.liu ---
(In reply to Richard Biener from comment #13)
> (In reply to Hongtao.liu from comment #12)
> > Fixed in GCC14, not sure if we want to backport the patch.
> > If so, the patch needs to be adjusted since GCC13
Yeah. No worry. We will eventually run full coverage testing && fix all bugs in
stage 3 && stage 4.
We are planning to run the whole gcc testsuite with all these following compile
option:
-march=rv64gcv_zvl128b --param=riscv-autovec-lmul=m1
-march=rv64gcv_zvl128b --param=riscv-autovec-lmul=m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:82919cf4cb232166fed03d84a91fefd07feef6bb
commit r13-7988-g82919cf4cb232166fed03d84a91fefd07feef6bb
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111833
--- Comment #4 from CVS Commits ---
The releases/gcc-13 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:82919cf4cb232166fed03d84a91fefd07feef6bb
commit r13-7988-g82919cf4cb232166fed03d84a91fefd07feef6bb
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #9 from JuzheZhong ---
(In reply to Maciej W. Rozycki from comment #7)
> Thank you for all your explanations. I think I'm still missing something
> here, so I'll write it differently (and let's ignore the tail-agnostic vs
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #8 from JuzheZhong ---
(In reply to Maciej W. Rozycki from comment #7)
> Thank you for all your explanations. I think I'm still missing something
> here, so I'll write it differently (and let's ignore the tail-agnostic vs
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #7 from Maciej W. Rozycki ---
Thank you for all your explanations. I think I'm still missing something
here, so I'll write it differently (and let's ignore the tail-agnostic vs
tail-undisturbed choice for the purpose of this
Thanks Patrick. Committed.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-10-27 02:12
To: Juzhe-Zhong; gcc-patches
CC: Kito Cheng; Robin Dapp
Subject: Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV
auto-vectorization
popcount and mask_gather_load_run fails seem to
Committed.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-10-27 06:28
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [NFC] RISC-V: Move lmul calculation into macro
Notice we calculate LMUL according to --param=riscv-autovec-lmul
in multiple places:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111888
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111888
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:e37bc2cf00671e3bc4d82f2627330c0f885a6f29
commit r14-4961-ge37bc2cf00671e3bc4d82f2627330c0f885a6f29
Author: Juzhe-Zhong
Date: Thu Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111318
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:e37bc2cf00671e3bc4d82f2627330c0f885a6f29
commit r14-4961-ge37bc2cf00671e3bc4d82f2627330c0f885a6f29
Author: Juzhe-Zhong
Date: Thu Oct
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-10-27 03:19
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix cond_sqrt tests.
Hi,
as long as we do not have universal Zvfh support in binutils
linking against libm does
On Thu, 26 Oct 2023, Sam James wrote:
> These options both enabled more checking within the C++ standard library
> and can expose errors in submitted code.
This is a good addition, thank you! I was going to approve/push, but it's
probably better for Jonathan to give the final okay.
Just one
Hi, Robin.
+ machine_mode vmode;
+ switch (mode)
+{
+ case QImode:
+ vmode = E_RVVM1QImode;
+ break;
+ case HImode:
+ vmode = E_RVVM1HImode;
+ break;
+ case SImode:
+ vmode = E_RVVM1SImode;
+ break;
+ case DImode:
+ vmode = E_RVVM1DImode;
+ break;
+ default:
+
Snapshot gcc-11-20231026 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20231026/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Notice we calculate LMUL according to --param=riscv-autovec-lmul
in multiple places: int lmul = riscv_autovec_lmul == RVV_DYNAMIC ? RVV_M8 :
riscv_autovec_lmul;
Create a new macro for it for easier matain.
gcc/ChangeLog:
* config/riscv/riscv-opts.h (TARGET_MAX_LMUL): New macro.
On 26/10/23 10:35, Richard Biener wrote:
On Mon, Oct 23, 2023 at 2:57 AM Mark Harmstone wrote:
This patch and the following add initial support for Microsoft's
CodeView debugging format, as used by MSVC, to mingw targets.
A high-level question - it seems there's almost no information in the
On Thu, 26 Oct 2023, Patrick Palka wrote:
> On Thu, 26 Oct 2023, Jason Merrill wrote:
>
> > On 10/25/23 14:55, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
> > >
> > > Now that we don't have to worry about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Roger Sayle changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
On Thu, 26 Oct 2023, Jason Merrill wrote:
> On 10/25/23 14:55, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Now that we don't have to worry about looking thruogh NON_DEPENDENT_EXPR,
> > we can easily extend
On 8/28/23 06:34, Richard Biener wrote:
On Fri, 25 Aug 2023, Jakub Jelinek wrote:
Hi!
The following patch implements
CWG 2406 - [[fallthrough]] attribute and iteration statements
The genericization of some loops leaves nothing at all or just a label
after a body of a loop, so if the loop is
On 10/13/23 17:28, Lewis Hyatt wrote:
On Tue, Sep 12, 2023 at 04:09:21PM -0400, Lewis Hyatt wrote:
On Tue, Aug 8, 2023 at 5:53 PM Jason Merrill wrote:
On 7/31/23 22:22, Lewis Hyatt via Gcc-patches wrote:
`#pragma GCC target' is not currently handled in preprocess-only mode (e.g.,
when
From: Andrew Pinski
I noticed we were missing these simplifications so let's add them.
This adds the following simplifications:
U & N <= U -> true
U & N > U -> false
When U is known to be as non-negative.
When N is also known to be non-negative, this is also true:
U | N < U -> false
U | N
On 10/25/23 06:28, Alex Coplan wrote:
On 11/10/2023 14:31, Alex Coplan wrote:
On 27/09/2023 15:27, Alex Coplan wrote:
Hi,
This is a v4 patch to address Jason's feedback here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630911.html
w.r.t. v3 it just removes a comment now that
On Thu, 26 Oct 2023, Jason Merrill wrote:
> On 10/26/23 14:01, Patrick Palka wrote:
> > Since when in a template context we end up just discarding the result
> > of build_new_1, we don't have to bother with much of the code generation
> > it performs. This patch makes the function exit early,
On 10/25/23 14:55, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Now that we don't have to worry about looking thruogh NON_DEPENDENT_EXPR,
we can easily extend the -Wparentheses warning in convert_for_assignment
to consider
On 26/10/2023 12:43, Jonathan Wakely wrote:
On 26/10/23 07:18 +0200, François Dumont wrote:
libstdc++: [_Hashtable] Use RAII type to manage rehash functor state
Replace usage of __try/__catch with a RAII type to restore rehash
functor
state when needed.
Generally I really like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
These options both enabled more checking within the C++ standard library
and can expose errors in submitted code.
-D_GLIBCXX_DEBUG is mentioned separately because while we want people to try it,
it's not always feasible because it requires the whole program and any used
libraries to also be built
Dear all,
the attached patch improves the diagnostics of MODULE PROCEDURE declaration
conflicts, when one of the declarations is an alternate return. We used to
ICE before.
Steve identified the cause of the issue and provided a partial fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp
instead of strverscmp to check the mcpu version against feature
options. By simply changing the define to use strverscmp,
the new version 10.0 is treated correctly as a higher version
than previous versions.
Signed-off-by: Neal
On 10/26/23 14:01, Patrick Palka wrote:
Since when in a template context we end up just discarding the result
of build_new_1, we don't have to bother with much of the code generation
it performs. This patch makes the function exit early, returning a dummy
non-erroneous result, once we've done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.5
--- Comment #3 from Jonathan
> +(define_expand "vcond_mask_len_"
> + [(match_operand:V_VLS 0 "register_operand")
> + (match_operand: 3 "nonmemory_operand")
> + (match_operand:V_VLS 1 "nonmemory_operand")
> + (match_operand:V_VLS 2 "autovec_else_operand")
> + (match_operand 4 "autovec_length_operand")
> +
Hi,
this patch adds a vectorized rawmemchr expander.
It's basically strstr but for 8, 16 and 32-byte needles.
Apart from adjusting the common-code tests I re-used a
similar test that Stefan added to the s390 backend.
Regards
Robin
gcc/ChangeLog:
* config/riscv/autovec.md (rawmemchr):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112096
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> ```
> int t01(int x, int y)
> {
> bool t = x == 5 && y == 5;
> if (t) return 5; return y;
> } // y
> ```
> Is able to be detected in phiopt2. Just not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> It would need a completely new category of "memory location that you can
> read and write to but nothing else"
That was supposed to say "read and write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #3 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> Maybe some how libstdc++ debug mode can catch this
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/libstdc++/manual/manual/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #2 from Jonathan Wakely ---
(In reply to Jan Engelhardt from comment #0)
> ==55843==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xsomething
How would that even be possible? The terminating nul clearly has to be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112096
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-26
Ever confirmed|0
Tested x86_64-linux. Pushed to trunk. Worth backporting to all active
branches, I think.
-- >8 --
The incorrect errc constant here looks like a copy error.
libstdc++-v3/ChangeLog:
PR libstdc++/112089
* include/std/shared_mutex (shared_lock::unlock): Change errc
constant
Tested x86_64-linux. Pushed to trunk. Worth backporting to gcc-13 too.
-- >8 --
This avoids failures due to compilation timeouts when testing with a low
tool_timeout value.
libstdc++-v3/ChangeLog:
* testsuite/20_util/duration/io.cc: Double timeout using
dg-timeout-factor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:0c305f3dec9a992dd775a3b9607b7b1e8c051859
commit r14-4960-g0c305f3dec9a992dd775a3b9607b7b1e8c051859
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112101
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098
--- Comment #3 from Andrew Pinski ---
Trying 6, 7, 8 -> 9:
6: {r105:SI=r108:SI 0>>0x9;clobber flags:CC;}
REG_DEAD r108:SI
REG_UNUSED flags:CC
7: {r106:SI=r105:SI&0x1;clobber flags:CC;}
REG_DEAD r105:SI
REG_UNUSED
On Thu, 2023-10-19 at 10:02 -0400, David Malcolm wrote:
> This patch adds a new function attribute to GCC for marking that an
> argument is expected to be a null-terminated string.
>
> For example, consider:
>
> void test_a (const char *p)
> __attribute__((null_terminated_string_arg (1)));
Hi Richard,
> On 26 Oct 2023, at 20:49, Richard Sandiford wrote:
>
> Iain Sandoe writes:
>> This was written before Thomas' modification to the ELF-handling to allow
>> a config-based change for target details. I did consider updating this
>> to try and use that scheme, but I think that it
I guess that what Kees wanted, ""fill the array without knowing the actual
final size" code pattern”, as following:
>> struct foo *f;
>> char *p;
>> int i;
>>
>> f = alloc(maximum_possible);
>> f->count = 0;
>> p = f->buf;
>>
>> for (i; data_is_available() &&
Iain Sandoe writes:
> This was written before Thomas' modification to the ELF-handling to allow
> a config-based change for target details. I did consider updating this
> to try and use that scheme, but I think that it would sit a little
> awkwardly, since there are some differences in the
On 10/25/23 01:02, Neal Frager wrote:
The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp
instead of strverscmp to check the mcpu version against feature
options. By simply changing the define to use strverscmp,
the new version 10.0 is treated correctly as a higher version
than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111530
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #2
Iain Sandoe writes:
> tested on cfarm185 (aarch64-linux-gnu, xgene1) and with the aarch64
> Darwin prototype. It is possible that some initial fallout could occur
> on some test setups (where the default has been catered for in some
> way) - but that should stabilize. OK for trunk?
> thanks
>
This is an enablement patch (the initial use comes with the Darwin aarch64
port). Tested on aarch64-linux-gnu, aarch64-apple-darwin and x86_64-darwin
just for good measure, OK for trunk?
thanks
Iain.
--- 8< ---
Some assmblers have a bug that requires +crc to be emitted even
though the base
On Thu, Oct 26, 2023 at 12:18 PM Sam James wrote:
>
> These options both enabled more checking within the C++ standard library
> and can expose errors in submitted code.
>
> -D_GLIBCXX_DEBUG is mentioned separately because while we want people to try
> it,
> it's not always feasible because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
Andrew Pinski changed:
What|Removed |Added
Component|sanitizer |libstdc++
--- Comment #1 from Andrew
Hi,
as long as we do not have universal Zvfh support in binutils
linking against libm does not work out of the box. This patch
splits the cond_sqrt tests into non-zvfh and zvfh variants and
makes the run-zvfh ones depend on a zvfh target.
While at it, I also added Zvfh handling to the testsuite
This was written before Thomas' modification to the ELF-handling to allow
a config-based change for target details. I did consider updating this
to try and use that scheme, but I think that it would sit a little
awkwardly, since there are some differences in the start-up scanning for
Mach-O. I
Hi Paul,
this looks all good to me.
It is great that you added the handling of nested parentheses to the
resolution, as that appears to be needed also in other situations.
Thanks for the patch!
Harald
On 10/26/23 19:14, Paul Richard Thomas wrote:
Hi All,
The attached patch fixes the
> On Oct 26, 2023, at 1:05 PM, Martin Uecker wrote:
>
> Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao:
>>
>>> On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
On Wed, Oct 25, 2023 at 8:16 PM
These options both enabled more checking within the C++ standard library
and can expose errors in submitted code.
-D_GLIBCXX_DEBUG is mentioned separately because while we want people to try it,
it's not always feasible because it requires the whole program and any used
libraries to also be built
Jonathan Wakely writes:
> On Thursday, 26 October 2023, Sam James wrote:
>> These options both enabled more checking within the C++ standard library
>> and can expose errors in submitted code.
>>
>> -D_GLIBCXX_DEBUG is mentioned separately because while we want people to try
>> it,
>> it's
On Thursday, 26 October 2023, Sam James wrote:
> These options both enabled more checking within the C++ standard library
> and can expose errors in submitted code.
>
> -D_GLIBCXX_DEBUG is mentioned separately because while we want people to
try it,
> it's not always feasible because it requires
On Thu, Oct 26, 2023 at 11:58 AM Iain Sandoe wrote:
>
> tested on cfarm185 (aarch64-linux-gnu, xgene1) and with the aarch64
> Darwin prototype. It is possible that some initial fallout could occur
> on some test setups (where the default has been catered for in some
> way) - but that should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #8 from Kaze Emanuar ---
This code is just an example, but I have seen this issue appear in many of my
collision functions. I agree it's not a huge issue in my use case, but it'd
still be cool to have this work well. I can work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111957
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111957
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:662655e22dddf5392d9aa67fce45beee980e5454
commit r14-4955-g662655e22dddf5392d9aa67fce45beee980e5454
Author: Andrew Pinski
Date:
tested on cfarm185 (aarch64-linux-gnu, xgene1) and with the aarch64
Darwin prototype. It is possible that some initial fallout could occur
on some test setups (where the default has been catered for in some
way) - but that should stabilize. OK for trunk?
thanks
Iain
--- 8< ---
When the
On Sun, Oct 15, 2023 at 12:40 PM Arsen Arsenović wrote:
>
> Evening,
>
> Arsen Arsenović writes:
>
> > Afternoon,
> >
> > This patch is a rebase and rewording of
> > https://inbox.sourceware.org/20230925150921.894157-1-ar...@aarsen.me/
> >
> > Changes since v1:
> > - Implement Brunos suggested
> On Oct 26, 2023, at 10:05 AM, Richard Biener
> wrote:
>
>
>
>> Am 26.10.2023 um 12:14 schrieb Martin Uecker :
>>
>> Am Donnerstag, dem 26.10.2023 um 11:20 +0200 schrieb Martin Uecker:
Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
On Wed, Oct 25, 2023 at
On Thu, Oct 26, 2023 at 11:01 AM Simon Sobisch via Gcc wrote:
>
> https://gcc.gnu.org/install/prerequisites.html has a bunch of tools
> under "Tools/packages necessary for modifying GCC", but GNU Bison is
> missing.
>
> I found it interesting to see that some files like under intl say
> 1 /*
This patch fixes an issue with the cost on "int_div" in various RISC-V
tune parameters including those for Rocket, SiFive U7 series, and T-Head
C906. This incorrect cost value interferes with the optimization process.
For example, it prevents the optimization of division by a constant to a
more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #7 from Andrew Pinski ---
Also is this function from real code or just an example to show the issue?
I suspect in real code you either have 2 extra nops or a scheduling bubble. the
nops might not make a huge difference ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111969
--- Comment #6 from Patrick O'Neill ---
Mixed up my hashes when copy/pasting.
r14-4875-g9cf2e7441ee passes locally/CI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #6 from Andrew Pinski ---
It just happened the scheduler didn't schedule it that way. Scheduling is NP
complete problem too.
1 - 100 of 254 matches
Mail list logo
