returning struct or union with just double on Win32/x86

[Jay K]

typedef struct { double d; } Struct;


Struct f1 ()
{ 
Struct res = {3.0};
return res;
}

typedef union { double d; } Union;


Union f2 ()
{
Union res = {3.0};
return res;
}

x86 mingw 7.3.0

The first returns in ST0, the  second in edx:eax.

Msvc returns first in edx:eax.

Seems like a bug?

Thank you,
 - Jay

computed goto, const, truncated int, C++, etc.

[Jay K]

computed goto.
​
​
The documentation advertises read only relative address.​
​
Like this:​
​
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html​
​
```​
static const int array[] = { &&foo - &&foo, &&bar - &&foo,​
                             &&hack - &&foo };​
goto *(&&foo + array[i]);​
```​
​
However, this doesn't quite work and is a little flawed.​
​
What one wants is:​
​
1. int or int32_t, as stated.​
1b. Or a target specific type provided by the compiler​
that encompasses the largest distance in a function.​
But in reality that is int/int32_t.​
​
Not blow the space unnecessarily on a 64bit integer, if executables and 
therefore distances within functions are limited to 32bits (I realize, there is 
a signnedess problem hypothethically, but ultimately I expect an assembler or 
linker warning for the label math overflow).

2. Syntax that works in C and C++.​
And is truly const, no dynamic initializer.
​This is crucial.

3. Preferably without casting.​
​But if I must, ok.


4. Instead of relative to a label, I should be able to use relative​
to the array itself. Which then only allows a single ampersand.​
Double might be nice, but whatever works.​
I think that might save an instruction.
It isn't critical.
​
5. 32bit and 64bit.​
​Crucial.


Many combinations do work, but you sometimes have to cast​
to char* or int or size_t.​
Sometimes have to narrow.​
Only sometimes can use the address of the array.​
Not always valid C and C++.​
​
And not all combinations do work.​
We have code that compiles as C or C++, unless/until we decide​
to use C++, and I couldn't make it work across the board.​
​
But now I'll see if the code is really any better than switch...

 - Jay

extern const initialized warns in C

[Jay K]

extern const int foo = 123;



Why does this warn?
This is a valid portable form, with the same meaning
across all compilers, and, importantly, portably
to C and C++.

I explicitly do not want to say:

  const int foo = 123

because I want the code to be valid and have the same meaning
in C and C++ (modulo name mangling).

I end up with:

// Workaround gcc warning.
#ifdef __cplusplus
#define EXTERN_CONST extern const
#else
#define EXTERN_CONST const
#endif


EXTERN_CONST int foo = 123;

and having to explain it to people.

$ cat 1.c
extern const int foo = 123;
$ $HOME/gcc720/bin/gcc -c -S 1.c
1.c:1:18: warning: 'foo' initialized and declared 'extern'
 extern const int foo = 123;
  ^~~
$ $HOME/gcc720/bin/gcc -c -S -xc++ -Wall -pedantic 1$ $HOME/gcc720/bin/gcc -v
Using built-in specs.

COLLECT_GCC=/Users/jay/gcc720/bin/gcc
COLLECT_LTO_WRAPPER=/Users/jay/gcc720/libexec/gcc/x86_64-apple-darwin16.7.0/7.2.0/lto-wrapper
Target: x86_64-apple-darwin16.7.0
Configured with: ../gcc-7.2.0/configure -prefix=/Users/jay/gcc720 -disable-nls 
-disable-bootstrap
Thread model: posix
gcc version 7.2.0 (GCC) $ 


Thank you,
 - Jay



 

Re: extern const initialized warns in C

[Jay K]

By this argument there is a missing warning for the equivalent:

  const int foo = 123;

with no previous extern declaration.

As well, there is no warning in C++.
All three constructs are equivalent, yet only one gets a warning.

Interesting point, that I had not realized, and with an often acceptable
workaround, however also there exist coding conventions that prohibit use of 
static.
Instead they "hide" things by omitting them from headers only.

That can still be worked around, just put the declaration right before the 
definition,
in the same source file.

I realize there are many arguments for and against file level static.

 - Jay  


From: David Brown 
Sent: Monday, January 22, 2018 8:32 AM
To: Jay K; gcc
Subject: Re: extern const initialized warns in C
  

On 21/01/18 08:12, Jay K wrote:
> extern const int foo = 123;
> 
> 
> 
> Why does this warn?
> This is a valid portable form, with the same meaning
> across all compilers, and, importantly, portably
> to C and C++.
> 
> I explicitly do not want to say:
> 
>   const int foo = 123
> 
> because I want the code to be valid and have the same meaning
> in C and C++ (modulo name mangling).
> 
> I end up with:
> 
> // Workaround gcc warning.
> #ifdef __cplusplus
> #define EXTERN_CONST extern const
> #else
> #define EXTERN_CONST const
> #endif
> 
> 
> EXTERN_CONST int foo = 123;
> 
> and having to explain it to people.
> 

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977>


45977 – "warning: 'i' initialized and declared 'extern ...
gcc.gnu.org
GCC Bugzilla – Bug 45977 "warning: 'i' initialized and declared 'extern'" could 
use a separate warning flag controlling it Last modified: 2017-07-26 15:36:22 
UTC

This suggests that gcc authors consider mixing "extern" and
initialization to be such bad style that the compiler warns by default.
 But the "bug" is that there is no flag to turn off this warning.
(Ideally every warning should have a matching flag, even if the warning
is enabled by default.)

Usually you do not want to have "extern" and initialisation in the same
line - it indicates a questionable organisation of your sources which is
more likely to be error-prone than the standard idioms.  (I say
"questionable", not necessarily wrong - but certainly I would question
it if I saw it in source code.)

Normally you want:

// file.h
// declaration, not definition
extern const int foo;

// file.c
#include 
// definition
const int foo = 123;

// otherfile.c
#include 
int usefoo(void) { return foo; }


The key advantages of this sort of setup are a cleaner separation
between declarations (which you need to /use/ things) and the
definitions (which should normally only exist once in the program -
certainly for C).  The declarations and definitions only exist in one
place, and they are checked for consistency - there are no "extern"
declarations lying around in C files that might get out of step from
changes in the headers or other files with definitions.

To be consistent with this, and to work consistently with C and C++, I
have a strict policy that a C (or C++) file never contains  declarations
without definitions (and initialisations as needed), with each
definition either also declared as "extern" in a matching header file,
or it is declared as "static".

This sort of arrangement is very common - though many people are lazy
about using "static".  (In C++, you can also use anonymous namespaces,
but "static" works for consistency between C and C++.)


Still, gcc should have a flag to disable this warning if you have reason
to use "extern const int foo = 123;" - it is, after all, correctly
defined C code.



> $ cat 1.c
> extern const int foo = 123;
> $ $HOME/gcc720/bin/gcc -c -S 1.c
> 1.c:1:18: warning: 'foo' initialized and declared 'extern'
>  extern const int foo = 123;
>   ^~~
> $ $HOME/gcc720/bin/gcc -c -S -xc++ -Wall -pedantic 1$ $HOME/gcc720/bin/gcc -v
> Using built-in specs.
> 
> COLLECT_GCC=/Users/jay/gcc720/bin/gcc
> COLLECT_LTO_WRAPPER=/Users/jay/gcc720/libexec/gcc/x86_64-apple-darwin16.7.0/7.2.0/lto-wrapper
> Target: x86_64-apple-darwin16.7.0
> Configured with: ../gcc-7.2.0/configure -prefix=/Users/jay/gcc720 
> -disable-nls -disable-bootstrap
> Thread model: posix
> gcc version 7.2.0 (GCC) $ 
> 
> 
> Thank you,
>  - Jay
> 
> 
> 
>  
> 

Re: extern const initialized warns in C

[Jay K]

Also the warning did not include a link explaining the desired workaround.


Since you advocate for static...and I know it has big value..

There are the following reasons against static:

 - It is prohibited in some coding conventions.
    They instead hide symbols by omitting them from any headers.

 - It allows/encourages symbols duplicated from a human point of view,
   leading to harder to read code; but this is also the point and good,
   it offers scope to pick shorter names, or at least hide
   names (you can still strive for globally unique names, in
   case the symbols later have to be made extern)
   
 - it leads to accidental duplication, static int foo = 123 in a header

 - There are toolsets that don't resolve statics in disassembly

 - It only allows for sharing within a file and hiding from all others,
   it doesn't allow sharing for within a few files and hiding from others

 - It sort of doesn't work with "unity builds" old fashioned LTO/LTCG where one
   source file includes the rest
   

   I think a linker switch to report symbols that could be static
   might be useful.
   
   I find the "scoping" too hard to pass it, and if I need to make
   the symbol extern in future, I can afford a rename to do it.
   

    - Jay




From: Jay K
Sent: Monday, January 22, 2018 9:31 AM
To: David Brown; gcc
Subject: Re: extern const initialized warns in C
  


By this argument there is a missing warning for the equivalent:

  const int foo = 123;

with no previous extern declaration.

As well, there is no warning in C++.
All three constructs are equivalent, yet only one gets a warning.

Interesting point, that I had not realized, and with an often acceptable
workaround, however also there exist coding conventions that prohibit use of 
static.
Instead they "hide" things by omitting them from headers only.

That can still be worked around, just put the declaration right before the 
definition,
in the same source file.

I realize there are many arguments for and against file level static.

 - Jay  


From: David Brown 
Sent: Monday, January 22, 2018 8:32 AM
To: Jay K; gcc
Subject: Re: extern const initialized warns in C
  

On 21/01/18 08:12, Jay K wrote:
> extern const int foo = 123;
> 
> 
> 
> Why does this warn?
> This is a valid portable form, with the same meaning
> across all compilers, and, importantly, portably
> to C and C++.
> 
> I explicitly do not want to say:
> 
>   const int foo = 123
> 
> because I want the code to be valid and have the same meaning
> in C and C++ (modulo name mangling).
> 
> I end up with:
> 
> // Workaround gcc warning.
> #ifdef __cplusplus
> #define EXTERN_CONST extern const
> #else
> #define EXTERN_CONST const
> #endif
> 
> 
> EXTERN_CONST int foo = 123;
> 
> and having to explain it to people.
> 

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977>


45977 – "warning: 'i' initialized and declared 'extern ...
gcc.gnu.org
GCC Bugzilla – Bug 45977 "warning: 'i' initialized and declared 'extern'" could 
use a separate warning flag controlling it Last modified: 2017-07-26 15:36:22 
UTC


45977 – "warning: 'i' initialized and declared 'extern ...
gcc.gnu.org
GCC Bugzilla – Bug 45977 "warning: 'i' initialized and declared 'extern'" could 
use a separate warning flag controlling it Last modified: 2017-07-26 15:36:22 
UTC

This suggests that gcc authors consider mixing "extern" and
initialization to be such bad style that the compiler warns by default.
 But the "bug" is that there is no flag to turn off this warning.
(Ideally every warning should have a matching flag, even if the warning
is enabled by default.)

Usually you do not want to have "extern" and initialisation in the same
line - it indicates a questionable organisation of your sources which is
more likely to be error-prone than the standard idioms.  (I say
"questionable", not necessarily wrong - but certainly I would question
it if I saw it in source code.)

Normally you want:

// file.h
// declaration, not definition
extern const int foo;

// file.c
#include 
// definition
const int foo = 123;

// otherfile.c
#include 
int usefoo(void) { return foo; }


The key advantages of this sort of setup are a cleaner separation
between declarations (which you need to /use/ things) and the
definitions (which should normally only exist once in the program -
certainly for C).  The declarations and definitions only exist in one
place, and they are checked for consistency - there are no "extern"
declarations lying around in C files that might get out of step from
changes in the headers or other files with definitions.

To be consistent with this, and to work consistently with C and C++, I
have a strict policy that a C (or C++) file never con

Re: extern const initialized warns in C

[Jay K]

> I find the "scoping" too hard to pass it, and if I need to make
> the symbol extern in future, I can afford a rename to do it.


I mean, I actually like like the ability to shorten file level static symbols.


As you point out, true, you can have it both ways, static does not force 
shortening, merely allows it, and protects you from inadvertant duplication.


Really, the prohibition against file level static is used in large code bases.

You already have to chose unique extern names, and depend on the linker to 
diagnose duplicate externals for them.

Extending this by barring statics isn't necessarily significant.

Such code bases prefix every extern identifier with some "local" prefix, and 
any missing prefix is easy to spot and a stylistic mistake.

(i.e. local to the subsystem or directory -- I realize it is the very 
definition of "local" that makes or break this)


I understand that hiding by omission from headers is not hiding at the linker 
level.


I agree there are scalability problems with naming in C, but it isn't clear 
static helps significantly.


There is an interesting side effect though that I think is not very much 
appreciated.

Large C code bases are more amenable to plain text search than large C++ code 
bases, due to the "more uniqueness" of symbols.


This plain text search aspect is one of extremely few advantages I see to C 
over C++, perhaps the only one.


 - Jay



From: David Brown 
Sent: Monday, January 22, 2018 10:14 AM
To: Jay K; gcc
Subject: Re: extern const initialized warns in C

Hi,

I made some points in my other reply.  But for completeness, I'll tackle
these too.

On 22/01/2018 10:38, Jay K wrote:
> Also the warning did not include a link explaining the desired workaround.
>
>
> Since you advocate for static...and I know it has big value..
>
> There are the following reasons against static:
>
>   - It is prohibited in some coding conventions.
>  They instead hide symbols by omitting them from any headers.

As noted before, that is insane.  It gives no benefits but makes it easy
to cause mistakes that are hard to find.

>
>   - It allows/encourages symbols duplicated from a human point of view,
> leading to harder to read code; but this is also the point and good,
> it offers scope to pick shorter names, or at least hide
> names (you can still strive for globally unique names, in
> case the symbols later have to be made extern)

Omitting "static" also allows symbol duplication.  It just means that
such duplication is an error in the code - which may or may not be
caught at link time.

You /can/ have a coding convention that discourages duplicate symbol
names - even when using "static".  That might help a little in
understanding, but will quickly mean bloated source code that is harder
to read and follow (because you end up with long-winded symbol names
everywhere).

Such conventions are not scalable, are hopeless for multi-programmer
projects, terrible for code re-use, and can make code far harder to read
and write.

The scoping and naming in C is limited enough without omitting half the
features it has to deal with modularisation.

>
>   - it leads to accidental duplication, static int foo = 123 in a header

It is quite simple - don't do that.  It is appropriate for constant data
- "static const int foo = 123;" in a header will be fine, because "foo"
has the same value everywhere and is likely to be "optimised away".
That is the reason C++ makes "const int foo = 123;" effectively static.

Headers (in C, and mostly in C++) are for /declarations/, not
definitions - at least if you want to write structured and modular code.

>
>   - There are toolsets that don't resolve statics in disassembly

Statics are local to the file.  Disassemblies should show them when they
are used.  For the tiny, tiny proportion of C programmers that ever use
a disassembler, if their toolchains are not good enough then they should
get better toolchains.  It should /never/ be a problem when using
assembly listing files generated by the compiler, which are almost
always more useful than disassembling object code.

Making a coding convention to suit this requirement is like making
gloves with 6 fingers so that they fit people with an extra digit.

>
>   - It only allows for sharing within a file and hiding from all others,
> it doesn't allow sharing for within a few files and hiding from others

C has no good way to allow sharing between a few files and hiding from
others.  Such shared identifiers must be program-wide global.  But that
does /not/ mean you should make /everything/ program-wide global!  It
means you should minimise such sharing, prefix such shared names in a
way likely to minimise conflicts, and organise your source c

Re: extern const initialized warns in C

[Jay K]

 > If you put static (non-const)
 > variables in your header files, you have misunderstood how to use header
 > files in C programming.


 Not me, and usually const, but people do it, both.
 Even the consts can get duplicated.
 Even the simple C++
   const int one = 1;


 I can take the address of.
 It is also unusual and maybe dumb. There are too many programmers
 writing C and C++ with too little oversight to rule these out.


 The static prohibition might be too closed to identity.


 I understand about the local edit, but it behooves
 one to make the non-edited build debugable too.


 I know you can only go so far, can't litter it with printf
 or breakpoints or volatile, nor can compile it unoptimized
 and ship it, but uniquifying function/data names seems
 maybe affordable for debuggability of official builds.


  > If you want to switch from C to C++, that's fine by me


 But the rest of my team has to agree.


  > C++ gives you namespaces, which gives you
  > nother way to group your identifiers and control their scope.


I know *all* about C++ but I think for newbies it is best
to start out focusing on member functions.
Pretend there is a type global namespace to replace C's function
global namespace. That is a huge improvement on its own.


 > It makes a large difference - both for code size and speed


 I only recently learned of how static impacts ELF visibility
 and therefore performance. Windows does not work this way,
 and I'm sure MacOS does either. Non-static on Windows does not imply
 replacable at dynamic link time, not even if the function is exported.
 Symbols are always resolved directly within the dll/sharedobject by
 the static linker if they are present with no pointer or stub in the way.
 (Ok, if you incorrectly annotate as __declspec(dllexport) and you don't
 use LTO/LTCG, then you will call through a pointer, but no stub,
 no actual inter-positionableness, and it is a rare occurence.)


 There is also always a two level namespace -- imported functions are qualified
 by the dll name they are expected to be in. For multiple dlls to export
 the same function name creates no ambiguity and implies no replacement
 of one by the other, and no semantic difference depending on load order.
 Unless someone writes very wierd code calling dlopen/dlsym like crazy.
 There is no LD_PRELOAD, slight loss, and replacing e.g. operator new
 isn't really possible process-wide, only within the scope of the static link,
 and even that is so rare, that it is probably sufficient.


 There is no going out of the way to accurately simulate the static linker
 at dynamic link time. Functions are only exported if they are annotated
 in source or listed in a separate file. Not just by being non-static.


  - Jay



From: David Brown 
Sent: Monday, January 22, 2018 10:42 AM
To: Jay K; gcc
Subject: Re: extern const initialized warns in C



On 22/01/2018 11:14, Jay K wrote:
> I  meant:
>
>
> extern const foo = 123;
>
>
> does not warn in C++, but by these arguments, should.
>

Yes, I think it should.  But I am a compiler user, not a compiler
author, so my bias is strongly towards /my/ code rather than a wider
audience.

>
>
> I understand that const int foo = 123 is static in C++.
>
> It is this difference between C and C++ and the desire to write code
> that means the same in C and C++ is why I write extern const int foo =
> 123 in the first place. If I was just writing C forever and not planning
> to compile as C++ ever then I would omit the redundant extern -- and not
> get a warning -- the other inconsistency!

As I suggested, put the declaration in the header and the definition in
the source file.  Then it is the same code for C and C++, works
correctly, and gives no warnings no matter what flags you use.  And it
is modular, structured, and lets programmers see exactly what is
"exported" from that C file by looking in a short header rather than
digging through a long source file.

>
>
> To repeat for clarity:
>
>
>   1 C: extern const int foo = 123; => warns, for reasons explained and
> understood even if not agreed
>
>   2 C: const int foo = 123; => means the same thing, but no warning;
> inconsistent?
>
>   3 C++: extern const int foo = 123; => also no warning, inconsistent?
>
>
>
> The prohibition against file level static is actually quite widespread
> and adhered to.
>

