https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117809
--- Comment #2 from felix-gcc at fefe dot de ---
Another real-world example is asprintf from GNU libc:
int asprintf(char **restrict strp, const char *restrict fmt, ...);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119353
--- Comment #2 from felix-gcc at fefe dot de ---
I ran rustup update stable.
$ rustc --version
rustc 1.85.0 (4d91de4e4 2025-02-17)
Severity: normal
Priority: P3
Component: rust
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org,
pierre-emmanuel.patry at embecosm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117810
--- Comment #2 from felix-gcc at fefe dot de ---
Hmm, now that you mention it explicitly... Just like C++ iterators, max does
not actually point at the last element in the array but at the first element
behind the array.
That appears to be more
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
I love attribute access, I use it all the time in my projects.
You can tell the compiler that the function reads n elements from a
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
I love attribute malloc! I would like to annotate all my functions with it
where applicable!
But you can only do it for
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Here is my example code:
#include
#include
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114658
felix-gcc at fefe dot de changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114658
--- Comment #2 from felix-gcc at fefe dot de ---
I'm probably doing something really stupid wrong, sorry for the noise.
Here's what I'm doing:
$ git checkout releases/gcc-13
Switched to branch 'releases/gcc-13'
$ git b
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Not sure how and where to file this bug, sorry.
I'm trying to build the current stable release branch,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107614
felix-gcc at fefe dot de changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
I'm trying to build the current gcc git and install it to /opt/gcc so it
doesn't clash with the system gcc.
This is on x86_64 Linux. The build goes through but make ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728
--- Comment #4 from felix-gcc at fefe dot de ---
If you do have a printf that references debug_cnt, it wouldn't be removed,
right?
If you expect unreferenced variables to not be optimized out, you can always
compile without optimizer. For
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Consider this piece of test code:
int dummy1()
{
static int removeme = 0;
if (removeme)
{
return 0;
}
removeme = 1;
return 0;
}
int dummy2()
{
static int
Assignee: dmalcolm at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Now that -fanalyzer is here to track leaking memory, I need a way to tell gcc
that a function takes ownership of a pointer.
You could call it takes_ownership or maybe free.
Here'
mponent: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
gcc offers a useful builtin around the cpuid instruction on x86 and x86_64,
which can be used to check for specific instruction set extensions, e.g.
if (_builtin_cpu_supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000
--- Comment #2 from felix-gcc at fefe dot de ---
The false positive also happens if you fix that.
In fact, my original (much longer) code does not try to write to read-only
memory.
I put that in my test case in the hope that somebody would
Assignee: dmalcolm at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Consider this contrived test code:
void proof(char* x) {
char* y=0;
switch (*x) {
case 'a':
y="foo";
case 'b':
if (*x=='a') *y='
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #4 from felix-gcc at fefe dot de ---
Sure, here's a test case:
#include
__attribute__((access(read_only,2,3), access(write_only,1,3)))
extern void* memcpy(void* dest, const void* src, size_t len);
int main() {
char b
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
I read about the access attribute and proceeded to add the annotations to the
string.h of my little libc. It works. But it stops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93703
--- Comment #2 from felix-gcc at fefe dot de ---
OK that answers half of the mystery, but why is foo not mangled?
++
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
I suspect this is my mistake, not gcc's, but I'm out of ideas so sorry for
wasting your time if that is true.
Here is my situation:
$ cat a.cc
const int foo = 23;
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Deserialization code often deals with endianness and alignment. However, in
some cases, the protocol endianness is the same as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80656
--- Comment #1 from felix-gcc at fefe dot de ---
Turns out my libc was installed incorrectly.
Retrying now. I'm still getting this build error in libgomp and libstdc++.
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
The build fails at least in libquadmath or libssp.
checking whether the /tmp/build/./gcc/xgcc -B/tmp/build/./gcc
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
clang supports several advanced __attribute__ cases that gcc does not, and two
strike me as particularly useful: enable_if and diagnose_if. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #4 from felix-gcc at fefe dot de ---
So which part of it is not constant, you would say?
It all looks constant to me. It only operates on constants.
If 3+4 is constant, why should this not be constant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #2 from felix-gcc at fefe dot de ---
uh, yes in C.
$ cat test.c
#define TOLOWER(x) (x&~0x20)
#define Word(s) \
s[1] ? s[2] ? s[3] ? \
(TOLOWER(s[0]) << 24) + (TOLOWER(s[1]) << 16) + (TOLOWER(s[2]) <
mponent: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
This is the code:
#define TOLOWER(x) (x&~0x20)
#define Word(s) \
s[1] ? s[2] ? s[3] ? \
(TOLOWER(s[0]) << 24) + (TOLOWER(s[1]) << 16) + (TOLOWER
: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
I was looking for a way to create statically linked PIE ELF binaries under
Linux.
Since these are statically linked and have no shared library, I am looking for
a way to tell gcc to not use GOT or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57716
felix-gcc at fefe dot de changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
rity: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
When trying out the std::thread support in g++ 4.8.1, I tried this test
program:
#include
#include
using namespace std;
void thethread(vector& b) {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719
--- Comment #7 from felix-gcc at fefe dot de 2013-03-25 16:01:14 UTC ---
I filed this bug because I was under the impression that gcc was already
supposed to optimize this out as part of the value range optimizations.
You probably know
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719
--- Comment #5 from felix-gcc at fefe dot de 2013-03-25 15:06:02 UTC ---
Yes. However I'd hope that fixing this case would mean that gcc also catches
the case where it is split to multiple if statements.
I think this statement came
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719
--- Comment #3 from felix-gcc at fefe dot de 2013-03-25 14:41:10 UTC ---
@comment 1: maybe it's me but that does not make any sense. 3fff is wrong and
the correct value is 3fff? Huh?
@comment 2: I extracted this code from a pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719
Bug #: 56719
Summary: missed optimization: i > 0x || i*4 > 0x
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56711
Bug #: 56711
Summary: spectaculary bad code generated for __uint128_t
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55815
Bug #: 55815
Summary: switch hash function of libstdc++ hash tables to
siphash
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53240
--- Comment #2 from felix-gcc at fefe dot de 2012-05-04 22:30:45 UTC ---
I was talking about the second gcc.
Turns out the steps until then broke something.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53240
Bug #: 53240
Summary: gcc 4.7 cross compiler build fails in libssp; link
test not allowed after GCC_NO_EXECUTABLES
Classification: Unclassified
Product: gcc
Version: 4.7.0
--- Comment #6 from felix-gcc at fefe dot de 2009-03-30 22:10 ---
> 'z' is for x87 insns.
Uh, what?! Let me quote the relevant "documentation"
(gcc/config/i386/i386.md):
;; The special asm out single letter directives following a '%' are:
;; '
--- Comment #4 from felix-gcc at fefe dot de 2009-03-30 20:27 ---
#include
#define atomic_add(mem,val) asm volatile ("lock; add%z0 %1, %0": "+m" (mem):
"ir" (val))
int main() {
size_t foo;
atomic_add(foo,23);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39590
--- Comment #2 from felix-gcc at fefe dot de 2009-03-30 19:54 ---
Uh, I did. Use the macro like this:
int foo=2;
atomic_add(foo,3);
then try size_t as type of foo and compile on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39590
"q" in this case.
--
Summary: inline asm %z on amd64 says "ll" instead of "q"
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assig
--- Comment #2 from felix-gcc at fefe dot de 2009-01-01 16:01 ---
Sorry, I just found out that xchg has an implicit lock. Never mind about this
bug.
--
felix-gcc at fefe dot de changed:
What|Removed |Added
--- Comment #1 from felix-gcc at fefe dot de 2009-01-01 15:58 ---
All I really want is a way to access lock cmpxchg and lock xadd, really :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38688
s not actually lock
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build triplet: x86_64-unkn
--- Comment #4 from felix-gcc at fefe dot de 2008-12-08 00:17 ---
This was apparently caused by a conflict with my userland. When I used vanilla
coreutils, the build works. This will be horrible to debug. Sorry for the
noise.
--
felix-gcc at fefe dot de changed:
What
--- Comment #3 from felix-gcc at fefe dot de 2008-12-07 23:38 ---
I have the sources in ~/tmp/gcc, and I build in ~/tmp/gcc/build using
../configure.
I can see the .in files you mention in libjava/classpath/tools and I can see
some binaries in build/x86_64-unknown-linux-gnu/libjava
--- Comment #1 from felix-gcc at fefe dot de 2008-12-07 21:46 ---
I tried building gcc with --disable-multilib but fails at the same location in
the 64-bit libjava build as well:
/bin/sh ./libtool --tag=GCJ --mode=link /home/leitner/tmp/gcc/build/gcc/gcj
-B/home/leitner/tmp/gcc/build
t: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet
gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37238
--- Comment #15 from felix-gcc at fefe dot de 2008-04-01 21:24 ---
I think we can all agree it does not matter what we call this problem.
Real world programs have security problems because of this.
-fstack-protector carries a much larger run-time cost and gcc still offers it,
and there
: operator new susceptible to integer overflow
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC
--- Comment #6 from felix-gcc at fefe dot de 2008-04-01 19:34 ---
Sure. For example:
char* c=malloc(lseek(somefd,0,SEEK_END);
on a platform where off_t is 64-bit, but where size_t is 32-bit. For example:
i686-linux with #define _FILE_OFFSET_BITS 64.
Now that I'm thinking abo
--- Comment #4 from felix-gcc at fefe dot de 2008-04-01 16:09 ---
I'm not familiar enough with how gcc works to say whether warning about
precision loss that turns out important later on can be done at all.
But I think we should not reject an idea because it only handles 60% o
Two simple examples:
unsigned int add(unsigned int a,unsigned int b) {
if (a+bhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=35646
--- Comment #2 from felix-gcc at fefe dot de 2008-03-14 19:58 ---
I am aware of -Wconversion, but I am not interested in ALL conversion
truncations. Truncation happens to be a security issue in a few cases, in many
other cases it would just be a regular bug. My suggestions aims to
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-
ary: slow code generated for 64-bit arithmetic
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fel
for long long shifts
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build t
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet:
--- Comment #4 from felix-gcc at fefe dot de 2007-07-22 23:08 ---
Falk:
union {
struct {
void* unused;
struct node n;
} a;
struct node b;
} u;
Then &u.a.n.next == &u.b.n.prev;
Artificial? Sure. But legal.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #2 from felix-gcc at fefe dot de 2007-07-22 17:12 ---
FWIW, the C compilers from Intel and Sun do reload n->next.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
--- Comment #1 from felix-gcc at fefe dot de 2007-07-22 17:09 ---
Well, since n is passed in a register, it can assume that n is still the same
here. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
ssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
--- Comment #48 from felix-gcc at fefe dot de 2007-01-22 19:50 ---
Oh wow, another wise cracking newbie who comments without actually
understanding the issue. I AM NOT RELYING ON UNDEFINED BEHAVIOR. On the
contrary. gcc is fine to assign 23 instead of a negative number. But if it
--- Comment #43 from felix-gcc at fefe dot de 2007-01-22 13:02 ---
No, it WAS about the security. Now that you made me check and I saw that the
optimization also doesn't give any actual speed increase, I want it removed on
that grounds, too. And I want it removed for reasons of s
--- Comment #41 from felix-gcc at fefe dot de 2007-01-22 02:18 ---
So I tested some C++ vector code using at, in a desperate attempt to find ANY
case where this so called "optimization" actually produces faster code.
http://ptrace.fefe.de/vector2.C
$ gcc -O3 -o vector2
--- Comment #36 from felix-gcc at fefe dot de 2007-01-21 17:47 ---
I think the actual root issue here is that the gcc argumentation is
fundamentally wrong. I am complaining that gcc removes my checks, not that
signed integer overflow is undefined.
Also, note that it is everything BUT
--- Comment #33 from felix-gcc at fefe dot de 2007-01-21 13:53 ---
so now you give us... a straw man?
The range analysis has nothing to do with just assuming integers can't wrap.
But more to the point: the Intel compiler does not assume signed integers can't
wrap, and IT STIL
--- Comment #28 from felix-gcc at fefe dot de 2007-01-18 15:23 ---
Mhh, so I wondered, how can it be that the code is exactly as fast. So I
disassembled the binary. You know what? IT'S THE EXACT SAME CODE.
So, my conjecture is, again: your "optimization" does
--- Comment #27 from felix-gcc at fefe dot de 2007-01-18 15:20 ---
Oh, so C++ code using vector gets faster, you say? Let's see...
This is vector.C from http://ptrace.fefe.de/vector.C
It does some assignments to a vector. It runs the loop 10 times and takes the
minimum cycle co
--- Comment #25 from felix-gcc at fefe dot de 2007-01-17 19:04 ---
Well, duh. You removed the security checks.
Hey, I have one for you, too. Optimize away all calls to pthread_mutex_lock,
and lo and behold, multithreaded code will be much faster! It will also be
broken, but
--- Comment #23 from felix-gcc at fefe dot de 2007-01-17 18:23 ---
In earlier gcc versions this only happened if the optimizer was on. So your
argument might hold some water there, if I squint my eyes enough.
But gcc 4.1 removes that code even with the optimizer turned off.
There
--- Comment #21 from felix-gcc at fefe dot de 2007-01-17 17:20 ---
I DID NOT WRITE THE BROKEN CODE.
Trying to trivialize the issue or insult me will not make it go away.
So, please tell me, which part of the argument in comment #9 were you unable to
follow? I could try using less
--- Comment #17 from felix-gcc at fefe dot de 2007-01-17 17:02 ---
You misunderstand.
We don't want you to say anything.
We want to you make your "optimization" off by default, or remove it
altogether.
You could also try to convince us that there is any actual tangi
--- Comment #14 from felix-gcc at fefe dot de 2007-01-17 16:37 ---
1. "apologist", in contrast to "asshole", is not a cuss word. Apparently you
are as ignorant about English as you are about the issue at hand.
2. I showed my gcc -v, why don't you? Maybe it&#
--- Comment #12 from felix-gcc at fefe dot de 2007-01-17 15:21 ---
(In reply to comment #11)
> Btw. your testcase "fails" with gcc 2.95.3 for me as well, so no news here.
>
Bullshit.
$ ./gcc2 -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/spe
--- Comment #9 from felix-gcc at fefe dot de 2007-01-17 13:55 ---
Hey Andrew, do you really think this issue goes away if you keep closing the
bugs fast enough?
Let me tell you something: that INT_MAX way to do it is bogus. These checks
are there so that it is obvious the int overflow
--- Comment #4 from felix-gcc at fefe dot de 2007-01-15 19:57 ---
(In reply to comment #2)
> signed type overflow is undefined by the C standard, use unsigned int for the
> addition or use -fwrapv.
You have GOT to be kidding?
All kinds of security issues are caused by integer
--- Comment #3 from felix-gcc at fefe dot de 2007-01-15 19:50 ---
even stranger, if I assert ((int)(a+100) > 0) then it STILL gets optimized
away.
WTF!?
--
felix-gcc at fefe dot de changed:
What|Removed |Ad
--- Comment #1 from felix-gcc at fefe dot de 2007-01-15 19:46 ---
Mhh, if I change "int+100" to "(int)(int+100)", the assert still gets optimized
away.
So it's not an integer promotion issue. Both sides are definitely int.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
?
--
Summary: assert(int+100 > int) optimized away
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at f
--- Comment #1 from felix-gcc at fefe dot de 2006-09-15 22:14 ---
Turns out you can still do make install and get a working cross compiler after
that, so I concur it's normal and not critical.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102
locker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27180
--- Additional Comments From felix-gcc at fefe dot de 2005-06-15 21:05
---
(In reply to comment #5)
> (In reply to comment #4)
> > what about *arithmetic shift* instruction (e.g. SAR on ix86) ?
> Nope, try that with a negative number and you will notice that it will
--- Additional Comments From felix-gcc at fefe dot de 2005-06-15 06:12
---
by the way, -Os generates an unnecessary register move:
pushl %ebp
movl$2, %edx
movl%esp, %ebp
movl12(%ebp), %eax
movl%edx, %ecx
imull 8(%ebp
oduct: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build tri
90 matches
Mail list logo
