Dear Madam or Sir,
I want to start a code analysis project using the -fdump debugging
outputs. Therefore I would like to ask if these features / switches are
considered stable in future versions of gcc ( I could not find any
information in the provided docs). Alternatively I have to write a
Hi Ranjit,
Thanks a lot for your help.
May I ask why it has to be native in order to generate jv-convert, grmic, etc?
Also if I replace the section in libjava/Makefile.am with the following, will
that work?
- - 8 -
bin_PROGRAMS =
Yes, of course, but what if you've checked out using a read-only
protocol? Is it going to fall down? Refuse to commit entirely?
You can use svk mirror --relocate before and after svn push --lump.
Paolo
* Hendrik Post:
I want to start a code analysis project using the -fdump debugging
outputs. Therefore I would like to ask if these features / switches are
considered stable in future versions of gcc ( I could not find any
information in the provided docs). Alternatively I have to write a
- - 8 -
## For now, only on native systems. FIXME.
if NATIVE
bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool
endif
- - 8 -
So this is expected behaviour at the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
TJ Laurenzo wrote:
- - 8 -
## For now, only on native systems. FIXME.
if NATIVE
bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool
endif
- - 8
Are you talking of a cross-compiler (target != host) or
a crossed-native compiler (target==host!=build)? I think
Rui was complaining about these tools not being generated
in the cross-compiler case while you might have observed
these being created in the crossed-native compiler case.
I
Basic testing done on i686-linux (built with --languages=c,fortran and
a shared libgmp in /foo/bar, and regtested). Extended testing (which
takes ages on my computer) in progress.
OK for mainline? OK for 4.0?
*ping*
This patch has both a toplevel part and a part in gcc/, so I don't
know
Brian Dessent wrote:
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/i
nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H
-I. -I../.
This patch has both a toplevel part and a part in gcc/, so I don't
know exactly who can approve it.
I haven't really understood why you need this patch.
If you need to set the LD_LIBRARY_PATH manually after installation,
something is broken. If the GMPLIBSDIR is for example something in your
Rui == Rui Wang [EMAIL PROTECTED] writes:
Rui May I ask why it has to be native in order to generate
Rui jv-convert, grmic, etc?
I think I wrote that code, but I don't remember the reason for this.
Rui Also if I replace the section in libjava/Makefile.am with the
Rui following, will that work?
Plain compiler bug. I'm not aware of any existing report to that
effect,
IMHO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9726
is the same bug
Joerg
hi,
Since the cvs version of gas supports extensions for the dwarf2
basic_block location information, I thought I could try to add support
to gcc for this feature. My use of this feature is related to binary
code analysis: being able to gather the bb boundaries through gcc's
debugging output
Rui May I ask why it has to be native in order to generate
jv-convert,
Rui grmic, etc?
I think I wrote that code, but I don't remember the reason for this.
Is it because grmic/grmiregistry is not working well on windows yet?
I have used Thisiscool gcc 4.0.2 to test a sun's RMI example, I
Rui == Rui Wang [EMAIL PROTECTED] writes:
Tom I think I wrote that code, but I don't remember the reason for this.
Rui Is it because grmic/grmiregistry is not working well on windows yet?
No, it is more like some weird configure/build thing having to do
with cross-builds.
Rui I have used
On Tue, 2005-11-08 at 21:10 -0500, Kaveh R. Ghazi wrote:
I've put a possible patch in the metabug (24639). As I mention in
the comments, I'm not comfortable self-approving it given my lack of
knowledge about the option processing code and the debate over what
we want the default
Gaby,
Are you referring to issues with operator new visibility, and RTTI/exception
handling? I'm not throwing objects across DSO boundaries, so this should be
less of an issue.
Gary
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 06 November 2005 12:25
To:
Gary M Mann [EMAIL PROTECTED] writes:
| Gaby,
|
| Are you referring to issues with operator new visibility, and RTTI/exception
| handling?
type infos and associates, yes.
-- Gaby
Why does treelang defines signedness of char with flag_signed_char?
IMHO it would be better if it had a fixed definition of it. I have
tried to use
build_common_tree_nodes (true, false);
It bootstraped and tested (make check-treelang).
Thanks,
Rafael
2005-10-25 Rafael Ávila de Espíndola
Hi,
I have a question concerning the lowering of return statements during
the gimple pass. Shouldnt the TREE_BLOCK () of the representative
return expr (which is moved to the end of the function) be updated to
reflect its new scope ?.
Or on the other hand is TREE_BLOCK () intended to be an
I sent this message a few days ago, but I could not find it in the
archives. I think it may have been stripped out, because I sent it as
HTML the first time. I'm trying it now as plain text.
I apologize if this is the second time you see this post.
I am in the process of learning the C
Redefined Horizons [EMAIL PROTECTED] writes:
I am in the process of learning the C Programming Language and
Assembly Language. I am looking for the opportunity to contribute to
an open source project while gaining some experience with assembly
language programming. Is there any projects being
On Mon, 7 Nov 2005, Steven Bosscher wrote:
2) when we see :0 align to the next unit, which seems to be the
behavior of GCC pre-3.4.
If by unit you mean size of type for the :0 field for
targets with PCC_BITFIELD_TYPE_MATTERS==1, and byte for
non-PCC_BITFIELD_TYPE_MATTERS targets, fine with
--- Comment #7 from bonzini at gcc dot gnu dot org 2005-11-09 08:20 ---
Reduced testcase
/* { dg-do run } */
/* { dg-options -O -fdump-tree-dom3 } */
int Link[] = { -1 };
int W[] = { 2 };
extern void abort (void);
int f (int k, int p)
{
int pdest, j, D1361;
j = 0;
pdest = 0;
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gcc dot gnu dot
|
--- Comment #8 from bonzini at gcc dot gnu dot org 2005-11-09 08:22 ---
dom3 is at fault
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
internal compiler error
subroutine nhatgrid()
implicit none
integer :: lambda
real(kind=8) :: arg,sigma
real(kind=8) :: dshpfunc
dshpfunc(arg)=-lambda/sigma*(arg/sigma)**(lambda-1)*exp(-(arg/sigma)**lambda)
end subroutine nhatgrid
--
Summary: internal compiler error with
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-09 10:08
---
(In reply to comment #5)
Don't worry, I do. :-) It comes from the linker, trigged by the
source code for fedisableexcept, using machinery that's set up
by to warn for functions that shouldn't be used, like in
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-09 10:12
---
(In reply to comment #3)
I believe I have a fix for this one that works with the previous patch to
pr24489. I am testing along with work on pr24699 to make sure we have no
conflicts or regressions. pr24719,
--- Comment #7 from hp at bitrange dot com 2005-11-09 10:24 ---
Subject: Re: [4.1 regression] testsuite
failure:gfortran.fortran-torture/execute/in-pack.f90 exe
On Wed, 9 Nov 2005, fxcoudert at gcc dot gnu dot org wrote:
--- Comment #6 from fxcoudert at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-09 11:07 ---
First, a hardware failure is possible - usually just re-trying may fix the
problem or make it show up somehow different / somewhere else, if this is the
case. Second, your gcc 3.4.2 is outdated, please update to a
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-11-09 11:28
---
Subject: Bug 22607
Author: eedelman
Date: Wed Nov 9 11:27:56 2005
New Revision: 106683
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106683
Log:
fortran/
2005-11-09 Erik Edelmann [EMAIL PROTECTED]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||law at gcc dot gnu dot org
Severity|normal
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24755
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 11:44 ---
Confirmed, backtrace:
#0 0x080727d3 in recursive_stmt_fcn (e=0x9fec3b8, sym=0x9fec218) at
/home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/match.c:2727
#1 0x080727b5 in recursive_stmt_fcn (e=0x9fec540,
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-09 12:01 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00389.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-09 12:01 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00388.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-09 12:02 ---
Note your testcase will fail on every target except for s390:
/* { dg-do compile } */
/* { dg-options -O1 -mpacked-stack } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-11-09 12:08
---
*** Bug 21957 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-11-09 12:08
---
*** This bug has been marked as a duplicate of 22127 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from krebbel at gcc dot gnu dot org 2005-11-09 12:18 ---
Ups sorry. I've fixed that now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |krebbel at gcc dot gnu dot
|dot org
--- Comment #2 from krebbel at gcc dot gnu dot org 2005-11-09 12:24 ---
Patch committed:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00387.html
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-11-09 12:34
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-11-09 12:34
---
Fixed.
--- Comment #25 from pinskia at gcc dot gnu dot org 2005-11-09 12:34
---
Subject: Bug 24644
Author: pinskia
Date: Wed Nov 9 12:33:59 2005
New Revision: 106693
URL:
--- Comment #9 from rguenth at gcc dot gnu dot org 2005-11-09 13:14 ---
It's IVCANONs fault, pr24716.c.t76.ivcanon:
...
# pdest_23 = PHI 0(1);
L24:;
return pdest_23;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #2 from pault at gcc dot gnu dot org 2005-11-09 13:17 ---
Since recursive_stmt_fcn is involved, this looks like my doing!
I'll take a look tomorrow morning.
Paul T
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-11-09 13:31
---
Or more definitely, store copyprop.
# BLOCK 1 freq:122
# PRED: 0 [100.0%] (fallthru,exec) 31 [100.0%] (fallthru,exec)
# jD.1285_18 = PHI 0(0), 1(31);
# pD.1281_7 = PHI pD.1281_25(0), pD.1281_48(31);
--- Comment #11 from rguenth at gcc dot gnu dot org 2005-11-09 13:59
---
Doh, I have a fix. What a stupid error in analyze_evolution_in_loop.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-11-09 14:01
---
Created an attachment (id=10185)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10185action=view)
patch
this is what I'm going to test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #9 from matz at suse dot de 2005-11-09 14:49 ---
A shorter testcase (which at least breaks on SuSEs 3.3-hammer compiler) is:
---
typedef union value {
long double d;
} Value;
double ld2d(Value v) {
return v.d;
}
By using a signed divide for pointer arithmetic an incorerct value can be
obtained given sufficient distance between two pointers.
I have tested this on gcc 3.4 (RedHat EL4 update 1) and the same behaviour
persists.
# gcc -v -save-temps -Wall -o test ./test.c
Reading specs from
--- Comment #1 from j3p0uk at hotmail dot com 2005-11-09 14:51 ---
Created an attachment (id=10186)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10186action=view)
Test source (.i)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-09 15:07
---
(In reply to comment #10)
Or more definitely, store copyprop.
s/store/scev/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #18 from dir at lanl dot gov 2005-11-09 15:13 ---
That was it - my system had two versions of strip.
Thanks,
Dale
The final library build has some warning messages, but they do not seem to hurt
anything -
ranlib -c .libs/libgfortranbegin.a
creating libgfortranbegin.la
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-09 15:17
---
(In reply to comment #18)
That was it - my system had two versions of strip.
Where was the second one comming from?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #16 from thebohemian at gmx dot net 2005-11-09 15:18 ---
Created an attachment (id=10187)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10187action=view)
preliminary patch - just for review
This is another preview of the patch. The patch begins to more and more depend
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-09 15:19 ---
Why do you think this is a bug. The difference between a[3]-a[4] better be
-1. (where a is an array).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from thebohemian at gmx dot net 2005-11-09 15:22 ---
Created an attachment (id=10188)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10188action=view)
lazy linker test setup
This is a small update to the test setup. BC-compilation is now done with
debugging symbols
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-09 15:23
---
Hmm, do we have an ABI change in 4.1:
We get in 4.1.0:
ld2d:
.prologue
.body
fnorm.d f8 = f8
br.ret.sptk.many b0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
--- Comment #6 from uros at kss-loka dot si 2005-11-09 15:27 ---
The problem is caused by the combination of (1) x86_64 parameter passing
convention, (2) x86 instructions that _require_ parameters in specific
registers and (3) sched1 scheduling pass.
ad 1)
x86_64 passes function
--- Comment #18 from aph at gcc dot gnu dot org 2005-11-09 15:28 ---
It's probably not the best idea to solve everything in this bug in a single
patch.
Better make several patches, for the different issues.
Also, if there are some verifier changes needed, let's get those committed
--- Comment #20 from dir at lanl dot gov 2005-11-09 15:29 ---
It was in /usr/local/bin along with a 100 or so other programs - I suppose that
one of them installed it .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #21 from pinskia at gcc dot gnu dot org 2005-11-09 15:30
---
Closing as works for me then.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from matz at suse dot de 2005-11-09 15:32 ---
You mean ABI change, because the input register seems to be f8, instead of
in0 (as would be need for this union)? I'm not sure, but it looks fishy
at least.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-09 15:53 ---
Note that obtaining the difference of pointers that don't point to the same
object is invoking undefined behavior, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-09 15:57
---
(In reply to comment #11)
You mean ABI change, because the input register seems to be f8, instead of
in0 (as would be need for this union)? I'm not sure, but it looks fishy
at least.
Actually it is not an ABI
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 16:26 ---
This works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-09 16:29
---
(In reply to comment #11)
This is reproducable on gcc mainline on amd64:
This works for me with GNU assembler 2.16.91 20051027 with the GCC mainline
on i686-linux-gnu
And with GNU assembler 2.16 with the GCC
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-09 16:31 ---
Works just fine here. What glibc are you using?
pr24428.c and pr24428-2.c are the only dg-do run tls tests, so perhaps
your libc doesn't support TLS at all?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
Since end of May, quite a few libstdc++-v3 testcases, stressing atomicity.h
are failing on multi-processor ia64 machines. See, for instance, in:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00411.html
FAIL: 22_locale/locale/cons/12658_thread-1.cc execution test
FAIL:
--- Comment #27 from jason at gcc dot gnu dot org 2005-11-09 16:58 ---
Subject: Bug 21123
Author: jason
Date: Wed Nov 9 16:58:52 2005
New Revision: 106698
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106698
Log:
PR c++/21123
* method.c (use_thunk): Use
Here's the test case:
---
typedef unsigned short ushort;
namespace X
{
typedef unsigned short ushort;
}
using namespace X;
int main()
{
ushort us = 0;
}
---
prompt g++ main.cpp
main.cpp: In function 'int main()':
main.cpp:12: error: 'ushort' was not declared in this scope
main.cpp:12:
--- Comment #1 from pcarlini at suse dot de 2005-11-09 17:00 ---
(In reply to comment #0)
Those tests *never* fail in 4_0-branch, which doesn't use the builtins, and
never did in mainline before the below of mine (and a simultaneous one to
the compiler, which emptied ia64intrin.h)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 17:03 ---
This is a dup of bug 23594.
*** This bug has been marked as a duplicate of 23594 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-09 17:03 ---
*** Bug 24758 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from pinskia at gcc dot gnu dot org 2005-11-09 17:04
---
Fixed in 4.0.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-09 17:12
---
Backport for the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 17:25 ---
Related to PR 9726.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from j3p0uk at hotmail dot com 2005-11-09 17:25 ---
The test case was a simple test case where I tried to show the mathematical
behaviour in as simple a way as possible.
The reason I thought that this may be a bug is because the behaviour on a
64-bit system is different
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 17:30 ---
This is invalid because otherwise you get the incorrect answer for a[3]-a[4]:
a = 0x8049668 b = 0x804966c
pointer ( a - b )
0x
non-pointer ( (
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-09 17:35 ---
Hmm you said in:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00149.html
That was really a glibc bug.
And actually 4.0 and before uses the builtins for ia64, this is where the
builtins came from in the first place.
The code
subroutine a (emask)
implicit none
real, intent(in) :: emask(:,:,:)
logical :: left(3), right(3)
integer :: i,j,k
i=1; j=1; k=1
left=.false.
right=.false.
if (.not.right(3)) left(1) = abs(emask(i,j,k+1)-1)0.01)
end subroutine a
contains an error in the if statement. The
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 17:39 ---
I notice that we give an unclassifiable error almost any time there is a syntax
error.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2005-11-09 17:45 ---
(In reply to comment #2)
Hmm you said in:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00149.html
That was really a glibc bug.
Exactly *was*. Ehi, do you think I'm stupid? Of course in the meanwhile
I have checked that
--- Comment #5 from daney at gcc dot gnu dot org 2005-11-09 17:46 ---
Created an attachment (id=10189)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10189action=view)
Program that demonstrates how shutdown can solve the problem.
Compile socktest.c thusly:
gcc -g -o soctest
--- Comment #1 from redi at gcc dot gnu dot org 2005-11-09 17:51 ---
We need to doc much more than that ... we don't have any docs saying which TR1
components are supported or how to make use of them, do we?
I had some changes on my hard drive adding docs to the docs/html/ext pages,
--- Comment #4 from pcarlini at suse dot de 2005-11-09 17:51 ---
(In reply to comment #3)
.Alternately, the ia64 builtins
themselves can be defective, but that seems much less likely to me, because
we are talking about a very consistent
--- Comment #2 from pcarlini at suse dot de 2005-11-09 17:52 ---
Your are welcome!
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #14 from rguenth at gcc dot gnu dot org 2005-11-09 18:01
---
Subject: Bug 24716
Author: rguenth
Date: Wed Nov 9 18:00:59 2005
New Revision: 106700
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106700
Log:
2005-11-09 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #15 from rguenth at gcc dot gnu dot org 2005-11-09 18:02
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joseph at codesourcery dot com 2005-11-09 18:09 ---
Subject: Re: gcc.dg/tls/pr24428.c execution test and
gcc.dg/tls/pr24428-2.c execution test fail on IA32
On Wed, 9 Nov 2005, jakub at gcc dot gnu dot org wrote:
Works just fine here. What glibc are you using?
--- Comment #2 from bero at arklinux dot org 2005-11-09 18:13 ---
It definitely wasn't added in binutils csl-arm-branch... Is gcc csl-arm-branch
supposed to be used with binutils head now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24695
--- Comment #6 from aph at gcc dot gnu dot org 2005-11-09 18:22 ---
Two things:
Does this work for fds that aren't associated with sockets?
It doesn't quite avoid the need for locking, since we still need to make sure
that we only close an fd once.
--
--- Comment #5 from pfl at iis dot fhg dot de 2005-11-09 18:35 ---
Ok, I switched to MacOSX.
There I have a /usr/gnu/build/gcc-4.0.2 diectory with the original sources.
Then I do a
../gcc-4.0.2/configure --cache-file=../mips-gcc-4.0.2.configure.cache
--prefix=/usr/gnu
--- Comment #5 from bkoz at gcc dot gnu dot org 2005-11-09 18:36 ---
Created an attachment (id=10190)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10190action=view)
tentative patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23591
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-09 18:40 ---
*** This bug has been marked as a duplicate of 24755 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-09 18:40 ---
*** Bug 24655 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24646
When compiling some files, the -da option or - AFAICT - any of its constituent
options changes the generated code. When using -da, the -quiet option can also
have an effect on the generated code, although this is harder to demonstrate.
--
Summary: -d option changes generated code
1 - 100 of 223 matches
Mail list logo