Can you give references or links?  As I say, I think such a convention
is /seriously/ wrong.

(There are plenty of other conventions that I think are wrong - even
famous and "professional" standards like MISRA have some daft ideas.)

>
> Along with it, of course, comes a mandate to pick globally unique names.

That mandate I can understand.  There are rational justifications for
it, even though I don't agree wi

r9 on ARM32?

[Jay K]

I'm wondering what is the role of r9 on ARM32, on Linux and Android.
  On Apple it is documented as long ago reserved, these days available for 
scratch.

I've looked around a bit but haven't gotten the full answer.

It is "the PIC register", I see.

What does that imply? Volatile? Von-volatile?

In particular I'm looking for a spare register, to pass an extra "special" 
parameter in, that can be considered volatile and never otherwise has a 
parameter.

Most ABIs have a few candidates, but arm32 comes up relatively short.

Intra procedural scratch (r12) probably cannot work for me.
I know gcc uses it for nested function context and that is laudable. I wish I 
could guarantee no code between me setting it and it being consumed.

And if it is volatile, I'd want the dynamic linker stubs to still preserve it 
incoming.

Thank you,
 - Jay

suggest more inhibit_libc for ia64-linux -- problems with exception handling when haven't yet built glibc.

[Jay K]

Building cross gcc and binutils is easy, but for the libc/libgcc parts. I've 
wrestled with this a lot.


I'm trying to build an ia64-linux cross toolset from a Mac.
Including cross building glibc.


I've gone through many options and errors, including sysroot and not,
following the LFS stuff and the CLFS stuff.


(Linux-from-Scratch, Cross-Linux-from-Scratch)

(CLFS good in that it uses sysroot and is cross, but it uses older versions and 
for
now I gave up, and non-cross-LFS is basically cross anyway.)


Some of what I hit:


In file included from /src/gcc-4.6.2/libgcc/../gcc/unwind-sjlj.c:30:0:
/obj/gcc/./gcc/include/unwind.h:214:20: fatal error: stdlib.h: No such file or 
directory
/src/gcc-4.6.2/libgcc/../gcc/config/ia64/fde-glibc.c:33:20: fatal error: 
stdlib.h: No such file or directory
/src/gcc-4.6.2/libgcc/../gcc/config/ia64/fde-glibc.c:36:18: fatal error: 
link.h: No such file or directory




and suggest, more use of inhibit_libc:



jbook2:gcc-4.6.2 jay$ diff -u gcc/config/ia64/fde-glibc.c.orig 
gcc/config/ia64/fde-glibc.c
--- gcc/config/ia64/fde-glibc.c.orig 2011-11-12 13:30:55.0 -0800
+++ gcc/config/ia64/fde-glibc.c 2011-11-12 13:32:47.0 -0800
@@ -25,6 +25,8 @@
 /* Locate the FDE entry for a given address, using glibc ld.so routines
 to avoid register/deregister calls at DSO load/unload. */
 
+#ifndef inhibit_libc
+
 #ifndef _GNU_SOURCE
 #define _GNU_SOURCE 1
 #endif
@@ -160,3 +162,5 @@
 
return data.ret;
 }
+
+#endif


jbook2:gcc-4.6.2 jay$ diff -u gcc/unwind-generic.h.orig gcc/unwind-generic.h
--- gcc/unwind-generic.h.orig 2011-11-12 13:02:32.0 -0800
+++ gcc/unwind-generic.h 2011-11-12 16:11:46.0 -0800
@@ -211,7 +211,9 @@
 compatible with the standard ABI for IA-64, we inline these. */
 
#ifdef __ia64__
+#ifndef inhibit_libc
 #include 
+#endif
 
static inline _Unwind_Ptr
 _Unwind_GetDataRelBase (struct _Unwind_Context *_C)
@@ -223,7 +225,9 @@
 static inline _Unwind_Ptr
 _Unwind_GetTextRelBase (struct _Unwind_Context *_C __attribute__ 
((__unused__)))
 {
+#ifndef inhibit_libc
 abort ();
+#endif
 return 0;
 }



I understand the result is "broken" and that a second build will be needed.
But that seems to be common practise in building a cross toolset when
"libc" doesn't already exist.

And even then, I'm not done. Maybe this still won't work.

I know about buildroot for example but they don't have IA64 support.


I'm going to see if there is an option for building without any exception 
handling support.
It looks like not. Though this diff sort of does that.


Another thing I'll try is skipping libgcc for the first pass.
But I did get an error about missing libgcc when building glibc.
The 64bit math stuff at least ought to go in, but I realize it's probably not 
needed for 64bit targets.


Thank you,
 - Jay

FW: gcc uses too much stack?

[Jay K]

Have people considered that stack space should be used more conservatively by 
gcc?
More malloc, less alloca, fewer/smaller local variables?
More std::stack or such, less recursion on the machine stack?
(Yes, I know std::stack has no existing use in gcc yet.)


Don't make the amount of stack used dependent on the input?
If something can be compiled with N stack, then anything can be?
  Is a reasonable goal?


You know, heap is generally much larger than stack, and easier to detect 
exhaustion of?
Granted, yes, I understand very well, heap is much slower to allocate and 
requires explicit free,
and is subject to fragmentation.


Thanks,
 - Jay

> Date: Sun, 8 Jan 2012 00:05:01 -0500
> To: djgpp-digest-da...@delorie.com
> 
> 2012/01/07/15:03:06 ANNOUNCE: DJGPP port of GNU binutils 2.22 uploaded.
> 
> --
> 
...
>   DJGPP specific changes.
>   ===
>   - This port allows a maximal number of 4294967296 relocations per object 
> file
> and a maximal number of 4294967296 of lines per executable file.
> The previous limits were the classical COFF limitations of 65536 for 
> boths.
> Please note, that due to limitations inherent to DOS and memory ressources
> not every file can be compiled.  E.g.: to be able to compile a single file
> containing up to 3 * 65536 relocations I had to increment stack space of
> cc1.exe from 2MB to 10MB.  If the file contains 4 * 65536 relocations then
> cc1.exe aborts because memory has become exhausted.  Neither as.exe nor
> ld.exe have shown memory issues.  Both have the standard stack space of
> 512KB.  In other words, even if 32 bit values for relocation and line
> counters are now supported by DJGPP port of as.exe and ld.exe it does not
> imply that large files can be successfully compiled and linked.  There are
> memory limitations that may not be solvable.
...
> 
> Enjoy.
> 
> Guerrero, Juan Manuel 
...

  

gcc 4.5.0 vms-gcc_shell_handler.c needs #define __NEW_STARLET

[Jay K]

/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c: In function 
'get_dyn_handler_pointer':
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: error: 
'PDSCDEF' undeclared (first use in this function)
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: note: 
each undeclared identifier is reported only once for each function it appears in
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:13: error: 
'pd' undeclared (first use in this function)
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: 
warning: cast to pointer from integer of different size
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: error: 
expected expression before ')' token
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:17: 
warning: cast to pointer from integer of different size
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:10: 
warning: cast to pointer from integer of different size
make[4]: *** [vms-gcc_shell_handler.o] Error 1
make[3]: *** [multi-do] Error 1
make[2]: *** [all-multi] Error 2
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2
 
 
fix, put this at top:
  
 
#ifndef __NEW_STARLET
#define __NEW_STARLET
#endif
 
 
 - Jay
  

gcc 4.5.0 stddef.h clobbers __size_t with #define, breaks VMS (code already avoids similar on FreeBSD)

[Jay K]

VMS decc$types.h:

    typedef unsigned int __size_t;

but with GCC 4.5.0 this preprocesses as:

    typedef unsigned int ;
    
and there are ensuing errors e.g. when compiling gcc/libiberty/regex.c

probably because of:

/usr/local/lib/gcc/alpha-dec-vms/4_5_0/include/stddef.h (it does get included)
#if defined (__FreeBSD__) && (__FreeBSD__>= 5)
/* __size_t is a typedef on FreeBSD 5!, must not trash it. */
#else
#define __size_t
#endif

presumably should be more like:

#if (defined (__FreeBSD__) && (__FreeBSD__>= 5)) || defined(__vms)
/* __size_t is a typedef on FreeBSD 5 and VMS, must not trash it! */
#else
#define __size_t
#endif


That gets further, then hits 


src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2':
/src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn:
(insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135)
    (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0)
    (const_int 5 [0x5]))) -1 (nil))
/src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in 
extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [regex.o] Error 1


 - Jay

  

gcc-4.5.0 internal compiler error on alpha-dec-vms compiling libiberty/regex.c without -mbwx

[Jay K]

> src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2':
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn:
> (insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135)
> (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0)
> (const_int 5 [0x5]))) -1 (nil))
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in 
> extract_insn, at recog.c:2103
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make: *** [regex.o] Error 1


Fixed by saying make CFLAGS=-mbwx, which enables some byte/word instructions.
More information needed?

Let's see.
Here is the code:

/* Like `insert_op1', but for two two-byte parameters ARG1 and ARG2.  */
/* ifdef WCHAR, integer parameter is 1 wchar_t.  */

static void
PREFIX(insert_op2) (re_opcode_t op, UCHAR_T *loc, int arg1,
    int arg2, UCHAR_T *end)
{
  register UCHAR_T *pfrom = end;
  register UCHAR_T *pto = end + 1 + 2 * OFFSET_ADDRESS_SIZE;

  while (pfrom != loc)
    *--pto = *--pfrom;

  PREFIX(store_op2) (op, loc, arg1, arg2);
}

Here is a reduced/preprocessed form that hits the same problem:


jbook2:~ jay$ cat re.c
typedef unsigned char UCHAR;


void insert_op2 (UCHAR *loc, UCHAR *end)
{
   UCHAR *pfrom = end;
   UCHAR *pto = end + 1;

  while (pfrom != loc)
    *--pto = *--pfrom;
}

jbook2:~ jay$ alpha-dec-vms-gcc -c re.c

jbook2:~ jay$ alpha-dec-vms-gcc -c -O2 re.c
re.c: In function 'insert_op2':
re.c:10:1: error: unrecognizable insn:
(insn 58 57 59 5 re.c:9 (set (reg:DI 120)
    (plus:SI (subreg/s:SI (reg/v/f:DI 108 [ pfrom ]) 0)
    (const_int 1 [0x1]))) -1 (nil))
re.c:10:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
jbook2:~ jay$ 


I opened a bug in the database.


  - Jay
  

gcc4.5.0/libiberty/pex-common.h missing pid_t on vms

[Jay K]

In file included from /src/gcc-4.5.0/libiberty/pex-common.c:23:0:
/src/gcc-4.5.0/libiberty/pex-common.h:73:3: error: expected 
specifier-qualifier-list before 'pid_t'


the code:

/* pid_t is may defined by config.h or sys/types.h needs to be
   included.  */
#if !defined(pid_t) && defined(HAVE_SYS_TYPES_H)
#include 
#endif


proposed/tested fix:
#ifdef __vms
#include 
#endif

or similar.

This then hits:

/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/unistd.h:475:22:
 error: macro "geteuid" passed 1 arguments, but takes just 0
/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/unistd.h:476:22:
 error: macro "getuid" passed 1 arguments, but takes just 0
make[2]: *** [pex-common.o] Error 1


But I say that's a bug in the VMS headers and I patch it:

#if __USE_LONG_GID_T
#   pragma __extern_prefix __save
#   pragma __extern_prefix "__long_gid_"
#elif __CRTL_VER>= 7000 && !defined(_VMS_V6_SOURCE)
#   if __CAN_USE_EXTERN_PREFIX
#  pragma __extern_prefix __save
#  pragma __extern_prefix "__unix_"
#   else
-#    define geteuid() __unix_geteuid()
-#    define getuid() __unix_getuid()
+#    define geteuid __unix_geteuid
+#    define getuid __unix_getuid
#   endif
#endif


__uid_t geteuid (void);
__uid_t getuid  (void);


I did the same thing in the VMS header unixlib.h.
Maybe something for fixincludes? (along with #define __NEW_STARLET, #define 
__int64 long long...)


(Alternate interpretation is that gcc should implement __CAN_USE_EXTERN_PREFIX
and the #pragmas. I'd be willing to #define __USE_LONG_GID_T but I assume the 
pragmas are a problem.)


 - Jay

gcc 4.5.0 libiberty .o vs. .obj confusion

[Jay K]

build=i386-darwin
host=alpha-dec-vms

target=alpha-dec-vms


alpha-dec-vms-ar rc ./libiberty.a \
      ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o 
./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o 
./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o 
./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o 
./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o 
./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o 
./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o 
./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o 
./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o  ./asprintf.obj 
./insque.obj ./memmem.obj ./mempcpy.obj ./mkstemps.obj ./stpcpy.obj 
./stpncpy.obj ./strndup.obj ./strverscmp.obj ./vasprintf.obj ./vfork.obj 
./strncmp.obj
alpha-dec-vms-ar: ./asprintf.obj: No such file or directory
make: *** [libiberty.a] Error 1
jbook2:libiberty jay$ edit Makefile 


alpha-dec-gcc -c foo.c outputs foo.obj.

"Something" seems to know this, since:

libiberty/Makefile.in:
LIBOBJS = @LIBOBJS@


libiberty/Makefile:
LIBOBJS =  ${LIBOBJDIR}./asprintf$U.obj ${LIBOBJDIR}./insque$U.obj 
${LIBOBJDIR}./memmem$U.obj ${LIBOBJDIR}./mempcpy$U.obj 
${LIBOBJDIR}./mkstemps$U.obj ${LIBOBJDIR}./stpcpy$U.obj 
${LIBOBJDIR}./stpncpy$U.obj ${LIBOBJDIR}./strndup$U.obj 
${LIBOBJDIR}./strverscmp$U.obj ${LIBOBJDIR}./vasprintf$U.obj 
${LIBOBJDIR}./vfork$U.obj ${LIBOBJDIR}./strncmp$U.obj


and then later there are explicit rules for building asprintf.o, etc.
I'll probably just hack the configure Makefile to say .o.


This could be an autoconf/automake bug.
Or maybe libiberty is supposed to say $O or such in place of .o?


 - Jay
  

RE: gcc 4.5.0 libiberty .o vs. .obj confusion

[Jay K]

I'm guessing that every ".o" in libiberty/Makefile.in should be changed to 
$(OBJEXT).

Thanks,
 - Jay


> From: jay.kr...@cornell.edu
> To: gcc@gcc.gnu.org
> Subject: gcc 4.5.0 libiberty .o vs. .obj confusion
> Date: Mon, 3 May 2010 11:29:15 +
>
>
> build=i386-darwin
> host=alpha-dec-vms
>
> target=alpha-dec-vms
>
>
> alpha-dec-vms-ar rc ./libiberty.a \
>   ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o 
> ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o 
> ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o 
> ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o 
> ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o 
> ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o 
> ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o 
> ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o 
> ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o 
> ./xstrndup.o  ./asprintf.obj ./insque.obj ./memmem.obj ./mempcpy.obj 
> ./mkstemps.obj ./stpcpy.obj ./stpncpy.obj ./strndup.obj ./strverscmp.obj 
> ./vasprintf.obj ./vfork.obj ./strncmp.obj
> alpha-dec-vms-ar: ./asprintf.obj: No such file or directory
> make: *** [libiberty.a] Error 1
> jbook2:libiberty jay$ edit Makefile
>
>
> alpha-dec-gcc -c foo.c outputs foo.obj.
>
> "Something" seems to know this, since:
>
> libiberty/Makefile.in:
> LIBOBJS = @LIBOBJS@
>
>
> libiberty/Makefile:
> LIBOBJS =  ${LIBOBJDIR}./asprintf$U.obj ${LIBOBJDIR}./insque$U.obj 
> ${LIBOBJDIR}./memmem$U.obj ${LIBOBJDIR}./mempcpy$U.obj 
> ${LIBOBJDIR}./mkstemps$U.obj ${LIBOBJDIR}./stpcpy$U.obj 
> ${LIBOBJDIR}./stpncpy$U.obj ${LIBOBJDIR}./strndup$U.obj 
> ${LIBOBJDIR}./strverscmp$U.obj ${LIBOBJDIR}./vasprintf$U.obj 
> ${LIBOBJDIR}./vfork$U.obj ${LIBOBJDIR}./strncmp$U.obj
>
>
> and then later there are explicit rules for building asprintf.o, etc.
> I'll probably just hack the configure Makefile to say .o.
>
>
> This could be an autoconf/automake bug.
> Or maybe libiberty is supposed to say $O or such in place of .o?
>
>
>  - Jay
>
  

internal compiler error compiling gmp/get_d/gmpn_get_d for alpha-dec-vms

[Jay K]

build=i386-darwin
host=alpha-dec-vms
target=alpha-dec-vms


/bin/sh ../libtool --mode=compile alpha-dec-vms-gcc -mbwx -std=gnu99 
-DHAVE_CONFIG_H -I. -I/src/gcc-4.5.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP 
-I/src/gcc-4.5.0/gmp -DOPERATION_`echo get_d | sed 's/_$//'`    -g -O2 -c -o 
get_d.lo get_d.c
 alpha-dec-vms-gcc -mbwx -std=gnu99 -DHAVE_CONFIG_H -I. 
-I/src/gcc-4.5.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I/src/gcc-4.5.0/gmp 
-DOPERATION_get_d -g -O2 -c get_d.c -o get_d.obj
get_d.c: In function '__gmpn_get_d':
get_d.c:490:1: internal compiler error: in 
compute_frame_pointer_to_fb_displacement, at dwarf2out.c:16269
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [get_d.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
jbook2:gmp jay$ 


I said make CFLAGS=-mieee and it seemed to fix it.
I think that merely turned off optimization though.


I did configure gcc in the first place with -disable-shared 
-enable-sjlj-exception, since there were problems compiling the libgcc/Dwarf 
stuff.
I can try "normal" there again.


 - Jay


  

RE: gcc4.5.0/libiberty/pex-common.h missing pid_t on vms

[Jay K]

> Use #ifdef HAVE_UNISTD_H instead. There are many examples in
> libiberty.
>
> Ian


Thanks Ian, that worked.


--- /src/orig/gcc-4.5.0/libiberty/pex-common.h    2009-04-13 03:45:58.0 
-0700
+++ /src/gcc-4.5.0/libiberty/pex-common.h    2010-05-04 06:43:24.0 -0700
@@ -31,6 +31,9 @@
 #if !defined(pid_t) && defined(HAVE_SYS_TYPES_H)
 #include 
 #endif
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
 
 #define install_error_msg "installation problem, cannot exec `%s'"


Perhaps someone can apply it..
Sorry, not me.


 - Jay
  

RE: gcc 4.5.0 libiberty .o vs. .obj confusion

[Jay K]

> CC: gcc@
> From: iant@
>
> Jay:
>> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to 
>> $(OBJEXT).
>
> Yes.
>
> Ian

Thanks. 

Specifically ".o" goes to "@objext@".

There's no way I'm going to be able to get "the papers" in.
I can try to squeak by via triviality of change.
I'm slightly derailed on other aspects of targeting VMS (e.g. *crt0*.c, 
vms-crtl.h), but this did work for me, attached.
It's many lines, but highly mechanical.
There are a few places where ".o" occurs in comments, can be left alone.
There is:

