Re: Deprecating nds32-*-linux-* target for GCC 14 (and removing it for GCC 15)
On 2023/12/12 07:43 UTC+8, Jeff Law via Gcc wrote: On 12/11/23 16:19, Andrew Pinski via Gcc wrote: nds32 support in Linux was removed last year: https://www.phoronix.com/news/Andes-Tech-NDS32-Removal The support for glibc never made it upstream as far as I can tell either. What are others thoughts on this? I believe the architecture is dead, so I wouldn't lose any sleep if it got deprecated across the board. While my tester includes nds32le-elf and nds32be-elf, there's no gdbsim, so those targets don't provide much, if any, additional coverage over targets in the tester. Jeff Hi Jeff, As for gdbsim/openocd, I remember that we did have nds32 contributions previously: - gdb: http://sourceware.org/ml/gdb-patches/2013-07/msg00223.html - openocd: http://openocd.zylin.com/1259 I suppose they have recently been dropped from the current gdb/openocd repository due to the lack of maintenance. I will reach out to Andes members to inquire whether the architecture is still considered to be available in gdb/openocd. Regards, jasonwucj
Re: Deprecating nds32-*-linux-* target for GCC 14 (and removing it for GCC 15)
On 2023/12/12 07:43 UTC+8, Jeff Law via Gcc wrote: On 12/11/23 16:19, Andrew Pinski via Gcc wrote: nds32 support in Linux was removed last year: https://www.phoronix.com/news/Andes-Tech-NDS32-Removal The support for glibc never made it upstream as far as I can tell either. What are others thoughts on this? I believe the architecture is dead, so I wouldn't lose any sleep if it got deprecated across the board. While my tester includes nds32le-elf and nds32be-elf, there's no gdbsim, so those targets don't provide much, if any, additional coverage over targets in the tester. Jeff Hi Jeff & Andrew, After a brief discussion with the previous maintainers of the Linux nds32 port, it is reasonable to deprecate nds32-linux for GCC 14 and remove it for GCC 15. However, considering that there are still customers relying on nds32le-elf and nds32be-elf for their embedded systems, it would be great to keep nds32le-elf and nds32be-elf in the GCC/binutils-gdb/newlib-cygwin repository. Regards, jasonwucj
Re: GCC 8.1 Release Candidate available from gcc.gnu.org
Jakub Jelinek on 2018/4/25 18:04 wrote: https://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425/ The first release candidate for GCC 8.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425 and shortly its mirrors. It has been generated from SVN revision 259636. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.1 on Wednesday, May 2nd. Hi, Jakub, There are 5 nds32-specific patches in the mainline to fix incorrect assembly code output: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01201.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01202.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01203.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01204.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01205.html I would like to have them in the gcc-8-branch before GCC 8.1 is released. Are those patches OK to be backported from mainline? Best regards, jasonwucj
Re: gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
Sorry there is a typo on step 2 command... 2014-03-27 13:36 GMT+08:00 Chung-Ju Wu : > > 2. Build them by your own: > (As usual, separating build folder and source folder is recommended.) > > $ /path/to/src/automake-1.11.1/configure --prefix=/path/to/local > $ make > $ make install > > $ /path/to/src/automake-2.64/configure --prefix=/path/to/local typo fix : $ /path/to/src/autoconf-2.64/configure --prefix=/path/to/local > $ make > $ make install > Best regards, jasonwucj
Re: gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
2014-03-26 18:24 GMT+08:00 Svante Signell :
> Hi,
>
> With the recent changes of not using automake for the build, only
> auto{re}conf I have problems generating an updated Makefile.in from a
> modified Makfile.am. Source is gcc-4.9-4.9-20140322
>
For gcc-4.9, I always use automake-1.11.1 and autoconf-2.64
to regenerate 'configure' and 'Makefile.in' content.
The following are my steps:
1. Download automake-1.11.1 and autoconf-2.64 from:
http://ftp.gnu.org/gnu/automake/
http://ftp.gnu.org/gnu/autoconf/
2. Build them by your own:
(As usual, separating build folder and source folder is recommended.)
$ /path/to/src/automake-1.11.1/configure --prefix=/path/to/local
$ make
$ make install
$ /path/to/src/automake-2.64/configure --prefix=/path/to/local
$ make
$ make install
3. Suppose you have modified libgo/configure.ac and libgo/Makefile.am.
After you 'cd gcc-4.9.0/libgo/', you can use:
(To simply generate configure from a modified configure.ac)
$ PATH=/path/to/local/bin:$PATH autoconf
(To simply generate Makefile.in from a modified Makefile.am)
$ PATH=/path/to/local/bin:$PATH automake
(To generate both configure and Makefile.in)
$ PATH=/path/to/local/bin:$PATH autoreconf
Hope it helps.
Best regards,
jasonwucj
Re: Controling reloads of movsicc pattern
2013/12/4 BELBACHIR Selim :
> Hi,
>
> My target has :
> - 2 registers class to store SImode (like m68k, data $D & address $A).
> - moves from wide offset MEM to $D or $A (ex: mov d($A1+50),$A2 ormov
> d($A1+50),$D1)
> - conditional moves from offset MEM to $D or $A but with a restriction :
> offset MEM conditionally moved to $A has a limited offset of 0 or 1
> (ex: mov.ifEQ d($A1,1),$A1 whereas we can still do mov.ifEQ d($A1,50),$D1)
>
> The predicate of movsicc pattern tells GCC that wide offset MEM is allowed
> and constraints describe 2 alternatives for 'wide offset MEM -> $D ' and
> 'restricted offset MEM -> $A" :
>
> (define_insn_and_split "movsicc_internal"
> [(set (match_operand:SI 0 "register_operand" "=a,d,m,a,d,m,a,d,m")
> (if_then_else:SI
> (match_operator 1 "prism_comparison_operator"
>[(match_operand 4 "cc_register" "") (const_int 0)])
> (match_operand:SI 2 "nonimmediate_operand" " v,m,r,0,0,0,v,m,r")
>;; "v" constraint is for restricted offset MEM
> (match_operand:SI 3 " nonimmediate_operand" "
> 0,0,0,v,m,r,v,m,r")))] ;; the last 3 alternatives are split to match the
> other alternatives
>
>
>
> I encountered : (on gcc4.7.3)
>
> core_main.c:354:1: error: insn does not satisfy its constraints:
> (insn 1176 1175 337 26 (set (reg:SI 5 $A5)
> (if_then_else:SI (ne (reg:CC 56 $CCI)
> (const_int 0 [0]))
> (mem/c:SI (plus:SI (reg/f:SI 0 $A0)
> (const_int 2104 [0x838])) [9 %sfp+2104 S4 A32])
> (const_int 1 [0x1]))) core_main.c:211:32 158 {movsicc_internal}
>
> Due to reload pass (core_main.c.199r.reload).
>
>
> How can I tune reload or write my movsicc pattern to prevent reload pass from
> generating a conditional move from wide offset MEM to $A registers ??
>
>Regards,
>
>
> Selim
Hi, Selim,
I think you can try to trace the flow and see how the (mem ...) and
(const_int 1)
were created for movsicc_internal pattern. It is very strange that
(const_int 1)
appears while you have "nonimmediate_operand" predicate for operands[3].
Best regards,
jasonwucj
Re: [Suggestion] about h8/300 architecture in gcc and binutils
2013/9/13 Chen Gang : > On 09/13/2013 01:09 AM, Jeff Law wrote: >> On 09/11/2013 10:38 PM, Chen Gang wrote: >>> Hello all: >>> [...] >>> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other >>> bugs may duplicate with these bugs, so I do not send (if they are also >>> valuable, I will send too). >>> [...] >> Please include the preprocessed source. The easiest way to get that is >> to add the "-save-temps" option to the command line. That will create a >> .i file which is the self-contained preprocessed code. We need that to >> be able to debug these issues. >> > > I put related ".i" files to all related bugs, please check, thanks. > [...] > > Welcome any additional information or suggestions. :-) > It seems that all of your cases (PR58256, PR58400, PR58401) are related to compilation error. I think the next step is to reduce the self-contained code that reproduces the same error for easily debugging. :) Best regards, jasonwucj
Re: WARNING: profopt.exp does not support dg-do
2013/8/21 Paolo Carlini : > On 08/21/2013 05:00 PM, Paolo Carlini wrote: >> >> ... I went through the recent gcc-testresults posted by HJ, and the only >> possible "culprit" seems this commit: >> >> >> http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00492.html >> >> Teresa, can you have a look? > > I think it's just matter of removing the offending line per the below. I'm > going to test and commit if everything is going well. > > Paolo. > > Ah~~ It was committed yesterday, no wonder there is no such warning on my 20130818 native build... Sorry that was me making a joke... >"< I think you got the point, that's the commit with 'dg-do' in the testcase and I guess it is obviously an accident. Right? Teresa? :) Best regards, jasonwucj
Re: WARNING: profopt.exp does not support dg-do
2013/8/21 Paolo Carlini : > Hi, > > and sorry for nitpicking, but lately when we run > g++.dg/tree-prof/tree-prof.exp we are all seeing a: > > WARNING: profopt.exp does not support dg-do > > (lots of examples in gcc-testresults). Any idea what's going wrong? > > Thanks, > Paolo. I did `make check-gcc RUNTESTFLAGS="--all tree-prof.exp"` on my native build with trunk r201823 (4.9.0 20130818). There is no such warning for my tree-prof.exp testing. Please find attached files (g++.sum / gcc.sum) for your referenece. Looking into profopt.exp, 'dg-do' is not an expected dg- command. Is there something wrong with your environment that some other testcases with 'dg-do' inside are accidentally included in your tree-prof.exp testing? :p Best regards, jasonwucj g++.sum Description: Binary data gcc.sum Description: Binary data
Re: Steven Bosscher appointed RTL optimizers reviewer
> On Tue, Aug 20, 2013 at 12:24 PM, Steven Bosscher > wrote: >> On Sun, Aug 11, 2013 at 10:04 PM, Gerald Pfeifer wrote: >>> It's my pleasure to announce the appointment of Steven Bosscher >>> as RTL optimizers reviewer. >>> >>> Congratulations and Happy Hacking, Steven! >>> >>> Gerald >>> >>> PS: Please update MAINTAINERS accordingly. >> >> >> Thanks! I've updated MAINTAINERS in r201889. >> >> Ciao! >> Steven Congrats! I knew you deserve this position. Many of your comments on mailing list did help me a lot to improve my implementation for GCC contribution. :) By the way, would you like to post a patch about MAINTAINERS file changes on gcc-patches? ^^ Best regards, jasonwucj
Re: HAVE_ATTR_enabled mishandling?
2013/8/14 Vladimir Makarov : > On 13-08-12 11:13 AM, Chung-Ju Wu wrote: >> >> Hi, Vladimir, >> >> Apparently the issue that David mentioned has already been fixed earlier: >>http://gcc.gnu.org/r198344 >> >> 2013-04-26 Vladimir Makarov >> >> ... >> * lra-constraints.c (curr_insn_set): New. >> ... >> (process_alt_operands): Use it. Use #if HAVE_ATTR_enabled instead >> of #ifdef. Add code to remove cycling. >> ... >> >> However, such change is only applied on trunk but not on 4.8 branch. >> Since 4.8 branch is still open and this issue seems to be a bug, >> perhaps it is a good idea to backport this part. >> >> What do you think? :) >> >> > I guess it is worth to do. It should be safe so no any objections for this. > Thanks Vladimir. :) As usual, I did bootstrap and regtest without any problem. So I posted a patch on: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00844.html Best regards, jasonwucj
Re: HAVE_ATTR_enabled mishandling?
On 7/10/13 5:51 AM, David Given wrote: > I think I have found a bug. This is in stock gcc 4.8.1... > > My backend does not use the 'enabled' attribute; therefore the following > code in insn-attr.h kicks in: > > #ifndef HAVE_ATTR_enabled > #define HAVE_ATTR_enabled 0 > #endif > > Therefore the following code in gcc/lra-constraints.c is enabled: > > #ifdef HAVE_ATTR_enabled > if (curr_id->alternative_enabled_p != NULL > && ! curr_id->alternative_enabled_p[nalt]) > continue; > #endif > > ->alternative_enabled_p is bogus; therefore segfault. > > Elsewhere I see structures of the form: > > #if HAVE_ATTR_enabled > ... > #endif > > So I think that #ifdef above is a straight typo. Certainly, changing it > to a #if makes the crash go away... > Hi, Vladimir, Apparently the issue that David mentioned has already been fixed earlier: http://gcc.gnu.org/r198344 2013-04-26 Vladimir Makarov ... * lra-constraints.c (curr_insn_set): New. ... (process_alt_operands): Use it. Use #if HAVE_ATTR_enabled instead of #ifdef. Add code to remove cycling. ... However, such change is only applied on trunk but not on 4.8 branch. Since 4.8 branch is still open and this issue seems to be a bug, perhaps it is a good idea to backport this part. What do you think? :) Best regards, jasonwucj
Re: Problems with register elimination
On 7/28/13 8:16 AM, David Given wrote: I am having a great deal of trouble getting register elimination (and stack frame layouts in general) working properly on my architecture. There is some fundamental issue I'm simply not getting here. [...] Weirdness (1): I never see ARG_POINTER_REGNUM used to access arguments. The compiler seems to want to access function arguments via FRAME_POINTER_REGNUM plus a small value, which means they overlap the locals. (It's definitely using the same numeric ranges. It looks like it's trying to use ARG_POINTER_REGNUM but is getting the wrong register.) Internally, ARG_POINTER_REGNUM is a pointer to the incoming arguments which is pushed into stack by caller, and FRAME_POINTER_REGNUM is a pointer to the first location of local variables. || old stack pointer -> || \ || incoming arguments pushed by caller || / argument pointer -> -- || || || frame pointer -> -- || \ || local variables || / -- || \ || outgoing arguments || / stack pointer -> || Weirdness (2): the following test function generates code with tries to copy AP_REG into a register without eliminating it. [...] I don't know whether this is just talking about the MCore, or gcc in general --- I find it interesting that most backends which use a fake frame pointer seem to end up with FRAME_POINTER_REGNO and HARD_FRAME_POINTER_REGNO pointing at different addresses. If anyone can offer any suggestions as to what I'm doing wrong --- or, better still, point me at more in-depth reading on how all this is supposed to work! Did you implement TARGET_CAN_ELIMINATE and INITIAL_ELIMINATION_OFFSET ?? You need to implement these two target macros to eliminate ARG_POINTER_REGNUM and FRAME_POINTER_REGNUM into HARD_FRAME_POINTER_REGNUM. Best regards, jasonwucj
Re: HAVE_ATTR_enabled mishandling?
On 7/10/13 5:51 AM, David Given wrote: I think I have found a bug. This is in stock gcc 4.8.1... My backend does not use the 'enabled' attribute; therefore the following code in insn-attr.h kicks in: #ifndef HAVE_ATTR_enabled #define HAVE_ATTR_enabled 0 #endif Therefore the following code in gcc/lra-constraints.c is enabled: #ifdef HAVE_ATTR_enabled if (curr_id->alternative_enabled_p != NULL && ! curr_id->alternative_enabled_p[nalt]) continue; #endif ->alternative_enabled_p is bogus; therefore segfault. Elsewhere I see structures of the form: #if HAVE_ATTR_enabled ... #endif So I think that #ifdef above is a straight typo. Certainly, changing it to a #if makes the crash go away... I faced exactly the same problem as yours. When I was trying to enable LRA on my target, I got segfault as well because I did not have 'enabled' attribute in my target.md file. I was told it was due to my faulty md design. The simplest workaround is to define 'enabled' attribute so I took it. But I suspected that may be a latent issue. It's so happy to see others have the same question and provide a solution. Certainly, whether your solution is correct should be reviewed by LRA maintainer, Vladmir Makarov, so I cc him in the list. Best regards, jasonwucj
Re: Porting from old to new GCC versions
On 7/11/13 4:23 AM, Hendrik Greving wrote: Hi, I have a hard time finding a good description of how old, obsolete and now poisoned target macros and backend switches had been replaced with. Examples are TARGET_SWITCHES, or CAN_DEBUG_WITHOUT_FP. I am porting from a very old compiler version. Is there any documentation (except ChangeLog which doesn't say much) available for these kind of patches? Regards, Hendrik Greving IMHO, the GCC Internals is the best documentation for your reference. Some obsolete macros are explicitly described in chapter 17.9. Other deprecated macros spread out over chapter 17 (e.g. FUNCTION_VALUE). My suggestion is to review your target macros one by one. See if they still can be found in GCC Internals. Best regards, jasonwucj
Re: Calculating instruction costs
2013/7/9, David Given :
> I'm working on a gcc backend for an architecture. The architecture has
> instructions for indexed array access; so, ld r0, (r1, r2) is equivalent
> to r0 = r1[r2] where r1 is a int32_t*.
>
> I'm representing this in the .md file with the following pattern:
>
> (define_insn "*si_load_indexed"
> [
> (set
> (match_operand:SI 0 "register_operand" "=r")
> (mem:SI
> (plus:SI
> (mult:SI
> (match_operand:SI 1 "register_operand" "%r")
> (const_int 4))
> (match_operand:SI 2 "register_operand" "r"
> ]
> ""
> "ld %0, (%2, %1)"
> [(set_attr "length" "4")]
> )
>
> However, the instruction is never actually being emitted. Looking at the
> debug output from the instruction combining stage, I see this:
>
> Trying 8, 9 -> 10:
> Successfully matched this instruction:
> (set (reg:SI 47 [ *_5 ])
> (mem:SI (plus:SI (mult:SI (reg/v:SI 43 [ b ])
> (const_int 4 [0x4]))
> (reg:SI 0 r0 [ a ])) [2 *_5+0 S4 A32]))
> rejecting combination of insns 8, 9 and 10
> original costs 8 + 4 + 4 = 16
> replacement cost 32
>
> Instructions 8, 9 and 10 are:
>
> (insn 8 5 9 2 (set (reg:SI 45)
> (ashift:SI (reg/v:SI 43 [ b ])
> (const_int 2 [0x2]))) test.c:5 15 {ashlsi3}
> (expr_list:REG_DEAD (reg/v:SI 43 [ b ])
> (nil)))
> (insn 9 8 10 2 (set (reg/f:SI 46)
> (plus:SI (reg/v/f:SI 42 [ a ])
> (reg:SI 45))) test.c:5 13 {addsi3}
> (expr_list:REG_DEAD (reg:SI 45)
> (expr_list:REG_DEAD (reg/v/f:SI 42 [ a ])
> (nil
> (insn 10 9 15 2 (set (reg:SI 47 [ *_5 ])
> (mem:SI (reg/f:SI 46) [2 *_5+0 S4 A32])) test.c:5 6 {*si_load}
> (expr_list:REG_DEAD (reg/f:SI 46)
> (nil)))
>
> If I've read this correctly, it indicates that the instruction pattern
> has been matched, but the instruction has been rejected due to being
> more expensive than the original instructions.
>
> So, how is it calculating the cost of my instruction? Where's it getting
> that 32 from (which seems weirdly high)?
>
> Right now all the cost macros are left as the default, which is probably
> the root of the problem; but I'm having a lot of trouble getting my head
> around them. In the interest of actually getting something to work, are
> there any ways of using a simplified cost model where the cost of each
> instruction is specified manually in the instruction pattern alongside
> the length? (Or even just *using* the length as the cost...)
>
Hi, David,
I suggest setting a break point on rtx_costs and
see how it calculates the overall costs when combining
insns 8, 9, and 10.
Best regards,
jasonwucj
[PATCH 0/6] Contributing new target port: Andes 'nds32'.
Hi, GCC Steering Committee, reviewers, and developers, On behalf of Andes Technology Corp., we are submitting a new port 'nds32' for GCC contribution. In this contribution, we use the design and strategy as modern as possible, such as having LRA enabled and taking soft-fp as our software floating point library. None of general gcc code is required to be changed for this nds32 port. We have already signed FSF agreement and are proposing Shiva Chen and myself (Chung-Ju Wu), both of Andes compiler engineers, as nds32 port maintainers: Index: MAINTAINERS === --- MAINTAINERS (revision 200655) +++ MAINTAINERS (working copy) @@ -87,6 +87,8 @@ mn10300 port Jeff Lawl...@redhat.com mn10300 port Alexandre Oliva aol...@redhat.com moxie port Anthony Green gr...@moxielogic.com +nds32 port Chung-Ju Wu jasonw...@gmail.com +nds32 port Shiva Chen shiva0...@gmail.com pdp11 port Paul Koning n...@arrl.net picochip port Daniel Towner d...@picochip.com rl78 port DJ Delorie d...@redhat.com A series of patches have been posted on gcc-patches: [PATCH 1/6] Andes nds32: configure settings for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00269.html [PATCH 2/6] Andes nds32: machine description of nds32 porting. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00270.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00271.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00272.html [PATCH 3/6] Andes nds32: libgcc of nds32 porting. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00273.html [PATCH 4/6] Andes nds32: testsuite modifications for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00274.html [PATCH 5/6] Andes nds32: documentation for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00276.html [PATCH 6/6] Andes nds32: wwwdoc for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00277.html A brief overview of changed files is as below: [gcc-svn: contrib/] * config-list.mk [gcc-svn: gcc/] * config.gcc * config/nds32/* * common/config/nds32/* * doc/invoke.texi * doc/md.texi * doc/install.texi * doc/extend.texi [gcc-svn: libgcc/] * config.host * config/nds32/* [gcc-svn: gcc/testsuite/] * g++.dg/other/PR23205.C * g++.dg/other/pr23205-2.C * gcc.dg/20020312-2.c * gcc.dg/builtin-apply2.c * gcc.dg/lower-subreg-1.c * gcc.dg/sibcall-3.c * gcc.dg/sibcall-4.c * gcc.dg/stack-usage-1.c * gcc.dg/torture/pr37868.c * gcc.dg/torture/stackalign/builtin-apply-2.c * gcc.dg/tree-ssa/20040204-1.c * gcc.dg/tree-ssa/forwprop-28.c * gcc.dg/tree-ssa/pr42585.c * gcc.dg/tree-ssa/sra-12.c * gcc.dg/ucnid-11.c * gcc.dg/ucnid-2.c * gcc.dg/ucnid-3.c * lib/target-supports.exp [wwwdoc-cvs: htdocs/] * backends.html * readings.html * gcc-4.9/changes.html In addition, here are some standard requirement we have made for contribution: 1. Add nds32le-elf and nds32be-elf into contrib/config-list.mk. 2. We follow the -2013 range convention in copyright description. 3. Using a native compiler from current GCC trunk (20130704, Rev.200655), the nds32 port can be built cleanly with --enable-werror-always on both 32-bit and 64-bit host. 4. The nds32 test results have been posted on gcc-testresults: 32-bit host: v2, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00378.html v3, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00380.html 64-bit host: v2, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00379.html v3, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00381.html For completeness of Andes nds32 toolchain, we also proposed nds32 contribution for other packages [1]-[3] on corresponding mailing list. And the nds32 target for packages [4] and [5] are previously merged into master on 2011.10 and 2013.06, respectively. We sincerely hope that the nds32 target will be available in GCC 4.9. Your reviews and comments are very important to us for making this contribution better. Thanks for your time to review our contribution. Best regards, jasonwucj [1] binutils: http://sourceware.org/ml/binutils/2013-07/msg00062.html [2] gdb: http://sourceware.org/ml/gdb-patches/2013-07/msg00223.html [3] newlib: http://sourceware.org/ml/newlib/2013/msg00525.html [4] u-boot: http://lists.denx.de/pipermail/u-boot/2011-October/106467.html [5] openocd: http://openocd.zylin.com/1259
Re: build error in libgcc
2013/6/22 Ian Lance Taylor : > On Sat, Jun 22, 2013 at 12:17 AM, Chung-Ju Wu wrote: >> Like this? >> >> === >> --- libgcc/Makefile.in (revision 200306) >> +++ libgcc/Makefile.in (working copy) >> @@ -121,8 +121,8 @@ >> .PHONY: all clean >> >> clean: >> - -rm -f auto-target.h libgcc_tm.h libgcc.map >> - -rm -f libgcc_tm.stamp stamp-h stmp-ldirs >> + -rm -f libgcc_tm.h libgcc.map >> + -rm -f libgcc_tm.stamp stmp-ldirs >> -rm -f *$(objext) >> -rm -f *.dep >> -rm -f *.a >> @@ -131,6 +131,8 @@ >> @$(MULTICLEAN) multi-clean DO=clean >> distclean: clean >> @$(MULTICLEAN) multi-clean DO=distclean >> + -rm -f auto-target.h >> + -rm -f stamp-h >> -rm -f *~ Makefile config.cache config.status multilib.out >> -rm -f config.log >> maintainer-clean realclean: distclean >> >> >> Hi, Mike, would you try this revised one? :) > > This patch is OK with a ChangeLog entry. > > Thanks. > > Ian Thanks for the review and approval. The patch and a ChangeLog has been posted on: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01420.html Best regards, jasonwucj
Re: build error in libgcc
2013/6/22 Andreas Schwab : > Chung-Ju Wu writes: > >> clean: >> - -rm -f auto-target.h libgcc_tm.h libgcc.map >> + -rm -f libgcc_tm.h libgcc.map >> -rm -f libgcc_tm.stamp stamp-h stmp-ldirs > > Same for stamp-h. > Like this? === --- libgcc/Makefile.in (revision 200306) +++ libgcc/Makefile.in (working copy) @@ -121,8 +121,8 @@ .PHONY: all clean clean: - -rm -f auto-target.h libgcc_tm.h libgcc.map - -rm -f libgcc_tm.stamp stamp-h stmp-ldirs + -rm -f libgcc_tm.h libgcc.map + -rm -f libgcc_tm.stamp stmp-ldirs -rm -f *$(objext) -rm -f *.dep -rm -f *.a @@ -131,6 +131,8 @@ @$(MULTICLEAN) multi-clean DO=clean distclean: clean @$(MULTICLEAN) multi-clean DO=distclean + -rm -f auto-target.h + -rm -f stamp-h -rm -f *~ Makefile config.cache config.status multilib.out -rm -f config.log maintainer-clean realclean: distclean Hi, Mike, would you try this revised one? :) Best regards, jasonwucj
Re: build error in libgcc
2013/6/22 Ian Lance Taylor : > On Thu, Jun 20, 2013 at 6:25 PM, Mike Stump wrote: >> A make clean followed by a make in the libgcc directory results in: >> >> ../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error: >> auto-target.h: No such file or directory >> #include "auto-target.h" >> >> Oh, the the old days, we'd just add a dependancy… If someone knows where to >> add just the right one… I ask, because there doesn't seem to be a single .h >> dependency anywhere… > > auto-target.h is created by the configure script. > > It's a bug that it is removed by "make clean". It should only be > removed by "make distclean". > > Ian Well... in that case, how about this patch?? Index: libgcc/Makefile.in === --- libgcc/Makefile.in (revision 200306) +++ libgcc/Makefile.in (working copy) @@ -121,7 +121,7 @@ .PHONY: all clean clean: - -rm -f auto-target.h libgcc_tm.h libgcc.map + -rm -f libgcc_tm.h libgcc.map -rm -f libgcc_tm.stamp stamp-h stmp-ldirs -rm -f *$(objext) -rm -f *.dep @@ -131,6 +131,7 @@ @$(MULTICLEAN) multi-clean DO=clean distclean: clean @$(MULTICLEAN) multi-clean DO=distclean + -rm -f auto-target.h -rm -f *~ Makefile config.cache config.status multilib.out -rm -f config.log maintainer-clean realclean: distclean Hi, Mike, would you try it to see if it fixes the problem? If it does, I will post the patch on gcc-patc...@gcc.gnu.org to acquire Ian's approval. :) Best regards, jasonwucj
Re: There is a -Wenum-compare warning in gcc/c-family/array-notation-common.c
2013/6/16 Chung-Ju Wu : > Hi Balaji, > > I was building a native gcc with trunk r200117, > but I noticed the following code fragment cause -Wenum-compare warning: > > > [gcc/c-family/array-notation-common.c] > > 483 /* This function is used by C and C++ front-ends. In C++, additional > 484 tree codes such as TARGET_EXPR must be eliminated. These codes are > 485 passed into additional_tcodes and are walked through and checked. */ > 486 for (ii = 0; ii < vec_safe_length (i_list->additional_tcodes); ii++) > 487 if (TREE_CODE (*tp) == (enum rid)(*(i_list->additional_tcodes))[ii]) > 488 *walk_subtrees = 0; > > > /gcc-4.9.0/gcc/c-family/array-notation-common.c: In function > 'tree_node* find_inv_trees(tree_node**, int*, void*)': > /gcc-4.9.0/gcc/c-family/array-notation-common.c:487:68: warning: > comparison between 'enum tree_code' and 'enum rid' [-Wenum-compare] > if (TREE_CODE (*tp) == (enum rid)(*(i_list->additional_tcodes))[ii]) > ^ > Thanks, Balaji, I can see this warning is fixed with following patch: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01217.html http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=200272 Best regards, jasonwucj
Re: Loop induction variable optimization question
2013/6/18 Steve Ellcey : > On Mon, 2013-06-17 at 21:36 +0200, Oleg Endo wrote: > >> >> Sorry for not having an answer. I got curious, because just yesterday I >> was looking at this one >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190 >> and thought that this is related, although it doesn't seem to. >> I've tried the two functions of yours on SH and there it produces the >> same machine code with -O2. -O3 results in a call to memcpy, while >> -O3 -fno-tree-loop-distribute-patterns again results in the same code. >> >> Cheers, >> Oleg > > Thanks for the pointer. It made me realize I should try running my test > with -fno-ivopts. That got rid of the '-4' usage and I wound up getting > the code that I was after. I still hope someone can help me understand > why ivopts made the transformation it did though. I am afraid that just > turning off ivopts may have a larger affect then I am after. > > Steve Ellcey > sell...@mips.com > > > > This may have something to do with sequence point concept. (C99 5.1.2.3, C99 Annex C) To my understanding, the following two statements are not equivalent if you take sequence point into consideration: (1) *d++ = *s++; (2) *d = *s; d++; s++; The case (2) has a sequence point after ';', which mean '++' is taken place after the expression *d=*s has been evaluated. But for the case (1), compiler is free to reorder evaluations, which may move the post-increments above the assignment and then ivopt convert it using -4 offset for memory reference. There remains space to discuss whether it is worth for ivopt to do such transformation. Apparently it is not good for your case, but it may be helpful to reduce register pressure for the target with few registers. Best regards, jasonwucj
There is a -Wenum-compare warning in gcc/c-family/array-notation-common.c
Hi Balaji, I was building a native gcc with trunk r200117, but I noticed the following code fragment cause -Wenum-compare warning: [gcc/c-family/array-notation-common.c] 483 /* This function is used by C and C++ front-ends. In C++, additional 484 tree codes such as TARGET_EXPR must be eliminated. These codes are 485 passed into additional_tcodes and are walked through and checked. */ 486 for (ii = 0; ii < vec_safe_length (i_list->additional_tcodes); ii++) 487 if (TREE_CODE (*tp) == (enum rid)(*(i_list->additional_tcodes))[ii]) 488 *walk_subtrees = 0; /gcc-4.9.0/gcc/c-family/array-notation-common.c: In function 'tree_node* find_inv_trees(tree_node**, int*, void*)': /gcc-4.9.0/gcc/c-family/array-notation-common.c:487:68: warning: comparison between 'enum tree_code' and 'enum rid' [-Wenum-compare] if (TREE_CODE (*tp) == (enum rid)(*(i_list->additional_tcodes))[ii]) ^ Seem that you are comparing different enum type. Is this intentional? Or are there some typo or some logic error for this piece of code? Best regards, jasonwucj
Re: Please document `contrib/download_prerequisites'
2013/5/30 Michael Witten : > It would probably be a good idea to mention: > > contrib/download_prerequisites > > on this page: > > http://gcc.gnu.org/install/prerequisites.html > > and probably on this page: > > http://gcc.gnu.org/install/download.html > > Sincerely, > Michael Witten Is this the page you are looking for?? http://gcc.gnu.org/wiki/InstallingGCC See 'Support libraries' section. Best regards, jasonwucj
Re: where can I find issues of a given version
2013/5/29 Diego Novillo : > On 2013-05-28 11:55 , lluvia_li...@lavabit.com wrote: >> >> How can I reach that information? > > > http://gcc.gnu.org > > See the section 'Release Series and Status'. > > > Diego. >From the section, you can find the information by reviewing the 'changes' of each maintained gcc version. For ealier/closed gcc version, just simply modify the version number in the URL, for example: http://gcc.gnu.org/gcc-4.5/changes.html http://gcc.gnu.org/gcc-4.6/changes.html The list of problem reports can be also found at the end of page changes.html for each released version. Best regards, jasonwucj
Re: -Og changes on 4.7.3?
2013/5/13 Basile Starynkevitch : >> >> This would be for personal use and not necessarily proposed for >> general release. > > For personal use it is so much simpler to just build GCC 4.8 and use it. > No good reason to stick to a patched GCC 4.7 > > Cheers. > -- I guess Gene was concerning about stability of the released version. Since 4.8 is just released with revision number '0' (4.8.0), people may think 4.7.[34] is more stable with bugfixes and prefer to stick to 4.7 released version. Best regards, jasonwucj
Re: naked function attribute support for Mips
2013/5/3 Chung-Ju Wu : > > Or do you think 'naked' is still useful for some other cases in mips porting? > You can implement it and submit the patch to gcc-patc...@gcc.gnu.org > and I believe the mips maintainers are willing to have review with you. :) > Oops~ I just noticed that the mips maintainer Richard Sandiford already had some thought about 'naked' attribute. Refer to: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html Best regards, jasonwucj
Re: naked function attribute support for Mips
2013/5/3 reed kotler :
> This issue of naked function attribute support for Mips has come up in the
> context of LLVM and in regards to maintaining compatibility with gcc.
>
> It's my understanding that the idea of the naked function attribute was
> rejected for gcc Mips.
>
> I'm curious as to why.
Because there is no 'naked' attribute spec for mips porting in gcc.
Refer to gcc/config/mips/mips.c:
668 static const struct attribute_spec mips_attribute_table[] = {
669 /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
670om_diagnostic } */
671 { "long_call", 0, 0, false, true, true, NULL, false },
672 { "far", 0, 0, false, true, true, NULL, false },
673 { "near",0, 0, false, true, true, NULL, false },
674 /* We would really like to treat "mips16" and "nomips16" as type
675 attributes, but GCC doesn't provide the hooks we need to support
676 the right conversion rules. As declaration attributes, they affect
677 code generation but don't carry other semantics. */
678 { "mips16", 0, 0, true, false, false, NULL, false },
679 { "nomips16",0, 0, true, false, false, NULL, false },
680 { "micromips", 0, 0, true, false, false, NULL, false },
681 { "nomicromips", 0, 0, true, false, false, NULL, false },
682 { "nocompression", 0, 0, true, false, false, NULL, false },
683 /* Allow functions to be specified as interrupt handlers */
684 { "interrupt", 0, 0, false, true, true, NULL, false },
685 { "use_shadow_register_set", 0, 0, false, true, true, NULL, false },
686 { "keep_interrupts_masked", 0, 0, false, true, true, NULL, false },
687 { "use_debug_exception_return", 0, 0, false, true, true, NULL, false },
688 { NULL, 0, 0, false, false, false, NULL, false }
689 };
Generally, 'naked' attribute is used for interrupt handler
because we don't want compiler to generate prologue/epilogue.
Since mips already provides attributes to handle interrupt handler,
it is trivial to have 'naked' one.
Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review with you. :)
Best regards,
jasonwucj
>
> For LLVM it basically works just by nature of how LLVM works in its target
> independent part.
>
> It will not emit the function prologue or epilogue.
>
> It still emits the .frame, .mask and .fmask because that is Mips specific
> code that does not currently know about the naked function attribute, but
> that is a separate issue.
>
> There is also the issue of the return statement but this also a separate non
> Mips specific issue and I will post that separately.
>
> Tia.
>
> Reed
>
>
>
Re: return statement in a function with the naked attribute
2013/5/3 reed kotler : > Should a return statement be emitted in a function that has the naked > attribute. > > There seems to be some confusion here and apparently disagreement between > various > gcc compilers. > IMHO, it depends on how you define the word 'naked' for a function and how you expect one writing functions with 'naked' attribute. If you think one is supposed to have *complete* control in the function (i.e. only inline assembly code, without using any C statement and variables), then the asm 'ret' can be omitted. Porgrammers must explicitly emit 'ret' in the inline asm. If you allow user using C statement in the function with 'naked' attribute, the asm 'ret' is still required. Because compiler may produce a branch to the epilogue position where 'ret' is expected to exist. AFAIK, there is no standard defining what 'naked' behavior should be. So gcc leaves it to back-end developers. Best regards, jasonwucj
Re: Suppress warning for conversion prototype (that is present) (Bug 6144)
2013/3/5 Jeffrey Walton :
> Hi All,
[...]
>
> void func (short);
> void short_test (void)
> { short x = 0;
>func(x);
> }
>
> From the bug report example above, the warning is telling me there
> would be a problem if `void func (short);` was not present since it
> would be assumed to be `void func (int)` (if I'm reading things
> correctly).
>
> How do I turn off warnings for missing prototype conversions that are
> not even present? The bug report does not list a workaround.
> -Wno-traditional-conversion was unrecognized. So I'm guessing it would
> be similar to -Wno-conversion-prototype, but I don't see it at
> http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html.
>
> Jeff
If I compile such code example:
void short_test (void)
{
short x = 0;
func(x);
}
I got following warning messages:
$ gcc -c test.c -Wall
test.c: In function ‘short_test’:
test.c:7:4: warning: implicit declaration of function ‘func’
[-Wimplicit-function-declaration]
So I turn the warning off by using
'-Wno-implicit-function-declaration' and it works.
I think '-Wno-implicit-function-declaration' is the option your are
looking for~ :)
Best regards,
jasonwucj
Re: GCC 4.8 and -Og
2013/2/25 Jeffrey Walton : > Hi All, > > I read the relase notes on GCC 4.8 > (http://gcc.gnu.org/gcc-4.8/changes.html) and -Og caught my eye (the > bulleted item is below). [deleted] > > What "n" does -Og correspond to for -O and -g (i.e., -O1, -O2; -g2, -g3)? [deleted] > Is -Og -g3 a valid combination to get the benefits of -Og with maximum > symbol support? Is it even needed? > > Jeff > To my understanding, '-Og' selects optimization level 1 so that you can have fast compilation and a superior debugging experience. You still need to use -g (or -g3, which is the option you normally use.) to guide GCC output debug information. Refer to following link for some -Og implementation detail: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00616.html Best regards, jasonwu
