--- Comment #2 from xinliangli at gmail dot com 2008-02-23 06:55 ---
(In reply to comment #1)
> Sometimes doing the strength reduction actually increases the code size.
> Think
> on targets which have auto increments.
>
> *** This bug has been marked as a duplicate of 22586 ***
>
It
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 05:50 ---
More than just constant prop, see PR 25972 for more info on what else it can be
done with union in the same way.
Actually I think MEM_REF will make it worse and will not help. In fact I still
think MEM_REF is a bad
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-02-23 05:39 ---
*** Bug 35304 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 05:39 ---
> should be (at least with -Os)
And normal -O2. This is a dup of bug 25553 for the reasons why this should be
done even at -O2.
*** This bug has been marked as a duplicate of 25553 ***
--
pinskia at gcc dot gn
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 05:34 ---
GCSE should take care of this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 05:29 ---
I think this is a dup of bug 23455.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35286
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 05:27 ---
*** Bug 35308 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 05:27 ---
Sometimes doing the strength reduction actually increases the code size. Think
on targets which have auto increments.
*** This bug has been marked as a duplicate of 22586 ***
--
pinskia at gcc dot gnu dot org c
union U {
struct A {
int a;
int b;
}aa;
long long ll;
};
struct B{
union U u1;
union U u2;
} bg;
struct B bg;
struct B bar();
int foo (int n)
{
if (n)
{
bg = bar();
}
return bg.u1.ll + bg.u2.ll;
};
// Two union fields loads are partially redund
// Example: the load of structs at return is partially redundant
struct A {
int a;
int b;
int c;
int d;
} ag, ag2,ag3;
struct A foo(int n)
{
if (n)
{
ag2 = ag;
}
return ag;
}
// Gcc generated assembly code:
foo:
.LFB2:
testl %edi, %edi
je .L2
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-02-23 05:22
---
*** Bug 35303 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 05:22 ---
*** This bug has been marked as a duplicate of 23286 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Seems to be a missing functionality
int a[100];
int g;
void foo(int i)
{
a[i] = i*g;
i++;
a[i] = i*g;
i++;
a[i] = i*g;
}
Both array address computation and RHS mpy operations can be strength reduced.
--
Summary: Straight line strength reduction
P
The following rule is good to have:
int i, i, k;
i/j/k ===> i/(j*k)
--
Summary: Missing Simplication for div op
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
The following rule is not handled by GCC
(a & x) || (a & y) ===> a & (x | y)
--
Summary: Missing expression simplication for conditional OR
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
// File this bug to track the problem
int g1, g2;
void foo(int a, int b, int k,int m)
{
if (k)
{
#pragma execution_frequency(very_high)
g1 = a + b;
}
if (m)
{
#pragma execution_frequency(very_high)
g2 = a + b;
}
}
--
Summary: Speculative PRE support
int* g;
void foo(int m)
{
if (m)
*g = 1;
else
*g = 2;
}
should be (at least with -Os)
void foo(int m)
{
if (m)
t = 1;
else
t = 2;
*g = t;
}
--
Summary: Missing store sinking (code size optimization) at tree
level
Missing code size optimization at tree level -- which is more flexible than RTL
level (allow hoisting memory operations).
int g1,g2;
int foo(int a, int b)
{
if (a)
g1 = a + b;
else if (b)
g2 = a+ b;
else
g3 = a + b
return g1 + g2;
}
With hoisting, it should b
This is a known problem -- file it to keep track of it.
In the following example, stores at (1) -- the array initializers are partially
dead -- not sinked.
struct A{
int a[100];
};
const struct A aa = {1,1,1};
int foo(int i)
{
int s = 0;
struct A a = {1,1,1}; // (1)
if (i)
--- Comment #6 from kkylheku at gmail dot com 2008-02-23 05:06 ---
(In reply to comment #5)
> (In reply to comment #4)
> > [crti.o is] found through multilib os-directory suffixes.
> Actually, I'm even more confused, because the breakage I'm seeing is simply
> arising from mips64-linux-l
--- Comment #5 from kkylheku at gmail dot com 2008-02-23 04:58 ---
(In reply to comment #4)
> [crti.o is] found through multilib os-directory suffixes.
Actually, I'm even more confused, because the breakage I'm seeing is simply
arising from mips64-linux-ld being called on a bunch of obj
--- Comment #4 from drow at gcc dot gnu dot org 2008-02-23 04:38 ---
It's found through multilib os-directory suffixes.
How did you configure GCC?
The standard_exec_prefix_1, et cetera patch is not necessary on HEAD and will
conflict. In fact that's another of Carlos's patches. I don
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 03:45 ---
I think this is correct CPP behavior.
it only evaluates one level of _ .
Think of:
#define a b
#define b a
b
a
What does that do?
it just does:
b
a
Instead of causing an infinite loop.
Once we try to revaluate _
It appears that CPP decides to stop expansion at some point.
Re-feeding the output to cpp iteratively peels macro levels.
#include
#include
#define _(op, ...) op(__VA_ARGS__)
#define _if(expr, then, els) if (expr) { then; } else { els; }
#define progn(...) ({__VA_ARGS__;})
#define when(expr, .
--- Comment #3 from kkylheku at gmail dot com 2008-02-23 02:18 ---
Oops, I spoke to soon. The no-prefix-search path breaks my final gcc build,
with shared libraries and glibc. When making libgcc_s.so, it can't find the
crti.o module.
What's happening is two problems.
Firstly, it appear
--- Comment #2 from kkylheku at gmail dot com 2008-02-23 01:40 ---
Created an attachment (id=15211)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15211&action=view)
Hack to not have /lib and /usr/ paths in cross-compiler.
I don't know whether this path is right in general, but it
--- Comment #1 from kkylheku at gmail dot com 2008-02-23 01:35 ---
Created an attachment (id=15210)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15210&action=view)
Patch to gcc/prefix.c for path relocation.
At some point gcc/gcc.c calls the function set_std_prefix in gcc/prefix.c
I am seeing the following two problems problem in gcc 4.1.1.
The front-end driver contains paths from the --prefix where the toolchain was
built, when it is installed at a different location. It was built using
--with-sysroot.
I am aware of bug 17621, and have applied all of Carlos's patches to g
--- Comment #9 from matz at gcc dot gnu dot org 2008-02-23 00:40 ---
Mine, have patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unas
--- Comment #8 from matz at gcc dot gnu dot org 2008-02-22 23:40 ---
I can confirm this, the code in foo is definitely wrong. When I compile
the (standard compliant, unlike the example from comment #4) with 4.2 or
4.3 on x86-64, with -O or -O2 it breaks:
% cat foo.c
long align;
int fo
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.3 4.4.0
Priority|P3 |P5
http:/
In a statement function, only the type and kind are determined from the host.
gfortran fails to compile
troutmask:kargl[205] cat n.f
SUBROUTINE PHTOD(E,N,I,H)
DIMENSION E(N)
HSTAR(E,B)=B**.4*((1.25*FUN(-E/40)+.18)) ! Doesn't work.
C HSTAR(X,Y)=Y**.4*((1.25*FUN(-X/40)+.18)) !
--- Comment #47 from fxcoudert at gcc dot gnu dot org 2008-02-22 23:12
---
(In reply to comment #18)
> the list of functions to fix by Mike
> (where non-builtins have been removed, and variadic functions are fixed
> conditionaly on macos_version_min, as per Geoff's advice...
Modifying
--- Comment #18 from joel at gcc dot gnu dot org 2008-02-22 22:35 ---
(In reply to comment #17)
> If you have it on CFARM let me know where and what command to launch to gdb
> your testcase.
I have been building and running it on my laptop but there is now enough on
CFARM to run it.
q
--- Comment #17 from laurent at guerby dot net 2008-02-22 22:02 ---
If you have it on CFARM let me know where and what command to launch to gdb
your testcase.
What does RTEMS ada_pthread_minimum_stack_size returns in both case (under
gdb)?
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #16 from joel at gcc dot gnu dot org 2008-02-22 22:01 ---
I can add mips/jmr3904 to the list that runs t.adb correctly. So we have
this as a summary:
sparc/sis, powerpc/psim, mips/jmr3904, arm/edb7312 - t.adb runs OK
i386/pc386 fails
bfin/exkit533 - GNAT bug bo
I doubleche
--- Comment #15 from joel at gcc dot gnu dot org 2008-02-22 21:56 ---
(In reply to comment #14)
> Default values come from ada/s-parame-rtems.adb, for the stack it ends up in
> RTEMS ada_pthread_minimum_stack_size:
>
> package body System.Parameters is
>
>function ada_pthread_minim
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-02-22 21:52
---
Subject: Bug 34715
Author: pinskia
Date: Fri Feb 22 21:51:19 2008
New Revision: 132560
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132560
Log:
2008-02-22 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-02-22 21:50
---
Fixed, thanks for your bug report.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-02-22 21:21
---
Subject: Bug 34715
Author: pinskia
Date: Fri Feb 22 21:21:11 2008
New Revision: 132558
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132558
Log:
2008-02-22 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #14 from laurent at guerby dot net 2008-02-22 21:12 ---
Default values come from ada/s-parame-rtems.adb, for the stack it ends up in
RTEMS ada_pthread_minimum_stack_size:
package body System.Parameters is
function ada_pthread_minimum_stack_size return Interfaces.C.size_t
--- Comment #13 from joel at gcc dot gnu dot org 2008-02-22 20:53 ---
Laurent's t.adb works on arm/edb7312.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-22 20:35 ---
Created an attachment (id=15209)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15209&action=view)
Source file which triggers error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35298
I decided to see what other targets did with Laurent's t.adb program (see
PR35284). My first attempt was bfin which died with this error.
bfin-rtems4.9-gcc -c -g
-I/home/joel/work-gnat/svn/bsp-install/bfin-rtems4.9/eZKit533//lib/include/adainclude
-O -gnata -gnatE -gnato -g t.adb
+===
--- Comment #3 from bugzilla-gcc at thewrittenword dot com 2008-02-22
20:23 ---
Created an attachment (id=15208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15208&action=view)
patch to include string.h and strings.h (stolen from libcpp)
Patch does not include generated files (c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2008-02-22 18:28
---
Taking care of it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-02-22 18:27
---
Thanks for the report, analysis and patch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from tdragon at tdragon dot net 2008-02-22 18:14 ---
Are there sufficient motivation and resources to fix this bug in 4.2? Since 4.3
is soon-to-be, an update on this would be sincerely appreciated -- even if it's
just forgetting about 4.2 and resolving as FIXED.
--
h
--- Comment #19 from jason at gcc dot gnu dot org 2008-02-22 18:03 ---
Seems Darwin doesn't track the source position of undefined symbol references.
Feel free to improve the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-22 17:58 ---
As when you say bigger do you mean the assembly is different sizes? Or do you
mean the actually text/data sections are bigger in the object file?
--
pinskia at gcc dot gnu dot org changed:
What|R
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-02-22 17:50
---
g++.dg/other/anon5.C fails on i386-darwin:
/var/tmp//ccpes1Oj.s:20:non-relocatable subtraction expression,
"__ZN12_GLOBAL__N_11c1tE" minus "L001$pb"^M
/var/tmp//ccpes1Oj.s:20:symbol: "__ZN12_GLOBAL__N_11c1t
Hi,
the following code fails to compile with gcc-4.3-20080215
template
struct test {};
int main()
{
test<> a;
return 0;
}
According to N2242 section 3.6, page 7:
If a template-parameter of a class template has a default template-argument,
each subsequent template-parameter sha
--- Comment #12 from joel at gcc dot gnu dot org 2008-02-22 16:43 ---
I just noticed that the stack size passed to
system.task_primitives.operations.create_task is also 0 in the back trace on
the i386. It is 32724 on the PowerPC.
So two parameters are bad. The 0 just indicates that the
--- Comment #4 from dominiq at lps dot ens dot fr 2008-02-22 16:21 ---
Forgot to give the result:
avd= -1.00 should be:0.00
fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
--- Comment #3 from dominiq at lps dot ens dot fr 2008-02-22 16:17 ---
Sorry, I have been too fast. The test in comment #1 fails with -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
--- Comment #2 from dominiq at lps dot ens dot fr 2008-02-22 16:01 ---
Subject: Re: Failures in the NIST test suite FM827 with
-m64
The test in comment #1 pass. I have forgotten to say that the arithmetic IF is
needed for the failure and that removing any one of the four left test cas
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-02-22 15:45
---
Works for me.
Can you try this test case:
program fm827
double precision avd, bvd, cvd, dvd, dvcorr
ct010* test 10 tanh(x) = 1 - 2/(exp(2x)+1)
bvd
--- Comment #11 from joel at gcc dot gnu dot org 2008-02-22 15:34 ---
Good Morning! By setting a breakpoint on _CPU_Context_switch in RTEMS, I can
see where things went wrong. On both SPARC and PowerPC, we dispatched out of
this backtrace:
(gdb) bt
#0 pthread_setschedparam (thread=18
init_expr_once sets direct_load and direct_store arrays, which are indexed by
mode. These are supposed to indicate "can we load a value of this mode from
memory" and similar for store. It does this by passing a bunch of (set (reg)
(mem)) instructions to recog.
At the top of the function:
/*
--- Comment #46 from bonzini at gnu dot org 2008-02-22 15:20 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
[off bugzilla]
I think FX is going to submit a patch soon.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2008-02-22
15:11 ---
I believe the code that assigns the function names in fortran is
#define DO_DEFINE_MATH_BUILTIN(code, name, argtype, tbase) \
gfc_define_builtin ("__builtin_" name "l", tbase##longdouble[argtype],
--- Comment #44 from fxcoudert at gcc dot gnu dot org 2008-02-22 15:09
---
(In reply to comment #42)
> (There is one exception: calls to cpowl generated by the Fortran front-end
> seem
> not to work, but it is a front-end issue: we don't treat cpow?() functions as
> builtins, probably
--- Comment #43 from bonzini at gnu dot org 2008-02-22 15:08 ---
I don't think you have to be afraid. Note that with your patch there wouldn't
even be need to patch math.h -- in other words, your patch DTRT and it should
have been done this way ever since the feature was introduced in t
--- Comment #42 from fxcoudert at gcc dot gnu dot org 2008-02-22 14:59
---
(In reply to comment #39)
> Actually, I think we're almost there. You have to prepend an
> underscore.
You're right, and it works. I'm a bit afraid of doing so (if it's handled
everywhere else, why isn't it ha
--- Comment #41 from bonzini at gnu dot org 2008-02-22 14:53 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
ubizjak at gmail dot com wrote:
> --- Comment #40 from ubizjak at gmail dot com 2008-02-22 14:49 ---
> This simple proof-of-co
--- Comment #40 from ubizjak at gmail dot com 2008-02-22 14:49 ---
This simple proof-of-concept patch works as expected:
--cut here--
Index: langhooks.c
===
--- langhooks.c (revision 132541)
+++ langhooks.c (working copy)
@
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 14:38 ---
Do you have a testcase? The constants should be printed according to their
mode, which is target dependent. The host representation should not matter
apart for the biggest supported mode.
--
rguenth at gcc dot
--- Comment #39 from bonzini at gnu dot org 2008-02-22 14:36 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
>> I think you should use set_user_assembler_name instead of
>> SET_DECL_ASSEMBLER_NAME.
>
> Nope. Doing this gives, for you C testca
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-02-22 14:19
---
oops, the file name is foo.txt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
We are cross-compiling to a 32-bit ARM target from both 32-bit and 64-bit PCs.
The gcc cross-compiler toolchain (3.4.6) generates valid code in both cases,
but the generated code is larger when a 64-bit host is used. We have tracked
this down to the following:
1) The RTL is using 64-bit (on the 6
Compiling this simple function:
#include
void foo()
{
_mm_srli_pi16(_mm_setzero_si64(), 8);
}
with the command line arm-angstrom-linux-gnueabi-gcc -c -O2 iwmmxt.cpp, results
in:
/home/qt/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r10/image/home/qt/gumstix/gum
--- Comment #38 from fxcoudert at gcc dot gnu dot org 2008-02-22 14:11
---
(In reply to comment #34)
> long double test(long double x) { return sinl(x); }
> long double test_(long double x) { return __builtin_sinl(x); }
>
> test_:
> jmp sinl$LDBL128
> test:
> jmp
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-02-22 14:10
---
Created an attachment (id=15207)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15207&action=view)
Modified streamio_15.f90 test case
hp, can you try this test case and post the output and also a hex dump of
--- Comment #37 from bonzini at gnu dot org 2008-02-22 14:03 ---
(Not that I knew that this morning, of course).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #36 from bonzini at gnu dot org 2008-02-22 14:02 ---
I think you should use set_user_assembler_name instead of
SET_DECL_ASSEMBLER_NAME.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #35 from ubizjak at gmail dot com 2008-02-22 13:49 ---
Hm...
/* Worker for DEF_BUILTIN.
Possibly define a builtin function with one or two names.
Does not declare a non-__builtin_ function if flag_no_builtin, or if
nonansi_p and flag_no_nonansi_builtin. */
static
--- Comment #34 from ubizjak at gmail dot com 2008-02-22 13:41 ---
Perhaps patch from comment #24 can give some clue, because with this patch I
get:
long double test(long double x) { return sinl(x); }
long double test_(long double x) { return __builtin_sinl(x); }
test_:
jmp
--- Comment #33 from fxcoudert at gcc dot gnu dot org 2008-02-22 13:22
---
(In reply to comment #26)
>> but the Fortran front-end apparently doesn't benefit from it:
>
> The weird thing is that we go through the code of the patch, so I'm not sure
> why it still fails.
Here is the fnde
--- Comment #32 from dominiq at lps dot ens dot fr 2008-02-22 13:12 ---
> Lack of interest for the platform. After all, PowerBooks have been
> discontinued for 3 years... :-)
This PR is more than two year old and is present on all the ppc machines
(including G5).
Note also that Apple
--- Comment #31 from bonzini at gnu dot org 2008-02-22 12:08 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
> Where the problem becomes serious is for languages such as fortran which has
> no
> direct way to access math.h. So far all the att
--- Comment #30 from bonzini at gnu dot org 2008-02-22 12:05 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
> (As a sidenote, there is one minor thing for which recompiling libgfortran is
> needed, and that's specific functions; I'm not using
--- Comment #13 from pcarlini at suse dot de 2008-02-22 11:07 ---
Unfortunately, back to a 4.3 (and 4.4) regression.
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--- Comment #10 from pcarlini at suse dot de 2008-02-22 11:05 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #12 from paolo at gcc dot gnu dot org 2008-02-22 11:04 ---
Subject: Bug 28743
Author: paolo
Date: Fri Feb 22 11:03:17 2008
New Revision: 132545
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132545
Log:
/testsuite
2008-02-22 Paolo Carlini <[EMAIL PROTECTED]>
--- Comment #9 from paolo at gcc dot gnu dot org 2008-02-22 11:04 ---
Subject: Bug 35282
Author: paolo
Date: Fri Feb 22 11:03:17 2008
New Revision: 132545
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132545
Log:
/testsuite
2008-02-22 Paolo Carlini <[EMAIL PROTECTED]>
--- Comment #8 from paolo at gcc dot gnu dot org 2008-02-22 11:03 ---
Subject: Bug 35282
Author: paolo
Date: Fri Feb 22 11:02:31 2008
New Revision: 132544
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132544
Log:
/testsuite
2008-02-22 Paolo Carlini <[EMAIL PROTECTED]>
--- Comment #11 from paolo at gcc dot gnu dot org 2008-02-22 11:03 ---
Subject: Bug 28743
Author: paolo
Date: Fri Feb 22 11:02:31 2008
New Revision: 132544
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132544
Log:
/testsuite
2008-02-22 Paolo Carlini <[EMAIL PROTECTED]>
--- Comment #10 from paolo at gcc dot gnu dot org 2008-02-22 11:02 ---
Subject: Bug 28743
Author: paolo
Date: Fri Feb 22 11:02:00 2008
New Revision: 132543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132543
Log:
/testsuite
2008-02-22 Paolo Carlini <[EMAIL PROTECTED]>
--- Comment #7 from paolo at gcc dot gnu dot org 2008-02-22 11:02 ---
Subject: Bug 35282
Author: paolo
Date: Fri Feb 22 11:02:00 2008
New Revision: 132543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132543
Log:
/testsuite
2008-02-22 Paolo Carlini <[EMAIL PROTECTED]>
--- Comment #29 from fxcoudert at gcc dot gnu dot org 2008-02-22 11:00
---
>> but the Fortran front-end apparently doesn't benefit from it:
>
> From what I understand, you have to rebuild libgfortran. Did you do so?
It doesn't need to, the calls are emitted directly by the front-end
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:58 ---
Confirmed. This also blocks removal of store_ccp.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:57 ---
Confirmed. I think this is the same issue as PRE of globals.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:55 ---
Confirmed. Re-association generates
D.1548_3 = a1_4(D) + a1_4(D);
b1_5 = D.1548_3 + a2_2(D);
b2_6 = b1_5 + a2_2(D);
D.1549_7 = b2_6 + a3_1(D);
but that does not expose SSA_NAMEs with the same value.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:52 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #28 from dominiq at lps dot ens dot fr 2008-02-22 10:51 ---
First thanks for looking to the problem.
Second, all the machinery for adding $LDBL128 is provided by math.h (or in
fixincludes/tests/base/architecture/ppc/math.h). So the problem for languages
accepting to include
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:48 ---
Confirmed. DSE is too dumb for this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #27 from bonzini at gnu dot org 2008-02-22 10:47 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
> but the Fortran front-end apparently doesn't benefit from it:
From what I understand, you have to rebuild libgfortran. Did you do
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:47 ---
Confirmed. A re-written DSE and introduction of MEM_REF will fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:46 ---
This is related to PR34043 and will be fixed by tweaking SCCVN and the
introduction of MEM_REF.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
1 - 100 of 114 matches
Mail list logo
