Re: vectorizer default in 4.3.0 changes document missing

[Ira Rosen]

Hi Andi,

[EMAIL PROTECTED] wrote on 10/03/2008 18:32:35:

>
> I noticed the gcc 4.3.0 changes document on the website does not
> mention that the vectorizer is now on by default in -O3.
> Perhaps that should be added? It seems like an important noteworthy
> change to me.

Thanks for pointing this out. The vectorizer's website was not update for a
while. I am going to do that.

>
> I'm not sure it applies to all architectures, but it applies to
> x86 at least.

Vectorization (-ftree-vectorize) is on by default in -O3 on all platforms,
but many architectures require additional flags to actually apply it, like
-maltivec on PowerPC.

Thanks,
Ira

>
> -Andi

Re: Possible GCC 4.3 driver regression caused by your patch

[Greg Schafer]

On Sun, Mar 02, 2008 at 01:17:02PM -0500, Carlos O'Donell wrote:
> Greg Schafer wrote:
> >Hi Carlos and Mark,
> >
> >Your "Relocated compiler should not look in $prefix" patch here:
> >
> >http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
> >
> >appears to have caused a regression in my GCC 4.3 testing.
> >
> >In summary, there is a small window *during the GCC build itself* where GCC
> >does not pick up the correct startfiles. For example, when GCC_FOR_TARGET 
> >is
> >called to build the target libraries, the startfiles in $prefix/lib are not
> >used. Instead, the startfiles from the host's /usr/lib are used which 
> >breaks
> >my build. Note that the problem seems to rectify itself once the just-built
> >GCC is installed into $prefix.
> >
> >Here's the scenario:
> >
> > - Native build
> > - i686-pc-linux-gnu
> > - --prefix=/temptools
> > - Glibc already installed in /temptools/lib
> 
> What options did you use to configure the compiler? Could you double 
> check your host system is actually i686-pc-linux-gnu? When you say 
> "breaks my build", what error are you seeing?

The issue is now filed as

http://gcc.gnu.org/PR35532

It would be appreciated if the responsible Codesourcery folks could address
this regression.

Thanks
Greg

gcc-4.1-20080310 is now available

[gccadmin]

Snapshot gcc-4.1-20080310 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080310/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 133096

You'll find:

gcc-4.1-20080310.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20080310.tar.bz2 C front end and core compiler

gcc-ada-4.1-20080310.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20080310.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20080310.tar.bz2  C++ front end and runtime

gcc-java-4.1-20080310.tar.bz2 Java front end and runtime

gcc-objc-4.1-20080310.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20080310.tar.bz2The GCC testsuite

Diffs from 4.1-20080303 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: GNAT on SVN Trunk

[Eric Botcazou]

> It builds now.

Thanks for the confirmation, and to H.J. for the fix.

-- 
Eric Botcazou

Re: GNAT on SVN Trunk

[Joel Sherrill]

Eric Botcazou wrote:

I think something has broken for GNU/Linux x86 in
the past week on the head.  It was building fine last
week.  Does anyone else see this?



You just need to browse Bugzilla, it's PR tree-opt/35493.
  
Thanks both of you.  It builds now. 

--
Eric Botcazou
  

--joel

Re: GNAT on SVN Trunk

[Eric Botcazou]

> I think something has broken for GNU/Linux x86 in
> the past week on the head.  It was building fine last
> week.  Does anyone else see this?

You just need to browse Bugzilla, it's PR tree-opt/35493.

-- 
Eric Botcazou

Re: GNAT on SVN Trunk

[Eric Botcazou]

> This is:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35493
>
> Patch by H.J. Lu to fix the issue was approved but not commited yet:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00466.html

It has been committed now.

-- 
Eric Botcazou

Re: GNAT on SVN Trunk

[Laurent GUERBY]

This is:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35493

Patch by H.J. Lu to fix the issue was approved but not commited yet:

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00466.html

Laurent

GNAT on SVN Trunk

[Joel Sherrill]

Hi,

I think something has broken for GNU/Linux x86 in
the past week on the head.  It was building fine last
week.  Does anyone else see this?