.c.o:
    false

> .c.obj:
>    false


and
<    -rm -rf *.o pic core errs \#* *.E a.out

>    -rm -rf *.o *.obj pic core errs \#* *.E a.out


and I wrapped the affected lines to one file per line, and spaces instead of 
tabs (consistent rendering)


 - Jay
  119a120,122
> .c.obj:
>   false
> 
160,178c163,213
< REQUIRED_OFILES = \
<   ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o\
<   ./alloca.o ./argv.o \
<   ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o  \
<   ./dyn-string.o  \
<   ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o\
<   ./fnmatch.o ./fopen_unlocked.o  \
<   ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o\
<   ./hashtab.o ./hex.o \
<   ./lbasename.o ./lrealpath.o \
<   ./make-relative-prefix.o ./make-temp-file.o \
<   ./objalloc.o ./obstack.o\
<   ./partition.o ./pexecute.o ./physmem.o  \
<   ./pex-common.o ./pex-one.o @pexecute@   \
<   ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o  \
<./strsignal.o  \
<   ./unlink-if-ordinary.o  \
<   ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o   \
<./xstrerror.o ./xstrndup.o
---
> REQUIRED_OFILES =   \
> ./reg...@objext@\
> ./cplus-d...@objext@\
> ./cp-demang...@objext@  \
> ./m...@objext@  \
> ./sh...@objext@ \
> ./allo...@objext@   \
> ./ar...@objext@ \
> ./choose-te...@objext@  \
> ./conc...@objext@   \
> ./cp-demi...@objext@\
> ./crc...@objext@\
> ./dyn-stri...@objext@   \
> ./fdmat...@objext@  \
> ./fibhe...@objext@  \
> ./filename_c...@objext@ \
> ./floatform...@objext@  \
> ./fnmat...@objext@  \
> ./fopen_unlock...@objext@ \
> ./geto...@objext@   \
> ./getop...@objext@  \
> ./getp...@objext@   \
> ./getrunti...@objext@   \
> ./hasht...@objext@  \
> ./h...@objext@  \
> ./lbasena...@objext@\
> ./lrealpa...@objext@\
> ./make-relative-pref...@objext@ \
> ./make-temp-fi...@objext@ \
> ./objall...@objext@ \
> ./obsta...@objext@  \
> ./partiti...@objext@\
> ./pexecu...@objext@ \
> ./physm...@objext@  \
> ./pex-comm...@objext@   \
> ./pex-o...@objext@  \
> @pexecute@  \
> ./safe-cty...@objext@   \
> ./so...@objext@ \
> ./spac...@objext@   \
> ./splay-tr...@objext@   \
> ./strerr...@objext@ \
> ./strsign...@objext@\
> ./unlink-if-ordina...@objext@   \
> ./xatex...@objext@  \
> ./xex...@objext@\
> ./xmall...@objext@  \
> ./xmemd...@objext@  \
> ./xstrd...@objext@  \
> ./xstrerr...@objext@\
> ./xstrnd...@objext@
183,203c218,276
< CONFIGURED_OFILES = ./asprintf.o ./atexit.o   \
<   ./basename.o ./bcmp.o ./bcopy.o ./bsearch.o ./bzero.o   \
<   ./calloc.o ./clock.o ./copysign.o   \
<   ./_doprnt.o \
<   ./ffs.o \
<   ./getcwd.o ./getpagesize.o ./gettimeofday.o \
<   ./index.o ./insque.o\
<   ./memchr.o ./memcmp.o ./memcpy.o ./memmem.o ./memmove.o \
<./mempcpy.o ./memset.o ./mkstemps.o\
<   ./pex-djgpp.o ./pex-msdos.o \
<./pex-unix.o ./pex-win32.o \
<./putenv.o \
<   ./random.o ./rename.o ./rindex.o\
<   ./setenv.o ./sigsetmask.o ./snprintf.o ./stpcpy.o ./stpncpy.o   \
<./strcasecm

RE: gcc 4.5.0 libiberty .o vs. .obj confusion

[Jay K]

oops, also need like:

--- /src/orig/gcc-4.5.0/libiberty/configure    2010-01-04 15:46:56.0 
-0800
+++ /src/gcc-4.5.0/libiberty/configure    2010-05-05 05:40:52.0 -0700
@@ -6533,10 +6533,10 @@
 
 # Figure out which version of pexecute to use.
 case "${host}" in
- *-*-mingw* | *-*-winnt*)    pexecute=./pex-win32.o  ;;
- *-*-msdosdjgpp*)        pexecute=./pex-djgpp.o  ;;
- *-*-msdos*)        pexecute=./pex-msdos.o  ;;
- *)                pexecute=./pex-unix.o   ;;
+ *-*-mingw* | *-*-winnt*)    pexecute=./pex-win32.$ac_objext  ;;
+ *-*-msdosdjgpp*)        pexecute=./pex-djgpp.$ac_objext  ;;
+ *-*-msdos*)        pexecute=./pex-msdos.$ac_objext  ;;
+ *)                pexecute=./pex-unix.$ac_objext   ;;
 esac
 

--- /src/orig/gcc-4.5.0/libiberty/configure.ac    2010-01-04 15:46:56.0 
-0800
+++ /src/gcc-4.5.0/libiberty/configure.ac    2010-05-05 05:45:47.0 -0700
@@ -671,10 +671,10 @@
 
 # Figure out which version of pexecute to use.
 case "${host}" in
- *-*-mingw* | *-*-winnt*)    pexecute=./pex-win32.o  ;;
- *-*-msdosdjgpp*)        pexecute=./pex-djgpp.o  ;;
- *-*-msdos*)        pexecute=./pex-msdos.o  ;;
- *)                pexecute=./pex-unix.o   ;;
+ *-*-mingw* | *-*-winnt*)    pexecute=./pex-win32.$ac_objext  ;;
+ *-*-msdosdjgpp*)        pexecute=./pex-djgpp.$ac_objext  ;;
+ *-*-msdos*)        pexecute=./pex-msdos.$ac_objext  ;;
+ *)                pexecute=./pex-unix.$ac_objext   ;;
 esac
 AC_SUBST(pexecute)
 

I manually edited configure.
I don't know how to keep multiple versions of autoconf installed/working, other 
than to use Cygwin and its special packages dedicated to this problem.

configure.ac:3: error: Autoconf version 2.64 or higher is required
configure.ac:3: the top level
autom4te: /usr/bin/gm4 failed with exit status: 63
jbook2:libiberty jay$ 

 - Jay



> From: jay.krell@
> To: i...@m
> CC: g...@g
> Subject: RE: gcc 4.5.0 libiberty .o vs. .obj confusion
> Date: Wed, 5 May 2010 10:10:15 +
>
>
>> CC: gcc@
>> From: iant@
>>
>> Jay:
>>> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to 
>>> $(OBJEXT).
>>
>> Yes.
>>
>> Ian
>
> Thanks.
>
> Specifically ".o" goes to "@objext@".
>
> There's no way I'm going to be able to get "the papers" in.
> I can try to squeak by via triviality of change.
> I'm slightly derailed on other aspects of targeting VMS (e.g. *crt0*.c, 
> vms-crtl.h), but this did work for me, attached.
> It's many lines, but highly mechanical.
> There are a few places where ".o" occurs in comments, can be left alone.
> There is:
>
> .c.o:
> false
>
>> .c.obj:
>>false
>
>
> and
> <-rm -rf *.o pic core errs \#* *.E a.out
>
>>-rm -rf *.o *.obj pic core errs \#* *.E a.out
>
>
> and I wrapped the affected lines to one file per line, and spaces instead of 
> tabs (consistent rendering)
>
>
>  - Jay
>
  

more .o vs. .obj targeting VMS

[Jay K]

Here's the next one:

alpha-dec-vms-ar cru libdecnumber.a decNumber.o decContext.o decimal32.o 
decimal64.o decimal128.o 
alpha-dec-vms-ar: decNumber.o: No such file or directory
make[2]: *** [libdecnumber.a] Error 1
make[1]: *** [all-libdecnumber] Error 2
make: *** [all] Error 2

jbook2:vms jay$ ls libdecnumber/
Makefile    config.log    decNumber.obj    decimal64.obj
config.cache    config.status    decimal128.obj    gstdint.h
config.h    decContext.obj    decimal32.obj    stamp-h1

 - Jay

  

gcc/resource.h conflicts with sysroot/usr/include/resource.h (alpha-dec-vms)

[Jay K]

lpha-dec-vms-gcc -c   -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attri
bute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -
I. -I/src/gcc-4.5.0/gcc -I/src/gcc-4.5.0/gcc/. -I/src/gcc-4.5.0/gcc/../include 
-I/src/gcc-4.5.0/gcc/../libcpp/include -I/obj/gcc/vms/.
/gmp -I/src/gcc-4.5.0/gmp -I/obj/gcc/vms/./mpfr -I/src/gcc-4.5.0/mpfr 
-I/src/gcc-4.5.0/mpc/src  -I/src/gcc-4.5.0/gcc/../libdecnumber -
I/src/gcc-4.5.0/gcc/../libdecnumber/dpd -I../libdecnumber 
/src/gcc-4.5.0/gcc/c-lang.c -o c-lang.o
In file included from /src/gcc-4.5.0/gcc/resource.h:24:0,
 from 
/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/wait.h:74,
 from 
/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/stdlib.h:51,
 from /src/gcc-4.5.0/gcc/system.h:211,
 from /src/gcc-4.5.0/gcc/c-lang.c:24:

/src/gcc-4.5.0/gcc/hard-reg-set.h:42:39: error: expected '=', ',', ';', 'asm' 
or '__attribute__' before 'HARD_REG_ELT_TYPE'


The problem is that there is both gcc/resource.h and 
sysroot/usr/include/resource.h.

When sysroot/usr/include/wait.h does:

#if defined _XOPEN_SOURCE_EXTENDED || !defined _POSIX_C_SOURCE
#   include         /* for siginfo_t */
#   include     /* for struct rusage */
#endif

it gets the wrong resource.h

for now I patched sysroot/usr/include/wait.h to #include "resource.h" instead.

Unfortunate fix is maybe to rename to gcc/gccresource.h?

 - Jay
 
  

builtin ffs vs. renamed ffs (vms-crtl.h)

[Jay K]

In gcc for VMS there is some mechanism to rename functions.
See the files:

/src/gcc-4.5.0/gcc/config/vms/vms-crtl-64.h
/src/gcc-4.5.0/gcc/config/vms/vms-crtl.h


which are mostly just lists of function from/to.


As well in gcc there is a mechanism for optimizing various "builtin" functions, 
like ffs.


These two mechanisms seem to conflict or be applied in the wrong order.
I didn't look at it deeply.


The symptom is that if you add ffs (to decc$ffs) to vms-crtl.h, the translation
is not done, and you end up with unresolved external ffs.


If you #if out the support for "builtin ffs", it works.


My local hack is below but obviously that's not the way.


I'll enter a bug.


Thanks,
 - Jay


diff -u /src/orig/gcc-4.5.0/gcc/builtins.c ./builtins.c
--- /src/orig/gcc-4.5.0/gcc/builtins.c    2010-04-13 06:47:11.0 -0700
+++ ./builtins.c    2010-05-07 23:11:30.0 -0700
@@ -51,6 +51,8 @@
 #include "value-prof.h"
 #include "diagnostic.h"
 
+#define DISABLE_FFS
+
 #ifndef SLOW_UNALIGNED_ACCESS
 #define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) STRICT_ALIGNMENT
 #endif
@@ -5899,6 +5901,7 @@
 return target;
   break;
 
+#ifndef DISABLE_FFS
 CASE_INT_FN (BUILT_IN_FFS):
 case BUILT_IN_FFSIMAX:
   target = expand_builtin_unop (target_mode, exp, target,
@@ -5906,6 +5909,7 @@
   if (target)
 return target;
   break;
+#endif
 
 CASE_INT_FN (BUILT_IN_CLZ):
 case BUILT_IN_CLZIMAX:
@@ -13612,6 +13616,7 @@
 case BUILT_IN_ABORT:
   abort_libfunc = set_user_assembler_libfunc ("abort", asmspec);
   break;
+#ifndef DISABLE_FFS
 case BUILT_IN_FFS:
   if (INT_TYPE_SIZE < BITS_PER_WORD)
 {
@@ -13620,6 +13625,7 @@
                        MODE_INT, 0), "ffs");
 }
   break;
+#endif
 default:
   break;
 }
diff -u /src/orig/gcc-4.5.0/gcc/optabs.c ./optabs.c
--- /src/orig/gcc-4.5.0/gcc/optabs.c    2010-03-19 12:45:01.0 -0700
+++ ./optabs.c    2010-05-07 23:11:36.0 -0700
@@ -45,6 +45,8 @@
 #include "basic-block.h"
 #include "target.h"
 
+#define DISABLE_FFS
+
 /* Each optab contains info on how this target machine
    can perform a particular operation
    for all sizes and kinds of operands.
@@ -3240,6 +3242,7 @@
 return temp;
 }
 
+#ifndef DISABLE_FFS
   /* Try implementing ffs (x) in terms of clz (x).  */
   if (unoptab == ffs_optab)
 {
@@ -3247,6 +3250,7 @@
   if (temp)
 return temp;
 }
+#endif
 
   /* Try implementing ctz (x) in terms of clz (x).  */
   if (unoptab == ctz_optab)
@@ -3268,7 +3272,11 @@
 
   /* All of these functions return small values.  Thus we choose to
  have them return something that isn't a double-word.  */
