Hello Darwin port maintainers,
I'm getting the frontend for the Go programming language to work in
Darwin. I encountered what looks like a bug in Darwin-specific gcc
code.
The Go frontend saves language-specific export information in the
object file inside a special section. This works fine in
Taras Glek wrote:
On 07/01/2010 02:45 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 11:36 PM, Taras Glek wrote:
On 07/01/2010 02:27 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glekwrote:
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual si
>> When you compile with -Os, the inlining happens only when code size reduces.
>> Thus we pretty much care about the code size metrics only. I suspect the
>> problem here might be that normal C++ code needs some inlining to make
>> abstraction penalty go away. GCC -Os implementation is generally
Jonathan Wakely wrote:
> Thanks. There's no need to post it to this mailing list too, bugzilla
> changes already go to the gcc-bugs mailing list where people can track
> new bug reports.
Oh, sorry ;)
[]s,
rod
On 1 July 2010 22:27, Rodolfo Schulz de Lima wrote:
>
> I've created ticket #44753 to track this issue.
Thanks. There's no need to post it to this mailing list too, bugzilla
changes already go to the gcc-bugs mailing list where people can track
new bug reports.
Snapshot gcc-4.5-20100701 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100701/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Quoting Richard Guenther :
That is, we no longer optimistically assume that comdat functions
can be eliminated if there are no callers in the local TU in 4.5
(but we did in previous releases).
But if the function is very simple, the only reason to keep it would be
if its address was taken some
On 07/01/2010 02:45 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 11:36 PM, Taras Glek wrote:
On 07/01/2010 02:27 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glekwrote:
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where
On Thu, Jul 1, 2010 at 11:36 PM, Taras Glek wrote:
> On 07/01/2010 02:27 PM, Richard Guenther wrote:
>>
>> On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
>>>
>>> On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where -Os is losing size and
spee
On 07/01/2010 02:27 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where -Os is losing size and speed
we can try
to do something about them.
According to our code size reports,
Hello, I've posted a message to comp.gcc.help with a compiler error I'm
having but after some testing me and others found out is a regression on
gcc-4.5, the code is the following:
// ---
template
struct identity
{
typedef T type;
};
template
struct foo {};
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
> On 06/30/2010 03:06 PM, Jan Hubicka wrote:
>>
>> If you can find actual simple examples where -Os is losing size and speed
>> we can try
>> to do something about them.
>>
>
> According to our code size reports, inlining is completely screwed for
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where -Os is losing size and speed we
can try
to do something about them.
According to our code size reports, inlining is completely screwed for
C++ wrapper classes like ones often used for smart pointers, arr
Joern Rennecke wrote:
[gcc plugins rely on ELF features and therefore don't work on MS windows]
Quoting David Brown :
In reality, if embedded developers are unhappy (for whatever reason)
with running gcc on Windows, they will move to proprietary compilers
under windows - not gcc on Linux.
Of
ad...@icybersurfer.com writes:
> I heard of GCC complier and that its a major complier for Playstation
> systems.
>
> As Nintendo has Wii, and Xbox 360 is coming out with Kinect, Playstation
> is coming up with Playstation Move. My question is, can I comply a game
> with GCC to be compatible with
Joern Rennecke writes:
> So, back to the original question. Is this a suitable bootstrap substitute
> for testing patches?
I think it can be. You have to use good judgment, of course. I know
you know this, but if the patch is going to change the generated code on
a specific target, then a boo
On Thu, Jul 1, 2010 at 5:30 PM, Richard Earnshaw wrote:
>
> On Wed, 2010-06-16 at 08:09 -0700, Andrew Pinski wrote:
>>
>> Sent from my iPhone
>>
>> On Jun 16, 2010, at 6:04 AM, Richard Guenther > > wrote:
>>
>> > On Wed, Jun 16, 2010 at 5:52 PM, Siarhei Siamashka
>> > wrote:
>> >> Hello,
>> >>
>
Dear GNU,
I heard of GCC complier and that its a major complier for Playstation
systems.
As Nintendo has Wii, and Xbox 360 is coming out with Kinect, Playstation
is coming up with Playstation Move. My question is, can I comply a game
with GCC to be compatible with Playstation Move, or is it that
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: 01 July 2010 16:27
> To: Richard Guenther
> Cc: Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Convert cross reference table to resolution file for LTO
>
> Hi,
>
> On Thu, 1 Jul 2010, Richard Guenther wro
On 06/30/2010 04:21 PM, Jan Hubicka wrote:
>> Long term we could arrange for libbackend.a to become libbackend.dll and
>> have that library be used for plugins. The existing practice of linking
>> back into the main executable is more or less an efficiency hack that
>> happens to work with ELF.
>
On Wed, 2010-06-16 at 08:09 -0700, Andrew Pinski wrote:
>
> Sent from my iPhone
>
> On Jun 16, 2010, at 6:04 AM, Richard Guenther > wrote:
>
> > On Wed, Jun 16, 2010 at 5:52 PM, Siarhei Siamashka
> > wrote:
> >> Hello,
> >>
> >> Currently gcc (at least version 4.5.0) does a very poor job
>
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 01 July 2010 16:13
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Convert cross reference table to resolution file for LTO
>
> On Thu, Jul 1, 2010 at 5:02 PM, Bingfeng Mei wro
Hi,
On Thu, 1 Jul 2010, Richard Guenther wrote:
> Does --cref work with .comm symbols properly (listing the biggest one
> first)?
Unfortunately no.
(I find it mildly ugly to make collect2 act as a file filter. Why
shouldn't the --cref parser be implemented in the lto frontend, next to
the r
On Thu, Jul 1, 2010 at 5:02 PM, Bingfeng Mei wrote:
> Hi,
> I did some experiments to convert cross-reference table
> to resolution files. Patches are attached and still crude.
>
> The initial idea is to have as little as possible change
> in GNU LD. It turns out that cross reference table doesn't
Hi,
I did some experiments to convert cross-reference table
to resolution files. Patches are attached and still crude.
The initial idea is to have as little as possible change
in GNU LD. It turns out that cross reference table doesn't
always print out definition at the first line. So
some chan
Quoting Paolo Bonzini :
--enable-werror-always is today what you're looking for, I think.
I just tried, and it seems to work for my i686-pc-linux-gnu X ia64-linux-gnu
build. Not only did it supply -Werror, make all-gcc already completed,
while the bootstrap on gcc60 has been chugging along fr
[gcc plugins rely on ELF features and therefore don't work on MS windows]
Quoting David Brown :
In reality, if embedded developers are unhappy (for whatever reason)
with running gcc on Windows, they will move to proprietary compilers
under windows - not gcc on Linux.
Of course, this is not a p
On 07/01/2010 03:34 PM, Joern Rennecke wrote:
Quoting Paolo Bonzini :
On 07/01/2010 03:26 PM, Joern Rennecke wrote:
Well, what we want for a bootstrap replacement is that it gives
errors for everything where a bootstrap gives errors.
--enable-werror-always?
No, we don't want -Werror for
Quoting Paolo Bonzini :
On 07/01/2010 03:26 PM, Joern Rennecke wrote:
Well, what we want for a bootstrap replacement is that it gives errors
for everything where a bootstrap gives errors.
--enable-werror-always?
No, we don't want -Werror for files that are excluded from -Werror for
a boot
On 07/01/2010 03:26 PM, Joern Rennecke wrote:
Quoting Paolo Bonzini :
Sorry, I meant that it should not give any warning, not that -Werror is
in use.
Well, what we want for a bootstrap replacement is that it gives errors
for everything where a bootstrap gives errors.
--enable-werror-always?
On Thu, Jul 1, 2010 at 3:23 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> Re-compiling the same plugin sources for different gcc versions is
>> not supported. Of course you might be lucky for minor version
>> changes such as 4.5.3 to 4.5.4.
>
> I think that's putting it a bit too st
Quoting Paolo Bonzini :
Sorry, I meant that it should not give any warning, not that -Werror is
in use.
Well, what we want for a bootstrap replacement is that it gives errors
for everything where a bootstrap gives errors.
Quoting Richard Guenther :
Re-compiling the same plugin sources for different gcc versions is
not supported. Of course you might be lucky for minor version
changes such as 4.5.3 to 4.5.4.
I think that's putting it a bit too strong. If the maintainer of a plugin
cares about the plugin working
On 07/01/2010 02:57 PM, Joern Rennecke wrote:
Quoting Paolo Bonzini :
On 07/01/2010 02:27 PM, Joern Rennecke wrote:
When risks of the patch mostly involve type checking or things that
could be caught with a simple compilation, could we relax this
testing requirement to do a cross-build of all-
On Thu, Jul 1, 2010 at 2:48 PM, David Brown wrote:
> I was perhaps over-generalising - obviously anything that depends on target
> specifics will be dependent on the target. And I'd also expect some things
> to change in the plugin interface between major gcc versions - while it
> would be nice t
Quoting Paolo Bonzini :
On 07/01/2010 02:27 PM, Joern Rennecke wrote:
When risks of the patch mostly involve type checking or things that
could be caught with a simple compilation, could we relax this
testing requirement to do a cross-build of all-gcc all-target-libgcc
with a recent fully boots
Hello all, hello Richard and thank you for your help.
On Wed, 30.06.2010 08:57, Richard Henderson wrote:
> On 06/30/2010 05:06 AM, M. -Eqbal Maraqa wrote:
> > f1.c:5:1: error: unrecognizable insn:
> > (insn 12 11 13 3 f1.c:4
> >(set (mem/c/i:SI (reg/f:SI 23 [ D.1964 ]) [0 +0 S4 A32])
>
On 01/07/2010 12:14, Joern Rennecke wrote:
Quoting David Brown :
But it strikes me that a system where the main programs and the plugins
are directly linking to each other is going to make it hard to separate
the development of the two sides, and hard to distribute compiled
plugins that will wo
On 06/30/2010 11:18 PM, Basile Starynkevitch wrote:
How do distributions makers achieve that?? IIRC they have a strict rule
that no compilation or build should run under root!
You use "make install DESTDIR=`pwd`/buildroot" and then copy the
contents of the buildroot into the real root (e.g. w
On 07/01/2010 02:27 PM, Joern Rennecke wrote:
When risks of the patch mostly involve type checking or things that
could be caught with a simple compilation, could we relax this
testing requirement to do a cross-build of all-gcc all-target-libgcc
with a recent fully bootstrapped compiler, with -We
On Thu, 01 Jul 2010 07:57:59 EDT
ken...@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:
> I disagree. From what I see of the industry and its practices, I think the
> risk of an attack on Free Software due to lack of providence issues is
> INCREASING, not decreasing. As FLOSS software makes more and
> If someone used a fake name when explicitly asked for a real name,
> why should I trust him to not violate copyright?
I agree. Remember that we're working mostly on trust here: the
indemnification isn't worth anything at all from an individual since they
don't have any assets to back it up.
We generally require bootstraps for patches to native-capable targets.
This is quite time consuming for targets like rs6000 or ia64 where
the available machines in the compile farm are have low processing speed
and/or memory, and for rs6000 also suffer issues with mpc / gmp / mpfr
libraries
and
Richard Kenner wrote:
I do understand the rationale for the FSF's desire to hold copyright,
and have a paper trail. But, at this point, I think that's making it
harder to people to participate, and with no real benefit. The FSF is
clinging to an outmoded policy due to a single occurrence from l
> I do understand the rationale for the FSF's desire to hold copyright,
> and have a paper trail. But, at this point, I think that's making it
> harder to people to participate, and with no real benefit. The FSF is
> clinging to an outmoded policy due to a single occurrence from long ago.
I disa
On 06/30/2010 09:43 PM, NightStrike wrote:
On Wed, Jun 30, 2010 at 3:24 PM, David Edelsohn wrote:
He understood your point very well. That is why Frank said, "You
falsely presume zero vetting."
Maybe I didn't get the zero vetting part, then. I thought I did, but
apparently not. What does t
On 1 July 2010 12:14, Joern Rennecke wrote:
>
>> And it should be possible to
>> build the plugin binary for Linux, Window s (native/mingw, not just
>> cygwin) and other major gcc hosts (Mac, BSDs, etc.). Like it or not, a
>> great deal of cross-compilation embedded development is done using gcc
Quoting David Brown :
But it strikes me that a system where the main programs and the plugins
are directly linking to each other is going to make it hard to separate
the development of the two sides, and hard to distribute compiled
plugins that will work with separately compiled main binaries.
On 01/07/2010 00:46, Dave Korn wrote:
On 30/06/2010 21:38, Kyle Girard wrote:
Hello,
I am playing around with a plug-in for gcc but recently ran into the
road block that plug-ins aren't supported on Windows. Are there any
plans to add support for the windows platform in the future? If not,
wh
(Apologies if you receive multiple copies of this announcement)
CGO 2011 - CALL FOR PAPERS
Ninth Annual IEEE/ACM International Symposium on Code Generation
and Optimization (CGO 2011)
April 2-6, 2011, Chamonix, France
http://www.cgo.org
The International Symposium on C
50 matches
Mail list logo
