h huge and highly
sophisticated software when I sent my first awful patch. It was
full of fun to participate in this great community. I've learned
what is the right thing and how it can be done on the list.
Thanks to all members of gcc community!
Best Regards,
kaz
--
2017-05
Joel Sherrill wrote:
> We have a few build failures on the RTEMS target where it appears
> that the -ml argument to make a relocatable is not turned into a
> -EL argument to ld by gcc 4.8.2.
>
> This is the output of invoking gcc with "-v". Below that I invoked
> the same LD command with -EL on t
Thomas Schwinge wrote:
> This is about sh and sh64 GDB sim testing for the whole toolchain. (I
> also do have sh4a hardware available, where testing is working fine.)
> Kaz, could you please have a look whether this looks basically sane, that
> my assumptions and the results I'm getting are about
Gerald Pfeifer wrote:
> Sure. Since you are a maintainer of this port/these ports, just
> ask Oleg to submit the new account form at
> http://sourceware.org/cgi-bin/pdw/ps_form.cgi
> and name you as a sponsor. (If Oleg already has an account on
> gcc.gnu.org/sourceware.org, ask overse...@gcc.g
Hi,
I'll sponsor Oleg Endo as a new write after approval maintainer.
He has written several good patches for SH targets and has filed
good PRs. He is working on the issues which will require larger
patches and being write after approval looks to be helpful.
His paper work with FSF has done. OK?
"Naveen H. S" wrote:
> The SH toolchain was built with the following patches and regression
> is completed.
> 1. sh-softfp-20100718-2131
> 2. sh-softfp-predicate-fix
> 3. Patch by Kaz Kojima-san at following link
> http://gcc.gnu.org/ml/gcc/2010-07/msg00352.html
Th
> Joern Rennecke wrote:
>> That's a bug, then; we shouldn't use a library function there,
>> but the cmpordered[sd]f_t_4 patterns.
>
> Argh, I've missed the required patterns are incorporated already
> in your patch. I'll test it again with sh-softfp-predicate-fix
> when the tests for 4.5.1-rc a
Joern Rennecke wrote:
> That's a bug, then; we shouldn't use a library function there,
> but the cmpordered[sd]f_t_4 patterns.
Argh, I've missed the required patterns are incorporated already
in your patch. I'll test it again with sh-softfp-predicate-fix
when the tests for 4.5.1-rc are done. Th
> 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.
There are a few warnings in bootstrap:
../trunk/gcc/config/sh/sh.c: In function 'sh_soft_fp_cmp':
../trunk
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
Joern Rennecke wrote:
> I don't have any sh[1234] hardware to EEMBC tests on, but the runtime
> difference of 'make check' on i686-pc-linux-gnu X sh-elf using a core2 quad
> for fp-bit vs. softfloat (w/ compare/conversion/divsf) is two hours 4 minutes
> versus 38 minutes.
Very impressive. Thanks
"Naveen H. S" wrote:
>>> you can free to propose a complete and regtested patch for SH
>>> assembly soft fp against trunk.
>
> Please find attached the ported soft float patch "sh_softfloat.patch".
> The original patch was posted at the following link by Joern RENNECKE.
> http://gcc.gnu.org/ml/
"Naveen H. S" wrote:
> Software floating point(libgcc) routines were implemented for SH in the
> following links:-
> http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00063.html
> http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00614.html
> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00624.html
>
> Ther
"Kaveh R. GHAZI" wrote:
> Please test this version and report back in this thread (not to me
> privately) the results of "make check". Also include your target triplet,
> and the versions of your compiler, gmp and mpfr.
===
All 57 tests passed
===
sh4-unknown-lin
"Kaveh R. GHAZI" wrote:
> Please test this MPC package and report back the results of running
> "make check" along with your target triplet, the compiler version you
> used, and the versions of gmp/mpfr used to compile it. You do not
> necessarily need to bootstrap mainline GCC with this MPC, but
Diego Novillo wrote:
> In preparation for the final merge into mainline. I need to test
> the branch on various platforms. Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
>
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
>
> $ svn c
Eric Botcazou wrote:
> Patch attached. I'll give it a whirl on SPARC but not immediately so, Kaz,
> if
> you can test it on SH in the meantime, you can apply it on all branches.
>
>
> 2009-07-14 Eric Botcazou
>
> PR rtl-optimization/40710
> * resource.c (mark_target_live_regs)
Steven Bosscher wrote:
> OK, so isn't the bug obvious then? You said: "mark_target_live_regs
> uses df_get_live_in to get live regs for the basic block including the
> opposite_thread insn which is insn 32.". And you had insn 32 in basic
> block 3. So find_basic_block returns the wrong basic block
[I'd like to add kenny to the CC list.]
Steven Bosscher wrote:
> So when the CFG is still valid, r15 is live-out in basic block 2 and
> live-in in basic block 3 (which contains insns 32, whatever that means
> for an invalid CFG). For which bb does mark_target_live_regs call
> df_get_live_in?
gdb
Hi,
I hope DF/middle-end experts will comment about this.
PR target/40710
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40710
is a wrong code problem on SH. A delayed slot of a conditional
branch insn is wrongly filled with an insn changing stack pointer
in the failing case. I've tried to see wh
Steven Bosscher wrote:
> Kaz, can you commit a patch for sh.c?
I've just applied the patch below.
Regards,
kaz
--
2009-05-08 Kaz Kojima
* config/sh/sh.c: Do not include c-pragma.h.
--- ORIG/trunk/gcc/config/sh/sh.c 2009-05-06 07:11:59.0 +0900
+++ t
Steven Bosscher wrote:
[snip]
> config/sh/sh.c:#include "c-pragma.h"
FYI, I've confirmed that there are no problems without
this line for sh4-unknown-linux-gnu.
Regards,
kaz
Steven Bosscher wrote:
>> sh64-unknown-elf-run will be there if sim was configured
>> for sh64-unknown-elf.
>
> Do I have to configure this explicitly?
>
> I just followed the instructions of
> http://gcc.gnu.org/simtest-howto.html. If something special must be
> done for sh64, perhaps you coul
Steven Bosscher wrote:
> Is there a simulator for SH64 available? If so, how do I run the
> testsuite with it? I built a cross-compiler from AMD64 to
> sh64-unknown-elf and tried to test on sh-sim (with "make -k check
> RUNTESTFLAGS=--target_board=sh-sim") but that doesn't work. Help?
sh64-unkn
Paolo Bonzini wrote:
> So you have that in the RTL stream we should canonicalize "a << 32" to
> "a", but "a << (b & 31)" is not the same as "a << b"?
Yes when the msb of b is set.
> Also, how is the sign bit is significant? Does it determine whether the
> value is left- or right-shifted?
Yep
Paolo Bonzini wrote:
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.
sh defines SHIFT_COUNT_TRUNCATED according to target
Diego Novillo <[EMAIL PROTECTED]> wrote:
> So, for folks with free cycles to spare, could you build the branch on
> your favourite target and report bugs? Bugzilla and/or email reports
> are OK. If you are creating a bugzilla report, please add my address to
> the CC field.
With the attached
"Joseph S. Myers" <[EMAIL PROTECTED]> wrote:
> Here is a draft FDPIC ABI for SH uClinux, based on the FR-V FDPIC ABI.
> Please send any comments; CodeSourcery will be implementing the final ABI
> version in GCC and Binutils.
Wow, great news!
One minor point I'm curious is the choice of the phy
> --- ORIG/trunk/gcc/config/sh/sh.h 2007-12-07 09:11:38.0 +0900
> +++ LOCAL/trunk/gcc/config/sh/sh.h2008-02-25 19:09:48.0 +0900
> @@ -553,7 +553,7 @@ do {
> \
> {
"Naveen H.S." <[EMAIL PROTECTED]> wrote:
> Yes, we completely agree that using the option "-mdalign" would solve
> the "address error" problem in the present testcase. We had tried the
> similar way to solve the problem. However, we observed that "-mdlaign"
> option would not guarantee the stack va
"Naveen H.S." <[EMAIL PROTECTED]> wrote:
> Yes, we got this error on SH72513(SH2A) hardware. When the same code
> is run on simulator, the "address error" occurs on encountering the
> "fmov.d" instruction.
[snip]
> It is mentioned that "Double longword data accessed from other than
> double longwo
"Naveen H.S." <[EMAIL PROTECTED]> wrote:
> The option "-mfmovd" is enabled by default for SH2A which generates
> "fmov.d" instruction by default. However, SH4 and SH4A targets
> generates "fmov.d" instruction only after passing the option "-mfmovd".
fmov.d has a byte order problem in little endia
DJ Delorie <[EMAIL PROTECTED]> wrote:
>> Is your gcc configured with --with-newlib --with-headers?
>
> $TOP/gcc/gcc/configure --prefix=$PREFIX --target=$TARGET \
> --enable-languages=c,c++ --with-newlib --with-mpfr=/usr/local
>
> I do a two-phase build. I build gcc (and let it fail for libgcc)
DJ Delorie <[EMAIL PROTECTED]> wrote:
> Is sh-elf/sim supposed to support profiling? My latest tests show all
> the profiling tests failing. For example, the bprob executable has
> the name of the gcda file in it, but doesn't attempt to write it out
> (verified with strace against the simulator).
"Andrew Pinski" <[EMAIL PROTECTED]> wrote:
>> on revision 126435. Anyone else sees this failure?
>
> Well this is obviously caused by:
> http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00617.html
>
> This is not the first time this has happened.
I've confirmed that x86 bootstraps again with revert
Hi,
My i686-pc-linux-gnu build fails with
libtool: link: /exp/ldroot/dodes/i686-gcc-orig/gcc/gcj
-B/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/
-B/exp/ldroot/dodes/i686-gcc-orig/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Conver
Hi,
I've noticed that some libjava tests fail for SH on trunk and
4.2.0 RC3.
New tests that FAIL:
Divide_1 -O3 -findirect-dispatch output - bytecode->native test
Divide_1 -O3 output - bytecode->native test
Divide_1 -O3 output - source compiled test
Divide_1 -findirect-dispatch output - bytecode-
"Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> In the mipsel-linux case, we ended up with a diamond region where the
> jump in the IF-block was folded, so that we could extend the path
> along one of the diamond's arms with the JOIN-block. This could
> happen because cse_main traversed the basic b
"Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> In that case, this is a different problem, probably caused by the new
> out-of-SSA pass. But to be sure, I suggest you revert my CSE patch
> and see if that makes the problem go away for you.
I've confirmed that that problem is remained after reverti
David Daney <[EMAIL PROTECTED]> wrote:
> From svn r119726 (Sun, 10 Dec 2006) I am getting an ICE during
> bootstrap on mipsel-linux. This is a new failure since Wed Dec 6
> 06:34:07 UTC 2006 (revision 119575) which bootstrapped and tested just
> fine. I don't really want to do a regression hu
Joern RENNECKE <[EMAIL PROTECTED]> wrote:
> My simulator now segfaults for every single execution test built with
> mainline; when I try gdb, it also segfaults,
> somewhere in the dwarf handling code.
> Unless someone comes up with a viable concept how to maintain sh64
> support in gcc, I think w
SUGIOKA Toshinobu <[EMAIL PROTECTED]> wrote:
> But now, "gcc -v -o hello hello.c" gives following output on linking phase.
>
> /usr/libexec/gcc/sh4-unknown-linux/4.1.0/collect2 --eh-frame-hdr -m
> shlelf_linux -dynamic-linker /lib/ld-linux.so.2 -o hello
> /usr/lib/gcc/sh4-unknown-linux/4.1.0/../
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> If these patches show an improvement on SH4, please go ahead and check
> them in. Please inform me of the status ASAP.
I've checked it in as 111792. Sorry for the delay.
Regards,
kaz
ted with bootstrap and
"make -k check" on i686-pc-linux-gnu with no new failures.
Although bootstrap on sh4-unknown-linux-gnu is on going, the result
of the toplevel "make -k check" on x86 cross sh4-unknown-linux-gnu
looks fine.
Regards,
kaz
--
2006-03-06Kaz K
Ian Lance Taylor wrote:
> In general, yes. But looking at it we should probably only call
> copy_to_reg if TARGET is not itself a pseudo-register.
>
> And I think I would put the new code before the "TARGET and VALREG
> cannot be equal" comment.
>
> That patch is OK if it works and passes testi
Ian Lance Taylor wrote:
> I don't see what this has to do with pure functions.
>
> It seems to me that instead you want to put something here:
>
> else if (target
> && GET_MODE (target) == TYPE_MODE (TREE_TYPE (exp))
> && GET_MODE (target) == GET_MODE (valreg))
>
Joern RENNECKE <[EMAIL PROTECTED]> wrote:
>>[.expand after the patch]
>>(set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7)))
>>(set (reg:SI 161) (plus:SI (reg:SI 12 r12) (reg/f:SI 160)))
>>(set (reg/f:SI 159) (mem/u/c:SI (reg:SI 161)))
>>(set (reg:SI 0 r0) (call (mem:SI (symbol_ref:
Hi,
I've tried to see what is gonig on for PR target/24445 which is
a 4.1 regression of SH.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
Comparing rtl dumps for the reduced testcase in the audit trail #4
of that PR with and without Jan's patch in #10, there is no return
value copy in the rt
Richard Henderson <[EMAIL PROTECTED]> wrote:
> Yes. We check peep2_current_count to validate this.
I'd like to take a look at why peep2_current_count doesn't work
as expected for the problematic case. Thanks for the suggestion.
Regards,
kaz
Hi,
I've got an ICE during glibc build with the current mainline on
sh4-unknown-linux-gnu:
../sysdeps/ieee754/flt-32/k_rem_pio2f.c: In function '__kernel_rem_pio2f':
../sysdeps/ieee754/flt-32/k_rem_pio2f.c:213: internal compiler error:
Segmentation fault
It doesn't fail with 20051003 compiler.
Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
>> sh libraries/configury Kaz Kojima [EMAIL PROTECTED]
>>
>> ?
>
> Looks fine.
Thanks! I'll send a patch to the list and check it in.
Regards,
kaz
Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> Yes -- and you can also include configure.gcc and Makefiles. ;-)
Ah. There is no room to include all, though. :-) How about
sh libraries/configury Kaz Kojima [EMAIL PROTECTED]
?
Regards,
kaz
[EMAIL PROTECTED]
sh portJoern Rennecke [EMAIL PROTECTED]
sh portAlexandre Oliva [EMAIL PROTECTED]
+sh libraries Kaz Kojima [EMAIL PROTECTED]
sparc port Richard Henderson [EMAIL PROTECTED]
sparc
bsdLoren J. Rittle [EMAIL PROTECTED]
netbsd Jason Thorpe[EMAIL PROTECTED]
sco5, unixware, sco udkKean Johnston [EMAIL PROTECTED]
-sh-linux-gnu Kaz Kojima [EMAIL PROTECTED]
+sh-linux-gnu, sh libs
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
OK for sh4-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00902.html
Regards,
kaz
> It's important to test the actual tarballs, rather than CVS, to check
> for any packaging issues. If you can, download and build the tarballs,
> post test results to the gcc-testresults mailing list with and
> contrib/test_summary.
sh4-unknown-linux-gnu is ok:
http://gcc.gnu.org/ml/gcc-testres
Joern RENNECKE <[EMAIL PROTECTED]> wrote:
> I can't justify spending the amount time that it would take to make the
> sh64 port regression free.
> The lack of a debugger that works reliably with recent gcc versions has
> led to an increasing
> backlog of uninvestigated execution failures.
Althou
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> GCC 4.0.1 RC3 is now available here:
>
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
>
> With luck, this will be the last 4.0.1 release candidate.
>
> Please do download tarballs from the above URL and confirm that they
> work OK on your sy
58 matches
Mail list logo