/home/joel/work-gnat/svn/b-native/./prev-gcc/xgcc 
-B/home/joel/work-gnat/svn/b-native/./prev-gcc/ 
-B/home/joel/work-gnat/svn//install/i686-pc-linux-gnu/bin/ -c -g -O2 
-fomit-frame-pointer  -gnatpg -gnata -nostdinc -I- -I. -Iada 
-I../../gcc/gcc/ada ../../gcc/gcc/ada/ada.ads -o ada/ada.o

+===GNAT BUG DETECTED==+
| 4.4.0 20080310 (experimental) [trunk revision 133080] 
(i686-pc-linux-gnu) |

| Assert_Failure uintp.adb:1593|
| No source file position information available|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.


compilation abandoned
make[3]: *** [ada/ada.o] Error 1

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: Combine repeats matching on insn pairs and will ICE on 3.

[hutchinsonandy]

The deed is done!

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35519

I added a patch but it needs more expertise than I have.



-Original Message-
From: Ian Lance Taylor <[EMAIL PROTECTED]>
To: Andy H <[EMAIL PROTECTED]>
Cc: GCC Development 
Sent: Mon, 10 Mar 2008 1:32 pm
Subject: Re: Combine repeats matching on insn pairs and will ICE on 3.



Andy H <[EMAIL PROTECTED]> writes:

> I have problem with data flow and combine that is causing ICE with
> experimental build. Despite all efforts to blame my own target
> changes,
> I have reached the conclusion that this is a gcc COMBINE bug, but seek
> your advice before filing a bug report.

Your analysis looks right to me.  Please do file a bug report.
Thanks.

Ian

Re: Constrain valid arguments to BIT_FIELD_REF

[Alexandre Oliva]

On Mar 10, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:

> On Mon, 10 Mar 2008, Alexandre Oliva wrote:
>> The reason SRA generates more IL is *precisely* to get better
>> optimization.  The back-ends don't handle BIT_FIELD_REFs very well.

> So I thought they can do bit-field stores...?  no?

Err...  Sorry, I didn't mean back-ends, I meant middle-end
optimization passes.  Dunno how I managed to mangle one into the
other.

>> There's a lot of code all over the compiler to simplify masking and
>> shifting that, when you use BIT_FIELD_REF, doesn't (and can't)
>> trigger.  BIT_FIELD_REF hides masks and shifts, such that the compiler
>> can't simplify them without lowering them in the first place.  And the
>> lowering is profitable.

> So, how do you recover from shifting and masking to single instruction
> bit-field stores?

You don't.  You don't open code these operations when they apply to
memory.  When they apply to gimple regs AKA pseudos, then you do, and
then various back-ends have combine patterns to recover the relevant
operations.

> It sounds easier to do from BIT_FIELD_REF and BIT_FIELD_EXPR on
> scalars.

It is easier, indeed, but it will take a lot of work to get the same
amount of optimization that we currently get, and, in order to perform
*some* simplifications, you have to either open-code them, or extend
BIT_FIELD_EXPR so as to specify a bit range to extract from the input
and *another* bit range to replace.  Such that you can combine say:

  T.1_0 = BIT_FIELD_REF ;
  y_2 = BIT_FIELD_EXPR ;

into

  y_2 = BIT_FIELD_REPLACE <3, y_1, 12, x, 5>;

With something like this you can eliminate unnecessary duplicate
shifting from x to y, which is one of the various optimizations that
the middle end can perform.  OTOH, such shift redundancy elimination
is unnecessary if a back-end offers efficient extv, extzv and insv
patterns.  But BIT_FIELD_REPLACE could expand to an extv/insv sequence
or an extzv/insv sequence (signedness doesn't matter, since we're
talking about the same number of bits in both cases), and, if such
operations aren't available, in can be expanded as two masks, a single
shift, and an or, rather than three masks and two shifts, which is
what the two-gimple-stmt above would require.


Note that BIT_FIELD_REPLACE supersedes both BIT_FIELD_REF and
BIT_FIELD_EXPR, except for the lvalue meaning of BIT_FIELD_REF:

 BIT_FIELD_REF  could be expressed as say
 BIT_FIELD_REPLACE 
 
and

  BIT_FIELD_EXPR  could be expressed as say
  BIT_FIELD_REPLACE 

