https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #33 from Franz Sirl ---
Yes, that works. Now the only question remains whether PLT or GOT is the right
thing to do for mcount.
I still wonder if there is too much guessing going on here and if reusing
common flags is the right thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #27 from Franz Sirl ---
Maybe silly question, but since the changelog is only talking about __fentry__,
why couldn't you make the decision based on flag_fentry?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Franz Sirl changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #4 from Franz Sirl ---
> Note that the GCC man page is pretty clear about this:
>
> -mdirect-extern-access
> -mno-direct-extern-access
>
> Do not use or use GOT to access external symbols. The default is
> -mno-direct-extern-acces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #3 from Franz Sirl ---
The option -mdirect-extern-access is enabled by default since it was added in
r12-7126-ab0b5fbfe90168d2e470aefb19e0cf31526290bc . I didn't even know about
this option before I ran into this problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Bug ID: 119386
Summary: [14/15 Regression][x64] Shared libraries can no longer
be compiled with profiling
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117259
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
--- Comment #11 from Franz Sirl ---
The fix works nicely here, thanks!
As a fun fact, we gain a warning for this likely undefined code:
```
class BaseC {
public:
virtual ~BaseC() {}
};
class C : public BaseC {
public:
virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116533
Bug ID: 116533
Summary: Possibly missing SAVE_EXPR in
get_member_function_from_ptrfunc()
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
--- Comment #5 from Franz Sirl ---
This small change fixes the bug and passes bootstrap and regtests on x86_64.
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -4195,7 +4195,7 @@ get_member_function_from_ptrfunc (tree *instance_ptrptr,
tree fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
--- Comment #3 from Franz Sirl ---
Isn't the missing bounds check on parr[c] on purpose? It's added with
-fsanitize=bounds-strict.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
Bug ID: 116449
Summary: Miscompilation with UBSAN
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458
--- Comment #5 from Franz Sirl ---
I wrongly added c#3 here, should have been PR 105690, sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105690
--- Comment #4 from Franz Sirl ---
The testcode started to fail with the backwards jump threader rewrite in
r12-2591-g2e96b5f14e4025691b57d2301d71aa6092ed44bc and a simple -Warray-bounds.
This is proven by the fact that compiling the testcase wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68845
Franz Sirl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112727
Bug ID: 112727
Summary: UBSAN creates GIMPLE path with uninitialized variable
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #8 from Franz Sirl ---
The proposed patch on top of r14-4307 fixes the profiled bootstrap here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283
--- Comment #8 from Franz Sirl ---
I see a similar profiledbootstrap failing with x86_64-linux-gnu:
/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/./prev-gcc/xg++
-B/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #7 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458
--- Comment #3 from Franz Sirl ---
Actually Comment 2 is only true for the original testcode (which was quite
fragile to reproduce). The reduced testcode started to fail with the backwards
jump threader rewrite in r12-2591-g2e96b5f14e4025691b57d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110857
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110496
--- Comment #2 from Franz Sirl ---
Forget to mention, needs -O2 or higher to reproduce.
Was exposed by r14-2150-gfe48f2651334bc4d96b6df6b2bb6b29fcb732a83 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110496
Bug ID: 110496
Summary: ICE: tree check: expected none of vector_type, have
vector_type in find_bswap_or_nop_1, at
gimple-ssa-store-merging.cc:654
Product: gcc
V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458
--- Comment #2 from Franz Sirl ---
This has been exposed by commit
r14-2013-gfb0447b1f6b7373f57cb3a3d17a46803cfd9909d "Hide IVOPTs strip_offset".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458
Bug ID: 110458
Summary: -Warray-bounds=2 new false positive
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109354
Bug ID: 109354
Summary: [arm32] Parameter stored on stack gets wrong debug
info with -Og or higher
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108821
Franz Sirl changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108821
Bug ID: 108821
Summary: Extra volatile access with -O2 -ftree-loop-im since
GCC-11
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
--- Comment #1 from Franz Sirl ---
Created attachment 53677
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53677&action=edit
Related GCDA file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
Bug ID: 107182
Summary: Commit
r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4
breaks profiledbootstrap
Product: gcc
Version: 13.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105690
--- Comment #3 from Franz Sirl ---
I managed to minimize the testcase a bit more:
unsigned int gvar1;
void fun1(int);
void fun2(unsigned int, char *);
int fun2_maxlen;
typedef struct {
int exist;
int mode;
} table_t;
table_t gtable[20];
vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105690
Bug ID: 105690
Summary: -Warray-bounds sensitive false positive with -O2
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #16 from Franz Sirl ---
Created attachment 51199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51199&action=edit
Patch version with minimum changes against GCC10
This is the minimum version of the patch, it fixes this PR but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #15 from Franz Sirl ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to Franz Sirl from comment #12)
> > The emitted .machine is easy to fix, what's not so easy to fix is the
> > intention behind Segher's change that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #12 from Franz Sirl ---
The emitted .machine is easy to fix, what's not so easy to fix is the intention
behind Segher's change that caused the wrong .machine.
Consider this source compiled with -mcpu=7400:
void ppcaltivecfunc (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #9 from Franz Sirl ---
(In reply to Segher Boessenkool from comment #8)
> I don't think it is a good idea to add workaround upon workaround to avoid
> some of the not-so-useful behaviours of -many. Instead, we should just
> not use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Franz Sirl changed:
What|Removed |Added
Attachment #51164|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #4 from Franz Sirl ---
Created attachment 51164
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51164&action=edit
Half-baken trial patch
How about something along this patch? It's not fully done (no good idea about
SPEC stuff l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #3 from Franz Sirl ---
(In reply to Segher Boessenkool from comment #1)
> The -many is problematic, that is the whole point of this. As in this
> example: on different subtargets there are different machine code
> translations for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #17 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Bug ID: 101393
Summary: PowerPC32 inline assembly broken by commit
2d94f7dea9c73ef3c116a0ddc722724578a860fe
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #8 from Franz Sirl ---
(In reply to Segher Boessenkool from comment #7)
> (In reply to Franz Sirl from comment #5)
> > For the naming I suggest __builtin_debugtrap() to align with clang. Maybe
> > with an aliased __debugbreak() on Win
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251
Bug ID: 99251
Summary: Strange -Wnonnull warning behaviour with dynamic_cast
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99159
Bug ID: 99159
Summary: Confusing -Warray-bounds warning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
--- Comment #13 from Franz Sirl ---
Some data for the inhouse testcase in Bug 80930 with ASAN+UBSAN:
gcc-9@r9-8944: OOM killed after 15min at ~85 GB
gcc-10@r10-9345: takes ~25min to compile, max mem ~6.5GB
Thanks for this nice improvement!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #5 from
48 matches
Mail list logo
