On 06/03/2024 15:04, Andrew Carlotti via Gcc wrote:
> On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote:
>> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
>>>
>>> Hi Christophe,
>>>
>>> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
I've not
On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote:
> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> >
> > Hi Christophe,
> >
> > On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> > > I've noticed that sourceware's buildbot has a small script
> >
On 05/03/2024 14:26, Richard Earnshaw (lists) wrote:
> On 04/03/2024 20:04, Jonathan Wakely wrote:
>> On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
>> wrote:
>>>
>>>
>>>
>>> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
Tools like git (and svn before it) don't try to maintain time-sta
On 04/03/2024 20:04, Jonathan Wakely wrote:
> On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
> wrote:
>>
>>
>>
>> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
>>> Tools like git (and svn before it) don't try to maintain time-stamps on
>>> patches, the tool just modifies the file and the time
On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
wrote:
>
>
>
> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
> > Tools like git (and svn before it) don't try to maintain time-stamps on
> > patches, the tool just modifies the file and the timestamp comes from the
> > time of the modification.
On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
Tools like git (and svn before it) don't try to maintain time-stamps on
patches, the tool just modifies the file and the timestamp comes from the time
of the modification. That's fine if there is nothing regenerated within the
repository (it
On 04/03/2024 16:42, Christophe Lyon wrote:
> On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw
> wrote:
>>
>>
>>
>> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
>> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
>> >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely
>> >> wrote:
>> >>>
>
On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw wrote:
>
>
>
> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
> >>>
> >>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc
> >
On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
> On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
>> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
>>>
>>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc
>>> wrote:
Hi!
On Mon, 4 Mar 2024 at 10:36, Thomas
On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
>>
>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote:
>>>
>>> Hi!
>>>
>>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
Hi!
On 2024-03-04T00:30:05+,
On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
>
> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote:
> >
> > Hi!
> >
> > On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
> > >
> > > Hi!
> > >
> > > On 2024-03-04T00:30:05+, Sam James wrote:
> > > > Mark Wielaard writes:
>
On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote:
>
> Hi!
>
> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
> >
> > Hi!
> >
> > On 2024-03-04T00:30:05+, Sam James wrote:
> > > Mark Wielaard writes:
> > >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> > >
Hi!
On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
>
> Hi!
>
> On 2024-03-04T00:30:05+, Sam James wrote:
> > Mark Wielaard writes:
> >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> >>> [...], I read
> >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
> >
Hi!
On 2024-03-04T00:30:05+, Sam James wrote:
> Mark Wielaard writes:
>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>>> [...], I read
>>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>>> which basically says "run autoreconf in every dir where there is a
>>> c
Mark Wielaard writes:
> Hi Christophe,
Hi Mark, Christophe, et. al,
>
> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>> > > > And it was indeed done this way because that way the files are
>> > > > regenerated in a reproducible way. Which wasn't the case when using
>> > > >
Hi Christophe,
On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> > > > And it was indeed done this way because that way the files are
> > > > regenerated in a reproducible way. Which wasn't the case when using
> > > > --enable-maintainer-mode (and autoreconfig also doesn't work).
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> > > That python script works across gcc/binutils/gdb:
> > > https://sourceware.org/cgit/builder/tree/builder/
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> > > That python script works across gcc/binutils/gdb:
> > > https://sourceware.org/cgit/builder/tree/builder/
Hi Christophe,
On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> > That python script works across gcc/binutils/gdb:
> > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py
> >
> > It is installed into a containe
On Thu, 29 Feb 2024 at 20:49, Thiago Jung Bauermann
wrote:
>
>
> Hello,
>
> Christophe Lyon writes:
>
> > I hoped improving this would be as simple as adding
> > --enable-maintainer-mode when configuring, after making sure
> > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's
>
Hello,
Christophe Lyon writes:
> I hoped improving this would be as simple as adding
> --enable-maintainer-mode when configuring, after making sure
> autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's
> libtool and gettext seems OK).
>
> However, doing so triggered several pr
On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> > I've noticed that sourceware's buildbot has a small script
> > "autoregen.py" which does not use the project's build system, but
> > rather calls a
On Thu, 29 Feb 2024 at 11:41, Richard Earnshaw (lists)
wrote:
>
> On 29/02/2024 10:22, Christophe Lyon via Gcc wrote:
> > Hi!
> >
> > Sorry for cross-posting, but I'm not sure the rules/guidelines are the
> > same in gcc vs binutils/gdb.
> >
> > TL;DR: are there some guidelines about how to use/en
Hi Christophe,
On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> I've noticed that sourceware's buildbot has a small script
> "autoregen.py" which does not use the project's build system, but
> rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way.
> Should we
On 29/02/2024 10:22, Christophe Lyon via Gcc wrote:
> Hi!
>
> Sorry for cross-posting, but I'm not sure the rules/guidelines are the
> same in gcc vs binutils/gdb.
>
> TL;DR: are there some guidelines about how to use/enable maintainer-mode?
>
> In the context of the Linaro CI, I've been looking
Hi!
Sorry for cross-posting, but I'm not sure the rules/guidelines are the
same in gcc vs binutils/gdb.
TL;DR: are there some guidelines about how to use/enable maintainer-mode?
In the context of the Linaro CI, I've been looking at enabling
maintainer-mode at configure time in our configurations
> Hello,
Hi,
> I have almost completed the output of relocation entries. The only thing
> that remains is to output the corresponding symbols in .symtab. In my
> current design, I store the info about relocation entry and the symbol
> name. However, the problem I am facing with this approach is tha
Hello,
I have almost completed the output of relocation entries. The only thing
that remains is to output the corresponding symbols in .symtab. In my
current design, I store the info about relocation entry and the symbol
name. However, the problem I am facing with this approach is that many
relocat
Greetings, Iaian.
On 2023-02-20 12:42, Iain Sandoe wrote:
Hi Shengyu,
On 20 Feb 2023, at 17:31, Shengyu Huang via Gcc wrote:
After following the instructions here (https://gcc.gnu.org/wiki/InstallingGCC)
and here (https://gcc.gnu.org/install/index.html), the `make` step simply fails
wit
Hi Shengyu,
> On 20 Feb 2023, at 17:31, Shengyu Huang via Gcc wrote:
>
> After following the instructions here
> (https://gcc.gnu.org/wiki/InstallingGCC) and here
> (https://gcc.gnu.org/install/index.html), the `make` step simply fails with
> “*** Configuration aarch64-apple-darwin22.1.0 not
Dear all,
After following the instructions here (https://gcc.gnu.org/wiki/InstallingGCC)
and here (https://gcc.gnu.org/install/index.html), the `make` step simply fails
with “*** Configuration aarch64-apple-darwin22.1.0 not supported”. I found this
issue on Bugzilla (https://gcc.gnu.org/bugzill
Jeff Law writes:
> On 04/02/14 06:08, Anthony Green wrote:
>>
>> One embarrassing feature of the moxie compiler port is that it really
>> doesn't understand how to promote integral types. Moxie cores
>> zero-extend all loads, but the compiler still shifts loaded values back
>> and forth to zero
Joern Rennecke writes:
> On 2 April 2014 13:08, Anthony Green wrote:
>
>> I though the answer was to simply add something like this...
>>
>> (define_insn "zero_extendqisi"
>> [(set (match_operand:SI 0 "register_operand" "=r")
>> (zero_extend:SI (match_operand:QI 1 "register_operand" "r
On 04/02/14 06:08, Anthony Green wrote:
One embarrassing feature of the moxie compiler port is that it really
doesn't understand how to promote integral types. Moxie cores
zero-extend all loads, but the compiler still shifts loaded values back
and forth to zero out the upper bits.
I'm a bit sur
On 2 April 2014 13:08, Anthony Green wrote:
> I though the answer was to simply add something like this...
>
> (define_insn "zero_extendqisi"
> [(set (match_operand:SI 0 "register_operand" "=r")
> (zero_extend:SI (match_operand:QI 1 "register_operand" "r")))]
> ""
> "; ZERO EXTEND (
One embarrassing feature of the moxie compiler port is that it really
doesn't understand how to promote integral types. Moxie cores
zero-extend all loads, but the compiler still shifts loaded values back
and forth to zero out the upper bits.
So...
unsigned int foo (unsigned char *c)
{
return
On Thu, 29 Mar 2012 23:29:40 +0200
Romain Geissler wrote:
>
> You've made a typo will copy/pasting part of the line. Look at the dollar $
> char
> near '=$ (shell)', the space is misplaced. It should be '= $(shell'.
Thanks! Corrected.
--
Basile STARYNKEVITCH http://starynkevitch.net
Le 29 mars 2012 à 23:03, Basile Starynkevitch a écrit :
> On Thu, 29 Mar 2012 22:45:27 +0200
> Romain Geissler wrote:
>
>> MELTGCC_BUILD_WITH_CXX = $(shell grep -q
>> 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
>> `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo
On Thu, 29 Mar 2012 22:45:27 +0200
Romain Geissler wrote:
> MELTGCC_BUILD_WITH_CXX = $(shell grep -q
> 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
> `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
>
Thanks; I applied that patch with
2012-03-29 Romain G
Le 29 mars 2012 à 22:02, Basile Starynkevitch a écrit :
>
> Hello All,
>
> The pre-release candidate 1 of MELT 0.9.5 is available for testing on
> http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz
> as a gzipped tar archive of 4473286 bytes and md5sum
> ae00b9bd31f481e1bbc40671
Hello All,
The pre-release candidate 1 of MELT 0.9.5 is available for testing on
http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz
as a gzipped tar archive of 4473286 bytes and md5sum
ae00b9bd31f481e1bbc406711ca4c2f4.
extracted from MELT branch 185969, march 29th 2012
You coul
On Thu, May 27, 2010 at 10:14 AM, Paolo Bonzini wrote:
> On 05/27/2010 10:10 AM, Steven Bosscher wrote:
>>
>> -/* FIXME: Still need to include rtl.h here (via expr.h) in a front-end
>> file.
>> - Pretend this is a back-end file. */
>> -#define IN_GCC_BACKEND
>> #include "expr.h" /* For vector_
On 05/27/2010 10:10 AM, Steven Bosscher wrote:
-/* FIXME: Still need to include rtl.h here (via expr.h) in a front-end file.
- Pretend this is a back-end file. */
-#define IN_GCC_BACKEND
#include "expr.h" /* For vector_mode_valid_p */
Is this really the only reason? We don't have any othe
gcc/ChangeLog:
* Makefile.in (ALL_CFLAGS): Add file-specific CFLAGS.
(ALL_HOST_FRONTEND_OBJS): New, for all front-end specific objects.
(ALL_HOST_BACKEND_OBJS): New, for all backend and target objects.
(ALL_HOST_OBJS): Now a union of the above two.
:
On Thu, May 27, 2010 at 9:49 AM, Paolo Bonzini wrote:
> On 05/27/2010 08:25 AM, Steven Bosscher wrote:
>>
>> On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
>> Well, gives me at least one clue so far: the implicit rule .c.o is
>> over-ruled by t-i386, which explains why the extra CFLAGS-$fi
On 05/27/2010 08:25 AM, Steven Bosscher wrote:
On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
Well, gives me at least one clue so far: the implicit rule .c.o is
over-ruled by t-i386, which explains why the extra CFLAGS-$file are
not passed to config/i386/i386-c.c. I'm now restarting the
On Thu, May 27, 2010 at 8:25 AM, Steven Bosscher wrote:
> On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
>> On 05/27/2010 06:58 AM, Steven Bosscher wrote:
>>>
>>> Well, it looks like I do need something like @F because I now only get
>>> the define on files in gcc/. Any file with a / in th
On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
> On 05/27/2010 06:58 AM, Steven Bosscher wrote:
>>
>> Well, it looks like I do need something like @F because I now only get
>> the define on files in gcc/. Any file with a / in the full name $@
>> does not get a file specific CFLAGS.
>
> Inte
On 05/27/2010 06:58 AM, Steven Bosscher wrote:
Well, it looks like I do need something like @F because I now only get
the define on files in gcc/. Any file with a / in the full name $@
does not get a file specific CFLAGS.
Interesting, this simpler testcase worked:
test-a/b = $(warning ok)
all
On Tue, May 25, 2010 at 5:06 PM, Paolo Bonzini wrote:
> On Tue, May 25, 2010 at 16:59, Andreas Schwab wrote:
>> Steven Bosscher writes:
>>
>>> So I guess this plan of mine is not going to work...
>>> Other ideas?
>>
>> Add $(CFLAGS-$(@F)) to the .c.o rule
>
> Actually $@ is fine, since you want
Steven Bosscher writes:
> OK, the patch at the end of this mail appears to do what I've been
> trying to achieve.
> Does it look correct, and acceptable for the trunk after proper testing?
I'll approve the patch to system.h if testing succeeds. The patch to
Makefile.in looks fine to me but I'd
On Tue, May 25, 2010 at 5:06 PM, Paolo Bonzini wrote:
> On Tue, May 25, 2010 at 16:59, Andreas Schwab wrote:
>> Steven Bosscher writes:
>>
>>> So I guess this plan of mine is not going to work...
>>> Other ideas?
>>
>> Add $(CFLAGS-$(@F)) to the .c.o rule
>
> Actually $@ is fine, since you want
Steven Bosscher writes:
> +ALL_HOST_FRONTEND_OBJS = $(C_OBJS)
> + $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
You still need the backslash.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something complete
On Tue, May 25, 2010 at 16:59, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> So I guess this plan of mine is not going to work...
>> Other ideas?
>
> Add $(CFLAGS-$(@F)) to the .c.o rule
Actually $@ is fine, since you want cp/tree.o to have different flags
from tree.o.
> and define CFLAG
Steven Bosscher writes:
> So I guess this plan of mine is not going to work...
> Other ideas?
Add $(CFLAGS-$(@F)) to the .c.o rule and define CFLAGS-foo for each foo
in $(ALL_HOST_FRONTEND_OBJS). Though the latter is a bit tricky if you
want to do it automatically.
Andreas.
--
Andreas Schwab
On Tue, May 25, 2010 at 4:28 PM, Ralf Wildenhues wrote:
> * Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST:
>> On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
>> > Target-specific variable values are applied to all dependencies, see
>> > (make) Target-specific:
> [...]
>> Th
* Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST:
> On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
> > Target-specific variable values are applied to all dependencies, see
> > (make) Target-specific:
[...]
> That is the problem here. TM_H depends on insn-constants.h, which
>
Steven Bosscher wrote:
> The first thing I'd like to do now, is banish RTL from the front end.
Certainly a desirable goal!
(I did a bit of this in the C++ front-end a while back, though nothing
as formal or complete as what you are suggesting. There used to be
various places where the front end
On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> But for some reason I get -DIN_GCC_FRONTEND also on some of the gen*
>> files, libiberty, and gcov-io.o, like so:
>
> Target-specific variable values are applied to all dependencies, see
> (make) Target-specif
On Tue, May 25, 2010 at 2:25 PM, Joseph S. Myers
wrote:
> On Tue, 25 May 2010, Steven Bosscher wrote:
>
>> I am guessing this comes in from the $C_TARGET_OBJS and other language
>> target objects. In the Makefile in the build directory I have this
>> dependency:
>>
>> Target specific, C specific
On Tue, 25 May 2010, Steven Bosscher wrote:
> I am guessing this comes in from the $C_TARGET_OBJS and other language
> target objects. In the Makefile in the build directory I have this
> dependency:
>
> Target specific, C specific object file
> C_TARGET_OBJS=i386-c.o
>
> But unfortunately I ca
Steven Bosscher writes:
> But for some reason I get -DIN_GCC_FRONTEND also on some of the gen*
> files, libiberty, and gcov-io.o, like so:
Target-specific variable values are applied to all dependencies, see
(make) Target-specific:
There is one more special feature of target-specific variab
On 25/05/2010 09:44, Steven Bosscher wrote:
> +# This lists all host objects for the front ends. Extra defines are passed
> +# to the compiler for these objects.
> +ALL_HOST_FRONTEND_OBJS = $(C_OBJS)
> + $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
> +
Missing line-continuation backslash the
On Tue, May 25, 2010 at 9:56 AM, Paolo Bonzini wrote:
> On 05/25/2010 09:55 AM, Steven Bosscher wrote:
>>
>> 1) Group front end objects in Makefile.in under e.g.
>> ALL_HOST_FRONTEND_OBJS
>> 2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
>> 3) Conditionally poison symbols in s
On 05/25/2010 09:55 AM, Steven Bosscher wrote:
1) Group front end objects in Makefile.in under e.g. ALL_HOST_FRONTEND_OBJS
2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
3) Conditionally poison symbols in system.h
For the last step, that would be e.g.:
#ifdef IN_GCC_FRONTEND
Hi,
I would like to banish bits and pieces of the compiler from ever
appearing again in places where they do not belong. That would be step
one towards modularization: impose boundaries of some kind. As it is,
we can't really make separate modules of parts of gcc yet, but at
least I would like to
anandulle wrote:
> total no of increment count :: 0
>
>
> /home/ulle/gcc/native/cprog/pg1.c: In function ‘main’:
> /home/ulle/gcc/native/cprog/pg1.c:7: internal compiler error: Segmentation
> fault
When you've been adding code to GCC and you see a seg fault crop up like
this, it u
: Segmentation
fault
--
View this message in context:
http://www.nabble.com/gcc-help-needed-tp24656019p24656019.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
raja.sal...@iap-online.com writes:
>>> Is there a way to make the instruction has to allocate to run without
>>> using the scheduler for particular instruction ?
>>
>> I don't understand the question.
>
> The target we are using supports parallel instruction execution, Max 7.
> For one cycle, one
Dear Ian,
Thanks the reply.
>> Is there a way to make the instruction has to allocate to run without
>> using the scheduler for particular instruction ?
>
> I don't understand the question.
The target we are using supports parallel instruction execution, Max 7.
For one cycle, one instruction pac
raja.sal...@iap-online.com writes:
> In gcc, while instruction scheduling can it be possible to suspend the
> scheduling for some instructions ? or
No. You can turn off instruction scheduling for the entire
compilation. You can use #pragma GCC optimize to turn scheduling off
for a specific func
Hi,
In gcc, while instruction scheduling can it be possible to suspend the
scheduling for some instructions ? or
Is there a way to make the instruction has to allocate to run without
using the scheduler for particular instruction ?
Currently there is RTL template in machine description unspec_vo
Laurent GUERBY wrote:
Hi,
Someone (identified as "MatthewSimoneau") renamed
http://gcc.gnu.org/wiki/CompileFarm
to
http://gcc.gnu.org/wiki/GCC%20Compile%20Farm%20Project
Which of course broke all the web links to this project
accumulated since 2005...
The only Wiki I know is Wikipedia, wher
On Fri, 2008-12-26 at 14:04 +0100, Laurent GUERBY wrote:
> Hi,
>
> Someone (identified as "MatthewSimoneau") renamed
>
> http://gcc.gnu.org/wiki/CompileFarm
>
> to
>
> http://gcc.gnu.org/wiki/GCC%20Compile%20Farm%20Project
>
> Which of course broke all the web links to this project
> accumulat
Hi,
Someone (identified as "MatthewSimoneau") renamed
http://gcc.gnu.org/wiki/CompileFarm
to
http://gcc.gnu.org/wiki/GCC%20Compile%20Farm%20Project
Which of course broke all the web links to this project
accumulated since 2005...
The problem is that I'm unable to use the "Rename" wiki functio
[EMAIL PROTECTED] wrote on 26/02/2007 10:40:59:
>I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector
>instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit
>additions, subtractions, multiplications & shift operations
simultaneously.
>I would like to use t
gt; ---Original Message---
> From: sdutta <[EMAIL PROTECTED]>
> Subject: Auto Vectorizing help needed
> Sent: 24 Feb '07 00:13
>
> I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector
> instructions (32 bit vectors). It can perform two 1
On Fri, Feb 23, 2007 at 04:13:39PM -0800, sdutta wrote:
> I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector
> instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit
> additions, subtractions, multiplications & shift operations simultaneously.
>
> I would l
I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector
instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit
additions, subtractions, multiplications & shift operations simultaneously.
I would like to use the Auto-Vectorizing capability to generate these
instr
Jim Wilson wrote:
> Tom Williams wrote:
>> I downloaded gcc-4.1.0 the other day and the compile went fine. When I
>> ran "make check" to make sure all went well, I get this error:
>
> Always use "make -k check". Otherwise, make will exit after the first
> failure, instead of running all of the test
Tom Williams wrote:
I downloaded gcc-4.1.0 the other day and the compile went fine. When I
ran "make check" to make sure all went well, I get this error:
Always use "make -k check". Otherwise, make will exit after the first
failure, instead of running all of the testsuites.
Some failures a
Hi! I posted this on gcc-help and got no responses, so I'm trying this
list. :)
I downloaded gcc-4.1.0 the other day and the compile went fine. When I
ran "make check" to make sure all went well, I get this error:
Fixed: types/vxTypesBase.h
Fixed: unistd.h
Fixed: wchar.h
Fixed: widec.h
Newly f
Hi,
I'm adding some assembly floating point functions to bfin port. These
functions are much faster than those in fp-bit.c. However, they relax
some IEEE floating point standard rules for checking inputs against
NaN. So I think we'd better to call them only when -ffast-math or
-ffinite-math-only i
Well, shoot.
I added that and reconfigured and recompiled over night but it looks
like I need to define __powerpc64__ and currently it is not defined.
On Jan 11, 2006, at 10:17 PM, Ian Lance Taylor wrote:
Perry Smith <[EMAIL PROTECTED]> writes:
The problem: In the particular build I am tr
Perry Smith <[EMAIL PROTECTED]> writes:
> The problem: In the particular build I am trying to do, when
> libgcc2.c is compled with -DL_floatdidf, instead of defining a
> routine called _floatdidf or __floatdidf, it creates a routine called
> __floattidf which references __floatdidf.
...
> This i
I'm not sure how to present all this so bear with me:
The problem: In the particular build I am trying to do, when
libgcc2.c is compled with -DL_floatdidf, instead of defining a
routine called _floatdidf or __floatdidf, it creates a routine called
__floattidf which references __floatdidf.
On Wed, Jun 01, 2005 at 04:22:24AM -0700, sandeep nadkarni wrote:
> Hello,
Hi,
> I'm trying to migrate from open vms to Linux. I'm
> compiling programs on Linux which are running on open
> VMS
>
> I'm facing problem with int64 function.
What problem? Which function?
> my hardware configurat
Hello,
I'm trying to migrate from open vms to Linux. I'm
compiling programs on Linux which are running on open
VMS
I'm facing problem with int64 function.
my hardware configuration is P-IV 3.06 GHz
512 MB,
I'm Running Fedora Core 3 with gcc
Reading specs from
/usr/lib/gcc/i386-redhat-linux/3.4.3
- Original Message -
From: "Andrew Pinski" <[EMAIL PROTECTED]>
To: "Lloyd Dupont" <[EMAIL PROTECTED]>
Cc: "Mike Stump" <[EMAIL PROTECTED]>;
Sent: Friday, May 20, 2005 10:25 AM
Subject: Re: ASM help needed... (on x86/windows/gcc)
On May 19, 20
On May 19, 2005, at 8:10 PM, Lloyd Dupont wrote:
Simple, I'm building an ObjectiveC binding from .NET.
Basically my .NET code generator transform all objectiveC method in a
call to
objc_msg_send() (from the .NET code, which could call C directly)
the problem with _built_in_apply() is you need to
AIL PROTECTED]>
To: "Lloyd Dupont" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, May 20, 2005 9:49 AM
Subject: Re: ASM help needed... (on x86/windows/gcc)
On May 19, 2005, at 4:08 PM, Lloyd Dupont wrote:
I want to do a binding to ObjectiveC
For how you described the question, lib
7;s a real issue for method such as +stringWithFormat:... with takes
a variable number of argument
- Original Message -
From: "Andrew Pinski" <[EMAIL PROTECTED]>
To: "Mike Stump" <[EMAIL PROTECTED]>
Cc: "Lloyd Dupont" <[EMAIL PROTECTED]>;
On May 19, 2005, at 7:49 PM, Mike Stump wrote:
On May 19, 2005, at 4:08 PM, Lloyd Dupont wrote:
I want to do a binding to ObjectiveC
For how you described the question, libffi would be the natural choice
and obviates the need for asms or machine dependencies. Maybe Andrew
might have some insight
On May 19, 2005, at 4:08 PM, Lloyd Dupont wrote:
I want to do a binding to ObjectiveC
For how you described the question, libffi would be the natural
choice and obviates the need for asms or machine dependencies. Maybe
Andrew might have some insight into something libobjc specific that
might
I want to do a binding to ObjectiveC
Basically I need to implement a function like
retval_t objc_msg_send(id obj, SEL sel, ...);
which would forward its call (same arguments, including the unidentified ...
(va_list)) to an other function know by pointer which would be looked up
from the 1st 2 par
On Mon, 28 Mar 2005, Janis Johnson wrote:
> There are several workarounds in the GCC testsuite for things that could
> be better handled in DejaGnu if the next release of GCC could require a
> new DejaGnu version. That might be the right thing to do for GCC 4.1.
> Ben Elliston is the DejaGnu maint
On Sun, Mar 27, 2005 at 01:07:09PM -0800, Mike Stump wrote:
> On Sunday, March 27, 2005, at 11:58 AM, Per Bothner wrote:
> >Now I'm willing to fix those tests by adding -fno-show-column where
> >necessary
>
> Ick. I favor adding it unconditionally to compile lines over this.
> See -fmessage-le
On Sunday, March 27, 2005, at 11:58 AM, Per Bothner wrote:
Now I'm willing to fix those tests by adding -fno-show-column where
necessary
Ick. I favor adding it unconditionally to compile lines over this.
See -fmessage-length code (gcc/testsuite/lib/g++.exp) for hints. And
even that, I'm not s
On Sunday, March 27, 2005, at 11:58 AM, Per Bothner wrote:
If you run 'make check' after --enable-mapped-location (even
just --enable-languages=c) you'll find some apparant regressions.
They aren't real regressions - it's just now we now get column numbers
in some of the diagnostic messages, and t
If you run 'make check' after --enable-mapped-location (even
just --enable-languages=c) you'll find some apparant regressions.
They aren't real regressions - it's just now we now get column numbers
in some of the diagnostic messages, and this confuses dejagnu.
Now I'm willing to fix those tests by
100 matches
Mail list logo