And then, if we were to add another operand for the output, or express
it as an assignment that could have one of the inputs as output, we'd
have complete semantics, and then it would be "just" a matter of
teaching all of the optimization passes that track bits and shifts to
deal with BIT_FIELD_REPLACE.  This would be just as needed for
BIT_FIELD_REF and BIT_FIELD_EXPR anyway, but the fact that this hasn't
been done for BIT_FIELD_REF yet makes me think I shouldn't hold my
breath.

> SRA _does_ pessimize code in some cases.  BIT_FIELD_REF lowering
> will so as well - after all we are in target independent code.

How could it pessimize code?  BIT_FIELD_REF is just an inflexible
shorthand for the operations that end up taking place anyway.  And the
fact that it's inflexible does harm some optimizations that can be
performed with open coding, and that are recognized and performed as a
combined operation if no optimizations apply.  I get a feeling that
you're barking up the wrong tree here, but I can't claim to have
compared in detail every single instance of generated code using
BIT_FIELD_REF or open-coding it.

> But yeah, it's way easier to add things here and there than to
> make some general changes and still keep people happy :(

Yeah, I can agree that making the changes in SRA only wasn't exactly
the best approach.  When I started, I had no idea that open coding was
so necessary, and when I realized it, I had already spent way too much
time on that particular issue, and I didn't get a feeling that I'd get
buy-in for a larger revamp.  Now, since there is a revamp underway, we
might as well do it right, rather than introduce regressions just to
keep things more uniform.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: RTL definition

[Ian Lance Taylor]

"Fran Baena" <[EMAIL PROTECTED]> writes:

> 2008/3/10, Jim Wilson <[EMAIL PROTECTED]>:
>> Fran Baena wrote:
>>  > RTL represents a low-level language, machine-independent. But I didn't
>>  > find any especification of such language represented. This is, I found
>>  > no document where the language represented were described or defined
>>  > in a grammar way.
>>
>>
>> RTL isn't a programming language, and hence has no grammar.  It is
>>  merely one of the internal representations that gcc uses for optimizing
>>  and generating code.  We do have gcc internals documentation that you
>>  have already been pointed at.
>
> i agree with you, RTL is not a programming language, is a language
> that is represented internally. But it could match a grammar
> definition. And this is my question, what is the process to define a
> RTL.

RTL is a set of data structures.  It's defined by rtl.def and rtl.h.
The closest thing to a grammar for RTL is rtl.def, which defines how
each of the fields are represented given the RTL code.

By the way, RTL is not really machine-independent.  The data
structures are machine independent.  But the contents are not.  You
can not, even in principle, take the RTL generated for one processor
and compile it on another processor.

Ian

Re: Combine repeats matching on insn pairs and will ICE on 3.

[Ian Lance Taylor]

Andy H <[EMAIL PROTECTED]> writes:

> I have problem with data flow and combine that is causing ICE with
> experimental build. Despite all efforts to blame my own target
> changes,
> I have reached the conclusion that this is a gcc COMBINE bug, but seek
> your advice before filing a bug report.

Your analysis looks right to me.  Please do file a bug report.
Thanks.

Ian

Re: vectorizer default in 4.3.0 changes document missing

[Andi Kleen]

Sorry I'm not going through this now, especially not for such
a trivialty. My past experiences are that it takes several months of pings 
to get anything included and I don't have time for that now.

-Andi

Re: RTL definition

[Fran Baena]

2008/3/10, Jim Wilson <[EMAIL PROTECTED]>:
> Fran Baena wrote:
>  > RTL represents a low-level language, machine-independent. But I didn't
>  > find any especification of such language represented. This is, I found
>  > no document where the language represented were described or defined
>  > in a grammar way.
>
>
> RTL isn't a programming language, and hence has no grammar.  It is
>  merely one of the internal representations that gcc uses for optimizing
>  and generating code.  We do have gcc internals documentation that you
>  have already been pointed at.

i agree with you, RTL is not a programming language, is a language
that is represented internally. But it could match a grammar
definition. And this is my question, what is the process to define a
RTL.

Thank you

Fran

Re: vectorizer default in 4.3.0 changes document missing

[Andi Kleen]

On Mon, Mar 10, 2008 at 10:33:01AM -0700, Andrew Pinski wrote:
> On Mon, Mar 10, 2008 at 10:28 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >  Sorry you lost me. You're saying everybody can change gcc SVN now?
> 
> Anyone can submit a patch 

Well I'm not going to write it because I for once not sure on
which architectures it is true.

Anyways I already spent too much time arguing this; i was told 
to report it, not planned to get into an endless discussion
about this trivial issue. If you guys don't feel it necessary
to document feel free to not do it.

-Andi

Re: vectorizer default in 4.3.0 changes document missing

[Joe Buck]

On Mon, Mar 10, 2008 at 06:28:57PM +0100, Andi Kleen wrote:
> On Mon, Mar 10, 2008 at 10:25:11AM -0700, Andrew Pinski wrote:
> > On Mon, Mar 10, 2008 at 10:23 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mon, Mar 10, 2008 at 09:58:44AM -0700, Andrew Pinski wrote:
> > >  > On Mon, Mar 10, 2008 at 9:32 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >  > >
> > >  > >  I noticed the gcc 4.3.0 changes document on the website does not
> > >  > >  mention that the vectorizer is now on by default in -O3.
> > >  > >  Perhaps that should be added? It seems like an important noteworthy
> > >  > >  change to me.
> > >  >
> > >  > Just like with any other parts of GCC, you can check out the web docs
> > >  > and change them yourself.  Yes I agree they should be mentioned.
> > >
> > >  I don't have svn write access. Someone else will have to do it.
> > 
> > That does not mean you cannot write it :).
> 
> Sorry you lost me. You're saying everybody can change gcc SVN now?

