Re: %pc relative addressing of string literals/const data
On Tue, Oct 05, 2010 at 11:56:55AM -0700, Richard Henderson wrote: > On 10/05/2010 06:54 AM, Joakim Tjernlund wrote: > > Ian Lance Taylor wrote on 2010/10/05 15:47:38: > >> Joakim Tjernlund writes: > >>> While doing relocation work on u-boot I often whish for strings/const data > >>> to be accessible through %pc relative address rather than and ABS address > >>> or through GOT. Has this feature ever been considered by gcc? > >> > >> The feature can only be supported on processors which are reasonably > >> able to support it. So, what target are you asking about? > > > > In my case PowerPC but I think most arch's would want this feature. > > Is there arch's where this cannot be support at all or just within > > some limits? I think within limits could work for small apps > > like u-boot. > > PowerPC doesn't really have the relocations for pc-relative offsets > within code -- primarily because it doesn't have pc-relative insns > to match. Nor, unfortunately, does it have got-relative relocations, > like some other targets. These are normally how we get around not > having pc-relative relocations and avoiding tables in memory. C.f. The new PowerPC medium code model for 64-bit now uses GOT-relative relocations for local data: The compiler issues (r2 has the TOC/GOT pointer): addis ,r2,la...@toc@ha addi ,,la...@toc@l to load the address in . If the data happens to be within 32K of the TOC pointer, the linker will transform this to: nop addi ,r2,la...@toc@l For non-local loads or the large code model, the compiler issues: addis ,r2,la...@got@ha ld ,la...@got@l() If the address happens to be defined in the current program unit (main program or shared librar), the linker can transform this to: addis ,r2,la...@toc@ha addi ,,la...@toc@l or: nop addi ,r2,la...@toc@l or: nop ld ,la...@got@l(r2) -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com
Re: %pc relative addressing of string literals/const data
Richard Henderson wrote on 2010/10/06 00:13:22: > > On 10/05/2010 02:40 PM, Joakim Tjernlund wrote: > > Especially one that doesn't require each function > > to calculate the GOT address in the function prologue(why is that so?) > > Because PIC code can be called from non-PIC code and because > the non-PIC code does not load the GOT address. > > Avoiding re-computation of the PIC register is something that > could be done via LTO and/or cgraph optimizations. To my > knowledge, no one is working on that at present. One could add an option to assume PIC reg is set. This would help targets where one has complete control. I beleive ARM has one: -msingle-pic-base
Re: %pc relative addressing of string literals/const data
On Wed, Oct 6, 2010 at 12:13 AM, Richard Henderson wrote: > On 10/05/2010 02:40 PM, Joakim Tjernlund wrote: >> Especially one that doesn't require each function >> to calculate the GOT address in the function prologue(why is that so?) > > Because PIC code can be called from non-PIC code and because > the non-PIC code does not load the GOT address. > > Avoiding re-computation of the PIC register is something that > could be done via LTO and/or cgraph optimizations. To my > knowledge, no one is working on that at present. It should be a matter of calling cgraph_only_called_directly_p () on the own cgraph node when expanding the GOT address calculation. Assuming that it is preserved across all call-sites we'd retain GOT address computation only in functions that can be called in ways the compiler doesn't know. Richard. > > r~ >
Re: %pc relative addressing of string literals/const data
Michael Meissner wrote on 2010/10/07 15:00:25: > > On Tue, Oct 05, 2010 at 11:56:55AM -0700, Richard Henderson wrote: > > On 10/05/2010 06:54 AM, Joakim Tjernlund wrote: > > > Ian Lance Taylor wrote on 2010/10/05 15:47:38: > > >> Joakim Tjernlund writes: > > >>> While doing relocation work on u-boot I often whish for strings/const > > >>> data > > >>> to be accessible through %pc relative address rather than and ABS > > >>> address > > >>> or through GOT. Has this feature ever been considered by gcc? > > >> > > >> The feature can only be supported on processors which are reasonably > > >> able to support it. So, what target are you asking about? > > > > > > In my case PowerPC but I think most arch's would want this feature. > > > Is there arch's where this cannot be support at all or just within > > > some limits? I think within limits could work for small apps > > > like u-boot. > > > > PowerPC doesn't really have the relocations for pc-relative offsets > > within code -- primarily because it doesn't have pc-relative insns > > to match. Nor, unfortunately, does it have got-relative relocations, > > like some other targets. These are normally how we get around not > > having pc-relative relocations and avoiding tables in memory. C.f. > > The new PowerPC medium code model for 64-bit now uses GOT-relative relocations > for local data: The compiler issues (r2 has the TOC/GOT pointer): > >addis ,r2,la...@toc@ha >addi ,,la...@toc@l > > to load the address in . If the data happens to be within 32K of the > TOC > pointer, the linker will transform this to: > >nop >addi ,r2,la...@toc@l > > For non-local loads or the large code model, the compiler issues: > >addis ,r2,la...@got@ha >ld ,la...@got@l() > > If the address happens to be defined in the current program unit (main program > or shared librar), the linker can transform this to: > >addis ,r2,la...@toc@ha >addi ,,la...@toc@l > > or: > >nop >addi ,r2,la...@toc@l > > or: > >nop >ld ,la...@got@l(r2) Why not offer some of this on PowerPC32? mcmodel=small would probably be enough. Jocke
Re: Bootstrap broken on Cygwin, fix on the way.
On 07/10/2010 05:01, Dave Korn wrote: > > FYI, in case anyone else runs into this and comes here looking for > information: a fix is on the way for the "multiple definitions of various > include-path-related things" problem currently breaking bootstrap on Cygwin. > Hope to have it working again within the next few hours. FTR: Working again at r.165119. cheers, DaveK
Re: [wwwdocs] PATCH for Re: new mirror
Hello Gerald, Our mirror address has been changed from http://gcc.parentinginformed.com/ to http://gcc.parentingamerica.com/ Please update your list to use the new URL. Also please use new e-mail to contact me when necessary: jmil...@parentingamerica.com. Thank you. Best wishes, James Miller On Mon, May 24, 2010 at 8:55 PM, Gerald Pfeifer wrote: > On Mon, 24 May 2010, James Miller wrote: >> We have raised a new GCC mirror at http://gcc.parentinginformed.com. >> The mirror is located in Canada and I am the contact point for it. > > Thanks for setting up a mirror and letting us now. I just added this > to our mirrors list at http://gcc.gnu.org/mirrors.html with the patch > below. > > Gerald > > Index: mirrors.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v > retrieving revision 1.197 > diff -u -3 -p -r1.197 mirrors.html > --- mirrors.html 9 May 2010 19:54:39 - 1.197 > +++ mirrors.html 24 May 2010 18:52:39 - > @@ -34,6 +34,7 @@ Key fingerprint = 33C2 35A3 4C46 AA3F FB > > Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, > thanks to Antonin dot Sprinzl at tuwien dot ac dot at > Bulgaria: href="http://gcc.igor.onlinedirect.bg/";>gcc.igor.onlinedirect.bg, thanks > to igor at onlinedirect dot bg > +Canada: href="http://gcc.parentinginformed.com";>http://gcc.parentinginformed.com, > thanks to James Miller (jmiller at parentinginformed dot com). > Canada, Toronto: href="http://gcc-ca.internet.bs";>http://gcc-ca.internet.bs, thanks to > Internet.bs (info at internet dot bs) > China: href="ftp://linuxforum.net/ftp.gcc.gnu.org/";>ftp://linuxforum.net/ftp.gcc.gnu.org/, > thanks to David Deng (david99deng at yahoo dot com) > France (no snapshots): href="ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 > dot fr
rules for svn commit-ing a [gengtype] patch?
Hello All,
I am a bit confused about the (GCC social) rules to commit a patch to
the GCC trunk svn, in particular after having read
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00419.html and
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00486.html and other
messages in that thread. I also am not sure to understand what does the
end of stage 1 means.
I am just a plain write after approval maintainer, that is at the
bottom of GCC social meritocracy.
Until now, I thought that to be autorized to svn commit a patch to GCC
trunk, I need to get an ok email (or maybe ok with such and such
changes) on the gcc-patches@ list by a person listed as reviewer in the
MAINTAINERS file. Apparently, there might be other means of getting an
Ok, but I believe they need IRC (which I don't have access to from
office) or face to face interaction (which I believe happens frequently
in big GCC businesses like Adacore, CodeSourcery, Google) from a
reviewer working in the same office (or place) as the svn commit-er.
As you probably know, I worked hard with Jeremie Salvucci to improve
gengtype for plugins (by persisting its state), and we sent several
iterations of patches, e.g.
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00227.html &
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01719.html and all patches
referenced there.
Our patches got several comments from Laurynas Biveinis, and we
(Jeremie & me Basile) reacted to each to our best. But Laurynas is
*not* listed as a reviewer, so he cannot (formally) Ok any patches.
And our patches are specific to gengtype. In particular
0. gengtype is a source code generator, generating code from GTY
annotation, to help garbage collection & precompiled headers. Its only
relation to (shipped) GCC behavior or even binary is indirect (thru the
gengtype generated gt*.[ch] files).
1. gengtype don't interest much reviewers; I know no gengtype reviewer,
so the only reviewer able to Ok our patches should be a global
reviewer. They are a very rare resource.
2. our patches don't change a bit in the gengtype generated files. My
feeling is that this property would make our patches even acceptable in
stage 2, but they add more functionality to gengtype so I would guess
that stage 1 would be mandatory to many (even if, as I said, our
patches don't change the behavior of the GCC compiler).
3. The last iteration of our patches is only cosmetic (mostly
indentation related), so I need to get a chunk svn commit-ed before
sending to gcc-patches@ the next chunk.
Even by pinging them, our patches got no much interest so far (except
some people, like Paolo Bonzini, wanting them but not able to OK them,
or like Laurynas reviewing them but not able to OK them).
Can we svn commit a patch after having compiled with a comment (like
those of Laurynas) without an Ok from a reviewer? (I believe not, but I
am thinking that some patches went into trunk without an ok on
gcc-patches@).
Should we try to find a reviewer interested in gengtype? How can I do
that?
Do you have any constructive suggestions.
I am even arriving one day earlier at GCC summit (ie on Saturday
evening, so I am available on Sunday in Ottawa) to meet any potential
global reviewer able to OK our patches.
What can I do more?
Given the delay of october 27th, & since I have to get one chunk
accepted into trunk before sending the next one in its final form, I am
very pessimistic about the chances of our patches going into 4.6.
Constructive suggestions, or offer to meet me in Ottawa on Sunday
october 24th by a global reviewer, are welcome.
Maybe there is something about svn commit (social) rules I did not
understand?
Or should I ping our patches more often?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: rules for svn commit-ing a [gengtype] patch?
Basile Starynkevitch writes: > Can we svn commit a patch after having compiled with a comment (like > those of Laurynas) without an Ok from a reviewer? (I believe not, but I > am thinking that some patches went into trunk without an ok on > gcc-patches@). You do need to have an OK from somebody listed in the MAINTAINERS file. In general patches should not be committed without a review, unless of course they are committed by a maintainer of the specific area. There are some exceptions, for rolling back your own erroneous patches and for changes which are obvious. People are expected to use good judgement for that. > Should we try to find a reviewer interested in gengtype? How can I do > that? For gengtype I believe you currently need a global reviewer. At least, it does not seem to me to fall under any of the other categories. I will try to take a look at some point if nobody else beats me to it. Ian
Re: %pc relative addressing of string literals/const data
On Thu, Oct 07, 2010 at 04:50:50PM +0200, Joakim Tjernlund wrote: > Why not offer some of this on PowerPC32? mcmodel=small would probably be > enough. Well as they say, contributions are welcome. Note, 32-bit mode doesn't need this when compiling for the main program, since it does addis/addi already (or moves the addi into the offset of the memory reference instructions) to load up addresses (in 32-bit mode, the addis/addi will form any address, but in 64-bit mode, this can't be used, because addresses are loaded above the 32k limit). For pic code, it does need to use the GOT in traditional fashion. Note, the 64-bit ABI requires that r2 have the current function's GOT in it when the function is called, while the 32-bit ABI uses r2 as a small data pointer (and possibly r13 as a second small data pointer). So, in 32-bit mode you have to get the GOT address by doing call to the next instruction to get the address in the LR. So, it isn't as simple as moving the the 64-bit stuff in 32-bit, since there are different assumptions. -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com
Re: rules for svn commit-ing a [gengtype] patch?
On Thu, 07 Oct 2010 10:55:46 -0700
Ian Lance Taylor wrote:
> Basile Starynkevitch writes:
>
> > Can we svn commit a patch after having compiled with a comment (like
> > those of Laurynas) without an Ok from a reviewer? (I believe not, but I
> > am thinking that some patches went into trunk without an ok on
> > gcc-patches@).
>
> You do need to have an OK from somebody listed in the MAINTAINERS file.
Sorry, I am misparsing your sentence. Do you mean that an OK from any
plain Write After Approval is enough?!?! Or do you mean (as I believed)
that I need an OK from a *reviewer* listed *as such* in MAINTAINERS -
this excludes people listed in the Write After Approval section (like
Laurynas or Jeremie or me Basile)?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: rules for svn commit-ing a [gengtype] patch?
On Thu, Oct 7, 2010 at 11:23, Basile Starynkevitch wrote: > On Thu, 07 Oct 2010 10:55:46 -0700 > Ian Lance Taylor wrote: > >> Basile Starynkevitch writes: >> >> > Can we svn commit a patch after having compiled with a comment (like >> > those of Laurynas) without an Ok from a reviewer? (I believe not, but I >> > am thinking that some patches went into trunk without an ok on >> > gcc-patches@). >> >> You do need to have an OK from somebody listed in the MAINTAINERS file. > > Sorry, I am misparsing your sentence. Do you mean that an OK from any > plain Write After Approval is enough?!?! Or do you mean (as I believed) > that I need an OK from a *reviewer* listed *as such* in MAINTAINERS - > this excludes people listed in the Write After Approval section (like > Laurynas or Jeremie or me Basile)? The latter. Diego.
Re: toplevel *again* out of sync
* Naveen H. S wrote on Mon, Oct 04, 2010 at 10:44:40AM CEST:
> >> Nick, Naveen, the diff between the GCC and the src commits is this;
> >> which variant is correct?
> >> -noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
> >> +noconfigdirs="$noconfigdirs ${libgcj}"
>
> The following variant in src is the correct version:-
> +noconfigdirs="$noconfigdirs ${libgcj}"
>
> The GCC commit should be modified as per the src commit.
> Sorry, hunk of GCC was my mistake in the modified patch.
>
> >> Please fix the wrong side, and fix src/ChangeLog. Thanks.
>
> Sorry, I don't have the permissions to commit these changes.
I've committed the first patch below to GCC now, and added the ChangeLog
entry below that to src/ChangeLog now.
Cheers,
Ralf
Fixup botched sync of toplevel configure from src.
/:
Sync from src:
* configure.ac (v850 support): Remove target-libgloss from
noconfigdirs.
* configure: Regenerate.
diff --git a/configure.ac b/configure.ac
index 5f80aa9..6af4be1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -968,7 +968,7 @@ case "${target}" in
noconfigdirs="$noconfigdirs bfd binutils gas gcc gdb ld
target-libstdc++-v3 opcodes target-libgloss ${libgcj}"
;;
v850*-*-*)
-noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
+noconfigdirs="$noconfigdirs ${libgcj}"
;;
vax-*-vms)
noconfigdirs="$noconfigdirs bfd binutils gdb ld target-newlib opcodes
target-libgloss ${libgcj}"
Add missing ChangeLog entry for toplevel configure from 2010-07-26.
Index: ChangeLog
===
RCS file: /cvs/src/src/ChangeLog,v
retrieving revision 1.932
diff -u -r1.932 ChangeLog
--- ChangeLog 2 Oct 2010 14:54:05 - 1.932
+++ ChangeLog 7 Oct 2010 19:24:50 -
@@ -51,6 +51,11 @@
* configure.ac: Fix unportable shell quoting.
* configure: Regenerate.
+2010-07-26 Naveen.H.S
+
+ * configure.ac: Support all v850 targets.
+ * configure: Regenerate.
+
2010-07-17 Jack Howarth
PR target/44862
Re: %pc relative addressing of string literals/const data
Michael Meissner wrote on 2010/10/07 20:21:38: > > On Thu, Oct 07, 2010 at 04:50:50PM +0200, Joakim Tjernlund wrote: > > Why not offer some of this on PowerPC32? mcmodel=small would probably be > > enough. > > Well as they say, contributions are welcome. Note, 32-bit mode doesn't need Yes, but then I would have to know if such an contribution is welcome and how to go about it. As nobody has considered ppc32 when adding this functionality I wonder if ppc32 I developed anymore? ppc32 appears to fall into maintained instead. > this when compiling for the main program, since it does addis/addi already (or > moves the addi into the offset of the memory reference instructions) to load > up > addresses (in 32-bit mode, the addis/addi will form any address, but in 64-bit > mode, this can't be used, because addresses are loaded above the 32k limit). > > For pic code, it does need to use the GOT in traditional fashion. pic code as in shared lib? In my case the main program needs to be pic but it doesn't use shared libs. > > Note, the 64-bit ABI requires that r2 have the current function's GOT in it > when the function is called, while the 32-bit ABI uses r2 as a small data > pointer (and possibly r13 as a second small data pointer). So, in 32-bit mode > you have to get the GOT address by doing call to the next instruction to get > the address in the LR. Don't need/use small data so r2 should be fine. > > So, it isn't as simple as moving the the 64-bit stuff in 32-bit, since there > are different assumptions. I see, this may very well be over my head then. Jocke
gcc-4.5-20101007 is now available
Snapshot gcc-4.5-20101007 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101007/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 165137 You'll find: gcc-4.5-20101007.tar.bz2 Complete GCC (includes all of below) MD5=4c71e7bbd4202de9d55b4ee50f2fe68f SHA1=26577e0070bd6450a7f2d838ff044d588778d320 gcc-core-4.5-20101007.tar.bz2C front end and core compiler MD5=ea0b7a627179af7311cb7ee52cd88f9e SHA1=68907b677ed464b70a117b599a72831acf5f1ebf gcc-ada-4.5-20101007.tar.bz2 Ada front end and runtime MD5=ed3582b1b842b52e10a54299d66ebe4d SHA1=51738a0a5e71dff2ef49d0595b2c732da55c6a62 gcc-fortran-4.5-20101007.tar.bz2 Fortran front end and runtime MD5=490c6ff5daa046502179c9a2a74be338 SHA1=a9e84191f32d0f9931767a626d9d707c5fbc5c93 gcc-g++-4.5-20101007.tar.bz2 C++ front end and runtime MD5=00a19ef6e8aa123851a11c4b7d17c72f SHA1=c8d18017a4661b40875fc442041f9af5c1b507ea gcc-java-4.5-20101007.tar.bz2Java front end and runtime MD5=2df4189385373d449fda109f54767947 SHA1=24cd695e94feb32740191919763ed629ad7ef6b9 gcc-objc-4.5-20101007.tar.bz2Objective-C front end and runtime MD5=96b2c4384478307abf9b004ead63c00c SHA1=a6bdc62d7546065728d1f453ba7b26f3b0348941 gcc-testsuite-4.5-20101007.tar.bz2 The GCC testsuite MD5=8e9e46b6a3921e06c12176e1d432a128 SHA1=12e13974f1218a971e1460e3862a3c6bf9ab5f0e Diffs from 4.5-20100930 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
GCC and out-of-range constant array indexes?
Consider the following:
$ cat -n t.c
1
2 int A[10] = { 0 };
3
4 int main()
5 {
6A[10] = 10;
7A[-1] = -1;
8return 0;
9 }
In a compiler test case that I reviewed recently, there was the
expectation that the compiler would issue a compile-time warning
on the statements at lines 6 an 7 above. I tried this with
GCC version "gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)"
recently and was unable to find compilation switches that
would cause it to complain about the use of out-of-range
indexes above.
Is there a technical reason that the compiler should not
issue a warning, or might this feature become a legitimate RFE?
thanks,
- Gary
Re: GCC and out-of-range constant array indexes?
Gary Funck writes:
> Consider the following:
>
> $ cat -n t.c
> 1
> 2 int A[10] = { 0 };
> 3
> 4 int main()
> 5 {
> 6A[10] = 10;
> 7A[-1] = -1;
> 8return 0;
> 9 }
>
> In a compiler test case that I reviewed recently, there was the
> expectation that the compiler would issue a compile-time warning
> on the statements at lines 6 an 7 above. I tried this with
> GCC version "gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)"
> recently and was unable to find compilation switches that
> would cause it to complain about the use of out-of-range
> indexes above.
-Warray-bounds, but that is one of the warnings which is unfortunately
only available when optimizing. In this case it requires -O2.
There was an attempt a couple of years ago to implement this warning
when not optimizing, but it leds to http://gcc.gnu.org/PR36108 , where
the issue is that there are array bounds violations which occur in code
which is never executed. When not optimizing, the compiler does not
currently know which code is executed and which is not.
Ian
