Hi,
while dealing with autogenerated code I found that GCC often outputs compare
trees instead of branch tables for switch statements. I found that GCC uses the
density of case labels within their spanned range as the key criterion. If the
density of labels is smaller than 10% (33% for size
A paper at this year's GCC Summit talked about this:
http://www.gccsummit.org/2006/view_abstract.php?content_key=18
You might like to follow up with Edmar (the author of the paper).
Cheers, Ben
Hi
I have now everything in place for dynamically register the
debug frame information that my JIT (Just in time compiler)
generates.
I generate a CIE (Common information block), followed by
a series of FDE (Frame Description Entries) describing
each stack frame. The binary code is the same as
In http://gcc.gnu.org/ml/gcc/2006-07/msg00156.html, your wrote:
A paper at this year's GCC Summit talked about this:
http://www.gccsummit.org/2006/view_abstract.php?content_key=18
You might like to follow up with Edmar (the author of the paper).
But that was about optimizing the trees for
On Fri, Jul 07, 2006 at 10:56:08PM -0400, Robert Dewar wrote:
That's not true, thread local storage can be done simply by mapping
hardware on some machines, where you swap maps on a context switch.
Not with the semantics we have for __thread, which asserts
that its address is valid in all
On Jul 10, 2006, at 6:57 AM, jacob navia wrote:
What is the procedure for registering the frame info?
If you don't get an answer, you may have to debug it. Just follow
what something like eh6.C from the C++ testsuite does, and what it
calls, when, and with what data, then mirror the eh6.C
On Mon, 2006-07-10 17:58:19 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: lauras
Date: Mon Jul 10 17:58:18 2006
New Revision: 115310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115310
Log:
fixincludes:
2006-07-10 Laurynas Biveinis [EMAIL PROTECTED]
PR
Hi,
I was building a AVR cross compiler from current GCC trunk, and got an error.
Build system was Ubuntu 6.06 on an Athlon, using the latest from CVS binutils
but otherwise configured exactly as shown in
http://www.nongnu.org/avr-libc/user-manual/install_tools.html
The assertion failure that
On Jul 9, 2006, at 10:52 PM, Vladimir 'Yu' Stepanov wrote:
I would like to offer one expansion for C/C++.
Did you just reinvent downcasting in C++? If so, C++ already has
that feature!? As for C, C, I'd claim C already has that feature[1],
you merely have to put in a #define into your
This patch broke building GCC because Makefile indention was done with
spaces instead of a TAB.
Obvious fix commited, r115313. That will teach me how to think oh
well that's a tiny patch I sent a month ago, I'll just copy it from
the mail archives instead of locating it on my disk.
Sorry.
--
You forgot a ChangeLog entry for
r115313 | lauras | 2006-07-10 12:44:48 -0700 (Mon, 10 Jul 2006) | 2 lines
Fix spaces to tabs in the last commit.
I'm not sure. I think that my ChangeLog entry by my previous commit
(the
On Mon, Jul 10, 2006 at 11:24:55PM +0300, Laurynas Biveinis wrote:
You forgot a ChangeLog entry for
r115313 | lauras | 2006-07-10 12:44:48 -0700 (Mon, 10 Jul 2006) | 2 lines
Fix spaces to tabs in the last commit.
On Mon, Jul 10, 2006 at 01:34:12PM -0700, Steve Kargl wrote:
It's my understanding that every change requires a ChangeLog
entry. There is now no consistent record of the difference
between 115310 and 115311 without actually looking at svn log
fixincludes/Makefile.in.
Perhaps, a quick
On Jul 10, 2006, at 1:24 PM, Laurynas Biveinis wrote:
Do such changes require ChangeLog entries?
For my own beyond trivial fixes that I catch quickly (say, less than
24 hours), normally I just fix them with a `fix typo' type svn log
entry. When in doubt, or if you're fixing someone else's
David Brownell wrote:
/home/tux/avr/gcc/obj-avr/./gcc/xgcc -B/home/tux/avr/gcc/obj-avr/./gcc/
-B/usr/local/avr/avr/bin/ -B/usr/local/avr/avr/lib/ -isystem
/usr/local/avr/avr/include -isystem /usr/local/avr/avr/sys-include -O2 -O2 -g
-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
On Jul 11, 2006, at 4:49 AM, David Brownell wrote:
Hi,
Anyone have a fix, workaround, or other suggestion?
Yes don't use --with-dwarf2 :).
This is PR 26504:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
Also someone should try the patch in PR 26015:
I am trying to make a configure change in the libstdc++-v3 directory but
when I run aclocal (even on an unmodified libstdc++-v3 directory from
the top-of-tree), I get an error message. Does anyone else see this?
[hpsje] $ aclocal
aclocal:configure.ac:85: warning: macro `AM_PROG_LIBTOOL' not
On Mon, Jul 10, 2006 at 03:14:36PM -0700, Steve Ellcey wrote:
I am trying to make a configure change in the libstdc++-v3 directory but
when I run aclocal (even on an unmodified libstdc++-v3 directory from
the top-of-tree), I get an error message. Does anyone else see this?
My rule of thumb:
I am trying to make a configure change in the libstdc++-v3 directory but
when I run aclocal (even on an unmodified libstdc++-v3 directory from
the top-of-tree), I get an error message. Does anyone else see this?
The current fashion for regenerating the config/make bits is to just run:
This patch is an improved version over the one proposed in
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00098.html
It doesn't introduce any features. The main difference is the removal
of TREE_CONSTANT_OVERFLOW check from real_isinteger function,
following the new policy about not handling
Andreas Jaeger wrote:
# Fix for argument ‘clean_text_p’ might be clobbered by ‘longjmp’ or ‘vfork’
unprotoize.o-warn = -Wno-error
This is OK.
PR 21161 and PR 24239 are different instances of the same problem, so we
don't need another bug report for this. The previously mentioned PR
21059
Gosh, so close...
I found that the below patch gets me one step closer to it building.
I'm sure it is wrong... but it should be enough of a hint for the
right person to know how to fix it.
Doing diffs in libstdc++-v3:
--- libstdc++-v3/include/ext/codecvt_specializations.h.~1~
On Monday 10 July 2006 22:42, [EMAIL PROTECTED] wrote:
Snapshot gcc-4.2-20060708 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060708/
something is brkoen here ...
[~/gcc]
../gcc-src/gcc-4.2-20060708/gcc/configure
ups, should of course have been
Anyone have a fix, workaround, or other suggestion?
Yes don't use --with-dwarf2 :).
Only a short term workaround... ;)
This is PR 26504:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
Comment #8 there seems on-the-mark, so the PR 26015 fix has
two half-confirmations now:
Also
This patch is an improved version over the one proposed in
Please avoid cross-posting. This should go on [EMAIL PROTECTED] only.
--
Eric Botcazou
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-10 07:20 ---
How old of binutils do you have?
Also -_SYSTYPE_SVR4 was added in 3.3 so you must be doing something wrong.
Can you try adding --with-gnu-as when configuring?
--
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-07-10 07:21
---
Fixed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Compile this with current 4.1 branch (verified with 4.1.2 20060710):
% cat one.ii
template typename T
struct One {
static const int A;
};
template typename T
const int OneT::A = 5;
int f()
{
return Oneint::A;
}
% ./gcc/cc1plus one.ii gcc -c one.s nm one.o | c++filt
U
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-10 08:53 ---
*** This bug has been marked as a duplicate of 28016 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-07-10 08:53
---
*** Bug 28327 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from matz at gcc dot gnu dot org 2006-07-10 08:57 ---
Mark, please apply to 4.1 branch also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to fail|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28299
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-07-10 12:19 ---
It doesn't compile with 4.1 either due to errors. Can you re-do preprocessed
source for 4.1 and possibly mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-10 12:32 ---
Numbers for -static -O3 -march=pentium4 -fomit-frame-pointer (on a P4)
3.4.6: 8.1s
4.0.3: 7.3s
4.1.1: 13.5s
4.2.0: 4.2s
(is there a correctness check inside the benchmark?)
with FDO:
3.4.6: 5.8s
4.0.3:
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-10 12:45 ---
I get on a Pentium 4, -O3 -march=pentium4 -fomit-frame-pointer -o bench
Random.i SparseCompRow.i array.i kernel.i main.i
3.4.6: 3.48s
4.0.3: 4.44s
4.1.1: 4.12s
4.2.0: 4.13s
--
rguenth at gcc dot gnu dot org
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-07-10 13:00
---
This seems to worked around on the mainline and also fails for 4.0.3.
Basically, on the mainline you can still see the behavior if using
-fno-if-conversion.
Short testcase:
int
foo (int *a, char * p)
{
int d;
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-10 13:24 ---
Confirmed. In 4.1, the data-refs have the wrong memtag associated:
Created dr for *D.2061_7
base_address: data__6
offset from base address: 0
constant offset from base address: 0
--- Comment #2 from jari dot aalto at cante dot net 2006-07-10 16:23
---
(In reply to comment #1)
This warning does not come from the GCC but instead the linker but really
glibc is where the warning is located, please report this bug to glibc.
Reported as:
--- Comment #1 from ian at airs dot com 2006-07-10 16:27 ---
This is not a bug in the compiler. The .set reorder directive tells the
assembler that it should reorder instructions into branch delay slots when
possible. The compiler just copies the .set reorder directly from the asm
--- Comment #7 from sje at gcc dot gnu dot org 2006-07-10 17:19 ---
Subject: Bug 28084
Author: sje
Date: Mon Jul 10 17:19:01 2006
New Revision: 115309
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115309
Log:
PR target/28084
* inclhack.def (hpux_extern_errno):
--- Comment #4 from sje at cup dot hp dot com 2006-07-10 17:20 ---
The patch for PR 28084 has been backported to the 4.1 branch and this is now
fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from markus at unixforces dot net 2006-07-10 17:41 ---
I tried this:
$ make LDFLAGS= LIBPATH=/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1
BOOT_CFLAGS=-m64 -O2 -pipe -mtune=power3 -mcpu=power3 profiledbootstrap
[...]
make[4]: Entering directory
--- Comment #4 from lauras at gcc dot gnu dot org 2006-07-10 17:58 ---
Subject: Bug 20437
Author: lauras
Date: Mon Jul 10 17:58:18 2006
New Revision: 115310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115310
Log:
fixincludes:
2006-07-10 Laurynas Biveinis [EMAIL PROTECTED]
--- Comment #5 from lauras at gcc dot gnu dot org 2006-07-10 18:04 ---
The fix will appear in 4.2.0, thanks for your report.
--
lauras at gcc dot gnu dot org changed:
What|Removed |Added
In the original ProPolice that the gcc 4.1 stack smash protection was derived
from, a stack smash would illicit a message similar to:
*** Stack smashing detected in function vuln() in source file net.c!!! Aborted
Examining the current source, the following code exists:
void
__stack_chk_fail
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-07-10 19:33 ---
Subject: Bug 15448
Author: bkoz
Date: Mon Jul 10 19:32:51 2006
New Revision: 115312
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115312
Log:
2006-07-10 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #9 from tromey at gcc dot gnu dot org 2006-07-10 19:33 ---
I think Andrew Haley's commit to the gcj-eclipse branch fixed this.
I'm closing it and marking it as target == 4.3; presumably the ecj
merge will happen in that release.
Andrew Hughes -- if this still happens for
This only happens with the gcj on the gcj-eclipse branch.
Doing a build with the new gcj leaves many .zip and .jar files
in /tmp. This is probably a bug in java/lang-specs.h, but could
also be a bug in gcc.c.
--
Summary: [ecj] gcj leaves .jar and .zip files in /tmp
The error is an invocation of operator(ringcacheRequest, loadRequest*).
ringcacheRequest defines operator(ringcacheRequest, cacheRequest*), and
cacheRequest is a public base of the actual loadRequest argument. If the right
argument is explicitly cast to cacheRequest* (as shown in the line
--- Comment #1 from igodard at pacbell dot net 2006-07-10 20:11 ---
Created an attachment (id=11855)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11855action=view)
compiler output -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28330
--- Comment #2 from igodard at pacbell dot net 2006-07-10 20:11 ---
Created an attachment (id=11856)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11856action=view)
save-temps source (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28330
--- Comment #14 from ro at techfak dot uni-bielefeld dot de 2006-07-10
20:17 ---
Subject: Re: [4.2 Regression] error: 'iconv_t' does not name a type
pcarlini at suse dot de writes:
It seemd to me that the best thing to do is adding the include on top of
codecvt_specializations.h
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2006-07-10
20:27 ---
Subject: Re: libgomp fails to configure on Tru64 UNIX
echristo at apple dot com writes:
Well, it shouldn't have mattered, but try re-adding the CFLAGS line that I
think I accidentally deleted just
--- Comment #5 from sje at gcc dot gnu dot org 2006-07-10 20:42 ---
Subject: Bug 28114
Author: sje
Date: Mon Jul 10 20:42:14 2006
New Revision: 115314
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115314
Log:
PR c++/28114
* name-lookup.c (pushtag): Return if we
--- Comment #6 from sje at gcc dot gnu dot org 2006-07-10 20:43 ---
Subject: Bug 28114
Author: sje
Date: Mon Jul 10 20:43:34 2006
New Revision: 115315
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115315
Log:
PR c++/28114
* g++.dg/other/pr28114.C: New.
Added:
--- Comment #7 from sje at cup dot hp dot com 2006-07-10 20:46 ---
I have checked in a patch for ToT and on the 4.1 branch. My inclination is to
not fix this on the 4.0 branch because the patch doesn't apply automatically.
The same change is probably needed somewhere else for 4.0, but
--- Comment #2 from echristo at apple dot com 2006-07-10 21:01 ---
Removing regression.
--
echristo at apple dot com changed:
What|Removed |Added
Summary|[4.2
--- Comment #5 from echristo at apple dot com 2006-07-10 21:03 ---
Well, the original place isn't correct because -pthread isn't valid for all
platforms, but it could be moved to where I have XPCFLAGS for non-darwin
targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
--- Comment #7 from sje at gcc dot gnu dot org 2006-07-10 21:05 ---
Subject: Bug 27019
Author: sje
Date: Mon Jul 10 21:05:00 2006
New Revision: 115316
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115316
Log:
PR c++/27019
* g++.dg/ext/pr27019.C: New.
Added:
--- Comment #8 from sje at gcc dot gnu dot org 2006-07-10 21:05 ---
Subject: Bug 27019
Author: sje
Date: Mon Jul 10 21:05:45 2006
New Revision: 115317
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115317
Log:
PR c++/27019
* typeck2.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-10 21:26 ---
Why not use a debuger to debug your program when stack smasher happens?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-07-10 21:37 ---
I think this is fixed, or as close as we can come.
There is now a checksum, and there are no longer any stamp files to do creation
of PCH files. Thus, in theory, this should be no longer an issue.
--
bkoz at gcc
Hi,
After calling __builtin_ia32_movntq, floating point operations do not seem to
work anymore :
When compiling this with the msse flag :
--
#include unistd.h
#include stdio.h
#include stdlib.h
int main()
{
unsigned long long int
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-10 22:36 ---
You forgot to flush the MMX/x87 registers since fp and MMX registers are the
same set and the hardware does not support them at the same time.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from cedric dot augonnet at ens-lyon dot org 2006-07-10
22:56 ---
(In reply to comment #1)
You forgot to flush the MMX/x87 registers since fp and MMX registers are the
same set and the hardware does not support them at the same time.
Ok, i see that adding
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-10 22:59 ---
You should not be using the builtins directly anyways. You should being the
intrincics which are source compatiable with Intel's intrincics. Also this
problem is documented with any part of the ISA of mmx anyways
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-07-10 23:02 ---
Richard Sandiford gave a more thorough patch in
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00335.html
and it's approved for the next stage1 of mainline.
--
kkojima at gcc dot gnu dot org changed:
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-07-10 23:17
---
This now affects powerpc-darwin:
/Users/regress/tbox/native/build/./gcc/xgcc -shared-libgcc
-B/Users/regress/tbox/native/build/./gcc -nostdinc++
--- Comment #4 from cedric dot augonnet at ens-lyon dot org 2006-07-10
23:17 ---
(In reply to comment #3)
You should not be using the builtins directly anyways. You should being the
intrincics which are source compatiable with Intel's intrincics. Also this
problem is documented
I do not have a copy of the C++ standard, so I am not sure if this is required
behaviour. However, I do know that G++ gives out a somewhat confusing error
that could be changed. My test case follows all of the other required
information.
The trouble is that G++ doesn't give me an error when I
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-10 23:39 ---
namespace foo
{
namespace bar
{
class A
{
public:
friend class B;
That class B is really class foo::bar::B.
This is all mentioned on the 4.0 changes page:
http://gcc.gnu.org/gcc-4.0/changes.html
The
--- Comment #1 from rmathew at gcc dot gnu dot org 2006-07-11 01:20 ---
Perhaps the %d string was omitted in the relevant specs:
http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
Just guessing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28329
--- Comment #5 from wilson at gcc dot gnu dot org 2006-07-11 01:32 ---
This is already fixed on dataflow-branch. At the end of combine_instructions,
it runs a global dataflow pass that removes all REG_DEAD and REG_UNUSED notes
before creating new ones.
--
--- Comment #6 from wilson at gcc dot gnu dot org 2006-07-11 01:41 ---
Created an attachment (id=11857)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11857action=view)
Delete old REG_DEAD notes before creating new ones.
This works for the testcase, but is otherwise untested. This
It should be possible to at least configure SSP to always log to syslog(). Of
course since it's (apparently) /usr/lib/libssp.so.0 (usr? I should talk to my
distro maintainers about that...), I suppose I could replace this with my own
version..
The logging of SSP kills to syslog() is useful
--- Comment #2 from nigelenki at comcast dot net 2006-07-11 02:43 ---
The program may be on an end user system that A) has insufficient debugging
data compiled in (though I'd imagine you know what function it's in anyway); or
B) has an end user that can't/won't debug (typical). It may
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-11 03:02 ---
If an end user gets a stack smash failure, they should report the bug to the
developer and have the developer fix it.
This is what is normally done for anyother bug, why should it be different than
a stack smashing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-11 03:03 ---
Again an end user should not care what caused the bug, even if it gives more
information to the developer faster, the developer should be able to debug the
program just fine. Also using SSP is about not trusting
--- Comment #4 from nigelenki at comcast dot net 2006-07-11 03:09 ---
(In reply to comment #3)
If an end user gets a stack smash failure, they should report the bug to the
developer and have the developer fix it.
This is what is normally done for anyother bug, why should it be
--- Comment #2 from nigelenki at comcast dot net 2006-07-11 03:27 ---
And the developer is going to debug a program nice and slow when those obscure,
hard to trigger bugs come along.
I was just toying with metasploit the other day. Threw an exploit at Windows
to get me a remote VNC
--- Comment #4 from fengwang at gcc dot gnu dot org 2006-07-11 04:09
---
Subject: Bug 28213
Author: fengwang
Date: Tue Jul 11 04:09:40 2006
New Revision: 115326
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115326
Log:
2006-07-11 Feng Wang [EMAIL PROTECTED]
PR
--- Comment #5 from fengwang at gcc dot gnu dot org 2006-07-11 04:10
---
Subject: Bug 28213
Author: fengwang
Date: Tue Jul 11 04:10:31 2006
New Revision: 115327
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115327
Log:
2006-07-11 Feng Wang [EMAIL PROTECTED]
PR
--- Comment #5 from solar at gentoo dot org 2006-07-11 04:25 ---
John is mostly right in reporting this.
Gentoo uses SSP more than anyone else out there for longer than most
anybody (obsd excluded) and I can't stress how vital it is to have the
function hint that Etoh's original
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-11 04:27 ---
(In reply to comment #2)
And the developer is going to debug a program nice and slow when those
obscure,
hard to trigger bugs come along.
An end user should not care why something crashed, it just confuses them
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-11 04:27 ---
(In reply to comment #4)
Thank you, I see the problem, there's a patch attached. Your distribution
should have a new version some time in a couple days.
Here is how normal GCC bugs go:
User (which is a
--- Comment #4 from solar at gentoo dot org 2006-07-11 04:28 ---
See bug #28328 comment #5 on why this should be closed as WONTFIX/INVALID or
the likes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-11 04:31 ---
(In reply to comment #5)
This bug should get itself assigned.
You know like many other open source projects, if you really want a feature you
should implement it. As I mentioned in the other bug, knowing where
--- Comment #5 from nigelenki at comcast dot net 2006-07-11 04:44 ---
(In reply to comment #4)
See bug #28328 comment #5 on why this should be closed as WONTFIX/INVALID or
the likes.
Eh close it WONTFIX because it's not gcc's job. Like I said, the stack smash
handler can be
--- Comment #8 from nigelenki at comcast dot net 2006-07-11 04:56 ---
(In reply to comment #6)
(In reply to comment #4)
Thank you, I see the problem, there's a patch attached. Your distribution
should have a new version some time in a couple days.
Here is how normal GCC bugs
--- Comment #9 from solar at gentoo dot org 2006-07-11 04:57 ---
(In reply to comment #7)
(In reply to comment #5)
This bug should get itself assigned.
You know like many other open source projects, if you really want a feature
you
should implement it.
I would not have a
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-07-11 05:25
---
(In reply to comment #8)
Actually it won't come from 1000 lines before. It'll go like this:
int vuln(char *s, int len) {
char a[10];
char b[20];
a[0] = 0;
strcpy(a, str: );
strcat(a, s);
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-07-11 05:32
---
(In reply to comment #9)
Sorry but as somebody that has been an active supporter of ssp over the
years and somebody thats fixed dozens of bugs spotted by ssp your
statement is not really valid about exposing a
--- Comment #12 from nigelenki at comcast dot net 2006-07-11 05:49 ---
(In reply to comment #10)
(In reply to comment #8)
That is just a simple (obvious) example, you seem to not understand how real
code looks like. You might instead have:
int f(int a, int b)
{
int f[10];
95 matches
Mail list logo
