[Bug bootstrap/28324] boostrapping with gcc fails with unrecognized linker option
--- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28324
[Bug target/28170] [4.1 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- 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 Known to fail||4.1.0 Known to work||4.0.2 4.2.0 Summary|[4.1/4.2 Regression] Wrong |[4.1 Regression] Wrong |result after swap byte in |result after swap byte in |one word when compiled in |one word when compiled in |64-bit mode |64-bit mode http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug c++/28327] New: const static members generate .data defs
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 __gxx_personality_v0
T f()
D _ZN3OneIT_E1AE
(strangely enough the name _ZN3OneIT_E1AE can't be demangled, but that's
secondary).
The important point is that this is a template member, which is not defined
as weak or linkonce symbol. This breaks when the template is instantiated
in multiple .o files (it occurred while compiling obby).
Interestingly it depends on the member being marked const. Without it
the symbols look right:
V Oneint::A
With 4.1.0 this generated no .data objects at all (presumably by optimizing
away all references to it, by using the constness), and hence no symbol
conflicts, so something changed till 4.1.0.
--
Summary: const static members generate .data defs
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28327
[Bug c++/28327] const static members generate .data defs
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28327
[Bug c++/28016] [4.1 Regression] emitting template constant
--- 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 CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug c++/28016] [4.1 Regression] emitting template constant
--- 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
[Bug c/28299] ICE with -Wmissing-prototypes
-- aldot at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.2.0 Known to work||4.0.1 Priority|P3 |P2 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28299
[Bug c/28299] ICE with -Wmissing-prototypes
-- 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
[Bug middle-end/20826] [4.0/4.1/4.2 Regression] excessive compiler resource usage
--- 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
[Bug rtl-optimization/21507] [4.0/4.1 Regression] BYTEmark floating-point emulation: Regression with -O3
--- 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: 9.8s 4.1.1: 10.5s 4.2.0: 4.2s indeed interesting that we loose on FDO for 4.0, and bad that we're that much slower for 4.1. Good for mainline though. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |BYTEmark floating-point |BYTEmark floating-point |emulation: Regression with -|emulation: Regression with - |O3 |O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21507
[Bug rtl-optimization/21676] [4.0/4.1/4.2 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- 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 changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug tree-optimization/24609] [4.0/4.1/4.2 regression] Same value duplicated in two different registers
--- 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;
if (p)
d = 1;
else
d = 2;
a[0] = d;
return p[d - 1];
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.0.3 4.1.0 4.1.1 4.2.0
Known to work||3.4.6
Last reconfirmed|-00-00 00:00:00 |2006-07-10 13:00:56
date||
Summary|[4.1/4.2 regression] Same |[4.0/4.1/4.2 regression]
|value duplicated in two |Same value duplicated in two
|different registers |different registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug tree-optimization/28029] [4.1 Regression] wrong optimization with -ftree-vectorize
--- 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 base_object: step: 4B misalignment from base: 0B aligned to: 4 memtag: TMT.5 Created dr for *D.2064_15 base_address: op_14 offset from base address: 0 constant offset from base address: 0 base_object: step: 4B misalignment from base: 0B aligned to: 4 memtag: TMT.6 after ifcvt: # TMT.6_22 = PHI TMT.6_21(3), TMT.6_20(1); # i_2 = PHI i_18(3), 0(1); L0:; D.2059_4 = i_2 * 4; D.2060_5 = (float *) D.2059_4; D.2061_7 = D.2060_5 + data__6; # VUSE TMT.6_22; D.2062_11 = *D.2061_7; D.2063_13 = (const float *) D.2059_4; D.2064_15 = D.2063_13 + op_14; # VUSE TMT.6_22; D.2065_16 = *D.2064_15; D.2066_17 = D.2062_11 * D.2065_16; # TMT.6_21 = V_MAY_DEF TMT.6_22; *D.2061_7 = D.2066_17; i_18 = i_2 + 1; if (size__3 i_18) goto L8; else goto L2; L8:; goto bb 2 (L0); no idea where that TMT.5 comes from (it's from the const qualifier, but the vectorizer makes this up itself). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.1 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-07-10 13:24:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28029
[Bug c/28310] [improve] warning: the use of `mktemp' is dangerous, better use `mkstemp'
--- 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: http://sources.redhat.com/bugzilla/show_bug.cgi?id=2898 Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28310
[Bug middle-end/28325] -fno-delayed-branch does not seem to work with the MIPS branch instructions
--- 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 statement. Both the compiler and the assembler are acting as expected. You should rewrite your asm statement to not use .set reorder. Do this instead: .set push .set noreorder ... .set pop -- ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28325
[Bug target/28084] [4.2 Regression] /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage
--- 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): New. * fixincl.x: Regenerate. Modified: branches/gcc-4_1-branch/fixincludes/ChangeLog branches/gcc-4_1-branch/fixincludes/fixincl.x branches/gcc-4_1-branch/fixincludes/inclhack.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28084
[Bug target/28320] bootstrap failure in libstdc++-v3
--- 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 CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28320
[Bug bootstrap/28326] [4.1/ICE] gcc-4.1.0 won't compile on power3
--- 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 `/root/gcc-4.1.1-temp/build/gcc' make[4]: `crtend.o' is up to date. make[4]: `crtbeginS.o' is up to date. make[4]: `crtendS.o' is up to date. make[4]: `crtbeginT.o' is up to date. make[4]: `ecrti.o' is up to date. make[4]: `ecrtn.o' is up to date. make[4]: `ncrti.o' is up to date. make[4]: `ncrtn.o' is up to date. make[4]: `crtsavres.o' is up to date. make[4]: Leaving directory `/root/gcc-4.1.1-temp/build/gcc' ./xgcc -B./ -B/usr/powerpc64-unknown-linux-gnu/bin/ -isystem /usr/powerpc64-unknown-linux-gnu/include -isystem /usr/powerpc64-unknown-linux-gnu/sys-include -L/root/gcc-4.1.1-temp/build/gcc/../ld -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -specs=ldblspecs -mno-minimal-toc -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include -fPIC -mstrict-align -DL_muldi3 -c ../../gcc-4.1.1/gcc/libgcc2.c -o libgcc/./_muldi3.o /tmp/ccCAOUnw.s: Assembler messages: /tmp/ccCAOUnw.s:71: Warning: Unary operator - ignored because bad operand follows /tmp/ccCAOUnw.s:71: Warning: zero assumed for missing expression /tmp/ccCAOUnw.s:72: Error: Unrecognized opcode: `f' /tmp/ccCAOUnw.s:76: Error: Unrecognized opcode: `f' /tmp/ccCAOUnw.s:1160: Error: unassigned file number 2 make[3]: *** [libgcc/./_muldi3.o] Error 1 make[3]: Leaving directory `/root/gcc-4.1.1-temp/build/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/root/gcc-4.1.1-temp/build/gcc' make[1]: *** [stageprofile_build] Error 2 make[1]: Leaving directory `/root/gcc-4.1.1-temp/build/gcc' make: *** [profiledbootstrap] Error 2 and this: $ make LDFLAGS= LIBPATH=/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1 BOOT_CFLAGS=-m64 -O2 -pipe -mtune=power3 -mcpu=power3 bootstrap last command builds fine. this is a regression then? gcc-3.4 used to build fine using profiledbootstrap. I have not tried gcc 4.0 IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28326
[Bug bootstrap/20437] bootstrap --enable-maintainer-mode broken
--- 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] PR bootstrap/20437 * Makefile.in (configure, config.h.in): change into $(srcdir) before autoconf or autoheader call. gcc: 2006-07-10 Laurynas Biveinis [EMAIL PROTECTED] PR bootstrap/20437 * Makefile.in (configure): add missing aclocal.m4 and acinclude.m4 dependencies. Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/Makefile.in trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20437
[Bug bootstrap/20437] bootstrap --enable-maintainer-mode broken
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20437
[Bug c/28328] New: Stack smash protection non-verbose
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 (void)
{
const char *msg = *** stack smashing detected ***: ;
fail (msg, strlen (msg), stack smashing detected: terminated);
}
This winds out with:
*** stack smashing detected ***: ./usr/lib/foxsrt/test/ssp_smash terminated
Unfortunately it seems this now can't be (cleanly) fixed without breaking
existing stack smash protected code. The only way to allow old behavior is to
add ANOTHER external function to libssp. One possible would be:
void
__stack_chk_fail2 (char *fctn, char *srcfile, void *damage)
{
const char *msg = *** stack smashing detected ***:;
/*Allocate: %s %s:%s (damage: 0x%p) ,msg,srcfile,fctn,damage*/
int msg2len = strlen (msg) + strlen (fctn)
+ strlen (srcfile) + sizeof(void*)*2 + 17;
char *msg2 = alloca (msg2len);
snprintf (msg2, msg2len, %s %s:%s (damage: 0x%p) ,
msg, srcfile, fctn, damage);
/* Not necessary, assuming %p doesn't spit out extra characters...*/
msg2[msg2len - 1] = '\0';
fail (msg2, strlen (msg2), stack smashing detected: terminated);
}
The emitted code would then have to call the following in case of a detected
stack smash:
__stack_chk_fail2(__FUNC__, __FILE__, __guard);
Where __FUNC__ is the function name, __FILE__ is the source file, and __guard
is the canary value in the function (which is now damaged).
The nice thing about doing something like this is that the programmer does not
have to pull out a debugger and try to reproduce stack smashing scenarios and
do a stack trace to figure out where the bug is. This is especially helpful
when an end user produces a bug report, because the bug report can say right
there, Stack smash in bad_code.c:vuln_function() and the programmer can go
right there and look through everything that the buffer is passed to and
everything he does with it to see what he messed up.
The overhead of this is an extra reference to __FILE__ and __FUNC__, which may
be generated inline or point to existing copies of those strings in the object.
The cost at runtime is only seen when a stack smash occurs. Total, the
program should get a few bytes bigger (if alignment doesn't fuzz that out) and
shouldn't run any slower, so nobody should care.
--
Summary: Stack smash protection non-verbose
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nigelenki at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug libstdc++/15448] libstdc++ does not rebuild PCH
--- 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 libstdc++/15448 * include/Makefile.am: Clean up pch rules. * include/Makefile.in: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15448
[Bug java/28222] [ecj] Fails compiling gnu/java/security/x509/X509Certificate.java
--- 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 you, reopen this PR. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28222
[Bug java/28329] New: [ecj] gcj leaves .jar and .zip files in /tmp
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 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org OtherBugsDependingO 28067 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28329
[Bug c++/28330] New: finds wrong template overload; peculiar diagnostic
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 immediately before the reported error) the correct operator is found and invoked. However, when the argument is the derived class the compiler finds and invokes an irrelevant definition of operator and then blows up inside it. The definition it finds is declared by template wideUintsize_t and in particular by wideUint1: operator(wideUint1, const uint32_t). Somehow it seems to decide that it can turn a ringcacheRequest into a wideUint1, and then complains that it can't turn a cacheRequest* into a uint32_t (which is a typedef for unsigned int). It seems to me that the compiler should be able to match the intended operator by converting to the base class. However, even if it cannot then shouldn't it just say no match found for ... rather than accepting the bogus match and then complaining about the conversion to uint32_t? -- Summary: finds wrong template overload; peculiar diagnostic Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28330
[Bug c++/28330] finds wrong template overload; peculiar diagnostic
--- 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
[Bug c++/28330] finds wrong template overload; peculiar diagnostic
--- 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
[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type
--- 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 itself and removing it from the other places where it does currently appear (because a grep reveals that the iconv facilities are *not* used anywhere else (besides the testsuite), I would appreciate of you could double check...). Can you try that? The compilation errors are gone with this change, but due to PR c++/28217, I still get an ICE: Index: codecvt_specializations.h === --- codecvt_specializations.h (revision 115313) +++ codecvt_specializations.h (working copy) @@ -38,6 +38,10 @@ * This file is a GNU extension to the Standard C++ Library. */ +#if _GLIBCXX_USE_ICONV +# include iconv.h +#endif + // XXX // Define this here so codecvt.cc can have _S_max_size definition. #define _GLIBCXX_USE_ENCODING_STATE 1 Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libgomp/28296] [4.2 Regression] libgomp fails to configure on Tru64 UNIX
--- 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 after XPCFLAGS: CFLAGS=$CFLAGS -pthread which is also just plain wrong, but perhaps this too should be moved inside the case block. Restoring this in the original place works (at least make configure-target-libgomp completes successfully). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug c++/28114] [4.0/4.1 regression] ICE with struct definition in argument of template function
--- 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 have error_mark_node. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/name-lookup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28114
[Bug c++/28114] [4.0/4.1 regression] ICE with struct definition in argument of template function
--- 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: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/pr28114.C Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28114
[Bug c++/28114] [4.0/4.1 regression] ICE with struct definition in argument of template function
--- 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 I don't think it is worth the trouble to find out where. Should I close this out as fixed in 4.1.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28114
[Bug target/27543] attribute ms_struct is now also for rs6000 but not documented
--- 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 Regression] attribute |attribute ms_struct is now |ms_struct is now also for |also for rs6000 but not |rs6000 but not documented |documented http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug libgomp/28296] [4.2 Regression] libgomp fails to configure on Tru64 UNIX
--- 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
[Bug c++/27019] [4.1 regression] ICE with designated initializers
--- 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: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/pr27019.C Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27019
[Bug c++/27019] [4.1 regression] ICE with designated initializers
--- 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 (process_init_constructor_array): Set ce-value on errors. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/typeck2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27019
[Bug other/28328] Stack smash protection non-verbose
--- 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 Component|c |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug libstdc++/15448] libstdc++ does not rebuild PCH
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2005-12-31 03:00:09 |2006-07-10 21:32:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15448
[Bug libstdc++/15448] libstdc++ does not rebuild PCH
--- 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 dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15448
[Bug c/28331] New: Problem with floating point operations after calling __builtin_ia32_movntq
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 a,b;
a = 1ULL;
b = 2ULL;
__builtin_ia32_movntq(a,b);
printf(%f\n, ((float) (1*2)));
return 0;
}
It returns nan instead of 2 as we might have expected.
Regards,
Cédric
--
Summary: Problem with floating point operations after calling
__builtin_ia32_movntq
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cedric dot augonnet at ens-lyon dot org
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28331
[Bug target/28331] Problem with floating point operations after calling __builtin_ia32_movntq
--- 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|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28331
[Bug target/28331] Problem with floating point operations after calling __builtin_ia32_movntq
--- 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 __builtin_ia32_emms() solves the problem indeed, thanks! Still, this does not seem to be documented yet, wouldn't it be a good thing to change this ? For instance it might have been notified in http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28331
[Bug target/28331] Problem with floating point operations after calling __builtin_ia32_movntq
--- 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 which you should read. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28331
[Bug target/28232] Wrong aligned load is generated with -m4a on sh-*
--- 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: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kkojima at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-10 23:02:25 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28232
[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type
--- 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++ -L/Users/regress/tbox/native/build/powerpc-apple-darwin8.5.0/libstdc++-v3/src -L/Users/regress/tbox/native/build/powerpc-apple-darwin8.5.0/libstdc++-v3/src/.libs -B/Users/regress/tbox/objs/powerpc-apple-darwin8.5.0/bin/ -B/Users/regress/tbox/objs/powerpc-apple-darwin8.5.0/lib/ -isystem /Users/regress/tbox/objs/powerpc-apple-darwin8.5.0/include -isystem /Users/regress/tbox/objs/powerpc-apple-darwin8.5.0/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -I/Users/regress/tbox/native/build/powerpc-apple-darwin8.5.0/libstdc++-v3/include/powerpc-apple-darwin8.5.0 -I/Users/regress/tbox/native/build/powerpc-apple-darwin8.5.0/libstdc++-v3/include -I/Users/regress/tbox/svn-gcc/libstdc++-v3/libsupc++ -O2 -g /Users/regress/tbox/svn-gcc/libstdc++-v3/include/precompiled/extc++.h -o powerpc-apple-darwin8.5.0/bits/extc++.h.gch/O2g.gch /Users/regress/tbox/native/build/powerpc-apple-darwin8.5.0/libstdc++-v3/include/ext/codecvt_specializations.h:57: error: 'iconv_t' does not name a type PPC-darwin has an iconv.h also. -- 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=28290
[Bug target/28331] Problem with floating point operations after calling __builtin_ia32_movntq
--- 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 with any part of the ISA of mmx anyways which you should read. I should indeed read it more carefully. But my point was that __builtin_ia32_emms() is never mentionned at all, only femms is. And actually it was already mentionned in http://gcc.gnu.org/ml/gcc-bugs/2003-05/msg00198.html. So this problem - with documentation, not gcc itself - was in 3.3, it is still there in 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28331
[Bug c++/28332] New: friend classes require explicit qualification when in twin nested namespaces
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 declare class B to be a
friend of class A, instead, it just ignores the declaration altogether unless i
explicitly qualify B to be foo::B, in which case it works.
**G++ version info**
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
**Command line**
g++ testcase.cpp
**Errors**
[EMAIL PROTECTED] ~]$ g++ testcase.cpp
testcase.cpp: In member function void foo::B::do_another(foo::bar::A):
testcase.cpp:20: error: virtual void foo::bar::A::do_something() is protected
testcase.cpp:36: error: within this context
**Preproccessed Testcase from -save-temps**
# 1 testcase.cpp
# 1 built-in
# 1 command line
# 1 testcase.cpp
namespace foo
{
namespace bar
{
class A;
};
class B;
};
namespace foo
{
namespace bar
{
class A
{
public:
friend class B;
protected:
virtual void do_something()=0;
};
};
class B
{
public:
void do_another(bar::A a);
};
};
using namespace foo;
using namespace foo::bar;
void B::do_another(A a)
{
a.do_something();
}
void A::do_something()
{
}
int main ( int argc, char *argv[] )
{
}
--
Summary: friend classes require explicit qualification when in
twin nested namespaces
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: genixpro at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28332
[Bug c++/28332] friend classes require explicit qualification when in twin nested namespaces
--- 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 error message is correct as foo::B is not a friend of foo::bar::A.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28332
[Bug java/28329] [ecj] gcj leaves .jar and .zip files in /tmp
--- 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
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- 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 just deletes the old REG_DEAD notes for a local life update before creating new ones. I believe this could be made simpler by eliminating UPDATE_LIFE_GLOBAL_RM_NOTES, and then calling count_or_remove_death_notes if PROP_DEATH_NOTES is set for both global and local updates. However, assuming we want what is on dataflow-branch, it seems better to go with a safer non-conflicting patch for now, and let dataflow-branch be the long term fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug other/28334] New: SSP always log to syslog()
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 because it allows users who are not monitoring the program in a console (think Firefox, gnome-session, etc) to retrieve stack smash information after a crash. Currently this would allow a user to immediately know if the program died due to a stack smash; however, in tandem with bug #28328, this could become much more useful. A useful consideration is that a distribution could supply a daemon that may be configured to watch syslog() for stack smashes. This daemon could then report stack smashes back to the distribution maintainers automatically (users rarely do). In tandem with bug #28328, such a tool could report not only the program that overflowed; but also report the source file and function that was overflowed. This is quite enough data to place a developer straight at the root of the problem: the function that the overflowed buffer was allocated in. From there it's relatively easy to trace down the problem-- orders of magnitude easier than having to examine the ENTIRE codebase to figure out WHICH buffer was overflowed AND why. Lacking such a tool, being able to quickly determine if there was a stack smash (and where if we consider #28328) would allow bug-reporters and newbies crying in the IRC channel of any distribution or project to return useful information in a few seconds, without the developers jumping through hoops trying to calm them down. (considering bug #28328, they could be waved away in under a minute, since they could give all useful information in that time). -- Summary: SSP always log to syslog() Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nigelenki at comcast dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
[Bug other/28328] Stack smash protection non-verbose
--- 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 also be difficult to reproduce the crash the user experiences when a stack smash occurs (hence why I am considering filing a bug about ALWAYS reporting stack smashing to syslog() to go with this*). Imagine an Ubuntu, Fedora Core, Mandriva, XandrOS, or MEPHIS Linux user encountering a mysterious crash that happens to be a stack smash. These distributions are largely aimed at typical users that will A) ignore it; or B) run to IRC and go help help wut happen :( and then bail out before reaching bugzilla. At least in the case of (B) someone can say Type dmesg or hit system-logs and click security and tell me what it says* and instantly have useful data. Another thought I had is that the stack trace may be destroyed; but this is not an issue, since the current function calls __stack_chk_fail() and thus passes us the current address, allowing us to find the function owning the overflowed buffer. This of course is only useful if the program happens to smash the stack while running in a debugger. *See bug #28334 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- 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 one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28334] SSP always log to syslog()
--- 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 the developer which means at that point you have to trust yourself to be able to debug the program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
[Bug other/28328] Stack smash protection non-verbose
--- 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 different than a stack smashing one? Because, like any normal report, it will go something like this: END USER: xmms crashed DEVELOPER: I need more info. END USER: it crashed what do u mean DEVELOPER: Why did it crash? END USER: i unno it just did it was playin mp3s n it died DEVELOPER: Did a specific MP3 cause it to crash? END USER: maybe i cant make it do it agan tho i dunno y DEVELOPER: Huh. Meh. I'll figure it out some time next year. I would ultimately rather the report go like this: END USER: xmms crashed DEVELOPER: OK, can you see why? First you should check 'dmesg | grep stack smash | grep xmms' END USER: ** stack smashing detected ***: mpg123_decode.c:decode_spline() (damage: 0xdeadbeef) Terminated DEVELOPER: Thank you, I see the problem, there's a patch attached. Your distribution should have a new version some time in a couple days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28334] SSP always log to syslog()
--- 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 session (vncdllbind payload). The exploit I used was active since WinNT4sp3 all the way up to WinXPSP1. Do you know how many years that is for an active buffer overflow to be around? How many times was that obscurely triggered like ONE TIME by someone who didn't know nor care why his OS just rebooted? Twice? Three times? Stuff like this can be patched on the distro end; this bug is mostly a proof of concept that I doubt is going to gain any traction. I'm more interested in #28328 tbh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
[Bug fortran/28213] ICE: Hollerith constant
--- 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 fortran/28213 * gfortran.dg/hollerith4.f90: Test hollerith constants used in I/O list. 2006-07-11 Feng Wang [EMAIL PROTECTED] PR fortran/28213 * trans-io.c (ransfer_expr): Deal with Hollerith constants used in I/O list. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/hollerith4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28213
[Bug fortran/28213] ICE: Hollerith constant
--- 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 fortran/28213 * gfortran.dg/hollerith4.f90: Test hollerith constants used in I/O list. 2006-07-11 Feng Wang [EMAIL PROTECTED] PR fortran/28213 * trans-io.c (ransfer_expr): Deal with Hollerith constants used in I/O list. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-io.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/hollerith4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28213
[Bug other/28328] Stack smash protection non-verbose
--- 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 __stack_smash_handler() offered from a distro point of view. When the initial porting of etohs code was done for 4.x this feature should of been ported also but sadly was not. I would ignore the part in his comments about syslog() as running the handler past that would mean that all vio/*intf functionality would have to have ssp disabled on it in *libc which pretty much means all of the libc. And dmesg() is moot cuz ssp userland handlers can't really reach that level of the kernel nor should they try. This bug should get itself assigned. -- solar at gentoo dot org changed: What|Removed |Added CC||solar at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28334] SSP always log to syslog()
--- 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 even more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
[Bug other/28328] Stack smash protection non-verbose
--- 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 developer, not neccessary of GCC): I ran some code through GCC and GCC produced an internal compiler error. Developer of GCC (if they did not follow the directions on the web page): Can you attach the preprocessed source as mentioned on http://gcc.gnu.org/bugs.html (if they did attach it, it is usually easy to figure out what is going on). Really the developer should set up a correct way of reporting a bug, what they require to report the bug. Like your example, xmms instructions should be like: attach the sound file you were trying to play. Everything else should fall out from there. Now if developer's don't care about their user that much, the user will move away from that program. This is called common sense about supply and demand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28334] SSP always log to syslog()
--- 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
[Bug other/28328] Stack smash protection non-verbose
--- 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 something crashed is only part of the story on debugging, you also need to know why, which can be much harder to see as the problem comes from 1000 lines before. So getting this info is only useful for obvious bugs which someone could spot by going through the code line by line. Also the user should not know your internals of your program, it just confuses them and in fact it might cause some of IP to be exposed and you don't want that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28334] SSP always log to syslog()
--- 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 altered distro-side as long as the same API is kept. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
[Bug other/28328] Stack smash protection non-verbose
--- 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 go:
...
attach the sound file you were trying to play.
...
But but! I have 18,397 files in XMMS! It was on another virtual desktop when
it crashed! It was in shuffle mode! I don't KNOW what file it was trying to
play and I can't get it to reproduce it!
Compilers are easy. They die and say holy crap I was trying to process this
and my tree did this and I failed to spill a register help! and you go to the
bugzilla and go It told me to give you this file it spit out and go home.
(In reply to comment #5)
John is mostly right in reporting this.
...
I would ignore the part in his comments about syslog() as running the
handler past that would mean that all vio/*intf functionality would
have to have ssp disabled on it in *libc which pretty much means all of
the libc.
Yeah, ignore that, it can be dealt with distro-side and I'll find another way
that's friendlier. open and a named pipe, or a UNIX socket, or something. The
handler's exact function can be altered without an API change.
(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'll try with 4.1.1 but I warn you I have no idea how gcc works internally.
Gimme a little help if I get stuck? :)
I'll poke the gcc ML if I get anywhere. I guess I'll start by unit testing my
stack check fail function.
As I mentioned in the other bug, knowing where something
crashed is only part of the story on debugging, you also need to know why,
which can be much harder to see as the problem comes from 1000 lines before.
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);
return strlen(a);
}
Result:
*** stack smashing detected ***: vuln.c:vuln() (damage: 0xdeadbeef) /bin/vuln
Terminated
We know that we trashed a[] or b[]. Let's imagine there's 3000 other
functions, and figure out where to look... oh, in vuln.c in vuln().
So getting this info is only useful for obvious bugs which someone could spot
by going through the code line by line.
Of course you could write a test case for your code, if you know where your
code is breaking.
Also the user should not know your internals of your program, it just confuses
them and in fact it might cause some of IP to be exposed and you don't want
that.
Confusing the user is a shoddy argument. What's the alternative? Attempt to
reproduce it, even though you can't after 5 hours? Run it through gdb,
because I can't reproduce it on my end? Trust me if you say to the user, It
should spit out something like 'IP: 0x7b, SP: 0x99, stack dump: 00 77 de ad be
ef ca fe ba be', give me that, he'll go uh... okay... don't know how you can
make any sense of any of that junk but...
IP exposure is a shoddy argument, a static function name is not important and
an external function name is readable via readelf -s.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- 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 problem doing that when I have some free time and am ready to move to gcc-4.x. As I mentioned in the other bug, knowing where something crashed is only part of the story on debugging, you also need to know why, which can be much harder to see as the problem comes from 1000 lines before. So getting this info is only useful for obvious bugs which someone could spot by going through the code line by line. Also the user should not know your internals of your program, it just confuses them and in fact it might cause some of IP to be exposed and you don't want that. 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 function name to end users. You might be surprised in fact at how many end users are also problem solvers. The printing a function name is not really an info leak nor is it exposing IP anymore than say looking .dynstr itself. I don't mean in anyway to insult you in saying so. I'm just saying I know what I'm talking about as somebody who has delt with many bugs with respect to this very thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- 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);
return strlen(a);
}
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];
.
f[a] = 1;
return f[b];
}
Where you know that a should be between 0 and 9 but comming into the function
it is not, so the value of a is wrong and you have to track down why that is
which can be a million lines in execution before calling of f. This is a stack
smashing bug also, yes a less common one than the obvious ones which you showed
but it is still going to happen. The obvious ones are easy to find in an audit
of the code, unlike this one. You can add asserts to the function but that
will produce as much useful info as the info you want from the stack smasher.
It is only useful for starting to debug the program, even then you get the
information just as quick from the debugger.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- 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 function name to end users. I am not saying ssp is bad, I am saying it is only a small tool in debuging/development and should be kept that way. If there are trust problems, then ssp is used and the end user is not trusting the developer of the program anyways. Oh you don't know lawyers (or non open source companies) that well when it comes to IP :). You might be surprised in fact at how many end users are also problem solvers. You are talking about gentoo end users and end users who actually semi care about being semi developers which have to be problem solvers. You forget about real end users like say a game player. He does not care why your program crashes, he just wants a fix or he might just ask for a refund since your program does not work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- 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];
.
f[a] = 1;
return f[b];
}
Where you know that a should be between 0 and 9 but comming into the function
it is not, so the value of a is wrong and you have to track down why that is
which can be a million lines in execution before calling of f. This is a
stack
smashing bug also, yes a less common one than the obvious ones which you
showed
but it is still going to happen. The obvious ones are easy to find in an
audit
of the code, unlike this one. You can add asserts to the function but that
will produce as much useful info as the info you want from the stack smasher.
It is only useful for starting to debug the program, even then you get the
information just as quick from the debugger.
You make the assumption that I somehow know the bug is in f(). What if I have
a 64 million line program with several hundred thousand functions like this,
and the bug is obscure and hard to reproduce? Where do I start? How do I know
the bug is in f()?
(In reply to comment #11)
(In reply to comment #9)
...
I am not saying ssp is bad, I am saying it is only a small tool in
debuging/development and should be kept that way.
Don't worry, it will be. I am only interested in getting a facility to obtain
information that says to start somewhere around here.
If there are trust problems,
then ssp is used and the end user is not trusting the developer of the program
anyways.
SSP is a safety net. If you can't trust the developer of the program, then you
assume the program is malicious, and don't run it because it's backdoored. SSP
is not a tool to stop untrusted developers, it's a tool to catch minor
mistakes.
.
You forget about
real end users like say a game player. He does not care why your program
crashes, he just wants a fix or he might just ask for a refund since your
program does not work.
I am experiencing a crash on level 10, sometimes when I enter this room
OK we'll look into it *months go by*
How about:
I am experiencing a crash on level 10, sometimes when I enter this room
OK, look in ~/level_10_dump.dbg, send me that file (game supplies an
overriden __stack_chk_fail() that also spits out a debug file) *patch released
4 days later*
I've heard enough stories about being on the phone with Apple for a total of 50
hours or whatnot, it's been fun but I'd rather just e-mail a file or copy-paste
a line of text and be done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
