Richard Guenther writes:
> But then can't people use a pure assembler stub instead? Without
> inlining there isn't much benefit left from writing
>
> void f1(int arg)
> {
> register int a1 asm("r8") = 10;
> register int a2 asm("r1") = arg;
>
> asm("scall" : : "r"(a1), "r"(a2));
> }
>
> i
Snapshot gcc-4.4-20110802 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110802/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the
CPython interpreter within GCC, allowing you to write new compiler
warnings in Python, generate code visualizations, etc.
Tarball releases are available at:
https://fedorahosted.org/releases/g/c/gcc-python-plugin/
Prebuilt-docum
On Tue, Aug 2, 2011 at 6:02 PM, Richard Henderson wrote:
> On 08/02/2011 05:22 AM, Richard Guenther wrote:
>>> -fno-tree-ter also unbreaks the ARM test case in PR48863 comment #4.
>>
>> It's of course only a workaround, not a real fix as nothing prevents
>> other optimizers from performing the re-
On Tue, Aug 2, 2011 at 11:24 AM, Toon Moene wrote:
> What am I doing wrong:
>
> configure:3247: checking for suffix of object files
> configure:3269: /home/toon/compilers/obj-t/./gcc/xgcc
> -B/home/toon/compilers/obj-t/./gcc/ -B/tmp/lto/x86_64-unknown-linux-gnu/bin/
> -B/tmp/lto/x86_64-unknown-lin
What am I doing wrong:
configure:3247: checking for suffix of object files
configure:3269: /home/toon/compilers/obj-t/./gcc/xgcc
-B/home/toon/compilers/obj-t/./gcc/
-B/tmp/lto/x86_64-unknown-linux-gnu/bin/
-B/tmp/lto/x86_64-unknown-linux-gnu/lib/ -isystem
/tmp/lto/x86_64-unknown-linux-gnu/inc
Richard Guenther schrieb:
I suggest to amend the documentation for local call-clobbered register
variables to say that the only valid sequence using them is from a
non-inlinable function that contains only direct initializations of the
register variables from constants or parameters.
Richard.
On 08/02/2011 05:22 AM, Richard Guenther wrote:
>> -fno-tree-ter also unbreaks the ARM test case in PR48863 comment #4.
>
> It's of course only a workaround, not a real fix as nothing prevents
> other optimizers from performing the re-scheduling TER does.
>
> I suggest to amend the documentation
Richard Guenther writes:
> On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> Or go one step further and deprecate local register variables alltogether
>>> (they IMHO don't make much sense, and rather the targets should provide
>>> a way to properly const
On 2 August 2011 14:08, Markus Trippelsdorf wrote:
> Revisions 176335 removed the traditional "#include " from
> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
> etc.) that implicitly rely on it.
> I'm not sure that the gain is worth the pain in this case.
The "pain" fixe
On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> Or go one step further and deprecate local register variables alltogether
>> (they IMHO don't make much sense, and rather the targets should provide
>> a way to properly constrain asm inputs and outputs).
>
>
Richard Guenther writes:
> Or go one step further and deprecate local register variables alltogether
> (they IMHO don't make much sense, and rather the targets should provide
> a way to properly constrain asm inputs and outputs).
No, local register variables are documented as working and many pr
On Tue, 2 Aug 2011, Richard Guenther wrote:
> > I'd be ok with that, FWIW; I see the problem with keeping the
> > scheduling of operations in a working order (yuck) and I don't
> > see how else to keep it working ...except perhaps make gcc flag
> > functions with register asms as non-inlinable, may
On Tue, Aug 02, 2011 at 03:08:03PM +0200, Markus Trippelsdorf wrote:
> Revisions 176335 removed the traditional "#include " from
> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
> etc.) that implicitly rely on it.
This isn't the first time the libstdc++ headers were clea
On Tue, Aug 2, 2011 at 2:53 PM, Hans-Peter Nilsson wrote:
> On Tue, 2 Aug 2011, Richard Guenther wrote:
>> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
>> > Michael Walle writes:
>> > >
>> > > Hi,
>> > >
>> > > > To confirm that try -fno-tree-ter.
>> > >
>> > > "lm32-gcc -O1 -fn
Revisions 176335 removed the traditional "#include " from
gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
etc.) that implicitly rely on it.
I'm not sure that the gain is worth the pain in this case.
--
Markus
On Tue, 2 Aug 2011, Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
> > Michael Walle writes:
> > >
> > > Hi,
> > >
> > > > To confirm that try -fno-tree-ter.
> > >
> > > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
> > > assem
Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
>> Michael Walle writes:
>> >
>> > Hi,
>> >
>> > > To confirm that try -fno-tree-ter.
>> >
>> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
>> > assembly code:
>> >
>> > f2:
>>
On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
> Michael Walle writes:
> >
> > Hi,
> >
> > > To confirm that try -fno-tree-ter.
> >
> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
> > assembly code:
> >
> > f2:
> > addi sp, sp, -4
> >
Michael Walle writes:
>
> Hi,
>
> > To confirm that try -fno-tree-ter.
>
> "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
> assembly code:
>
> f2:
> addi sp, sp, -4
> sw (sp+4), ra
> addi r2, r0, 10
> calli__ashrsi3
Hi,
> To confirm that try -fno-tree-ter.
"lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
assembly code:
f2:
addi sp, sp, -4
sw (sp+4), ra
addi r2, r0, 10
calli__ashrsi3
addi r8, r0, 10
scall
On Tue, Aug 2, 2011 at 12:01 PM, Georg-Johann Lay wrote:
> Richard Guenther wrote:
>> On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson wrote:
>>> Hans-Peter Nilsson writes:
>>> > On Mon, 1 Aug 2011, Richard Henderson wrote:
>>> >
>>> > > On 08/01/2011 01:30 PM, Michael Walle wrote:
>>> > >
Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson wrote:
>> Hans-Peter Nilsson writes:
>> > On Mon, 1 Aug 2011, Richard Henderson wrote:
>> >
>> > > On 08/01/2011 01:30 PM, Michael Walle wrote:
>> > > > 1) function inlining
>> > > > 2) deferred argument evaluation
On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson wrote:
> Hans-Peter Nilsson writes:
> > On Mon, 1 Aug 2011, Richard Henderson wrote:
> >
> > > On 08/01/2011 01:30 PM, Michael Walle wrote:
> > > > 1) function inlining
> > > > 2) deferred argument evaluation
> > > > 3) because our target
On Mon, Aug 1, 2011 at 8:43 PM, Oleg Smolsky
wrote:
> On 2011/7/29 14:07, Xinliang David Li wrote:
>>
>> Profiling tools are your best friend here. If you don't have access to
>> any, the least you can do is to build the program with -pg option and
>> use gprof tool to find out differences.
>
> Th
On Tue, Aug 2, 2011 at 4:37 AM, Jiangning Liu wrote:
> Hi,
>
> For the following simple test case, PRE optimization hoists computation
> (s!=1) into the default branch of the switch statement, and finally causes
> very poor code generation. This problem occurs in both X86 and ARM, and I
> believe
Hans-Peter Nilsson writes:
> On Mon, 1 Aug 2011, Richard Henderson wrote:
>
> > On 08/01/2011 01:30 PM, Michael Walle wrote:
> > > 1) function inlining
> > > 2) deferred argument evaluation
> > > 3) because our target has no barrel shifter, (arg >> 10) is emitted as a
> > > function call
27 matches
Mail list logo
