--- 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.
--
http://gcc.gnu.org/bugzilla/show
--- 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 x86
> 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
--- 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 interfa
--- 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)
+++ langh
--- 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 include
--- 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 #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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- 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=15206&action=view)
Complete patch
That patch builds fine on powerpc-apple-darwin9.2.0. The C compiler generated
seems OK:
$ c
--- 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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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 att
--- 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 fnde
--- 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=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 #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
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
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
--- 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 testca
--- 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 ha
--- 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 #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 #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 proof-of-co
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 (thread=18
--- 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 #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 the
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 #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
--- 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 #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.
--
h
--- 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
As
--
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=15208&action=view)
patch to include string.h and strings.h (stolen from libcpp)
Patch does not include generated files (c
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=15209&action=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 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 #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 #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 #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 #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 #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 #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.
q
--- 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
http:/
--- 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
--- 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
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 #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
--- 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 #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
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 #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 don
--- 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 #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
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 b
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
