gcc-help needed

[anandulle]

i have added my own pass and i am trying to find out the number of variable
declarations in a C program the code is attached for your reference 
http://www.nabble.com/file/p24656019/gccwk09.c gccwk09.c i am getting an
error like this whats wrong kindly help me 


mainD.1181 = 0;
return D.1181;


Number of assignment statements:: 0



Total Number of assignment statements (including temp vars):: 1



total no of increment count :: 0


/home/ulle/gcc/native/cprog/pg1.c: In function ‘main’:
/home/ulle/gcc/native/cprog/pg1.c:7: internal compiler error: Segmentation
fault

-- 
View this message in context: 
http://www.nabble.com/gcc-help-needed-tp24656019p24656019.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: merging VTA: what does it take?

[Richard Guenther]

On Sat, Jul 25, 2009 at 1:19 AM, Alexandre Oliva wrote:
> So...  It's been a long journey, but I think I'm at a point in which,
> even though VTA is not completely finished, it's already enough of an
> improvement that it could go in, be useful and get wider testing.
>
> To the best of my knowledge, all of the concerns and objections that
> were raised have already been addressed: we have low memory and
> compile-time overhead in general, and we have significantly improved
> debug information.
>
> Besides all the data that Jakub has already posted, Mark Wielaard has
> done some Systemtap testing, comparing debug information for parameters
> of inlined functions using a pristine Fedora kernel vs results using a
> vta4.4 compiler to compile the same kernel sources.
>
> Out of 42249 inlined function parameters for which some debug
> information was emitted, GCC 4.4 emitted location information for only
> 280, whereas the backport of VTA to GCC 4.4 emitted location information
> for as many as 7544.
>
> The careful reader will note that 34705 parameters still don't get
> location information.  That's a lot.  No investigation has been done as
> to how many of them are indeed unavailable, and therefore couldn't
> possibly and shouldn't have got debug location/value information, but
> I'd be surprised if it's this many.  As I pointed out before, the code
> is not perfect, and there is certainly room for further improvements,
> but waiting for perfection will take too long ;-)
>
> Seriously, if VTA could be merged soonish, or at least accepted soon for
> a merge at a later date, Fedora would adopt it right away in its
> development tree, and then we'd get much broader testing.  So, what does
> it take to get it merged soonish, even if not enabled by default?

I didn't see the generic RTL parts getting a single review yet and I'd
like you to re-post the tree pieces (you can do it as a single patch), just
so I can double-check and ack them.  I think we have a sort-of consensus
that we would like to have VTA in 4.5.

For the merge itself there's still this ChangeLog thing that needs to be done
and checking that the primary archs (or at least the majority of them)
pass bootstrap and testing (not that I expect any target specific problems).