-  if (unoptab == ffs_optab || unoptab == clz_optab || unoptab == ctz_optab
+  if (
+#ifndef DISABLE_FFS
+  unoptab == ffs_optab ||
+#endif
+    unoptab == clz_optab || unoptab == ctz_optab
   || unoptab == popcount_optab || unoptab == parity_optab)
 outmode
   = GET_MODE (hard_libcall_value (TYPE_MODE (integer_type_node),
@@ -6301,7 +6309,9 @@
   init_optab (addcc_optab, UNKNOWN);
   init_optab (one_cmpl_optab, NOT);
   init_optab (bswap_optab, BSWAP);
+#ifndef DISABLE_FFS
   init_optab (ffs_optab, FFS);
+#endif
   init_optab (clz_optab, CLZ);
   init_optab (ctz_optab, CTZ);
   init_optab (popcount_optab, POPCOUNT);
@@ -6558,9 +6568,11 @@
   one_cmpl_optab->libcall_basename = "one_cmpl";
   one_cmpl_optab->libcall_suffix = '2';
   one_cmpl_optab->libcall_gen = gen_int_libfunc;
+#ifndef DISABLE_FFS
   ffs_optab->libcall_basename = "ffs";
   ffs_optab->libcall_suffix = '2';
   ffs_optab->libcall_gen = gen_int_libfunc;
+#endif
   clz_optab->libcall_basename = "clz";
   clz_optab->libcall_suffix = '2';
   clz_optab->libcall_gen = gen_int_libfunc;
@@ -6643,11 +6655,13 @@
   satfractuns_optab->libcall_basename = "satfractuns";
   satfractuns_optab->libcall_gen = gen_satfractuns_conv_libfunc;
 
+#ifndef DISABLE_FFS
   /* The ffs function operates on `int'.  Fall back on it if we do not
  have a libgcc2 function for that width.  */
   if (INT_TYPE_SIZE < BITS_PER_WORD)
 set_optab_libfunc (ffs_optab, mode_for_size (INT_TYPE_SIZE, MODE_INT, 0),
        "ffs");
+#endif
 
   /* Explicitly initialize the bswap libfuncs since we need them to be
  valid for things other than word_mode.  */


Thanks,
 - Jay
  

vmsdbgout.c int-to-enum cast and #define globalref

[Jay K]

vmsdbgout.c has an int-to-enum warning and needs some form of "globalref" when 
host=alpha-dec-vms since that #includes the VMS system headers.
Perhaps gcc should recognize globalref when target=*vms* and at least interpret 
it as extern.

Thanks,
 - Jay

diff -u /src/orig/gcc-4.5.0/gcc/vmsdbgout.c ./vmsdbgout.c
--- /src/orig/gcc-4.5.0/gcc/vmsdbgout.c    2009-11-25 02:55:54.0 -0800
+++ ./vmsdbgout.c    2010-05-06 01:40:20.0 -0700
@@ -21,6 +21,8 @@
 along with GCC; see the file COPYING3.  If not see
 .  */
 
+#define globalref extern
+
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -743,7 +745,7 @@
   modbeg.dst_b_modbeg_flags.dst_v_modbeg_version = 1;
   modbeg.dst_b_modbeg_flags.dst_v_modbeg_unused = 0;
   modbeg.dst_b_modbeg_unused = 0;
-  modbeg.dst_l_modbeg_language = module_language;
+  modbeg.dst_l_modbeg_language = (DST_LANGUAGE)module_language;
   modbeg.dst_w_version_major = DST_K_VERSION_MAJOR;
   modbeg.dst_w_version_minor = DST_K_VERSION_MINOR;
   modbeg.dst_b_modbeg_name = strlen (module_name);
@@ -822,7 +824,7 @@
  + string count byte + string length */
   header.dst__header_length.dst_w_length
 = DST_K_DST_HEADER_SIZE - 1 + 1 + 4 + 1 + strlen (go);
-  header.dst__header_type.dst_w_type = 0x17;
+  header.dst__header_type.dst_w_type = (DST_DTYPE)0x17;
 
   totsize += write_debug_header (&header, "transfer", dosizeonly);
 


  

pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

[Jay K]

I haven't tried 4.5.0 yet.
 
 
-bash-4.1$ /opt/csw/gcc4/bin/g++ -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/op
t/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/
csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --e
nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-st
age1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
Thread model: posix
gcc version 4.3.3 (GCC)
 

/opt/csw/gcc4/bin/g++ 1.cpp -fPIC -S -m64
"1.s", line 117 : Warning: Illegal subtraction - symbols from different 
sections: ".LFB2", ".DOT-2"
"1.s", line 120 : Warning: Illegal subtraction - symbols from different 
sections: ".LLSDA2", ".DOT-3"
void F1();
void F2()
{
  try { F1(); } catch(...) {F2(); }
}

 
 /usr/ccs/bin/as -xarch=amd64 1.s
 


or similar:
-bash-4.1$ cat 2.c
void F1() { }
 

   /opt/csw/gcc4/bin/gcc -fPIC -S -funwind-tables -m64 2.c
   /usr/ccs/bin/as -xarch=amd64 2.s
Assembler: 2.c
"2.s", line 38 : Warning: Illegal subtraction - symbols from different 
sections: ".LFB2", ".DOT-1"
 

I'm aware of this thread:
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00908.html
 
 

I think I'll switch to GNU as, or omit -funwind-tables for now.
  Or see if 4.5.0 fixes it.
Sparc32, sparc64, x86 work.
 
 
-gstabs+ also generated .stabd that Sun assembler didn't like.
I switched to -gstabs.
Maybe I messed up something though, as it looks like gcc is aware not to output 
.stabd to non-gas.
  More reason to use GNU assembler, understood.

 
http://gcc.gnu.org/install/specific.html#ix86-x-solaris210
 could be a bit more precise:
  >> Recent versions of the Sun assembler in /usr/ccs/bin/as work almost as 
well, though. 

 
"almost as well"?
Maybe that should say more, like, use -g or -gstabs instead of -gstabs+, don't 
use 64bit+pic+unwind-tables or 64bit+pic+exceptions
 
 
I switched to Sun assembler because I'm seeing GNU as installed in different 
places on different machines.
  Some people don't install /usr/sfw and the install elsewhere.
 
 
 - Jay

RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

[Jay K]

Ah, good point. I don't think my "real" scenario did that though.
I'll investigate more. Networking problems were?are hampering download 4.5.0 and
 build and configure it.
 
I did come up with Makefile:
 
Assemble = $(shell if test -x /opt/csw/gnu/as ; then echo /opt/csw/gnu/as ; \
 elif test -x /usr/sfw/bin/gas ; then echo /usr/sfw/bin/gas ; \
 else echo "unable to find GNU assembler" ; fi )
 
:) which addresses why I wasn't using GNU as.
 
(Yes, I've heard of autoconf.)
 
Thanks, later,
 - Jay



> From: pins...@gmail.com
> To: jay.kr...@cornell.edu
> Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section 
> subtraction
> Date: Sun, 9 May 2010 17:48:04 -0700
> CC: gcc@gcc.gnu.org
>
>
>
> Sent from my iPhone
>
> On May 9, 2010, at 5:42 PM, Jay K wrote:
>
>>
>> I haven't tried 4.5.0 yet.
>>
>>
>> -bash-4.1$ /opt/csw/gcc4/bin/g++ -v
>> Using built-in specs.
>> Target: i386-pc-solaris2.10
>> Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --
>> exec-prefix=/op
>> t/csw/gcc4
>
>
>
>> --with-gnu-as
>
>
> You configured gcc to build with the gnu as but then run with it so
> what do you expect.
>
>
>> --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
>> usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-
>> prefix=/opt/
>> csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-
>> awt=xlib --e
>> nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix
>> --enable-st
>> age1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
>> Thread model: posix
>> gcc version 4.3.3 (GCC)
>>
>>
>> /opt/csw/gcc4/bin/g++ 1.cpp -fPIC -S -m64
>> "1.s", line 117 : Warning: Illegal subtraction - symbols from
>> different sections: ".LFB2", ".DOT-2"
>> "1.s", line 120 : Warning: Illegal subtraction - symbols from
>> different sections: ".LLSDA2", ".DOT-3"
>> void F1();
>> void F2()
>> {
>> try { F1(); } catch(...) {F2(); }
>> }
>>
>>
>> /usr/ccs/bin/as -xarch=amd64 1.s
>>
>>
>>
>> or similar:
>> -bash-4.1$ cat 2.c
>> void F1() { }
>>
>>
>> /opt/csw/gcc4/bin/gcc -fPIC -S -funwind-tables -m64 2.c
>> /usr/ccs/bin/as -xarch=amd64 2.s
>> Assembler: 2.c
>> "2.s", line 38 : Warning: Illegal subtraction - symbols from
>> different sections: ".LFB2", ".DOT-1"
>>
>>
>> I'm aware of this thread:
>> http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00908.html
>>
>>
>>
>> I think I'll switch to GNU as, or omit -funwind-tables for now.
>> Or see if 4.5.0 fixes it.
>> Sparc32, sparc64, x86 work.
>>
>>
>> -gstabs+ also generated .stabd that Sun assembler didn't like.
>> I switched to -gstabs.
>> Maybe I messed up something though, as it looks like gcc is aware
>> not to output .stabd to non-gas.
>> More reason to use GNU assembler, understood.
>>
>>
>> http://gcc.gnu.org/install/specific.html#ix86-x-solaris210
>> could be a bit more precise:
>>>> Recent versions of the Sun assembler in /usr/ccs/bin/as work
>>>> almost as well, though.
>>
>>
>> "almost as well"?
>> Maybe that should say more, like, use -g or -gstabs instead of -
>> gstabs+, don't use 64bit+pic+unwind-tables or 64bit+pic+exceptions
>>
>>
>> I switched to Sun assembler because I'm seeing GNU as installed in
>> different places on different machines.
>> Some people don't install /usr/sfw and the install elsewhere.
>>
>>
>> - Jay  

RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

[Jay K]

Fix in 4.4.0.
 
I was getting:
 
.LASFDE1:
.long   .LASFDE1-.Lframe1
.long   .LFB2-.  <<<
.long   .LFE2-.LFB2
 
4.5.0 configured right:
 
.LASFDE1:
.long   .LASFDE1-.Lframe1
.long   .l...@rel <<< 
.long   .LFE0-.LFB0
 
dw2_asm_output_encoded_addr_rtx =>
 
#ifdef ASM_OUTPUT_DWARF_PCREL
   ASM_OUTPUT_DWARF_PCREL (asm_out_file, size, XSTR (addr, 0));
#else
   dw2_assemble_integer (size, gen_rtx_MINUS (Pmode, addr, pc_rtx));
#endif

  
 C:\src\gcc-4.4.0\gcc\config\i386\sol2-10.h(45):#define 
ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
 C:\src\gcc-4.5.0\gcc\config\i386\sol2-10.h(46):#define 
ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \

 
#define ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
  do {   \
fputs (integer_asm_op (SIZE, FALSE), FILE);  \
assemble_name (FILE, LABEL);   \
fputs (SIZE == 8 ? "@rel64" : "@rel", FILE); \
  } while (0)
#endif

2009-01-29  Rainer Orth  
 * config/i386/sol2-10.h [!HAVE_AS_IX86_DIFF_SECT_DELTA]
 (ASM_OUTPUT_DWARF_PCREL): Define.

http://gcc.gnu.org/viewcvs?view=revision&revision=143758
 
 
Thanks,
 - Jay



> From: jay.kr...@cornell.edu
> To: pins...@gmail.com
> CC: gcc@gcc.gnu.org
> Subject: RE: pic+64bit+sun assembler+unwind-tables => illegal cross section 
> subtraction
> Date: Mon, 10 May 2010 01:02:29 +
>
>
> Ah, good point. I don't think my "real" scenario did that though.
> I'll investigate more. Networking problems were?are hampering download 4.5.0 
> and
> build and configure it.
>
> I did come up with Makefile:
>
> Assemble = $(shell if test -x /opt/csw/gnu/as ; then echo /opt/csw/gnu/as ; \
> elif test -x /usr/sfw/bin/gas ; then echo /usr/sfw/bin/gas ; \
> else echo "unable to find GNU assembler" ; fi )
>
> :) which addresses why I wasn't using GNU as.
>
> (Yes, I've heard of autoconf.)
>
> Thanks, later,
> - Jay
>
>
> 
>> From: pins...@gmail.com
>> To: jay.kr...@cornell.edu
>> Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section 
>> subtraction
>> Date: Sun, 9 May 2010 17:48:04 -0700
>> CC: gcc@gcc.gnu.org
>>
>>
>>
>> Sent from my iPhone
>>
>> On May 9, 2010, at 5:42 PM, Jay K wrote:
>>
>>>
>>> I haven't tried 4.5.0 yet.
>>>
>>>
>>> -bash-4.1$ /opt/csw/gcc4/bin/g++ -v
>>> Using built-in specs.
>>> Target: i386-pc-solaris2.10
>>> Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --
>>> exec-prefix=/op
>>> t/csw/gcc4
>>
>>
>>
>>> --with-gnu-as
>>
>>
>> You configured gcc to build with the gnu as but then run with it so
>> what do you expect.
>>
>>
>>> --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
>>> usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-
>>> prefix=/opt/
>>> csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-
>>> awt=xlib --e
>>> nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix
>>> --enable-st
>>> age1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
>>> Thread model: posix
>>> gcc version 4.3.3 (GCC)
>>>
>>>
>>> /opt/csw/gcc4/bin/g++ 1.cpp -fPIC -S -m64
>>> "1.s", line 117 : Warning: Illegal subtraction - symbols from
>>> different sections: ".LFB2", ".DOT-2"
>>> "1.s", line 120 : Warning: Illegal subtraction - symbols from
>>> different sections: ".LLSDA2", ".DOT-3"
>>> void F1();
>>> void F2()
>>> {
>>> try { F1(); } catch(...) {F2(); }
>>> }
>>>
>>>
>>> /usr/ccs/bin/as -xarch=amd64 1.s
>>>
>>>
>>>
>>> or similar:
>>> -bash-4.1$ cat 2.c
>>> void F1() { }
>>>
>>>
>>> /opt/csw/gcc4/bin/gcc -fPIC -S -funwind-tables -m64 2.c
>>> /usr/ccs/bin/as -xarch=amd64 2.s
>>> Assembler: 2.c
>>> "2.s", line 38 : Warning: Illegal subtraction - symbols from
>>> different sections: ".LFB2", ".DOT-1"
>>>
>>>
>>> I'm aware of this thread:
>>> http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00908.html
>>>
>>>
>>>
>>> I think I'll switch to GNU as, or omit -funwind-tables for now.
>>> Or see if 4.5.0 fixes it.
>>> Sparc32, sparc64, x86 work.
>>>
>>>
>>> -gstabs+ also generated .stabd that Sun assembler didn't like.
>>> I switched to -gstabs.
>>> Maybe I messed up something though, as it looks like gcc is aware
>>> not to output .stabd to non-gas.
>>> More reason to use GNU assembler, understood.
>>>
>>>
>>> http://gcc.gnu.org/install/specific.html#ix86-x-solaris210
>>> could be a bit more precise:
>>>>> Recent versions of the Sun assembler in /usr/ccs/bin/as work
>>>>> almost as well, though.
>>>
>>>
>>> "almost as well"?
>>> Maybe that should say more, like, use -g or -gstabs instead of -
>>> gstabs+, don't use 64bit+pic+unwind-tables or 64bit+pic+exceptions
>>>
>>>
>>> I switched to Sun assembler because I'm seeing GNU as installed in
>>> different places on different machines.
>>> Some people don't install /usr/sfw and the install elsewhere.
>>>
>>>
>>> - Jay 

-disable-fixincludes doesn't quite work, minor

[Jay K]

-disable-libgcc and/or -disable-fixincludes are useful, depending on your goal.

 Like if you just want to compile C to assembly or object files.


It fails, but only after doing what I want anyway.

make[2]: *** No rule to make target 
`../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh', needed by 
`stmp-fixinc'.  Stop.
gmake[2]: Leaving directory `/home/jkrell/obj/gcc.sparc/gcc'
gmake[1]: *** [all-gcc] Error 2

Definitely not a big deal.


$HOME/src/gcc-4.5.0/configure -without-gnu-ld -with-ld=/usr/ccs/bin/ld 
-without-gnu-as -with-as=/usr/ccs/bin/as -disable-nls -disable-fixincludes 
-verbose -disable-libgcc -disable-bootstrap
gmake


(I'd still like -disable-intl; I always just delete that directory. 
-disable-intl /might/ work, I should try it again.
I'd also like  -without-libiconv, which I'm sure doesn't work. This way the 
resulting gcc doesn't require
libiconv, which isn't on all systems. I have automation to patch out the 
libiconv use.)

 - Jay
  

RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

[Jay K]

It might also be necessary to configure for i586-sun-solaris2.10 instead of 
i586-solaris2.10.
Something I read said you can use various shorter forms, and I like the idea 
for convenience and to avoid those "pc"s and "unknown"s,
but this seems to have bitten me a number of times, not just today.

Anyway, it is working for me, configure -without-gnu-as i586-sun-solaris2.10, 
having applied Rainer's change to a 4.3 tree.
 (Yes, I'd like to upgrade.)

It seems using GNU as might still be slightly preferred in order to move data 
(jump tables) out of .text and into read only data, like, you know, "the less 
that is executable, the more secure". Though for locality, .text might be 
better.

For now I'm erring toward using what is more often present in the same location.

I should have just waited till I tested with 4.5, that would have shut me up. :)

Thanks,
 - Jay


> From: jay.kr...@cornell.edu
> To: pins...@gmail.com
> CC: gcc@gcc.gnu.org
> Subject: RE: pic+64bit+sun assembler+unwind-tables => illegal cross section 
> subtraction
> Date: Mon, 10 May 2010 03:17:40 +
>
>
> Fix in 4.4.0.
>
> I was getting:
>
> .LASFDE1:
> .long .LASFDE1-.Lframe1
> .long .LFB2-. <<<
> .long .LFE2-.LFB2
>
> 4.5.0 configured right:
>
> .LASFDE1:
> .long .LASFDE1-.Lframe1
> .long .l...@rel <<<
> .long .LFE0-.LFB0
>
> dw2_asm_output_encoded_addr_rtx =>
>
> #ifdef ASM_OUTPUT_DWARF_PCREL
> ASM_OUTPUT_DWARF_PCREL (asm_out_file, size, XSTR (addr, 0));
> #else
> dw2_assemble_integer (size, gen_rtx_MINUS (Pmode, addr, pc_rtx));
> #endif
>
> 
> C:\src\gcc-4.4.0\gcc\config\i386\sol2-10.h(45):#define 
> ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
> C:\src\gcc-4.5.0\gcc\config\i386\sol2-10.h(46):#define 
> ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
>
>
> #define ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
> do { \
> fputs (integer_asm_op (SIZE, FALSE), FILE); \
> assemble_name (FILE, LABEL); \
> fputs (SIZE == 8 ? "@rel64" : "@rel", FILE); \
> } while (0)
> #endif
>
> 2009-01-29 Rainer Orth 
> * config/i386/sol2-10.h [!HAVE_AS_IX86_DIFF_SECT_DELTA]
> (ASM_OUTPUT_DWARF_PCREL): Define.
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=143758
>
>
> Thanks,
> - Jay
>
>
> 
>> From: jay.kr...@cornell.edu
>> To: pins...@gmail.com
>> CC: gcc@gcc.gnu.org
>> Subject: RE: pic+64bit+sun assembler+unwind-tables => illegal cross section 
>> subtraction
>> Date: Mon, 10 May 2010 01:02:29 +
>>
>>
>> Ah, good point. I don't think my "real" scenario did that though.
>> I'll investigate more. Networking problems were?are hampering download 4.5.0 
>> and
>> build and configure it.
>>
>> I did come up with Makefile:
>>
>> Assemble = $(shell if test -x /opt/csw/gnu/as ; then echo /opt/csw/gnu/as ; \
>> elif test -x /usr/sfw/bin/gas ; then echo /usr/sfw/bin/gas ; \
>> else echo "unable to find GNU assembler" ; fi )
>>
>> :) which addresses why I wasn't using GNU as.
>>
>> (Yes, I've heard of autoconf.)
>>
>> Thanks, later,
>> - Jay
>>
>>
>> 
>>> From: pins...@gmail.com
>>> To: jay.kr...@cornell.edu
>>> Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section 
>>> subtraction
>>> Date: Sun, 9 May 2010 17:48:04 -0700
>>> CC: gcc@gcc.gnu.org
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On May 9, 2010, at 5:42 PM, Jay K wrote:
>>>
>>>>
>>>> I haven't tried 4.5.0 yet.
>>>>
>>>>
>>>> -bash-4.1$ /opt/csw/gcc4/bin/g++ -v
>>>> Using built-in specs.
>>>> Target: i386-pc-solaris2.10
>>>> Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --
>>>> exec-prefix=/op
>>>> t/csw/gcc4
>>>
>>>
>>>
>>>> --with-gnu-as
>>>
>>>
>>> You configured gcc to build with the gnu as but then run with it so
>>> what do you expect.
>>>
>>>
>>>> --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
>>>> usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-
>>>> prefix=/opt/
>>>> csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-
>>>> awt=xlib --e
>>>> nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix
>&

RE: -disable-fixincludes doesn't quite work, minor

[Jay K]

Ok if I do both or the emails are just annoying?
I find that bugs are often ignored just as well (but not lost/forgotten, 
granted. :) )
 
Thanks,
 - Jay



> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
> Subject: Re: -disable-fixincludes doesn't quite work, minor
> From: i...@google.com
> Date: Mon, 10 May 2010 09:50:01 -0700
>
> Jay K writes:
>
>> -disable-libgcc and/or -disable-fixincludes are useful, depending on your 
>> goal.
>>
>> Like if you just want to compile C to assembly or object files.
>>
>>
>> It fails, but only after doing what I want anyway.
>>
>> make[2]: *** No rule to make target 
>> `../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh', needed by 
>> `stmp-fixinc'. Stop.
>> gmake[2]: Leaving directory `/home/jkrell/obj/gcc.sparc/gcc'
>> gmake[1]: *** [all-gcc] Error 2
>
>
> Thanks for pointing these things out. However, I hope you are filing
> bug reports about these issues you are raising. Problems which are
> only reported to the mailing list will be reliably lost and forgotten.
> If you want them to be fixed, please open bug reports. Thanks.
>
> Ian 

rep prefix doesn't work with Solaris 2.9 Sun assembler

[Jay K]

Solaris 2.9 x86 gcc 4.5.0 configure -without-gnu-as -with-as=/usr/ccs/bin/as

 
 => Assembly syntax errors in gcov.c whereever there is rep prefix.
 

I was actually looking for a problem with lock prefixes on 4.3 -- testing 
4.5.0, found this instead, which is about about the same.
 
 
See:
 http://gcc.gnu.org/viewcvs?view=revision&revision=127728
  for handling of the lock prefix in a separate instruction.
 
 
See: 
http://developers.sun.com/sunstudio/downloads/ssx/express_Feb2008_readme.html
 "You can now place lock/rep/repnz/repz/repe/repne prefix on the same line as 
the following instruction."
 
 
But I'd like to stay compatible with the existing Sun assembler 
at /usr/ccs/bin/as.
 
 
I considered just changing them all to \;, like there is rep\;ret, but
I noticed this:
sync.md:  "lock{%;| }or{l}\t{$0, (%%esp)|DWORD PTR [esp], 0}"
 

which appears to be an attempt to output Microsoft/Intel assembly, so I went
with the space usually and ; only for Darwin/Solaris, like how sync.md
was already using ; for Darwin.
 

Proposed patch below/attached.
  (-w to hide indent change)
 

I'll open a bug. And test it on some machines maybe.
Any marked with TARGET_64BIT I left alone. Maybe that is too inconsistent 
though.
 
 

diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c ./i386.c
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c Wed Apr  7 23:58:27 
2010
+++ ./i386.c Tue May 11 10:01:54 2010
@@ -11896,11 +11896,10 @@
return;
 
  case ';':
-#if TARGET_MACHO
+   if (TARGET_MACHO || TARGET_SOLARIS)
fputs (" ; ", file);
-#else
+   else
putc (' ', file);
-#endif
return;
 
  default:
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.h ./i386.h
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.h Wed Mar 24 21:44:48 
2010
+++ ./i386.h Tue May 11 09:59:01 2010
@@ -467,6 +467,9 @@
redefines this to 1.  */
 #define TARGET_MACHO 0
 
+/* Like TARGET_MACHO, redefined in sol2.h. */
+#define TARGET_SOLARIS 0
+
 /* Likewise, for the Windows 64-bit ABI.  */
 #define TARGET_64BIT_MS_ABI (TARGET_64BIT && ix86_cfun_abi () == MS_ABI)
 
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.md ./i386.md
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.md Wed Mar 24 19:49:49 
2010
+++ ./i386.md Tue May 11 09:49:05 2010
@@ -13811,7 +13811,7 @@
   [(return)
(unspec [(const_int 0)] UNSPEC_REP)]
   "reload_completed"
-  "rep\;ret"
+  "rep{%;| }ret"
   [(set_attr "length" "2")
(set_attr "atom_unit" "jeu")
(set_attr "length_immediate" "0")
@@ -17772,7 +17772,7 @@
  (mem:BLK (match_dup 4)))
(use (match_dup 5))]
   "!TARGET_64BIT"
-  "rep movs{l|d}"
+  "rep{%;| }movs{l|d}"
   [(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "both")
@@ -17808,7 +17808,7 @@
  (mem:BLK (match_dup 4)))
(use (match_dup 5))]
   "!TARGET_64BIT"
-  "rep movsb"
+  "rep{%;| }movsb"
   [(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "both")
@@ -18023,7 +18023,7 @@
(use (match_operand:SI 2 "register_operand" "a"))
(use (match_dup 4))]
   "!TARGET_64BIT"
-  "rep stos{l|d}"
+  "rep{%;| }stos{l|d}"
   [(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "store")
@@ -18056,7 +18056,7 @@
(use (match_operand:QI 2 "register_operand" "a"))
(use (match_dup 4))]
   "!TARGET_64BIT"
-  "rep stosb"
+  "rep{%;| }stosb"
   [(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "store")
@@ -18188,7 +18188,7 @@
(clobber (match_operand:SI 1 "register_operand" "=D"))
(clobber (match_operand:SI 2 "register_operand" "=c"))]
   "!TARGET_64BIT"
-  "repz cmpsb"
+  "repz{%;| }cmpsb"
   [(set_attr "type" "str")
(set_attr "mode" "QI")
(set_attr "prefix_rep" "1")])
@@ -18239,7 +18239,7 @@
(clobber (match_operand:SI 1 "register_operand" "=D"))
(clobber (match_operand:SI 2 "register_operand" "=c"))]
   "!TARGET_64BIT"
