https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107848
--- Comment #2 from Jose E. Marchesi ---
This is likely due to the fact they added new BPF relocations:
https://reviews.llvm.org/D102712
Or course not bothering telling us.
at gcc dot gnu.org
Reporter: jose.marchesi at oracle dot com
Target Milestone: ---
We noticed that recently LLVM changed the BPF ABI by allowing to pass small
record arguments by value. Previously all records were passed by reference.
This is the LLVM change:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733
Jose E. Marchesi changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733
--- Comment #2 from Jose E. Marchesi ---
Urgh I obviously meant bpf-unknown-none.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.marchesi at oracle dot com
Target Milestone: ---
eBPF effectively supports two kind of call instructions:
- The so called pseudo-calls ("bpf to bpf").
- External call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537
--- Comment #2 from Jose E. Marchesi ---
(In reply to Andrew Pinski from comment #1)
> > This option is used in the kernel source tree for some BPF programs.
>
> Why not fix the sources? Seems not hard to add a cast or two.
That's what I would
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.marchesi at oracle dot com
Target Milestone: ---
GCC emits pedwarns unconditionally when comparing pointers of different types,
for example:
int xdp_context (struct xdp_md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
--- Comment #9 from Jose E. Marchesi ---
So I got feedback from the clang/llvm folks on this.
As you can see in [1] they asked the WG14 reflectors about the footnote 135 in
the C18 spec and their conclusion is that there is no normative objectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106515
--- Comment #3 from Jose E. Marchesi ---
This is due to having not so good regular expressions in the test btf-int-1.c
and to a slightly different way than the powerpc backend has to comment lines
in assembly.
Working on a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106515
--- Comment #2 from Jose E. Marchesi ---
Don't bother I just reproduced the issue in powerpc64le-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106515
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #3 from Jose E. Marchesi ---
Wilco: The assessment in comment 1 was extracted from an internal discussion on
an issue that is still under investigation. We are certainly hitting a
cant-reach-the-linker-generated-veneer problem, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
--- Comment #8 from Jose E. Marchesi ---
After a little discussion in IRC I filed this LLVM bug:
https://github.com/llvm/llvm-project/issues/56468
Regarding the ICE described by Ulrich, I cannot reproduce it using:
bpf-unknown-none-gcc (GCC) 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
--- Comment #7 from Jose E. Marchesi ---
If, as a workaround, I try to use a `section' attribute, like in:
__attribute__((section(".rodata"))) volatile const int lala = 0;
I don't get an ICE, but a section with write permissions:
.section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104656
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758
--- Comment #2 from Jose E. Marchesi ---
I can reproduce this problem in sparc64-*-linux-gnu. Looks like there
are many missing definitions for stub structs in
sanitizer_platform_limits_posix.h for sparc. Working on this.. after
I get it buildin
20 matches
Mail list logo
