https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112394
--- Comment #2 from Hongyu Wang ---
Should be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112394
--- Comment #1 from CVS Commits ---
The master branch has been updated by Hongyu Wang :
https://gcc.gnu.org/g:ca281a7b97163273de9d73da556fb3f6dcc3b61b
commit r14-5242-gca281a7b97163273de9d73da556fb3f6dcc3b61b
Author: Hongyu Wang
Date: Tue N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #7 from JuzheZhong ---
(In reply to Kito Cheng from comment #6)
> The key is the splat of VLMAX instruction need move into loop body, but AVL
> propagation should still able to do:
>
> ```
> foo(int, int*, int*):
> ble a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #6 from Kito Cheng ---
The key is the splat of VLMAX instruction need move into loop body, but AVL
propagation should still able to do:
```
foo(int, int*, int*):
ble a0,zero,.L5
csrra5,vlenb
srlia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #5 from Kito Cheng ---
Assume:
VLEN = 128 and n = 5, *in is {0, 0, 0, 0, 0}
so VLMAX = 4 for e32m1
It can be run with vl = 4 for first iteration, and vl = 1 vl for second
iteration
But it could be something like that: vl = 3 for f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #4 from JuzheZhong ---
Oh. I see what you mean.
I think it may not be the valid optimization.
Since the following codes:
.L3:
vsetvli a5,a0,e32,m1,ta,ma
sllia4,a5,2
vle32.v v1,0(a1)
sub a0,a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112340
Jiu Fu Guo changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432
--- Comment #2 from Li Pan ---
(In reply to Richard Biener from comment #1)
> Is there a corresponding C API? We don't have "generic" versions in
> builtins.def either (with _VAR).
>
> That said, what's the testcase here?
I found some FLOATN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #3 from JuzheZhong ---
You mean current codegen is bug ?
No, I don't think there is a bug in current codegen.
It's induction variable.
ble a0,zero,.L5
...
vsetvli a3,zero,e32,m1,ta,ma
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112361
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #2 from Kito Cheng ---
oh, but the root cause might be little bit deeper, not just the problem of
propagation or not propagation the AVL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112359
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
Bug ID: 112438
Summary: RISC-V: Failed to AVL propagation through induction
variable
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #12 from JuzheZhong ---
It should be fixed on the trunk.
Plz verify it and close the issue.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Lehua Ding :
https://gcc.gnu.org/g:f9148120048f4508156acfcd19a334f4dcbb96f0
commit r14-5239-gf9148120048f4508156acfcd19a334f4dcbb96f0
Author: Juzhe-Zhong
Date: Wed No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
--- Comment #12 from Haochen Jiang ---
Seems like we should prevent the optimization in that commit to register
x/ymm16+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907
--- Comment #8 from Haochen Jiang ---
Should be fixed on trunk now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907
--- Comment #7 from CVS Commits ---
The master branch has been updated by Haochen Jiang :
https://gcc.gnu.org/g:078087d1605060da4f993af83b1bfa351b278d38
commit r14-5238-g078087d1605060da4f993af83b1bfa351b278d38
Author: Haochen Jiang
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112437
--- Comment #2 from Andrew Pinski ---
The backtrace:
```
t55.cc:4:37: internal compiler error: Segmentation fault
4 | concept Throwable = requires(T x) { throw x; };
| ^~~
0x133b01f crash_signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112437
--- Comment #1 from Andrew Pinski ---
Maybe related to:
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-09/msg00226.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112436
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112437
Bug ID: 112437
Summary: ICE with throw inside concept sometimes and -std=c++20
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112436
Bug ID: 112436
Summary: SFINAE-unfriendly error on throwing pointer to
incomplete type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
Sam James changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112434
--- Comment #2 from Andrew Pinski ---
Oh wait is documented as a "generic" one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #10 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
--- Comment #12 from JuzheZhong ---
(In reply to Richard Sandiford from comment #10)
> Some of the SME changes I'm working on fix this, but I'm not sure how widely
> we'll be able to use them on non-SME code. Assigning myself just in case.
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #9 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
--- Comment #8 from Sam James ---
I've kicked off a reduction although I'm not really sure how it's going to turn
out...
I'll do a bisect while I wait.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112422
Sam James changed:
What|Removed |Added
Blocks||84402
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
--- Comment #6 from Andrew Pinski ---
#(insn:TI 48 192 56 6 (set (reg:V8SF 22 xmm2 [445])
#(vec_select:V8SF (vec_concat:V16SF (reg:V8SF 20 xmm0 [orig:442
MEM[(__m256_u * {ref-all})gridptr_432] ] [442])
#(reg:V8SF 53 xmm17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
--- Comment #5 from Andrew Pinski ---
vblendps$240, %ymm17, %ymm0, %ymm2
vblendps$240, %ymm1, %ymm17, %ymm17
vshuff32x4 $1, %ymm1, %ymm0, %ymm0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
|WAITING
Last reconfirmed||2023-11-08
--- Comment #3 from Andrew Pinski ---
I could not reproduce it with:
GNU C++17 (GCC) version 14.0.0 20231107 (experimental) [trunk 8b937ae0a9e]
(x86_64-pc-linux-gnu)
compiled by GNU C version 14.0.0 20231107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
--- Comment #2 from Sam James ---
(In reply to Andrew Pinski from comment #1)
> What binutils version are you using?
> It could also be a binutils bug.
>
$ as --version
GNU assembler (Gentoo 2.41 p2) 2.41.0
> vblendps is just a plain avx inst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
--- Comment #1 from Andrew Pinski ---
What binutils version are you using?
It could also be a binutils bug.
vblendps is just a plain avx instruction even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117
Lewis Hyatt changed:
What|Removed |Added
Keywords||patch
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
Bug ID: 112435
Summary: [14 regression]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112434
--- Comment #1 from Andrew Pinski ---
The c inline-asm modifiers is not documented for riscv ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
--- Comment #6 from Andrew Pinski ---
Created attachment 56529
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56529&action=edit
Cleanup testcase
Basically removed the long variable/function names.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
Sam James changed:
What|Removed |Added
Target||x86_64-linux-gnu
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112434
Bug ID: 112434
Summary: unexpected error when compiling for riscv64: invalid
'asm': invalid use of '%c'
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #14 from dave.anglin at bell dot net ---
On 2023-11-07 8:36 p.m., sjames at gcc dot gnu.org wrote:
> If I instrument certain functions in compile.c with no optimisation attribuet
> or build the file with -fno-fold-mem-offsets, Python
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
--- Comment #3 from Kito Cheng ---
Share some thought from my end: we've tried at least 3 different approach on
LLVM side before, and now we model that as "partial early clobber", we plan to
upstream this on LLVM side but just didn't get high e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
--- Comment #2 from JuzheZhong ---
(In reply to Kito Cheng from comment #1)
> Give few more background why LLVM must do that way: LLVM can't allocate new
> pseudo register during register allocation process, however spilling vector
> register wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
--- Comment #1 from Kito Cheng ---
Give few more background why LLVM must do that way: LLVM can't allocate new
pseudo register during register allocation process, however spilling vector
register with specific length may require scratch register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #15 from JuzheZhong ---
Update status:
There are only these following dump FAILs:
FAIL: gcc.dg/signbit-2.c scan-tree-dump optimized "\\s+>\\s+{ 0(, 0)+ }"
FAIL: gcc.dg/signbit-2.c scan-tree-dump-not optimized "\\s+>>\\s+31"
XPASS:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #13 from Sam James ---
Created attachment 56527
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56527&action=edit
compile.c.323r.fold_mem_offsets.bad.xz
Output from
```
hppa2.0-unknown-linux-gnu-gcc -c -DNDEBUG -g -fwrapv -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
--- Comment #3 from Sam James ---
Better reduction without uninit:
```
int secp256k1_scalar_reduce_512_r_0_0, secp256k1_scalar_reduce_512_m6,
secp256k1_scalar_reduce_512_m9, secp256k1_scalar_reduce_512_th,
secp256k1_scalar_reduce_512_tl;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
--- Comment #2 from Sam James ---
Reduced:
```
int secp256k1_scalar_reduce_512_r_0_0, secp256k1_scalar_reduce_512_m6,
secp256k1_scalar_reduce_512_m9, secp256k1_scalar_reduce_512_th,
secp256k1_scalar_reduce_512_tl;
unsigned int secp256k1_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
Bug ID: 112433
Summary: RISC-V GCC-15 feature: Split register allocation into
RVV and non-RVV, and make vsetvl PASS run between them
Product: gcc
Version: 14.0
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432
Bug ID: 112432
Summary: Internal-fn: The [i|l|ll]rint family don't support
FLOATN
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
--- Comment #2 from JuzheZhong ---
My colleague Lehua takes this response to support this feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
JuzheZhong changed:
What|Removed |Added
CC||lehua.ding at rivai dot ai
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
Bug ID: 112431
Summary: RISC-V GCC-15 feature: Support register overlap on
widen RVV instructions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
Bug ID: 112430
Summary: [14 Regression] ICE: verify_ssa failed, missing
definition
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22196
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> This actually undos some of what phi-opt might do and only should be done
> for a few operations. I think divide, multiple, shifts and rotates should
> be done a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
--- Comment #11 from JuzheZhong ---
(In reply to Richard Sandiford from comment #10)
> Some of the SME changes I'm working on fix this, but I'm not sure how widely
> we'll be able to use them on non-SME code. Assigning myself just in case.
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109078
Richard Sandiford changed:
What|Removed |Added
Last reconfirmed||2023-11-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112361
--- Comment #8 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:fd940d248bfccb6994794152681dc4c693160919
commit r14-5231-gfd940d248bfccb6994794152681dc4c693160919
Author: Robin Dapp
Date: Mon Nov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112359
--- Comment #4 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:fd940d248bfccb6994794152681dc4c693160919
commit r14-5231-gfd940d248bfccb6994794152681dc4c693160919
Author: Robin Dapp
Date: Mon Nov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #3 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:fd940d248bfccb6994794152681dc4c693160919
commit r14-5231-gfd940d248bfccb6994794152681dc4c693160919
Author: Robin Dapp
Date: Mon Nov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #12 from Sam James ---
(In reply to Manolis Tsamis from comment #11)
> Hi all,
>
> I will also go ahead and try to reproduce that, although it may take me some
> time due to my limited experience with HPPA. Once I manage to reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112429
Bug ID: 112429
Summary: Wnonnull should warn for multi-dimensional arrays
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428
Bug ID: 112428
Summary: Wnonnull outputs wrong type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112427
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Las
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391
Richard Sandiford changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112427
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112427
--- Comment #1 from Sam James ---
This reproduces with just 'g++ -c mesh.cpp.ii' for me.
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112427
Bug ID: 112427
Summary: [14 regression] ICE when buliding Minetest (internal
compiler error: tree check: expected tree that
contains ‘decl common’ structure, have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511
--- Comment #8 from Andrew Macleod ---
(In reply to Richard Biener from comment #2)
> VRP could use max_stmt_executions here (note it doesn't properly handle loop
> nests so the name is somewhat misleading)
Do you have to ask for max_stmt_execu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
--- Comment #13 from Thomas Koenig ---
(In reply to Patrick Palka from comment #3)
> Perhaps related to this PR: On x86_64, the following basic wrapper around
> int128 addition
>
> __uint128_t f(__uint128_t x, __uint128_t y) { return x + y; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269
--- Comment #11 from Patrick Palka ---
Sorry for the breakage... FWIW a patch is on review at
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634859.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Alex Coplan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112426
--- Comment #1 from Andrew Pinski ---
This looks almost the same as PR 100697 really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110540
--- Comment #3 from Andrew Macleod ---
EVRP figures out the j value can only be 0 or -9 and removes a few stmts as a
result, and simplifies the PHI, producing
[local count: 114863530]:
# j_12 = PHI <0(2), -9(6)>
[local count: 107374182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
--- Comment #5 from Saurabh Jha ---
Hey,
I did some digging into it. The ICE is happening on this assert:
gcc_assert (REG_P (op))
Here the op->code is MEM while it was expecting a REG. For the test program
above, the function arm_effective_re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
--- Comment #3 from Tomáš Trnka ---
Yes, -frecursive makes the build pass and it is a workaround which I have been
using ever since upgrading to 13. Should have mentioned that, sorry.
I see that something is making the compiler think the routin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112426
Bug ID: 112426
Summary: sched1 pessimizes codegen on aarch64 by increasing
register pressure
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419
Hans-Peter Nilsson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |uecker at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112425
Bug ID: 112425
Summary: Invalid SARIF output when column number is zero
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
Paul Thomas changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
--- Comment #8 from Gaius Mulley ---
Created attachment 56524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56524&action=edit
Proposed fix v5 (git diff -w)
Here is the same patch as v5 but generated using git diff -w.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112422
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
Gaius Mulley changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from Gaius Mulle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112424
Bug ID: 112424
Summary: libgomp: cuStreamSynchronize error: misaligned address
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
Gaius Mulley changed:
What|Removed |Added
Attachment #56508|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #11 from Manolis Tsamis ---
Hi all,
I will also go ahead and try to reproduce that, although it may take me some
time due to my limited experience with HPPA. Once I manage to reproduce, most
f-m-o issues are straightforward to locat
1 - 100 of 130 matches
Mail list logo
