--- Comment #8 from charlet at gcc dot gnu dot org 2008-02-22 08:02 ---
Sounds like something specific to RTEMS, since I've never seen something like
that on any other platform.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from ubizjak at gmail dot com 2008-02-22 08:23 ---
Hm, perhaps we should just put something like:
set_optab_libfunc (sin_optab, TFmode, sinl$LDBL128);
...
into rs6000_init_libfuncs()? At least this is what other targets do.
--
--- Comment #22 from bonzini at gnu dot org 2008-02-22 08:25 ---
You can call it at the end of rs6000_init_builtins, something like
#ifdef SUBTARGET_INIT_BUILTINS
SUBTARGET_INIT_BUILTINS;
#endif
and in config/rs6000/darwin.h
#define SUBTARGET_INIT_BUILTINS darwin_patch_builtins ()
--- Comment #9 from laurent at guerby dot net 2008-02-22 08:29 ---
Arnaud, do you have any idea on what to look at (interesting breakpoint and
data structures)? RTEMS tasking works on other platforms. May be some Ada/C
thread interface data structure has the wrong size in the case of
Arnaud, do you have any idea on what to look at (interesting breakpoint and
data structures)? RTEMS tasking works on other platforms. May be some Ada/C
thread interface data structure has the wrong size in the case of x86 and
things get corrupted (s-oisinte-rtems.ads).
I'd suggest putting a
--- Comment #10 from charlet at adacore dot com 2008-02-22 08:34 ---
Subject: Re: Branch to 0x0 from Ada run-time
Arnaud, do you have any idea on what to look at (interesting breakpoint and
data structures)? RTEMS tasking works on other platforms. May be some Ada/C
thread interface
--- Comment #23 from bonzini at gnu dot org 2008-02-22 08:39 ---
No, the math functions optabs are only used to invoke
define_insns/define_expands, not to create libcalls. If the optab says there
is no insn, the original CALL_EXPR is expanded which uses the builtin's
ASSEMBLER_NAME.
--- Comment #24 from ubizjak at gmail dot com 2008-02-22 09:28 ---
Hm, for some reason the obvious approach from c#16 doesn't work:
The patch:
--cut here--
Index: langhooks.c
===
--- langhooks.c (revision 132541)
+++
--- Comment #3 from jakub at gcc dot gnu dot org 2008-02-22 09:41 ---
Even the extra error in nontype16.C is IMHO wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-22 09:51 ---
For 4.3, guess ice-on-invalid is more acceptable than rejects-valid, unless we
have a real fix RSN, though I'll let Jason/Mark to decide.
We have everything else what I was waiting for on gcc-4_3-branch, so if we can
--- Comment #4 from pcarlini at suse dot de 2008-02-22 09:48 ---
Ok, I'm going to post a patch reverting completely the fix for 28743, and then
we'll see...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-22 10:44 ---
IMHO reverting the fix for PR28743 is the way to go (Paolo, you don't need
approval for reverting a patch of your own).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- 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
--- 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
--- 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
--- 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: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 #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 #26 from fxcoudert at gcc dot gnu dot org 2008-02-22 10:40
---
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.
--
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2008-02-22 10:21
---
Created an attachment (id=15206)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15206action=view)
Complete patch
That patch builds fine on powerpc-apple-darwin9.2.0. The C compiler generated
seems OK:
$
--- 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 #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:58 ---
Confirmed. This also blocks removal of store_ccp.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- 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=gccview=revrev=132543
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=gccview=revrev=132543
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=gccview=revrev=132544
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=gccview=revrev=132544
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=gccview=revrev=132545
Log:
/testsuite
2008-02-22 Paolo Carlini [EMAIL PROTECTED]
--- 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=gccview=revrev=132545
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 #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 #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 #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
--- 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 #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 fndecl
--- 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 #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 #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 #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 #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=15207action=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 #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 sinl
Compiling this simple function:
#include mmintrin.h
void foo()
{
_mm_srli_pi16(_mm_setzero_si64(), 8);
}
with the command line arm-angstrom-linux-gnueabi-gcc -c -O2 iwmmxt.cpp, results
in:
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
--- 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
--- 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 testcase
--- 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 #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
--- 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
--- 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 a
--- 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 #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 #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
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 #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
--- 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
--- 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 #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 #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
Hi,
the following code fails to compile with gcc-4.3-20080215
template class T=int, class... ARGS
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
--- 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_11c1tE
--- 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
--- 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 #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.
--
--- 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 #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
--
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 #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=15208action=view)
patch to include string.h and strings.h (stolen from libcpp)
Patch does not include generated files
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 #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=15209action=view)
Source file which triggers error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35298
--- 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
--- 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 #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=gccview=revrev=132560
Log:
2008-02-22 Andrew Pinski [EMAIL PROTECTED]
PR
--- 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
--- 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)?
--
--- 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=gccview=revrev=132558
Log:
2008-02-22 Andrew Pinski [EMAIL PROTECTED]
PR
--- 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
--- 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 #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.
--- 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
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))
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.3 4.4.0
Priority|P3 |P5
--- 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
--- 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
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
--- 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=15210action=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
--- 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=15211action=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 #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
It appears that CPP decides to stop expansion at some point.
Re-feeding the output to cpp iteratively peels macro levels.
#include stdlib.h
#include stdio.h
#define _(op, ...) op(__VA_ARGS__)
#define _if(expr, then, els) if (expr) { then; } else { els; }
#define progn(...) ({__VA_ARGS__;})
--- 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 _
--- 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
--- 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
--- 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-ld
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)
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
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
// 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
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
1 - 100 of 114 matches
Mail list logo
