[PATCH,libstdc++] unwind-cxx.h: correct prototypes for ARM EH routines (PR libstdc++/44902)
The prototypes for two ARM EH routines don't match their actual
definitions in eh_arm.cc, resulting in build-time warnings. When
-Werror is active, the build fails. See PR44902.
Fixed simply by updating the prototypes to match the definitions.
Tested with crosses to arm-eabi and arm-linux-gnueabi, and with
a native bootstrap and regtest on arm-linux-gnueabi.
Ok for 4.6? 4.5? (I don't have svn write access.)
libstdc++-v3/
2010-07-20 Mikael Pettersson
PR libstdc++/44902
* libsupc++/unwind-cxx.h (__cxa_type_match): Correct prototype.
(__cxa_begin_cleanup): Likewise.
--- gcc-4.6-20100717/libstdc++-v3/libsupc++/unwind-cxx.h.~1~2009-05-03
18:51:50.0 +0200
+++ gcc-4.6-20100717/libstdc++-v3/libsupc++/unwind-cxx.h2010-07-20
11:18:42.0 +0200
@@ -196,9 +196,9 @@ typedef enum {
ctm_succeeded = 1,
ctm_succeeded_with_ptr_to_base = 2
} __cxa_type_match_result;
-extern "C" bool __cxa_type_match(_Unwind_Exception*, const std::type_info*,
-bool, void**);
-extern "C" void __cxa_begin_cleanup (_Unwind_Exception*);
+extern "C" __cxa_type_match_result __cxa_type_match(_Unwind_Exception*, const
std::type_info*,
+ bool, void**);
+extern "C" bool __cxa_begin_cleanup (_Unwind_Exception*);
extern "C" void __cxa_end_cleanup (void);
#endif
Re: [PATCH,libstdc++] unwind-cxx.h: correct prototypes for ARM EH routines (PR libstdc++/44902)
Mikael Pettersson writes:
> The prototypes for two ARM EH routines don't match their actual
> definitions in eh_arm.cc, resulting in build-time warnings. When
> -Werror is active, the build fails. See PR44902.
>
> Fixed simply by updating the prototypes to match the definitions.
>
> Tested with crosses to arm-eabi and arm-linux-gnueabi, and with
> a native bootstrap and regtest on arm-linux-gnueabi.
>
> Ok for 4.6? 4.5? (I don't have svn write access.)
>
> libstdc++-v3/
>
> 2010-07-20 Mikael Pettersson
>
> PR libstdc++/44902
> * libsupc++/unwind-cxx.h (__cxa_type_match): Correct prototype.
> (__cxa_begin_cleanup): Likewise.
Please ignore, I mistakenly cc:d gcc not gcc-patches.
>
> --- gcc-4.6-20100717/libstdc++-v3/libsupc++/unwind-cxx.h.~1~ 2009-05-03
> 18:51:50.0 +0200
> +++ gcc-4.6-20100717/libstdc++-v3/libsupc++/unwind-cxx.h 2010-07-20
> 11:18:42.0 +0200
> @@ -196,9 +196,9 @@ typedef enum {
>ctm_succeeded = 1,
>ctm_succeeded_with_ptr_to_base = 2
> } __cxa_type_match_result;
> -extern "C" bool __cxa_type_match(_Unwind_Exception*, const std::type_info*,
> - bool, void**);
> -extern "C" void __cxa_begin_cleanup (_Unwind_Exception*);
> +extern "C" __cxa_type_match_result __cxa_type_match(_Unwind_Exception*,
> const std::type_info*,
> +bool, void**);
> +extern "C" bool __cxa_begin_cleanup (_Unwind_Exception*);
> extern "C" void __cxa_end_cleanup (void);
> #endif
>
Re: SH optimized software floating point routines
Joern Rennecke wrote: > I've found two bugs in truncdfsf2; > I've also added back a number of hunks that Naveen had dropped. > > Note that most of the patch has been prepared in 2006, so that is the > proper most recent copyright date for those files that haven't been touched > save for swapping the Copyright notice. I've got some regressions with "make check" on sh4-unknown-linux-gnu. It looks that all of them are failed with the undefined references to __unorddf2/__unordsf2 when -mieee enabled. I'm trying the attached patch over sh-softfp-20100718-2131 patch. All regressions go away with it on cross sh4-unknown-linux-gnu, though the native bootstrap will take a few days more. BTW, it looks that softfp __unord?f2 routines check signaling NaNs only. This makes __builtin_isnan return false for quiet NaNs for which current fp-bit ones return true when -mieee enabled. Perhaps that change of behavior might be OK for software FP. Regards, kaz -- diff -uprN ORIG/trunk/gcc/config/sh/ieee-754-df.S trunk/gcc/config/sh/ieee-754-df.S --- ORIG/trunk/gcc/config/sh/ieee-754-df.S 2010-07-20 11:39:29.0 +0900 +++ trunk/gcc/config/sh/ieee-754-df.S 2010-07-20 11:36:15.0 +0900 @@ -23,11 +23,11 @@ see the files COPYING3 and COPYING.RUNTI !! STMicroelectronics ST40 CPUs !! Contributed by J"orn Rennecke joern.renne...@st.com -#ifndef __SH_FPU_DOUBLE__ - #include "lib1funcs.h" #include "insn-constants.h" +#ifndef __SH_FPU_DOUBLE__ + /* Double-precision floating-point emulation. We handle NANs, +-infinity, and +-zero. However, we assume that for NANs, the topmost bit of the fraction is set. */ @@ -123,7 +123,7 @@ GLOBAL(unorddf2): mov.l LOCAL(c_DF_NAN_MASK),r1 not DBL0H,r0 tst r1,r0 - not r6,r0 + not DBL1H,r0 bt LOCAL(unord) tst r1,r0 LOCAL(unord): @@ -788,4 +788,52 @@ LOCAL(x7ff8): #endif /* L_divdf3 */ #endif /* DYN_SHIFT */ +#else /* __SH_FPU_DOUBLE__ */ + +#ifdef L_unorddf2 + .balign 4 + .global GLOBAL(unorddf2) + FUNC(GLOBAL(unorddf2)) +GLOBAL(unorddf2): + fldsfr4,fpul + sts fpul,r4 + shllr4 + mov.l LOCAL(c_DF_QNAN_MASK),r1 + shlrr4 + cmp/eq r4,r1 + bf/sLOCAL(unord_check_qnan0) + fldsfr5,fpul + sts fpul,r5 + tst r5,r5 + bt LOCAL(unord_next) +LOCAL(unord_check_qnan0): + not r4,r0 + tst r1,r0 + bt LOCAL(unord) +LOCAL(unord_next): + fldsfr6,fpul + sts fpul,r6 + shllr6 + shlrr6 + cmp/eq r6,r1 + bf/sLOCAL(unord_check_qnan1) + fldsfr7,fpul + sts fpul,r7 + tst r7,r7 + bt LOCAL(unord_fail) +LOCAL(unord_check_qnan1): + not r6,r0 + tst r1,r0 +LOCAL(unord): + rts + movtr0 +LOCAL(unord_fail): + rts + mov #0,r0 + .balign 4 +LOCAL(c_DF_QNAN_MASK): + .long 0x7ff0 + ENDFUNC(GLOBAL(unorddf2)) +#endif /* L_unorddf2 */ + #endif /* __SH_FPU_DOUBLE__ */ diff -uprN ORIG/trunk/gcc/config/sh/ieee-754-sf.S trunk/gcc/config/sh/ieee-754-sf.S --- ORIG/trunk/gcc/config/sh/ieee-754-sf.S 2010-07-20 11:39:30.0 +0900 +++ trunk/gcc/config/sh/ieee-754-sf.S 2010-07-20 11:35:58.0 +0900 @@ -23,11 +23,11 @@ see the files COPYING3 and COPYING.RUNTI !! STMicroelectronics ST40 CPUs !! Contributed by J"orn Rennecke joern.renne...@st.com -#ifndef __SH_FPU_ANY__ - #include "lib1funcs.h" #include "insn-constants.h" +#ifndef __SH_FPU_ANY__ + /* Single-precision floating-point emulation. We handle NANs, +-infinity, and +-zero. However, we assume that for NANs, the topmost bit of the fraction is set. */ @@ -689,4 +689,42 @@ LOCAL(tab): #endif /* L_hypotf */ #endif /* DYN_SHIFT */ +#else /* __SH_FPU_ANY__ */ + +#ifdef L_unordsf2 + .balign 4 + .global GLOBAL(unordsf2) + FUNC(GLOBAL(unordsf2)) +GLOBAL(unordsf2): + fldsfr5,fpul + sts fpul,r4 + shllr4 + mov.l LOCAL(c_SF_QNAN_MASK),r1 + shlrr4 + cmp/eq r4,r1 + bt/sLOCAL(unord_next) + not r4,r0 + tst r1,r0 + bt LOCAL(unord) +LOCAL(unord_next): + fldsfr4,fpul + sts fpul,r5 + shllr5 + shlrr5 + cmp/eq r5,r1 + bt/sLOCAL(unord_fail) + not r5,r0 + tst r1,r0 +LOCAL(unord): + rts + movtr0 +LOCAL(unord_fail): + rts + mov #0,r0 + .balign 4 +LOCAL(c_SF_QNAN_MASK): + .long 0x7f80 + ENDFUNC(GLOBAL(unordsf2)) +#endif /* L_unordsf2 */ + #endif /* __SH_FPU_ANY__ */
Reload problems with only one base reg for "base + offset" addressing mode
Hi,
I am porting GCC to a 8bit architecture, and now I have problem on
reload problem on addressing mode.
Besides 15 general registers, it has three 16bit address registers,
R16,R17,R18.
R16,R17,R18 are able to be as base register in "base" address mode,
but only R18 can be base regs for "base+offse(immediate)t" address
mode.
I make "BASE_REGS" class for "R16,R17,R18", and "POINTER_REG" class
for R18, and frame pointer is R18, the maxim "offset" in "base+offset"
is 127.
And now the test compiler sometimes generate following errors:
test3.c: In function 'OS_EventTaskWait':
test3.c:62: error: unable to find a register to spill in class 'POINTER_REG'
test3.c:62: error: this is the insn:
(insn 58 57 61 2 (set (mem/s:QI (plus:HI (reg:HI 16 R16 [51])
(const_int 5 [0x5])) [0 .OSEventTbl S1 A8])
(ior:QI (mem/s:QI (plus:HI (reg:HI 16 R16 [51])
(const_int 5 [0x5])) [0 .OSEventTbl S1 A8])
(mem/s:QI (plus:HI (reg:HI 17 R17 [orig:38 OSTCBCur.0 ] [38])
(const_int 14 [0xe])) [0 .OSTCBBitX+0 S1
A8]))) 25 {*iorqi3_noimm} (insn_list:REG_DEP_TRUE 51 (nil))
(expr_list:REG_DEAD (reg:HI 17 R17 [orig:38 OSTCBCur.0 ] [38])
(expr_list:REG_DEAD (reg:HI 16 R16 [51])
test3.c:62: confused by earlier errors, bailing out.
It seems that the reload tries to reload "R16+5" and "R17+114" to be
"R18+5" and "R17+14", but complains that there is only on R18.
I have constraint the base reg of "base+offset(immediate)" address
mode in "GO_IF_LEGITIMATE_ADDRESS", and defined
LEGITIMIZE_RELOAD_ADDRESS (I take reference from AVR port).
#define LEGITIMIZE_RELOAD_ADDRESS(X, MODE, OPNUM, TYPE, IND_LEVELS, WIN)\
do \
{
\
debug_rtx(X); \
printf("LEGITIMIZE_RELOAD_ADDRESS,frame ptr
needed=%d\r\n",frame_pointer_needed);\
if (GET_CODE (X) == PLUS \
&& REG_P (XEXP (X, 0))
\
&& GET_CODE (XEXP (X, 1)) == CONST_INT
\
&& INTVAL (XEXP (X, 1)) >= 1)
\
{
\
int fit = INTVAL (XEXP (X, 1)) <= (127 - GET_MODE_SIZE (MODE)); \
if (fit )
\
{\
if( !FRAME_POINTER_REQUIRED ) \
{
\
if (reg_equiv_address[REGNO (XEXP (X, 0))] != 0)
\
{
\
int regno = REGNO (XEXP (X, 0));
\
rtx mem = make_memloc (X, regno);
\
push_reload(XEXP (mem,0), NULL, &XEXP (mem,0), NULL,
\
BASE_REGS, Pmode, VOIDmode, 0, 0,
\
1, ADDR_TYPE (TYPE));
\
push_reload(mem, NULL_RTX, &XEXP (X, 0), NULL, \
POINTER_REG, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN;
\
}
\
push_reload(XEXP (X, 0), NULL_RTX, &XEXP (X, 0), NULL, \
POINTER_REG, GET_MODE (X), VOIDmode, 0, 0,\
OPNUM, TYPE); \
goto WIN; \
}\
else\
{\
push_reload (X, NULL_RTX, &X, NULL, \
BASE_REGS, GET_MODE (X), VOIDmode, 0, 0,\
OPNUM, TYPE); \
goto WIN; \
}\
}\
else if (! (frame_pointer_needed && XEXP (X,0) == frame_pointer_rtx)) \
{
\
push_reload (X, NULL_RTX, &X, NULL,\
BASE_REGS, GET_MODE (X), VOIDmode, 0, 0, \
Re: Reload problems with only one base reg for "base + offset" addressing mode
redriver jiang writes:
> I am porting GCC to a 8bit architecture, and now I have problem on
> reload problem on addressing mode.
> Besides 15 general registers, it has three 16bit address registers,
> R16,R17,R18.
> R16,R17,R18 are able to be as base register in "base" address mode,
> but only R18 can be base regs for "base+offse(immediate)t" address
> mode.
> I make "BASE_REGS" class for "R16,R17,R18", and "POINTER_REG" class
> for R18, and frame pointer is R18, the maxim "offset" in "base+offset"
> is 127.
>
> And now the test compiler sometimes generate following errors:
>
> test3.c: In function 'OS_EventTaskWait':
> test3.c:62: error: unable to find a register to spill in class 'POINTER_REG'
> test3.c:62: error: this is the insn:
> (insn 58 57 61 2 (set (mem/s:QI (plus:HI (reg:HI 16 R16 [51])
> (const_int 5 [0x5])) [0 .OSEventTbl S1 A8])
> (ior:QI (mem/s:QI (plus:HI (reg:HI 16 R16 [51])
> (const_int 5 [0x5])) [0 .OSEventTbl S1 A8])
> (mem/s:QI (plus:HI (reg:HI 17 R17 [orig:38 OSTCBCur.0 ] [38])
> (const_int 14 [0xe])) [0 .OSTCBBitX+0 S1
> A8]))) 25 {*iorqi3_noimm} (insn_list:REG_DEP_TRUE 51 (nil))
> (expr_list:REG_DEAD (reg:HI 17 R17 [orig:38 OSTCBCur.0 ] [38])
> (expr_list:REG_DEAD (reg:HI 16 R16 [51])
> test3.c:62: confused by earlier errors, bailing out.
You should be able to fix this by using constraints. Define a
constraint which uses the base register and define one which permits one
of the indirect registers. Write different alternatives such that only
one operand uses the base register in each alternative. Then reload
should be able to pick the best one, and reload the other addresses into
the indirect register.
Ian
Re: Microblaze PIC problem
Chris Wulff wrote: I'm trying to track down a bug in the -fPIC support for microblaze. I'm currently using the gcc 4.1.2 tree from the Xilinx git repository but the microblaze 4.5 branch from svn shows the same symptom. It appears that what is going on is that it is creating a non-PIC symbol_ref instead of the correct one. (It actually compiles with gcc 3, but I think it creates a non-PIC reference directly to the symbol as it just doesn't have that assertion.) My questions are these (more details below): 1) When doing PIC, should REG_EQUIV or REG_EQUAL notes still refer to the original symbol_ref or should they contain the PIC expression? 2) Or should the PIC expression be re-inserted in some later phase? 3) Does it look like I'm even looking in the right area? I'm still learning my way around the gcc codebase but my current understanding is that the "global_alloc" or "reload" code can just replace the pseudo-register with the REG_EQUIV note if it can't keep the register around. Chris -- Your last point is correct, but this only happens if there is no suitable register. I'll take a look at your diagnostics and see if I can make some sense of what is going on. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
C++ template issue in gcc 4.5.0 (Linux)
Hi,
after tracking down an issue [1] in dvisvgm [2] related to GCC 4.5.0, it
turned out that GCC 4.5.0 doesn't handle sub-classes defined and
instantiated in a template's method properly. At least on x86_64 Linux
systems, the code listed below leads to a segfault, while it works on
Windows/MinGW (x64). I built it with "g++ -g f1.cpp f2.cpp main.cpp".
valgrind backtrace:
==12833== Process terminating with default action of signal 11 (SIGSEGV)
==12833== Bad permissions for mapped region at address 0x0
==12833==at 0x0: ???
==12833==by 0x400C9B: C::doit() (c.h:22)
==12833==by 0x400B77: f2() (f2.cpp:6)
==12833==by 0x400D65: main (main.cpp:7)
Does anybody know if this is a known issue, or should I file a bug report?
Regards,
Martin
[1]
http://sourceforge.net/tracker/?func=detail&aid=3031498&group_id=145640&atid=762580
[2] http://dvisvgm.sourceforge.net
main.cpp
#include "f1.h"
#include "f2.h"
int main () {
f1();
f2();
}
f1.h
#ifndef F1_H
#define F1_H
void f1 ();
#endif
f1.cpp
#include "f1.h"
#include "c.h"
void f1 () {
C c;
c.doit();
}
f2.h
#ifndef F2_H
#define F2_H
void f2 ();
#endif
f2.cpp
#include "f2.h"
#include "c.h"
void f2 () {
C c;
c.doit();
}
c.h
#ifndef C_H
#define C_H
#include
template
class C
{
public:
struct Actions {
virtual ~Actions () {}
virtual void fail () {}
};
void doit () {
struct DoitActions : Actions {
void fail () {
std::cout << "hello\n";
}
} actions;
perform_actions(actions);
}
void perform_actions (Actions &actions) {
actions.fail();
}
};
#endif
Re: C++ template issue in gcc 4.5.0 (Linux)
On 20 July 2010 01:36, Martin Gieseking wrote: > Does anybody know if this is a known issue, or should I file a bug report? Please file a bug report, if it's a known issue someone will mark it as a duplicate.
Re: C++ template issue in gcc 4.5.0 (Linux)
Am 20.07.2010 19:24, schrieb Jonathan Wakely: > On 20 July 2010 01:36, Martin Gieseking wrote: >> Does anybody know if this is a known issue, or should I file a bug report? > > Please file a bug report, if it's a known issue someone will mark it > as a duplicate. Done (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45008). Thanks for the advice. Martin
gcc-4.4-20100720 is now available
Snapshot gcc-4.4-20100720 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100720/ 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-4_4-branch revision 162355 You'll find: gcc-4.4-20100720.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100720.tar.bz2 C front end and core compiler gcc-ada-4.4-20100720.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100720.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100720.tar.bz2 C++ front end and runtime gcc-java-4.4-20100720.tar.bz2 Java front end and runtime gcc-objc-4.4-20100720.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100720.tar.bz2The GCC testsuite Diffs from 4.4-20100713 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
why are multiply-accumulate insns not used when -mfp32 on mips
HI: found mult-acc insns like madd.s/d are only used when -mfp64 is specified, as to codes, there macros defined as: #define ISA_HAS_FP4 ((ISA_MIPS4 \ || (ISA_MIPS32R2 && TARGET_FLOAT64) \ <--only float 64 || ISA_MIPS64 \ || ISA_MIPS64R2) \ && !TARGET_MIPS16) #define ISA_HAS_FP_MADD4_MSUB4 ISA_HAS_FP4 why not use madd when fp32? Is there anything special with fp32? any clarification? Thanks very much -- Best Regards.