No.  Submit a patch, and if it is approved, a maintainer (Gerald, perhaps,
since that's his area) will apply it for you.  It should go to gcc-patches
with [wwwdocs] in the beginning of the title.

Patches for the web site are treated much like patches for code: they
go to gcc-patches, and have an approval process.

Re: RTL definition

[Fran Baena]

Hi Ramana,

>  > I have read the documentation and i didn't found where it is
>  > described, maybe I searched in wrong place.
>
>
> RTL language definition is in rtl.def and gives the different
>  operators and operands. info gccint on a standard linux distribution
>  should help you figure out details about RTL .
>
>  You could look at the wiki for getting started
>
>  http://gcc.gnu.org/wiki/GettingStarted
>
>  There are links to a number of tutorials that talk about the RTL IR in
>  the wiki that you could take a look at.  I am not clear about what you
>  want to do with RTL so can't help you further.

I have read http://gcc.gnu.org/onlinedocs/gccint/RTL.html document and
I have got compiler information applying -fdump-rtl-all option. My
main doubt is how RTL is defined, this is, what it represents.
I suppose is something very close to assembler, because It has to
represent the operations between registers. But I don't know how RTL
is defined from IR. At the end, RTL represents a low-level
intermediate representation (language) that its internally represented
by a tree, but I find no place where is defined what can representate
a RTL tree node, etc.

Thanks

Fran

Re: vectorizer default in 4.3.0 changes document missing

[Andrew Pinski]

On Mon, Mar 10, 2008 at 10:28 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>  Sorry you lost me. You're saying everybody can change gcc SVN now?

Anyone can submit a patch 

-- Pinski

Re: vectorizer default in 4.3.0 changes document missing

[Andi Kleen]

On Mon, Mar 10, 2008 at 10:25:11AM -0700, Andrew Pinski wrote:
> On Mon, Mar 10, 2008 at 10:23 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Mar 10, 2008 at 09:58:44AM -0700, Andrew Pinski wrote:
> >  > On Mon, Mar 10, 2008 at 9:32 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >  > >
> >  > >  I noticed the gcc 4.3.0 changes document on the website does not
> >  > >  mention that the vectorizer is now on by default in -O3.
> >  > >  Perhaps that should be added? It seems like an important noteworthy
> >  > >  change to me.
> >  >
> >  > Just like with any other parts of GCC, you can check out the web docs
> >  > and change them yourself.  Yes I agree they should be mentioned.
> >
> >  I don't have svn write access. Someone else will have to do it.
> 
> That does not mean you cannot write it :).

Sorry you lost me. You're saying everybody can change gcc SVN now?

-Andi

Re: vectorizer default in 4.3.0 changes document missing

[Andrew Pinski]

