--- 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];
70 matches
Mail list logo
