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.
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=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
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
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.
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=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
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
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
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
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
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 .
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=110458
--- Comment #2 from Franz Sirl ---
This has been exposed by commit
r14-2013-gfb0447b1f6b7373f57cb3a3d17a46803cfd9909d "Hide IVOPTs strip_offset".
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
: 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
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
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Hi,
this small example
extern volatile int *x;
static int gCrc;
static int crc16Add(int crc, int b) __attribute__((noinline
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
: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 53676
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53676&acti
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
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Hi,
this minimized testcase issues
# gcc-12 -O2 -Warray-bounds -c testcase.c
testcase.c: In function 'fun3.part.0':
testcase.c:16:13: warning: array subscript
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
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
A PowerPC32 GCC configured with "--target=powerpc-unknown-eabi
--enable-languages=c,c++ --with-cp
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
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
With this testcase:
class cl1 {
virtual void m();
};
class cl2 : public cl1 {
public:
int g();
int h();
int i();
};
class cl3 {
cl1 *p;
int g();
int h
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Hi,
with this minimized testcase, compiled with -O2 -Warray-bounds:
struct s1
{
char b[12];
};
struct s2
{
int x;
struct s1 y;
} *pb, c;
extern struct s2 *es;
void test1 (int f
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97157
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073
--- Comment #8 from Franz Sirl ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 49236 [details]
> gcc11-pr97073.patch
>
> Untested fix.
I can confirm that this patch applied to the gcc-8 branch fixes the testcase
and the ori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073
Franz Sirl changed:
What|Removed |Added
Known to work|6.3.1 |
--- Comment #7 from Franz Sirl ---
No, my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073
--- Comment #5 from Franz Sirl ---
(In reply to Jakub Jelinek from comment #3)
> This broke in between r102000 (still good) and r104000 (already
> miscompiled), so I don't believe that 6.3.1 worked.
Hmm, maybe something in 6.3.1 is masking the b
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 49229
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49229&action=edit
Testcase demonstrating the problem.
Hi,
the attached simple testcase abor
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 47176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47176&action=edit
testcase
This code:
typedef struct {
char cs[256];
} inner_small
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 47133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47133&action=edit
testcase
The attached creduced testcases recently started to warn differently in trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #15
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 44335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44335&action=edit
testcase
The a
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This short creduced snippet
enum { a = 1 } b;
int c() {
int d = a;
for (; d;)
d &= d - 1;
return b;
}
compiled with "gcc-9 -c -W -Wall
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-linux
Created attachment 44070
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44070&action=edit
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650
--- Comment #1 from Franz Sirl ---
Created attachment 44068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44068&action=edit
testcase 2
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 44067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85420
--- Comment #3 from Franz Sirl ---
Hmm, this maybe creduce'd too much, the original source reads more like
strcpy(b, b + a + 10);
which would be only UB for sure if strlen(b + a + 10) >= 9, or?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85420
--- Comment #1 from Franz Sirl ---
Created attachment 43951
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43951&action=edit
C++ testcase
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 43950
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43950&action=edit
C t
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This small testcase warns 3 time when compiled with 8.0.1@r259308:
extern char a[], b[], d[];
int c, e;
char *strcpy(char *, const char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762
--- Comment #13 from Franz Sirl ---
Yes, I can do a patch for GCC-9. Any idea for the option naming? Like
-msvr4-struct-return-msb? Or should I consolidate -maix-struct-return and
-msvr4-struct-return into -maggr-return-mode={aix,svr4,svr4gnu}?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762
Franz Sirl changed:
What|Removed |Added
Known to fail||3.1.1
--- Comment #11 from Franz Sirl ---
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This small testcase doesn't warn if compiled with -g and -O1 or higher. Only
"-g -O0" or for example -O2 without -g warn for the te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078
--- Comment #1 from Franz Sirl ---
The ICE was introduced between r257623 and r257685.
, at cp/mangle.c:878
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
CC: marxin at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #3
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: powerpc-eabi
For an example like:
struct smallstruct { char a; char b; char c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #2
IRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
With gcc-8 trunk@258093 for this example
char *append_leading_digits(char *cp, int i)
{
char buf[16];
__builtin_sp
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 43216
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43216&action=edit
testcase
Compiling the attached file with r256939 of trunk issues 2 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510
--- Comment #6 from Franz Sirl ---
The patch in comment 5 applied to r256877 fixes the warning in both the
testcase and the original code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510
Franz Sirl changed:
What|Removed |Added
Known to work||6.4.0, 7.2.0
--- Comment #2 from Franz Sirl
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 42933
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42933&action=edit
testcase
The attached testcase started to pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82271
--- Comment #6 from Franz Sirl ---
Actually this is likely triggered by undefined behaviour. The array m_pTemp is
too small for nAccessSize=4096. Increasing the array size to 1024 elements
makes the bug go away.
If you agree, just close the bug a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82271
--- Comment #3 from Franz Sirl ---
The bug was introduced with r195054:
2013-01-09 Jan Hubicka
PR tree-optimiation/55875
* tree-ssa-loop-niter.c (number_of_iterations_cond): Add
EVERY_ITERATION parameter.
(num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82271
Franz Sirl changed:
What|Removed |Added
Known to work||4.5.4, 4.6.4, 4.7.4
Known to fail|
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 42211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42211&action=edit
testcase
The attached testcase removes conditions in the loop when compi
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This example code doesn't warn with -Wtautological-compare:
int f(int a)
{
if ((a & 0x10) == 10)
return 1;
return 0;
}
clang warns
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This testcase warns only once with -Wdeclaration-after-statement since at least
gcc-4.8:
#include
bool f2(char *pRedo)
{
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742
--- Comment #5 from Franz Sirl ---
Actually, after seeing a large bunch of justified warnings in our codebase with
the disabled APPEARS_TO_BE_BOOLEAN_EXPR_P check, I wonder if a new option like
-Wbool-bitwise-parentheses (thus not depending on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742
--- Comment #4 from Franz Sirl ---
APPEARS_TO_BE_BOOLEAN_EXPR_P was introduced with r141340 (PR 7543), but I
cannot find a discussion on why this suppression makes sense. When I disable it
I only see 3 places where it triggers in trunk:
gcc/cp/l
||2017-07-05
CC||sirl at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Franz Sirl ---
Still happens with 7.1.1 and trunk. clang catches both with the
-Wlogical-not-parentheses option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80930
--- Comment #2 from Franz Sirl ---
Further investigation shows that "-O2 -fsanitize=undefined" is enough to
trigger the excessive memory usage.
The big difference between GCC-6 and GCC-7 is that the function causing this
has ~20 blocks in GCC
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
We have an inhouse C source where the memory usage is excessive (> 88GB, then
OOM killed) with GCC-7/x86_64 (7.
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
I couldn't find (also grepping under trunk/gcc/doc) any documentation on the -e
commandline option. It seems the option and it's argument are directly passed
to the linker, sim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79265
--- Comment #6 from Franz Sirl ---
(In reply to Jakub Jelinek from comment #4)
> This is a new warning, the fact that we didn't warn on some code and now
> warn with a new warning is not necessarily a regression.
Well, I wasn't so sure either if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79265
Franz Sirl changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 41073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41073&action=edit
testcase
The attached testcase issues 2 warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78735
--- Comment #1 from Franz Sirl ---
Can be worked around by bootstrapping with --disable-werror. Last reconfirmed
with trunk r246380. Trunk is at 7.0.1, so --disable-werror is the default right
now.
I guess the only real question is if the profil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79692
--- Comment #3 from Franz Sirl ---
I can confirm that the patch fixes both the submitted testcase and the original
code.
Thanks for your efforts.
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 40820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40820&action=edit
testcase
With trunk r245678 on x86_64 the attached testcase prints these warnings:
gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082
--- Comment #14 from Franz Sirl ---
I just finished testing with r245021 and now the warnings are as expected. All
warnings are there with -Wformat-truncation=2 and also -Wformat-truncation=1
behaves according to the documentation (BTW, there's a
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This code:
class Base
{
public:
static bool state();
};
class Derived : public Base
{
};
class MyClass
{
public:
Derived *m_Derived;
Base *m_Base;
bool state();
};
bool MyClass
1 - 100 of 134 matches
Mail list logo
