https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #65 from Kees Cook ---
(In reply to Alejandro Colomar from comment #64)
> How about having two macros? One that works for non-attributed pointers,
> and other that works for attributed ones. And use the appropriate one for
> each o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #63 from Kees Cook ---
(In reply to Alejandro Colomar from comment #62)
> What's the value of returning NULL instead of just failing the compilation
> with an error?
It's so that the same allocator macros can be used for FAM structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #59 from Kees Cook ---
(In reply to Bill Wendling from comment #57)
> (In reply to Kees Cook from comment #47)
> > So, with the builtin being used within the allocator to set counter, now the
> > old code pattern still works (as coun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #55 from Kees Cook ---
(In reply to Alejandro Colomar from comment #49)
> For reading the counted_by value, that is, for reading the number of
> elements in the FAM, I'm implementing a __lengthof__ operator, which returns
> the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #47 from Kees Cook ---
Yes, the counter must be manually set until Linux minimum compiler versions are
raised to include counted_by support, but this is about making the transition
to using counted_by easier and less prone to bugs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #32 from Kees Cook ---
(In reply to qinzhao from comment #29)
> (In reply to Jakub Jelinek from comment #28)
> > Speaking of counted_by, I see support for it in c-family/ and c/, but not in
> > cp/ at all, what is the attribute suppo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #31 from Kees Cook ---
(In reply to Qing Zhao from comment #25)
> The source code need to be:
>
> If (__builtin_get_counted_by (P->FAM))
> __builtin_get_counted_by (P->FAM) = COUNT;
>
> Yes, I agree that this is good too for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #1 from Kees Cook ---
Matching Clang feature request:
https://github.com/llvm/llvm-project/issues/99774
mal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
With the wonderful addition of the 'counted_by' attribute and its wide roll-out
within the Linux kernel, we have found a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #8 from Kees Cook ---
The warning is about:
val = &sg->vals[index];
poc.c:20:20: warning: array subscript 4 is above array bounds of 'int[4]'
[-Warray-bounds=]
20 | val = &sg->vals[index];
|~~~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #6 from Kees Cook ---
(In reply to qinzhao from comment #5)
> adding __attribute__ ((noreturn)) to the routine "warn" can eliminate the
> false positive warning.
But it does return... it's not an assert.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #8 from Kees Cook ---
Clang bug: https://github.com/llvm/llvm-project/issues/84565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #7 from Kees Cook ---
There is still no way to use C99 flexible arrays in unions (or alone in
structs) without syntactic obfuscation. The extension that already allows
0-sized arrays in unions should be extended to cover C99 arrays. T
,
||kees at outflux dot net,
||ndesaulniers at google dot com,
||qing.zhao at oracle dot com
--- Comment #6 from Kees Cook ---
There is still no way to use C99 flexible arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #42 from Kees Cook ---
Exciting! Are you able to attach the latest patch? I'd love to try it out. I've
been testing Clang's version as well:
https://reviews.llvm.org/D148381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #3 from Kees Cook ---
Is there a viable path to a solution here? This seems to cause enough false
positives with -Warray-bounds that at least Linux can't enable the flag. I'd
really like to have it enabled, though, since it finds ple
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 54611
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54611&action=edit
PoC for -Warray-bounds false positive
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #6 from Kees Cook ---
I really want to avoid the changes to sizeof() -- this will confuse a lot of
other things. Sizeof is expected to be a constant expression, for example.
I think the attribute is best since it avoids colliding wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #1 from Kees Cook ---
The corresponding Clang feature request is here:
https://github.com/llvm/llvm-project/issues/60928
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Frequently a structure containing a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
Kees Cook changed:
What|Removed |Added
Attachment #54508|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #1 from Kees Cook ---
The matching Clang bug is: https://github.com/llvm/llvm-project/issues/60926
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #7 from Kees Cook ---
(In reply to Kees Cook from comment #6)
> Sorry, I forgot to include those details fully! Here's how I'm seeing it:
>
> $ gcc --version
> gcc (GCC) 13.0.0 20230105 (experimental)
> ...
> $ gcc -O2 -fno-strict-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #6 from Kees Cook ---
Sorry, I forgot to include those details fully! Here's how I'm seeing it:
$ gcc --version
gcc (GCC) 13.0.0 20230105 (experimental)
...
$ gcc -O2 -fno-strict-overflow -fsanitize=shift -Warray-bounds -c -o /dev/n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Kees Cook changed:
What|Removed |Added
Attachment #54198|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #2 from Kees Cook ---
Ugh, sorry. The PoC is bad -- the bounds check isn't present. Let me try to get
a another PoC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Kees Cook changed:
What|Removed |Added
CC||arnd at linaro dot org,
|
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 54198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54198&action=edit
reduced PoC
This seems similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #11 from Kees Cook ---
(In reply to Richard Biener from comment #10)
> I sofar refrained from doing this because of the large amount of fallout and
> followup changes and I think those are not warranted on the GCC 12 branch.
Totally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
Kees Cook changed:
What|Removed |Added
CC||qing.zhao at oracle dot com
--- Comment #9
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Hi,
Similar to this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106528
-Wmissing-indentation is blinded by comments:
int square(int num) {
if (num == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #6 from Kees Cook ---
(In reply to Richard Biener from comment #5)
> Should be fixed on trunk. Can you check on the original unreduced testcase?
Thanks! I've done test builds and can confirm these two false positives have
been elim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #41 from Kees Cook ---
(In reply to Bill Wendling from comment #40)
> The question then is if `-fstrict-flex-arrays=3' is used, what does a `[0]'
> at the end of a struct represent (assuming GCC no longer treats it as an
> FAM)?
It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #34 from Kees Cook ---
-fstrict-flex-arrays=3 is still needed. (E.g. for proper FORTIFY coverage,
etc.) I don't have an opinion about the -W options, though.(In reply to James Y
Knight from comment #33)
> (In reply to qinzhao from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #21 from Kees Cook ---
(In reply to Martin Sebor from comment #20)
> Well, I just "asked" for such an option the same way you asked for
> -fstrict-flex-arrays in comment #3, because I believe it would be useful to
> make the BOS impr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #19 from Kees Cook ---
(In reply to Martin Sebor from comment #18)
> The zero size case exists (and is documented) solely as a substitute for
> flexible array members. Treating is as an ordinary array would disable that
> extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #17 from Kees Cook ---
(In reply to qinzhao from comment #16)
> additional work are needed in order to make this task complete:
>
> 1. add one more new gcc option:
>
> -fstrict-flex-arrays
>
> when it's on, only treat the followin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #13 from Kees Cook ---
Maybe the enum needs to also be expanded so that [0] can be distinguished from
[]?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #11 from Kees Cook ---
and with a flex array to compare:
https://godbolt.org/z/s9nb4Y7q4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #10 from Kees Cook ---
Here's a slightly reworked example:
https://godbolt.org/z/EvehMax84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #9 from Kees Cook ---
Just to clarify, __builtin_dynamic_object_size() shouldn't have anything to do
with this. What's needed is something like -fstrict-flex-arrays so that all the
"trailing array is a flex array" assumptions can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #1 from Kees Cook ---
The Linux kernel has encountered at least two of these (seen as specifically
"array subscript 32", though the root cause may be causing many others:
../drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: arra
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 53010
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53010&action=edit
test case minimized as much as possible
Some combination of things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #7 from Kees Cook ---
Right, perhaps I should rename this bug? The much more surprising thing is the
lack of warning about the uninit use. With or without -ftrivial-auto-var-init,
I'd want to have the diagnostic that a UB may have ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #2 from Kees Cook ---
https://godbolt.org/z/99Pdro9Te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #1 from Kees Cook ---
(Also this doesn't warn about y being used uninitialized.)
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
It looks like some pass is being run before the initializers are added:
int x (int z) {
int y;
if (z)
y = 10;
return y;
}
under "gcc -ftrivial-aut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #4 from Kees Cook ---
The kernel keeps gaining more of these cases, so it'll be important to get this
fixed:
https://lore.kernel.org/lkml/200fe5cb203ad5cc00c5c60b7ded2cd85c9b85ea.ca...@perches.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
--- Comment #4 from Kees Cook ---
(Ah, I knew this had been reported before. I found it now...)
Duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
--- Comment #2 from Kees Cook ---
As mentioned in a Linux kernel thread, isn't it possible to transform this:
switch (x) {
int y;
default:
y = x * 2;
return y;
}
into this:
{
int y;
switch (x) {
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428
--- Comment #2 from Kees Cook ---
Note that this needs a struct attribute that will allow structs to be excluded
from the diagnostic (since the kernel needs to deal with legacy UAPI headers
forever).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #11 from Kees Cook ---
The trouble with "optimize" is that it just doesn't work. The kernel has banned
its use because it results in all other optimization options being forgotten
for the function in question.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
As done for powerpc (1b3254e4bbe82245421a55324bc8fe34a99c6e3c), aarch64
(cd0b2d361df82c848dc7e1c3078651bb0624c3c6), riscv
(c931e8d5a96463427040b0d11f9c4352ac22b2b0), and x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #9 from Kees Cook ---
(In reply to Jakub Jelinek from comment #8)
> So, instead (when building the kernel with sanitization) build with
> -fsanitize=signed-integer-overflow and no -fno-strict-overflow, and
> the routines where you wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #7 from Kees Cook ---
The problem the kernel needs to solve is basically having our cake and eating
it too. :)
In _most_ situations, we want signed overflows to trap (i.e. get caught by
"-fsanitize=signed-integer-overflow").
In som
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Currently -fzero-call-used-regs will use a pattern of:
XOR regA,regA
MOV regA,regB
MOV regA,regC
...
RET
However, this introduces both a register ordering dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #3 from Kees Cook ---
Eww. That means _FORTIFY_SOURCE doesn't work correctly.
Can there please be a -fstrict-flex-arrays or something to turn off all the
heuristics so a code base can declare it only uses flex arrays for dynamic
tra
MED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 51282
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51282&action=edit
str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #5 from Kees Cook ---
Perhaps the best question to ask is "given an arbitrary argument, how can code
detect the remaining bytes of a member, including if the member contains a
flexible array?"
Because right now, this does not work:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #4 from Kees Cook ---
It seems like this isn't about crossing field boundaries -- it's asking "how
large is this particular member?" and bos can't know the answer because there
is a flex-array.
Why would
__builtin_object_size(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #2 from Kees Cook ---
Created attachment 51280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51280&action=edit
Same PoC, but with malloc to provide non-unlimited bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #1 from Kees Cook ---
This is even more visible when the size IS known (via malloc hinting, for
example):
https://godbolt.org/z/4v5rKbhaf
MED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 51279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51279&action=edit
bos1 fails to
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 51131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51131&action=edit
memset collapsing breaks __builtin_obje
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
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: kees at outflux dot net
Target Milestone: ---
It would be nice to gain "-Wzero-length-array" so we can enforce this standard
in the Linux kernel once all conversions have moved struct to flexible array
members. Clang supports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
--- Comment #8 from Kees Cook ---
Created attachment 48153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48153&action=edit
updated PoC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
--- Comment #7 from Kees Cook ---
(In reply to Kees Cook from comment #6)
> (In reply to Jakub Jelinek from comment #4)
> > (In reply to Kees Cook from comment #2)
> > > Is there anything to enforce a strict "only consider empty array size as
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
--- Comment #6 from Kees Cook ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Kees Cook from comment #2)
> > Is there anything to enforce a strict "only consider empty array size as
> > flexible array member" mode? This is an unfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307
--- Comment #5 from Kees Cook ---
Hi! I recently learned that Clang has -fsanitizer-minimal-runtime that is very
close to what I was expecting to use:
https://bugs.llvm.org/show_bug.cgi?id=45295
That is close to what you're already suggesting.
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
--- Comment #2 from Kees Cook ---
Is there anything to enforce a strict "only consider empty array size as
flexible array member" mode? This is an unfortunate weakening of the array
bounds checker as there are plenty of structures that have a fix
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90673
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310
--- Comment #4 from Kees Cook ---
But it's optimizing away the check. If strlen() were suddenly acting like
strnlen(), that'd be one thing, but the return value from strlen() is being
used by the memcpy() without the actual test in between. That'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310
Kees Cook changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 43889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43889&action=edit
test case
Something is gcc 8 is broken when dealing with strlen() results.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411
--- Comment #3 from Kees Cook ---
To clarify, using -mno-sdata means all things are removed from sdata, not just
const, yes? I'd like to be able to leave writable stuff there, to avoid any
additional performance penalty.
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
On powerpc, a const variable may end up in the .sdata section, which is
writable. This means authors cannot depend on the "const" marking to mean
"read-only", as is required f
--- Comment #2 from kees at outflux dot net 2010-06-27 17:55 ---
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02690.html
--
kees at outflux dot net changed:
What|Removed |Added
--- Comment #6 from kees at outflux dot net 2009-03-24 17:39 ---
I'm trying to minimize the Ubuntu patch by getting changes accepted for the FSF
GCC testsuite. I'm hoping to demonstrate that many of the changes are valid
and represent stricter C coding, though none change th
--- Comment #3 from kees at outflux dot net 2009-03-24 07:10 ---
g++.old-deja/g++.pt/t39.C: It looks like ptr[0],[1],[2] are either int or const
char (i.e. ptr is int* or const char*). %p doesn't make much sense in those
cases, so I opted for a cast.
I'm not sure I followed
--- Comment #1 from kees at outflux dot net 2009-03-24 06:34 ---
Created an attachment (id=17530)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17530&action=view)
testsuite updates for format strings and casts
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537
ReportedBy: kees at outflux dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537
--- Comment #1 from kees at outflux dot net 2009-03-24 06:27 ---
Created an attachment (id=17529)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17529&action=view)
more VERIFY() calls in libstdc++ testsuite
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39536
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kees at outflux dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39536
--- Comment #5 from kees at outflux dot net 2009-01-18 18:12 ---
Created an attachment (id=17135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17135&action=view)
multiple tests for the regression
This contains a series of tests, none of which should fail.
--
--- Comment #9 from kees at outflux dot net 2008-12-22 01:01 ---
Yes! Adding "-fno-strict-aliasing" to a normal (-O2) build seems to have fixed
the problems so far. The full test suite takes a while, but the early failures
are not present any more. I will report more once i
--- Comment #7 from kees at outflux dot net 2008-12-18 01:07 ---
Created an attachment (id=16925)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16925&action=view)
4.4.0 -E output of log_event.cc (bzip2)
$ /usr/lib/gcc-snapshot/bin/g++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME=
--- Comment #5 from kees at outflux dot net 2008-12-18 00:40 ---
Created an attachment (id=16923)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16923&action=view)
obj file from -O2 gcc 4.3.2
--
kees at outflux dot net changed:
What|
--- Comment #4 from kees at outflux dot net 2008-12-18 00:39 ---
Created an attachment (id=16922)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16922&action=view)
obj file from -O2 gcc 4.4.0 20081212 (experimental) [trunk revision 142725]
--
kees at outflux dot net
--- Comment #6 from kees at outflux dot net 2008-12-18 00:41 ---
Created an attachment (id=16924)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16924&action=view)
obj file from -O1 gcc 4.4.0 20081212 (experimental) [trunk revision 142725]
--
http://gcc.gnu.org/b
--- Comment #3 from kees at outflux dot net 2008-12-18 00:38 ---
Created an attachment (id=16921)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16921&action=view)
obj file from -O2 gcc 4.4.0 20081212 (experimental) [trunk revision 142725]
--
http://gcc.gnu.org/b
1 - 100 of 105 matches
Mail list logo
