Richard Guenther 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 correctly under
certain restr
"Bingfeng Mei" 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 is a bug in
On Mon, Jun 14, 2010 at 11:27 AM, David Brown wrote:
> On 14/06/2010 11:22, Dave Korn wrote:
>>
>> On 14/06/2010 05:43, Ian Lance Taylor wrote:
>>>
>>> David Brown writes:
>>>
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases whe
On Mon, Jun 14, 2010 at 9:26 AM, David Brown wrote:
> On 14/06/2010 06:43, Ian Lance Taylor wrote:
>>
>> David Brown 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
On 14/06/2010 11:22, Dave Korn wrote:
On 14/06/2010 05:43, Ian Lance Taylor wrote:
David Brown 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
> -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 writes:
&g
On 14/06/2010 05:43, Ian Lance Taylor wrote:
> David Brown 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 -f
On 14/06/2010 06:43, Ian Lance Taylor wrote:
David Brown 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
David Brown 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 case of libraries or ot
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 orig
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 writes:
> >>>
> If -flto were to activate the -fno-common flag, would that then catch
>
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 writes:
>>>
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
>>> We c
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 poste
Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown 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 we shoul
On Sun, 13 Jun 2010, Dave Korn wrote:
> On 13/06/2010 20:55, Ian Lance Taylor wrote:
> > David Brown 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 Fo
On 13/06/2010 20:55, Ian Lance Taylor wrote:
> David Brown 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 we shouldn't
David Brown 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 12/06/2010 16:52, Richard Guenther wrote:
On Sat, Jun 12, 2010 at 3:32 PM, David Brown wrote:
Ian Lance Taylor wrote:
Manuel López-Ibáñez writes:
This also means that linking your program with non-LTO+whole-program
code may lead to miscompilations without any warning, which is really
ba
David Brown 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.
It's a good idea but u
On Sat, Jun 12, 2010 at 3:32 PM, David Brown wrote:
> Ian Lance Taylor wrote:
>>
>> Manuel López-Ibáñez 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 reas
Ian Lance Taylor wrote:
Manuel López-Ibáñez 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 12 June 2010 01:27, Richard Guenther wrote:
> On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez
> wrote:
>> On 11 June 2010 20:48, Cary Coutant wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for
On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 20:48, Cary Coutant 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 mist
Manuel López-Ibáñez 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 for users. They wo
On Fri, Jun 11, 2010 at 12:50 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 21:41, Manuel López-Ibáñez wrote:
>> On 11 June 2010 20:48, Cary Coutant wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning fo
On 11 June 2010 21:41, Manuel López-Ibáñez wrote:
> On 11 June 2010 20:48, Cary Coutant 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
On 11 June 2010 20:48, Cary Coutant 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 not only co
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 i
> 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
Quoting Jan Hubicka :
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 type changes.
* 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 s
Manuel López-Ibáñez writes:
> On 11 June 2010 15:04, Bingfeng Mei 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
Manuel López-Ibáñez writes:
> On 11 June 2010 15:26, 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 becaus
> 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
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 June 2010 15:26, 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 fi
> 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 -fwhol
> -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
> -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, 2
On 11 June 2010 15:04, Bingfeng Mei 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 correctly, mixed
>> 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'
rn.cyg...@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 specific
On Fri, Jun 11, 2010 at 3:21 PM, Dave Korn 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 just GNU ld and collec
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 -fwhole-pr
On Fri, Jun 11, 2010 at 2:57 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 14:40, Richard Guenther wrote:
>> On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
>> wrote:
>>> On 11 June 2010 14:23, Richard Guenther wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
wrote
On 11 June 2010 14:40, Richard Guenther wrote:
> On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
> wrote:
>> On 11 June 2010 14:23, Richard Guenther wrote:
>>> On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
>>> wrote:
On 11 June 2010 14:07, Richard Guenther wrote:
> On Fri,
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 14:23, Richard Guenther wrote:
>> On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
>> wrote:
>>> On 11 June 2010 14:07, Richard Guenther wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei wrote:
> Hi,
On 11 June 2010 14:23, Richard Guenther wrote:
> On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
> wrote:
>> On 11 June 2010 14:07, Richard Guenther wrote:
>>> On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
>
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
wrote:
> On 11 June 2010 14:07, Richard Guenther wrote:
>> On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei wrote:
>>> Hi,
>>>
>>> I am still puzzled by the effect of LTO/-fwhole-program.
>>> For the following simple tests:
>>>
>>> a.c:
>>>
>>> #
On 11 June 2010 14:07, Richard Guenther wrote:
> On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei wrote:
>> Hi,
>>
>> I am still puzzled by the effect of LTO/-fwhole-program.
>> For the following simple tests:
>>
>> a.c:
>>
>> #include
>> int v;
>>
>> extern void bar();
>> int main()
>> {
>> v = 5
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei wrote:
> Hi,
>
> I am still puzzled by the effect of LTO/-fwhole-program.
> For the following simple tests:
>
> a.c:
>
> #include
> int v;
>
> extern void bar();
> int main()
> {
> v = 5;
> bar();
>
> printf("v = %d\n", v);
> return 0;
> }
>
> b.c
51 matches
Mail list logo
