https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
--- Comment #11 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113219
--- Comment #2 from m.cencora at gmail dot com ---
So I guess this falls into the "confusing overload resolution for user-defined
conversion" but I fail to see what can be confusing here.
createInt() returns prvalue, so later it binds to xvalue f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
Bug ID: 113229
Summary: [14 Regression] gcc.dg/torture/pr70083.c ICEs when
compiled with -march=armv9-a+sve2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #11 from m.cencora at gmail dot com ---
This is surprising to say the least because apparently for following code
(where both conversion operators return same type) the compiler somehow
correctly chooses && qualified overload:
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
--- Comment #2 from Andrew Pinski ---
gcc.target/aarch64/pr70120-1.c ICEs in a similar way too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
Andrew Pinski changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230
Bug ID: 113230
Summary: 27_io/print/1.cc fails when run with qemu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
Bug ID: 113231
Summary: x86_64 use MMX instructions for simple shift
operations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
--- Comment #1 from Andrew Pinski ---
xmm0 is sse registers rather than mmx :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
Andrew Pinski changed:
What|Removed |Added
Summary|x86_64 use MMX instructions |x86_64 uses SSE
|for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #5 from Mikael Pettersson ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641800.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60031
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113217
--- Comment #4 from Alex Coplan ---
Looks like the fix in r14-6784-gaca1f9d7cab3dc1a374a7dc0ec6f7a8d02d2869a wasn't
sufficient to prevent trying to move throwing accesses above debug insns. ICEs
with just -O -fnon-call-exceptions -g. I'll see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #25 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:3ac58063114cf491891072be6205d32a42c6707d
commit r14-6915-g3ac58063114cf491891072be6205d32a42c6707d
Author: Roger Sayle
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
YunQiang Su changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113184
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113184
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113232
Bug ID: 113232
Summary: wrong code at -fpack-struct on x86_64-pc-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] ICE: in |[13/14 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
--- Comment #4 from Jakub Jelinek ---
(In reply to Manuel Lauss from comment #2)
> I'm seeing similar ICE in xgcc when trying to build GCC-14 for MIPS32;
> it goes away when I drop "-fPIC" or "-march=mips32":
Please file this separately, that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
Uroš Bizjak changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #56 from Richard Earnshaw ---
I've never heard of a memcpy implementation that corrupts data if called with
memcpy (p, p, n). (The problems come from partial overlaps where the direction
of the copy may matter).
Has anybody consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230
--- Comment #1 from Jonathan Wakely ---
But any single character should match "." in the regex. Is the output being
converted (somewhere) from Latin-1 to UTF-8 which means that "À" becomes more
than one byte, and the regex doesn't match?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
Bug ID: 113233
Summary: LoongArch: target options from LTO objects not
respected during linking
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #1 from Yang Yujie ---
I've already made a patch for this, will push it to gcc-patc...@gcc.gnu.org
later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230
--- Comment #2 from Jonathan Wakely ---
The point of the test is to write out a byte that isn't valid UTF-8, and check
that it's printed unchanged, as a single byte. If something does some kind of
iconv-like conversion on the test output and "fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #57 from Rich Felker ---
I think one could reasonably envision an implementation that does some sort of
vector loads/stores where, due to some performance constraint or avoiding
special casing for possible page boundary past the end o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
Xi Ruoyao changed:
What|Removed |Added
Target||loongarch*
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #58 from Jakub Jelinek ---
(In reply to Rich Felker from comment #57)
> and more concerned about the consequences of LTO/whole-program-analysis where
> something in the translation process can see the violated restrict
> qualifier, in
> Confirm. But option save/restore has been always implemented:
>
> .section.gnu.lto_.opts,"",@progbits
> .ascii "'-fno-openmp' '-fno-openacc' '-fno-pie' '-fcf-protection"
> .ascii "=none' '-mabi=lp64d' '-march=loongarch64' '-mfpu=64' '-m"
> .ascii "simd=lasx' '-mcmodel=nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #3 from Jan Hubicka ---
> Confirm. But option save/restore has been always implemented:
>
> .section.gnu.lto_.opts,"",@progbits
> .ascii "'-fno-openmp' '-fno-openacc' '-fno-pie' '-fcf-protection"
> .ascii "=none'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #4 from Xi Ruoyao ---
(In reply to Jan Hubicka from comment #3)
> > Confirm. But option save/restore has been always implemented:
> >
> > .section.gnu.lto_.opts,"",@progbits
> > .ascii "'-fno-openmp' '-fno-openacc' '-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #5 from Xi Ruoyao ---
Note that x86 also passes the recorded -mavx2 etc. to lto1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113222
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:db5b01d282a0e3ddcac737e55f9758c8b081cf4b
commit r14-6917-gdb5b01d282a0e3ddcac737e55f9758c8b081cf4b
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112790
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:5743e1899d596497800f7d6f4273d535ea0abcdd
commit r14-6918-g5743e1899d596497800f7d6f4273d535ea0abcdd
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112790
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:05c99b1c7965f46f0ff17d5e8f4020a62c643ae5
commit r14-6919-g05c99b1c7965f46f0ff17d5e8f4020a62c643ae5
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #59 from Richard Earnshaw ---
Memcpy must never write beyond the end of the specified buffer, even if reading
it is safe. That wouldn't be thread safe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #60 from Rich Felker ---
Nobody said anything about writing past end of buffer. Obviously you can't do
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #61 from Richard Earnshaw ---
Then I don't understand what you're trying to say in c57.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #62 from Rich Felker ---
The process described there would have to end at least N bits before the end of
the destination buffer. The point was that it would destroy information
internal to the buffer at each step along the way, before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230
--- Comment #3 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #2)
> The point of the test is to write out a byte that isn't valid UTF-8, and
> check that it's printed unchanged, as a single byte. If something does some
> kind o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113234
Bug ID: 113234
Summary: missing folding to builtin_isunordered if manual nan
comparison is used
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113222
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
Bug 106358 depends on bug 113222, which changed state.
Bug 113222 Summary: ICE with -fanalyzer seen on Linux kernel kernel/sched/core.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113222
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113232
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112790
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230
--- Comment #4 from Andreas Schwab ---
What does "run with qemu" mean exactly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #6 from Jan Hubicka ---
> which fixes the ICE by preferring PRED_BUILTIN_EXPECT* over others.
> At least in this case when one operand is a constant and another one is
> __builtin_expect* result that seems like the right choice to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #7 from Jakub Jelinek ---
So, what about following patch (which also fixes the ICE, would of course need
to add the testcase) and doesn't regress any predict-*.c tests)?
--- gcc/predict.cc.jj 2024-01-03 11:51:32.0 +0100
++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113234
--- Comment #1 from Joseph S. Myers ---
Note that if flag_signaling_nans, __builtin_isnan should not raise exceptions
for signaling NaN argument (bug 66462), but ==, != and __builtin_isunordered
should raise exceptions for signaling NaN argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230
--- Comment #5 from Andrew Pinski ---
Created attachment 56988
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56988&action=edit
dejagnu board that I use
And run the testsuite like:
export SIM_ARM=qemu-aarch64
export QEMU_LD_PREFIX=${SYSRO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113234
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804
Filip Kastl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113217
--- Comment #5 from Andrew Pinski ---
(In reply to Alex Coplan from comment #4)
> Looks like the fix in r14-6784-gaca1f9d7cab3dc1a374a7dc0ec6f7a8d02d2869a
> wasn't sufficient to prevent trying to move throwing accesses above debug
> insns. ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #8 from Jakub Jelinek ---
Created attachment 56989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56989&action=edit
gcc14-pr110852.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #9 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
>
> --- Comment #7 from Jakub Jelinek ---
> So, what about following patch (which also fixes the ICE, would of course need
> to add the testcase) and doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #11 from Mikael Pettersson ---
Reduced test case:
> cat ../pr110934.c
extern double clobber_fp0(void);
void f(void) { clobber_fp0(); }
> gcc/xgcc -Bgcc -fzero-call-used-regs=used -fPIC -O -S ../pr110934.c
during RTL pass: zero_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #10 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #9)
> By removing the logic we lose ability to optimize things like
> a = b * c;
> where b is predicted to value 0 and c has no useful prediction on it.
No, that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113228
--- Comment #8 from Patrick O'Neill ---
(In reply to Andrew Pinski from comment #7)
> This seems like a reduced testcase, where is the original testcase from? Or
> is it an automated code generator?
This was found with the fuzzer we're using to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
Roger Sayle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #11 from Jan Hubicka ---
> > + int p1 = get_predictor_value (*predictor, *probability);
> > + int p2 = get_predictor_value (predictor2, probability2);
> > + /* If both predictors agrees, it does not matter fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113228
--- Comment #9 from Andrew Pinski ---
(In reply to Patrick O'Neill from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > This seems like a reduced testcase, where is the original testcase from? Or
> > is it an automated code generat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113228
--- Comment #10 from Patrick O'Neill ---
(In reply to Andrew Pinski from comment #9)
> Oh ok, I was deciding if I should look further into this or let someone else
> handle it. Since it is from a fuzzer, I am just going to say I don't have
> tim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #12 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #11)
> I added the early exits to handle the following case.
>
> a = b * c
>
> If b is prediced to 0 with predictor1, while c is predicted to 1 with
> predictor2 your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #13 from Jakub Jelinek ---
But, when you are touching the PHI case, I think
/* If this PHI has itself as an argument, we cannot
determine the string length of this argument. However,
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206
--- Comment #9 from Patrick O'Neill ---
(In reply to JuzheZhong from comment #8)
> It seems that we still didn't locate the real problem of failed SPEC you ran.
> Do you have any other ideas to locale the real problem ?
>
> Li Pan didn't locate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235
Bug ID: 113235
Summary: SMHasher SHA3-256 benchmark is almost 40% slower vs.
Clang on AMD Zen 4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
--- Comment #3 from Jerry DeLisle ---
Created attachment 56990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56990&action=edit
Suggested patch including affected test cases
Regression tested OK. Three test cases affected.
$ git status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103500
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #3 from Alex Coplan ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113236
Bug ID: 113236
Summary: WebP benchmark is 20% slower vs. Clang on AMD Zen 4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226
--- Comment #2 from Patrick Palka ---
(In reply to Patrick Palka from comment #1)
> Huh, how bizarre.
>
> > i == 1, j == -100, i*j == 4294967196, max_type(i) == 1, max_type(i)*j ==
> > -100
>
> Here i and j are just ordinary 'long long', so I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235
--- Comment #1 from Artem S. Tashkinov ---
Also valid for MTL:
https://www.phoronix.com/review/intel-meteorlake-gcc-clang/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113236
--- Comment #1 from Artem S. Tashkinov ---
That's WebP image encode, Quality 100, highest compression.
Also applies to MTL:
https://www.phoronix.com/review/intel-meteorlake-gcc-clang/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852
--- Comment #14 from Jan Hubicka ---
> I thought the goal was to handle what is in predict-18.c, i.e.
> b * __builtin_expect (c, 0)
> or similar. If it is about
> __builtin_expect_with_probability (b, 42, 0.25) *
> __builtin_expect_with_probabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235
--- Comment #2 from Xi Ruoyao ---
The test file can be downloaded from
http://phoronix-test-suite.com/benchmark-files/smhasher-20220822.tar.xz. Just
build it with cmake and run "./SMHasher --test=Speed sha3-256". The building
system enables -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #27 from Patrick O'Neill ---
Linking the discussion/plan here since more interested people are CCd here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
--- Comment #7 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #6)
> Started with r11-2446-g3e61a2056335ca7d4e2009823efae4ee2dc950ee
Note r10-9757-gec97d2e842022a3f112e27d6d8 is the backported to the GCC 10
branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
Bug ID: 113237
Summary: [14 Regression] ICE verify_ssa failed when building
500.perlbench_r since r14-6822-g01f4251b8775c8
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226
--- Comment #3 from Hans-Peter Nilsson ---
(In reply to Patrick Palka from comment #1)
> Huh, how bizarre.
Indeed. I'm *not* ruling out an actual gcc bug. Whether in the target or
middle-end this time I dare not guess; too few posts.
JFTR; I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
--- Comment #1 from Tamar Christina ---
> I have bisected the failure to r14-6822-g01f4251b8775c8 (middle-end: Support
> vectorization of loops with multiple exits). I have tried if the patch
> attached to PR 113137 helps but unfortunately it d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
--- Comment #2 from Tamar Christina ---
Ah wait, I see. Ok, taking a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #3)
> Created attachment 56990 [details]
> Suggested patch including affected test cases
>
> Regression tested OK. Three test cases affected.
>
Thanks, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
Tamar Christina changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436
--- Comment #8 from Florian Schanda ---
I am no longer working at BMW.
For safety topics please contact alexander.schem...@bmw.de or
markus.schur...@bmw.de
For TRLC and LOBSTER topics please contact philipp.wullstein-kamm...@bmw.de or
create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113238
Bug ID: 113238
Summary: [14] RISC-V: gcc.dg vect-tsvc flakey test timeouts
when under heavy workload
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113238
--- Comment #1 from Edwin Lu ---
Debug log for one of the flakey tests
spawn -ignore SIGHUP
/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/xgcc
-B/github/patric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
Bug ID: 113239
Summary: [13 regression] After 822a11a1e64, bogus
-Warray-bounds warnings in std::vector
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113238
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:97def769e6b28832f5ba4087d6fcdd44e18bf005
commit r14-6927-g97def769e6b28832f5ba4087d6fcdd44e18bf005
Author: Andrew Pinski
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
--- Comment #1 from Andrew Pinski ---
So I suspect it is either inlining differences due to slightly increased sizes
in some cases or jump threading due to the extra check. I highly doubt that
patch is underlying cause of the warning ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86152
Hannes Domani changed:
What|Removed |Added
CC||ssbssa at yahoo dot de
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
Paul M. Bendixen changed:
What|Removed |Added
CC||paulbendixen at gmail dot com
--- Co
1 - 100 of 112 matches
Mail list logo