On Mon, Mar 10, 2008 at 10:23 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 10, 2008 at 09:58:44AM -0700, Andrew Pinski wrote:
>  > On Mon, Mar 10, 2008 at 9:32 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>  > >
>  > >  I noticed the gcc 4.3.0 changes document on the website does not
>  > >  mention that the vectorizer is now on by default in -O3.
>  > >  Perhaps that should be added? It seems like an important noteworthy
>  > >  change to me.
>  >
>  > Just like with any other parts of GCC, you can check out the web docs
>  > and change them yourself.  Yes I agree they should be mentioned.
>
>  I don't have svn write access. Someone else will have to do it.

That does not mean you cannot write it :).

-- Pinski

Re: vectorizer default in 4.3.0 changes document missing

[Andi Kleen]

On Mon, Mar 10, 2008 at 09:58:44AM -0700, Andrew Pinski wrote:
> On Mon, Mar 10, 2008 at 9:32 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> >  I noticed the gcc 4.3.0 changes document on the website does not
> >  mention that the vectorizer is now on by default in -O3.
> >  Perhaps that should be added? It seems like an important noteworthy
> >  change to me.
> 
> Just like with any other parts of GCC, you can check out the web docs
> and change them yourself.  Yes I agree they should be mentioned.

I don't have svn write access. Someone else will have to do it.

-Andi

Re: -Wparentheses lumps too much together

[Derek M Jones]

All,

