On Thu, Oct 1, 2009 at 2:47 AM, Dave Korn
wrote:
>
> Hi everyone,
>
> I'm using g++.old-deja/g++.brendan/new3.C as a testcase to investigate a
> problem with dllimport at the moment, and noticed something a bit unusual:
>
> Here is the CIE data from new3.C as compiled with gcc-4.3.4
>
>>
Hi Dave.
It was me who, in a mistake (I wanted to delete them) marked those tickets
as "Opened".
Sorry for the inconvenience.
--
Jose E. Marchesi
GNU Project http://www.gnu.org
Richard Guenther wrote:
> On Thu, Oct 1, 2009 at 2:47 AM, Dave Korn wrote:
>> I'm using g++.old-deja/g++.brendan/new3.C as a testcase to investigate a
>> problem with dllimport at the moment, and noticed something a bit unusual:
>>
>> Here is the CIE data from new3.C as compiled with gcc-4.3.4
Hi,
I ran an experiment with arm-elf. I took every
CPU model documented in the gcc.info file and
passed it in via -mcpu=XXX. The following
CPU models linked successfully:
arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm7m
arm7d arm7dm arm7di arm7dmi arm70 arm700 arm700i arm710
arm710c
> 2. If the normal way to do things is to parse the make -n output
> with perl etc, that's fine, I'll do it that way. I was just wondering
> if the proper way was to incorporate the logic into a Makefile
> rule and get that rule repeatedly executed rather than just
> having a simple "echo". It s
> Do we want to enable more multilibs in arm-elf?
Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
maintenance only mode. You should be using arm-eabi.
IMHO building lots of multilibs by default significantly increases toolchain
size and build time for little actual ben
> I am happy to construct all of this on a Unix system with the various
> tools (m4 etc) available.
>
> But from the Unix system, I need to be able to generate the
> above very simple compile script, which is a precursor to creating
> very simple JCL steps (trust me, you don't want to see what
> S
On 09/15/2009 02:22 PM, Mark Zweers wrote:
While experimenting with "Defaulted and deleting functions" on my brand-newly
downloaded gcc-4.5 compiler, I've noticed the following: the order of '=default' and
'=delete' matters with template member functions.
I'm about to check in a fix for this,
Hi,
on s390x I see broken debug info generated for the attached C++
testcase (compile with -O2 -g -fPIC).
The debug info contains a symbol reference with a @GOTENT modifier
what should not happen (and is not accepted by gas):
.LLST3:
I am happy to construct all of this on a Unix system with the various
tools (m4 etc) available.
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks l
I've opened bz #41535 for this problem.
Bye,
-Andreas-
"Paul Edwards" writes:
>> the gcc build system working. Trying to bootstrap gcc there seems
>> like a lot
>> of pain for no real benefit.
>
> The effort is mostly in the Canadian Cross. The changes to get it to
> bootstrap from that point are relatively small.
I think you are underestimating th
Paul Brook wrote:
Do we want to enable more multilibs in arm-elf?
Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
maintenance only mode. You should be using arm-eabi.
IMHO building lots of multilibs by default significantly increases toolchain
size and build t
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards wrote:
>>> But from the Unix system, I need to be able to generate the
>>> above very simple compile script, which is a precursor to creating
>>> very simple JCL steps (trust me, you don't want to see what
>>> ST2CMP looks like). Note that the JCL ha
Hi,
I moved implicit-zee.c to config/i386. Can you please take another look ?
* tree-pass.h (pass_implicit_zee): New pass.
* testsuite/gcc.target/i386/zee.c: New test.
* timevar.def (TV_ZEE): New.
* common.opt (fzee): New flag.
* config.gcc: Add impli
David Edelsohn wrote:
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards wrote:
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks like). Note that
On Thu, 1 Oct 2009, Paul Brook wrote:
> > Do we want to enable more multilibs in arm-elf?
>
> Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
> maintenance only mode. You should be using arm-eabi.
I'm possibly (probably?) wrong, but as far as I know, it forces alignmen
Snapshot gcc-4.5-20091001 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091001/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
> Since this will be arm-rtems multilib's when submitted,
> which variants and matches need to be added so we have
> the right libraries for all CPU model arguments. ld is
> complaining at least about libc.a mismatches for these variations.
>
> does not use Maverick instructions, whereas a.out
There should not be any more functional changes to the LTO merge
needed for the final merge into mainline. I am waiting for the final
round of testing and finishing up documentation changes requested by
Joseph.
I expect this to be done by tomorrow. I would like to freeze trunk on
Sat 3-Oct and d
> > Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
> > maintenance only mode. You should be using arm-eabi.
>
> I'm possibly (probably?) wrong, but as far as I know, it forces alignment
> of 64-bit datum (namely, doubles and long longs) to 8 byte boundaries,
> which does
On Thu, 1 Oct 2009, Diego Novillo wrote:
> There should not be any more functional changes to the LTO merge
> needed for the final merge into mainline. I am waiting for the final
> round of testing and finishing up documentation changes requested by
> Joseph.
>
> I expect this to be done by tomo
the gcc build system working. Trying to bootstrap gcc there seems
like a lot
of pain for no real benefit.
The effort is mostly in the Canadian Cross. The changes to get it to
bootstrap from that point are relatively small.
I think you are underestimating the work involved.
? Note that I ha
Richard Guenther writes:
>
> The wish for more granular and thus smaller debug information (things like
> -gfunction-arguments which would properly show parameter values
> for backtraces) was brought up. We agree that this should be addressed at a
> tools level, like in strip, not in the compiler
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks like). Note that the JCL has the filenames
truncated to 8 characters, listed twice, uppercased, a
On Thu, Oct 01, 2009 at 05:00:10PM -0700, Andi Kleen wrote:
> Richard Guenther writes:
> >
> > The wish for more granular and thus smaller debug information (things like
> > -gfunction-arguments which would properly show parameter values
> > for backtraces) was brought up. We agree that this shou
On Thu, Oct 1, 2009 at 20:22, Paul Brook wrote:
>
> > > Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
> > > maintenance only mode. You should be using arm-eabi.
Is it now possible to build a 100% arm-eabi functional toolchain
(including i.e. newlib) in multilib mode st
> Meh. Badly written code on antique hardware.
> I realise this sounds harsh, but in all seriousness if you take a bit of care
Yes, I think it does sound harsh, considering that, I believe, at least as
many chips are sold with ARM7TDMI core as the nice fat chips with MMU,
caches, 64 and 128 bit bu
28 matches
Mail list logo