-  "repz cmpsb"
+  "repz{%;| }cmpsb"
   [(set_attr "type" "str")
(set_attr "mode" "QI")
(set_attr "prefix_rep" "1")])
@@ -18305,7 +18305,7 @@
(clobber (match_operand:SI 1 "register_operand" "=D"))
(clobber (reg:CC FLAGS_REG))]
   "!TARGET_64BIT"
-  "repnz scasb"
+  "repnz{%;| }scasb"
   [(set_attr "type" "str")
(set_attr "mode" "QI")
(set_attr "prefix_rep" "1")])
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/sol2.h ./sol2.h
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/sol2.h Wed Mar 31 11:03:29 
2010
+++ ./sol2.h Tue May 11 10:02:17 2010
@@ -172,3 +172,6 @@
 #define TF_SIZE 113
 
 #define MD_UNWIND_SUPPORT "config/i386/sol2-unwind.h"
+
+#undef  TARGET_SOLARIS
+#define TARGET_SOLARIS 1
 
 
Thanks,
 - JayOnly in .: 1.txt
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c ./i386.c
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c  Wed Apr  7 
23:58:27 2010
+++ ./i386.cTue May 11 10:01:54 2010
@@ -11896,11 +11896,10 @@
  retur

RE: rep prefix doesn't work with Solaris 2.9 Sun assembler

[Jay K]

Understood, but I'll have to stick to "small" changes as I can't get the papers.

Uros pointed to:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00657.html

which appears to just be *very* coincident timing.
So I Rainer will fix it soon.
I have a patch now based on that discussion.

I used:
    case ';':
      if ((TARGET_MACHO || TARGET_SOLARIS) && ASSEMBLER_DIALECT == ASM_ATT)
        fputs (" ; ", file);
      else
        fputc (' ', file);
      return;

though even better might be to assume 64bit implies more recent assembler:

    case ';':
      if ((TARGET_MACHO || TARGET_SOLARIS) && ASSEMBLER_DIALECT == ASM_ATT && 
!TARGET_64BIT)
        fputs (" ; ", file);
      else
        fputc (' ', file);
      return;

I guess there was an obscure bug where -masm=intel didn't work for Darwin 
targets?.
What, people use -masm=intel and masm/nasm/yasm instead of gas? Or just to 
human read the output?

Thanks,
 - Jay


> From: ebotca...@adacore.com
> To: jay.kr...@cornell.edu
> Subject: Re: rep prefix doesn't work with Solaris 2.9 Sun assembler
> Date: Tue, 11 May 2010 10:35:12 +0200
> CC: gcc@gcc.gnu.org
>
>> Proposed patch below/attached.
>> (-w to hide indent change)
>
> See http://gcc.gnu.org/contribute.html for guidelines.
>
>> I'll open a bug.
>
> See http://gcc.gnu.org/bugs for guidelines.
>
> Generally speaking, posting a patch inlined in a message on gcc@gcc.gnu.org
> will most likely result in it being lost and forgotten. In order to report
> an issue, please open a ticket with bugzilla. In order to submit a patch,
> please use gcc-patc...@gcc.gnu.org. In both cases, follow the guidelines
> written down in the aforementioned documentation. Thanks in advance.
>
> --
> Eric Botcazou
  

FW: [Bug c/44166] New: -fvisibility=protected doesn't work?

[Jay K]

> Date: Mon, 17 May 2010 13:41:57 +
> Subject: [Bug c/44166] New: -fvisibility=protected doesn't work?
> To: jay.kr...@cornell.edu
> From: gcc-bugzi...@gcc.gnu.org
>
> -fvisibility=protected doesn't work?
>
> a...@xlin2:~$ cat 1.c
> void F1() { }
> void* F2() { return F1; }
>
> j...@xlin2:~$ $HOME/bin/gcc 1.c -fPIC -shared -fvisibility=protected
>
> /usr/bin/ld: /tmp/cc0d6EQ3.o: relocation R_386_GOTOFF against protected
> function `F1' can not be used when making a shared object
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
>
> j...@xlin2:~$ $HOME/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/home/jay/bin/gcc
> COLLECT_LTO_WRAPPER=/home/jay/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
> Target: i686-pc-linux-gnu
> Configured with: /src/gcc-4.5.0/configure -verbose -prefix=/home/jay
> -disable-bootstrap -disable-multilibs
> Thread model: posix
> gcc version 4.5.0 (GCC)
>
>
> --
> Summary: -fvisibility=protected doesn't work?
> Product: gcc
> Version: 4.5.0
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: c
> AssignedTo: unassigned at gcc dot gnu dot org
> ReportedBy: jay dot krell at cornell dot edu
> GCC build triplet: i686-pc-linux-gnu
> GCC host triplet: i686-pc-linux-gnu
> GCC target triplet: i686-pc-linux-gnu
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44166
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
  

alpha-dec-osf5.1 4.5 built/installed

[Jay K]

per http://gcc.gnu.org/install/finalinstall.html

Built/installed 4.5 on alpha-dec-osf.

alphaev67-dec-osf5.1

bash-4.1$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper
Target: alphaev67-dec-osf5.1
Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls 
-prefix=/home/jayk
Thread model: posix
gcc version 4.5.0 (GCC) 

C and C++
Though I meant to let it do "all".

This isn't a "normal modern" 5.1, like 5.1a or 5.1b, but is old 5.1 rev 732.

Not easy to get the prerequisites for running tests: 
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00967.html
More followup still to do.

and I only ran make check in the gcc directory, to skip gmp/mpfr/mpc.


 - Jay
  

ARM FLOOR_MOD_EXPR?

[Jay K]

Do FLOOR_DIV_EXPR and FLOOR_MOD_EXPR work on ARM, for 64bit signed integer?
I have a front end (sort of), using gcc 4.3, generates trees, doesn't work.
   type_for_mode(TImode) is NULL and that is dereferenced.
I realize TRUNC_* would be far more "normal", but I can't change that.
I guess I'll just go back to generating function calls.

 - Jay
  

RE: ARM FLOOR_MOD_EXPR?

[Jay K]

in calls.c:

  tfom = lang_hooks.types.type_for_mode (outmode, 0);
  if (aggregate_value_p (tfom, 0))

for 64bit mod, outmode ends up TImode.
Our frontend doesn't support TImode -- reasonable? -- and so type_for_mode 
returns NULL here.
aggregate_value_p then derefences that NULL.

At least that's what happens in 4.3.

I tried hacking the C frontend to interpret % as FLOOR instead of TRUNC.
It works though -- the C frontend supports TImode.
Seems a little bit odd to depend on that?

 - Jay


> From: jay.kr...@cornell.edu
> To: gcc@gcc.gnu.org
> Subject: ARM FLOOR_MOD_EXPR?
> Date: Sat, 19 Jun 2010 08:17:16 +
>
>
> Do FLOOR_DIV_EXPR and FLOOR_MOD_EXPR work on ARM, for 64bit signed integer?
> I have a front end (sort of), using gcc 4.3, generates trees, doesn't work.
>type_for_mode(TImode) is NULL and that is dereferenced.
> I realize TRUNC_* would be far more "normal", but I can't change that.
> I guess I'll just go back to generating function calls.
>
>  - Jay
>
  

suggest assert wide_int larger than hashval_t

[Jay K]

I get this in 4.3.5:

../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type

./include/hashtab.h:typedef unsigned int hashval_t;

  unsigned HOST_WIDE_INT hwi;
  hashval_t h, *hp;
 ...
    const int shift = sizeof (hashval_t) * CHAR_BIT;
    const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
    int i;

    h ^= (hashval_t) hwi;
    for (i = 1; i < n; ++i)
      {
        hwi >>= shift;  here


It looks about the same in 4.5.0 except without const:


    int shift = (sizeof (hashval_t) * CHAR_BIT);


Something is amiss here locally, for the types to be the same size.


But maybe add gcc_assert(sizeof(hashval_t) < sizeof(HOST_WIDE_INT),
outside the loop? It should be optimized away anyway.


Maybe I'd get -Werror but I use -disable-bootstrap.
Native compiler is gcc, but old.


Thanks,
 - Jay

  

RE: suggest assert wide_int larger than hashval_t (32bit hwint?)

[Jay K]

Hm, it seems on some 32bit systems, where there is no -m64, wideint can be a 
mere 32bits.

In which case the code should probably say:

hwi = ((hwi >> (shift - 1)) >> 1);

This was targeting OpenBSD/x86.
Maybe I should just stick need_64bit_hwint = yes on config.gcc for that and 
move along?
Assume there is always long long or __int64?
Coverage of this case is pretty rare now from my skimming.

 - Jay


> From: jay.kr...@cornell.edu
> To: gcc@gcc.gnu.org
> Subject: suggest assert wide_int larger than hashval_t
> Date: Mon, 19 Jul 2010 06:44:33 +
>
>
> I get this in 4.3.5:
>
> ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
> ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
>
> ./include/hashtab.h:typedef unsigned int hashval_t;
>
>   unsigned HOST_WIDE_INT hwi;
>   hashval_t h, *hp;
>  ...
> const int shift = sizeof (hashval_t) * CHAR_BIT;
> const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
> int i;
>
> h ^= (hashval_t) hwi;
> for (i = 1; i < n; ++i)
>   {
> hwi >>= shift;  here
>
>
> It looks about the same in 4.5.0 except without const:
>
>
> int shift = (sizeof (hashval_t) * CHAR_BIT);
>
>
> Something is amiss here locally, for the types to be the same size.
>
>
> But maybe add gcc_assert(sizeof(hashval_t) < sizeof(HOST_WIDE_INT),
> outside the loop? It should be optimized away anyway.
>
>
> Maybe I'd get -Werror but I use -disable-bootstrap.
> Native compiler is gcc, but old.
>
>
> Thanks,
>  - Jay
>
>
  

RE: suggest assert wide_int larger than hashval_t

[Jay K]

It's "just" a warning, no "real" affects seen.
I patched my copy to say
  hwi = ((hwi >> (shift - 1)) >> 1);

Thanks,
 - Jay


> From: i...@google.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
> Subject: Re: suggest assert wide_int larger than hashval_t
> Date: Mon, 19 Jul 2010 00:36:06 -0700
>
> Jay K  writes:
>
> > I get this in 4.3.5:
> >
> > ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
> > ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
> >
> > ./include/hashtab.h:typedef unsigned int hashval_t;
> >
> >   unsigned HOST_WIDE_INT hwi;
> >   hashval_t h, *hp;
> >  ...
> > const int shift = sizeof (hashval_t) * CHAR_BIT;
> > const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
> > int i;
> >
> > h ^= (hashval_t) hwi;
> > for (i = 1; i < n; ++i)
> >   {
> > hwi >>= shift;  here
>
> It's not an actual problem, because the code is never executed in the
> case where right shift count >= width of type. Note that the loop
> starts at 1. If this is breaking bootstrap that it needs to be
> addressed one way or another, otherwise it's not too serious.
>
> Ian
  

http://gcc.gnu.org/install/specific.html maybe should mention memory settings for OpenBSD

[Jay K]

Possibly a note for:


http://gcc.gnu.org/install/specific.html
under OpenBSD.


or just for the mail archives:


Building a *slight* fork of 4.5.1 on OpenBSD/x86 4.7 I hit


gcc -c  -g -O2 -static -DIN_GCC   -W -Wall -Wwrite-strings \
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute   \
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc -I../../gcc-4.5/gcc/. \
-I../../gcc-4.5/gcc/../include -I../../gcc-4.5/gcc/../libcpp/include \
-I/home/jay/dev2/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp \
-I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/gmp \
-I/home/jay/dev2/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr \
-I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/mpfr \
-I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/mpc/src \
-I../../gcc-4.5/gcc/../libdecnumber \
-I../../gcc-4.5/gcc/../libdecnumber/dpd -I../libdecnumber \
-I/usr/local/include insn-attrtab.c -o insn-attrtab.o


cc1: out of memory allocating 304988696 bytes after a total of 0 bytes
gmake: *** [insn-attrtab.o] Error 1


This was not a problem with 4.3.0 or 4.3.5. I don't know about 4.4.x.
We skipped them, just because we are slow and lagging.
 

I couldn't get ulimit to do anything as non-root. I do have swap.


I changed these from 512 to 768, probably not all of them necessary:


# pwd
/etc
# grep 768 login.conf  
    :datasize-max=768M:\
    :datasize-cur=768M:\
    :datasize-cur=768M:\


and then I can proceed.


System probably doesn't have much RAM, maybe only 512MB, so that
could be where the previous values came from. I had never touched them.


Smaller amounts of RAM seem "more normal" these days to pack
more virtual machines onto one physical system.
(Though this just an old laptop, not a virtual machine.)


 - Jay
  

internal compiler error: in referenced_var_lookup, at tree-dfa.c

[Jay K]

So..we have a custom frontend.
That uses process boundaries to avoid GPL crossing into BSDish licensed code.
So maybe you don't want to help me. Understood.

But just in case:

We generate trees. Probably they aren't of great quality.
e.g. relatively devoid of types and do field accesses by offseting pointers and 
casting.
We do our own layout earlier. Not great, but that's how it is.


Currently we use gcc 4.5.1.
When I enable inlining on some architectures, e.g. Macosx/x86, much code yields:


../FPrint.m3: In function 'FPrint__xCombine':
../FPrint.m3:25:0: internal compiler error: in referenced_var_lookup, at 
tree-dfa.c:525
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Now I've spent a while debugging this. I'm not completely lazy.


The original source (again, not a standard frontend):

PROCEDURE xCombine (): INTEGER =
  BEGIN
    RETURN xFix32 (0);
  END xCombine;

PROCEDURE xFix32 (x: INTEGER): INTEGER =
  CONST a = 1;
  BEGIN
   IF Word.And (x, a) = 0 THEN
 RETURN 0;
   END;
   RETURN 0;
  END xFix32;

 -fdump-tree-all, 003t.original:

FPrint__xCombine ()
{
  int_32 D.985;
  int_32 M3_AcxOUs__result;

    int_32 M3_AcxOUs__result;
    int_32 D.985;
  D.985 = FPrint__xFix32 (0);
   = D.985;
  return ;
}


FPrint__xFix32 (int_32 M3_AcxOUs_x)
{
  int_32 M3_AcxOUs__result;

    int_32 M3_AcxOUs__result;
  if ((M3_AcxOUs_x & 1) != 0)
    {
  goto ;
    }
   = 0;
  return ;
  :;
   = 0;
  return ;
}



040t.release_ssa:
;; Function FPrint__xFix32 (FPrint__xFix32)

Released 0 names, 0.00%
FPrint__xFix32 (int_32 M3_AcxOUs_x)
{
  int_32 D.987;

:
  D.987_3 = M3_AcxOUs_x_2(D) & 1;
  if (D.987_3 != 0)
    goto  ();
  else
    goto ;

:
  _4 = 0;
  goto ;

:
  _5 = 0;

:
  # _1 = PHI <_4(3), _5(4)>
  return _1;

}


Breakpoint 1, 0x0078f21a in copy_phis_for_bb (bb=0x4126a280, id=0xb5d8) at 
../../gcc-4.5/gcc/tree-inline.c:1937
1937    {
(gdb) n
1938      basic_block const new_bb = (basic_block) bb->aux;
(gdb) 
1943      jaykrell_check_1();  doesn't do anything now, was helping debug 
(gdb) 
1945      for (si = gsi_start (phi_nodes (bb)); !gsi_end_p (si); gsi_next (&si))
(gdb) 
1947      tree res = { 0 }, new_res = { 0 };
(gdb) 
1948      gimple new_phi = { 0 };
(gdb) 
1949      edge new_edge = { 0 };
(gdb) 
1951      phi = gsi_stmt (si);
(gdb) 
1952      res = PHI_RESULT (phi);
(gdb) 
1953      new_res = res;
(gdb) 
1954      if (is_gimple_reg (res))
(gdb) 
1956          walk_tree (&new_res, copy_tree_body_r, id, NULL);
(gdb) 
1957          new_phi = create_phi_node (new_res, new_bb);  This line split up 
locally, ok.
(gdb) 
1958          SSA_NAME_DEF_STMT (new_res) = new_phi;
(gdb) call debug_referenced_vars()

Referenced variables in FPrint__xCombine: 7

Variable: D.1036, UID D.1036, int_32gimple_default_def 0x412130a8 1036

Variable: D.1041, UID D.1041, int_32gimple_default_def 0x412130a8 1041

Variable: .MEM, UID D.1038, , is global, call 
clobberedgimple_default_def 0x412130a8 1038

Variable: M3_AcxOUs_x, UID D.1039, int_32gimple_default_def 0x412130a8 1039

Variable: D.1040, UID D.1040, int_32gimple_default_def 0x412130a8 1040

Variable: , UID D.979, int_32gimple_default_def 0x412130a8 979

Variable: D.985, UID D.985, int_32gimple_default_def 0x412130a8 985


(gdb) n
1959          FOR_EACH_EDGE (new_edge, ei, new_bb->preds)
(gdb) call debug_referenced_vars()

Referenced variables in FPrint__xCombine: 7

Variable: D.1036, UID D.1036, int_32gimple_default_def 0x412130a8 1036

Variable: D.1041, UID D.1041, int_32gimple_default_def 0x412130a8 1041

Variable: .MEM, UID D.1038, , is global, call 
clobberedgimple_default_def 0x412130a8 1038

Variable: M3_AcxOUs_x, UID D.1039, int_32gimple_default_def 0x412130a8 1039

Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def 0x412130a8 
1093058884

Variable: , UID D.979, int_32gimple_default_def 0x412130a8 979

Variable: D.985, UID D.985, int_32gimple_default_def 0x412130a8 985


You can see D.1040 got overwritten with something else.
  And then later the assertion is that it is missing.
Is it valid for uids to be so high?


Any clues/tips?


Thanks much,
 - Jay
  

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

[Jay K]

Er, As  I understand, lack of a process boundary automatically implies GPL 
"spread" through "linkage".

  Assuming "linkage" means "ld". I'm not sure I've seen "linkage" defined. 
However

  if "linkage" or "derivation" includes "interaction via file or network I/O", 
then a lot of folks will be upset,
  (and some people very pleased :) ) File and network I/O connect all code in 
the world.

A process boundary at least gives you a chance.


Some of the work -- the frontend -- is clearly derived, and linked, so it is 
GPL.



> a derived work! You need to consult a knowledgable attorney before

> proceeding in this direction.



Most of the proceeding in this direction was done >10 years ago by others.
  Granted, I don't know what legal advise they had.

I'm proceeding not much further, e.g. merging to current gcc, making debugging 
better.

At some point I might generate C to fix a number of problems (including this 
assert and
licensing, and debugging, and efficient exception handling, etc.), but that is 
a different matter.



Anyway, I put this out there to give folks a chance to not "like" me and not 
help me.

I'll address the technical part separately.


Thanks,

 - Jay


> Date: Fri, 10 Sep 2010 11:17:59 -0400
> From: de...@adacore.com
> To: i...@google.com
> CC: jay.kr...@cornell.edu; gcc@gcc.gnu.org
> Subject: Re: internal compiler error: in referenced_var_lookup, at tree-dfa.c
>
> On 9/10/2010 11:08 AM, Ian Lance Taylor wrote:
> > Jay K writes:
> >
> >> That uses process boundaries to avoid GPL crossing into BSDish licensed 
> >> code.
> >> So maybe you don't want to help me. Understood.
> >
> > Note that different people have different opinions as to whether a
> > process boundary means that your code is not a derived work. Not that
> > we should get into that discussion on this mailing list.
>
> Indeed, it is important to realize that putting in an arbitrary
> process boundary is not guarantee at all that you have not created
> a derived work! You need to consult a knowledgable attorney before
> proceeding in this direction.
  

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

[Jay K]

[licensing dealt with separately]



> > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def 
> > 0x412130a8 1093058884
> This is clearly wrong, though I have no idea what caused it.
> > Is it valid for uids to be so high?
> No.

Thanks, that helps.


> From your description, you've implemented some sort of customized tree
> reader.


Not exactly, by my understanding of terminology.
We do end up making gcc trees but we serialize something that is separately
specified and not really the same, though some level of resemblance is
unavoidable since they both are involved with compilation, i.e. they both
have operations like "add" and notions of locals, parameters, functions, etc.
Ours is stack-based though for example (not my preference, but it was already 
there).


 > Does it play nicely with the garbage collector?


I think so.
We have the GTY annotations, I've managed to crash things when I got them
wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even have
to hack on the code a bit because GTY has to be in a different place.
I put the type declarations in seperate .h files, maintain both, and copy one
over the other before compilation.


We do have an open bug report about causing the gcc garbage collector
consuming infinite memory, maybe due to a cycle in our data.
But really the system works a ton. I can compile and run tens of thousands of 
lines
of code, for multiple architectures. I "just" have to turn off inlining, and 
a small number of other optimizations. Clearly we are pretty good, and flawed.


Notice that the gcc middle end seemed to have created this variable with the 
high uid.
I checked the globals that guide uid assignment, found them after sending the
first mail. They aren't so high.
I haven't yet found where this uid comes from.
I kind of suspect it might be a type mismatch, overwriting part of a tree node
  with the wrong type or such.
I'll have to dig more.

I know it comes from here:
copy_phis_for_bb:
...
      SSA_NAME_DEF_STMT (new_res)
        = new_phi = create_phi_node (new_res, new_bb);



Thanks,
 - Jay
  

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

[Jay K]

> I kind of suspect it might be a type mismatch, overwriting part of a tree node

configure -enable-checking:

?"Bmr?: In function 'FPrint__xCombine':
`?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have 
var_decl in copy_phis_for_bb, at tree-inline.c:1950

