Re: Where does the C standard describe overflow of signed integers?
Paul Schlie wrote: In that case you may want to stick with -O0. There are *lots* of things GCC does that alter undefined cases. How about the undefined behavior when aliasing rules are violated? Would you want to make -fno-strict-aliasing be the only supported setting? - Isn't the purpose of "restrict" to explicitly enable the compiler to more aggressively optimize references which it may be not have been able to identify it as being strictly safe? (As opposed to it feeling compelled presume potentially disastrously otherwise, without explicit permission to do so?) "restrict" allows the compiler to make further assumptions than -fstrict-aliasing. with strict aliasing, the compiler assumes that an int pointer and a long pointer cannot refer to the same object, whereas "restrict" allows you to specify that two int pointers do not refer to the same object. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: please update the gcj main page
John M. Gabriele wrote: > Please update http://gcc.gnu.org/java/index.html and mention > how much of the Java 1.5 spec that GCJ currently implements. > > When I refer folks to GCJ, the first thing they usually ask is, > "does it support generics?" "autoboxing?" and so on. That info > should be right up on the GCJ front page -- even if GCJ doesn't > support those newer features. *Especially* if GCJ doesn't > support those newer features. GCJ doesn't yet support any of the new 1.5 features. Tom Tromey is developing "gcjx", a complete rewrite of the GCJ compiler front-end, that would support the 1.5 features in addition to being easier to maintain, etc. You can check it out for yourself using the "gcjx-branch" branch of the GCC CVS repository: http://gcc.gnu.org/cvs.html As for your suggestion, I believe the correct place would be "2.8 What features of the Java language are/aren't supported?" in the FAQ: http://gcc.gnu.org/java/faq.html#2_8 in addition to the front-page (if so desired). Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
Get $266/mo extra
1a http://dd5dbek.convolve.esouroe.us/?1qT go.gif Description: GIF image
Merged CVS repository of gcc and old-gcc
In preparation for the future transition to subversion, I've written some code to merge the old-gcc repository into current mainline. I would like to see this merged repository used as the basis for the conversion to subversion. The advantage is that it provides revision history back to 1992, when the gcc sources were first put into a source code control system. (At the time, it was RCS. Before 1992 the source code control system was emacs numbered backup files.) Since I just wrote this code, I'd like any feedback that people care to give on the correctness and usability of the generated repository. People with SSH access to sourceware should be able to access the temporary merged repository by doing cvs -d :ext:gcc.gnu.org:/pool/ian/repo co gcc This is a snapshot, and it will not be updated to keep up with mainline changes, except to test bug fixes. It only includes the gcc subdirectory, since that is all that is present in old-gcc. It does not include some subdirectories which are not present in old-gcc, such as ada, fortran, java, and testsuite. Some implementation notes. I first created a new repository in /pool/ian/repo, and copied the gcc files there: cp -pr /cvs/gcc/gcc/gcc /pool/ian/repo/ Then I ran this command: (cd /cvs/gcc/old-gcc; find . -name '*,v' -print) | while read f; do echo $f; /home/ian/gccmerge/objdir/src/cvs -d /pool/ian/repo gccmerge /cvs/gcc/old-gcc gcc $f; done That command took about 10 minutes to run. It directly modifies the file in the repository provided as the -d option. Yes, for those scoring at home, this is a modification of CVS itself. I did it that way to make easy use of the RCS library within CVS. Sources are on gcc-mergebranch of coolo-cvs in /cvs/sourceware. By the way, in case anybody asks, I will not be doing this merge before the subversion conversion, because it changes all the CVS revision numbers and thus breaks all existing working directories. Thanks. Ian
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
Mark Cuss kirjoitti: Hello all I apologize if this is off topic for this list - I wasn't sure exactly where to ask but I thought this would be a good place to start: Something for newbies like gcc-help? I'm trying to get myself a group of libraries that I can distribute with my program so that they'll run on any distro. On SuSEs, Mandrakes, Debians,...? Or on only Red Hats and Fedoras? I run into problems all the time when different distros have different versions of system libraries like libstdc++, libgcc, libc, etc. Excluding libstdc++*.so's all these should be backwards compatible with old apps produced on old systems... But usually only among the same "company". So Red Hat 8.0 should run apps made for Red Hat 6.x and 7.x and maybe even older apps made for "Red Hat". This is what one could expect, an opsys made for company use must be "stable" in the sense that in some time frame all apps made for it should run... In the (bad?) Windoze, SCO, UnixWare, Solaris2 etc. worlds this backwards-compatability issue has always taken seriously. But I remember in 1994 the (Finnish) Linux experts to tell that Linux WILL NEVER have any "backwards compatability" or any binary compatability between its distros! People are assumed to rebuild all apps to the new Linux installations! People like me who thought things like the then new Novell UnixWare to be "a good thing" because it claimed compatability with almost every source and binary made that far, were doomed as being "heretics"... But Linux entering into the company world has caused pressure for "binary compatability" a'la MS, SCO,... So nowadays one can download a new "Firefox 1.0.5" for Linux/x86 and expect it to work OK on one's Red Hat, SuSE, Debian and so on !!! That this is possible, must be a horrible disappointment to the old Linux users... To make this application run on a Red Hat 7.3 machine, At least the backwards compatability for apps made for Red Hat 7.3 has this far seemed perfect... Alls the apps made for RHL 7.3 on RH 8.0 by me have run OK both on RH 8.0 and on RH 7.x too... So my advice is to produce the apps for the "least common nominator". Maybe Red Hat 7.3 could be this for RH 7.x, 8.0 and 9, and for the Fedora Cores. But I have no experience about the SuSEs. Maybe one must have a similar "least common nominator" toolchain for those... So - the question is: How do I do this? Even though LD_LIBRARY_PATH points to ./ as it's first entry, ldd still looks in /lib first for ld-linux.so.2. I've tried the rpath option to ld at link time, but that doesn't work either. It seems that thing is somehow hardcoded to look in /lib for this library. Trying the backwards compatability sounds being the natural thing for me. Generally those "native GCCs" used as the production tools for any apps (excluding the GCCs) is from the ass, IMHO... Instead one should produce "portable GCCs" so that when one has produced several GCCs for the then installed host, one could just copy them to the (backwards compatible) new Linux distro. Without rebuilding them. Heretics maybe, but struggling with trying to produce egcs-1.1.2 for RHL 6.2 target using gcc-3.4 or something on Fedora is really not seen as any alternative by me if needing to produce apps for RH 6.2 on Fedora... Sometimes in the past I understood that "native GCCs are from the ass" and after that I have produced only crosscompilers for everything, even for the "native" target... On my RHL 8.0 all the GCCs for RHL 8.0 target are crosscompilers for RHL 8.0. And made for the current "least common nominator" runtime host, RHL 7.3... Is there a way to somehow configure gcc build executables that look elsewhere for ld-linux.so.2, or is what I'm trying to do simply not possible? I'd really like to have a set of libraries with my program so that it's binary compatible with other distros... there must be a way. If anyone has any tips or advice I'd appreciate it. What about learning the "--help" option? When you link, you can force the resulted apps to search their shared libraries from anywhere : F:\usr\local\i486-linux-gnu\bin>ld --help Usage: ld [options] file... Options: -a KEYWORD Shared library control for HP/UX compatibility -A ARCH, --architecture ARCH Set architecture -b TARGET, --format TARGET Specify target for following input files -rpath PATH Set runtime shared library search path -rpath-link PATHSet link time shared library search path Finding the option for "Set runtime shared library search path" needs only newbie level skills, ie capability to write "--help" and read :-) RTFM then tells more, again capability to read is required... Producing nice manuals for the GNU tools from their texinfo sources is also quite newbie level skill. Some can even use MS Word or the text processor in OpenOffice and invent their own clauses, only converting existing things to some
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
Kai Ruottu kirjoitti:
Mark Cuss kirjoitti:
So - the question is: How do I do this? Even though LD_LIBRARY_PATH
points to ./ as it's first entry, ldd still looks in /lib first for
ld-linux.so.2. I've tried the rpath option to ld at link time, but
that doesn't work either. It seems that thing is somehow hardcoded to
look in /lib for this library.
Seems that also I must learn to read much better!!! Not thinking that
"others cannot ever even read". Not very good results yet got... My
apologies for not reading what Mark wrote!!!
So '-rpath' was tried but not yet the '-dynamic-linker', which must
be used for the 'ld-linux.so.2', 'ld.so.1' or something depending on
the Linux, SVR4 etc. variation...
Finding the "dynamic linker", "program interpreter" or whatever the
official name then is, from the right place at runtime can be a problem,
but it is also a problem at linktime!!! Here is my clue for those who
yet don't know how on earth the search place for those "NEEDED" shared
libraries (told inside other shared libraries being needed too when
linking) :
-- clip --
F:\usr\local\i486-linux-gnu\bin>ld -verbose
GNU ld version 2.10.1 (with BFD 2.10.1)
Supported emulations:
elf_i386
i386linux
using internal linker script:
==
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
"elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR(/usr/local/i486-linux-gnu/lib);
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
SECTIONS
-- clip --
The "SEARCH_DIR" told in the internal linker script seems to be the
place where the stuff will be searched...
Sometimes there was a bug in this and using '-rpath-link' was
obligatory. Nowadays there can be a problem with the bi-arch
(64/32-bit) targets like 'x86_64-linux-gnu', using '-m elf_i386'
in the linker command gives something like :
-- clip --
GNU ld version 020322 20020322
Supported emulations:
elf_x86_64
elf_i386
i386linux
using internal linker script:
==
/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
"elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR("/usr/local/i386-linux-gnu/lib");
-- clip --
So the linker was made for 'x86_64-linux-gnu' but it searches from
'.../i386-linux-gnu/lib' for the 32-bit 'ld-linux.so.2' at linktime.
Who could have guessed this?
I haven't though checked how the uptodate linkers behave...
Re: Where does the C standard describe overflow of signed integers?
Paul Schlie wrote:
From: Robert Dewar <[EMAIL PROTECTED]>
Paul Schlie wrote:
I don't contest that it may, I simply don't believe it should.
you can't seriously mean that with respect to uninitialized
variables. this would mean you could not put local variables in
registers. the effect on code quality woul be awful!
Why would anyone care about the performance of an access to an
un-initialized variable? [..] although do
see substantial value in producing compiled code which is strictly
consistent with the specified program and native target behavior,
regardless of its portability.
You can have both, correctness and uninitialised local
variables. For an impression of the difference in performance,
and for a way to ensure correctness, I tried this
(switch register/volatile in the declaration lines in comp
and r to see the effects).
#include
#include
#define BUFFER_SIZE 1000 // must be > 0
#define ITERATIONS 10 // must be > 0
static inline int comp(const short, const short, const short);
/* pre: a has elements, that is hi > 0. Frequently called */
int r(short a[], size_t hi)
{
//register int x, y, z;
volatile int x=1, y=2, z=3;
assert(hi > 0);
for (size_t c=0; c < hi + 2; ++c) {
if (a[c]) {
jfssoae:
x = c + 3, y = z = a[c];
if (comp(x, y, z)) z = x - y;
}
}
return x + y + z;
}
static inline int comp(const short x, const short y, const short z)
{
//register int result = (x + y) == (x + z);
volatile int result = (x + y) == (x + z);
return result;
}
int main()
{
short buffer[BUFFER_SIZE];
int result;
assert(ITERATIONS > 0);
for (int runs = 0; runs < ITERATIONS; ++runs) {
result = r(buffer, BUFFER_SIZE);
}
return result;
}
Re: Where does the C standard describe overflow of signed integers?
Georg Bauhaus wrote:
(There are at least two bugs in this :-/ but corrections
won't change the picture. Neither will initialisation.)
#define BUFFER_SIZE 1000 // must be > 0
#define ITERATIONS 10 // must be > 0
assert(hi > 0);
for (size_t c=0; c < hi + 2; ++c) {
if (a[c]) {
RE: Where does the C standard describe overflow of signed integers?
Original Message
>From: Georg Bauhaus
>Sent: 15 July 2005 14:21
> You can have both, correctness and uninitialised local
> variables. For an impression of the difference in performance,
> and for a way to ensure correctness, I tried this
> (switch register/volatile in the declaration lines in comp
> and r to see the effects).
I didn't get that far. Before the first call to comp the program has
already accessed uninitialised memory:
> int main()
> {
> short buffer[BUFFER_SIZE];
> int result;
>
> assert(ITERATIONS > 0);
So far, so good. Declare some uninitialised storage.
>
> for (int runs = 0; runs < ITERATIONS; ++runs) {
First time round, runs = 0;
> result = r(buffer, BUFFER_SIZE);
Call function 'r'.
> /* pre: a has elements, that is hi > 0. Frequently called */
> int r(short a[], size_t hi)
> {
> //register int x, y, z;
> volatile int x=1, y=2, z=3;
x=1, y=2 and =3. hi = BUFFER_SIZE and a[] is uninitialised.
>
> assert(hi > 0);
Still good...
> for (size_t c=0; c < hi + 2; ++c) {
> if (a[c]) {
Uninitialised variable access. Boom. *NOT* correct.
In what sense of the word 'correct' do you claim this example is correct?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: [toplevel] Update COPYING.LIB from FSF
On Thu, Jul 14, 2005 at 07:44:35PM -0400, DJ Delorie wrote: > > > As I understand it, the only difference in the bumped version number > > is the address. Can anyone confirm this? > > A simple diff shows other changes, including the all-new shared > library clause and the change of "Library" to "Lesser" in the name. Yes - Joe, I believe you're thinking of the latest revisions of the GPL, which do only differ in the address. LGPL 2.0 -> 2.1 predates the move by a while. -- Daniel Jacobowitz CodeSourcery, LLC
Re: The origin of scalar evolutions?
Hi Sebastian,
Thank you for your quick reply. I have a few more comments though, and
I hope you can take a look at these.
1. After reading the paper, we concluded that the scalar evolutions
are
actually a restricted polynomial form of chains of recurrences by
Bachmann and Zima [6,8]. Is this true? Or is there an essential
difference with multi-variate chains of recurrences [7]? Does the
"scalar evolutions" name suggest something else beyond the recurrence
forms. Are we missing a crucial point?
a = {1, +, a}
b = {3, +, [1, 2]}
c = {-, +, +}
d = {abstract_value, +, abstract_value}
are not chains of recurrences. More generally chains of recurrences
use integer or real coefficients, whereas coefficients of scalar
evolutions are over any abstract domain.
I disagree. The chains of recurrences algebra is applicable to any
semi-ring, as long as the objects adhere to the properties, based on
the fact that chains of recurrences are strongly related to finite
differencing, which are known to work for functions over commutative
rings. You could use the algebra on matrices for example. There has
been a lot of similar work on differencing techniques for various
domains. Wouldn't it be prudent to prove you have a commutative
(semi-)ring when dealing with abstract values? In our chains of
recurrences approach we impose restrictions on symbolic coefficients to
ensure the validity of the representation. For example, {i,+,1}_i is
not valid.
a is a mixer (exponential), b is an envelope (interval coefficients),
c is a monotonic evolution (coefficients in {+, -}). The name of
scalar evolutions is not that far from the name "monotonic evolution"
used by Peng Wu, and it seemed appropriate to be used for the general
concept (you're free to disagree with my choice for using this name).
The fact remains that scalar evolutions are the same as chains of
recurrences based on my statement above.
2. What is the difference between the SSA-based algorithm described in
the paper and the G-SSA form proposed in 1995 by Tu and Padua [9].
Not the same. You're rebuilding a higher level tree from the
gimple-ssa form, but then you use abstract domains for representing
some of the difficult evolutions. Analyzers are like poetry: there
always will be room for something new because they are not comparable;
they just fill a missing topic.
But that is my whole point: if you have a (slightly) different code
representation (with the same semantics), I can think of another
(slightly) different code representation and modify an existing
algorithm to do the same job on the new representation. The basic
principles of the approach won't change though.
The show that there is no inherent difference in the approach, consider
the IV problem:
k = 0
DO
k = k + 1
j = k
k = j + 1
Using our algorithm published in 2001 [1,2] by analyzing the code
bottom-up we get:
k = 0
DO
k = k + 1 => (step 3) k = k + 2 => {0,+,2}
j = k => (step 2) k = k + 1
k = j + 1 => (step 1) k = j + 1
Note that we don't need to substitute the variables to obtain the CR,
following links is sufficient. It is just more convenient to use
replacement to visualize the algorithm.
With an SSA form, we get (again using the same algorithm):
k1 = 0
DO
k2 = phi(k1, k4) => (step 4) k4 = phi(0, k4) + 2 => {0,+,2}
k3 = k2 + 1 => (step 3) k4 = k2 + 2
j1 = k3 => (step 2) k4 = k3 + 1
k4 = j1 + 1 => (step 1) k4 = j1 + 1
This algorithm is applicable to affine, polynomial, and exponential
series. Maybe I am losing my mind here, but I don't see the difference
when comparing the scalar evolutions approach on SSA forms to the
earlier CR approach.
I also have decided to restrict the polynomials to a degree less or
equal than 2 (affine evolutions) because all the other constructs are
just pure nonsense, and not used by any optimizer or other analyzer.
It's too bad that I have not restricted the analyzer earlier based on
the suggestions from Zdenek Dvorak.
If you restrict the degree to affine, you recreate the induction
variable representations discussed in the Red Dragon book (offset +
stride) modulo the use of intervals, of course. But there are codes
that use quadratic forms. It is true that auto-vectorization wouldn't
be easy to achieve with non-affine forms thereby rendering the use of
higher-order forms useless.
- Robert van Engelen
Robert van Engelen: Associate Professor, Computer Science Department
Florida State University, 162 J. Love Bldg., Tallahassee, FL32306-4530
Offices: 162LOV/471DSL, (850)644-9661/645-0309, Fax: (850)644-0058
Email: [EMAIL PROTECTED], URL: http://www.cs.fsu.edu/~engelen
Re: Where does the C standard describe overflow of signed integers?
> From: Georg Bauhaus <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
Paul Schlie wrote:
I don't contest that it may, I simply don't believe it should.
>>> you can't seriously mean that with respect to uninitialized
>>> variables. this would mean you could not put local variables in
>>> registers. the effect on code quality woul be awful!
>> Why would anyone care about the performance of an access to an
>> un-initialized variable? [..] although do
>> see substantial value in producing compiled code which is strictly
>> consistent with the specified program and native target behavior,
>> regardless of its portability.
>
> You can have both, correctness and uninitialised local
> variables. For an impression of the difference in performance,
> and for a way to ensure correctness, I tried this
> (switch register/volatile in the declaration lines in comp
> and r to see the effects).
- which predominantly illustrates the effect of volatile semantics?
int x, y, z;
(vs.)
int x=1, y=2, z=3;
would illustrate the effect of potentially uninitialised local variables,
along with the accesses specified to the uninitialised elements of buffer.
in that circumstance, what optimizations would you advocate as beneficial?
> #include
> #include
>
> #define BUFFER_SIZE 1000 // must be > 0
> #define ITERATIONS 10 // must be > 0
>
> static inline int comp(const short, const short, const short);
>
> /* pre: a has elements, that is hi > 0. Frequently called */
> int r(short a[], size_t hi)
> {
> //register int x, y, z;
> volatile int x=1, y=2, z=3;
>
> assert(hi > 0);
>
> for (size_t c=0; c < hi + 2; ++c) {
> if (a[c]) {
> jfssoae:
> x = c + 3, y = z = a[c];
> if (comp(x, y, z)) z = x - y;
> }
> }
> return x + y + z;
> }
>
> static inline int comp(const short x, const short y, const short z)
> {
> //register int result = (x + y) == (x + z);
> volatile int result = (x + y) == (x + z);
> return result;
> }
>
> int main()
> {
> short buffer[BUFFER_SIZE];
> int result;
>
> assert(ITERATIONS > 0);
>
> for (int runs = 0; runs < ITERATIONS; ++runs) {
> result = r(buffer, BUFFER_SIZE);
> }
> return result;
> }
>
Re: please update the gcj main page
--- Ranjit Mathew <[EMAIL PROTECTED]> wrote: > John M. Gabriele wrote: > > Please update http://gcc.gnu.org/java/index.html and mention > > how much of the Java 1.5 spec that GCJ currently implements. > > > > When I refer folks to GCJ, the first thing they usually ask is, > > "does it support generics?" "autoboxing?" and so on. That info > > should be right up on the GCJ front page -- even if GCJ doesn't > > support those newer features. *Especially* if GCJ doesn't > > support those newer features. > > GCJ doesn't yet support any of the new 1.5 features. Hi Ranjit. Thanks for the reply. I hope I didn't sound confrontational -- I just realized I forgot to put any smilies into my original message. :) > Tom Tromey is developing "gcjx", a complete rewrite > of the GCJ compiler front-end, that would support > the 1.5 features in addition to being easier to maintain, > etc. You can check it out for yourself using the "gcjx-branch" > branch of the GCC CVS repository: > > http://gcc.gnu.org/cvs.html Nice. Thanks for the link. It would be great to have that information right on the gcj front page. How can we go about adding it? > As for your suggestion, I believe the correct place would > be "2.8 What features of the Java language are/aren't supported?" > in the FAQ: > > http://gcc.gnu.org/java/faq.html#2_8 Ah. Some expansion of that faq item would be useful (re. 1.4 vs 1.5). Following the link to the JLS page, I see that they are still pointing users to what looks to me like the Java 1.4 spec (I browsed the online html version's index, and there's no mention of generics or autoboxing), though a new version of that JLS book seems to be coming out last month. :) Also note that the "table of contents" at the top of the GCJ faq page has a typo: s/arn't/aren't/. > in addition to the front-page (if so desired). Yes. How do we go about it? :) Thanks, ---John > Ranjit. > > -- > Ranjit Mathew Email: rmathew AT gmail DOT com > > Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/ > Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: please update the gcj main page
Ranjit Mathew wrote: As for your suggestion, I believe the correct place would be "2.8 What features of the Java language are/aren't supported?" in the FAQ: http://gcc.gnu.org/java/faq.html#2_8 in addition to the front-page (if so desired). The FAQ is badly in need of an update - in fact, it should be moved over to the Wiki (http://gcc.gnu.org/wiki/GCJ) in order to be easier to update and maintain. We need to avoid incorporating too many random factiods on the front page, but mentioning that GCJ is currently approximately-compatible with Java 1.4.2 would be worthwhile. Bryce
Re: please update the gcj main page
John M. Gabriele wrote: Ah. Some expansion of that faq item would be useful (re. 1.4 vs 1.5). Following the link to the JLS page, I see that they are still pointing users to what looks to me like the Java 1.4 spec (I browsed the online html version's index, and there's no mention of generics or autoboxing), though a new version of that JLS book seems to be coming out last month. :) Also note that the "table of contents" at the top of the GCJ faq page has a typo: s/arn't/aren't/. in addition to the front-page (if so desired). Yes. How do we go about it? :) The web pages can be found in the "wwwdocs" module in GCC cvs. Go here for details: http://gcc.gnu.org/cvs.html Fixes and updates should be submitted to [EMAIL PROTECTED] and [EMAIL PROTECTED] We appreciate your help with this! Bryce
Successful gcc4.0.1 build (Redhat 9. Kernel 2.4.25)
make bootstrap successful build info: config.guess states: i686-pc-linux-gnu gcc -v states: Using built-in specs. Target: i686-pc-linux-gnu Configured with: /tmp/downloads/gcc-4.0.1/configure -prefix=/apps/Linux/gcc401 --program-suffix=401 Thread model: posix gcc version 4.0.1 /etc/issue states: Red Hat Linux release 9 (Shrike) Kernel \r on an \m uname -a states: Linux parsley 2.4.25-3dneg #1 SMP Tue Sep 7 11:16:44 BST 2004 i686 i686 i386 GNU/Linux -- (This is essentially the 2.4.25 kernel with some nfs patches) rpm -q glibc states: glibc-2.3.2-11.9 Notes: This build worked for installing sitewide over nfs fine. --prefix and --program-suffix worked fine. Jeff Clifford
Re: please update the gcj main page
--- Bryce McKinlay <[EMAIL PROTECTED]> wrote: > Ranjit Mathew wrote: > > >As for your suggestion, I believe the correct place would > >be "2.8 What features of the Java language are/aren't supported?" > >in the FAQ: > > > > http://gcc.gnu.org/java/faq.html#2_8 > > > >in addition to the front-page (if so desired). > > > > > > The FAQ is badly in need of an update - in fact, it should be moved over > to the Wiki (http://gcc.gnu.org/wiki/GCJ) in order to be easier to > update and maintain. The faq looks great. I'm paranoid though -- with wiki's, I always worry some random troll is going to pop in and make tiny incorrect changes just to mess with everyone. IMO, if you needed some special access privileges to make changes (besides just creating a username and password), that would be ideal. Also, the GCJ front page could use a link to the GCJ page of the wiki (right under or in place of the GCJ FAQ link). Further, in the column on the left (GCJ homepage), everything below the "About GCC" should probably be under some sort of GCC heading or graphic or color-scheme (to show that that stuff is not *specifically* GCJ-related, but rather, general GCC-related). I tend to end up hitting the GCC-in-general links on that page when I was looking to click GCJ-specific links. Thanks, ---John Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: please update the gcj main page
--- Bryce McKinlay <[EMAIL PROTECTED]> wrote: > John M. Gabriele wrote: > > > >Yes. How do we go about it? :) > > > > > > The web pages can be found in the "wwwdocs" module in GCC cvs. Go here > for details: http://gcc.gnu.org/cvs.html > > Fixes and updates should be submitted to [EMAIL PROTECTED] and > [EMAIL PROTECTED] We appreciate your help with this! > > Bryce > Thanks for the links Bryce. :) Will have a look at it this weekend. ---J Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: please update the gcj main page
On Jul 15, 2005, at 12:39 PM, John M. Gabriele wrote: The faq looks great. I'm paranoid though -- with wiki's, I always worry some random troll is going to pop in and make tiny incorrect changes just to mess with everyone. IMO, if you needed some special access privileges to make changes (besides just creating a username and password), that would be ideal. I check the recent edits page almost every day. Oh that reminds me to check it today. -- Pinski a GCC bug master
Re: Some notes on the Wiki
On Mon, 11 Jul 2005, Steven Bosscher wrote: > Unless we are going to require reviewing for wiki changes now, too, > there is no point in this entire discussion. I beg to disagree: first, we again raised the GFDL issue with RMS, we may have some new volunteers to help with web pages/documentation, got some discussions on the Wiki going (partly including RMS as well), and put some of the true motiviations for (not) doing specific things on the table. All of these are useful in my book. Gerald
[Q] Class instance layout details
Can someone please point me to a place where I can get information about how gcc (2.96 and later) lays out class instances? In other words if I examine the contents of an object pointer, is there a document that specifies how the contents of the memory with relation to the pointer correspond to the members, the vtable etc. Thanks, Bharadwaj
gcc vs Darwin memcmp
Darwin's memcmp has semantics that are an extension of the language standard: The memcmp() function returns zero if the two strings are identical, oth- erwise returns the difference between the first two differing bytes (treated as unsigned char values, so that `\200' is greater than `\0', for example). gcc's x86 inline expansion of memcmp doesn't do this, so I need to fix it. Is there interest in having this in mainline, and if so how would you like it controlled?
Re: please update the gcj main page
> "Bryce" == Bryce McKinlay <[EMAIL PROTECTED]> writes: Bryce> The FAQ is badly in need of an update - in fact, it should be moved Bryce> over to the Wiki (http://gcc.gnu.org/wiki/GCJ) in order to be easier Bryce> to update and maintain. Great idea, I agree. We've had a lot of trouble with bit-rot of the main pages over the years. Moving to the wiki might help, at least that way folks could more easily fix their own problems. Tom
Re: [Q] Class instance layout details
Bharadwaj Yadavalli <[EMAIL PROTECTED]> writes: > Can someone please point me to a place where I can get information > about how gcc (2.96 and later) lays out class instances? In other > words if I examine the contents of an object pointer, is there a > document that specifies how the contents of the memory with relation > to the pointer correspond to the members, the vtable etc. Newer versions of C++ more or less follow the Itanium C++ ABI: http://www.codesourcery.com/cxx-abi/abi.html That started somewhere in gcc 3.x, though I don't know exactly when. I don't know if there any documentation on object layout in 2.96. Ian
Re: [Q] Class instance layout details
On Jul 15, 2005, at 5:02 PM, Ian Lance Taylor wrote: Bharadwaj Yadavalli <[EMAIL PROTECTED]> writes: Newer versions of C++ more or less follow the Itanium C++ ABI: http://www.codesourcery.com/cxx-abi/abi.html That started somewhere in gcc 3.x, though I don't know exactly when. It started with 3.0. And then there have been some bug fixes to GCC since then to get closer and closer to the what the ABI says. Thanks, Andrew Pinski
scheduling insn on none
Hi, I am trying to add instruction scheduling to a machine description. I added everything I think I need and the .dfa looks right to me, but when I compile with -fsched-verbose=10 I get something that looks like this: ;; == ;; -- basic block 0 from 9 to 83 -- before reload ;; == ;; --- forward dependences: ;; --- Region Dependences --- b 0 bb 0 ;; insn codebb dep prio cost blockage units ;; -- --- - ;;917 0 012 10 - 0 none : 83 10 ;; 1062 0 111 10 - 0 none : 83 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 ;; 1236 0 110 10 - 0 none : 83 13 ;; 1317 0 2 9 10 - 0 none : 83 33 ;; 1436 0 110 10 - 0 none : 83 15 ;; 1517 0 2 9 10 - 0 none : 83 33 ;; 1636 0 110 10 - 0 none : 83 17 (snip) ;; Ready list after queue_to_ready:19 32 17 15 13 30 28 26 24 22 20 ;; Ready list after ready_sort:32 19 17 15 13 30 28 26 24 22 20 ;; Ready list (t = 6):32 19 17 15 13 30 28 26 24 22 20 ;; --> scheduling insn <<<20>>> on unit none ;; dependences resolved: insn 21 into queue with cost=1 ;; Ready-->Q: insn 21: queued for 1 cycles. ;; Ready list (t = 6):32 19 17 15 13 30 28 26 24 22 ;; Q-->Ready: insn 21: moving to ready without stalls ;; Ready list after queue_to_ready:21 32 19 17 15 13 30 28 26 24 22 ;; Ready list after ready_sort:32 21 19 17 15 13 30 28 26 24 22 ;; Ready list (t = 7):32 21 19 17 15 13 30 28 26 24 22 ;; --> scheduling insn <<<22>>> on unit none ;; dependences resolved: insn 23 into queue with cost=1 ;; Ready-->Q: insn 23: queued for 1 cycles. ;; Ready list (t = 7):32 21 19 17 15 13 30 28 26 24 ;; Q-->Ready: insn 23: moving to ready without stalls (snip) What does it mean by "unit none"? Has anyone else encountered this problem? What more information do you think you would need to diagnose it? The port I am working on came from gcc 3.4.2. Thank you, Charles
Can't turn off overflow_warning?
After examining the source and documentation, it appears to me that in
4.0.* and on mainline one cannot turn off the warning generated by
overflow_warning, in, for example,
[descartes:~] lucier% cat test.c
#include
int main() {
if (1048256 * 1048256 < 0)
printf("1");
else
printf("2");
return 0;
}
[descartes:~] lucier% /pkgs/gcc-4.0.0/bin/gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure --prefix=/pkgs/gcc-4.0.0
--with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3
Thread model: posix
gcc version 4.0.0
[descartes:~] lucier% /pkgs/gcc-4.0.0/bin/gcc -O1 -Wall -W -Wextra
-fwrapv test.c
test.c: In function 'main':
test.c:4: warning: integer overflow in expression
[descartes:~] lucier% ./a.out
1[descartes:~] lucier%
I'd like to be able to do this, since I'm auto-generating code that
explicitly uses overflow tests that assume that signed ints overflow
using twos-complement arithmetic and I don't want to be distracted by
extraneous warnings when constant propagation in the Scheme system puts
constants into this C code.
Personally, I'd like overflow_warning to be turned off for signed ints
if -fwrapv is passed as a flag. I suppose an explicit
-Wno-overflow-warning would be OK, too.
If I were to propose a patch, which way should I go?
Brad
Re: Can't turn off overflow_warning?
On Jul 15, 2005, at 10:27 PM, Bradley Lucier wrote: After examining the source and documentation, it appears to me that in 4.0.* and on mainline one cannot turn off the warning generated by overflow_warning, in, for example, IIRC the C standard requires that a warning here but I could be wrong. -- Pinski
Re: Can't turn off overflow_warning?
> If I were to propose a patch, which way should I go? Why not check out my recently posted -Wpragmas patch on gcc-patches? It takes a set of existing non-optional warnings, and gives them an option that can be used to disable them, which defaults to on (i.e. -Wno-pragmas is the useful option). That way, you get control but the default action stays the same.
Re: scheduling insn on none
"Tabony, Charles" <[EMAIL PROTECTED]> writes: > What does it mean by "unit none"? First I'll note that you shouldn't see this when using the DFA scheduler (define_insn_reservation, etc.). You should only see it when using the old pipeline description (define_function_unit, etc.). The old pipeline description has been removed from the current sources, but it was still present in 3.4. "unit none" simply means that the scheduler doesn't know which functional unit(s) are used by the insn. The insn did not match any of the tests in the various define_function_unit clauses. If you actually wrote define_insn_reservation clauses, then see TARGET_SCHED_USE_DFA_PIPELINE_INTERFACE. Ian
Re: Can't turn off overflow_warning?
Andrew Pinski <[EMAIL PROTECTED]> writes: | On Jul 15, 2005, at 10:27 PM, Bradley Lucier wrote: | | > After examining the source and documentation, it appears to me that | > in 4.0.* and on mainline one cannot turn off the warning generated | > by overflow_warning, in, for example, | | IIRC the C standard requires that a warning here but I could be wrong. Please not again. The C standard knows nothing about warning. There is a notion of diagnostic but I don't think it makes any sense in the particular case Brad describes. | | -- Pinski -- Gabriel Dos Reis [EMAIL PROTECTED]
Re: [Flex] Getting the absolute input file position
On Friday 15 July 2005 03.42, [EMAIL PROTECTED] wrote:
> I need to figure out how I can augment the generated file to get
> the absolute input file position within two rules:
> start file position...end file position.
In the pl1gcc project, I have implemented token offsets across multiple input
files for the scanner. Don't expect too much help from Flex though. You will
have to code the beancounting yourself.
I had to extend the YYLTYPE structure:
typedef struct pl1ltype
{
int first_file;
int first_line;
int first_column;
int first_offset;
int last_file;
int last_line;
int last_column;
int last_offset;
} pl1ltype;
#define YYLTYPE pl1ltype
pl1gcc.sourceforge.net
hope this helps you
Henri
