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
> 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
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 (
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
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
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
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
60 matches
Mail list logo
