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=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
Franz Sirl changed:
What|Removed |Added
Attachment #51164|0 |1
is obsolete|
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
--- 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 #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 #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=110857
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #2
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=111283
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #7
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=111559
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #3
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.
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Hi,
compiling this example with
g++-trunk -c
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
--- 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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This came up during the discussion of PR 116449.
get_member_function_from_ptrfunc() generates a statement with repeated
expressions, but
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Hi,
this small testcase
class c1
{
struct s1
{
unsigned int m_n1;
};
struct s2
{
s1 sM1;
s1 sM2;
};
s2 m_s2
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 55412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55412&action=edit
testcase
Since somewhere between r14-1870 and r14-2097 a new -Warray-bounds=2 false
p
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".
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This testcase (reduced with cvise):
long
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=68845
Franz Sirl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=117259
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #5
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=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
--- 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
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Hi,
compiling even the simplest code to a shared library with profiling is broken
since r14-811
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
--- 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
Franz Sirl changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #7
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This small code snippet warns with r15-9900 (r15-9866 was still OK):
static const char Names[16][8]= { "ac0", "ac1"
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This small code snippet warns with r15-9921 (r15-9866 was still OK):
static const int map01[32] = { 11, 12, 13, 14, 15 };
static const int map02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121244
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #3
101 - 137 of 137 matches
Mail list logo
