On Tue, May 18, 2010 at 2:34 AM, Andrew Haley wrote:
>> For example:
>> A textual GIMPLE tuple for the statement a=b+c can be like
>> > (As demonstrated by the internal
>> manual also).
>> Is such a representation easy to parse?
>
> S-expressions are easier to parse and more compact,
> On Mon, May 17, 2010 at 10:57:31AM -0700, Toon Moene wrote:
> > On 05/17/2010 08:08 PM, Dave Korn wrote:
> > >
> > > Hi!
> > >
> > >PR42904 is a bug where, when compiling a windows DLL using
> > > -fwhole-program,
> > > the compiler optimises away the entire library body, because there'
On 05/17/2010 09:15 PM, Sandeep Soni wrote:
> Hi,
>
> As part of GSoC 2010, I am developing a front end for GIMPLE.
> You can find the basic theme of the project at:
> http://gcc.gnu.org/wiki/GimpleFrontEnd
>
> One of the most important components in this GIMPLE Front End is to
> convert the GIMP
Michael Matz writes:
> On Mon, 17 May 2010, Ian Lance Taylor wrote:
>
>> >> Since the atomic operations are being built into the compiler, the
>> >> intent is to eventually optimize and inline them for speed... and in
>> >> the best case, simply result in a load or store. That's further work
>
Hi,
As part of GSoC 2010, I am developing a front end for GIMPLE.
You can find the basic theme of the project at:
http://gcc.gnu.org/wiki/GimpleFrontEnd
One of the most important components in this GIMPLE Front End is to
convert the GIMPLE tuples into text.
How such a textual representation shoul
Eggenmüller Bernd writes:
> Andrew Pinski schrieb:
>> On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd wrote:
>>
>>> Is there any implementation with less registers like this.
>>>
>>
>> libgcc2 is written in C; so if it fails to compile you need to fix up
>> your backend. There might
On Mon, May 17, 2010 at 10:57:31AM -0700, Toon Moene wrote:
> On 05/17/2010 08:08 PM, Dave Korn wrote:
> >
> > Hi!
> >
> >PR42904 is a bug where, when compiling a windows DLL using
> > -fwhole-program,
> > the compiler optimises away the entire library body, because there's no
> > depende
On 05/17/2010 08:08 PM, Dave Korn wrote:
Hi!
PR42904 is a bug where, when compiling a windows DLL using -fwhole-program,
the compiler optimises away the entire library body, because there's no
dependency chain related to 'main' to anchor it.
Aren't "shared library" and "whole program"
Hi!
PR42904 is a bug where, when compiling a windows DLL using -fwhole-program,
the compiler optimises away the entire library body, because there's no
dependency chain related to 'main' to anchor it.
It's pointed out that we could perhaps resolve this by inferring attribute
externally_v
On Mon, May 17, 2010 at 9:08 AM, Rathish C wrote:
> But still the soft-fp routines are not getting used. Do we need to specify
> any configure options to gcc?
>
> Also, please let me know the name of library built for soft-fp and how to
> verify that the soft-fp files are compiled and linked with
Michael Matz wrote:
Hi,
On Mon, 17 May 2010, Andrew MacLeod wrote:
The guarantees you seem to want to establish by the proposed memory model.
Possibly I misunderstood.
I'm not 100% sure on the guarantees you want to establish. The proposed
model seems to merge multiple concepts together
Andrew Pinski schrieb:
On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd wrote:
Is there any implementation with less registers like this.
libgcc2 is written in C; so if it fails to compile you need to fix up
your backend. There might need some middle-end fixes too with this
small n
Hi,
On Mon, 17 May 2010, Andrew MacLeod wrote:
> > > Well, you get the same thing you get today. Any synchronization
> > > done via a function call will tend to be correct since we never move
> > > shared memory operations across calls. Depending on your
> > > application, the types of data
On 17/05/2010 14:47, Jay K wrote:
>
>
>> Date: Mon, 17 May 2010 13:41:57 +
>> Subject: [Bug c/44166] New: -fvisibility=protected doesn't work?
Every newly-created bugzilla entry automatically sends a post to the
gcc-bugs list; there's no need to spam
Hi,
On Mon, 17 May 2010, Ian Lance Taylor wrote:
> >> Since the atomic operations are being built into the compiler, the
> >> intent is to eventually optimize and inline them for speed... and in
> >> the best case, simply result in a load or store. That's further work
> >> of course, but these
Michael Matz wrote:
Hi,
On Wed, 12 May 2010, Andrew MacLeod wrote:
Well, you get the same thing you get today. Any synchronization done
via a function call will tend to be correct since we never move shared
memory operations across calls. Depending on your application, the
types of data
Michael Matz writes:
> On Wed, 12 May 2010, Andrew MacLeod wrote:
>
>> Well, you get the same thing you get today. Any synchronization done
>> via a function call will tend to be correct since we never move shared
>> memory operations across calls. Depending on your application, the
>> types
On Mon, May 17, 2010 at 3:49 PM, Diego Novillo wrote:
> On Mon, May 17, 2010 at 09:48, Jack Howarth wrote:
>
>> It would be nice if the lto had some sort of verbose mode which
>> would show you the compiler flags being used for each object file
>> as it was processed (since there does appear to
On Mon, May 17, 2010 at 09:48, Jack Howarth wrote:
> It would be nice if the lto had some sort of verbose mode which
> would show you the compiler flags being used for each object file
> as it was processed (since there does appear to be a crude automatic
> association of compiler flags done in
On Mon, May 17, 2010 at 09:34, Richard Guenther
wrote:
> Well, something would be nice, but not magically choosing something,
> only complaining if the result won't work as expected.
Agreed. I don't think there are silver bullets here. I would like to
get to a point where:
1- The IL saved by
On Mon, May 17, 2010 at 03:34:26PM +0200, Richard Guenther wrote:
> On Mon, May 17, 2010 at 3:21 PM, Jack Howarth
> wrote:
> > On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote:
> >
> >>
> >> For example the C++ frontend sets flag_exceptions to 1 but the
> >> command-line does
> Date: Mon, 17 May 2010 13:41:57 +
> Subject: [Bug c/44166] New: -fvisibility=protected doesn't work?
> To: jay.kr...@cornell.edu
> From: gcc-bugzi...@gcc.gnu.org
>
> -fvisibility=protected doesn't work?
>
> a...@xlin2:~$ cat 1.c
> void F1() { }
> voi
On Mon, May 17, 2010 at 3:21 PM, Jack Howarth wrote:
> On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote:
>
>>
>> For example the C++ frontend sets flag_exceptions to 1 but the
>> command-line does not contain -fexceptions. Or the Fortran
>> frontend might set flag_no_signed_z
On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote:
>
> For example the C++ frontend sets flag_exceptions to 1 but the
> command-line does not contain -fexceptions. Or the Fortran
> frontend might set flag_no_signed_zeros but the command-line
> does not contain -fno-signed-zero
Hi,
On Wed, 12 May 2010, Andrew MacLeod wrote:
> Well, you get the same thing you get today. Any synchronization done
> via a function call will tend to be correct since we never move shared
> memory operations across calls. Depending on your application, the
> types of data races the option
Hi David,
Thank you for the reply.
>
> Did you include soft-fp/t-softfp in tmake_file? Please see
> gcc/config/soft-fp/t-softfp for more details about configuring GCC to
> use soft-fp.
>
Yes, I have also added the soft-fp/t-softfp to tmake_file.
I have defined the variables mentioned in
On Mon, May 17, 2010 at 2:46 PM, Diego Novillo wrote:
> On Mon, May 17, 2010 at 08:39, Richard Guenther
> wrote:
>
>> Instead of trying to record switches that way we should instead
>> save the final settings of relevant flag_* values somewhere and
>> simply complain on mismatches.
>
> What would
On Mon, May 17, 2010 at 08:39, Richard Guenther
wrote:
> Instead of trying to record switches that way we should instead
> save the final settings of relevant flag_* values somewhere and
> simply complain on mismatches.
What would be the difference? The flags are reapplied as if they had
been g
On Mon, May 17, 2010 at 2:27 PM, Diego Novillo wrote:
> On 5/16/10 23:18 , Jack Howarth wrote:
>> What is the current LTO design with regards to the
>> retention of compiler flags during the actual link
>> time optimization compilation steps. For example, if
>
> Some options are embedded, but n
On 5/16/10 23:18 , Jack Howarth wrote:
>What is the current LTO design with regards to the
> retention of compiler flags during the actual link
> time optimization compilation steps. For example, if
Some options are embedded, but not all (see lto-opts.c). You will need
to pass the same flags
On 05/17/2010 12:46 PM, Richard Guenther wrote:
On Mon, May 17, 2010 at 1:44 PM, mike wrote:
Sorry for the newbie question ...
This question is more appropriate for gcc-help.
Sorry. Wasn't sure which to send to.
You need to set your LD_LIBRARY_PATH environment to point
to the
On Mon, May 17, 2010 at 1:44 PM, mike wrote:
> Sorry for the newbie question ...
>
> I need the build process to look for libelf in /usr/lib but gmp, ppl, cloog,
> etc. in /usr/local/lib. I've tried lots of combinations of the
> flags/options listed by 'configure --help' including this:
>
>> ~/GC
Sorry for the newbie question ...
I need the build process to look for libelf in /usr/lib but gmp, ppl,
cloog, etc. in /usr/local/lib. I've tried lots of combinations of the
flags/options listed by 'configure --help' including this:
~/GCC/gcc-4.5.0/configure --program-suffix=-4.5.0
--with-l
On Mon, May 17, 2010 at 5:18 AM, Jack Howarth wrote:
> What is the current LTO design with regards to the
> retention of compiler flags during the actual link
> time optimization compilation steps. For example, if
> one is linking mixed fortran and c object files which
> have distinct flags pass
34 matches
Mail list logo
