I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx, case TRUNCATE): Respect value of
TRULY_NOOP_TRUNCATION.
Index: combine.c
==
Jan Engelhardt writes:
> I noticed that __alignof__(uint64_t) will return 8, while
> __alignof__(struct { uint64_t x; }) will give only 4. This
> run on a typical 32-bit x86 CPU (GCC config below).
>
> What I am wondering about is why GCC was coded to give different
> alignments here. If aligning
Hello All,
I am very glad that plugins are now inside the trunk.
I have configured the trunk as suggested in
http://gcc.gnu.org/ml/gcc/2009-06/msg00173.html so I invoke it as gcc-trunk
Apparently, the goal is to be able to compile (at least some) plugins
without having the GCC source tree or
I would like to change gcc so AVR C++ port will use FLASH memory instead
of SRAM to store virtual function pointers. Does anyone try to do it? I
have no experience as gcc developer, so can you head me to appropriate
files/literature about this particular problem?
TIA.
Hi, your guys:
Here is the cc1 the notation cc1 crashed:
mvx_audio_dec_mp3_test.c:112: error: unable to find a register to
spill in class 'R0_REG'
mvx_audio_dec_mp3_test.c:112: error: this is the insn:
(insn 185 134 133 6 (set (reg/f:SI 4 R4 [101])
(const_int 2076 [0x81c])) 4 {load_imm_lo
2009/6/15 Aldy Hernandez :
>> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?:
>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>> function ?make_decl_one_only?
>
> make_decl_one_only expects one argument, and that's what's being fed.
> Could you pl
2009/6/16 Rafael Espindola :
> 2009/6/15 Aldy Hernandez :
>>> ../../gcc/gcc/config/i386/winnt.c: In function
>>> ?i386_pe_encode_section_info?:
>>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>>> function ?make_decl_one_only?
>>
>> make_decl_one_only expects one argument, an
> At revision 148493 decl_one_only was changed to take 2 arguments.
> Looks like I missed winnt.c.
148492 actually. Fixed in revision 148523:
2009-06-16 Rafael Avila de Espindola
* config/i386/winnt.c (i386_pe_encode_section_info): Update call to
make_decl_one_only.
Cheers,
2009/6/16 Rafael Espindola :
>> At revision 148493 decl_one_only was changed to take 2 arguments.
>> Looks like I missed winnt.c.
>
> 148492 actually. Fixed in revision 148523:
>
>
> 2009-06-16 Rafael Avila de Espindola
>
> * config/i386/winnt.c (i386_pe_encode_section_info): Update call
Basile STARYNKEVITCH wrote:
Can a branch be simply a plugin, or should I close (soon) the
melt-branch and start a melt-plugin-branch on the SVN. If I do that,
do I need some authorization? from whom?
Apparently, nothing very special is required to start a new branch. So I
intend to creat
On Tue, Jun 16, 2009 at 1:13 PM, Basile
STARYNKEVITCH wrote:
> Basile STARYNKEVITCH wrote:
>>
>>
>> Can a branch be simply a plugin, or should I close (soon) the melt-branch
>> and start a melt-plugin-branch on the SVN. If I do that, do I need some
>> authorization? from whom?
>
>
> Apparently, not
Richard Guenther wrote:
On Tue, Jun 16, 2009 at 1:13 PM, Basile
STARYNKEVITCH wrote:
Basile STARYNKEVITCH wrote:
Can a branch be simply a plugin, or should I close (soon) the melt-branch
and start a melt-plugin-branch on the SVN. If I do that, do I need some
authorization? from whom?
On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote:
> I thought on the contrary that is was expected that some code would become FSF
> owned plugins?
Not without a mechanism for linking plugins in statically on hosts for
which we don't support dynamic loading of plugins, and even then it's
doubtfu
Rafael Espindola wrote:
> 2009/6/15 Aldy Hernandez :
>>> ../../gcc/gcc/config/i386/winnt.c: In function
>>> ?i386_pe_encode_section_info?:
>>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>>> function ?make_decl_one_only?
>> make_decl_one_only expects one argument, and that's
> Apparently, the goal is to be able to compile (at least some) plugins
> without having the GCC source tree or build tree.
Correct.
> However, I believe we don't have any documentation stating that. At least
> not in http://gcc.gnu.org/onlinedocs/gccint/Plugins.html and not in
> http://gcc.gnu.o
(trying again)
Hi, all. I have a basic question about GENERIC trees.
I'm playing with writing a front end, and find the distinction between
BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying
to get a handle on how to represent a function in GENERIC form.
On the surface the
Hi, again,
I am a little unclear on VAR_DECL and DECL_EXPR. The impression I get
from reading the docs is that when a variable is first declared in a
function, a VAR_DECL should be created, possibly with DECL_INITIAL()
set.
What's less clearly stated is what you use for variable references later
> This is ok, too. I assume you have done a regression test? ;)
On the fix patch? The file would not build without it
I did test the original patch, but missed the winnt file.
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dubl
I (Basile) very probably misunderstood what Joseph Myers or Richard
Guenther meant. What I might have [mis]understood scares me. This is a
request for clarification.
Joseph S. Myers wrote:
On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote:
I thought on the contrary that is was expected
Rafael Espindola wrote:
>> This is ok, too. I assume you have done a regression test? ;)
>
> On the fix patch? The file would not build without it
>
> I did test the original patch, but missed the winnt file.
>
> Cheers,
I did look at the file myself, but couldn't tell (without studying y
Rafael Espindola wrote: (citing me Basile)
Apparently, the goal is to be able to compile (at least some) plugins
without having the GCC source tree or build tree.
Correct.
However, I believe we don't have any documentation stating that. At least
not in http://gcc.gnu.org/onlinedocs/gc
On Tue, Jun 16, 2009 at 1:50 PM, Jerry Quinn wrote:
> (trying again)
> Hi, all. I have a basic question about GENERIC trees.
>
> I'm playing with writing a front end, and find the distinction between
> BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying
> to get a handle on ho
On Tue, Jun 16, 2009 at 2:14 PM, Jerry Quinn wrote:
> Hi, again,
>
> I am a little unclear on VAR_DECL and DECL_EXPR. The impression I get
> from reading the docs is that when a variable is first declared in a
> function, a VAR_DECL should be created, possibly with DECL_INITIAL()
> set.
>
> What's
On Tue, Jun 16, 2009 at 2:22 PM, Basile
STARYNKEVITCH wrote:
>
> I (Basile) very probably misunderstood what Joseph Myers or Richard Guenther
> meant. What I might have [mis]understood scares me. This is a request for
> clarification.
>
>
> Joseph S. Myers wrote:
>
>
>> On Tue, 16 Jun 2009, Basile
On Tue, Jun 16, 2009 at 2:23 PM, Bingfeng Mei wrote:
> Hello,
>
> I came across a function renaming issue in GCC 4.4.
>
> ~/work/install-x86/bin/gcc -Wall -Winline -O3 -g -D_FILE_OFFSET_BITS=64
> -save-temps -c bzip2.c -fdump-tree-all
>
>
> Function saveInputFileMetaInfo is renamed to T.251 after
Is it possible to restore the original name if the copy propagation is not
profitable and doesn't go ahead?
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 16 June 2009 13:56
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Questionable f
On Tue, Jun 16, 2009 at 3:01 PM, Bingfeng Mei wrote:
> Is it possible to restore the original name if the copy propagation is not
> profitable and doesn't go ahead?
The calling convention is changed, so I don't see how this is
easily possible.
Richard.
>> -Original Message-
>> From: Ric
On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote:
> > > I thought on the contrary that is was expected that some code would become
> > > FSF
> > > owned plugins?
> > >
> >
> > Not without a mechanism for linking plugins in statically on hosts for which
> > we don't support dynamic loading of
On Tue, 2009-06-16 at 14:43 +0200, Richard Guenther wrote:
> BIND_EXPRs are containers for local variables in the GENERIC
> function body (they persist until GIMPLE is lowered). BLOCKs
> represent the scope tree of the function (which also refers to
> local variables). The BLOCK tree is kept live
daniel tian writes:
> mvx_audio_dec_mp3_test.c:112: error: unable to find a register to
> spill in class 'R0_REG'
> mvx_audio_dec_mp3_test.c:112: error: this is the insn:
> (insn 185 134 133 6 (set (reg/f:SI 4 R4 [101])
> (const_int 2076 [0x81c])) 4 {load_imm_low_si} (nil)
> (expr_lis
On 06/15/2009 01:22 PM, Bernie Innocenti wrote:
On 06/15/09 16:28, Rafael Espindola wrote:
It fails with
$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'
$ git fetch
fatal: refs/remotes/origin/gcc-4_0-branch tracks both
refs/remotes/gcc-4_0-branch and refs/heads/gc
On Tue, Jun 16, 2009 at 10:17 AM, Jason Merrill wrote:
> On 06/15/2009 01:22 PM, Bernie Innocenti wrote:
>>
>> On 06/15/09 16:28, Rafael Espindola wrote:
>>>
>>> It fails with
>>>
>>> $ git config --add remote.origin.fetch
>>> '+refs/remotes/*:refs/remotes/origin/*'
>>> $ git fetch
>>> fatal: refs/
Thanks, I didn't notice both functions have different arguments after
transformation.
However, gprof produces T.251 in its statistics, completely unknown
to user. Could GCC use more informative name here, e.g.,
saveInputFileMetaInfo.251?
50.01 0.01 0.01 24 0.42 0.42 BZ2
On Tue, Jun 16, 2009 at 3:19 PM, Jerry Quinn wrote:
> On Tue, 2009-06-16 at 14:43 +0200, Richard Guenther wrote:
>> BIND_EXPRs are containers for local variables in the GENERIC
>> function body (they persist until GIMPLE is lowered). BLOCKs
>> represent the scope tree of the function (which also r
On Tue, Jun 16, 2009 at 3:49 PM, Bingfeng Mei wrote:
> Thanks, I didn't notice both functions have different arguments after
> transformation.
> However, gprof produces T.251 in its statistics, completely unknown
> to user. Could GCC use more informative name here, e.g.,
> saveInputFileMetaInfo.2
Hi,
On Tue, Jun 16, 2009 at 06:49:58AM -0700, Bingfeng Mei wrote:
> Thanks, I didn't notice both functions have different arguments after
> transformation.
> However, gprof produces T.251 in its statistics, completely unknown
> to user. Could GCC use more informative name here, e.g.,
> saveInp
Adam Nemet writes:
> I am trying to understand the checkin by Jeff Law from about 11 years ago:
>
>r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
>
>
>* combine.c (simplify_rtx, case TRUNCATE): Respect value of
>TRULY_NOOP_TRUNCATION.
>
Tomasz Francuz writes:
> I would like to change gcc so AVR C++ port will use FLASH memory
> instead of SRAM to store virtual function pointers. Does anyone try to
> do it? I have no experience as gcc developer, so can you head me to
> appropriate files/literature about this particular problem?
T
On Tue, Jun 16, 2009 at 04:34:01PM +0200, Martin Jambor wrote:
> Hi,
>
> On Tue, Jun 16, 2009 at 06:49:58AM -0700, Bingfeng Mei wrote:
> > Thanks, I didn't notice both functions have different arguments after
> > transformation.
> > However, gprof produces T.251 in its statistics, completely un
Jerry Quinn writes:
> There is also DECL_EXPR representing local declarations, which appears
> to be related. How do these get used and would it even be used in a
> C-like language?
The VAR_DECL is simply stored in the BLOCK, but in C++, C99, and GNU89,
not all variables are declared at the sta
Incidentally, I notice that branches in subdirectories of branches/ are
still broken; i.e. ARM apple redhat suse ubuntu, maybe others. I give
instructions on the GitMirror page for how to deal with that, but I
wonder if it's possible to set it up properly on the mirror instead.
Jason
On Mon, Jun 15, 2009 at 2:18 PM, NightStrike wrote:
> On Mon, Jun 15, 2009 at 2:05 PM, Aldy Hernandez wrote:
>>> ../../gcc/gcc/config/i386/winnt.c: In function
>>> ?i386_pe_encode_section_info?:
>>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>>> function ?make_decl_one_only
On Tue, 2009-06-16 at 14:22 +0200, Basile STARYNKEVITCH wrote:
> I (Basile) very probably misunderstood what Joseph Myers or Richard
> Guenther meant. What I might have [mis]understood scares me. This is a
> request for clarification.
> Did I understood that in your view no branch hosted on GCC
On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote:
> Basile, people are saying that MELT no longer belongs in a branch of
> the GCC repository because now that plug-ins are supported, MELT no
> longer needs to modify GCC itself and can be maintained independently.
> That does not mean that MELT c
Diego Novillo wrote:
On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote:
Basile, people are saying that MELT no longer belongs in a branch of
the GCC repository because now that plug-ins are supported, MELT no
longer needs to modify GCC itself and can be maintained independently.
MELT is n
On Tue, 16 Jun 2009, Janis Johnson wrote:
> Basile, people are saying that MELT no longer belongs in a branch of
> the GCC repository because now that plug-ins are supported, MELT no
> longer needs to modify GCC itself and can be maintained independently.
> That does not mean that MELT cannot be a
2009/6/16 Ian Lance Taylor :
> Tomasz Francuz writes:
>
>> I would like to change gcc so AVR C++ port will use FLASH memory
>> instead of SRAM to store virtual function pointers. Does anyone try to
>> do it? I have no experience as gcc developer, so can you head me to
>> appropriate files/literatu
Daniel Berlin wrote:
> pre-globals-git and restrict-git were test branches from an old mostly
> broken version. ;)
>
> They are dead and if someone wants to manually remove the refs, go for it.
> No idea what oldmaster is.
Done.
>> And why have both
>> "master" and "trunk" as heads?
>
> See "
> This question would be more appropriate for the mailing list
> gcc-h...@gcc.gnu.org than for g...@gcc.gnu.org. Please take any
> followups to gcc-help. Thanks.
>
> Virtual tables will normally be placed in the .rodata section which
> holds read-only data. All you should need to do it arrange
Ian Lance Taylor writes:
> I agree that this patch looks wrong in todays compiler. There should be
> no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow.
Thanks.
Do you think we can assume this for TRUNCATEs in general or only for MIPS-like
TRUNCATEs?
I can't think of why it w
Snapshot gcc-4.4-20090616 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090616/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Zoltán Kócsi writes:
> So it is indeed a valid compiler issue, not an incompetent user issue.
> Probably an improvement request would be the best.
Thanks for the details on the AVR.
The question of gcc vs. gcc-help is not one of compiler issues
vs. incompetent user issues. Many highly competen
Adam Nemet writes:
> Ian Lance Taylor writes:
>> I agree that this patch looks wrong in todays compiler. There should be
>> no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow.
>
> Thanks.
>
> Do you think we can assume this for TRUNCATEs in general or only for MIPS-like
> TRUN
>
> One thing you certainly need to do is set REG_ALLOC_ORDER so that r0 is
> the last register allocated.
>
> You need to set TARGET_RTX_COSTS so that constants larger than 512 are
> more expensive than registers. That should prevent the constant from
> being propagated into the insn.
Yeah. I 'v
Adam Nemet wrote:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx, case TRUNCATE): Respect value of
TRULY_NOOP_TRUNCATION.
Index
Ian Lance Taylor wrote:
Adam Nemet writes:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx, case TRUNCATE): Respect value of
TRULY_NO
Hi all,
As we see from gcc doc, the builtins are intended to be compatible
with those described in the Intel Itanium Processor-specific
Application Binary Interface, section 7.4. Why did gcc for x86 miss
expanding such built-ins, just generating a call to an external
function? Is it on purpose or
Lijuan Hai writes:
> As we see from gcc doc, the builtins are intended to be compatible
> with those described in the Intel Itanium Processor-specific
> Application Binary Interface, section 7.4. Why did gcc for x86 miss
> expanding such built-ins, just generating a call to an external
> function
I got my first main program built in multi-source mode running.
The ALI file and debug-info generation isn't perfect yet; also I'm
using raw gnat1 as gnatmake is not yet adapted to multi-source mode.
Oliver
gnat1_multi_demo.tgz
Description: application/compressed-tar
genrecog uses strings to keep track of where it is, specifically,
digits and letters. I've got an insn that writes to more than 26
registers. Would switching to something bigger than [A-Z] be
difficult? Perhaps using Japanese letters instead of English? ;-)
> Pending initial (technical) approval
Ping? Still waiting for technical approval from a global maintainer.
http://people.redhat.com/dj/mep/
Jeff Law writes:
> Ian Lance Taylor wrote:
> > Adam Nemet writes:
> >
> >
> >> I am trying to understand the checkin by Jeff Law from about 11 years ago:
> >>
> >>r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
> >>
> >>
> >>* combine.c (simplify_rt
Ian Lance Taylor writes:
> truncate has a machine independent meaning.
Yes, I guess with your definition below it does. It's interesting though that
Jim had said the opposite in the excerpts posted by Jeff:
And a later message from Jim:
Truncate converts a value from a larger to a smaller
63 matches
Mail list logo
