https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29040
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
On Fri, Feb 16, 2024 at 07:52:17PM +0200, Dimitar Dimitrov wrote:
> The issue in PR112344 is triggered only at -O2, so there is little value
> in running the test at lower optimization levels. At the same time the
That is generally not true.
We had hundreds of cases in the history where a test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26278
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
Marek Polacek changed:
What|Removed |Added
Resolution|--- |WORKSFORME
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17000
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #10 from Arthur O'Dwyer ---
FWIW, I think I agree with your analysis. To reiterate what you already said
(and I think GCC already gets the following snippet correct): in
X g (X x) try {
throw x;
} catch (...) {
The issue in PR112344 is triggered only at -O2, so there is little value
in running the test at lower optimization levels. At the same time the
generated code at low and code-size optimization levels is taking a long
time to execute because it loops a few billion iterations.
On the PRU simulator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111682
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #7 from Antoni ---
I don't know if this helps, but I added a small Rust reproducer that can
trigger the segfault when compiled with rustc_codegen_gcc and the corresponding
GIMPLE for this Rust reproducer.
Fixed by the PR113612 fix r14-8960-g19ac327de421fe.
PR c++/111682
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ86.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/var-templ86.C | 23 +++
1 file changed, 23 insertions(+)
create mode 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111682
--- Comment #2 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:c95dc611a6203f0564722975acff4ad866b9c45e
commit r14-9035-gc95dc611a6203f0564722975acff4ad866b9c45e
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #6 from Antoni ---
Created attachment 57439
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57439=edit
Rust reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #5 from Antoni ---
Created attachment 57438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57438=edit
GIMPLE for the Rust reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:e501a279fb4298c9b23637d573287e059b3b06c8
commit r13-8336-ge501a279fb4298c9b23637d573287e059b3b06c8
Author: Marek Polacek
An update to the 5th version of the patches:
Kees helped me to do more testings, and found one issue:
===
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113158
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Marek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Summary|[13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98388
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:254ff3d0e34835b4de93d5e5763a7366dc7d989d
commit r14-9034-g254ff3d0e34835b4de93d5e5763a7366dc7d989d
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:254ff3d0e34835b4de93d5e5763a7366dc7d989d
commit r14-9034-g254ff3d0e34835b4de93d5e5763a7366dc7d989d
Author: Marek Polacek
Date:
On 2/16/24 10:58, Marek Polacek wrote:
On Thu, Feb 15, 2024 at 04:36:40PM -0500, Jason Merrill wrote:
On 2/15/24 10:19, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we have
template
auto is_throwable(T t) -> decltype(throw t, true) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #46 from Andrew Macleod ---
(In reply to Jan Hubicka from comment #43)
> > // See discussion here:
> > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
> Discussion says:
>
> "Once legacy evrp is removed, this
On Fri, 16 Feb 2024, Jakub Jelinek wrote:
> > There is no function prologue to optimise in the VAX case, because all
> > the frame setup has already been made by the CALLS instruction itself in
> > the caller. The first machine instruction of the callee is technically
> > already past the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104919
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #45 from Jan Hubicka ---
> > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL
> > will tell the truth. However, this will mean that we will no longer
> > remove the first __builtin_unreachable combo. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5286b0761b5dfac4348d1c5bfdcc162a66f338ee
commit r14-9033-g5286b0761b5dfac4348d1c5bfdcc162a66f338ee
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752
--- Comment #7 from Marek Polacek ---
Comment 5 test was fixed by r14-5979-g99d114c15523e0
commit 99d114c15523e0bfe7a89ef1947f82eb5ff0260b
Author: Marek Polacek
Date: Fri Nov 17 14:48:44 2023 -0500
c++: P2280R4, Using unknown refs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961
--- Comment #1 from seurer at gcc dot gnu.org ---
< previous run: g:1aef0a9b07766d100a218ef3e9576d0a0dd35a2d,
r14-9027-g1aef0a9b07766d
> this run: g:7f3d900684ad989164114f25eb46a33871c6533d,
r14-9028-g7f3d900684ad98
< FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
--- Comment #5 from Jan Hubicka ---
I don't think we can reasonably expect every caller of lambda function to be
early inlined, so we need to extend ipa-prop to understand the obfuscated code.
I disucussed that with Martin some time ago - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213
David Malcolm changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #4 from David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #5 from Jan Hubicka ---
hmm. cfg.cc:815 for me is:
fputs (", maybe hot", outf);
which seems quite safe.
The problem does not seem to reproduce for me:
jh@ryzen3:~/gcc/build/gcc> ./xgcc -B ./ tt.c -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #43 from Jan Hubicka ---
> // See discussion here:
> // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
Discussion says:
"Once legacy evrp is removed, this won't be an issue, as ranges in the IL
will tell the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961
Bug ID: 113961
Summary: [14 regression] 26_numerics/random/pr60037-neg.cc
fails in new place after r14-9028-g7f3d900684ad98
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
On Thu, Feb 15, 2024 at 04:36:40PM -0500, Jason Merrill wrote:
> On 2/15/24 10:19, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Here we have
> >
> >template
> >auto is_throwable(T t) -> decltype(throw t, true) { ... }
> >
> >
Hi!
Ah, and the reason why it doesn't work on target is that it has the
everything is mapped assumption:
if ((ctx->region_type & ORT_TARGET) != 0)
{
if (ctx->region_type & ORT_ACC)
/* For OpenACC, as remarked above, defer expansion. */
shared = false;
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #42 from Jakub Jelinek ---
So guess we need to union the ranges and for earlier gccs also the zero bits
stuff upon ICF, right?
On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
> On 2/16/24 04:14, Jakub Jelinek wrote:
> > DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
> > we emit it), but also on anonymous unions/structs (and we didn't emit that
> > attribute there).
> > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jan Hubicka changed:
What|Removed |Added
Summary|[14 regression] ICU |[12/13/14 regression] ICU
On 2/16/24 07:56, Iain Sandoe wrote:
tested on x86_64-darwin, so far. OK for trunk if regression test is
successful on Linux too?
thanks
Iain
--- 8< ---
r14-5310-g879cf9ff45d940 introduced some new handling for spawning sub
processes. The return value from the generic exec_child is
On 2/16/24 04:14, Jakub Jelinek wrote:
Hi!
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it), but also on anonymous unions/structs (and we didn't emit that
attribute there).
The following patch fixes it.
Should this involve cp_decl_dwarf_attribute like the
On Fri, Feb 16, 2024 at 04:15:05PM +0100, Tobias Burnus wrote:
> I have no idea whether that would - nor whether that would be
> the way forward. - Thoughts?
Don't have time to dive through this now in detail, just want to point out
why we ignore DECL_VALUE_EXPR on the magic var during
The following works with PARALLEL but not with TARGET.
OpenMP states the following is supposed to work:
A = 5; // == this->A
B = 6; // == this->B
C[44] = 7; // == this->C; assume 'int C[100]'
#pragma firstprivate(A,C) private(B)
{
A += 5; // Now: A is 10.
B = 7;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113294
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113294
--- Comment #4 from GCC Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:ebe00c9d3a0436dec5c354a62d98e444d763ff95
commit r13-8335-gebe00c9d3a0436dec5c354a62d98e444d763ff95
Author: Paul Keir
On 2/16/24 04:21, Jakub Jelinek wrote:
Hi!
For template parameters, the optional this specifier is in the grammar
template-parameter-list -> template-parameter -> parameter-declaration,
just [dcl.fct/6] says that it is only valid in parameter-list of certain
functions. So, unlike the case of
On Fri, 16 Feb 2024 at 14:10, Jakub Jelinek wrote:
>
> On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> > Ah, although __atomic_compare_exchange only takes pointers, the
> > compiler replaces that with a call to __atomic_compare_exchange_n
> > which takes the newval by value,
The following works with PARALLEL but not with TARGET.
OpenMP states the following is supposed to work:
A = 5; // == this->A
B = 6; // == this->B
C[44] = 7; // == this->C; assume 'int C[100]'
#pragma firstprivate(A,C) private(B)
{
A += 5; // Now: A is 10.
B = 7;
C[44]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #24 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:3a72c717b311ce8093042d927a1f2f2b940a969c
commit r13-8334-g3a72c717b311ce8093042d927a1f2f2b940a969c
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #40 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #39)
> This testcase
> #include
> int data[100];
>
> __attribute__((noinline))
> int bar (int d, unsigned int d2)
> {
> if (d2 > 10)
> printf ("Bingo\n");
>
On Thu, 15 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> One would expect consecutive calls to bytes_in/out::b for streaming
> adjacent bits, as we do for tree flag streaming, to at least be
> optimized by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Iain Sandoe changed:
What|Removed |Added
Component|c++ |other
Keywords|wrong-code
tested on x86_64-darwin, so far. OK for trunk if regression test is
successful on Linux too?
thanks
Iain
--- 8< ---
r14-5310-g879cf9ff45d940 introduced some new handling for spawning sub
processes. The return value from the generic exec_child is examined
and needs to be < 0 to signal an error.
> On Feb 16, 2024, at 6:34 AM, Maciej W. Rozycki wrote:
>
> On Thu, 15 Feb 2024, Paul Koning wrote:
>
>>> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote:
>>>
>>> ...
>>>
>>> I may choose to implement a non-DWARF unwinder instead, as the VAX stack
>>> frame is always fully described
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54052
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
* Andi Kleen via Gcc:
>> ***This is NodeNumber0
>> (0x7f12e13b0d00) NodeNumber0
>> tree_code: function_decl
>> tree_code_class: tcc_declaration
>
> My suggestion if you go this route would be to generate
> some standard format like YAML or JSON that other tools
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #39 from Jan Hubicka ---
This testcase
#include
int data[100];
__attribute__((noinline))
int bar (int d, unsigned int d2)
{
if (d2 > 10)
printf ("Bingo\n");
return d + d2;
}
int
test2 (unsigned int i)
{
if (i > 10)
On 16/02/2024 14:34, Thomas Schwinge wrote:
Hi!
On 2024-01-29T11:34:05+0100, Tobias Burnus wrote:
Andrew wrote off list:
"Vector reductions don't work on RDNA, as is, but they're
supposed to be disabled by the insn condition"
This patch disables "fold_left_plus_", which is about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
David Malcolm changed:
What|Removed |Added
Resolution|--- |WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562
Bug 108562 depends on bug 105755, which changed state.
Bug 105755 Summary: -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
--- Comment #3 from David Malcolm ---
Current status of reproducer on Compiler Explorer:
GCC trunk: no warning: https://godbolt.org/z/o6ecKKa8e
GCC 13.2: no warning: https://godbolt.org/z/z7hdYx1Y7
GCC 12.3: false +ve:
Hi!
On 2024-01-29T11:34:05+0100, Tobias Burnus wrote:
> Andrew wrote off list:
>"Vector reductions don't work on RDNA, as is, but they're
> supposed to be disabled by the insn condition"
>
> This patch disables "fold_left_plus_", which is about
> vectorization and in the code path shown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
Bug ID: 113960
Summary: std::map with std::vector as input overwrites itself
with c++20, on s390x platform
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
On Fri, Feb 16, 2024 at 02:23:54PM +, Maciej W. Rozycki wrote:
> On Fri, 16 Feb 2024, Segher Boessenkool wrote:
>
> > > Conversely no heuristics is required to unwind VAX frames, because they
> > > are fixed in layout by hardware, fully self-described, and with the
> > > hardware frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
--- Comment #1 from Iain Sandoe ---
the problem is that liberty is using the value set by posix_spawnp for pid.
but:
(darwin):
The argument pid is a pointer to a pid_t variable to receive the pid of
the spawned process; if this is NULL,
On Fri, 16 Feb 2024, Segher Boessenkool wrote:
> > Conversely no heuristics is required to unwind VAX frames, because they
> > are fixed in layout by hardware, fully self-described, and with the
> > hardware frame pointer always available.
>
> The downside of the VAX situation of course is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959
Bug ID: 113959
Summary: Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to
`__builtin_isfinite(x)`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105961
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #21
On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> Ah, although __atomic_compare_exchange only takes pointers, the
> compiler replaces that with a call to __atomic_compare_exchange_n
> which takes the newval by value, which presumably uses an 80-bit FP
> register and so the padding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109251
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113314
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Hi!
On 2024-02-16T12:41:06+, Andrew Stubbs wrote:
> On 16/02/2024 12:26, Richard Biener wrote:
>> On Fri, 16 Feb 2024, Andrew Stubbs wrote:
>>> On 16/02/2024 10:17, Richard Biener wrote:
On Fri, 16 Feb 2024, Thomas Schwinge wrote:
> On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
On Fri, 16 Feb 2024 at 12:38, Jonathan Wakely wrote:
>
> On Fri, 2 Feb 2024 at 16:52, xndcn wrote:
> >
> > Thank you for your careful review!
> >
> > > But we don't need a new one if it's going to be used in exactly one test
> > > and if the new option does the same thing for all targets that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2010-06-17 10:36:48 |2024-2-16
--- Comment #40 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #1 from Georg-Johann Lay ---
What's the LRA way to do LEGITIMIZE_RELOAD_ADDRESS?
On Fri, Feb 16, 2024 at 11:34:55AM +, Maciej W. Rozycki wrote:
> Not really, in particular because EH unwinding has to be reliable and
> heuristics inherently is not.
Yup. Which is why I did 0359465c703a for rs6000 six years ago (how time
flies!) The commit message for that includes
> On 15 Feb 2024, at 18:05, Richard Sandiford wrote:
>
> Iain Sandoe writes:
>>> On 5 Feb 2024, at 14:56, Iain Sandoe wrote:
>>>
>>> Tested on aarch64-linux,darwin and a cross from aarch64-darwin to linux,
>>> OK for trunk, or some alternative is needed?
>>
>> Hmm.. apparently, this fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113503
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
Rainer Orth changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
--- Comment #5 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:7c6071a66f32f43cea7aa4aa32d89b338e768307
commit r14-9030-g7c6071a66f32f43cea7aa4aa32d89b338e768307
Author: Rainer Orth
Date: Fri
Hi Jakub,
> On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
>> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>>
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
>> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #17 from Richard Biener ---
The following still helps quite a bit on its own.
diff --git a/gcc/bitmap.cc b/gcc/bitmap.cc
index 459e32c1ad1..a05ad810800 100644
--- a/gcc/bitmap.cc
+++ b/gcc/bitmap.cc
@@ -2695,18 +2695,21 @@
On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
> FAIL:
The following addresses the weak bitmap_hash function which results
in points-to analysis taking a long time because of a high collision
rate in one of its bitmap hash tables. Using a better hash function
like in the bitmap.cc hunk below doesn't help unless one also replaces
the hash function in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113503
--- Comment #5 from Jakub Jelinek ---
For the warning case, I think
--- gcc/fortran/trans-expr.cc.jj2024-02-14 14:26:19.764810614 +0100
+++ gcc/fortran/trans-expr.cc 2024-02-16 13:22:48.693104239 +0100
@@ -9253,19 +9253,20 @@
On 16/02/2024 12:26, Richard Biener wrote:
On Fri, 16 Feb 2024, Andrew Stubbs wrote:
On 16/02/2024 10:17, Richard Biener wrote:
On Fri, 16 Feb 2024, Thomas Schwinge wrote:
Hi!
On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
I've committed this patch
... as commit
On Fri, 2 Feb 2024 at 16:52, xndcn wrote:
>
> Thank you for your careful review!
>
> > But we don't need a new one if it's going to be used in exactly one test
> > and if the new option does the same thing for all targets that run the test.
> Got it, thanks. Now add option "-latomic" directly,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
Rainer Orth changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org
Last
c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 execution test
FAIL:
On Fri, 16 Feb 2024, Andrew Stubbs wrote:
> On 16/02/2024 10:17, Richard Biener wrote:
> > On Fri, 16 Feb 2024, Thomas Schwinge wrote:
> >
> >> Hi!
> >>
> >> On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
> >>> I've committed this patch
> >>
> >> ... as commit
101 - 200 of 245 matches
Mail list logo
