https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114134
--- Comment #8 from Pilar Latiesa ---
I'm observing a slight improvement with current trunk for the testcase in
comment #5:
struct T { int i, j, k, w; };
T f(int x)
{ return {x, 0, x, 0}; }
With 14.3 I get:
movabsq $-429496729
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chopra.kavya04 at gmail dot com
Target Milestone: ---
program generates the wrong code at [14/15] for -O{1,2,3}. Godbolt link:
https://godbolt.org/z/aG4o6P9sj
kchopra@ast-epyc5:~/gcc_bugs$ gcc -v
Using built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119814
Alfred Agrell changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #9 from Ken Jin ---
I tried this out with CPython's interpreter that uses tail calls with the patch
at https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/saved/master?ref_type=heads
applied.
I get a roughly 10% speedup on the pystones
|--- |FIXED
Target Milestone|--- |2.45
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
--- Comment #2 from Alan Modra ---
Fixed
--
You are receiving this mail because:
You are on the CC list for the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #8 from H.J. Lu ---
Created attachment 61120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61120&action=edit
A tested patch
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
void a(...);
template
bool b()
{
return requires { v(v(1)); };
}
bool c() { return b(); }
Expected: False. a(1) is void, and cannot be passed to a(), even if it&#
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
void a(...);
bool b()
{
return std::is_invocable_v;
}
template
bool c()
{
return requires { a(std::declval()); };
}
bool d() { return c(); }
or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #15 from Zbigniew ---
The second example, I mean the one from PDF book, spits out somewhat different
errors. I mean the second one from the section 2.17:
PROCEDURE Example (foo, bar: CARDINAL) : CARDINAL ;
VAR
myout: CARDINAL ;
BEGI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800
--- Comment #7 from Keith Refson ---
Yes, definitely. Any scalar with an ultimate allocatable component should be
warned about.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800
--- Comment #3 from Keith Refson ---
I think it probably also needs to flag up if MOLD contains an allocatable or
pointer component too. Modifying the example to TRANSFER to an integer,
followed by a second TRANSFER with SOURCE= as an integer a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422
--- Comment #7 from Jesse Williamson ---
Revisiting this, I don't think it's a bug-- but perhaps a more specific error
message could have saved some confusion.
See update: https://godbolt.org/z/sePdf4bvv
...adding scope resolution to the frie
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eczbek.void at gmail dot com
Target Milestone: ---
https://godbolt.org/z/zaTaEWesh
Works fine with Clang
```
using size_t = decltype(0uz);
template
struct CounterReader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119726
--- Comment #2 from Anders Wind ---
Two questions:
I am a bit interested in why my original case is correctly rejecting the code,
but the following is not being rejected (A is no longer a template class).
```
struct A {
template
struc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #21 from Paul McKenney ---
> Given C++ abandoned 'volatile' I would rather suggest to document
> better ways of achieving that and if existing ways are too cumbersome
> we should see a way to do this without altering behavior on 'vol
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chopra.kavya04 at gmail dot com
Target Milestone: ---
gcc14 and trunk hang at -O1 with this code snippet. Godbolt link:
https://godbolt.org/z/WGhGWbq8b
kchopra@ast-epyc5:~$ gcc -v
Using built-in specs.
COLLECT_GCC
: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: krefson at gmail dot com
Target Milestone: ---
Created attachment 6
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #8 from AlphaOmegaProgrammer ---
> So what about this untested patch?
I've spent about an hour trying to find flaws in the idea, and I can't think of
any. I applied the patch and it fixed the deadlock for me in my test code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #5 from AlphaOmegaProgrammer ---
> Please see https://gcc.gnu.org/contribute.html for how to contribute, which
> includes sending a real patch
My apologies, this is my first time trying to contribute. I'll do this.
> This can only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #15 from Owen A. ---
https://code.wildebeest.org/git/mirror/gcc/commit/?id=89ca1e3cb697a87f02682a1fb1f62f02d0671c57
Wildebeest seems to have the patch. It seems like all of the linked tests are
failing for other reasons, though. Doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #2 from AlphaOmegaProgrammer ---
Created attachment 61109
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61109&action=edit
Proposed Patch
This is my proposed patch. I've tested it and my test case no longer deadlocks,
and none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #1 from AlphaOmegaProgrammer ---
Created attachment 61108
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61108&action=edit
Current implementation of locking algorithm
This file can be found at /libatomic/config/posix/lock.c
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alpha.and.omega.programmer at gmail dot com
Target Milestone: ---
Created attachment 61107
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61107&action=edit
Code that demon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #13 from Zbigniew ---
And regarding my Comment #8 — about assembler-related problems? Is it a bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119791
--- Comment #1 from nightstrike ---
Created attachment 61102
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61102&action=edit
RTL on linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119791
--- Comment #3 from nightstrike ---
Created attachment 61104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61104&action=edit
asm on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119791
--- Comment #2 from nightstrike ---
Created attachment 61103
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61103&action=edit
asm on Windows
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Created attachment 61101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61101&action=edit
RTL on windows
All four tests in this file fail on Windows:
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86273
nightstrike changed:
What|Removed |Added
Known to work||13.1.0
Known to fail|
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
This test fails on at least x86_64-w64-mingw32:
/* { dg-final { scan-assembler-symbol-section {^_?ar}
{^\.(const|rodata)|\[RO\]} } } */
with the following message:
FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119765
--- Comment #6 from nightstrike ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680856.html
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: collin.funk1 at gmail dot com
Target Milestone: ---
Created attachment 61099
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61099&action=edit
preprocessed source dump
I see the following crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #16 from Owen A. ---
*linked builders
--
You are receiving this mail because:
You are on the CC list for the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #16 from Owen A. ---
*linked builders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #15 from Owen A. ---
https://code.wildebeest.org/git/mirror/gcc/commit/?id=89ca1e3cb697a87f02682a1fb1f62f02d0671c57
Wildebeest seems to have the patch. It seems like all of the linked tests are
failing for other reasons, though. Doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
H.J. Lu changed:
What|Removed |Added
Attachment #61093|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119784
--- Comment #1 from H.J. Lu ---
Created attachment 61098
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61098&action=edit
A patch
I am testing this.
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
[hjl@gnu-tgl-3 pr119628]$ cat x1.c
#define DONT_SAVE_REGS __attribute__((no_callee_saved_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100818
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
Thanks, that does indeed explain it. The é in José?
I have put Sandra in copy because I just wrote to her about these PRs a few
minutes ago.
Obrigado
Paul
On Sun, 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
--- Comment #6 from H.J. Lu ---
no_caller_saved_registers only works with XMM and ZMM, not YMM, since YMM load
will clear the upper 256 bits of ZMM.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chopra.kavya04 at gmail dot com
Target Milestone: ---
The compiler hangs at runtime with -O{1,s}. It works fine for -O3 and -O2
though. Godbolt link: https://godbolt.org/z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119765
--- Comment #4 from nightstrike ---
Ah, I think I understand better. It's not the AMD64 ABI saying to pass the
register count in EAX, it's the SysV or whatever ABI saying to do it, and the
Windows ABI says to do something else. So really instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #12 from Owen A. ---
I can't replicate this on my end anymore -- is it still present on x86_64?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #12 from Owen A. ---
I can't replicate this on my end anymore -- is it still present on x86_64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119765
--- Comment #3 from nightstrike ---
Is this a case of "skip windows", or a case of "skip targets with/without
feature X"?
Also, I'm a little surprised, as based on the name of the test, I would think
it was testing a feature of the cpu type, no
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: izaberina at gmail dot com
Target Milestone: ---
Created attachment 61092
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61092&action=edit
the horrible code in question
so i wrote some horrible code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119773
--- Comment #1 from Kavya Chopra ---
it also seems to have compilation errors (i believe the compiler hangs?) for
some previous versions
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chopra.kavya04 at gmail dot com
Target Milestone: ---
This bug's a weird one - it seems to compile just fine, but hangs at -O1 and
above for the current gcc trunk version. Godbolt link:
https://godbolt.
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
The test gcc.target/i386/amd64-abi-9.c fails on at least x86_64-w64-mingw-w64
due to the xorl instruction not being found:
FAIL: gcc.target/i386/amd64-abi-9.c scan-assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #8 from Zbigniew ---
I'd like also to note there's also a need to take better care about the docs;
for example: I tried a code snippet from
https://gcc.gnu.org/onlinedocs/gm2/Assembly-language.html („2.17 Interface to
assembly langua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #7 from Zbigniew ---
I'd like to stress it: presently these error messages (I mean without '-fiso'
option) look like compiler was malfunctioning:
coex.mod:8:24: error: In program module 'CoEx': unknown symbol 'COROUTINE'
8 | FRO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #6 from Zbigniew ---
Indeed I confirm 'gm2 -fiso coex.mod -o coex' works in case of GCC 14.2.0. Yes,
the error message could be a bit more specific, if it's feasible.
In case of 12.2.0 there's still an error (below) — but I assume it
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is the sibling of PR119748:
https://godbolt.org/z/Mv184YGo8
#include
int main() {
volatile char vc[4] = {'a', 'b', 'c',
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119748
--- Comment #1 from 康桓瑋 ---
The _S_copy_range(pointer __p, _Rg&& __rg, size_type __n) help committed
yesterday also needs to be fixed for the contiguous_range branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #4 from Zbigniew ---
Excuse me, but it'll again compile 20 hours or so.
No, it's highly unlikely literally every distro has 'packaging issues' and
exactly with gm2 — maybe the better way would be if you first try the example
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #2 from Zbigniew ---
It is compiled (the whole 14.2 'suite') from the sources. But I doubt
Slackware's scripts interfere with GM2 subdirectories in any way. You can
easily check Slackware-current scripts, they are available on any Sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119750
--- Comment #2 from Zbigniew ---
Indeed, I didn't try any other compilation since that time. It reports:
gcc hw.c -o hw.o
Assembler messages:
Internal error (Illegal instruction).
Please report this bug.
Well I did compilation of GCC 11.5 on t
iority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: zbigniew2011 at gmail dot com
Target Milestone: ---
Consider following programming example:
(* https://www.vajhoej.dk/arne/articles/m2.html *)
MODULE CoEx;
FROM STextIO IMPORT WriteString, WriteLn;
F
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zbigniew2011 at gmail dot com
Target Milestone: ---
Created attachment 61084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61084&action=edit
files (*.i*)
Not sure is it s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119747
--- Comment #1 from Barry Revzin ---
Clang's diagnostic is equivalent to gcc's for this example:
:9:5: error: expected expression
9 | CALL_F(1, 2);
| ^
:6:40: note: expanded from macro 'CALL_F'
6 | #define CALL_F(v, ...) f
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Here is a reduced example of a problem I just spent a while debugging:
template
void f(int, Args...) {
}
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116178
Janez Zemva changed:
What|Removed |Added
CC||janezz55 at gmail dot com
--- Comment
oduct: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: awia00 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/h3frfdqTf
The following cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #26 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #25)
> If we can't use range-based 'for' with ranges then we've taken a wrong turn
> somewhere.
>
> I did test them in e.g. std/ranges/access/begin.cc so we know that
> rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #24 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #22)
> but they deserve to break.
I agree with that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #21 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #20)
> Does it matter? By design, ranges::begin does the same things as range-based
> for (handles arrays first, then looks for member begin(), then looks for ADL
> begin).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #19 from 康桓瑋 ---
(In reply to GCC Commits from comment #18)
> The master branch has been updated by Jonathan Wakely :
>
> https://gcc.gnu.org/g:882d3b319dbf50ae64080731a1398031c100b7c7
>
> commit r15-9378-g882d3b319dbf50ae64080731a
ibstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following should be well-formed since C++23.
#include
#include
int main() {
std::array a;
std::tuple<> t;
auto eq = (t == a);
auto cmp = (t <
https://sourceware.org/bugzilla/show_bug.cgi?id=32846
--- Comment #10 from H.J. Lu ---
A patch is posted at
https://sourceware.org/pipermail/binutils/2025-April/140473.html
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=32846
--- Comment #9 from H.J. Lu ---
(In reply to Sam James from comment #0)
> Hi!
>
> Since ...
>
> commit 2707d55e539ef323dd14a1293e762bf3d9739ee7
> Author: Michael Matz
> Date: Mon Mar 31 15:57:08 2025 +0200
>
> [lto] Fix symlookup in
https://sourceware.org/bugzilla/show_bug.cgi?id=32846
H.J. Lu changed:
What|Removed |Added
Blocks||32854
Referenced Bugs:
https://sourceware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119708
--- Comment #4 from Alfred Agrell ---
No, that's not relevant to this bug either (though it is relevant to bug
109993). This bug is about ECMAScript flavor regex, not the POSIX ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119708
--- Comment #2 from Alfred Agrell ---
No, bug 84110 looks unrelated to me. That bug refers to actual 0x00 bytes in
the input regex.
This bug is about how the regex parser treats backslashes.
https://sourceware.org/bugzilla/show_bug.cgi?id=32858
Alan Modra changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32854
H.J. Lu changed:
What|Removed |Added
Depends on||32846
Referenced Bugs:
https://sourceware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
--- Comment #6 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #5)
> Lets take this discussion elsewhere - e.g. to my Darwin toolchains - there
> is no upstream solution to this on any of the components (cctools, ld64,
> gcc, llvm)
https://sourceware.org/bugzilla/show_bug.cgi?id=32846
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=32854
Bug 32854 depends on bug 32846, which changed state.
Bug 32846 Summary: LTO link failures in various packages since
2707d55e539ef323dd14a1293e762bf3d9739ee7
https://sourceware.org/bugzilla/show_bug.cgi?id=32846
What|Removed
https://sourceware.org/bugzilla/show_bug.cgi?id=32854
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: makovick at gmail dot com
Target Milestone: ---
Created attachment 61065
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61065&action=edit
Minimal example
Latest
++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
int main() {
try {
std::regex r{"\\00"};
puts("valid");
} catch (const std::exception& e) {
printf(&
https://sourceware.org/bugzilla/show_bug.cgi?id=32858
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
Assignee: unassigned at gcc dot gnu.org
Reporter: chopra.kavya04 at gmail dot com
Target Milestone: ---
The compiler seems to hang and not produce an executable for this for -O1 and
above. This has been there since v 14.1.
Godbolt link: https://godbolt.org/z/dbqWh15do
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bigmagicreadsun at gmail dot com
Target Milestone: ---
When compiling the following code with RISC-V GCC:
#include
volatile int16_t x;
int get() {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #21 from Mateusz Guzik ---
Given the issues outline in 119703 and 119704 I decided to microbench 2 older
uarchs with select sizes. Note a better quality test which does not merely
microbenchmark memset or memcpy is above for one rea
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mjguzik at gmail dot com
Target Milestone: ---
13.3.0 runs into it, but I also tested on godbolt which claims to have 15.0.1:
gcc
(Compiler
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mjguzik at gmail dot com
Target Milestone: ---
13.3.0 runs into it, but I also tested on godbolt which claims to have 15.0.1:
gcc
(Compiler-Explorer-Build-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926
Ville Voutilainen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Assignee: dmalcolm at gcc dot gnu.org
Reporter: kaelfandrew at gmail dot com
CC: antoyo at gcc dot gnu.org
Target Milestone: ---
libgccjit.h does not seem to expose va_list in gcc_jit_context_get_type().
Could be added via tree node va_list_type_node in tree.h
https://sourceware.org/bugzilla/show_bug.cgi?id=32864
--- Comment #1 from Constantine Bytensky ---
Created attachment 16014
--> https://sourceware.org/bugzilla/attachment.cgi?id=16014&action=edit
Sample quick-and-dirty patch
--
You are receiving this mail because:
You are on the CC list for t
Severity: normal
Priority: P2
Component: tools
Assignee: unassigned at sourceware dot org
Reporter: cbytensky at gmail dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Created attachment 16013
--> https://sourceware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
--- Comment #4 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #2)
> it's always been broken, unfortunately (for a start, it gets the range wrong)
> At that stage, there were not many exes that were large enough to trigger an
> iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119628
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-04-09
CC|
https://sourceware.org/bugzilla/show_bug.cgi?id=32860
H.J. Lu changed:
What|Removed |Added
Summary|Definition of GCC builtin |Definition of GCC builtin
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-tgl-3 lto-6]$ cat pr31482a.c
#include
int
main()
{
abort ();
return 0;
}
[hjl@gnu-tgl-3 lto-6]$ cat pr31482c.c
#include
#include
void
abort (void
https://sourceware.org/bugzilla/show_bug.cgi?id=32860
H.J. Lu changed:
What|Removed |Added
Summary|Definition in the archive |Definition of GCC builtin
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yannick.daveluy at gmail dot com
Target Milestone: ---
With user defined literal operator template there is a problem of template
instantiation. It seems the the first instantiation stay in
1 - 100 of 12488 matches
Mail list logo