and some other problems..I really need to fix those...

 - Jay


> From: jay.kr...@cornell.edu
> To: i...@google.com
> CC: gcc@gcc.gnu.org
> Subject: RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
> Date: Fri, 10 Sep 2010 20:38:58 +
>
>
> [licensing dealt with separately]
>
>
>
> > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def 
> > > 0x412130a8 1093058884
> > This is clearly wrong, though I have no idea what caused it.
> > > Is it valid for uids to be so high?
> > No.
>
> Thanks, that helps.
>
>
> > From your description, you've implemented some sort of customized tree
> > reader.
>
>
> Not exactly, by my understanding of terminology.
> We do end up making gcc trees but we serialize something that is separately
> specified and not really the same, though some level of resemblance is
> unavoidable since they both are involved with compilation, i.e. they both
> have operations like "add" and notions of locals, parameters, functions, etc.
> Ours is stack-based though for example (not my preference, but it was already 
> there).
>
>
>  > Does it play nicely with the garbage collector?
>
>
> I think so.
> We have the GTY annotations, I've managed to crash things when I got them
> wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even have
> to hack on the code a bit because GTY has to be in a different place.
> I put the type declarations in seperate .h files, maintain both, and copy one
> over the other before compilation.
>
>
> We do have an open bug report about causing the gcc garbage collector
> consuming infinite memory, maybe due to a cycle in our data.
> But really the system works a ton. I can compile and run tens of thousands of 
> lines
> of code, for multiple architectures. I "just" have to turn off inlining, and
> a small number of other optimizations. Clearly we are pretty good, and flawed.
>
>
> Notice that the gcc middle end seemed to have created this variable with the 
> high uid.
> I checked the globals that guide uid assignment, found them after sending the
> first mail. They aren't so high.
> I haven't yet found where this uid comes from.
> I kind of suspect it might be a type mismatch, overwriting part of a tree node
>   with the wrong type or such.
> I'll have to dig more.
>
> I know it comes from here:
> copy_phis_for_bb:
> ...
>   SSA_NAME_DEF_STMT (new_res)
> = new_phi = create_phi_node (new_res, new_bb);
>
>
>
> Thanks,
>  - Jay
>
  

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

[Jay K]

arg..well, I had replaced xmalloc with alloca, leading to some of the garbage 
below, but
I am indeed still running afoul of the garbage collector.
I don't know if that is my original problem but I should probably fix this 
first.
 ie: now that I'm using -enable-checking, and I think it collects earlier/more 
often.


I need to "map" my internal unsigned long arbitrary integers, to trees.
So I just have an array of struct {unsigned id; tree t };
I put GTY on the struct, on the field, and on the VEC of them.
When I append I mark it dirty.
When I search I qsort if dirty, then bsearch.


typedef struct GTY(()) m3type_t
{
  unsigned long id;
  tree GTY (()) t;
} m3type_t;


static GTY (()) VEC (m3type_t,gc)* m3type_table;

seems reasonable eh?
The files are in gtfiles. When I put the GTY in the wrong place I get compile 
errors.

I guess I can try rolling my own "VEC" or even use a fixed size and see what 
happens..

Thanks,
 - Jay


