Re: [PATCH] PowerPC VLE port
;; Return 1 if op is an operand that can be loaded via the GOT.
-;; or non-special register register field no cr0
(define_predicate "got_operand"
(match_code "symbol_ref,const,label_ref"))
Most likely should be submitted and committed (as obvious) separately.
Yes, will do.
switch (mode)
{
- case QImode:
+case QImode:
case HImode:
if (dest == NULL)
dest = gen_reg_rtx (mode);
Likewise.
Will do.
case 'Q':
- if (TARGET_MFCRF)
- fputc (',', file);
-/* FALLTHRU */
- else
+ if (! TARGET_MFCRF)
return;
+ fputc (',', file);
+ /* FALLTHRU */
case 'R':
/* X is a CR register. Print the mask for `mtcrf'. */
Likewise.
Will do.
/* Return the string to output a conditional branch to LABEL, which is
- the operand number of the label, or -1 if the branch is really a
+ the operand template of the label, or NULL if the branch is really a
conditional return.
OP is the conditional expression. XEXP (OP, 0) is assumed to be a
This looks like it should be done separately also.
OK.
+bool
+valid_vle_sd4_field (rtx mem, enum machine_mode mode)
No comment before this function.
I'll fix that.
- (simple_return "")])
+ (simple_return "1")])
Submitted separately it looks.
Sure.
libgcc/longlong.h
Gets sync'd with glibc's version sometimes.
Are you asking me to change something here?
Also have you thought have just adding a vle.md for all the needed
patterns and disabling the patterns in rs6000.md for VLE and not using
%^/%+/%- ? I think that would have been a cleaner implementation of
vle than adding support for it to the current patterns. Also does not
have the maintenance issue of always having to check if a new pattern
needs the %^/%+/%-.
The idea was discussed. A disadvantage is the code duplication it
would cause, which is also a maintenance headache. So we opted for the
current implementation. If the mainstream development causes a problem
for VLE it will be up to those interested in VLE to correct %^ etc.
--
Jim Lemke
Mentor Graphics / CodeSourcery
Orillia Ontario, +1-613-963-1073
Re: [PATCH] PowerPC VLE port
On 10/19/2012 02:52 PM, David Edelsohn wrote: How do you want to move forward with the VLE patch? Can you localize more of the changes? David, I have been distracted by other tasks. I expect to revisit VLE this week. However, I won't be able to invest much more time on VLE. I'll look at what else I can do. -- Jim Lemke Mentor Graphics / CodeSourcery Orillia Ontario, +1-613-963-1073
[PATCH] testsuite/lib/gcc-defs.exp (dg-additional-files-options)
Change dg-additional-files to match the behaviour of dg-additional-sources.
This fix has been in the CS trunk for 2 months without problem.
It's fairly obvious so I'll commit in the next day or two unless there are
objections.
--
Jim Lemke
Mentor Graphics / CodeSourcery
Orillia Ontario
2013-11-04 James Lemke
* lib/gcc-defs.exp (dg-additional-files-options): Extend regsub for
dg-additional-files to also match BOL.
Index: lib/gcc-defs.exp
===
--- lib/gcc-defs.exp (revision 204355)
+++ lib/gcc-defs.exp (working copy)
@@ -245,7 +245,7 @@
set additional_sources ""
}
if { $additional_files != "" } then {
- regsub -all " " $additional_files " [file dirname $source]/" additional_files
+ regsub -all "^| " $additional_files " [file dirname $source]/" additional_files
set to_download [concat $to_download $additional_files]
set additional_files ""
}
[PATCH] Add CFI entries for ARM Linux idiv0 / ldiv0
A divide by zero exception was not giving a proper traceback for LINUX
ARM_EABI. The attached patch fixes the problem on trunk (and several
local branches).
Tested on gcc-trunk for arm-none-linux-gnueabi.
OK to commit?
--
Jim Lemke, GNU Tools Sourcerer
Mentor Graphics / CodeSourcery
Orillia, Ontario
2015-06-16 James Lemke
libgcc/config/arm/
* lib1funcs.S (aeabi_idiv0, aeabi_ldiv0): Add CFI entries for
Linux ARM_EABI.
Index: libgcc/config/arm/lib1funcs.S
===
--- libgcc/config/arm/lib1funcs.S (revision 224523)
+++ libgcc/config/arm/lib1funcs.S (working copy)
@@ -1336,23 +1336,30 @@ LSYM(Lover12):
#define SIGFPE 8
#ifdef __ARM_EABI__
+ cfi_start __aeabi_ldiv0, LSYM(Lend_aeabi_ldiv0)
WEAK aeabi_idiv0
WEAK aeabi_ldiv0
ARM_FUNC_START aeabi_idiv0
ARM_FUNC_START aeabi_ldiv0
+ do_push {r1, lr}
+98: cfi_push 98b - __aeabi_ldiv0, 0xe, -0x4, 0x8
#else
+ cfi_start __div0, LSYM(Lend_div0)
ARM_FUNC_START div0
+ do_push {r1, lr}
+98: cfi_push 98b - __div0, 0xe, -0x4, 0x8
#endif
- do_push {r1, lr}
mov r0, #SIGFPE
bl SYM(raise) __PLT__
- RETLDM r1
+ RETLDM r1 unwind=98b
#ifdef __ARM_EABI__
+ cfi_end LSYM(Lend_aeabi_ldiv0)
FUNC_END aeabi_ldiv0
FUNC_END aeabi_idiv0
#else
+ cfi_end LSYM(Lend_div0)
FUNC_END div0
#endif
Fwd: [PATCH] Add CFI entries for ARM Linux idiv0 / ldiv0
Ping..
Forwarded Message
Subject: [PATCH] Add CFI entries for ARM Linux idiv0 / ldiv0
Date: Tue, 16 Jun 2015 17:25:49 -0400
From: James Lemke
To: gcc-patches@gcc.gnu.org
A divide by zero exception was not giving a proper traceback for LINUX
ARM_EABI. The attached patch fixes the problem on trunk (and several
local branches).
Tested on gcc-trunk for arm-none-linux-gnueabi.
OK to commit?
--
Jim Lemke, GNU Tools Sourcerer
Mentor Graphics / CodeSourcery
Orillia, Ontario
2015-06-16 James Lemke
libgcc/config/arm/
* lib1funcs.S (aeabi_idiv0, aeabi_ldiv0): Add CFI entries for
Linux ARM_EABI.
Index: libgcc/config/arm/lib1funcs.S
===
--- libgcc/config/arm/lib1funcs.S (revision 224523)
+++ libgcc/config/arm/lib1funcs.S (working copy)
@@ -1336,23 +1336,30 @@ LSYM(Lover12):
#define SIGFPE 8
#ifdef __ARM_EABI__
+ cfi_start __aeabi_ldiv0, LSYM(Lend_aeabi_ldiv0)
WEAK aeabi_idiv0
WEAK aeabi_ldiv0
ARM_FUNC_START aeabi_idiv0
ARM_FUNC_START aeabi_ldiv0
+ do_push {r1, lr}
+98: cfi_push 98b - __aeabi_ldiv0, 0xe, -0x4, 0x8
#else
+ cfi_start __div0, LSYM(Lend_div0)
ARM_FUNC_START div0
+ do_push {r1, lr}
+98: cfi_push 98b - __div0, 0xe, -0x4, 0x8
#endif
- do_push {r1, lr}
mov r0, #SIGFPE
bl SYM(raise) __PLT__
- RETLDM r1
+ RETLDM r1 unwind=98b
#ifdef __ARM_EABI__
+ cfi_end LSYM(Lend_aeabi_ldiv0)
FUNC_END aeabi_ldiv0
FUNC_END aeabi_idiv0
#else
+ cfi_end LSYM(Lend_div0)
FUNC_END div0
#endif
Re: [PATCH] Add CFI entries for ARM Linux idiv0 / ldiv0
Tested on gcc-trunk for arm-none-linux-gnueabi. OK to commit? 2015-06-16 James Lemke libgcc/config/arm/ * lib1funcs.S (aeabi_idiv0, aeabi_ldiv0): Add CFI entries for Linux ARM_EABI. s/for Linux ARM EABI// given you handle both __ARM_EABI__ and the not __ARM_EABI__ targets in the source. This is OK if no regressions. I saw no regressions for arm-none-linux-gnueabi. However, I don't have access to a non-eabi linux target. Shall I commit with the non-eabi portions or remove them? Jim. -- Jim Lemke, GNU Tools Sourcerer Mentor Graphics / CodeSourcery Orillia, Ontario
Re: [PATCH] Add CFI entries for ARM Linux idiv0 / ldiv0
On 06/23/2015 12:22 PM, Ramana Radhakrishnan wrote: I have no access to a non-EABI arm target to test this, not sure if there are any intree anymore (probably vxworks ?) . It looks sane on a read - just apply it and look after regressions if anything gets reported in bugzilla. Thanks Ramana. I will change the CL entry as you suggested. Jim. -- Jim Lemke, GNU Tools Sourcerer Mentor Graphics / CodeSourcery Orillia, Ontario
Re: [PATCH] PowerPC VLE port
On 09/06/2012 06:09 PM, Andrew Pinski wrote: Could you explain why you are changing system.h ? That was a convenience to me at one point. It should have been deleted from the patch set. -- Jim Lemke Mentor Graphics / CodeSourcery Orillia Ontario, +1-613-963-1073
Re: [PATCH] PowerPC VLE port
On 09/06/2012 07:07 PM, Joseph S. Myers wrote: The -t* options added duplicate -mcpu= options; the only existing precedent appears to be arm-vxworks and I don't think the options are appropriate for generic PowerPC target files (not specific to an OS port such as VxWorks with its own special selection of multilibs). Instead, it would be better to make the -mcpu= options imply appropriate other options. Agreed. I will remove the -t* options. -- Jim Lemke Mentor Graphics / CodeSourcery Orillia Ontario, +1-613-963-1073
Re: [PATCH] PowerPC VLE port
On 09/07/2012 07:52 PM, David Edelsohn wrote: This patch contains a lot of unnecessary, gratuitous changes in addition to being very invasive. It was not edited and cleaned sufficiently before posting. It has too much of a negative impact on the current PowerPC port. The patch is not going to be accepted in its current form. David, What are your thoughts on how to move forward. -- Jim Lemke Mentor Graphics / CodeSourcery Orillia Ontario, +1-613-963-1073
