[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
struct One {
static const int A;
};
template
const int One::A = 5;
int f()
{
return One::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 One::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 ; # i_2 = PHI ; :; D.2059_4 = i_2 * 4; D.2060_5 = (float *) D.2059_4; D.2061_7 = D.2060_5 + data__6; # VUSE ; D.2062_11 = *D.2061_7; D.2063_13 = (const float *) D.2059_4; D.2064_15 = D.2063_13 + op_14; # VUSE ; D.2065_16 = *D.2064_15; D.2066_17 = D.2062_11 * D.2065_16; # TMT.6_21 = V_MAY_DEF ; *D.2061_7 = D.2066_17; i_18 = i_2 + 1; if (size__3 > i_18) goto ; else goto ; :; goto (); 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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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<<(ring&, loadRequest*). ring defines operator<<(ring&, 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 wideUint and in particular by wideUint<1>: operator<<(wideUint<1>, const uint32_t&). Somehow it seems to decide that it can turn a ring& into a wideUint<1>, 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=11855&action=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=11856&action=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 +#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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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
#include
#include
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 ""
# 1 ""
# 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=11857&action=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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
[Bug other/28328] Stack smash protection non-verbose
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-07-11 06:00
---
(In reply to comment #12)
> (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()?
Right, you just admitted this is information is only useful when the problem is
obvious which 95% of the time it is not. So you get only a very small part of
the story from the information which you are requesting to be outputed, in fact
the developer still has to debug the program and to see why it is wrong. It
might be a misleading to the developer to get where the problem shows up rather
than where the problem really is caused from. Different developers have
different style of debugging so why push one style debuging on them?
Again the end user does not care why it crashes, they only care if it is fixed.
Think of the issue this way, when you ride on an elevator, and it stops
working, you don't care why, you just care it gets fixed. This is how software
should be dealt with but really developer's are not held up to that standard
for some reason except in the case where it is life and death can occur (well
technically it can occur any time with real programs because they could cause
someone to have a cesure).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- Comment #14 from nigelenki at comcast dot net 2006-07-11 06:25 --- (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > (In reply to comment #8) > > > > > ... > > > > 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()? > > Right, you just admitted this is information is only useful when the problem > is > obvious which 95% of the time it is not. Uh, ACTUALLY I just pointed out the scenario where the developer has no idea what the end user did; the end user knows he has a problem but that's it; and the developer would have to check the ENTIRE code base blindly if the end user couldn't just tell him "Oh it said it blew up a buffer in f(), whatever that means." In other words I just showed that I saved the developer thousands of man-hours of work. > in fact > the developer still has to debug the program and to see why it is wrong. Yes but now he has a limited number of code paths to go wrong on. > It > might be a misleading to the developer to get where the problem shows up > rather > than where the problem really is caused from. Um, there are only so many code paths that lead you to f(). There's a LOT of code you can cut out of your program now... > Different developers have > different style of debugging so why push one style debuging on them? We're just volunteering more information, not forcing them to use it. Kind of like keeping soda in the fridge. Maybe you don't drink soda, but it's better than keeping nothing so everyone has to drive out to the store when they're thirsty. > > Again the end user does not care why it crashes, they only care if it is > fixed. Right. It crashed, here's the file you asked me to e-mail, fix the damn thing. > Think of the issue this way, when you ride on an elevator, and it stops > working, you don't care why, you just care it gets fixed. And you pick up the "Emergency Phone," and the operator says, "open the panel, there's a number displayed, what does it say?" and you blindly say "37" and they go to an exact panel in an exact room and work backwards from there instead of combing the entire elevator system. > This is how software > should be dealt with but really developer's are not held up to that standard > for some reason except in the case where it is life and death can occur (well > technically it can occur any time with real programs because they could cause > someone to have a cesure). > So, you are saying that software should be dealt with by an end user saying, "I don't know why it broke, fix it;" rather than saying, "I don't know why it broke, it asked me to e-mail you this file. Here, now fix it"? (literal, this is the ENTIRE conversation, you get NO MORE information from the end user on the problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-07-11 06:45 --- (In reply to comment #14) > > > > > > 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()? > > > > Right, you just admitted this is information is only useful when the > > problem is > > obvious which 95% of the time it is not. > > Uh, ACTUALLY I just pointed out the scenario where the developer has no idea > what the end user did; the end user knows he has a problem but that's it; and > the developer would have to check the ENTIRE code base blindly if the end user > couldn't just tell him "Oh it said it blew up a buffer in f(), whatever that > means." > > In other words I just showed that I saved the developer thousands of man-hours > of work. Not really, since they still have to figure out if it was already fixed in a different version or not. If the bug report was good on how to reproduce it, like I have $10,000 when I enter level 10 and it crashes. The developer knows how to set the paramters to get to right before that point and then try to reproduce it. Random failures are the hardest to reproduce and sometimes it is actually not the developer's fault like the hardware is failing (like the computer is overheating which yes I have been able to happen to me already but since I know the symtom of hardware overheating I know the fix too). > Yes but now he has a limited number of code paths to go wrong on. That is not true. he just knows the last function and nothing more, this is where a debugger comes in handy to get the full backtrace. You seem to think getting where the crash is, is a magic bullet at fixing an issue which it is not. It sometimes (less than 5%) can be a magic bullet but then using a debug is part of the development cycle. > Um, there are only so many code paths that lead you to f(). There's a LOT of > code you can cut out of your program now... What from 100 million down to 90 million, yes you cut the problem down by 1% but there still can be a huge amount to go. > And you pick up the "Emergency Phone," and the operator says, "open the panel, > there's a number displayed, what does it say?" and you blindly say "37" and > they go to an exact panel in an exact room and work backwards from there > instead of combing the entire elevator system. but that is how you reproduce the bug > So, you are saying that software should be dealt with by an end user saying, > "I don't know why it broke, fix it;" rather than saying, "I don't know why it > broke, it asked me to e-mail you this file. Here, now fix it"? (literal, > this is the ENTIRE conversation, you get NO MORE information from the > end user on the problem). No you get almost no more information about the problem if you get a bug report with just where it crashes, even GCC gets those because people don't read instructions. That information is only useful once you can reproduce the issue and by then you should have fired up the debugger to be able to debug it. Also this is why software has instructions on how to file a bug report. If the software program does not, then it is really not something you should be able to trust to run and you should be not running it, unless you are willing to be able to suffer through the bugs. Yes I suffer through the bugs for an IRC client I run because I am too lazy to report the bug and it only is reproduciable everyonce in a while and I don't care about that much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
