On Mon, Aug 1, 2011 at 12:12 PM, Rohit Arul Raj wrote:
> Hello All,
>
> I compiled a simple 1.c file with -mpcu=e500mc64 option and while
> trying to create a relocatable, i am getting the following error:
>
> $powerpc-elf-ld.exe -static -r 1.o
> powerpc-elf-ld.exe: Relocatable linking with reloca
Jon Grant wrote:
> Hello
>
> Georg-Johann Lay wrote, On 08/07/11 19:08:
> [.]
>> I can confirm that it's hardly readable on some systems.
>> I use Opera and several FF versions, some worse, some a bit less worse.
>>
>> IMO it's definitely to small, I already thought about complaining, too.
>>
>> J
On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote:
> It's quite necessary to solve the general problem in middle-end rather than
> in back-end.
That's what we disagree on. All back-ends but ARM are able to handle it
right, why can't ARM too? The ABI rules for stack handling in the e
2011/8/1 Marc Glisse :
> On Fri, 15 Jul 2011, Ian Lance Taylor wrote:
>
>> I would like to propose this patch as a step toward building gcc using a
>> C++ compiler. This patch builds stage1 with the C compiler as usual,
>> and defaults to building stages 2 and 3 with a C++ compiler built during
>>
On Mon, 1 Aug 2011, Richard Guenther wrote:
> I think it's the only viable solution (use the full enum for a non-GCC stage1
> C++ compiler). We could help it somewhat by at least placing
> enum bitfields first/last in our bitfield groups.
Are GCC and other compilers declaring that they support t
On Mon, Aug 1, 2011 at 11:53 AM, Joseph S. Myers
wrote:
> On Mon, 1 Aug 2011, Richard Guenther wrote:
>
>> I think it's the only viable solution (use the full enum for a non-GCC stage1
>> C++ compiler). We could help it somewhat by at least placing
>> enum bitfields first/last in our bitfield gro
On Mon, 1 Aug 2011, Jakub Jelinek wrote:
> On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote:
> > It's quite necessary to solve the general problem in middle-end rather than
> > in back-end.
>
> That's what we disagree on. All back-ends but ARM are able to handle it
> right, why can
On Mon, 1 Aug 2011, Joseph S. Myers wrote:
On Mon, 1 Aug 2011, Richard Guenther wrote:
I think it's the only viable solution (use the full enum for a non-GCC stage1
C++ compiler). We could help it somewhat by at least placing
enum bitfields first/last in our bitfield groups.
Are GCC and oth
The answer is ARM can. However, if you look into the bugs PR30282 and
PR38644, PR44199, you may find in history, there are several different cases
in different ports reporting the similar failures, covering x86, PowerPC and
ARM. You are right, they were all fixed in back-ends in the past, but we
On 01/08/11 10:11, Jakub Jelinek wrote:
> On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote:
>> It's quite necessary to solve the general problem in middle-end rather than
>> in back-end.
>
> That's what we disagree on. All back-ends but ARM are able to handle it
> right, why can't A
On Mon, Aug 01, 2011 at 06:14:27PM +0800, Jiangning Liu wrote:
> ARM. You are right, they were all fixed in back-ends in the past, but we
> should
> fix the bug in a general way to make GCC infrastructure stronger, rather
> than fixing the problem target-by-target and case-by-case! If you further
> Don't change the constraint, just add an alternative. Or use a
> different insn with an insn predicate.
This is misunderstanding beacuse of my great English :)
I am not going to update existing constraint. I am going to implement new one.
Actually, I am looking for some expample, where similar
> What if the object being constructed has only POD-type members with constant
> initializers but is declared volatile
I don't understand really... but it doesn't matter, I give up.
Hi Benjamin,
On 2011/7/30 06:22, Benjamin Redelings I wrote:
I had some performance degradation with 4.6 as well.
However, I was able to cure it by using -finline-limit=800 or 1000 I
think. However, this lead to a code size increase. Were the old
higher-performance binaries larger?
Yes, th
On Mon, 1 Aug 2011, Oleg Smolsky wrote:
BTW, some of these tweaks increase the binary size to 99K, yet there is no
performance increase.
I don't see this in the thread: did you use -march=native?
--
Marc Glisse
See:
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00117.html
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http
On Mon, 1 Aug 2011, Toon Moene wrote:
See:
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00117.html
Er, the python thing only tells you your system has a broken symlink but
ignores it. Did you check in libgcc/config.log for the real error?
--
Marc Glisse
On 08/01/2011 08:45 PM, Marc Glisse wrote:
On Mon, 1 Aug 2011, Toon Moene wrote:
See:
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00117.html
Er, the python thing only tells you your system has a broken symlink but
ignores it. Did you check in libgcc/config.log for the real error?
Oop
On 08/01/2011 08:56 PM, Toon Moene wrote:
On 08/01/2011 08:45 PM, Marc Glisse wrote:
On Mon, 1 Aug 2011, Toon Moene wrote:
See:
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00117.html
Er, the python thing only tells you your system has a broken symlink but
ignores it. Did you check in
On 07/29/2011 12:13 PM, Vladimir Makarov wrote:
On 07/27/2011 05:59 PM, Sandra Loosemore wrote:
[snip]
So, here's my question. Is it worthwhile for me to continue this
approach of trying to make the MIPS backend smarter? Or is the way IRA
deals with CANNOT_CHANGE_MODE_CLASS fundamentally broke
Hi list,
consider the following test code:
static void inline f1(int arg)
{
register int a1 asm("r8") = 10;
register int a2 asm("r1") = arg;
asm("scall" : : "r"(a1), "r"(a2));
}
void f2(int arg)
{
f1(arg >> 10);
}
If you compile this code with 'lm32-gcc -O1 -S -c test.c' (se
Michael Walle schrieb:
Hi list,
consider the following test code:
static void inline f1(int arg)
{
register int a1 asm("r8") = 10;
register int a2 asm("r1") = arg;
asm("scall" : : "r"(a1), "r"(a2));
}
void f2(int arg)
{
f1(arg >> 10);
}
If you compile this code with 'lm32-g
Hi,
That was quick :)
> Your asm has no output operands and no side effects, with more
> aggressive optimization the whole ask would disappear.
Sorry, that was just a small test file, the original code has output operands.
The new test code:
static int inline f1(int arg)
{
register int ret
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 to libgcc's __ashrsi3 (_in place_!)
> 4) BAM! dead code elimination optimizes r8 assignment away becau
Re-sending as plain text for gcc@gcc.gnu.org ...
Hi,
I have a question about the line 0 hack on line 13232 of gcc/cp/decl.c
(or just text search for "Hack", it's the only place it's found in
that file...).
From my revision history, Steven introduced this in 2005, an
Hi,
It turns out that x32 needs R_X86_64_64. One major reason is
the displacement range of x32 is -2G to +2G. It isn't a problem
for compiler since only small model is required for x32.
However, to address 0 to 4G directly in assembly code, we have
to use R_X86_64_64 with movabs. I am checking
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 it is also a problem for other targets.
int f(char *t) {
in
I have removed the hack and the test output is identical to the clean
build test output.
See issue4835047 for the patch.
Gabriel
On Mon, Aug 1, 2011 at 2:56 PM, Gabriel Charette wrote:
> Re-sending as plain text for gcc@gcc.gnu.org ...
>
>
>
> Hi,
>
> I have a quest
Hi Jakub,
Appreciate for your valuable comments!
I think SPARC V9 ABI doesn't have red zone defined, right? So
stack_red_zone_size should be defined as zero by default, the scheduler
would block moving memory accesses across stack adjustment no matter what
the offset is. I don't see any risk here
Try isolate the int8_t constant folding testing from the rest to see
if the slow down can be reproduced with the isolated case. If the
problem disappear, it is likely due to the following inline
parameters:
large-function-insns, large-function-growth, large-unit-insns,
inline-unit-growth. For inst
On Mon, 1 Aug 2011, Georg-Johann Lay wrote:
> Michael Walle schrieb:
> > Hi list,
> >
> > consider the following test code:
> > static void inline f1(int arg)
> > {
> >register int a1 asm("r8") = 10;
> >register int a2 asm("r1") = arg;
> >
> >asm("scall" : : "r"(a1), "r"(a2));
> > }
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 to libgcc's __ashrsi3 (_in place_!)
> > 4) BAM
Michael Walle wrote:
> Hi,
>
> That was quick :)
>
>> Your asm has no output operands and no side effects, with more
>> aggressive optimization the whole ask would disappear.
> Sorry, that was just a small test file, the original code has output operands.
>
> The new test code:
> static int inl
33 matches
Mail list logo
