Edward Peschko writes:
> When I link with a shared library, for example:
>
> env LD_RUN_PATH="/usr/lib" /usr/bin/gcc -shared -fPIC
> -L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o
> blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib
> /usr/lib/libconfig.so
>
> the ld
All,
When I link with a shared library, for example:
env LD_RUN_PATH="/usr/lib" /usr/bin/gcc -shared -fPIC
-L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o
blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib
/usr/lib/libconfig.so
the ld command follows the version, and
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
On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu wrote:
> [snip]
> x86 assembler isn't an optimizing assembler. -mtune only does
> instruction selection. What you are proposing sounds like an optimizing
> assembler to me. Are we going to support scheduling, macro, ...?
> --
> H.J.
Just to clarify, we ar
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 Fri, Jun 11, 2010 at 02:09:33PM -0500, Quentin Neill wrote:
> Currently GCC doesn't compute the current encoding offset (doesn't
> know mnemonic/opcode lengths),
That's not true, gcc for i?86/x86_64 actually calculates the length and for
most of the commonly used insns correctly, I've spent so
On Fri, Jun 11, 2010 at 12:09 PM, Quentin Neill
wrote:
> On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
> wrote:
>> On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
> [snip]
>>> Does this qualify as a form of what you are suggesting? Because this
>>> is exactly what is being p
On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
wrote:
> On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
[snip]
>> Does this qualify as a form of what you are suggesting? Because this
>> is exactly what is being proposed:
>>
>> .balign 8 # start window
>> i
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
Hi,
I am trying to dump the final-most gimple (in ssa) file. My understanding is
that lto encodes GIMPLE IR in the bytestream of the object files and
accordingly I invoke PLUGIN_PASS_MANAGER_SETUP to embed my faux dummy pass
after 'pass_ipa_lto_finish_out'. Is ssa information available at the
On 06/11/10 10:48, Bernd Schmidt wrote:
On 06/11/2010 06:32 PM, Jeff Law wrote:
But shouldn't having an invariant form just decrease the priority
for pseudo 59 to get a hard register? The NO_REGS preferencing will
totally disable register allocation for pseudo 59.
And that's intende
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.
On 06/11/2010 06:32 PM, Jeff Law wrote:
> But shouldn't having an invariant form just decrease the priority
> for pseudo 59 to get a hard register? The NO_REGS preferencing will
> totally disable register allocation for pseudo 59.
And that's intended, because from the costs we've concluded that
* 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
On 06/10/10 14:44, Bernd Schmidt wrote:
On 06/10/2010 10:37 PM, Jeff Law wrote:
Compile the attached with -O2 on x86-unknown-linux-gnu and review the
.ira dump for main()
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
Building IRA IR
star
On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
> > On the other hand, I'm not going to argue that it's a lot of work.
Missing "not" !
> When you say "put assertions in the assembler output" I understood it
> to mean "in the assembly source code output by the compiler", not "the
>
"Radu Hobincu" writes:
> Thanks for the reply. I scrolled a lot through the i386 md and c files. I
> notice that the i386 architecture has dedicated
> instructions for comparing values and ALU instructions only specify
> (clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify
>
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
Thanks for the reply. I scrolled a lot through the i386 md and c files. I
notice that the i386 architecture has dedicated
instructions for comparing values and ALU instructions only specify
(clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify
the way ALU instructions affect th
> 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:04, Bingfeng Mei wrote:
> >
> -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 M
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
On Fri, Jun 11, 2010 at 3:04 PM, 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.
True. Without symbol resol
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.
Bingfeng
> -Original Message-
> From: Dave Korn [mailto:dave.korn.cyg...@gmail.
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
i have pushed the patch on "mob"
Coo: initial last member of union
Please change my name of patch: U-YUAN\Administrator -> yuanbin
2010/6/11 grischka :
> Too all:
>
> Please push patches on our "mob" branch:
> http://repo.or.cz/w/tinycc.git
>
> People who don't like/know git: at least base patch
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 06/11/2010 10:15 AM, yuanbin wrote:
gcc initial the first member of union now, This is not the C standard also.
I just want gcc initial the last member of union with some switch.
Why do you want the last one? Is there a compiler that does that (e.g.
MSVC++)? If yes, it can be toggled by -
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
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:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
I
Richard Guenther writes:
>
> Iff the inheritence is restricted to initializers like in the above example
> it should be straight-forward to implement in the frontends.
Great.
For best results would need some inheritance to callees too, if the
callees are not called by other non annotated code (t
On Thu, Jun 10, 2010 at 10:26 PM, Andi Kleen wrote:
> Hi Honza,
>
> Here's an idea to make it easier to manually annotate
> large C code bases for hot/cold functions where
> it's too difficult to use profile feedback.
>
> It's fairly common here to call function through
> function pointers in manu
I am familiar with C++, Do not recommend C++ to me.
gcc initial the first member of union now, This is not the C standard also.
I just want gcc initial the last member of union with some switch.
2010/6/11 Magnus Fromreide :
> On Fri, 2010-06-11 at 08:44 +0800, yuanbin wrote:
>> typedef struct CBa
48 matches
Mail list logo
