On 14/06/2010 06:43, Ian Lance Taylor wrote:
David Browndavid.br...@hesbynett.no writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases where LTO is used. You use
-flto when compiling each source file, then link them with gcc with
On 14/06/2010 05:43, Ian Lance Taylor wrote:
David Brown david.br...@hesbynett.no writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases where LTO is used. You use
-flto when compiling each source file, then link them with gcc
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Ian Lance Taylor
Sent: 14 June 2010 05:43
To: David Brown
Cc: gcc@gcc.gnu.org
Subject: Re: Issue with LTO/-fwhole-program
David Brown david.br...@hesbynett.no writes:
After doing
On 14/06/2010 11:22, Dave Korn wrote:
On 14/06/2010 05:43, Ian Lance Taylor wrote:
David Browndavid.br...@hesbynett.no writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases where LTO is used. You use
-flto when compiling each
On Mon, Jun 14, 2010 at 9:26 AM, David Brown da...@westcontrol.com wrote:
On 14/06/2010 06:43, Ian Lance Taylor wrote:
David Browndavid.br...@hesbynett.no writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases where LTO is used.
On Mon, Jun 14, 2010 at 11:27 AM, David Brown da...@westcontrol.com wrote:
On 14/06/2010 11:22, Dave Korn wrote:
On 14/06/2010 05:43, Ian Lance Taylor wrote:
David Browndavid.br...@hesbynett.no writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will
Bingfeng Mei b...@broadcom.com writes:
Actually, gold plugin is used in the original example. However, resolution
produced by plugin is bypassed due to a bug-fix by Richard. Do you have any
comment on that:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01116.html
Sorry, I missed that. There
Richard Guenther richard.guent...@gmail.com writes:
Commons between shared libraries and a program can't work.
Technically speaking, shared libraries never have common symbols.
They can have defined symbols which are labelled as, in essence,
formerly common, and those can be made to work
On 12/06/2010 16:52, Richard Guenther wrote:
On Sat, Jun 12, 2010 at 3:32 PM, David Browndavid.br...@hesbynett.no wrote:
Ian Lance Taylor wrote:
Manuel López-Ibáñezlopeziba...@gmail.com writes:
This also means that linking your program with non-LTO+whole-program
code may lead to
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common
symbols.
Ian
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common
symbols.
Well
On Sun, 13 Jun 2010, Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code,
Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common
On 13/06/2010 23:22, David Brown wrote:
I agree that banning common symbols is not a complete solution. But
perhaps it may be a partial solution until some more complete solution
is found and implemented?
How about having a warning flag -Wcommon-lto
Incidentally, the original poster
On 13/06/2010 23:20, Joseph S. Myers wrote:
On Sun, 13 Jun 2010, Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We
On Mon, 14 Jun 2010, Dave Korn wrote:
On 13/06/2010 23:20, Joseph S. Myers wrote:
On Sun, 13 Jun 2010, Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown da...@westcontrol.com writes:
If -flto were to activate the -fno-common flag, would that then catch
Dave Korn wrote:
On 13/06/2010 23:22, David Brown wrote:
I agree that banning common symbols is not a complete solution. But
perhaps it may be a partial solution until some more complete solution
is found and implemented?
How about having a warning flag -Wcommon-lto
Incidentally, the
David Brown david.br...@hesbynett.no writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases where LTO is used. You use
-flto when compiling each source file, then link them with gcc with
-flto and -fwhole-program. Except in the
On 12 June 2010 01:27, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost
Ian Lance Taylor wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
This also means that linking your program with non-LTO+whole-program
code may lead to miscompilations without any warning, which is really
bad. I don't think it is a reasonable limitation and we will get bad
press when
On Sat, Jun 12, 2010 at 3:32 PM, David Brown david.br...@hesbynett.no wrote:
Ian Lance Taylor wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
This also means that linking your program with non-LTO+whole-program
code may lead to miscompilations without any warning, which is really
David Brown david.br...@hesbynett.no writes:
Assuming I'm correct here, then perhaps there could be a warning or
error message that is triggered by breaking the ODR, and which could
be enabled automatically by the -flto flag. Perhaps existing checking
mechanisms from C++ can be used here.
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther
On 11 June 2010 14:40, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
On Fri, Jun 11, 2010 at 2:57 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:40, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther
On 11/06/2010 13:59, Richard Guenther wrote:
Well, we can't. We specifically support mixed LTO/non LTO objects
(think of shared libraries for example). With the linker-plugin and gold
we can do better, but with just GNU ld and collect2 we can't.
Well then shouldn't we warn if
On Fri, Jun 11, 2010 at 3:21 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
On 11/06/2010 13:59, Richard Guenther wrote:
Well, we can't. We specifically support mixed LTO/non LTO objects
(think of shared libraries for example). With the linker-plugin and gold
we can do better, but with
...@gmail.com]
Sent: 11 June 2010 14:21
To: Richard Guenther
Cc: Manuel López-Ibáñez; Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka
Subject: Re: Issue with LTO/-fwhole-program
On 11/06/2010 13:59, Richard Guenther wrote:
Well, we can't. We specifically support mixed LTO/non LTO objects
(think
To: Richard Guenther
Cc: Manuel López-Ibáñez; Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka
Subject: Re: Issue with LTO/-fwhole-program
On 11/06/2010 13:59, Richard Guenther wrote:
Well, we can't. We specifically support mixed LTO/non LTO objects
(think of shared libraries for example
On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com wrote:
Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly
Application. Gold support for our target is still far away. I found
-fwhole-program
is very important for our size optimization.
But if I understand
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: 11 June 2010 14:08
To: Bingfeng Mei
Cc: Dave Korn; Manuel López-Ibáñez; gcc@gcc.gnu.org; Jan Hubicka
Subject: Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 3:04 PM, Bingfeng Mei b
-Original Message-
From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com]
Sent: 11 June 2010 14:14
To: Bingfeng Mei
Cc: Dave Korn; Richard Guenther; gcc@gcc.gnu.org; Jan Hubicka
Subject: Re: Issue with LTO/-fwhole-program
On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the other object files.
It is really up to user to understand
On 11 June 2010 15:26, Jan Hubicka hubi...@ucw.cz wrote:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the other
On 11/06/2010 14:26, Jan Hubicka wrote:
Perhaps we can somehow poison the object names that are brought local with
-fwhole-program
so linking explode, but I am not sure there is way to do so.
Could emit warning symbols, but, like the others, I don't see why collect2
can't spot this.
On 11/06/2010 14:26, Jan Hubicka wrote:
Perhaps we can somehow poison the object names that are brought local with
-fwhole-program
so linking explode, but I am not sure there is way to do so.
Could emit warning symbols, but, like the others, I don't see why collect2
can't spot
Manuel López-Ibáñez lopeziba...@gmail.com writes:
On 11 June 2010 15:26, Jan Hubicka hubi...@ucw.cz wrote:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler
Manuel López-Ibáñez lopeziba...@gmail.com writes:
On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com wrote:
Well, mixed LTO/non-LTO is quite useful. For example, we have mixed
C/assembly
Application. Gold support for our target is still far away. I found
-fwhole-program
is very
* Jan Hubicka wrote on Fri, Jun 11, 2010 at 03:26:12PM CEST:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the
Quoting Jan Hubicka hubi...@ucw.cz:
Perhaps we can somehow poison the object names that are brought
local with -fwhole-program
so linking explode, but I am not sure there is way to do so.
The linker will generally emit a diagnostic when the size or alignment
of a symbol increases, or the
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for this
specific combination. I think making this mistake would be quite easy
but hard to debug.
It's not only correct, it's essential. Whole Program doesn't mean
that
On 06/11/2010 03:26 PM, Jan Hubicka wrote:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the other object files.
It
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for this
specific combination. I think making this mistake would be quite easy
but hard to debug.
It's
On 11 June 2010 21:41, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for this
specific combination. I
On Fri, Jun 11, 2010 at 12:50 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 21:41, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost
Manuel López-Ibáñez lopeziba...@gmail.com writes:
This also means that linking your program with non-LTO+whole-program
code may lead to miscompilations without any warning, which is really
bad. I don't think it is a reasonable limitation and we will get bad
press when programs start breaking
On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for this
specific
52 matches
Mail list logo