--- Comment #2 from ian at airs dot com 2006-08-18 06:32 ---
Unfortunately I do not currently have a valid copyright assignment with the
FSF. I think my one word change is fine, but I don't feel comfortable moving a
function around (although I agree that is the right approach).
--
--- Comment #2 from beethoven3322 at hotmail dot com 2006-08-18 06:31
---
On a related note, is macro prescanning of arguments part of the ANSI standard?
In "Harbison and Steele" they seem to imply argument prescanning in macros is
not ANSI-compliant...
--
http://gcc.gnu.org/bugzil
--- Comment #9 from patchapp at dberlin dot org 2006-08-18 05:30 ---
Subject: Bug number PR28735
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00635.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from lee dot adamson at macquarie dot com 2006-08-18 05:27
---
Same thing also happens if I build a sparc-sun-solaris2.8 to i686-pc-linux-gnu
cross compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28689
--- Comment #17 from patchapp at dberlin dot org 2006-08-18 05:15 ---
Subject: Bug number PR18111
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00634.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 05:11 ---
Confirmed, a regression from 3.3.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following C program will not compile with the command "gcc file.c":
#define FIRST "This is a split
int main() {
printf( FIRST string");
}
It gives the expected error message about the malformed preprocessor token.
However if the output of "cpp file.c" or "gcc -E file.c" is saved and fed ba
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-18 04:52 ---
(In reply to comment #3)
> Also, removing the space between '-x' and 'c++' works, eg,
You are correct, weird.
Actually:
g++ -c -x c++ t.h
fails too:
--output-pch=t.h.gch
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-08-18
04:48 ---
Also, removing the space between '-x' and 'c++' works, eg,
g++ -fsyntax-only -xc++ stdio.h
but I get warning
warning: #pragma system_header ignored outside include file
ditto with
g++ -c -x c++ std
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:46 ---
Actually I don't think this is fallout of that patch but really of the
anonymous namespace changes which added decl_anon_ns_mem_p.
Confirmed.
Most likely introduced by:
2006-06-29 Jason Merrill <[EMAIL PROTECTED]
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:43 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:43 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28683
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:24 ---
This a build regression. This is eh related.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-18 04:34 ---
(In reply to comment #4)
> I applied this patch against the gcc 4.1.1, but the bug is still there (at
> least procps keeps segfaulting).
4.1.1 did not have the force_align_arg_pointer attribute so what do you expect
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-18 04:29 ---
The type of the CONSTRUCTOR is NULL which is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28255
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-08-18 04:20
---
(In reply to comment #14)
Any news on the patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-08-18 04:18
---
This works for me with a cross (and sysroot) to powerpc-linux-gnu from a
i686-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:15 ---
Confirmed, I am adding the keyword wrong-debug which almost true.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:13 ---
Confirmed, we add the new attribute but we cannot convert between the types for
some reason. I bet there is a way to reproduce this without using new too but
I cannot find it.
--
pinskia at gcc dot gnu dot org c
For this code:
class A {
int f(void);
};
int (A::*ptr) (void);
GCC will output debug information claiming that the type of PTR is:
struct {
void (*__pfn) (args, ...);
ptrdiff_t __delta;
};
At least for dwarf2, GCC should output DW_TAG_ptr_to_member, just like it does
for data members.
The
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 04:06 ---
Confirmed, it did not work in 3.4.0 which almost means this was caused by the
PCH changes.
Janis could you do a regression hunt on this one. The best way I guess to do
this is to put "int main(void){}" in a .h file.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-18 04:02 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 03:54 ---
Here is a patch (though I have looked to see if it works with templates yet):
Index: init.c
===
--- init.c (revision 116236)
+++ init.c (worki
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-18 03:42 ---
for +=/-= we could use PREINCREMENT_EXPR/PREDECREMENT_EXPR trees but for *=,
/=, |=, ^=, we cannot use any of the above.
I wonder if a SAVE_EXPR make this work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 03:30 ---
This is not a regression as far as I can tell.
Note I found this while working on PR 28418.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
The following should be able to compile but does not:
struct A { int i; };
template
void foo()
{
((struct A) { 0 }).i += 1;
}
void g(void)
{
foo<0>();
}
If we remove the template on foo, the statement with compund literal expression
is accepted.
--
Summary: compound
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-18 03:20 ---
Wait a minute the C front-end produces for this testcase:
<<< Unknown tree: compound_literal_expr
struct A D.1524 = {.i=0}; >>>
.i = <<< Unknown tree: compound_literal_expr
struct A D.1524 = {.i=0}; >>>
.i
--- Comment #4 from ngiff at yahoo dot com 2006-08-18 02:52 ---
i guess i'm supposed to verify/close this...
--
ngiff at yahoo dot com changed:
What|Removed |Added
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-08-18 02:41 ---
Should be fixed now
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |schwab at suse dot de
|dot org
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-18 02:28 ---
Actually no I am not going to fix this. Because it means I have to do a
partical rewrite on how c_parser_external_declaration is done for objc and I am
not going to do it.
--
pinskia at gcc dot gnu dot org chang
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-18 02:23 ---
Actually I am going to implement the fix better, we really should be even
calling c_parser_objc_method_decl at the toplevel of parsing. I think it was
implemented this way because the old bison based parser did tha
--- Comment #1 from pcarlini at suse dot de 2006-08-18 02:13 ---
Hi Ian. Please go ahead with the inlining: only, from a stylistical point of
view, please move the entire body inline, do not mark inline the out of line
code. Patch preapproved, thanks a lot!
--
pcarlini at suse dot de
Compile this code with -O2:
#include
void foo(__gnu_cxx::__vstring s)
{
s.clear();
}
Look at the resulting assembler code. Do not show it to small children. It is
too scary.
With this simple patch:
--- include/ext/sso_string_base.h (revision 116231)
+++ include/ext/sso_string_base.h
I'd like to add Joern to the list.
sh4-unknown-linux-gnu build fails during libjave build with:
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:
In class 'javax.swing.plaf.basic.BasicTextUI':
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.ja
--- Comment #7 from mcvick_e at iname dot com 2006-08-18 00:03 ---
(In reply to comment #4)
> -mstrict-align does not do what you think it does. What it does is say the
> alignment requirements for loads/stores cannot be violated.
That's fine for the -mstrict-align, however as I stated
--- Comment #15 from pluto at agmk dot net 2006-08-17 23:39 ---
(In reply to comment #13)
> (In reply to comment #12)
> > The patch is wrong, you need something like
> >
> > -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
> > +CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS) $(SYSRO
/ecj.jar
Using built-in specs.
Reading specs from /usr/lib/gcc/i486-linux-gnu/4.2.0/libgcj.spec
[...]
gcc version 4.2.0 20060817 (experimental) (Ubuntu 4.2-20060817-0ubuntu1)
gcj-4.2 -v \
-O2 -g -Wl,-Bsymbolic -fPIC -fjni -findirect-dispatch \
--main
--- Comment #6 from mcvick_e at iname dot com 2006-08-17 22:35 ---
The spec also has multiple examples of big versus little endian layouts and how
they map in memory and what their alignment is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-08-17 22:34 ---
The original simd-3.c still fails on mainline (my test compiler is configured
with --enable-e500_double but it still appears with -mfloat-gprs=single) though
the reduced test doesn't.
--
jsm28 at gcc dot gnu dot or
--- Comment #5 from mcvick_e at iname dot com 2006-08-17 22:28 ---
Additional information, if you insist on having an ABI then please go to this
link and look at pages 3-8 and 3-9. It states that bitfields have the same
alignment restrictions as their base types (int for int) (short fo
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-17 22:19 ---
-mstrict-align does not do what you think it does. What it does is say the
alignment requirements for loads/stores cannot be violated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
--- Comment #3 from mcvick_e at iname dot com 2006-08-17 22:17 ---
Are you telling me that if I put two of those structures side by side in memory
that GNU will mis-align them even though I pass the flag -mstrict-align? That
couldn't possibly be since the align flag states to use stric
% gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.4/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions -
--- Comment #16 from mmitchel at gcc dot gnu dot org 2006-08-17 20:29
---
I think the patch in Comment #8 is OK, but that the right approach would be to
stop using %y to denote two different things. I think we should add
documentation saying that %y has dual meanings and check in this
--- Comment #4 from aeby at graeff dot com 2006-08-17 19:43 ---
A bug tracker is not the right place to discuss philosophy questions, so if
you'd like to continue the discussion, we should move over to e-mail or the gcj
mailing list (lookout for subject: "GCJ 4.1.1 and static linking - S
--- Comment #14 from bonzini at gnu dot org 2006-08-17 19:24 ---
Please post to GCC Patches -- I am not a maintainer so I can't approve it
anyway. Also, you need a ChangeLog entry, and the CXXFLAGS_FOR_TARGET needs
the same treatment.
--
bonzini at gnu dot org changed:
--- Comment #13 from pluto at agmk dot net 2006-08-17 19:22 ---
(In reply to comment #12)
> The patch is wrong, you need something like
>
> -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
> +CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
>
> and simil
--- Comment #2 from pluto at agmk dot net 2006-08-17 19:18 ---
the `Y y2 = 2` requires two impicit user-defined conversions
(realized by conv-ctors) but standard allows at most one.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #8 from Vladislav dot Mikhailikov at paradox-neo dot uz
2006-08-17 18:51 ---
It seems that gcc-4.2 has the same problem. At least all .pch tests fail with
that option set
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28734
--- Comment #10 from pcarlini at suse dot de 2006-08-17 18:40 ---
Don't worry, the problem will be *certainly* resolved in time for the release:
the issue is clear, we know in detail what's going wrong and how to fix it.
Benjamin will.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #1 from hjl at lucon dot org 2006-08-17 18:16 ---
Wrong target is used for cross compiler build.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 18:04 ---
Can you quote the ABI document that says they have the same alignment?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-17 18:01 ---
Actually I don't think they have the same alignment requirement.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I have compiled a sample application that demonstrates my problem (see below
for the sample code).
Basically when I have two structures, one that contains a bitfield and one that
does not, the sizeof macro acts differently between the two structures.
These structures are identical as far as conten
The following program:
program write
implicit none
integer :: debuglevel = 1
if (0 < debuglevel) write (0, "('test == ', f0.3)") 0.75
end program write
produces the following error at compile time:
> gfortran foo.f90
In file foo.f90:5
if (0 < debuglevel) write (0, "('test == ', f0.3)"
--- Comment #3 from daney at gcc dot gnu dot org 2006-08-17 16:18 ---
(In reply to comment #2)
> Why are you trying to static link java code? It will almost not work for
> other
> cases.
>
We have 7.5X10^6 lines of code in about 800 classes that run fine statically
linked. So it doe
--- Comment #11 from hjl at lucon dot org 2006-08-17 15:53 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00521.html
works for me on ia64:
http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg00722.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-17 15:33 ---
I will let Daniel Berlin comment on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-17 15:32 ---
Can you show the output of the orginal configure?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 15:28 ---
These are not strange at all, this is normal, just your prefix == triplet.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 15:12 ---
Why are you trying to static link java code? It will almost not work for other
cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-17 15:08 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #8 from pault at gcc dot gnu dot org 2006-08-17 15:03 ---
Sorry, meant to accept this on the last reply.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20256
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-17 15:01
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-17 14:58
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #7 from pault at gcc dot gnu dot org 2006-08-17 14:57 ---
(In reply to comment #6)
OK I understand it now. The PRIVATE declaration prevents references to 'a' and
'b' from being resolved, when USEing dummybdy_comm, because it suppresses the
symtree. This is demonstrated by m
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-17 14:48 ---
This is not a bug as mentioned by comment #6.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from bero at arklinux dot org 2006-08-17 14:45 ---
gcj -C miscompiles just org/eclipse/jdt/internal/compiler/lookup/Scope.java and
org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java -- I can
generate a perfectly working ecj using gcj -C for all files, then r
--- Comment #17 from bjoern dot m dot haase at web dot de 2006-08-17 14:36
---
I have made a superficial analysis of the issue and would like to discuss at
the end of this post a possible approach for resolving PR4131.
The first observation is, that when one is having a code segment li
--- Comment #3 from bonzini at gnu dot org 2006-08-17 14:28 ---
It probably will not happen before 4.3 and, even if it happened for 4.2, it
will never be backported to 4.1 since this one is in regression fixes-only
mode.
You could help by looking at the source code (there are only a few
--- Comment #2 from whaley at cs dot utsa dot edu 2006-08-17 14:17 ---
Richard,
Thanks for confirmation. There's no chance of this happening soon, I guess?
I'm working on a release of ATLAS (fast linear algebra), and I can't enable gcc
vectorization until its necessary flags are separ
--- Comment #6 from pluto at agmk dot net 2006-08-17 14:11 ---
(In reply to comment #5)
> I meant the copy ctor, not the dtor.
> Anyhow, looking at it again, it makes some sense.
"When certain criteria are met, an implementation is allowed to omit the copy
construction of a class objec
--- Comment #5 from ist_alex at yahoo dot com 2006-08-17 14:00 ---
I meant the copy ctor, not the dtor.
Anyhow, looking at it again, it makes some sense.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
--- Comment #4 from ist_alex at yahoo dot com 2006-08-17 13:57 ---
Never thought the C++ standard allows ignoring the code written in a dtor. What
if the dtor does something important (like in the example - it doesn't just
copy the contents)?
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-08-17 13:23 ---
(In reply to comment #0)
Note, this bug had caused a bootstrap failure, discussed here:
http://gcc.gnu.org/ml/gcc/2006-07/msg00108.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28289
--- Comment #13 from spop at gcc dot gnu dot org 2006-08-17 13:14 ---
Subject: Bug 20256
Author: spop
Date: Thu Aug 17 13:14:26 2006
New Revision: 116223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116223
Log:
PR middle-end/25211
PR middle-end/20256
PR
--- Comment #9 from spop at gcc dot gnu dot org 2006-08-17 13:14 ---
Subject: Bug 26435
Author: spop
Date: Thu Aug 17 13:14:26 2006
New Revision: 116223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116223
Log:
PR middle-end/25211
PR middle-end/20256
PR
--- Comment #9 from spop at gcc dot gnu dot org 2006-08-17 13:14 ---
Subject: Bug 25211
Author: spop
Date: Thu Aug 17 13:14:26 2006
New Revision: 116223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116223
Log:
PR middle-end/25211
PR middle-end/20256
PR
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-17 13:06
---
The fix of PR 28385 changed the behavior on mainline so that the bug
is now fixed on mainline (w.r.t. current version of the standard).
I.e. only the 4.0 branch and the 4.1 branch (and everyting before 3.4.1)
is a
--- Comment #9 from brett dot albertson at stratech dot com 2006-08-17
13:02 ---
(In reply to comment #7)
> Subject: Bug 27697
This fails on i386-pc-solaris2.10 on trunk with:
Executing on host: /u01/var/tmp/gcc_trunk_svn/gcc_20060817/gcc/xgcc
-B/u01/var/tmp/gcc_trunk_svn/gcc_20060817
--- Comment #3 from jakub at gcc dot gnu dot org 2006-08-17 12:38 ---
The is just the libstdc++ ABI check not being able to understand
tanl@@GLIBCXX_3.4 -> [EMAIL PROTECTED] etc. changes (22 such symbols).
Those are not ABI breakers, all that means is that newly linked programs
won't res
--- Comment #9 from jakub at gcc dot gnu dot org 2006-08-17 12:20 ---
The problem mentioned in #7 is not specific to variables, foo.c:
extern int foo (void);
__attribute__((externally_visible)) void *bar(void)
{
return foo;
}
bar.c:
__attribute__((externally_visible)) int foo (void)
{
--- Comment #3 from pluto at agmk dot net 2006-08-17 12:18 ---
this is not a bug. the c++ standard allows RVO optimization.
see $12.8/15 for more details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
--- Comment #2 from ist_alex at yahoo dot com 2006-08-17 11:54 ---
Created an attachment (id=12089)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12089&action=view)
The preprocessed source (*.ii) file
Bug related file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
--- Comment #1 from ist_alex at yahoo dot com 2006-08-17 11:52 ---
Created an attachment (id=12088)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12088&action=view)
The original source code
Bug related file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
--- Comment #8 from jakub at gcc dot gnu dot org 2006-08-17 11:52 ---
Subject: Bug 28744
Author: jakub
Date: Thu Aug 17 11:52:26 2006
New Revision: 116222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116222
Log:
PR c/28744
* cgraph.h (struct cgraph_node): Remov
Sytem information:
- LFS-based Linux, with kernel 2.6.15 (with some genpatches)
GCC configuring
---
./gcc-3.4.3/configure --prefix=/usr \
--libexecdir=/usr/lib --enable-shared \
--enable-threads=posix --enable-__cxa_atexit \
--enable-clocale=gnu --enable-languag
--- Comment #1 from aeby at graeff dot com 2006-08-17 11:50 ---
Created an attachment (id=12087)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12087&action=view)
Ugly workaround GC_PTHREAD_CREATE_NAME segfault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
Compiled java programs that are linked statically with gcj segfault on startup
(starting with GCC 4.1.x):
# gcj -g -static --main=test -Wl,--whole-archive -lnss_files_p -lnss_dns_p
-lresolv -lpthread -ldl -Wl,--no-whole-archive test.java
# ./a.out
Segmentation fault
with test.java being i.e
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-08-17 09:44 ---
Subject: Bug 27865
Author: hubicka
Date: Thu Aug 17 09:44:12 2006
New Revision: 116220
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116220
Log:
PR tree-optimization/27865
* reload1.c (forge
--- Comment #9 from tim at klingt dot org 2006-08-17 09:43 ---
i have the same problem on my machine, using the latest snapshot.
i'm not sure, if the following information is helpful, but gcc -v gives me:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-17 09:20
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-17 09:19
---
Subject: Bug 28606
Author: reichelt
Date: Thu Aug 17 09:19:27 2006
New Revision: 116219
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116219
Log:
PR c++/28606
* parser.c (cp_parser_diagnos
--- Comment #7 from dwmw2 at infradead dot org 2006-08-17 09:16 ---
The one with proc_mkdir was because the EXPORT_SYMBOL is in a different file to
the original function -- although my version was working correctly, I'm willing
to deal with that case.
The symbol 'proc_root' is also miss
1 - 100 of 119 matches
Mail list logo
