Congratulations guys!
-eric
On Fri, Sep 26, 2014 at 1:01 PM, Jeff Law wrote:
>
> Sorry this has taken so long, the delays have been totally mine in not
> following-up to get votes, then tally them from the steering committee.
>
> I'm pleased to announce that Catherine Moore and Matthew Fortune h
On Tue, Jul 29, 2014 at 5:58 AM, Matthew Fortune
wrote:
> Jeff Law writes:
>> On 07/22/14 06:56, Richard Sandiford wrote:
>> > I'll need to step down as MIPS maintainer this weekend in order to
>> avoid
>> > a possible conflict of interest with a new job. SC: please could you
>> > appoint some n
> Could you recommend me what best options you think I should use for this
> processor.
>
> As I wrote, I am more interesting in aarch64 which can be used in a
> server (as you know RedHat works on a server market) but unfortunately I
> have no such machine for SPEC benchmarking.
>
I know Qualcomm
On Mon, May 26, 2014 at 1:14 AM, FX wrote:
>> > .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
>> > cast in a inline asm context requiring an l-value: remove the cast or
>> > build with -fheinous-gnu-extensions
>> > umul_ppmm (val[1], val[0], op1.ulow (), op2.
On Wed, Apr 21, 2010 at 3:44 PM, Paolo Bonzini wrote:
> On Thu, Apr 22, 2010 at 00:35, Andreas Schwab wrote:
>> Paolo Bonzini writes:
>>
>>> I'm not sure if "nm -g" would work under Linux, since
>>>
>>> $ nm -g /usr/lib64/libsqlite3.so
>>> nm: /usr/lib64/libsqlite3.so: no symbols
>>>
>>> $ objdu
On Mon, May 11, 2009 at 10:27 AM, Mark George
wrote:
> Please Send me info on GCC related to developing for the Apple iPhone new
> 3.0 OS. If I could get sample codes including simple code such as "Hello"
> world it would be great as I am relearning C/C++. Thank you for any support
> you can pro
>> Given that the svn://gcc.gnu.org/svn/gcc/branches/plugin branch is not
>> really active, I suggest to
>>
>> svn mv svn://gcc.gnu.org/svn/gcc/branches/plugin
>> svn://gcc.gnu.org/svn/gcc/branches/old-plugin
>>
>> What do you think about that?
>
> I have no opinion on this. Eric and Sean should
>> So my question is whether the saving in the size of the debug info with
>> -msym32 is really worth the trouble here or should we just start generating
>> 64-bit addresses with -msym32?
>
> Generating 64-bit addresses would be fine with me FWIW. I'm not sure
> the current behaviour is exactly de
On Jan 21, 2009, at 11:40 AM, Uros Bizjak wrote:
Hello!
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extra work here otherwise bits of gcc get very grumpy
when we ask for lower alignment. We could just reject values le
On Wed, Sep 24, 2008 at 11:22 AM, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote:
>> Right. However, the wording I saw was much broader than just the
>> plugin model. It was vague and poorly worded, and you could interpret
>> it as saying that
> Please open a bug report. They also fail on Linux with SSE fpmath:
>
>
That'd be why they fail on darwin then - we default to sse2 :)
-eric
On Thu, Aug 7, 2008 at 9:13 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Eric,
> Thanks for looking into this. FYI, the problem also occurs in...
>
> FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (test for excess
On Thu, Aug 7, 2008 at 8:47 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Is anyone else seeing some new internal compiler errors in the gcc
> testsuite on i686-apple-darwin9? I am using the same graphite patch
> I used a couple days back with the current svn of gcc trunk and now
> I see failures
Hi All,
On behalf of Sean I've made the initial commit to the gcc plugin
branch. This work directly applies to the paper that he'll be giving
at the summit this week. If people want to try out the code and or
just look and see what direction he's going. If you have any questions
or commen
and check SImode as well.
Tested on mips64vr-elf and x86-darwin.
OK?
-eric
2007-07-03 Eric Christopher <[EMAIL PROTECTED]>
* libgcc2.h: Conditionally include __bswapsi2 and
__bswapdi2.
Index: libgcc2.h
===
---
On Jun 20, 2007, at 9:40 PM, Pompapathi V Gadad wrote:
Hello Eric,
The target I am working on is 16-bit target and cannot support 64-
bit data types (DI mode).
How about conditionally declare the function?
#if LONG_LONG_TYPE_SIZE > 32
extern DItype __bswapdi2 (DItype);
#endif
You'll want t
On Jun 19, 2007, at 10:50 PM, Pompapathi V Gadad wrote:
Hello,
Current function declaration of __bswapdi2 in libgcc2.h is:
DItype __bswapdi2 (DItype u)
Since this declaration does not check if DItype is supported, it is
bound for compilation failure for targets that do not support
DItype.
On Jun 18, 2007, at 6:50 PM, Joseph S. Myers wrote:
Any comments on either the general approach or the details?
Sounds fine to me. In mips land we were previously using named
sections to solve this, but as long as the approach allows arbitrarily
long sets of attributes I think it sounds g
I'm sure plenty will look down their nose at me for asking in this
forum(mailing list) ...but I recall a tool for checking libraries
and build
options (libtool libraries only maybe) ...I can't recall how or
where, or
think what to feed google (The architecture I'm building on is amd64
if th
Thank you, I guess I missed that page somehow.
Only I ran into the same Libc wall again, so I'm temporarily stumped:
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when
searching
for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when
searching for
-lc
/usr/bin/
On Jun 18, 2007, at 2:36 PM, michael.a wrote:
This suggestion made some ground. But I just can't get a build to
complete.
The newest checkout / release aren't compatible with my C libraries it
seems, and I'm not sure its safe dependency wise to just replace the C
libraries. So I rewound my su
Thanks for the reply.
I did remove --enable-libmudflap option from the build script and
followed following steps for libmudflap configuration:
Why on earth would you do this?
I created a separate build folder and from there
a) [libmudflap source path]/configure --target=sh-elf --prefix=[M
On Jun 4, 2007, at 12:09 AM, Deepen Mantri wrote:
Frank Ch. Eigler <[EMAIL PROTECTED]> wrote:
libmudflap needs to know the know the name of the entry point symbol,
to enable one of its heuristics. See the ENTRY_POINT area in
configure.ac, and update it for your own runtime. Be aware that
l
On May 25, 2007, at 2:10 PM, Eric Botcazou wrote:
I don't personally have time to convert all ports, and it is
better if
people who know each individual backend and have access to hardware
do the conversions, anyway. So I'd like to invite port
maintainers to
convert their ports in this d
On May 16, 2007, at 8:00 PM, Jack Howarth wrote:
Currently gcc 4.2.0 suffers from 90 libjava failures on i686-
apple-darwin8
including the boehm gctest. Backporting the changes from revision
120684...
http://gcc.gnu.org/viewcvs?view=rev&revision=120684
as suggested in...
which include
On May 16, 2007, at 1:53 PM, Andrew Pinski wrote:
On 5/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
This also occurred with the latest snapshot:
Configure syntax was:
./configure --prefix=/opt/gcc-4.3
Configure completed fine. Make is getting stuck at:
You are compiling in the s
In file included from ../.././libgcc/../libdecnumber/decContext.c:36:
../.././libgcc/../libdecnumber/decContext.h:52:50: error:
gstdint.h: No such file or directory
... lots of other errors ...
gstdint.h seems to be at:
/part/build/mark/gcc/host-x86_64-unknown-linux-gnu/libdecnumber/
g
On May 14, 2007, at 11:35 AM, Mike Stump wrote:
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
Maybe something like:
#ifndef _SOFT_FLOAT
stfd %f1, 48(%r1)
#e
On May 13, 2007, at 3:48 AM, Tom Womack wrote:
I have some code of the form
This really isn't enough, I put a bit of a testcase together, but
nothing that would give bad behavior at -O3 (there is no -O9).
Have more of a testcase? Something compilable?
-eric
On Apr 20, 2007, at 1:24 AM, Victor Librado wrote:
Hello all,
I`m working with an arm core 9260EJ-S under Linux (Linux kernel
2.6.15; armv5l-linux toolchain with compiler gnu gcc 3.4.2). I
would like to take advantage of the asm DSP like functions the core
provides. I compile this way:
increase code size? I feel I must be missing something really
obvious... is
it just that the other optimisations that become possible on inline
code
usually compensate?
That or the savings from not having to save/restore registers, set up
the frame, etc as well.
-eric
On Apr 12, 2007, at 10:17 PM, Daniel Berlin wrote:
On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]>
wrote:
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.
T
I didn't just pull this out of a hat, you know :-) Where do you think
it's going to install the library if you do that?
Yeah, I know. I said it wasn't a good patch, but I was on my way out
of the office for the evening and wanted to get Doug something and
have you look at the code too :)
That said, though, there's something weird going on in your build that
should probably be tracked down. It didn't happen to me last time I
built...
Here's a patch that fixes it though it doesn't fix the testsuite
results yet and is likely not quite what Daniel will want...
Dan?
The basic
../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:7597: warning:
string length '575' is greater than the length '509' ISO C89
compilers are required to support
Are these expected?
Yup.
-eric
On Mar 17, 2007, at 4:31 PM, Dominique Dhumieres wrote:
The new method will be that the default will be the system that
you are
currently on. It's not the default now.
How new is new? As far as I can tell, it did not work for the
20070309 snapshot. Form the regtests gcc.dg/builtins-59.c and
On Mar 17, 2007, at 4:15 PM, Dominique Dhumieres wrote:
Eric,
Thanks for the explanations.
The idea, I believe, is that the default will be the system that you
are currently on.
It would be nice, but it is not the way it seems to work (at least
for gcc,
for g++ and gfortran it may, but
Thanks for the answer, but I understand very little of it.
The above can be read as:
If TARGET_64BIT is true, then TARGET_C99_FUNCTIONS is true,
otherwise if we're targeting 10.3 or later, then TARGET_C99_FUNCTIONS
is true, otherwise, TARGET_C99_FUNCTIONS is false.
So far so good.
we are ta
This and the register changes come close to multi-arch gcc. Is that a
direction we want to go? Historically we have not tried to support
Personally I'd love to see us go this way if it doesn't inconvenience
us too much.
From what I remember of the MeP port it was pretty clean and wouldn't
Hi Michael,
Two questions about Apple's Objective-C 2.0 work:
1) Does anyone know when the syntax extensions will be available &
working
in the gcc compiler?
2) Will their garbage collection & accelerated message dispatch
mechanisms
also be supported?
Fairborz is working on them, I ima
There was a long discussion about this a couple of months ago. The
summary was that __attribute__ ((mode (word))) was considered harmful.
It's safe enough when you use it within a program, but when you start
to use in a data structure shared by different codes you run into ABI
problems. A typic
One target is to identify more places where we can get rid of
_Unwind_Word.
Other places exist where we definitely need a data type like
_Unwind_Word
representing a general purpose register. So we have to find a way
to define
_Unwind_Word without using the mode(word) attribute.
So, I mi
On Jan 17, 2007, at 5:19 PM, Jack Howarth wrote:
I noticed today that gcc 4.2 branch seems to create a bogus symlink
on Darwin PPC. A symlink for libgcc_s_x86_64.1.dylib is created that
points at libgcc_s.1.dylib. However libgcc_s.1.dylib is not a quad
binary...
file libgcc_s.1.dylib
libgcc_s
On Jan 13, 2007, at 8:28 AM, Jack Howarth wrote:
Eric,
So will FSF gcc on Darwin maintain the current 64-bit subdirectory
or will it eventually migrate to using fat binaries as Apple gcc does?
Current is likely.
-eric
On Jan 13, 2007, at 6:13 AM, Jack Howarth wrote:
I noticed that Apple's gcc compiler in MacOS X 10.4
creates fat binaries in /usr/lib rather than using a
ppc64 or x86_64 subdirectory like FSF gcc. Do the Darwin
gcc developers ever intend to replicate the use of fat
binaries for FSF gcc (in g
On Dec 23, 2006, at 10:28 AM, Dominique Dhumieres wrote:
Building gcc4-4.3.0-20061223 on OSX 10.3 failed with:
...
gcc -g -fkeep-inline-functions -no-cpp-precomp -
DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format
make -k -j 8 check >& check.log ; make mail-report-with-warnings.log
I got results that appear not much different from the powerpc-apple-
darwin8.8.0 (i.e., 32-bit) results:
http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00267.html
i.e., these results don't show a particular fortran proble
to see if that eliminates the problems. Also I
assume Bradley remembered to install the build
before running make check. I see lots of libgomp
failures I believe those could be due to that.
Also, Bradley, did you remember to patch the
prune.exp scripts in the testsuite? You will
get a huge numbe
It isn't only on the AVR that bswap_32() is nontrivial to get
right.
These two versions would rule on the i386 if GCC would be just a
little bit
smarter:
I prefer the single instruction bswap that we now generate for
__builtin_bswap[32,64] myself...
-eric
On Nov 15, 2006, at 8:59 PM, Jack Howarth wrote:
Mike,
The problem is that the Geoff rejected the configure.in patch
that removes libgcj from noconfigdirs...
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00642.html
...as being too invasive for gcc 4.2. If you manually
apply that, it should
On Nov 14, 2006, at 11:32 AM, Eric Christopher wrote:
You appear to have regenerated configure, on both mainline and 4.2
branch,
with autoconf 2.60. Could you please regenerate it with 2.59 in both
places?
Sure, I'll have to dig it up somewhere. It appears to be the default
o
You appear to have regenerated configure, on both mainline and 4.2
branch,
with autoconf 2.60. Could you please regenerate it with 2.59 in both
places?
Sure, I'll have to dig it up somewhere. It appears to be the default
on FC6, I'll use that.
-eric
On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote:
Kaveh R GHAZI writes:
Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html
Kaveh> Perhaps we could take a second look at this decision? The
average system
Kaveh> has increased in s
On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote:
Kaveh R GHAZI writes:
Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html
Kaveh> Perhaps we could take a second look at this decision? The
average system
Kaveh> has increased in s
Eric> Well, yes, did you see anything in what I wrote that argued
differently?
Yes, what I quoted, the comparison with gmp/mpfr and c99 inlining.
Those other problems are irrelevant.
I disagree, they were other examples of breakages.
-eric
On Nov 7, 2006, at 5:24 AM, David Edelsohn wrote:
Eric Christopher writes:
Eric> We're in stage1, breakages happen - see the current fun with
gmp/mpfr as
Eric> well as c99 inlining. File a bug or bring a problem up for
discussion.
Yes, breakage happens in Stage 1, b
Except this is a different issue as the patch is for Darwin.
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00168.html
Geoff appears to have given a workaround for the problem and has
promised to inquire further about more up to date solutions. Another
solution, of course, is to revert the defaul
On Nov 6, 2006, at 8:59 PM, Andrew Pinski wrote:
On Mon, 2006-11-06 at 20:57 -0800, Eric Christopher wrote:
As far as 4.2 this is the first I've heard of it. What's the problem?
Well you need a new cctools which does not exist for 10.2.
While I'm sure you could be less
Right now after patches by the Apple folks causes you to need a
newer
dwarfutils which don't exist outside of Apple so the community of Free
Source and GCC is not helped by making Darwin a primary platform.
Maybe we should list a specific version of darwin which changes the
confusion of whi
I ended up including both your preference and mine. Hopefully one or
other other (or both) end up being useful to users.
Thanks, this will help with some of the questions I received
internally today.
-eric
Maintainability first. If something fails with parallel make, and
is reproducible with plain "make" (i.e. doesn't screw up the build
directory), I don't see a reason not to move it. You'd do "make"
anyway to check if a dependency is missing, wouldn't you?
Really, all I care about is hav
On Oct 23, 2006, at 4:15 PM, Paolo Bonzini wrote:
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC
subdirectory, not in the toplevel (it was anyway a hack for the
sake of disabling Fortran).
Moving it is not reall
On Oct 19, 2006, at 2:50 PM, Diego Novillo wrote:
Eric Christopher wrote on 10/19/06 17:33:
I was wondering if anyone planned on changing abi or if we can depend
on all changes not breaking the abi of these libraries?
There is nothing planned in that area, but I wouldn't want to
guar
We're thinking of including these libraries in the next version of OS
X on the system so that 4.2 will work out of the box when either a) it
is released, or b) leopard is released, whichever happens last. Since
we need to keep abis stable, I was wondering if anyone planned on
changing abi o
Has this been considered in the past, but rejected for some reason?
Don't see why it would. Could be useful.
Should I have posted this to a different GCC list? :P
This is fine.
-eric
On Oct 8, 2006, at 4:35 PM, Jack Howarth wrote:
Ben,
Currently on Darwin and apparently Solaris as well, we have
build failures when gcc trunk is built without resorting to
--disable-multilib on hardware that doesn't support 64-bits.
See PR21561.
It'd be possible for non-cross compiles t
Jack Howarth wrote:
Eric,
I had always thought 90% of the advantage of
x86_64 was the extra registers in EMT64. Actually
the only gripe I have with Apple's transient to
Intel is that they didn't junk the i386 model and
only use chips that could do EMT64 so we would always
have those extra re
Bradley Lucier wrote:
On Oct 4, 2006, at 1:57 PM, Eric Christopher wrote:
FWIW I think a 64-bit native version might be nice as a separate
target, but I've been told there's no real advantage there either on ppc.
Perhaps I'm misunderstanding your comment, but with a 64-
On Oct 4, 2006, at 10:53 AM, Bradley Lucier wrote:
On Sep 22, 2006, at 9:20 PM, Eric Christopher wrote:
Bradley Lucier wrote:
Right now, it seems that one may not be able to build a 64-bit
version of the compiler itself
You may or may not have noticed that there are no 64-bit native
So, a testcase like this:
extern void foo() __attribute__((deprecated));
extern void bar() __attribute__((deprecated));
void foo() {}
void bar()
{
foo();
}
Should we warn on the invocation of foo() since it's also being called
from within a deprecated function? We are today, but I've gott
Bradley Lucier wrote:
Right now, it seems that one may not be able to build a 64-bit version
of the compiler itself, on either either x86-64 or ppc64, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994
I notice that because some of my (automatically generated) C programs,
with certain comp
I'm glad you asked ;) Although you probably won't be.
I must admit I've always felt mips-elf to be a less-than-ideal
replacement for mips-sgi-irix6.5. The former is 32-bit only, while the
latter includes o32, n32 and n64, giving both 32-bit and 64-bit coverage.
I fully agree with removing mip
Mike Stump wrote:
On Sep 20, 2006, at 8:11 PM, Mark Mitchell wrote:
4. Replace powerpc-apple-darwin with i686-apple-darwin. Apple's
hardware switch would seem to make the PowerPC variant less interesting.
I'd rather just add i686-apple-darwin as a secondary. We don't
instantly replace the e
I filed a PR29090 for the gcc.dg-struct-layout-1 failure of
T(94,struct atal16{}a;,)
OK.
.comm _a94,1
.stabs "a94:G(0,1)=ar(0,2)[EMAIL
PROTECTED];r(0,2);0;017;;0;04;(1,1)",32,0,1,0
.stabs "long unsigned int:t(0,3)[EMAIL
PROTECTED];r(0,3);0;01
Eric, Do you mean that they're noisy because of the WARNINGs? I always
find warnings annoying, perhaps test_summary should filter them out.
Yeah, that's what I meant.
Notice that for -m32, the message from the linker includes "In function
`main':"; this causes prune_gcc_output to remove tha
Jack Howarth wrote:
Eric,
Do you see the same set of failures...
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_
Does anyone recognize any sort of pattern to these failures which might suggest
why they
fail on Darwin PPC at -m64 and not on ppc64?
We do have a radar about the lack of aligned uninitialized variable
support, i.e. .comm x,size,align that references t001 and t025.
-eric
Joseph S. Myers wrote:
On Tue, 12 Sep 2006, Eric Christopher wrote:
So, these are xfailed, but still produce quite a bit of noise on both
x86_64-darwin and x86_64-linux since they fail to produce a working executable
and then xfail. Should we move them to skip or link only and xfail them. With
So, these are xfailed, but still produce quite a bit of noise on both
x86_64-darwin and x86_64-linux since they fail to produce a working
executable and then xfail. Should we move them to skip or link only and
xfail them. With link only they do manage to be quiet in the logs and
we'll still not
Shantonu Sen wrote:
That's not correct. The linker support only exists in ld64 for Xcode
2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be
using this assembly feature...
Right, I knew that. Looks like I have a typo though. Bah.
I'll fix it shortly. Though nothing wrong
Jack Howarth wrote:
Eric,
One last question. Is it correct to assume that when
the newer cctools with the literal16 support becomes
available, things like 'integer(16)' will become available
in gfortran for darwin?
Seems reasonable to expect that it could be made to happen.
-eric
Using the cctools from Xcode 2.4, the failure changes and moves to the linkage
of libgfortran itself...
ld: .libs/maxloc0_4_r16.o unknown flags (type) of section 2
(__TEXT,__literal16) in load command 0
ld: .libs/maxloc0_8_r16.o unknown flags (type) of section 2
(__TEXT,__literal16) in load c
Once the noise from those linker warnings is removed from the libstdc++-v3
testsuite
results at -m64 on Darwin PPC, we find that the failures drop from 54 to just
6. So
we actually only have four additional libstdc++-v3 testsuite failures at -m64
compared to -m32. These are...
FAIL: 21_strings/
Jack Howarth wrote:
Eric,
Does the following test fail for you under your x86_64 patch set for
Macintel?
No, but that's because I have a patch to fix it :)
-eric
Jack Howarth wrote:
Eric,
Does that imply that the TImode patch is a must have
for Darwin x86_64 in the gcc 4.2 release? If so you might try
to convince Geoff that it really should go into gcc trunk
before the branch occurs. Frankly I was aghast to discover
yesterday that the folks doing the I
So the problem on Darwin seems to be with conversion of the float results to
integer results.
Geoff has said he has done all he intends to with TImode for now so perhaps
someone else more
interested might take a look at this bug (which may well be independent of, but
exposed by the
TImode sup
Jack Howarth wrote:
Geoff,
It appears that this issue with the ld64 link issuing warnings of
"can't find atom for N_GSYM stabs" is not specific to gfortran. I finally
figured out the correct syntax to run a complete make check so that the
libraries as well as gcc are checked. FYI, the trick is
However, in s390.c, we have:
static bool
s390_valid_pointer_mode (enum machine_mode mode)
{
return (mode == SImode || (TARGET_64BIT && mode == DImode));
}
Note that more than one mode is supported simultaneously. Thus, it's
legal for the application to specify SI or DI mode for pointer (via
_
Andrew de Quincey wrote:
On Thursday 27 July 2006 02:20, Mike Stump wrote:
On Jul 26, 2006, at 3:54 PM, Andrew de Quincey wrote:
Hi, I have been porting mozilla firefox to the SH4 platform.
However, I have
run into some horrible floating point problems.
This list isn't for what you think it is
kernel coder wrote:
hi,
I'm trying to understand the backend code of gcc for MIPS
architecture.I'm having some trouble while understanding following
functions.
I think most of these are obvious, what problems in specific are you
having with them?
-eric
I have to choose between:
(a) keep Wconversion only for warnings about prototypes causing a type
conversion different from what would happen to the same argument in
the absence of a prototype, which was its original purpose, and move
everything else to a new option (Wcoercion).
(b) keep the wa
The insn when x==0 is this:
(call_insn 28 27 29 (parallel [
(set (reg:DI 30 $r0)
(call (mem:SI (symbol_ref:SI ("g") [flags 0x3]
) [0 S4 A32])
(const_int 0 [0x0])))
(use (nil))
(clobber (reg:SI 2 $ra))
]) -1 (nil)
This SIGSEGV happens here:
mark_jump_label (x=0x0, insn=0xb7f34b00, in_mem=0) at
../../gcc/gcc/jump.c:1381
1381 RTX_CODE code = GET_CODE (x);
(gdb) where
#0 mark_jump_label (x=0x0, insn=0xb7f34b00, in_mem=0)
at ../../gcc/gcc/jump.c:1381
#1 0x08123eee in mark_jump_label (x=0xb7f7c540,
On May 28, 2006, at 11:06 PM, Monika Sapra wrote:
Hi all,
I am new to this list and GCC compiler. I am trying to build
GCC4.1.0 for
"mipsisa32-elf" target. I would appreciate if someone could help me
out in
resolving the errors during build process.
You should really use a combined tree
On May 28, 2006, at 2:06 PM, Manuel López-Ibáñez wrote:
Thanks Andrew, that is exactly what I did, although I was expecting
configure to be smart enough to use that trick on my behalf.
but that would be guessing what you meant and not requiring you to
explicitly say what you meant.
-eric
On May 17, 2006, at 4:32 PM, fsshl plinlin wrote:
Union-Souths-Computer:~/Developer/usr/local/bin UnionSouth$ ./gcc
../../../try.cgcc: error trying to exec 'cc1': execvp: No such file or
directory
This list is for developers of gcc. You should be using gcc-help.
FWIW you need more than jus
On May 16, 2006, at 7:39 PM, fsshl plinlin wrote:
Dear gcc and/or apple OS X 7.9 users:
Union-Souths-Computer:~/gcc-5250 UnionSouth$ cat config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:595: chec
On May 14, 2006, at 12:13 PM, Eric Botcazou wrote:
They don't complain and they update their sources when integrating
into the mainline. They had to update Objective-C++ for the new C++
parser.
Just like AdaCore had to update Ada for tree-ssa?
That's part of maintaining. Sometimes the lang
On May 7, 2006, at 5:06 PM, fsshl plinlin wrote:
dear gcc:
when I try to install gcc 4.0 at my apple mac os X , 7.9.0 (by uname
-r),
when I ./configure
it reply error as no acceptable cc found in $PATH
if that need c compiler be install, please tell where, (if binary ,
please indicate th
Any suggestions, pointers or recommendations for tools, tips and/or
techniques would be appreciated.
A couple of different ways come to mind:
a) there's the binutils -ffunction-sections -Wl,-gc-sections approach
where every function is put into it's own section and the total is
then garbag
1 - 100 of 189 matches
Mail list logo