Oh, and of course approval is missing (you may get pieces from me, but
I don't feel comfortable to review and approve RTL infrastructure changes).

Thanks,
Richard.

RE: As-if Infinitely Ranged Integer Model

[Robert Seacord]

Joseph,

Comments below.

Then you are building on the runtime-constraint mechanism and rsize_t of TR 
24731-1.  TR 24731-1 is considered useless in the Linux world, and not 
implemented in the GNU C Library, and with good reason; see 
.  If you want 
general adoption in the Linux world you will need to extract those pieces from 
the pile of useless, duplicative and prior-art-ignoring functions that is most 
of TR 24731-1 and demonstrate that despite their background the 
runtime-constraints and rsize_t have more general utility.

[rcs] If it makes you feel any better, these were both inventions of WG14.

I believe the best defense of rsize_t is given by Randy Meyers in his paper 
"Limited size_t" WG14 N1080 Sept 27, 2004. 

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1080.pdf

The name rsize_t did not fall out until the Fall 2004 Redmond meeting:

http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1083.pdf

We have a recommendation in The CERT C Secure Coding Standard which states:

INT01-C. Use rsize_t or size_t for all integer values representing the size of 
an object

https://www.securecoding.cert.org/confluence/x/PwE

-- 

CERT also recommends the use of runtime-constraint mechanism when calling 
functions defined by TR24731-1:

ERR03-C. Use runtime-constraint handlers when calling functions defined by 
TR24731-1

https://www.securecoding.cert.org/confluence/x/5wD3 

Of course, you probably don't care about this if you don't want to implement 
TR24731-1.  However, I think this runtime-constraint mechanism provides an 
important, standard mechanism for handling errors in C language programs that 
up until now has been lacking. 

Again, if it makes you feel better, this API was invented by Bill Plauger (and 
adopted by the group) at an editorial group meeting for the TR. Currently 
available versions of Microsoft Visual Studio do not support the same interface 
defined by TR24731-1 for installing runtime constraint handlers. Visual Studio 
calls these functions "invalid parameter handlers," and they are installed by 
calling the _set_invalid_parameter_handler() function. The signature of the 
handler is also significantly different. 

rCs

Re: Bootstrap failure configuring in-tree gmp in mainline

[Ralf Wildenhues]

* Bradley Lucier wrote on Wed, Jul 15, 2009 at 10:37:56PM CEST:
> After configuring
> 
> Target: x86_64-unknown-linux-gnu
> gcc version 4.5.0 20090715 (experimental) [trunk revision 149654] (GCC) 
> 
> with
> 
> ../../mainline/configure --enable-checking=release 
> --prefix=/pkgs/gcc-mainline-mem-stats --enable-languages=c 
> --enable-gather-detailed-mem-stats
> 
> I get the bootstrap error:
> 
> Configuring stage 2 in ./gmp
> < stuff omitted>
> checking how to run the C++ preprocessor... /lib/cpp
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details.
> make[2]: *** [configure-stage2-gmp] Error 1
> make[2]: Leaving directory `/home/lucier/programs/gcc/objdirs/mainline'
> make[1]: *** [stage2-bubble] Error 2
> make[1]: Leaving directory `/home/lucier/programs/gcc/objdirs/mainline'
> make: *** [bootstrap] Error 2
> 
> This is using an in-tree gmp 4.3.0, gmp/config.log reports:
> 
> configure:11030: checking how to run the C++ preprocessor
> configure:11061:  /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++ 
> -B/home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/ 
> -B/pkgs/gcc-mainline-mem-stats/x86_64-unknown-linux-gnu/bin/ -nostdinc++ 
> -I/home/lucier/programs/gcc/objdirs/mainline/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
>  
> -I/home/lucier/programs/gcc/objdirs/mainline/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
>  
> -I/home/lucier/programs/gcc/objdirs/mainline/../../mainline/libstdc++-v3/libsupc++
>  
> -L/home/lucier/programs/gcc/objdirs/mainline/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
>  -E -DNO_ASM conftest.cc
> /home/lucier/programs/gcc/mainline/gmp/configure: line 11062: 
> /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++: No such file or 
> directory
> 
> configure:11061: /lib/cpp -DNO_ASM conftest.cc
> cpp: error trying to exec 'cc1plus': execvp: No such file or directory
> 
> Am i missing something? 

Does /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++ exist,
and if yes, is it a functioning executable?

If it doesn't exist, that looks like the toplevel logic for which
languages to build still has a loop hole for --enable-languages=c,
either not properly enabling the C++ compiler for stage 1, or wrongly
overriding CXX, CXX_FOR_BUILD in toplevel Makefile.tpl to point to
nonexistent previous-stage C++ compiler.  I don't know which is the
desired one.

BTW, what's the last , and why does your /lib/cpp try to
spawn cc1plus?

Cheers,
Ralf

Re: Gimple Pass

[pms]

Hi Nathan
   I looked into tree.def, I added a case in the new gimple pass to count
the number of integer variables in the c code. the following is the piece of
code.
Here, the first case is working, but I'm not getting the second one. can u
pls help in this regard.
How to trace thru the other codes & there usage
switch (TREE_CODE(stmt)){
case GIMPLE_MODIFY_STMT:
 
lval=GIMPLE_STMT_OPERAND(stmt,0);
rval=GIMPLE_STMT_OPERAND(stmt,1);
if(TREE_CODE(lval) == VAR_DECL) {
if(!DECL_ARTIFICIAL(lval)){

//print_generic_stmt(stderr,stmt,0);
numassigns++;
}   
totalassigns++; 
}
break;
case DECL:
if(TREE_CODE(stmt) == VAR_DECL){

if(TREE_CODE(TREE_TYPE(stmt))==INTEGER_TYPE){
intvar++;
}
}
  break;


Nathan Froyd-2 wrote:
> 
> On Fri, Jul 24, 2009 at 05:20:16AM -0700, pms wrote:
>>   But I want to know what are the TREE_CODEs for other remaing constructs
>> viz declration stmt, conditions, count for constants  and how to use them
>> in
>> the gimple pass. Can anybody help in this regard
> 
> The names are defined in tree.def.
> 
> -Nathan
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Gimple-Pass-tp24643577p24657080.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Gimple Pass

[Richard Guenther]

On Sat, Jul 25, 2009 at 1:28 PM, pms wrote:
>
> Hi Nathan
>   I looked into tree.def, I added a case in the new gimple pass to count
> the number of integer variables in the c code. the following is the piece of
> code.
> Here, the first case is working, but I'm not getting the second one. can u
> pls help in this regard.
> How to trace thru the other codes & there usage

VAR_DECLs do not appear as statements.  You should look at existing
code in GCC and learn from it.  Please also refer to your supervisor
first before asking such basic questions in this forum.

Thanks,
Richard.

> switch (TREE_CODE(stmt)){
>                        case GIMPLE_MODIFY_STMT:
>                                lval=GIMPLE_STMT_OPERAND(stmt,0);
>                                rval=GIMPLE_STMT_OPERAND(stmt,1);
>                                if(TREE_CODE(lval) == VAR_DECL) {
>                                        if(!DECL_ARTIFICIAL(lval)){
>                                                
> //print_generic_stmt(stderr,stmt,0);
>                                                numassigns++;
>                                        }
>                                        totalassigns++;
>                                }
>                                break;
>                        case DECL:
>                                if(TREE_CODE(stmt) == VAR_DECL){
>                                        
> if(TREE_CODE(TREE_TYPE(stmt))==INTEGER_TYPE){
>                                                intvar++;
>                                        }
>                                }
>                              break;
>
>
> Nathan Froyd-2 wrote:
>>
>> On Fri, Jul 24, 2009 at 05:20:16AM -0700, pms wrote:
>>>   But I want to know what are the TREE_CODEs for other remaing constructs
>>> viz declration stmt, conditions, count for constants  and how to use them
>>> in
>>> the gimple pass. Can anybody help in this regard
>>
>> The names are defined in tree.def.
>>
>> -Nathan
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/Gimple-Pass-tp24643577p24657080.html
> Sent from the gcc - Dev mailing list archive at Nabble.com.
>
>

Re: gcc-help needed

[Dave Korn]

anandulle wrote:

> total no of increment count :: 0
> 
> 
> /home/ulle/gcc/native/cprog/pg1.c: In function ‘main’:
> /home/ulle/gcc/native/cprog/pg1.c:7: internal compiler error: Segmentation
> fault

  When you've been adding code to GCC and you see a seg fault crop up like
this, it usually means you've done something bad with a pointer.  (GCC has
internal handlers that intercept things like NULL dereferences and convert
them into the internal compiler error message you see above).

  You could run the compiler again using "-v" to see the command-line passed
to cc1, and then run that under gdb, setting a breakpoint on "internal_error",
and see where it gets called from.  But I can work it out just from seeing the
output and reading your code: it crashed just after you print the increment
count, so what happens after that?

  if(flag_pass_gccwk09){
 fprintf(dump_file,"\n\nNumber of assignment statements::
%d\n\n",numassigns);
 fprintf("\n\ntotal no of init expr :: %d\n\n",varexpr);
 fprintf(dump_file,"\n\nTotal Number of assignment statements
(including temp vars):: %d\n\n",totalassigns);
  }

  Look at the middle fprintf: you forgot the 'dump_file' argument, so it's
trying to treat the format string as a FILE* pointer!  Argh!  (Are you
building with --disable-werror?  I would have expected this to cause a warning
and make the compiler build fail.)

cheers,
  DaveK

Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

[Dave Korn]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857


  There's a clash between the FOPEN macro used by Ada (defined in adaint.h to
hide 32/64-bit file i/o selection) and an identically named macro defined in
newlib's sys/_default_fcntl.h.

  Since they're only used in a few places, I think that probably the better
solution would be to stick a prefix in front of Ada's macros rather than
#undef the one from the newlib header, so I'm about to start work on a patch
that adds a "_GNAT_" prefix to each of the definitions in adaint.h, and their
respective uses in adaint.c and cstreams.c.

  If any Ada maintainers would prefer a different prefix name, please drop me
a line or post to PR40857.  Thanks.

cheers,
  DaveK

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

[Robert Dewar]

Dave Korn wrote:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857


  There's a clash between the FOPEN macro used by Ada (defined in adaint.h to
hide 32/64-bit file i/o selection) and an identically named macro defined in
newlib's sys/_default_fcntl.h.

  Since they're only used in a few places, I think that probably the better
solution would be to stick a prefix in front of Ada's macros rather than
#undef the one from the newlib header, so I'm about to start work on a patch
that adds a "_GNAT_" prefix to each of the definitions in adaint.h, and their
respective uses in adaint.c and cstreams.c.

  If any Ada maintainers would prefer a different prefix name, please drop me
a line or post to PR40857.  Thanks.


__gnat_ seems like it would be more consistent with the other 
definitions in adaint.h, but it's not critical certainly.


cheers,
  DaveK

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

[Robert Dewar]

Dave Korn wrote:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857


  There's a clash between the FOPEN macro used by Ada (defined in adaint.h to
hide 32/64-bit file i/o selection) and an identically named macro defined in
newlib's sys/_default_fcntl.h.

  Since they're only used in a few places, I think that probably the better
solution would be to stick a prefix in front of Ada's macros rather than
#undef the one from the newlib header, so I'm about to start work on a patch
that adds a "_GNAT_" prefix to each of the definitions in adaint.h, and their
respective uses in adaint.c and cstreams.c.

  If any Ada maintainers would prefer a different prefix name, please drop me
a line or post to PR40857.  Thanks.


Actually you do not want to use __gnat_ now that I look at it, that 
would cause other clashes, so I guess _GNAT_ is as good as anything.


cheers,
  DaveK

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

[Dave Korn]

Robert Dewar wrote:
> 
> __gnat_ seems like it would be more consistent with the other
> definitions in adaint.h, but it's not critical certainly.

  Well, but they're macros rather than functions, and I personally don't like
to hide the difference.  I ended up doing this because it makes them look like
a lot of the other type-independence macros we have in the code.

  Ah, and I see you also had an after-thought in a second reply.  I'll respin
this if you think it's horribly ugly, otherwise I'll send it to -patches with
a changelog once the build has finished.

cheers,
  DaveK
Index: adaint.c
===
--- adaint.c	(revision 149338)
+++ adaint.c	(working copy)
@@ -520,7 +520,7 @@ __gnat_try_lock (char *dir, char *file)
 {
   char full_path[256];
   char temp_file[256];
-  STRUCT_STAT stat_result;
+  _GNAT_STRUCT_STAT_ stat_result;
   int fd;
 
   sprintf (full_path, "%s%c%s", dir, DIR_SEPARATOR, file);
@@ -775,7 +775,7 @@ __gnat_fopen (char *path, char *mode, int encoding
 #elif defined (VMS)
   return decc$fopen (path, mode);
 #else
-  return FOPEN (path, mode);
+  return _GNAT_FOPEN_ (path, mode);
 #endif
 }
 
@@ -1019,9 +1019,9 @@ long
 __gnat_file_length (int fd)
 {
   int ret;
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
-  ret = FSTAT (fd, &statbuf);
+  ret = _GNAT_FSTAT_ (fd, &statbuf);
   if (ret || !S_ISREG (statbuf.st_mode))
 return 0;
 
@@ -1038,7 +1038,7 @@ long
 __gnat_named_file_length (char *name)
 {
   int ret;
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
   ret = __gnat_stat (name, &statbuf);
   if (ret || !S_ISREG (statbuf.st_mode))
@@ -1269,7 +1269,7 @@ __gnat_file_time_name (char *name)
 }
   return (OS_Time) ret;
 #else
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
   if (__gnat_stat (name, &statbuf) != 0) {
  return (OS_Time)-1;
   } else {
@@ -1361,9 +1361,9 @@ __gnat_file_time_fd (int fd)
   return (OS_Time) ret;
 
 #else
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
-  if (FSTAT (fd, &statbuf) != 0) {
+  if (_GNAT_FSTAT_ (fd, &statbuf) != 0) {
  return (OS_Time) -1;
   } else {
 #ifdef VMS
@@ -1651,7 +1651,7 @@ __gnat_get_libraries_from_registry (void)
 }
 
 int
-__gnat_stat (char *name, STRUCT_STAT *statbuf)
+__gnat_stat (char *name, _GNAT_STRUCT_STAT_ *statbuf)
 {
 #ifdef __MINGW32__
   /* Under Windows the directory name for the stat function must not be
@@ -1683,7 +1683,7 @@ int
   return _tstat (wname, (struct _stat *)statbuf);
 
 #else
-  return STAT (name, statbuf);
+  return _GNAT_STAT_ (name, statbuf);
 #endif
 }
 
@@ -1699,7 +1699,7 @@ __gnat_file_exists (char *name)
   S2WSC (wname, name, GNAT_MAX_PATH_LEN + 2);
   return GetFileAttributes (wname) != INVALID_FILE_ATTRIBUTES;
 #else
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
   return !__gnat_stat (name, &statbuf);
 #endif
@@ -1744,7 +1744,7 @@ int
 __gnat_is_regular_file (char *name)
 {
   int ret;
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
   ret = __gnat_stat (name, &statbuf);
   return (!ret && S_ISREG (statbuf.st_mode));
@@ -1754,7 +1754,7 @@ int
 __gnat_is_directory (char *name)
 {
   int ret;
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
   ret = __gnat_stat (name, &statbuf);
   return (!ret && S_ISDIR (statbuf.st_mode));
@@ -1972,9 +1972,9 @@ __gnat_is_readable_file (char *name)
 #else
   int ret;
   int mode;
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
-  ret = STAT (name, &statbuf);
+  ret = _GNAT_STAT_ (name, &statbuf);
   mode = statbuf.st_mode & S_IRUSR;
   return (!ret && mode);
 #endif
@@ -2004,9 +2004,9 @@ __gnat_is_writable_file (char *name)
 #else
   int ret;
   int mode;
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
-  ret = STAT (name, &statbuf);
+  ret = _GNAT_STAT_ (name, &statbuf);
   mode = statbuf.st_mode & S_IWUSR;
   return (!ret && mode);
 #endif
@@ -2034,9 +2034,9 @@ __gnat_is_executable_file (char *name)
 #else
   int ret;
   int mode;
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
-  ret = STAT (name, &statbuf);
+  ret = _GNAT_STAT_ (name, &statbuf);
   mode = statbuf.st_mode & S_IXUSR;
   return (!ret && mode);
 #endif
@@ -2056,9 +2056,9 @@ __gnat_set_writable (char *name)
   SetFileAttributes
 (wname, GetFileAttributes (wname) & ~FILE_ATTRIBUTE_READONLY);
 #elif ! defined (__vxworks) && ! defined(__nucleus__)
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
-  if (STAT (name, &statbuf) == 0)
+  if (_GNAT_STAT_ (name, &statbuf) == 0)
 {
   statbuf.st_mode = statbuf.st_mode | S_IWUSR;
   chmod (name, statbuf.st_mode);
@@ -2078,9 +2078,9 @@ __gnat_set_executable (char *name)
 __gnat_set_OWNER_ACL (wname, GRANT_ACCESS, FILE_GENERIC_EXECUTE);
 
 #elif ! defined (__vxworks) && ! defined(__nucleus__)
-  STRUCT_STAT statbuf;
+  _GNAT_STRUCT_STAT_ statbuf;
 
-  if (STAT (name, &statbuf) == 0)
+  if (_GNAT_STAT_ (name, &statbuf) == 0)
 {
   statbuf.st_mode = statbuf.s

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

[Arnaud Charlet]

>   Ah, and I see you also had an after-thought in a second reply.  I'll respin
> this if you think it's horribly ugly, otherwise I'll send it to -patches with
> a changelog once the build has finished.

It is indeed ugly.

I'd use GNAT_STRUCT_STAT and GNAT_FOPEN instead.

Since these are macros, I don't see the need to add trailing or leading
underscores.

Please post to gcc-patches when ready, I'll review it officially there.

Arno

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

[Laurent GUERBY]

Isn't it the same as

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578

Were I suggested GNAT_FOPEN (and you commented too)?

Sincerely,

Laurent

On Sat, 2009-07-25 at 16:30 +0100, Dave Korn wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857
> 
> 
>   There's a clash between the FOPEN macro used by Ada (defined in adaint.h to
> hide 32/64-bit file i/o selection) and an identically named macro defined in
> newlib's sys/_default_fcntl.h.
> 
>   Since they're only used in a few places, I think that probably the better
> solution would be to stick a prefix in front of Ada's macros rather than
> #undef the one from the newlib header, so I'm about to start work on a patch
> that adds a "_GNAT_" prefix to each of the definitions in adaint.h, and their
> respective uses in adaint.c and cstreams.c.
> 
>   If any Ada maintainers would prefer a different prefix name, please drop me
> a line or post to PR40857.  Thanks.
> 
> cheers,
>   DaveK
> 
> 
> 

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

[Robert Dewar]

Arnaud Charlet wrote:

  Ah, and I see you also had an after-thought in a second reply.  I'll respin
this if you think it's horribly ugly, otherwise I'll send it to -patches with
a changelog once the build has finished.


It is indeed ugly.

I'd use GNAT_STRUCT_STAT and GNAT_FOPEN instead.


That indeed seems better


Since these are macros, I don't see the need to add trailing or leading
underscores.

Please post to gcc-patches when ready, I'll review it officially there.

Arno

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

[Dave Korn]

Laurent GUERBY wrote:
> Isn't it the same as
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
> 
> Were I suggested GNAT_FOPEN (and you commented too)?

  Oh, thanks for the reminder.  Yes, it is, so I marked the new one as a dup
and took the assignment of the first one.  I'll respin the patch as requested
and post to -patches in a little while.  Thanks all for advice.

cheers,
  DaveK

Re: Bootstrap failure configuring in-tree gmp in mainline

[Bradley Lucier]

Thanks for your reply.

On Jul 25, 2009, at 7:18 AM, Ralf Wildenhues wrote:


Does /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++ exist,


No.


and if yes, is it a functioning executable?

If it doesn't exist, that looks like the toplevel logic for which
languages to build still has a loop hole for --enable-languages=c,
either not properly enabling the C++ compiler for stage 1, or wrongly
overriding CXX, CXX_FOR_BUILD in toplevel Makefile.tpl to point to
nonexistent previous-stage C++ compiler.  I don't know which is the
desired one.

BTW, what's the last , and why does your /lib/cpp  
try to

spawn cc1plus?


I put gmp/config.log at

http://www.math.purdue.edu/~lucier/bugzilla/10/gmp-config.log

and the build log (which is a bit confusing, I did a "make -j 6  
bootstrap > build.log" and then "make bootstrap >>& build.log" (in  
tcsh) to get a clearer message of the error at the end of the log) at


http://www.math.purdue.edu/~lucier/bugzilla/10/build.log

I tried building gcc like this on another machine, and it gets more  
confusing, at least to me.  When I put gmp-4.2.4 or gmp-4.3.0 in-tree  
on RHEL 5 with


leibniz-4% uname -a
Linux leibniz.math.purdue.edu 2.6.18-128.1.16.el5xen #1 SMP Fri Jun  
26 11:10:46 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux


it works; when I put either in-tree on Ubuntu 9.04 with

heine:~/programs/gcc/objdirs/mainline> uname -a
Linux heine.math.purdue.edu 2.6.28-13-generic #45-Ubuntu SMP Tue Jun  
30 22:12:12 UTC 2009 x86_64 GNU/Linux


it fails.

Brad

Re: Bootstrap failure configuring in-tree gmp in mainline

[Paolo Bonzini]

Am i missing something?


No, it is a bug due to the build-with-C++ patches.  Please file a PR 
and, in the meanwhile, try --enable-stage1-languages=c,c++ or 
--enable-build-with-cxx.


Thanks!

Paolo

Re: Bootstrap failure configuring in-tree gmp in mainline

[Bradley Lucier]

On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote:


Am i missing something?


No, it is a bug due to the build-with-C++ patches.  Please file a  
PR and, in the meanwhile, try --enable-stage1-languages=c,c++


That seemed to work, thanks, bootstrap has gotten past my old problem.


or --enable-build-with-cxx.


This fails with


Configuring stage 1 in ./libcpp

checking dependency style of g++... none
configure: error: no usable dependency style found
make[2]: *** [configure-stage1-libcpp] Error 1
make[2]: Leaving directory `/home/lucier/programs/gcc/objdirs/ 
mainline'

make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/lucier/programs/gcc/objdirs/ 
mainline'

make: *** [bootstrap] Error 2



Brad

Re: Bootstrap failure configuring in-tree gmp in mainline

[Bradley Lucier]

On Jul 25, 2009, at 2:16 PM, Bradley Lucier wrote:




On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote:


Am i missing something?


No, it is a bug due to the build-with-C++ patches.  Please file a  
PR and, in the meanwhile, try --enable-stage1-languages=c,c++


That seemed to work, thanks, bootstrap has gotten past my old problem.


Ah, I was too quick, it failed again at the next bootstrap stage.

Re: Bootstrap failure configuring in-tree gmp in mainline

[Paolo Bonzini]

Am i missing something?


No, it is a bug due to the build-with-C++ patches. Please file a PR
and, in the meanwhile, try --enable-stage1-languages=c,c++


That seemed to work, thanks, bootstrap has gotten past my old problem.


Ah, I was too quick, it failed again at the next bootstrap stage.


Ah sorry I didn't understand you were doing --enable-languages=c.  You 
need to specify c++ there too.


Paolo

Compiling programs licensed under the GPL version 2 with GCC 4.4

[Florian Weimer]

Kalle Olavi Niemitalo discovered that as an operating system vendor,
you are not allowed to distribute GPL version 2 programs if they are
compiled with GCC 4.4.  The run-time library is GPL version 3 or
later, which is incompatible with GPL version 2, so it is not
permitted to link this with the GPLv2-only program and distribute the
result.  (Previous discussions have centered on infringing GCC's
license, so this is different.)  An operating system vendor cannot
make use of the system library exception in the GPL version 2; this
part is quite similar to the OpenSSL and former Qt situation.

According to Kalle, this is [gnu.org #433709] at the FSF.

What shall we do about it?  Any solution without support from the FSF
will result in circumventing the restrictions imposed by the new GCC
library exception.

Re: Failure in a complete build of current gcc snapshot

[Angelo Graziosi]

OK, it seems that this failure happens *only* on Cygwin: I have tried on 
GNU/Linux Kubuntu 8.04 and it works...


For what I have understood, this failure remembers, in some manner, what 
is discussed in this thread [1], and beside this...


Dave,

...are the files with an '*' in their names, like libstdc++*-gdb.py, 
allowed on Cygwin?



Cheers,
   Angelo.


---
[1] http://gcc.gnu.org/ml/gcc/2009-07/msg00443.html



Angelo Graziosi ha scritto:

Trying to build gcc-4.5-20090723 on Cygwin 1.5, configuring with:

${gcc_dir}/configure --prefix="${prefix_dir}" \
--exec-prefix="${eprefix_dir}" \
--sysconfdir="${sysconf_dir}" \
--libdir="${lib_dir}" \
--libexecdir="${libexec_dir}" \
--mandir="${man_dir}" \
--infodir="${info_dir}" \
--program-suffix="${suffix}" \
--enable-bootstrap \
--enable-checking=release \
--enable-decimal-float=bid \
--enable-languages=c,c++,fortran \
--enable-libgomp \
--enable-libssp \
--enable-nls \
--enable-threads=posix \
--enable-version-specific-runtime-libs \
--disable-fixed-point \
--disable-libmudflap \
--disable-shared \
--disable-sjlj-exceptions \
--disable-win32-registry \
--with-arch=i686 \
--with-dwarf2 \
--with-system-zlib \
--with-tune=generic \
--without-included-gettext \
--without-x,

after a successful 'make -j4', it fails in:

   make -j4 DESTDIR=${dest_dir} install

with:

[...]
make[4]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/gfortran/share/gcc-4.5.0/python" || mkdir -p -- 
"/tmp/inst/usr/local/gfortran/share/gcc-4.5.0/python"
/bin/sh: line 0: cd: /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0: 
No such file or directory
 /usr/bin/install -c -m 644 gdb.py 
/tmp/inst/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/libstdc++*-gdb.py
/usr/bin/install: impossibile creare il file normale 
`/tmp/inst/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/libstdc++*-gdb.py': 
No such file or directory

make[4]: *** [install-data-local] Error 1
make[4]: *** Waiting for unfinished jobs
 /tmp/gcc-4.5-20090723/install-sh -c -m 644 
'/tmp/gcc-4.5-20090723/libstdc++-v3/python/libstdcxx/v6/printers.py' 
'/tmp/inst/usr/local/gfortran/share/gcc-4.5.0/python/libstdcxx/v6/printers.py' 

 /tmp/gcc-4.5-20090723/install-sh -c -m 644 
'/tmp/gcc-4.5-20090723/libstdc++-v3/python/libstdcxx/v6/__init__.py' 
'/tmp/inst/usr/local/gfortran/share/gcc-4.5.0/python/libstdcxx/v6/__init__.py' 

 /tmp/gcc-4.5-20090723/install-sh -c -m 644 
'/tmp/gcc-4.5-20090723/libstdc++-v3/python/libstdcxx/__init__.py' 
'/tmp/inst/usr/local/gfortran/share/gcc-4.5.0/python/libstdcxx/__init__.py'

make[4]: Leaving directory `/tmp/build/i686-pc-cygwin/libstdc++-v3/python'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/tmp/build/i686-pc-cygwin/libstdc++-v3/python'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/tmp/build/i686-pc-cygwin/libstdc++-v3'
make[1]: *** [install-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/tmp/build'
make: *** [install] Error 2

Could this be related to the usage of DESTDIR? (Even if Bug #40286 [1]
seems to be fixed...)

Cheers,
   Angelo.

---
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40286

Re: Failure in a complete build of current gcc snapshot

[Dave Korn]

Angelo Graziosi wrote:

> 
> ...are the files with an '*' in their names, like libstdc++*-gdb.py,
> allowed on Cygwin?

  No, it's a glob match, the makefile expects there to be something to match
that pattern but there isn't so the shell returns it verbatim instead of
expanding it.  The reason why nothing matches is probably DESTDIR-related but
it could be connected to use of -j.

>> make[4]: Nothing to be done for `install-exec-am'.
>> test -z "/usr/local/gfortran/share/gcc-4.5.0/python" || mkdir -p --
>> "/tmp/inst/usr/local/gfortran/share/gcc-4.5.0/python"
>> /bin/sh: line 0: cd: /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0:
>> No such file or directory

  Notice here how it tests for the real install dir, then if it doesn't exist
it creates the DESTDIR-prefixed version, then it tries to cd into the real one
and fails.  That's definitely a bug there.

cheers,
  DaveK

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Joe Buck]

On Sat, Jul 25, 2009 at 01:53:40PM -0700, Florian Weimer wrote:
> Kalle Olavi Niemitalo discovered that as an operating system vendor,
> you are not allowed to distribute GPL version 2 programs if they are
> compiled with GCC 4.4.  The run-time library is GPL version 3 or
> later, which is incompatible with GPL version 2, so it is not
> permitted to link this with the GPLv2-only program and distribute the
> result. 

That's incorrect.  The runtime library is GPLv3 or later, but with an
*exception* that permits linking not only with GPLv2 programs, but
also with proprietary programs.

The relevant document is the GCC Runtime Library Exception.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Florian Weimer]

* Joe Buck:

> On Sat, Jul 25, 2009 at 01:53:40PM -0700, Florian Weimer wrote:
>> Kalle Olavi Niemitalo discovered that as an operating system vendor,
>> you are not allowed to distribute GPL version 2 programs if they are
>> compiled with GCC 4.4.  The run-time library is GPL version 3 or
>> later, which is incompatible with GPL version 2, so it is not
>> permitted to link this with the GPLv2-only program and distribute the
>> result. 
>
> That's incorrect.  The runtime library is GPLv3 or later, but with an
> *exception* that permits linking not only with GPLv2 programs, but
> also with proprietary programs.

Eh, this exception doesn't change that the GPLv2 program perceives the
GPLv3 as incompatible.  Why would it?

I can't take my own proprietary library, give permission to link it
with GPLv2 programs, link it with a GPLv2 program, and distribute the
result.  The GPLv2 license on the program does not permit this.  And
as far as the GPLv2 is concerned, the GPLv3 is like a proprietary
license because it has got additional restrictions.