I am working on an application over fedora using c language and
sockets (TCP). I have to send a structure which contains a pointer to
another strcuture. Now what happens is that when the primary structure
(containing the pointer) gets sent, instead of the secondary structure
(pointed to) being
On Sat, 22 Jul 2006, Andrew Haley wrote:
Roar Thronæs writes:
I have started working on moving the frontend from 3.4.3 to 4.1.1.
But it seems EXIT_BLOCK_EXPR and LABELED_BLOCK_EXPR have been moved
to java, since no one else was using it.
Would it be possible to move that code back,
On Sat, Jul 22, 2006 at 01:28:34AM -0700, Andrew Pinski wrote:
On Jul 22, 2006, at 1:05 AM, Roar Thronæs wrote:
But it seems EXIT_BLOCK_EXPR and LABELED_BLOCK_EXPR have been moved
to java, since no one else was using it.
Would it be possible to move that code back, please?
I don't
On 7/23/06, Abid Ghufran [EMAIL PROTECTED] wrote:
I am using send and receive for this purpose. How can i manage the
send(ing) and receive(ing) of the primary and the secondary structure?
This is the wrong place to ask. We discuss the development of gcc on this list.
Gr.
Steven
Andrew Pinski wrote:
On Jul 14, 2006, at 1:17 PM, Carlos O'Donell wrote:
We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be searching
both directories?
Yes because someone might have just relocated the compiler
Mark Mitchell [EMAIL PROTECTED] writes:
1. If we search both locations (i.e., for a relocated compiler, search
the configured-time prefix and the installation-time prefix), we get the
following set of problems:
...
2. If we search only location (i.e., for a relocated compiler, search
only
On Jul 23, 2006, at 10:44 AM, Ian Lance Taylor wrote:
However, I think it's clear that the problems in (1) are more severe
than the problems in (2), on several grounds:
Me too.
I actually think the problems with 1 (b) are artificial and should not
be taken into account. I actually depend
Andrew Pinski wrote:
I actually think the problems with 1 (b) are artificial and should not
be taken into account.
This is not a hypothetical or artificial issue -- as I said, all three
problems I listed have been encountered by real users.
I actually depend on a common sysroot already
and
Yes, that's clever. But, you can create a symbolic link to the
sysroot
from each installation with a single command. And, your installer for
third-party developers can do that for you.
What are the equivalent to symbolic links on Windows and I am not
talking about
cygwin either?
(1b) If the configure-time prefix does not exist, but is under an NFS
mount, the compiler will cause automount traffic, NFS timeouts, etc.
...
However, I think it's clear that the problems in (1) are more severe
than the problems in (2), on several grounds:
I actually think the problems
Andrew Pinski wrote:
Yes, that's clever. But, you can create a symbolic link to the sysroot
from each installation with a single command. And, your installer for
third-party developers can do that for you.
What are the equivalent to symbolic links on Windows and I am not
talking about
Before Vista, there's no solution short of cp. However, you still
have the --sysroot command-line option. And, if you're worried about
Windows, see Paul's response; the problems I've described are
particularly bad on Windows, and the developer-base there is often
less
used to GNU software,
Andrew Pinski wrote:
Before Vista, there's no solution short of cp. However, you still
have the --sysroot command-line option. And, if you're worried about
Windows, see Paul's response; the problems I've described are
particularly bad on Windows, and the developer-base there is often less
On Jul 23, 2006, at 10:44 AM, Ian Lance Taylor wrote:
Me too.
Except now you have suggested that we change the current behavior
which you already suggested at the GCC summit we should not do at
least not for a couple of release for warning people. You cannot
have it both ways, people
On Sun, Jul 23, 2006 at 11:40:38AM -0700, Andrew Pinski wrote:
Before Vista, there's no solution short of cp. However, you still
have the --sysroot command-line option. And, if you're worried about
Windows, see Paul's response; the problems I've described are
particularly bad on Windows, and
On Jul 23, 2006, at 11:48 AM, Mark Mitchell wrote:
Are you suggesting that we ship software that performs poorly on
one of
the most popular systems actually in the field because, in the
abstract,
those systems could be better?
Maybe we just have to force the issue on people. As I
Andrew Pinski wrote:
On Jul 23, 2006, at 11:48 AM, Mark Mitchell wrote:
Are you suggesting that we ship software that performs poorly on one of
the most popular systems actually in the field because, in the abstract,
those systems could be better?
Maybe we just have to force the issue
On Sunday 23 July 2006 19:40, Andrew Pinski wrote:
Before Vista, there's no solution short of cp. However, you still
have the --sysroot command-line option. And, if you're worried about
Windows, see Paul's response; the problems I've described are
particularly bad on Windows, and the
Mark Mitchell wrote:
Sent: Monday, July 24, 2006 4:59 AM
Andrew Pinski wrote:
On Jul 14, 2006, at 1:17 PM, Carlos O'Donell wrote:
We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be
searching both
Currently in config/i386/cygming.h we have this:
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n) (write_symbols == DWARF2_DEBUG \
? svr4_dbx_register_map[n] \
: dbx_register_map[n])
This is fine as long as we assume
Daniel Jacobowitz [EMAIL PROTECTED] writes:
[...]
| I think that in stage 1, we should switch to not searching any of the
| configured paths in favor of the relocated paths. Carlos has been
| working on patches for this. I'm sure it will break a few
| unexpected configurations. When it does,
Yes, that's clever. But, you can create a symbolic link to the
sysroot from each installation with a single command. And, your
installer for third-party developers can do that for you.
Beware - the linker expands symlinks to determine if a library comes
from the sysroot or not. It affects
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from patchapp at dberlin dot org 2006-07-23 09:35 ---
Subject: Bug number PR target/28270
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-07/msg00992.html
--
--- Comment #14 from patchapp at dberlin dot org 2006-07-23 10:15 ---
Subject: Bug number PR c++/27369
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-07/msg00993.html
--
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-23 11:51 ---
Consider these lines in elfos.h:ASM_OUTPUT_ASCII:
\
for (p = _ascii_bytes; p limit *p != '\0'; p++) \
--- Comment #2 from arno at heho dot snv dot jussieu dot fr 2006-07-23
13:05 ---
Created an attachment (id=11924)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11924action=view)
test if found dependency lib in fact has a name
I use this patch for months to prevent this bug.
It
--- Comment #7 from steven at gcc dot gnu dot org 2006-07-23 13:11 ---
Happens on at least all the targets that includes elfos.h, cris/aout.h,
i386/ptx4-i.h, i386/i386-interix.h, i386/sysv4.h, i386/i386elf.h.
I'm only fixing elfos.h, but others can copy over the same idea.
--
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-23 13:17
---
My XP box died last week (is that a curse?) It's being taken care of, but I
won't be able to work on it for some time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-23 14:54 ---
Created an attachment (id=11925)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11925action=view)
proposed fix, nukes quadratic behavior
needs detailed testing, but this cuts the time spent in debug info
Enabling some tree dumps causes a tramp3d-v4 compile to run into swap,
requiring
about 50% more ram than a non-dumped compile.
Pinskia suggests
Index: gcc/cgraph.c
===
--- gcc/cgraph.c(revision 115684)
+++ gcc/cgraph.c
--- Comment #1 from steven at gcc dot gnu dot org 2006-07-23 15:22 ---
Yup. And a regression too because previous GCCs could dump without sending your
machine to swap space land.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mark at codesourcery dot com 2006-07-23 15:59 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
drow at gcc dot gnu dot org wrote:
--- Comment #1 from drow at gcc dot gnu dot org 2006-07-23 00:12 ---
Mark, did the old C++ parser
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-07-23 16:17
---
I don't think it's a curse, but its spooky. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
--- Comment #3 from drow at gcc dot gnu dot org 2006-07-23 16:44 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
On Sun, Jul 23, 2006 at 03:59:58PM -, mark at codesourcery dot com wrote:
If we're setting TYPE_CONTEXT to global_namespace, I think that's a
--- Comment #4 from mark at codesourcery dot com 2006-07-23 16:48 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
drow at gcc dot gnu dot org wrote:
--- Comment #3 from drow at gcc dot gnu dot org 2006-07-23 16:44 ---
Subject: Re: [4.0/4.1/4.2
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-07-23 17:14 ---
I'll take a look at this.
See http://gcc.gnu.org/ml/fortran/2006-07/msg00311.html and
follow-ups for the discussion of this bug.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-07-23 17:23 ---
While I work on this, I might as well tackle some other issues.
Before I start work, some timings with a vanilla tree as of today.
The timing isn't terrible (within a factor of two with Intel 8.1),
but of course, I
--- Comment #5 from seongbae dot park at gmail dot com 2006-07-23 17:27
---
It seems that you didn't change libgcov.c,
which suggests that you didn't address __gcov_{pow2,interval}_profiler.
Without such change, -fprofile-generate will cause the mismatch between
the value counters and
--- Comment #10 from ian at airs dot com 2006-07-23 17:35 ---
I believe that patch is responsible because this behaviour does not happen in
gcc 4.0.1, and it does happen in gcc 4.0.2, and that was the obvious change. I
admit that I haven't actually tried reverting that specific patch
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-23 17:56 ---
Subject: Bug 25468
Author: steven
Date: Sun Jul 23 17:56:34 2006
New Revision: 115685
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115685
Log:
2006-07-23 Steven Bosscher [EMAIL PROTECTED]
PR
--- Comment #10 from steven at gcc dot gnu dot org 2006-07-23 17:57 ---
Fixed on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from gdr at integrable-solutions dot net 2006-07-23 18:03
---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| drow at gcc dot gnu dot org wrote:
| --- Comment #3 from drow at gcc dot gnu
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-23 18:05 ---
Jakub, ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25938
--- Comment #6 from drow at gcc dot gnu dot org 2006-07-23 18:48 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
On Sun, Jul 23, 2006 at 06:03:46PM -, gdr at integrable-solutions dot net
wrote:
I believe the situation has been that clear for DECLs for a
--- Comment #19 from dorit at il dot ibm dot com 2006-07-23 19:03 ---
The fix we've agreed is best in principle is to speculatively increase
the DECL_ALIGN of vectorisable variables before compiling functions.
Dorit says that there is a patch related to this on the autovect branch,
--- Comment #7 from drow at gcc dot gnu dot org 2006-07-23 19:55 ---
grokvardecl uses a NULL scope to indicate the current scope, and current_scope
never returns NULL. It used to, before revision 89627, but then grokvardecl
explicitly tried current_namespace.
This patch instituted the
--- Comment #4 from sayle at gcc dot gnu dot org 2006-07-23 20:14 ---
Subject: Bug 28247
Author: sayle
Date: Sun Jul 23 20:14:44 2006
New Revision: 115686
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115686
Log:
PR target/28247
* gthr-solaris.h: Prototype
--- Comment #8 from mark at codesourcery dot com 2006-07-23 20:17 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
drow at gcc dot gnu dot org wrote:
It did so by introducing FROB_CONTEXT. Right now, FROB_CONTEXT is used at a
number of places which set
--- Comment #3 from echristo at apple dot com 2006-07-23 20:28 ---
Patch submitted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-07-23 20:28
---
Subject: Bug 28025
Author: mmitchel
Date: Sun Jul 23 20:28:26 2006
New Revision: 115687
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115687
Log:
PR c++/28025
* cp-tree.h (LOOKUP_HIDDEN):
--- Comment #28 from echristo at apple dot com 2006-07-23 20:30 ---
We're not going to support building 4.0 in the source directory. Closing.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-07-23 20:32
---
Subject: Bug 28025
Author: mmitchel
Date: Sun Jul 23 20:32:28 2006
New Revision: 115688
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115688
Log:
PR c++/28025
* cp-tree.h (LOOKUP_HIDDEN):
--- Comment #4 from anlauf at gmx dot de 2006-07-23 21:06 ---
(In reply to comment #3)
Because less people test glibc staticly. Anyways this is a glibc bug which
has
since been fixed and it is the same problem as mentioned in PR 28351 so
closing
as a dup of that bug.
Negative.
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-07-23 21:14 ---
Created an attachment (id=11926)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11926action=view)
patch
This implements random for KIND=10 and KIND=16 REALs. It
is regression-tested on i686-pc-linux-gnu, but
#include stdio.h
template typename TYPE
struct Base {
Base() {
//this unqualified call works fine within the base class
voidFunc();
}
void voidFunc() {
printf(voidFunc()!\n);
}
//a public variable
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-07-23 22:02
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #4 from kargl at gcc dot gnu dot org 2006-07-23 23:32 ---
Thomas,
Don't you need a HAVE_GFC_REAL_16 section or is random_r10 used
for random_r16?
Also, I noticed that you've eliminated the normalize_* calls.
I think may actually be able to remove these functions and
the
--- Comment #9 from gdr at integrable-solutions dot net 2006-07-23 23:45
---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
drow at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
|
| On Sun,
--- Comment #10 from gdr at integrable-solutions dot net 2006-07-23 23:47
---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
mark at codesourcery dot com [EMAIL PROTECTED] writes:
[...]
| (IMO, the ideal representation would have global_namespace for
|
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-23 23:56 ---
No, it is still the same bug in glibc even though it is a different target and
32bit vs 64bit.
*** This bug has been marked as a duplicate of 28351 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-23 23:56 ---
*** Bug 28456 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28351
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-23 23:59 ---
The Error is correct.
See http://gcc.gnu.org/gcc-3.4/changes.html
.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from patchapp at dberlin dot org 2006-07-24 00:05 ---
Subject: Bug number PR28071
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-07/msg01011.html
--
--- Comment #11 from mark at codesourcery dot com 2006-07-24 00:05 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
gdr at integrable-solutions dot net wrote:
--- Comment #10 from gdr at integrable-solutions dot net 2006-07-23
23:47 ---
Subject:
--- Comment #12 from drow at gcc dot gnu dot org 2006-07-24 00:11 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
On Sun, Jul 23, 2006 at 11:47:32PM -, gdr at integrable-solutions dot net
wrote:
I agree that is the correct representation. Can we agree to
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-07-24 00:16 ---
Subject: Bug 25795
Author: hubicka
Date: Mon Jul 24 00:16:16 2006
New Revision: 115693
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115693
Log:
PR c/25795
PR c++/27369
* cgraph.c
--- Comment #15 from hubicka at gcc dot gnu dot org 2006-07-24 00:16
---
Subject: Bug 27369
Author: hubicka
Date: Mon Jul 24 00:16:16 2006
New Revision: 115693
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115693
Log:
PR c/25795
PR c++/27369
* cgraph.c
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-07-24 00:18
---
Subject: Bug 25289
Author: jvdelisle
Date: Mon Jul 24 00:17:52 2006
New Revision: 115698
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115698
Log:
2006-07-23 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-07-24 00:19
---
Subject: Bug 25289
Author: jvdelisle
Date: Mon Jul 24 00:19:45 2006
New Revision: 115700
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115700
Log:
2006-07-23 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-07-24 00:26
---
Subject: Bug 25289
Author: jvdelisle
Date: Mon Jul 24 00:26:08 2006
New Revision: 115702
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115702
Log:
2006-07-24 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #39 from roger at eyesopen dot com 2006-07-24 00:45 ---
My latest analysis and a possible patch/workaround have been posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01015.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
All statically linked OpenMP Fortran programs cause segment fault when executed
on i686-pc-linux-gnu platform.
--
Summary: [gomp] Statically linked OpenMP Fortran programs cause
segment fault
Product: gcc
Version: 4.2.0
Status:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-24 01:03 ---
This is a bug in glibc I think, can you get a backtrace? Also what version of
glibc are you using? Also static linking is on its way out for glibc in
general which is why I would not doubt this is a bug in glibc.
--- Comment #13 from gdr at integrable-solutions dot net 2006-07-24 01:34
---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
drow at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
|
| On Sun,
--- Comment #6 from gnb at sgi dot com 2006-07-24 02:23 ---
Ian Lance Taylor says:
Please send e-mail to [EMAIL PROTECTED] first. When that process is
complete, send the patch to [EMAIL PROTECTED]
Thanks, that was the guidance I needed ;-) The process is underway.
Seongbae Park
--- Comment #14 from drow at gcc dot gnu dot org 2006-07-24 02:58 ---
Subject: Bug 28460
Author: drow
Date: Mon Jul 24 02:58:08 2006
New Revision: 115703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115703
Log:
PR c++/28460
* decl.c (grokvardecl): Use
--- Comment #3 from drow at gcc dot gnu dot org 2006-07-24 03:00 ---
Subject: Bug 27473
Author: drow
Date: Mon Jul 24 02:59:36 2006
New Revision: 115704
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115704
Log:
PR debug/27473
* dbxout.c (output_used_types_helper,
--- Comment #4 from echristo at apple dot com 2006-07-24 03:20 ---
I doubt we're going to backport that patch to 4.1 at all, should we just close
this bug?
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #9 from echristo at apple dot com 2006-07-24 03:22 ---
No testcase after 3 mos. No need to keep this open.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-07-24 04:46
---
Invalid as mentioned by Eric because we don't have a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from echristo at apple dot com 2006-07-24 04:54 ---
The bug says c++, feel like opening another one or fixing the title on the bug
you opened?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
--- Comment #1 from echristo at apple dot com 2006-07-24 05:07 ---
This can't possibly be a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-24 05:20 ---
(In reply to comment #1)
This can't possibly be a regression.
Why? It is a user visible regression as now preprocessed sources include the
altivec attribute while before it used vector_size.
--
--- Comment #3 from steven at gcc dot gnu dot org 2006-07-24 05:29 ---
Yup. New feature lacking documentation. We've always treated those as
documentation quality regressions.
So confirmed.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-24 05:32 ---
(In reply to comment #2)
Removing regression.
It is a QOI regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from echristo at apple dot com 2006-07-24 05:45 ---
Is this a problem with mainline? It has 4.2 regression marked on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
/configure --enable-languages=c,c++,objc,fortran
Thread model: posix
gcc version 4.2.0 20060723 (experimental)
./cc1 -quiet -v -iprefix
/home/steven/devel/build-trunk-test/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/
-isystem ./include t.c -quiet -dumpbase t.c -mtune=generic -auxbase t -version
--- Comment #11 from echristo at apple dot com 2006-07-24 05:51 ---
Is libssp even assumed to be OK for non-native targets? I think that it should
probably be turned off by default on the embedded targets and just left that
way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-07-24 05:51 ---
(In reply to comment #8)
Is this a problem with mainline? It has 4.2 regression marked on it.
Why do you think otherwise, the commits were all to a developmental branch and
the patch is up on the patch queue so why
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-07-24 05:53
---
It works, just the problem is that library's configure is incorrect, there have
been threads about this issue which I cannot find right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-24 05:55 ---
I bet a beer or two it was caused by:
2006-05-16 H.J. Lu [EMAIL PROTECTED]
PR driver/26885
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
94 matches
Mail list logo