Developer knowledge of operator precedence and the issue of what
they intended to write are interesting topics.  Some experimental
work is described in (binary operators only I'm afraid):

www.knosof.co.uk/cbook/accu06a.pdf
www.knosof.co.uk/cbook/accu07a.pdf

The ACCU 2006 experiment provides evidence that developer knowledge
is proportional to the number of occurrences of a construct in
source code, it also shows a stunningly high percentage of incorrect
answers.

The ACCU 2007 experiment provides evidence that the names of the
operands has a significant impact on operator precedence choice.

The data from the ACCU06 experiment might be used to select a cutoff
above (ie, frequency of occurrence or developer performance) which
operator pairs will not be flagged as requiring parenthesis.

If GCC wanted to be even more selective it could look at the operand
names before deciding whether to complain.

ps.
I am always on he look out for opportunities to run experiments
using experienced developers.  Does anybody have any suggestions
for conferences I might approach?

--
Derek M. Jones  tel: +44 (0) 1252 520 667
Knowledge Software Ltd  mailto:[EMAIL PROTECTED]
Applications Standards Conformance Testinghttp://www.knosof.co.uk

Re: vectorizer default in 4.3.0 changes document missing

[Andrew Pinski]

On Mon, Mar 10, 2008 at 9:32 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>  I noticed the gcc 4.3.0 changes document on the website does not
>  mention that the vectorizer is now on by default in -O3.
>  Perhaps that should be added? It seems like an important noteworthy
>  change to me.

Just like with any other parts of GCC, you can check out the web docs
and change them yourself.  Yes I agree they should be mentioned.

Thanks,
Andrew Pinski

CRX and CR16 port maintainer

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
accepted the CR16 port for inclusion in GCC and appointed
Pompapathi Gadad as maintainer for the CRX and CR16 ports.  The initial CR16
patch needs approval from a GCC GWP maintainer before it may be committed.

Please join me in congratulating Pompa on his new role.
Please update your listing in the MAINTAINERS file.

Happy hacking!
David

New picoChip port and maintainers

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
accepted the picoChip port for inclusion in GCC and appointed
Hariharan Sandanagobalane and Daniel Towner as port maintainers.
The initial patch needs approval from a GCC GWP maintainer before it may
be committed.

Please join me in congratulating Hari and Daniel on their new role.
Please update your listing in the MAINTAINERS file.

Happy hacking!
David

vectorizer default in 4.3.0 changes document missing

[Andi Kleen]

I noticed the gcc 4.3.0 changes document on the website does not 
mention that the vectorizer is now on by default in -O3.
Perhaps that should be added? It seems like an important noteworthy
change to me.

I'm not sure it applies to all architectures, but it applies to
x86 at least.

-Andi

Re: RTL definition

[Jim Wilson]

Fran Baena wrote:

RTL represents a low-level language, machine-independent. But I didn't
find any especification of such language represented. This is, I found
no document where the language represented were described or defined
in a grammar way.


RTL isn't a programming language, and hence has no grammar.  It is 
merely one of the internal representations that gcc uses for optimizing 
and generating code.  We do have gcc internals documentation that you 
have already been pointed at.


Jim

Re: [tuples] gimple_assign_subcode for GIMPLE_SINGLE_RHS

[Richard Guenther]

On Mon, Mar 10, 2008 at 4:12 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 9, 2008 at 14:22, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
>
>  >  extract_ops_from_tree would return GIMPLE_COPY as subcode and
>  >  the whole expression as op1, where's the problem?
>
>  Sorry, I misunderstood you.  I thought you were advocating *against*
>  GIMPLE_COPY.
>
>
>  >  > I need to introduce GIMPLE_TERNARY_RHS (for ASSERT_EXPR) and
>  >  > GIMPLE_QUATERNARY_RHS (for COND_EXPR),
>  >
>  >  How are you going to represent the COND_EXPRs (i.e., where are you
>  >  going to put their comparison operator)?
>
>  Well, until 10 seconds ago, I was going to represent 'a = (b > c) ? x : y' 
> with
>
>  GIMPLE_ASSIGN 
>
>  *but* that could be confused with 'a = (b > c)', so I have to think
>  more about it.

You could either do

GIMPLE_ASSIGN 

or invent COND_GT_EXPR, COND_GE_EXPR, etc. (at least in GIMPLE
we always have a comparison in COND_EXPR_COND, never a plain
boolean variable).

Richard.

Re: [tuples] gimple_assign_subcode for GIMPLE_SINGLE_RHS

[Diego Novillo]

On Sun, Mar 9, 2008 at 14:22, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:

>  extract_ops_from_tree would return GIMPLE_COPY as subcode and
>  the whole expression as op1, where's the problem?

Sorry, I misunderstood you.  I thought you were advocating *against*
GIMPLE_COPY.

>  > I need to introduce GIMPLE_TERNARY_RHS (for ASSERT_EXPR) and
>  > GIMPLE_QUATERNARY_RHS (for COND_EXPR),
>
>  How are you going to represent the COND_EXPRs (i.e., where are you
>  going to put their comparison operator)?

Well, until 10 seconds ago, I was going to represent 'a = (b > c) ? x : y' with

GIMPLE_ASSIGN 

*but* that could be confused with 'a = (b > c)', so I have to think
more about it.


Diego.

Re: Possible gcc-4.3 regression wrt bootstrapping the toolchain

[Jonas Meyer]

On 10/03/2008, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
>  >> If you just want to build just gcc and libgcc, not any other target
>  >>  libraries, do
>  >>  make all-gcc && make all-target-libgcc
>  >>
>  > ah great. that should work. can you tell me the equivalent of 
> install-gcc,too?
>
>
> make install-gcc install-target-libgcc
>
>  Or, just configure with --disable-libmudflap if it's giving problems.

great. all-target-gcc actually works. But when trying
--disable-libmudflap instead the next thing it fails at is configuring
libiberty. I already tried --disable-libiberty which seems to not
change anything. Can I disable libiberty indirectly,maybe?

Jonas

Re: RTL definition

[Ramana Radhakrishnan]

Hi Fran,


> I have read the documentation and i didn't found where it is
> described, maybe I searched in wrong place.

RTL language definition is in rtl.def and gives the different
operators and operands. info gccint on a standard linux distribution
should help you figure out details about RTL .

You could look at the wiki for getting started

http://gcc.gnu.org/wiki/GettingStarted

There are links to a number of tutorials that talk about the RTL IR in
the wiki that you could take a look at.  I am not clear about what you
want to do with RTL so can't help you further.

If you are looking at RTL from a machine description point of view
then you could look at Machine Descriptions in the internals document.

Cheers
Ramana

Cheers
Ramana



On Mon, Mar 10, 2008 at 11:39 AM, Fran Baena <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> RTL represents a low-level language, machine-independent. But I didn't
> find any especification of such language represented. This is, I found
> no document where the language represented were described or defined
> in a grammar way. So, I 'd thank you to show me where the RTL-language
>  is defined.  Is it an assembler subset?
> I have read the documentation and i didn't found where it is
> described, maybe I searched in wrong place.
>
> Thanks all you
>



-- 
Ramana Radhakrishnan

GCC 4.3.0-20080228 (powerpc-linux-gnuspe) ICE on 20000718.c test

[Sergei Poselenov]

Hello all,

I've got the ICE on the gcc.c-torture/compile/2718.c test:
powerpc-linux-gnuspe-gcc -c -O3 -funroll-loops 2718.c
2718.c: In function 'baz':
2718.c:14: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Compilation passed OK with -mfloat-gprs=single, and fails with
-mfloat-gprs=double (compiler default).

Is this a known failure? Any fixes?


compiler details:
Target: powerpc-linux-gnuspe
Configured with: ../gcc-4.3-20080228/configure 
--target=powerpc-linux-gnuspe 
--prefix=/opt/crosstool/gcc-4.3-20080228-glibc-20070515T2025/powerpc-linux-gnuspe 
--disable-hosted-libstdcxx 
--with-headers=/opt/crosstool/gcc-4.3-20080228-glibc-20070515T2025/powerpc-linux-gnuspe/powerpc-linux-gnuspe/include 
--with-local-prefix=/opt/crosstool/gcc-4.3-20080228-glibc-20070515T2025/powerpc-linux-gnuspe/powerpc-linux-gnuspe 
--disable-nls --enable-threads=posix --enable-symvers=gnu 
--enable-__cxa_atexit --enable-languages=c,c++,java --enable-shared 
--enable-c99 --enable-long-long --without-x --with-mpfr=/usr/local 
--with-cpu=8540 --enable-cxx-flags=-mcpu=8540 --enable-e500_double


I analyzed test results for the gnuspe target; latest I found is
for 4.3.0 20080124 
(http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01187.html).


The 2718.c test passed, as I see, but I wonder how was the compiler
configured? The test target name was "reg_e500v1_ssh", so I guess the
compiler configuration was without e500 long double support (i.e. 
without -mfloat-gprs=double).


Have anyone ran the gcc testuite with e500 long double enabled?

Thanks for any help.

Regards,
Sergei

Re: Possible gcc-4.3 regression wrt bootstrapping the toolchain

[Paolo Bonzini]

If you just want to build just gcc and libgcc, not any other target
 libraries, do
 make all-gcc && make all-target-libgcc


ah great. that should work. can you tell me the equivalent of install-gcc,too?


make install-gcc install-target-libgcc

Or, just configure with --disable-libmudflap if it's giving problems.

Paolo

RTL definition

[Fran Baena]

Hi all,

RTL represents a low-level language, machine-independent. But I didn't
find any especification of such language represented. This is, I found
no document where the language represented were described or defined
in a grammar way. So, I 'd thank you to show me where the RTL-language
 is defined.  Is it an assembler subset?
I have read the documentation and i didn't found where it is
described, maybe I searched in wrong place.

Thanks all you

Re: Possible gcc-4.3 regression wrt bootstrapping the toolchain

[Jonas Meyer]

ah great. that should work. can you tell me the equivalent of install-gcc,too?
Thanks.

On 10/03/2008, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 10, 2008 at 11:57:21AM +0100, Jonas Meyer wrote:
>  > I gave it a couple more tries and I'm still pretty sure that make
>  > all-gcc was the correct way to do it. After all all the toolchain
>  > creating scripts I looked at like openwrt,buildroot and crosstools do
>  > it that way.
>  > make all fails while configuring libmudflap - telling me the c
>  > compiler couldn't create executables. Probably because the libc is not
>  > yet there. I'm building on x86_64 for a i486-linux-uclibc target.
>  > I could try building for i486-linux-glibc but I'm sure that wouldn't
>  > change anything about this problem.
>  > How should I go on about this problem?
>
>
> If you just want to build just gcc and libgcc, not any other target
>  libraries, do
>  make all-gcc && make all-target-libgcc
>
ah great. that should work. can you tell me the equivalent of install-gcc,too?
Thanks.

Re: Possible gcc-4.3 regression wrt bootstrapping the toolchain

[Jakub Jelinek]

On Mon, Mar 10, 2008 at 11:57:21AM +0100, Jonas Meyer wrote:
> I gave it a couple more tries and I'm still pretty sure that make
> all-gcc was the correct way to do it. After all all the toolchain
> creating scripts I looked at like openwrt,buildroot and crosstools do
> it that way.
> make all fails while configuring libmudflap - telling me the c
> compiler couldn't create executables. Probably because the libc is not
> yet there. I'm building on x86_64 for a i486-linux-uclibc target.
> I could try building for i486-linux-glibc but I'm sure that wouldn't
> change anything about this problem.
> How should I go on about this problem?

If you just want to build just gcc and libgcc, not any other target
libraries, do
make all-gcc && make all-target-libgcc

Jakub

Re: Possible gcc-4.3 regression wrt bootstrapping the toolchain

[Jonas Meyer]

I gave it a couple more tries and I'm still pretty sure that make
all-gcc was the correct way to do it. After all all the toolchain
creating scripts I looked at like openwrt,buildroot and crosstools do
it that way.
make all fails while configuring libmudflap - telling me the c
compiler couldn't create executables. Probably because the libc is not
yet there. I'm building on x86_64 for a i486-linux-uclibc target.
I could try building for i486-linux-glibc but I'm sure that wouldn't
change anything about this problem.
How should I go on about this problem?

Re: Constrain valid arguments to BIT_FIELD_REF

[Richard Guenther]

On Mon, 10 Mar 2008, Alexandre Oliva wrote:

> On Mar  9, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> 
> > On Sun, 9 Mar 2008, Alexandre Oliva wrote:
> >> AM33/2.0 and H8SX come to mind, although it's been a while since I
> >> dealt with the memory bit-field operations of these two ports to have
> >> the details handy.
> 
> > Ok, I would expect it a size benefit at most.
> 
> I wouldn't think so.  Turning a single hardware-optimized instruction
> into a series of load, shift, mask, combine, store is unlikely to
> benefit just size.  Especially considering that these optimized
> instructions were introduced in revisions of the processor.
> 
> And then, I've failed to see a compelling reason to justify such a
> change, that would have the effect of disabling this optimization,
> even if it was "just" a size optimization.
> 
> >> >> > Right.  By means of fixing the BIT_FIELD_REF_UNSIGNED case it is now
> >> >> > as specified above.
> >> >> 
> >> >> This doesn't make the change that went in 
> 
> >> > ?
> 
> >> ... desirable.
> 
> > To recap, what went in is a restriction to constant args 2 and 3 and
> > a result TYPE_PRECISION (in case of intergal type) or MODE_PRECISION
> > (in other cases) matching to the bit-field size in argument 2.
> 
> > The latter change made BIT_FIELD_REF_UNSIGNED redundant and (finally)
> > allows for constant folding of BIT_FIELD_REF in fold_ternary.
> 
> Good, then you didn't put in the requirement that the first argument
> must be a gimple reg, and that its type must be the same as that of
> the bit-field.  Those are the changes I object to, but you said they
> had gone in.  I couldn't find the patch that did it, but I took your
> word for it.  I'm glad it was just a misunderstanding.
> 
> As for removing BIT_FIELD_REF_UNSIGNED, I don't have much of a problem
> with it.  Using the unsignedness of the BIT_FIELD_REF type works
> AFAICT.
> 
> However, requiring a perfect match between the result type and the
> extracted bit-width is troublesome, because we don't have
> language-independent machinery to generate types with arbitrary widths
> or even arbitrary precisions.
> 
> 
> >> You make for much better optimization, at least with current
> >> handling of BIT_FIELD_REF.
> 
> >> OTOH, the much constrained version of BIT_FIELD_REF you propose will
> >> indeed only generate lots of IL for the most common case of
> >> BIT_FIELD_REF.
> 
> > It generates much less IL than what the SRA lowering currently does.
> 
> The reason SRA generates more IL is *precisely* to get better
> optimization.  The back-ends don't handle BIT_FIELD_REFs very well.

So I thought they can do bit-field stores...?  no?

> There's a lot of code all over the compiler to simplify masking and
> shifting that, when you use BIT_FIELD_REF, doesn't (and can't)
> trigger.  BIT_FIELD_REF hides masks and shifts, such that the compiler
> can't simplify them without lowering them in the first place.  And the
> lowering is profitable.

So, how do you recover from shifting and masking to single instruction
bit-field stores?

It sounds easier to do from BIT_FIELD_REF and BIT_FIELD_EXPR on
scalars.

SRA _does_ pessimize code in some cases.  BIT_FIELD_REF lowering
will so as well - after all we are in target independent code.

But yeah, it's way easier to add things here and there than to
make some general changes and still keep people happy :(

Richard.