https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116621
--- Comment #5 from Dimitar Dimitrov ---
(In reply to Dimitar Dimitrov from comment #4)
> (In reply to H.J. Lu from comment #3)
> > Created attachment 59055 [details]
> > A patch
> >
> > Try this.
>
> Thanks. This fixes not only the attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #21 from Joshua ---
Well then; I guess I'm having pain every time I upgrade the compiler no matter
what.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #20 from Xi Ruoyao ---
Sorry I made my commands wrong. But still:
$ gcc -o nutty0 -Wall -Wl,-T,minipie.ld -Wl,--no-dynamic-linker -pie -nostdlib
-nostartfiles -O3 -s -fpic -fno-asynchronous-unwind-tables -ffreestanding
package.s nu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #19 from Xi Ruoyao ---
(In reply to Joshua from comment #18)
> I stand corrected. I removed -pie.
>
> The resulting output binary is still relocatable in memory. I don't think
> the Kernel is willing to load an ELF binary at address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116644
Bug ID: 116644
Summary: Warnings in generic code don't report column number
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #18 from Joshua ---
I stand corrected. I removed -pie.
The resulting output binary is still relocatable in memory. I don't think the
Kernel is willing to load an ELF binary at address 0, and that's the only other
option with this he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #17 from Xi Ruoyao ---
(In reply to Joshua from comment #16)
> I took out -fpie and the output assembly was different and the binary
> started working. That is contrary to the documentation which says you need
> -fpie for position in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #16 from Joshua ---
I took out -fpie and the output assembly was different and the binary started
working. That is contrary to the documentation which says you need -fpie for
position independent executables.
I suppose it would be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112418
--- Comment #2 from Andrew Pinski ---
Created attachment 59076
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59076&action=edit
Start of the patch
This is the start but the patch does too much for little benifit.
Example:
```
int g(int);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #15 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639
--- Comment #3 from Larry Smith ---
Thanks for the quick turnaround (and reference to the similar issue a few years
back). Appreciated. I see you also found (and cited) my Clang post. Credit for
your thoroughness :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #14 from Joshua ---
Is this just a doc problem then?
It says I must use -fpie to make a relocatable executable.
I need a relocatable executable with no relocations. There is nothing in source
code requiring a relocation, so I am su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #13 from Andrew Pinski ---
(In reply to Joshua from comment #12)
> You can't *do* that in this environment. No relocations allowed.
you requested PIE which requires some relocations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #12 from Joshua ---
I located the actual bug in the disassembly. While it is somehow caused by
vfork; it is not due to vfork or vfork rules. The bad assembly code is here.
.LC16:
.quad .LC7
You can't *do* that in this env
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116643
Bug ID: 116643
Summary: PHI_RESULT vs gimple_phi_result/gimple_phi_result_ptr
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: enh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #11 from Joshua ---
So far I have the following.
I have modified the asm stub so that vfork() is an alias for fork(); of course
gcc doesn't know about that, and that's the point.
If I remove -ffreestanding I can verify the asm is c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116631
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #10 from Andrew Pinski ---
Vfork returns twice.
Sounds like some missing volatile too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #9 from Joshua ---
Update: vfork is not the problem. If the function is _called_ vfork the bug
happens. The bug remains if I update package.s to use __NR_fork instead of
__NR_vfork.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #8 from Joshua ---
I am absolutely certain declaring new local variables inside the vfork() block
is kosher.
Modifying variables outside the vfork() block simply requires marking them
volatile; in this the rule is the same as setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #7 from Andrew Pinski ---
vfork basically should not be used really. It has since been removed from POSIX
standard in 2008. Plus on many Linux arch, fork and vfork don't exist as system
calls; only clone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> >either modifies any data other than a variable
>of type pid_t used to store the return value from vfork()
>
> Is the case here.
That is you are modify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #4 from Andrew Pinski ---
>either modifies any data other than a variable
of type pid_t used to store the return value from vfork()
Is the case here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #3 from Andrew Pinski ---
(From POSIX.1) The vfork() function has the same effect as
fork(2), except that the behavior is undefined if the process
created by vfork() either modifies any data other than a variabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #2 from Joshua ---
Created attachment 59075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59075&action=edit
linker script used to build nutty.i (don't know if requried or not to build
executable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #1 from Joshua ---
Created attachment 59074
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59074&action=edit
runtime required to build nutty.i all the way to an executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
Bug ID: 116642
Summary: miscompilation involving vfork child.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113683
--- Comment #2 from Andrew Pinski ---
>clang accepts it though ...
EDG also accepts it.
so this is 2/4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116640
--- Comment #1 from Andrew Pinski ---
>For comparison, Clang and MSVC accept both Inner1 and Inner2.
EDG also accepts both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116641
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-09-07
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116641
Bug ID: 116641
Summary: [12/13/14/15 Regression] std::string move assignment
incorrectly depends on POCCA
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116181
--- Comment #8 from Gaius Mulley ---
Created attachment 59072
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59072&action=edit
Proposed fix for location_t and tree -Wodr warnings
This patch fixes the -Wodr warning for m2tree_Tree vs tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116640
Bug ID: 116640
Summary: Inconsistent compiler rules when using private types
as default template parameters
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79013
Andrew Pinski changed:
What|Removed |Added
CC||iamkirkezz at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116446
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116446
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-07
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116567
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116567
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:0c80216b7bb0938bff7db230cbefa5bc3e8b3034
commit r14-10652-g0c80216b7bb0938bff7db230cbefa5bc3e8b3034
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116567
--- Comment #3 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:dfb63765e994bee74d533c810fdf75d3269530ad
commit r15-3530-gdfb63765e994bee74d533c810fdf75d3269530ad
Author: Patrick Palka
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588
--- Comment #4 from GCC Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:506417dbc8b1cbc1133a5322572cf94b671aadf6
commit r15-3529-g506417dbc8b1cbc1133a5322572cf94b671aadf6
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116592
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:d620499b3a24f14cfb98529640584e63d7eca149
commit r15-3527-gd620499b3a24f14cfb98529640584e63d7eca149
Author: Jin Ma
Date: Sat Sep 7 10:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639
--- Comment #1 from Larry Smith ---
FYI that the behavior table I posted above is a bit long but appeared correct
in the preview window when I submitted it (after expanding it using the
window's sizing grip). Wrapping now occurring instead in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639
Bug ID: 116639
Summary: "private" access specifier not respected in overloaded
SFINAE context
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115973
--- Comment #2 from Jens Seifert ---
Assembly that better integrates:
unsigned long long addc_opt(unsigned long long a, unsigned long long b,
unsigned long long *res)
{
unsigned long long rc;
__asm__("addc %0,%2,%3;\n\tsubfe
%1,%1,%1":"=r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100632
Simon Martin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #236 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #235)
> Not sure though whether this is related at all. Will go back to the known
> working version and retry with all patches.
OK, the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
Andrew Pinski changed:
What|Removed |Added
Attachment #59068|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
--- Comment #10 from Andrew Pinski ---
Created attachment 59069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59069&action=edit
Reduced all the way I can make it
Still LTO only: `-shared -O3 -march=armv9-a -flto`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
--- Comment #9 from Andrew Pinski ---
Created attachment 59068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59068&action=edit
slightly reduced
`-shared -O3 -march=armv9-a -flto`
Will reduce it further in a few minutes.
*To be removed from our mailing list, please respond to this message with
UNSUBSCRIBE in the subject line*
--
**
12th INTERNATIONAL SCHOOL ON DEEP LEARNING
(with special focus on Large Language Models, Foundation Models and Generative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116614
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bb8dd0980b39cfd601f88703fd356055727ef24d
commit r15-3525-gbb8dd0980b39cfd601f88703fd356055727ef24d
Author: Jakub Jelinek
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
--- Comment #8 from Andrew Pinski ---
Created attachment 59067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59067&action=edit
Preprocessed testcase
aarch64-linux-gnu-g++ -shared t.ii -O3 -flto -march=armv8.2-a+sve+fp16+dotprod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
--- Comment #7 from Andrew Pinski ---
Reduced down to one object file:
```
aarch64-linux-gnu-g++ build/src/cpu/kernels/activation/generic/sve/fp16.os
-shared
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116637
--- Comment #7 from Xi Ruoyao ---
(In reply to Greg Morse from comment #5)
> if glibc is not part of gcc why does the GNU bug reporting page give glibc
> as a sub option to gcc?
libgcc is not libc.
> So who is responsible for the malloc code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116637
--- Comment #6 from Xi Ruoyao ---
(In reply to Greg Morse from comment #4)
> the error comes from an attempt to do a malloc or calloc; it does not come
> from an attempt to use the pointer.the assertion that causes the crash comes
> from the ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116637
--- Comment #5 from Greg Morse ---
if glibc is not part of gcc why does the GNU bug reporting page give glibc as
a sub option to gcc?
So who is responsible for the malloc code in the libgcc library?
On Friday, September 6, 2024 at 10:29:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116637
--- Comment #4 from Greg Morse ---
the error comes from an attempt to do a malloc or calloc; it does not come
from an attempt to use the pointer.the assertion that causes the crash comes
from the malloc source code see here:
** malloc.c
60 matches
Mail list logo