> From: jay.kr...@cornell.edu
> To: i...@google.com
> CC: gcc@gcc.gnu.org
> Subject: RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
> Date: Sat, 11 Sep 2010 08:48:08 +
>
>
> > I kind of suspect it might be a type mismatch, overwriting part of a tree 
> > node
>
> configure -enable-checking:
>
> ?"Bmr?: In function 'FPrint__xCombine':
> `?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have 
> var_decl in copy_phis_for_bb, at tree-inline.c:1950
>
> and some other problems..I really need to fix those...
>
>  - Jay
>
> 
> > From: jay.kr...@cornell.edu
> > To: i...@google.com
> > CC: gcc@gcc.gnu.org
> > Subject: RE: internal compiler error: in referenced_var_lookup, at 
> > tree-dfa.c
> > Date: Fri, 10 Sep 2010 20:38:58 +
> >
> >
> > [licensing dealt with separately]
> >
> >
> >
> > > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def 
> > > > 0x412130a8 1093058884
> > > This is clearly wrong, though I have no idea what caused it.
> > > > Is it valid for uids to be so high?
> > > No.
> >
> > Thanks, that helps.
> >
> >
> > > From your description, you've implemented some sort of customized tree
> > > reader.
> >
> >
> > Not exactly, by my understanding of terminology.
> > We do end up making gcc trees but we serialize something that is separately
> > specified and not really the same, though some level of resemblance is
> > unavoidable since they both are involved with compilation, i.e. they both
> > have operations like "add" and notions of locals, parameters, functions, 
> > etc.
> > Ours is stack-based though for example (not my preference, but it was 
> > already there).
> >
> >
> > > Does it play nicely with the garbage collector?
> >
> >
> > I think so.
> > We have the GTY annotations, I've managed to crash things when I got them
> > wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even 
> > have
> > to hack on the code a bit because GTY has to be in a different place.
> > I put the type declarations in seperate .h files, maintain both, and copy 
> > one
> > over the other before compilation.
> >
> >
> > We do have an open bug report about causing the gcc garbage collector
> > consuming infinite memory, maybe due to a cycle in our data.
> > But really the system works a ton. I can compile and run tens of thousands 
> > of lines
> > of code, for multiple architectures. I "just" have to turn off inlining, and
> > a small number of other optimizations. Clearly we are pretty good, and 
> > flawed.
> >
> >
> > Notice that the gcc middle end seemed to have created this variable with 
> > the high uid.
> > I checked the globals that guide uid assignment, found them after sending 
> > the
> > first mail. They aren't so high.
> > I haven't yet found where this uid comes from.
> > I kind of suspect it might be a type mismatch, overwriting part of a tree 
> > node
> > with the wrong type or such.
> > I'll have to dig more.
> >
> > I know it comes from here:
> > copy_phis_for_bb:
> > ...
> > SSA_NAME_DEF_STMT (new_res)
> > = new_phi = create_phi_node (new_res, new_bb);
> >
> >
> >
> > Thanks,
> > - Jay
> >
>
  

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

[Jay K]

I have it seemingly working now, much better, thanks for the nudges -- that 
indeed high id is invalid, and to look again at my GTY use.
I don't know if it made the difference but I changed some whitespace to match 
others, and
typedef struct foo_t { ... } foo_t;
to
typedef struct foo { ... } foo_t; without the _t on the struct tag.

 - Jay


...snip...
  

eliminating mpc/mpfr and reducing gmp

[Jay K]

Hi. You know, gmp/mpfr/mpc are a significant
portion of building any frontend/backend.


So I looked at it.


mpc of course is only for complex numbers.
Our frontend doesn't use them.
Maybe only for "builtins" as well.


#define do_mpc_arg1(a, b, c) NULL_TREE
and such.


mpfr appears to be used for floating point builtins.
Not for floating point constant folding as I'd thought?


We generate very few builtins, just memcmp, memset, memmove, memcpy, and *sync*.
Either way, floating point doesn't matter to me much.
#define do_mpfr_arg1(a,b,c) NULL_TREE and such.
including something_logarithm, something_exponent.


And #if out the version report in toplev.c.
And the then unused conversions in real.c.
and the #include in real.h.


and then mpfr isn't needed.


That is: changes to gcc to eliminate mpc and mpfr dependencies are pretty darn 
small.
I used #if 1/#if 0, but it'd be easy enough to have configure -without-mpc 
-without-mpfr.
I was able to do this for 4.5, and then 4.3 was trivial, the same except no mpc.


And then, if you dig a bit more, you find that gmp
contains "n", "q" (rational), "z", "f" (float), and miscellaneous e.g. *rand*.
(apples and oranges: *rand* must operate on some mp type, of course)


None of "q" and "f" are needed, and vast swaths of "n" and "z"
are unused and can be deleted. Easier to truncate the
files first when experimenting.


Probably can do even better.
There is a file in GMP dumbmp.c (as in dump, stupid) that contains
a simple portable subset of GMP, used for some "generator" programs.
First glance says it isn't sufficient, but it might be close..


The result is a lot faster to build, if you are just doing a just
a single stage build of a compiler.
To some extent it adds up -- multiple stages.
To some extent it is is minor -- if you are building libstdc++/libada/libjava x 
multilibs.
I build just a frontend/backend though.


I understand you can also build/install the libraries once.
That isn't a terrible option. I have operated that away. But does have 
drawbacks.
It is harder for Canadian cross and "cross back" (cross build a native 
compiler),
which admittedly, I don't do much. 
There were problems last I tried, esp. with enable-shared and fixincludes,
and it always a pain to get the C runtime headers/libraries.
The first I opened bugs for. The second can't really be fixed, except
e.g. with an integrated tree with glibc/newlib. Maybe some people
have scripts out there to scp the appropriate files. I end up taking
way more than necessary and sometimes hunting around for what I missed.


and gmp doesn't build with default gcc 4.0 on Intel MacOSX 10.5.
Building within the gcc tree is one workaround, because how it fiddles with 
CFLAGS
and seemingly accidentally avoids the problems with "inline".
Granted, CC=gcc-4.2 is another easy one. Other options.


Anyway.

- Jay 

RE: eliminating mpc/mpfr and reducing gmp

[Jay K]

Wow that is fast.


My fastest machine, and I have several slower:


gmp
time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared 
-enable-static && make && ssh r...@localhost \"cd `pwd` && make install\""
real    2m2.594s

mpfr
time sh -c "./configure -disable-shared -enable-static && make && ssh 
r...@localhost \"cd `pwd` && make install\""
real    0m43.756s

mpc
time sh -c "./configure -disable-shared -enable-static && make && ssh 
r...@localhost \"cd `pwd` && make install\""
real    0m15.495s


which is still a significant fraction of building cc1 (I don't have that time 
sorry)

I used to use Cygwin. Things add up much faster there.


> mpfr et al. If you're not, it only happens once.


Almost anything long but incremental can be justified via incrementality.
But there is also, occasionally, mass bouts of trying to get the configure 
switches just right and
starting over repeatedly...at least me being unsure of incrementality in the 
fact of rerunning configure...


Anyway, just putting it out there, probably won't happen, but  configure 
-without-mpc -without-mpfr might be nice
and aren't difficult, -without-gmp much better, but I can't yet claim it isn't 
difficult.
Maybe, something like, if gmp is "in tree", after configure, the Makefile could 
be hacked down
to omit mpf, mpq, and lots others, but then the linkage between gcc and gmp 
gets messy.
  i.e. as gmp changes.


 - Jay


> Date: Mon, 27 Sep 2010 11:37:04 +0100
> From: a...@redhat.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
> Subject: Re: eliminating mpc/mpfr and reducing gmp
>
> On 09/27/2010 01:23 AM, Jay K wrote:
> >
> > Hi. You know, gmp/mpfr/mpc are a significant
> > portion of building any frontend/backend.
>
> I disagree. Most of the time I don't notice them.
>
> > The result is a lot faster to build, if you are just doing a just
> > a single stage build of a compiler.
>
> Sure, but if you're working on the compiler you don't need to rebuild
> mpfr et al. If you're not, it only happens once.
>
> On my box, for mpc:
>
> real 0m2.624s
> user 0m3.336s
> sys 0m1.663s
>
> and for mpfr:
>
> real 0m4.484s
> user 0m12.006s
> sys 0m5.127s
>
> Andrew.
  

RE: eliminating mpc/mpfr and reducing gmp

[Jay K]

I only do one language, no driver, one stage, no libraries (none of libgcc, 
libstdc++, libjava, libada, etc.), no fixincludes (the headers are probably 
fine, and aren't used by this frontend anyway), the bootstrap compiler is 
always pretty decent, thus one stage (or I'll "cheat" and do one full regular 
bootstrap+install of a recent release on the occasional oddball host).
 
 
It takes under 10 minutes on year old MacBook. (sorry, I didn't measure).
 
 
I guess it is very unusual, but it is also actually very useful.
 
 
Everyone else probably depends on good incrementality when actively changing 
stuff, or pays a higher price overall when occasionally building the entire 
thing clean and not changing stuff, so this is minor.
 
 
We understand each other, fair enough.
 
 
 - Jay



> Date: Tue, 28 Sep 2010 01:51:31 +0100
> From: dave.korn.cyg...@gmail.com
> To: jay.kr...@cornell.edu
> CC: a...@redhat.com; gcc@gcc.gnu.org
> Subject: Re: eliminating mpc/mpfr and reducing gmp
>
> On 27/09/2010 12:39, Jay K wrote:
>
> > gmp
> > time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared 
> > -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\""
> > real 2m2.594s
> >
> > mpfr
> > time sh -c "./configure -disable-shared -enable-static && make && ssh 
> > r...@localhost \"cd `pwd` && make install\""
> > real 0m43.756s
> >
> > mpc
> > time sh -c "./configure -disable-shared -enable-static && make && ssh 
> > r...@localhost \"cd `pwd` && make install\""
> > real 0m15.495s
>
>
> > which is still a significant fraction of building cc1 (I don't have that
> > time sorry)
>
>
> Huh, am I doing something seriously wrong? It takes me four hours to
> boostrap GCC at with all languages enabled at -j8 on an AMD2x64; I'm not too
> concerned about 3 minutes per pass!
>
> cheers,
> DaveK
> 

RE: eliminating mpc/mpfr and reducing gmp

[Jay K]

> Well, the other thing is: why not just build them once and install them to
> your $prefix? There's no need to build them in-tree every time if you have
> sufficiently up-to-date versions installed.
>
> cheers,
> DaveK

 
I have a CVS tree, used by others, that builds a frontend.
 
 
"Others" are a few people and a few automated build machines (using Hudson),
with various operating systems (Linux, Solaris, Darwin, FreeBSD, etc.).
 
 
The requirements on these machines isn't of course zero -- they
exist, they are up and running -- but is kept low where possible.
 
 
So the decision was made, not exactly by me, but I went along,
to add gmp+mpfr to the tree, and later mpc.
 
 
It's pretty simple, reliable, works.
 
 
What I was often doing was deleting gmp/mpfr in my local CVS tree,
leaving configure to find them in /usr/local.
And then sometimes I'd accidentally restore them with cvs upd -dAP.
 
 
I toyed with the idea of having it always check /usr/local first
but didn't do that. What if user has an insufficient version there?
I'd have to test for that and fallback to in-tree.
 
 
Since we are using Hudson we could probably add nice automation,
to build gmp/mpfr/mpc "somewhere", neither /usr/local, nor "in gcc",
 maybe install to $HOME/hudson, and point the frontend build at them.
But the Hudson stuff...is not well known to me, I'd kind of rather
leave it alone. And I'd have to e.g. deal with the gmp inline problem,
just another small detail...
 
 
I'm satisfied so far with the pruning. I can see it isn't for everyone.
We'll see, maybe I'll grow to dislike it as well.
 
 
 - Jay

atomicity of x86 bt/bts/btr/btc?

[Jay K]

gcc-4.5/gcc/config/i386/i386.md:

;; %%% bts, btr, btc, bt.
;; In general these instructions are *slow* when applied to memory,
;; since they enforce atomic operation. When applied to registers,


I haven't found documented confirmation that these instructions are atomic 
without a lock prefix,
having checked Intel and AMD documentation and random web searching.
They are mentioned as instructions that can be used with lock prefix.


- Jay 

RE: atomicity of x86 bt/bts/btr/btc?

[Jay K]

> Subject: Re: atomicity of x86 bt/bts/btr/btc?
> From: foxmuldrsterm
> To: jay.krell
> CC: gcc@gcc.gnu.org
> Date: Tue, 19 Oct 2010 02:52:34 -0500
>
> > ;; %%% bts, btr, btc, bt.
> > ;; In general these instructions are *slow* when applied to memory,
> > ;; since they enforce atomic operation. When applied to registers,
> >
> > I haven't found documented confirmation that these instructions are atomic 
> > without a lock prefix,
> > having checked Intel and AMD documentation and random web searching.
> > They are mentioned as instructions that can be used with lock prefix.
>
> They do not automatically lock the bus. They will lock the bus with the
> explicit LOCK prefix, and BTS is typically used for an atomic read/write
> operation.
>
> - Rick

 
Thanks Rick.
I'll go back to using them.
I'm optimizing mainly for size.
The comment should perhaps be amended.
The "since they enforce atomic operation" part seems wrong.
 
 - Jay

RE: atomicity of x86 bt/bts/btr/btc?

[Jay K]

> Subject: RE: atomicity of x86 bt/bts/btr/btc?
> From: foxmuldrster
> To: jay
> CC: gcc
> Date: Tue, 19 Oct 2010 03:05:26 -0500
>
> > > They do not automatically lock the bus. They will lock the bus with the
> > > explicit LOCK prefix, and BTS is typically used for an atomic read/write
> > > operation.
>
> > Thanks Rick.
> > I'll go back to using them.
> > I'm optimizing mainly for size.
> > The comment should perhaps be amended.
> > The "since they enforce atomic operation" part seems wrong.
>
> Np. For citation, see here (page 166).
>
> http://www.intel.com/Assets/PDF/manual/253666.pdf
>
> - Rick

 
Yep that was one of my references.
 
 
It might be nice if optimizing for size would use them with code like e.g.:
 
 
void set_bit(size_t* a, size_t b)
{
  const unsigned c = sizeof(size_t) * CHAR_BIT;
  a[b / c] |= (((size_t)1) << (b % c));
}
 
void clear_bit(size_t* a, size_t b)
{
  const unsigned c = sizeof(size_t) * CHAR_BIT;
  a[b / c] &=  ~(((size_t)1) << (b % c));
}
 
int get_bit(size_t* a, size_t b)
{
  const unsigned c = sizeof(size_t) * CHAR_BIT;
  return !!(a[b / c] & (((size_t)1) << (b % c)));
}
 
 
 - Jay

is gcc garbage collector compacting?

[Jay K]

Is the gcc garbage collector compacting?


In particular I want to have ".def" file (like tree.def) where
the macros generate struct declarations,
and the fields might be tree.


That won't work with the gcc garbage collection scheme.


However, I'm willing also store all trees
that go in these structs in a global VEC of trees,
that does work with the garbage collector.


That would suffice to keep them alive.
But it wouldn't keep them up to date if the
garbage collector is compacting.


Heck, I guess, if need be, I'm willing to apply
a slight hack to disable the garbage collector.


If I really must -- if there is really much garbage
to collect, I could run the preprocessor ahead of time
and provide a file to gengtype that it understands.
I'm leary of this approach, because I want only
certain preprocessing to take place.
I could output markers before/after the chunk I want though.


Or, maybe the files do get preprocessed?
Evidence is no, as when #if 0'ed out some types, gengtype still saw them.
Something to consider, perhaps.


Thanks,
 - Jay

  

RE: is gcc garbage collector compacting?

[Jay K]

 > Are you coding inside your branch, or just your plugin?
 > [implied] What are you actually doing? 


It isn't relevant or short, but if you really want to know:


It is a front end, and indeed, a branch, it won't ever be contributed.
It is the Modula-3 frontend, which plays slight licensing games and
the original authors aren't around, so couldn't get to FSF, and current
maintainers can't either.


Honestly, long term, I'd like to generate C instead, for a variety of reasons.
 - no more license game 
 - more portability (e.g. to platforms that also fork/maintain gcc,
   so we don't have to fork and patch also theirs: e.g. OpenBSD, iPhone;
    e.g. to platforms with no gcc such as NT/ia64) 
 - generate C++ actually, for portable usually efficient exception handling 
   Currently we use setjmp/longjmp and a thread local. It works and is very 
portable,
    but is very inefficient.
 - debuggability, with stock debuggers   
 - solidly fix stuff I detail below  
 - a source distribution story  
   Yes, I realize, compilers must be distributed as binaries, but one can
   paint the world as layered on C or C++ and then only their compilers need 
binary distribution. 
  - I realize compile speed would suffer. And expression evaluation in debugger 
would suffer. Those are the drawbacks. 


Making it a plugin might be viable in the future, but I'm more keen on 
generating C instead.
We also have our own frontend for NT/x86, that writes out COFF .objs, which 
might be interesting to extend to others,
but that is a lot of work.


Historically we have generated very poor trees.


One particular example is that our structs have size but no fields.
I only realized this when targeting Solaris/sparc64 and hitting
assertion failures in the middle end -- the code couldn't
figure out how to pass such things.


As well, historically, we made everything volatile, in order to defeat
the optimizer. Now what we do is almost never use volatile, but still
turn off a small number of optimizations.


Nobody also had been using configure -enable-checking, and it complains 
variously.
I've fixed some of that.


So I'm working on filling in types much better.


I have made good fast progress.




This also greatly improves debugging with stock gdb, instead of forked/hacked
gdb that we get debug info to in a somewhat sleazy but fairly portable way
(custom stabs, as I understand, doesn't work e.g. on HP-UX/HPPA64 or on any 
MacOSX.)



However some of the types are circular, and the code currently
only makes one pass. So I simply want it to build up its own in-memory
representation, make some passes over that, and then generate the "real" trees.
The in-memory representation will contain some trees.. though I suppose
now that I explain it, there is a way around that.


The reading of the intermediate form is somewhat data driven, reading into 
locals.
I want to reuse that but read into structs, and then loop over them.
Simple stuff really.


I could probably also make extra passes over the gcc trees instead,
but I'm designing partly out of ignorance. I'm not sure when you can
continue to change them vs. when they are frozen.


The non-compacting of the gc makes this easier than it might be otherwise.
Though looking at it, we already store many of our trees in global arrays.
There's just a few stragglers I can also put in global arrays and be ok.


Thanks,
 - Jay
  

RE: is gcc garbage collector compacting?

[Jay K]

> I believe that your case is a very good example of why front-ends
> should be able to become plugins. It is not the case yet, and adding


Currently we do define a new tree code, I think just one.
And the implementation is *slightly* invasive.


I was tempted to write up a proposal to this list to add it to mainline gcc but
I ended up not.


I noticed the D/gcc frontend does something similar.


In particular..nested functions...taking their address..we implement them in a 
way that
doesn't involve runtime codegen. Though there are significant downsides
to what we do. Having thought about it, I believe there is no particularly
good way to implemented nested functions (taking their address), just
multiple not very good ways.


What we do is, is that function pointers are rare in our language.
Before calling through any function pointer, we read the data it points to and
check for a marker -- -1, currently of size_t size, though probably should
always be 4 bytes (alignment issues), except maybe on IA64 (particularly
large instructions). This is a bit sleazy -- assumption
that code is readable and that -1 isn't valid code, but other target-dependent
markers could be specified. Anyway, if it -1, it is followed by actual function
pointer and frame pointer, and that is used instead of calling it directly.
Something like that.
The implication on the backend isn't perhaps clear from that, nor do I 
necessarily
understand it. But certainly gcc's existing nested functions don't work this 
way.
I understand, again, there are major tradeoffs either way. Ours is not 
monotonically
better than gcc's.
Ah, I guess the new code is to load the static link following the -1.


A C-generating front end has other advantages:
  I know what is well formed C.
  I don't know what is well formed gcc/tree or gcc/gimple.
  The various problems we have with the optimizer -- because our trees are 
poorly formed -- would go away.
   We wouldn't have to twiddle various optimizations off.
  This is sort of "magic/special" -- I just happen to know far more about C 
than gcc internals.
  

> (and there is also LLVM which could perhaps interest you).


Yeah, people have asked about using it. But nobody puts any work into
it from our side (we have precious few people doing anything!).
We aren't supposed to discuss it here. :)
And it has the same disadvantage vs. C/C++ that gcc/tree/gimple has -- I know 
what is valid C/C++,
whereas LLVM is another big unknown to investigate. And it hits fewer targets.
Granted, both mainline gcc and LLVM hit plenty targets.
I do dream of having portability on par with: printf("hello world\n"); without
doing much porting myself/ourselves, and have access to wierd systems such as 
VMS. :)


 > future gimple front-end


Interesting. But again similar problems.
  Given my knowledge, generating C/C++ easier than anything else. 
Also have to wait until these versions of gcc are widespread.
Look at Apple and OpenBSD for how older gcc remains in use.


Anyway, knowing the garbage collector isn't compacting is good.


Thanks,
 - Jay


> Date: Wed, 3 Nov 2010 10:23:14 +0100
> From: basile@
> To: jay.kr...@u
> CC: gcc@
> Subject: Re: is gcc garbage collector compacting?
>
[snip]
  

asm_fprintf inefficiency?

[Jay K]

so..I was bemaining to self extra #ifs, extra autoconf..
the checking for puts_locked...
the fact that asm_fprintf calls putc one character at a time,
which probably benefits from _unlocked.



1) asm_fprintf probably should skip from % to %, calling
puts on each span, instead of putc one at a time.
Granted, its input strings tend to be short.


2) But more so..


given, e.g.:


asm_fprintf(file, "%Rfoo");


one could instead say


#ifndef REGISTER_PREFIX
#define REGISTER_PREFIX ""
#endif


fprintf(file, "%sfoo", REGISTER_PREFIX);


That works for all of asm_fprintf (I, L, R, U) except %O, and %O appears
little used or unused. And it doesn't handle {.


jbook2:gcc jay$ grep asm_fprintf */*/* | grep { | wc -l
  33
jbook2:gcc jay$ grep asm_fprintf */*/* |  wc -l
 318

Maybe something else could be done for those 10%?

like:
before:
asm_fprintf (file, "\t{l|lwz} %s,", reg_names[0]);

after:
fprintf (file, "\t%s %s,", dialect_number ? "lwz" : "l", reg_names[0]);
or bigger/faster:
fprintf (file, dialect_number ? "\tlwz %s," : \tl %s,", reg_names[0]);


(Really I'd rather gcc just output .o files directly...)


 - Jay




  

RE: asm_fprintf

[Jay K]

 > And putc_unlocked is a macro which appends to a buffer. puts is not.
 
 
I *assumed* there is puts_unlocked like all the other *_unlocked.
Maybe not.

 
 > (Really I'd rather gcc just output .o files directly...) 
 > It would be an interesting project, but it's not a major component of 
 > optimizing compilation time. I would certainly encourage any interested 
 
 
Perhaps when not optimizing?
Eh, but I've taken no measurement.
There is the possible fork() cost on Cygwin.
But maybe spawn is used, much faster.
 
 
 
 - Jay

extern "C" applied liberally?

[Jay K]

I know it is debatable and I could be convinced otherwise, but I would suggest:
 
 
 
#ifdef __cplusplus
extern "C" {
#endif
 
...


#ifdef __cplusplus
} /* extern "C" */
#endif
 
 
be applied liberally in gcc.
Not "around" #includes, it is the job of each .h file, and mindful of #ifdefs 
(ie: correctly).
 
 
Rationale:
  Any folks that get to see the mangled names, debugging, working on binutils, 
whatever, are saved from them.
 They are generally believed to be ugly, right? Yeah yeah, not a technical 
argument.
 
  For some reason, I wasn't able to set breakpoints in gdb on MacOSX otherwise, 
though this doesn't make sense and a small example didn't reproduce the 
behavior. I have since applied this to 300+ files in a 4.5.1 fork -- not all of 
them just out of time/laziness. (I tried and failed to automate it.)
 
 
 
I think it is a good idea for any C or historically C code when moving to a C++ 
compiler.
  I have done that with a few small/medium sized code bases.
 
 
 
They could/would be removed as templates/function overloads/operator 
overloading are introduced.
Or such sections of code/declarations could have extern "C++" { } around them 
(not a well known feature, but ok.)
 
 
 
 - Jay

re: extern "C" applied liberally?

[Jay K]

I somewhat tracked down the odd/dubious reason extern "C" is "good".


Some wierd interaction on Darwin with Apple's gcc and gdb.

Breakpoints don't work on non-extern "C", at least if a library is involved.

This isn't necessarily a problem with gcc, or current gcc, or non-Apple gcc,
or gdb, or non-Apple gdb, but somewhere in the Apple gcc/gdb.
Reported here for followup to my suggestion of liberal use of extern "C".
  (which I have applied to our fork and it does help)


1.c

#include "1.h"

int main()
{
 F1();
}


2.c

#ifdef EXTERNC
extern "C" {
#endif
static void F2(void) { }
void F1(void) { F2(); }
#ifdef EXTERNC
}
#endif


1.h
#ifdef EXTERNC
extern "C" {
#endif
void F1(void);
#ifdef EXTERNC
}
#endif


$ rm -rf a.out*
$ g++ -g -c 1.c 2.c
$ rm lib2.a
$ ar rc lib2.a 2.o
$ rm 2.o
$ g++ -g 1.o -L. -l2
$ gdb ./a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
...
(gdb) break F2
Function "F2" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) break F1
Function "F1" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) q


$ g++ -g -c 1.c 2.c -DEXTERNC
$ rm 2.o
$ rm lib2.a
$ g++ -g -c 1.c 2.c -DEXTERNC
$ ar rc lib2.a 2.o
$ g++ -g 1.o -L. -l2
$ gdb ./a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
...

(gdb) break F2
Breakpoint 1 at 0x1fae: file 2.c, line 4.
(gdb) break F1
Breakpoint 2 at 0x1fb6: file 2.c, line 5.
(gdb) q


Using Apple's gcc-4.2 didn't help.


Strange.


(In reality, the library is libbackend.a)


$ g++ -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking 
-enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ 
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib 
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic 
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)


I could try with my own gcc.
But maybe it is a matter of flags to gcc/ar/ld.


 - Jay
  

-fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)

[Jay K]

/src/gcc-4.7.0/configure -disable-bootstrap -enable-languages=go


book2:gccgo-4.7 jay$ g++ -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking 
-enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ 
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib 
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic 
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)


a lot of:

/usr/include/c++/4.0.0/tr1/functional_iterate.h:912: error: cannot use typeid 
with -fno-rtti
/src/gcc-4.7.0/gcc/go/gofrontend/string-dump.h: At global scope:


gcc/configure.ac:

# Disable exceptions and RTTI if building with g++
ACX_PROG_CC_WARNING_OPTS(
    m4_quote(m4_do([-fno-exceptions -fno-rtti])), [noexception_flags])

Maybe best to just leave the default flags? Maybe just remove this snippet?
Or maybe this is
 - meant for otherwise C code? Slightly optimize it??
 - meant to reduce memory/disk use and let things work that otherwise fail?
  i.e. on older hosts and/or with older g++?
  
 
Yeah yeah, I'll try without -disable-bootstrap.
If that fails though, I'll try removing those lines from configure/configure.ac.


Thank you,
  - Jay
  

tree-nomudflap.c dependency on gt-tree-mudflap.h not needed

[Jay K]

 gcc-4.6.2/gcc/Makefile.in: 


 tree-nomudflap.o : $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(TREE_INLINE_H) \ 
 $(C_TREE_H) $(C_COMMON_H) $(GIMPLE_H) $(DIAGNOSTIC_H) $(HASHTAB_H) \ 
 output.h langhooks.h tree-mudflap.h $(TM_H) coretypes.h \ 
 $(GGC_H) gt-tree-mudflap.h $(TREE_PASS_H) $(DIAGNOSTIC_CORE_H) 


 gcc-4.6.2/gcc/tree-nomudflap.c 

 /* Instead of: 
 #include "gt-tree-mudflap.h" 
 We prepare a little dummy struct here. 
 */ 

 EXPORTED_CONST struct ggc_root_tab gt_ggc_r_gt_tree_mudflap_h[] = { 
 LAST_GGC_ROOT_TAB 
 }; 


 so I don't believe gt-tree-mudflap.h should be in the dependencies of 
 tree-nomudflap.o. 


 and 4.7.0 is the same. 


(on the other hand -- it seems kind of hacky and maybe the right fix is the 
other way around?)


 - Jay  
  

RE: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)

[Jay K]

> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
> the way.)

I don't know why.
I'm getting them, at least via the list.


> Since the OP is apparently seeing Go build in stage 1, I assume that the
> OP is configuring with --disable-bootstrap or with


Right. I thought I was clear on that.


So I guess there is nothing to see here..move along..but..why the use of 
-fno-rtti?
It seems like a guess of "more work for less good"?
i.e. remove those lines in configure and more fairly reasonable stuff works?


I can see maybe the opposite though.
Maybe the point is to avoid poor rtti implementations in old gcc bootstrap??
Or maybe the point was to compile C, really C code, with g++, and turn off 
"gratituitous"
C++ features that the code "doesn't even come near" (i.e. the bulk of gcc 
really is C
that is compatible with gcc, vs. the go frontend that is currently a rare case 
of "actual C++".
  If that's the rationale, again, maybe the lines should just be removed. I 
understand this is
  much to do about very little.


Heck maybe rtti and exceptions are decent enough out there that stage1 could 
use them??


I "always" use -disable-bootstrap.
So much gain for acceptable pain.
I know I'm cutting corners, but I'm in active development of very small changes.


My bootstrap compiler isn't super wierd/bad, just a somewhat old gcc/g++.
  (I have relatively recently bootstrapped from K&R cc on HP-UX though gcc 3.x 
to get to gcc 4.x, and buggy
  compilers I think on Irix that slightly miscompile GNU make, forcing one to 
loop back with
  gcc and rebuild make and then rebuild gcc (maybe in-tree the first time, I 
forget..I should check my notes..)..
But anyway...


I don't want to change a header and have make go through and build the compiler 
multiple times.
I have enough problems with incrementality building way too much..that I should 
look into..



I really just wanted to step through gccgo to understand its implementation to 
inform my own front end work.
(Yes, go is certainly an interesting hybrid -- native code + static compilation 
+ static typing + C-like syntax + garbage collection + fast compilation
via a good module system instead of the C preprocessor toiling over the same 
million lines repeatedly... -- you don't see that often. :)



Thank you,
 - Jay



> From: i...@google.com
> To: g...@integrable-solutions.net
> CC: jwakely@gmail.com; jay.kr...@cornell.edu; gcc@gcc.gnu.org
> Subject: Re: -fno-rtti in configure.ac breaks building go? (older g++, 
> -disable-bootstrap)
> Date: Sun, 20 May 2012 22:41:08 -0700
>
> Gabriel Dos Reis  writes:
>
> > On Mon, May 21, 2012 at 12:08 AM, Ian Lance Taylor  wrote:
> >> Gabriel Dos Reis  writes:
> >>
> >>> On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor  
> >>> wrote:
> >>>
>  To be clear, as far as I can see the Go frontend isn't doing anything
>  wrong or dubious.  It just happens to #include  when
>  it is available but  is not.  It looks like in gcc 4.0
>  you can not #include  when using -fno-rtti.
> 
>  We could work around this by changing gcc/configure.ac to check whether
>  that #include  works with -fno-rtti.  If that fails,
>  the Go frontend will next try .
> >>>
> >>> Is it unacceptable for the Go front-end to use the stage1 g++, especially
> >>> as we are moving toward switching to C++?
> >>
> >> The Go frontend does use the stage1 g++.
> >>
> >> I assume that this error can only occur when using --disable-bootstrap
> >> or when building Go in stage 1.  I don't see how this error could occur
> >> when building stages 2 or 3 of a bootstrap.
> >
> > OK. In that case, maybe make Go build only in stage2.
>
>
> By default, Go will only build in stages 2 and 3.
>
> Since the OP is apparently seeing Go build in stage 1, I assume that the
> OP is configuring with --disable-bootstrap or with
> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
> the way.)
>
> That is, normally, everything should be fine. But if you use unusual
> configure options you can definitely get into unusual cases. Ideally
> those cases should be made to work if possible. It's not very
> important, though.
>
> Ian
  

RE: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)

[Jay K]

[again as plain text, sorry, with edits]

I know gccgo is actually C++.
But why was no-rtti specified? Maybe that is for the other code, the C code?




But I see:

 > and using -fno-rtti saves some space in the generated compiler.

 

Is it worth it?

I guess you could configure with and without -fno-rtti + #include 
 and use

the combination that works? Kind of you said that, but alternatively, use 
unordered_hashmap either way,

but only -fno-rtti if it works? I do realize though there is another factor, it 
might be

interesting to use just map, for older compilers/libraries, since unordered is 
"new".



 
Thank you, sorry, I'm in a rush right now,
 - Jay
 





> From: i...@google.com
> To: jay.kr...@cornell.edu
> CC: g...@integrable-solutions.net; jwakely@gmail.com; gcc@gcc.gnu.org
> Subject: Re: -fno-rtti in configure.ac breaks building go? (older g++, 
> -disable-bootstrap)
> Date: Mon, 21 May 2012 06:48:08 -0700
> 
> Jay K  writes:
> 
> >> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
> >> the way.)
> >
> > I don't know why.
> > I'm getting them, at least via the list.
> 
> For every e-mail I send to jay.kr...@cornell.edu, I'm getting a bounce
> from cashub03.exchange.cornell.edu saying
> 
> - The following addresses had permanent fatal errors -
> jay.kr...@gmail.com
> (reason: 550 5.7.1 Unauthenticated email is not accepted from this domain. 
> r15si1037948qct.2)
> (expanded from: )
> 
> I would send you more details off-list but you probably wouldn't get
> them.
> 
> 
> > So I guess there is nothing to see here..move along..but..why the use of 
> > -fno-rtti?
> > It seems like a guess of "more work for less good"?
> 
> GCC does not use RTTI information, and using -fno-rtti saves some space
> in the generated compiler.
> 
> 
> > I can see maybe the opposite though.
> > Maybe the point is to avoid poor rtti implementations in old gcc bootstrap??
> > Or maybe the point was to compile C, really C code, with g++, and turn off 
> > "gratituitous"
> > C++ features that the code "doesn't even come near" (i.e. the bulk of gcc 
> > really is C
> > that is compatible with gcc, vs. the go frontend that is currently a rare 
> > case of "actual C++".
> > If that's the rationale, again, maybe the lines should just be removed. I 
> > understand this is
> > much to do about very little.
> 
> No, that's not it. The Go frontend is actual C++, but it doesn't use
> RTTI either. What you are running into is a bug in the GCC 4.0
> implementation of -fno-rtti.
> 
> 
> > I don't want to change a header and have make go through and build the 
> > compiler multiple times.
> > I have enough problems with incrementality building way too much..that I 
> > should look into..
> 
> The correct fix is the one I alluded to earlier: change the mainline
> gcc/configure.ac to test whether  works correctly
> when using -fno-rtti. That would detect the buggy GCC 4.0
> implementation, and avoid using  in that case.
> 
> Ian 

mkconfig.sh incrementality?

[Jay K]

At the bottom of mkconfig.sh in 4.6.2 and 4.7.0:


# Avoid changing the actual file if possible.
if [ -f $output ] && cmp ${output}T $output >/dev/null 2>&1; then
    echo $output is unchanged >&2
    rm -f ${output}T
else
    mv -f ${output}T $output
fi

# Touch a stamp file for Make's benefit.
rm -f cs-$output
echo timestamp > cs-$output



Shouldn't the timestamp > cs-$output only be a) mainly if the other file 
updated, by the mv and b) corner case, if it doesn't exist?
Maybe rm -rf by the mv, and echo if not exist?



 - Jay
  

constant that doesn't fit in 32bits in alpha.c

[Jay K]

gcc-4.7.0/gcc/config/alpha/alpha.c


  word1 = expand_and (DImode, word1, GEN_INT (0x0ffffff0), NULL);


That "big" constant isn't portable since it doesn't fit in 32bits.


1) append LL
or 2) break it up into an expression, like
  ((HOST_WIDE_INT)0x0fff) << 8) | 0x0fff0


or such.
#2 is more portable, i.e. to compilers with "__int64" and "0xFFi64" instead of 
"long long" and "LL".


#3) something involving a double-precision integer using two longs, as I 
believe gcc does elsewhere.


#2 Depending on HOST_WIDE_INT being portable suffices imho.



 - Jay
  

pretty-print.h warning: ‘__gcc_tdiag__’ is an unrecognized format function type

[Jay K]

./../gcc-4.7/gcc/pretty-print.h:324: warning: ‘__gcc_tdiag__’ is an 
unrecognized format function type
../../gcc-4.7/gcc/pretty-print.h:327: warning: ‘__gcc_tdiag__’ is an 
unrecognized format function type


 I get a lot of those.
Yes, I'm using -disable-bootstrap.
It is a warning, not an error.
Maybe it should be autoconf'ed away?
 Or just removed entirely if building with -disable-bootstrap? (kind of like 
how -O2 is removed)



 - Jay
  

RE: pretty-print.h warning: ‘__gcc_tdiag__’ is an unrecognized format function type

[Jay K]

ok. 1) my mistake for not reading the FAQ, sorry.
2) add to the FAQ, for the diligent folks who read it? Sorry, good point.
It's tough, you know, bootstrap compilers vary widely in quality. gcc 4.0 
pretty good, old vendor cc sometimes really bad, though they are falling out of 
support (e.g. HP-UX/HPPA K&R-only, Irix, etc.);

I gotta go,
 - Jay



> Date: Mon, 11 Jun 2012 20:27:16 +
> From: jos...@codesourcery.com
> To: lopeziba...@gmail.com
> CC: jay.kr...@cornell.edu; gcc@gcc.gnu.org
> Subject: Re: Re: pretty-print.h warning: ‘__gcc_tdiag__’ is an unrecognized 
> format function type
>
> On Mon, 11 Jun 2012, Manuel López-Ibáñez wrote:
>
> > http://gcc.gnu.org/wiki/FAQ#stage1warnings
> >
> > I really don't understand why first stage or --disable-bootstrap is
> > not using -w. (Probably, like most things in GCC, because nobody has
> > bothered to implement it.)
>
> If you are building a cross compiler (so not bootstrapped), having the
> warnings, even if noisy because the compiler used to build it isn't
> exactly the same version as the compiler being built, is a lot better than
> hiding them all. And if a file fails to build in stage 1 of a bootstrap,
> having the warnings, again even if noisy, helps identify the problem more
> than if only actual error messages are present (more generally, warnings
> from a changed file in stage 1 of a bootstrap give you an early indication
> of possible problems with a patch without needing to wait for a later
> stage for a more precise set).
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
  

tree-sra.c and BIT_FIELD_REF?

[Jay K]

Our front end is wierd.
The input is unusually low level, and so are the trees it produces.
I do have a hankering to fix that (or maybe just to output more portable C...)
But for now:
It doesn't use component_refs, and doesn't
define types much, but uses either
either (type*)(base + offset) or bitfield_ref(base, offset, size).


As such, it runs into occasional problems.
I have had to turn off various optimizations with e.g.:
 flag_tree_sra = false
in langhook_post_options.



Looking at this briefly, I think I see one of the problems.
tree-sra.c looks for component_refs to bitfields, but
it doesn't look for bitfield_refs. It should?


also, in fold-const:
  /* A bit-field-ref that referenced the full argument can be stripped.  */


should probably check that the other type is integral
and that the signedness matches.


 - Jay

RE: tree-sra.c and BIT_FIELD_REF?

[Jay K]

  > On Tue, Jun 12, 2012 at 03:57:44PM +0000, Jay K wrote:
  > > 
  > > Our front end is wierd.
  > > The input is unusually low level, and so are the trees it produces.
  > > I do have a hankering to fix that (or maybe just to output more portable 
C...)
  > > But for now:
  > > It doesn't use component_refs, and doesn't
  > > define types much, but uses either
  > > either (type*)(base + offset) or bitfield_ref(base, offset, size).
  > > 
  > > As such, it runs into occasional problems.
  > > I have had to turn off various optimizations with e.g.:
  > >  flag_tree_sra = false
  > > in langhook_post_options.
  > > 
  > > Looking at this briefly, I think I see one of the problems.
  > > tree-sra.c looks for component_refs to bitfields, but
  > > it doesn't look for bitfield_refs. It should?
  > 
  > I am not sure what you mean, if you search for the sting BIT_FIELD_REF
  > in tree-sra.c, you'll quickly find the places where we "look for" them
  > (or perhaps I should write look through them). The most important
  > ones are in functions build_access_from_expr_1 and especially
  > sra_modify_expr.
  > 
  > Having said that, Andrew Pinski has reported problems with SRA's
  > handling of BIT_FIELD_REF in another special setup, so perhaps you
  > have similar problems. Please have a look at the thread starting with
  > message: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg9.html
  > 
  > So far it however looks that, if we ever come across such problems on
  > trunk, we'll disable SRA for aggregate parts which are written to by a
  > BIT_FIELD_REF on a left hand side, mainly because we do not consider
  > them important for performance critical code.
  > 
  > Thanks,
  > 
  > Martin

 

  create_access is where I noticed it.   

 

 

  Yeah, I know my report is vague and crummy.  

  Maybe I should put together somesuch "hardcoded tree frontend" to demonstrate 
it.  

  I don't think the trees I'm thinking of are producible from C, unless maybe 
via a gcc extension?

  I'll look later..like..I wonder where BIT_FIELD_REF would be used at all in a 
normal frontend.  

   If I can find one, I'll maybe try to put together a test case for it. 

  We do use them for reads and writes.  

  Even for things like picking out exponent/mantissa from floats .. well, it 
used to.  

  I changed it to prefer *(type*)(base + offset) when either base or type is 
floating point.  

 

 

  Longer story:  

  I changed to use *(type*)(base + offset) for floating point because we used 
to make  

  everything addressable/volatile. Then all optimizations "worked" -- no 
internal compiler  

  errors, bus errors, etc., but of course the code quality stunk. Though better 
with bit_field_ref  

  than *(type*)(base + offset).  

  In removing the addressable/volatile, I then had to work through  

  the compiler errors, incorrect code, etc., disabling optimizations 
selectively,  

  changing our trees some.  

  I understand we generate weird trees, so I try not to complain too much.  

 

 

Thank you,

 - Jay

  

typos in http://gcc.gnu.org/wiki/CppConventions

[Jay K]

They clause client code taking the address 

 => cause

 

 

 

structs adn classes 
 => and   

problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)

[Jay K]

problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)


1) ENUM_BITFIELD is not portable. I've reported this before.


  It should be more like:  


  #ifdef __cplusplus  
  #define ENUM_BITFIELD(TYPE, NAME, SIZE) enum TYPE NAME : SIZE  
  #elif (GCC_VERSION > 2000)  
  #define ENUM_BITFIELD(TYPE, NAME, SIZE) __extension__ enum TYPE NAME : SIZE  
  #else  
  #define ENUM_BITFIELD(TYPE, NAME, SIZE) unsigned int NAME : SIZE  
  #endif


and then modify the uses to fit -- three parameters.


It is likely that in 4.8 this is moot, as the C++ case will be the only one 
remaining.


2) given:

int foo()
{
 gcc_unreachable();
}


Solaris cc/CC gives a warning or maybe an error.
It should be:


int foo(void)
{
 gcc_unreachable();
 return 0;
}


This occurs a few times e.g. in i386.md.


Despite me being uncertain between warnings and errors and cc and CC,
these do definitely show up as problems.
I've been building a few versions of gcc through the years from 4.2
and up (yeah, yeah, I know it goes back much further) with a variety
of host compilers, mostly a few versions of gcc/g++ but sometimes Solaris cc/CC,
maybe others, and I've had to patch these repeatedly. Again, today, in 4.7.


I do use -disable-bootstrap, to drastically cut build times.
It is possible that contributes to "the problem", but I also think these
are reasonable changes and -disable-bootstrap is really nice to use, it
saves a lot of time and these aren't awful ancient non-optimizing host 
compilers.



Thanks,
 - Jay

RE: problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)

[Jay K]

bitfield: sorry, maybe I didn't look closely enough here.
I had to patch it in 4.5, but maybe not in 4.7.
I had gotten warnings or errors about integers being truncated.
I'll look later.



gcc_unreachable: I don't think it is a bug, for a compiler
to not be gcc. That appears to be all it takes for gcc_unreachable
to be nothing special, just a function call.


/* Use gcc_unreachable() to mark unreachable locations (like an
   unreachable default case of a switch.  Do not use gcc_assert(0).  */
#if (GCC_VERSION >= 4005) && !ENABLE_ASSERT_CHECKING
#define gcc_unreachable() __builtin_unreachable()
#else
#define gcc_unreachable() (fancy_abort (__FILE__, __LINE__, __FUNCTION__))
#endif


/* Redefine abort to report an internal error w/o coredump, and
   reporting the location of the error in the source file.  */
extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)


#if (GCC_VERSION < 2007)
# define __attribute__(x)
#endif

#ifndef ATTRIBUTE_NORETURN
#define ATTRIBUTE_NORETURN __attribute__ ((__noreturn__))
#endif /* ATTRIBUTE_NORETURN */



 - Jay



> Date: Sat, 9 Feb 2013 23:41:24 -0800
> Subject: Re: problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
> From: pins...@gmail.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
>
> On Sat, Feb 9, 2013 at 3:49 PM, Jay K  wrote:
> > problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
> >
> >
> > 1) ENUM_BITFIELD is not portable. I've reported this before.
> >
> >
> > It should be more like:
> >
> >
> > #ifdef __cplusplus
> > #define ENUM_BITFIELD(TYPE, NAME, SIZE) enum TYPE NAME : SIZE
> > #elif (GCC_VERSION > 2000)
> > #define ENUM_BITFIELD(TYPE, NAME, SIZE) __extension__ enum TYPE NAME : SIZE
> > #else
> > #define ENUM_BITFIELD(TYPE, NAME, SIZE) unsigned int NAME : SIZE
> > #endif
>
>
> Could you explain why the current way is not correct?
>
> Which does:
> #ifdef __cplusplus
> #define ENUM_BITFIELD(TYPE) enum TYPE
> #elif (GCC_VERSION > 2000)
> #define ENUM_BITFIELD(TYPE) __extension__ enum TYPE
> #else
> #define ENUM_BITFIELD(TYPE) unsigned int
> #endif
>
> Which is no different from what you have above really.
>
>
> >
> >
> > and then modify the uses to fit -- three parameters.
> >
> >
> > It is likely that in 4.8 this is moot, as the C++ case will be the only one 
> > remaining.
> >
> >
> > 2) given:
> >
> > int foo()
> > {
> > gcc_unreachable();
> > }
> >
> >
> > Solaris cc/CC gives a warning or maybe an error.
>
> That is a bug with Oracle's compilers as nothing after gcc_unreachable
> is reachable
>
> > It should be:
> >
> >
> > int foo(void)
> > {
> > gcc_unreachable();
> > return 0;
> > }
> >
> >
> > This occurs a few times e.g. in i386.md.
> >
> >
> > Despite me being uncertain between warnings and errors and cc and CC,
> > these do definitely show up as problems.
> > I've been building a few versions of gcc through the years from 4.2
> > and up (yeah, yeah, I know it goes back much further) with a variety
> > of host compilers, mostly a few versions of gcc/g++ but sometimes Solaris 
> > cc/CC,
> > maybe others, and I've had to patch these repeatedly. Again, today, in 4.7.
> >
> >
> > I do use -disable-bootstrap, to drastically cut build times.
>
> Cut build times but depends on bugs in the compiler which compiles stage1.
>
>
> > It is possible that contributes to "the problem", but I also think these
> > are reasonable changes and -disable-bootstrap is really nice to use, it
> > saves a lot of time and these aren't awful ancient non-optimizing host 
> > compilers.
>
> Except some host compilers have bugs. That is the point of the
> bootstrap rather than the non-optimizing host compilers. As show
> above Oracle's compilers have bugs already.
>
> Thanks,
> Andrew Pinski   

Re: analyzer: implement five new warnings for misuse of POSIX

[Jay K via Gcc]

 > check for double "close" of a FD (CWE-1341).
 > check for read/write of a closed file descriptor 
 
 These sound good but kinda non general or incomplete to me. 
 I mean, isn't the "right" thing, to disallow passing 
 a closed fd to "almost any" function?  

 But I realize "almost any" is difficult to pin down. 
  fd = open(); 
  close(fd); 
  printf("%d", fd);  

is often ok (assuming nobody reads the output, string to int,
back to close/read/write). It is any path leading to,
a long list, like close, read, write, ioctl, send, recv, etc.
and I don't know if "path leading to" is possible to model here, haven't 
looked, sorry.

 - Jay