Re: Phase 1 of gcc-in-cxx now complete

[Ian Lance Taylor]

Matt  writes:

>> * Develop some trial patches which require C++, e.g., convert VEC to
>>  std::vector.
>
> Do you have any ideas for the easiest starting points? Is there
> anywhere that is decently self-contained, or will if have to be a big
> bang?

Thanks for your interest.

I think the one I mentioned--converting VEC to std::vector--is a good
starting point.  This is the interface in vec.h.

Another easy starting point would be converting uses of htab_t to type
safe C++ hash tables, e.g., std::tr1:;unordered_map.  Here portability
suggests the ability to switch to different hash table implementations;
see gold/gold.h in the GNU binutils for one way to approach that.

Another easy starting point is finding calls to qsort and converting
them to std::sort, which typically leads to code which is larger but
runs faster.

Longer term, we know that memory usage is an issue in gcc.  In the old
obstack days, we had a range of obstacks with different lifespans, so we
could create RTL with a temporary lifetime which was given a longer
lifetime when needed.  We got away from that because we spent far too
much time chasing bugs in which RTL should have been saved to a longer
lifetime but wasn't.  However, that model should permit us to run with
significantly less memory, which would translate to less compile time.
I think we might be able to do it by implementing a custom allocator,
such as a pool allocator which permits allocating different sizes of
memory, and never frees memory.  Then the tree class could take an
allocator as a template parameter.  Then we would provide convertors
which copied the tree class to a different allocation style.  Then, for
example, fold-const.c could use a temporary pool which lived only for
the length of the call to fold.  If it returned a new value, the
convertor would force a copy out of the temporary pool.  If this works
out, we can use type safety to enforce memory discipline, use
significantly less memory during compilation, and take a big step toward
getting rid of the garbage collector.

Ian

Re: Failure building current 4.5 snapshot on Cygwin

[Seiji Kachi]

Kai Tietz wrote:

No, this bug appeared on all windows pe-coff targets. A fix for this
is already checked in yesterday on binutils. Could you try it with the
current binutils head version?

Cheers,
Kai



I solved this failure with binutils-2.19.51.

Thank you.

Seiji

Re: Phase 1 of gcc-in-cxx now complete

[Matt]

* Develop some trial patches which require C++, e.g., convert VEC to
 std::vector.


Do you have any ideas for the easiest starting points? Is there anywhere 
that is decently self-contained, or will if have to be a big bang?


I'd love to see this happen so there's more exercising of template 
expansion during the profiledbootstrap. If I can get pointed in the right 
direction, I can probably produce a patch within the next week.


Thanks for this work and adding all the extra warnings!

--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Ian Lance Taylor]

Arnaud Charlet  writes:

>> Switching gnatbind to generate Ada if there's nothing against
>> it might be a better solution since stage1 uses the system gnatbind, so
>> a patch to current gnatbind will not help (unless we push it to branches
>> and tell user to install a fairly recent gnatbind first).
>
> This does create a bootstrap incompatibility/issue indeed, interesting.
> Yet another alternative would be to use a C compiler to compile the binder
> generated file during bootstrap.

Yes, I think that either compiling with a C compiler, or generating Ada
bindings, would be the best approach here.

Ian

Re: unsigned integer wrap 'trap'.

[Ian Lance Taylor]

samboy  writes:

> I have a storage application to which I can record or retrieve files. Its
> multi-process C/C++ compiled 
> to run on the SPARC platform. The problem is the maximum file size which can
> be stored is 4GB due to 
> the size being internally conveyed using an unsigned integer. I need to
> extend the range so it accepts
> much larger files i.e. convert all uints to long longs. The approach at
> first was to work through the code 
> line-by-line to locate and upsize all variables as required. The problem is
> there's almost a million lines of
> code and no guarantee every instance of filesize usage will be located &
> upsized. Another more elegant
> approach which came to mind was to somehow 'trap' the occurrence of
> *unsigned* integer overflow...or
> should that be wrapping - yes I know its completely acceptable behaviour. If
> I could get gcc to do this 
> for me I could simply run a full suite of end-to-end functional testing then
> wait for the trap to fire and 
> abort. After each abort I can identify the undersized variable (via the
> backtrace) then apply a fix and
> repeat the process. This approach guarantees I'll target all variables
> restricting >4GB file records.

That seems doable but somewhat difficult.  You may get some traction
with the -Wconversion option in mainline gcc.  It will emit a warning
every time you convert from, e.g, 'unsigned long long' to 'unsigned
int'.  If the file size is coming in as 'unsigned long long' somewhere,
then you can use -Wconversion to trace it as it goes through the code.
Assuming there are no explicit casts: -Wconversion will only warn about
implicit casts.

Ian

Re: (known?) Issue with bitmap iterators

[Alexander Monakov]

On Fri, 26 Jun 2009, Joe Buck wrote:


On Fri, Jun 26, 2009 at 03:38:31AM -0700, Alexander Monakov wrote:

1. Add bool field `modified_p' in bitmap structure.
2. Make iterator setup functions (e.g. bmp_iter_set_init) reset it to
false.
3. Make functions that modify the bitmap set it to true.
4. Make iterator increment function (e.g. bmp_iter_next) assert
!modified_p.


Sorry, it doesn't work.  Function foo has a loop that iterates
over a bitmap.  During the iteration, it calls a function bar.  bar
modifies the bitmap, then iterates over the bitmap.  It then returns
to foo, which is in the middle of an iteration, which it continues.
The bitmap has been modified (by bar), but modified_p was reset to
false by the iteration that happened at the end of bar.


Good catch, thanks!  Let me patch that up a bit:

1. Add int field `generation' in bitmap structure, initialized arbitrarily 
at bitmap creation time.
2. Make iterator setup functions save initial generation count in the 
iterator (or generation counts for two bitmaps, if needed).

3. Modify generation count when bitmap is modified (e.g. increment it).
4. Verify that saved and current generations match when incrementing the 
iterator.

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Arnaud Charlet]

> Switching gnatbind to generate Ada if there's nothing against
> it might be a better solution since stage1 uses the system gnatbind, so
> a patch to current gnatbind will not help (unless we push it to branches
> and tell user to install a fairly recent gnatbind first).

This does create a bootstrap incompatibility/issue indeed, interesting.
Yet another alternative would be to use a C compiler to compile the binder
generated file during bootstrap.

Arno

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Laurent GUERBY]

On Fri, 2009-06-26 at 14:07 -0400, Robert Dewar wrote:
> Ian Lance Taylor wrote:
> 
> > gnatbind -C appears to be used when bootstrapping gcc to generate .c
> > files.  With --enable-build-with-cxx, those .c files will be compiled
> > with a C++ compiler.  The symbols emitted by that compilation need to be
> > linkable with the symbols emitted when compiling Ada code, so the .c
> > files need extern "C" to avoid C++ mangling.
> > 
> > Or at least so it seems to me.  I may be missing some key step.
> 
> No, I think that analysis is correct. I agree that if we can make
> the gnatbind output C++ compatible (remembering that it must be
> strictly standard, you cannot assume that gcc will be used to
> compile it!) easily, we may as well do so.
> 
> I am not clear why we have to use gnatbind -C in the build context,
> but in any case, let's fix this if it is easy to do so.

Switching gnatbind to generate Ada if there's nothing against
it might be a better solution since stage1 uses the system gnatbind, so
a patch to current gnatbind will not help (unless we push it to branches
and tell user to install a fairly recent gnatbind first).

Laurent

Re: Phase 1 of gcc-in-cxx now complete

[Adam Nemet]

Ian Lance Taylor  writes:
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works.  Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.

With GMP 4.2.1 build fails like this:

g++ -mabi=n32 -c  -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc 
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include  
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd 
-I../libdecnumber
../../src/gcc/c-lang.c -o c-lang.o
In file included from ../../src/gcc/double-int.h:24,
 from ../../src/gcc/tree.h:30,
 from ../../src/gcc/c-lang.c:27:
//usr/include/gmp.h:515: error: 'std::FILE' has not been declared
make[3]: *** [c-lang.o] Error 1
make[3]: Leaving directory `/mnt/src/gcc-tmp/mips64octeon-linux/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/mnt/src/gcc-tmp/mips64octeon-linux'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/mnt/src/gcc-tmp/mips64octeon-linux'
make: *** [all] Error 2

We need at least GMP 4.2.3 with --enable-build-with-cxx:

>From :

Changes in GMP 4.2.3
Bugs:

...
* For C++, gmp.h now includes cstdio, improving compiler
compatibility. 
...

Adam

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Robert Dewar]

Ian Lance Taylor wrote:


gnatbind -C appears to be used when bootstrapping gcc to generate .c
files.  With --enable-build-with-cxx, those .c files will be compiled
with a C++ compiler.  The symbols emitted by that compilation need to be
linkable with the symbols emitted when compiling Ada code, so the .c
files need extern "C" to avoid C++ mangling.

Or at least so it seems to me.  I may be missing some key step.


No, I think that analysis is correct. I agree that if we can make
the gnatbind output C++ compatible (remembering that it must be
strictly standard, you cannot assume that gcc will be used to
compile it!) easily, we may as well do so.

I am not clear why we have to use gnatbind -C in the build context,
but in any case, let's fix this if it is easy to do so.


Ian

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Ian Lance Taylor]

Robert Dewar  writes:

> Ian Lance Taylor wrote:
>
>> I think the function to change is Gen_Output_File_C in bindgen.adb.
>
> I don't really see any urgency for this change, yes gnatbind has
> the option to generate C, but it is not the normal path, and only
> of use in unusual circumstances, so I don't really see the need
> for this output to be C++ compatible. The documentation doesn't
> claim this after all.

gnatbind -C appears to be used when bootstrapping gcc to generate .c
files.  With --enable-build-with-cxx, those .c files will be compiled
with a C++ compiler.  The symbols emitted by that compilation need to be
linkable with the symbols emitted when compiling Ada code, so the .c
files need extern "C" to avoid C++ mangling.

Or at least so it seems to me.  I may be missing some key step.

Ian

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Arnaud Charlet]

> I don't really see any urgency for this change, yes gnatbind has
> the option to generate C, but it is not the normal path, and only
> of use in unusual circumstances, so I don't really see the need
> for this output to be C++ compatible. The documentation doesn't
> claim this after all.

We're talking about bootstrapping GNAT itself. The other PATH would be
to change the Makefile to use gnatbind instead of gnatbind -C. Note sure
one option is simpler than the other (I suspect the gnatbind change is
actually simpler than the Makefile change).

Arno

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Robert Dewar]

Ian Lance Taylor wrote:


I think the function to change is Gen_Output_File_C in bindgen.adb.


I don't really see any urgency for this change, yes gnatbind has
the option to generate C, but it is not the normal path, and only
of use in unusual circumstances, so I don't really see the need
for this output to be C++ compatible. The documentation doesn't
claim this after all.

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Arnaud Charlet]

> I don't really know how the Ada compiler works, but it looks like this
> code is generated by the gnatbind program.  I bet it would work if
> gnatbind -C emitted this at the start of the output:
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> and emitted this at the end:
> 
> #ifdef __cplusplus
> }
> #endif
> 
> I think the function to change is Gen_Output_File_C in bindgen.adb.

Looks like a good track indeed and a reasonable change to make IMO.

Arno

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Ian Lance Taylor]

Laurent GUERBY  writes:

> Next issue is that gnat1 link fails on many missing symbols:
>
> ada/b_gnat1.o: In function `adainit()':
> ada/b_gnat1.c:287: undefined reference to `system__soft_links___elabb()'
> ada/b_gnat1.c:291: undefined reference to
> `system__secondary_stack___elabb()'
> 
> ada/b_gnat1.c:89: undefined reference to
> `system__standard_library__adafinal()'
> ada/b_gnat1.o:(.eh_frame+0x12): undefined reference to
> `__gxx_personality_v0'
> ada/adadecode.o:(.eh_frame+0x12): undefined reference to
> `__gxx_personality_v0'
> ...
>
> (full log attached as b.log.gz)
>
> I suspect some Makefile+gnatbind work specific to this branch is needed
> to go past this issue but I've no idea on what is the exact source
> of the issue and how to fix it, I've no experience in C++/Ada code
> mixing. Help welcomed :).

I don't really know how the Ada compiler works, but it looks like this
code is generated by the gnatbind program.  I bet it would work if
gnatbind -C emitted this at the start of the output:

#ifdef __cplusplus
extern "C" {
#endif

and emitted this at the end:

#ifdef __cplusplus
}
#endif

I think the function to change is Gen_Output_File_C in bindgen.adb.

Ian

Re: Failure building current 4.5 snapshot on Cygwin

[Tim Prince]

Kai Tietz wrote:

2009/6/26 Tim Prince :
  

Kai Tietz wrote:


2009/6/26 Seiji Kachi :

  

Angelo Graziosi wrote:



Dave Korn ha scritto:

  

Angelo Graziosi wrote:



I want to flag the following failure I have seen on Cygwin 1.5 trying
to
build current 4.5-20090625 gcc snapshot:

  

 So what's in config.log?  And what binutils are you using?



The config logs are attached, while binutils is the current in
Cygwin-1.5,
i.e. 20080624-2.


Cheers,
Angelo.

  

I have also seen similar faulure, and the reason on my environment is as
follows.

(1) In my case, gcc build complete successfully.  But a.exe which is
compiled from the new compiler fails. Error message is

$ ./a.exe
bash: ./a.exe: Permission denied

Source code of a.exe is quite simple:
main()
{
 printf("Hello\n");
}

(2) This failuer occurres from gcc trunk r148408.  r148407 is OK.

(3) r148408 removed "#ifdef DEBUG_PUBTYPES_SECTION".  r148407 does not
generate debug_pubtypes section, but r148408 and later version generates
 debug_pubtypes section in object when we set debug option.

(4) gcc build sequence usually uses debug option.

(5) My cygwin environment seems not to accept debug_pubtypes section, and
pop up "Permission denied" error.

When I reverted "#ifdef DEBUG_PUBTYPES_SECTION" in dearf2out.c, the
failuer
disappeared.

Does this failure occurr only on cygwin?

Regards,
Seiji Kachi




No, this bug appeared on all windows pe-coff targets. A fix for this
is already checked in yesterday on binutils. Could you try it with the
current binutils head version?

Cheers,
Kai


  

Is this supposed to be sufficient information for us to find that binutils?
 I may be able to find an insider colleague, otherwise I would have no
chance.




Hello,

you can find the binutils project as usual under
http://sources.redhat.com/binutils/ . You can find on this page how
you are able to get current cvs version of binutils. This project
contains the gnu tools, like dlltool, as, objcopy, ld, etc.
The issue you are running in is reasoned by a failure in binutils
about setting correct section flags for debugging sections. By the
last change in gcc - it was the output of the .debug_pubtypes secton -
this issue was shown.
There is a patch already applied to binutils's repository head, which
should solve the issue described here in this thread. We from
mingw-w64 were fallen already over this issue and have taken care.

Cheers,
Kai

  
My colleague suggested building and installing last week's binutils 
release.   I did so, but it didn't affect the requirement to run each 
stage 2 configure individually from command line.

Thanks,
Tim

Re: Failure building current 4.5 snapshot on Cygwin

[Steve Kargl]

On Fri, Jun 26, 2009 at 06:51:35PM +0200, Angelo Graziosi wrote:
> Steve Kargl ha scritto:
> >
> >Can you guys learn to trim the cc list?  This issue
> >has absoutely nothing to do with gfortran.  Yet,
> >for...@gcc.gnu.org is being spammed with your email.
> 
> Really... it was discovered because someone has the 'bad' habit to build 
> gfortran... :-)
> 

If you actually read the text that you posted in
your first email, you would have found that
there is clearly no evidence that this failure
is gfortran related.  This then would have been
a clear indication that cross-posting to fortran@
is unwelcomed.

-- 
Steve

Re: Failure building current 4.5 snapshot on Cygwin

[Angelo Graziosi]

Steve Kargl ha scritto:


Can you guys learn to trim the cc list?  This issue
has absoutely nothing to do with gfortran.  Yet,
for...@gcc.gnu.org is being spammed with your email.


Really... it was discovered because someone has the 'bad' habit to build 
gfortran... :-)




Have a nice day.



Angelo

Re: (known?) Issue with bitmap iterators

[Joe Buck]

On Fri, Jun 26, 2009 at 03:38:31AM -0700, Alexander Monakov wrote:
> 1. Add bool field `modified_p' in bitmap structure.
> 2. Make iterator setup functions (e.g. bmp_iter_set_init) reset it to
> false.
> 3. Make functions that modify the bitmap set it to true.
> 4. Make iterator increment function (e.g. bmp_iter_next) assert
> !modified_p.

Sorry, it doesn't work.  Function foo has a loop that iterates
over a bitmap.  During the iteration, it calls a function bar.  bar
modifies the bitmap, then iterates over the bitmap.  It then returns
to foo, which is in the middle of an iteration, which it continues.
The bitmap has been modified (by bar), but modified_p was reset to
false by the iteration that happened at the end of bar.

Re: Failure building current 4.5 snapshot on Cygwin

[Steve Kargl]

On Fri, Jun 26, 2009 at 06:17:15PM +0200, Kai Tietz wrote:
> 
> you can find the binutils project as usual under
> http://sources.redhat.com/binutils/ . You can find on this page how
> you are able to get current cvs version of binutils. This project
> contains the gnu tools, like dlltool, as, objcopy, ld, etc.
> The issue you are running in is reasoned by a failure in binutils
> about setting correct section flags for debugging sections. By the
> last change in gcc - it was the output of the .debug_pubtypes secton -
> this issue was shown.
> There is a patch already applied to binutils's repository head, which
> should solve the issue described here in this thread. We from
> mingw-w64 were fallen already over this issue and have taken care.

Can you guys learn to trim the cc list?  This issue
has absoutely nothing to do with gfortran.  Yet,
for...@gcc.gnu.org is being spammed with your email.

Have a nice day.

-- 
Steve

Re: Failure building current 4.5 snapshot on Cygwin

[Kai Tietz]

2009/6/26 Tim Prince :
> Kai Tietz wrote:
>>
>> 2009/6/26 Seiji Kachi :
>>
>>>
>>> Angelo Graziosi wrote:
>>>

 Dave Korn ha scritto:

>
> Angelo Graziosi wrote:
>
>>
>> I want to flag the following failure I have seen on Cygwin 1.5 trying
>> to
>> build current 4.5-20090625 gcc snapshot:
>>
>
>  So what's in config.log?  And what binutils are you using?
>

 The config logs are attached, while binutils is the current in
 Cygwin-1.5,
 i.e. 20080624-2.


 Cheers,
 Angelo.

>>>
>>> I have also seen similar faulure, and the reason on my environment is as
>>> follows.
>>>
>>> (1) In my case, gcc build complete successfully.  But a.exe which is
>>> compiled from the new compiler fails. Error message is
>>>
>>> $ ./a.exe
>>> bash: ./a.exe: Permission denied
>>>
>>> Source code of a.exe is quite simple:
>>> main()
>>> {
>>>  printf("Hello\n");
>>> }
>>>
>>> (2) This failuer occurres from gcc trunk r148408.  r148407 is OK.
>>>
>>> (3) r148408 removed "#ifdef DEBUG_PUBTYPES_SECTION".  r148407 does not
>>> generate debug_pubtypes section, but r148408 and later version generates
>>>  debug_pubtypes section in object when we set debug option.
>>>
>>> (4) gcc build sequence usually uses debug option.
>>>
>>> (5) My cygwin environment seems not to accept debug_pubtypes section, and
>>> pop up "Permission denied" error.
>>>
>>> When I reverted "#ifdef DEBUG_PUBTYPES_SECTION" in dearf2out.c, the
>>> failuer
>>> disappeared.
>>>
>>> Does this failure occurr only on cygwin?
>>>
>>> Regards,
>>> Seiji Kachi
>>>
>>>
>>
>> No, this bug appeared on all windows pe-coff targets. A fix for this
>> is already checked in yesterday on binutils. Could you try it with the
>> current binutils head version?
>>
>> Cheers,
>> Kai
>>
>>
>
> Is this supposed to be sufficient information for us to find that binutils?
>  I may be able to find an insider colleague, otherwise I would have no
> chance.
>

Hello,

you can find the binutils project as usual under
http://sources.redhat.com/binutils/ . You can find on this page how
you are able to get current cvs version of binutils. This project
contains the gnu tools, like dlltool, as, objcopy, ld, etc.
The issue you are running in is reasoned by a failure in binutils
about setting correct section flags for debugging sections. By the
last change in gcc - it was the output of the .debug_pubtypes secton -
this issue was shown.
There is a patch already applied to binutils's repository head, which
should solve the issue described here in this thread. We from
mingw-w64 were fallen already over this issue and have taken care.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: Problem on Front-End List Page

[Joe Buck]

On Fri, Jun 26, 2009 at 08:59:32AM -0700, Bryce wrote:
>   Many IDEs other than the ones that you list on your page of
> front-ends to GCC compiler exist.  One such IDE is XCode 3.1.3, which
> is developed by Apple, Inc.

That's not an oversight.  The intention is to only include free software,
and XCode is proprietary.

Problem on Front-End List Page

[Bryce]

To the GCC team,

 Many IDEs other than the ones that you list on your page of  
front-ends to GCC compiler exist.  One such IDE is XCode 3.1.3, which  
is developed by Apple, Inc.


From a Visitor to Your Website

Re: Failure building current 4.5 snapshot on Cygwin

[Tim Prince]

Kai Tietz wrote:

2009/6/26 Seiji Kachi :
  

Angelo Graziosi wrote:


Dave Korn ha scritto:
  

Angelo Graziosi wrote:


I want to flag the following failure I have seen on Cygwin 1.5 trying to
build current 4.5-20090625 gcc snapshot:
  

 So what's in config.log?  And what binutils are you using?


The config logs are attached, while binutils is the current in Cygwin-1.5,
i.e. 20080624-2.


Cheers,
Angelo.
  

I have also seen similar faulure, and the reason on my environment is as
follows.

(1) In my case, gcc build complete successfully.  But a.exe which is
compiled from the new compiler fails. Error message is

$ ./a.exe
bash: ./a.exe: Permission denied

Source code of a.exe is quite simple:
main()
{
 printf("Hello\n");
}

(2) This failuer occurres from gcc trunk r148408.  r148407 is OK.

(3) r148408 removed "#ifdef DEBUG_PUBTYPES_SECTION".  r148407 does not
generate debug_pubtypes section, but r148408 and later version generates
 debug_pubtypes section in object when we set debug option.

(4) gcc build sequence usually uses debug option.

(5) My cygwin environment seems not to accept debug_pubtypes section, and
pop up "Permission denied" error.

When I reverted "#ifdef DEBUG_PUBTYPES_SECTION" in dearf2out.c, the failuer
disappeared.

Does this failure occurr only on cygwin?

Regards,
Seiji Kachi




No, this bug appeared on all windows pe-coff targets. A fix for this
is already checked in yesterday on binutils. Could you try it with the
current binutils head version?

Cheers,
Kai

  
Is this supposed to be sufficient information for us to find that 
binutils?  I may be able to find an insider colleague, otherwise I would 
have no chance.

Re: Failure building current 4.5 snapshot on Cygwin

[Tim Prince]

Dave Korn wrote:

Angelo Graziosi wrote:
  

I want to flag the following failure I have seen on Cygwin 1.5 trying to
build current 4.5-20090625 gcc snapshot:



  So what's in config.log?  And what binutils are you using?

cheers,
  DaveK

  
In my case, it says no permission to execute a.exe.  However, I can run 
the intl configure and make from command line.  When I do that, and 
attempt to restart stage 2, it stops in liberty, and again I have to 
execute steps from command line.

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Arnaud Charlet]

> > What is the way forward: fixing in some way the Ada Makefile? Or doing
> > search and replace in case of keyword/identifier conflict? If
> > search/replace, do AdaCore people have an opinion on the best way
> > to proceed to avoid maintenance issues in the various trees? (eg: commit
> > of those trivial patches directly on trunk or on AdaCore tree then
> > trunk?)
> 
> I can't answer that--it's up to the Ada maintainers.

I think we do want to fix these warnings. Apart from trivial keyword issues,
they do point to dubious C constructs anyway, so nice to clean up in
any case.

I'd suggest posting patching to gcc-patches as usual.

Arno

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Ian Lance Taylor]

Laurent GUERBY  writes:

> What is the way forward: fixing in some way the Ada Makefile? Or doing
> search and replace in case of keyword/identifier conflict? If
> search/replace, do AdaCore people have an opinion on the best way
> to proceed to avoid maintenance issues in the various trees? (eg: commit
> of those trivial patches directly on trunk or on AdaCore tree then
> trunk?)

I can't answer that--it's up to the Ada maintainers.


> I don't know much about C++/C compatibilities and the way to solve
> them choosen on the gcc-in-cxx branch, is there a document somewhere?

No.  In some cases the warnings given by -Wc++-compat will be more
helpful.


> Next error is related to enum in for loop:
>
> g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -fno-common  
> -DHAVE_CONFIG_H -I.. -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada 
> -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
> -I/opt/cfarm/gmp-4.2.4//include -I/opt/cfarm/mpfr-2.4.1//include 
> -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid 
> -I../libdecnumber../../gcc/gcc/ada/gcc-interface/misc.c -o ada/misc.o
> ../../gcc/gcc/ada/gcc-interface/misc.c: In function 'void 
> enumerate_modes(void (*)(int, int, int, int, int, int, unsigned int))':
> ../../gcc/gcc/ada/gcc-interface/misc.c:734: error: invalid conversion from 
> 'int' to 'machine_mode'
> ../../gcc/gcc/ada/gcc-interface/misc.c:734: error: no 'operator++(int)' 
> declared for postfix '++', trying prefix operator instead
> ../../gcc/gcc/ada/gcc-interface/misc.c:734: error: no match for 'operator++' 
> in '++i'


In the C/C++ common subset you can not write loops in which the index
variable has enum type.  Loops like these must be written as something
along the lines of

  int iloop;

  for (iloop = 0; iloop < NUM_MACHINE_MODES; iloop++)
{
  enum machine_mode i = (enum machine_mode) iloop;
  ...
}


> Another kind of error on struct declarations:
>
> <<
> g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -fno-common  
> -DHAVE_CONFIG_H -I.. -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada 
> -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
> -I/opt/cfarm/gmp-4.2.4//include -I/opt/cfarm/mpfr-2.4.1//include 
> -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid 
> -I../libdecnumber../../gcc/gcc/ada/gcc-interface/trans.c -o ada/trans.o
> ../../gcc/gcc/ada/gcc-interface/trans.c:111: error: conflicting declaration 
> 'typedef struct parm_attr* parm_attr'
> ../../gcc/gcc/ada/gcc-interface/trans.c:103: error: 'struct parm_attr' has a 
> previous declaration as 'struct parm_attr'

In C++, if a typedef and a struct tag have the same name, they must name
the same type.  I've been addressing these issues by consistently
renaming the struct with a "_d" suffix.  See, e.g., struct
alias_set_entry_d and alias_set_entry in alias.c.


> Last error is on void* arithmetic:
>
> <<
> g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -fno-common 
> -Wno-error -DHAVE_CONFIG_H  -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada 
> -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
> -I/opt/cfarm/gmp-4.2.4//include -I/opt/cfarm/mpfr-2.4.1//include 
> -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid 
> -I../libdecnumber\
> -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada 
> -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
> -I/opt/cfarm/gmp-4.2.4//include -I/opt/cfarm/mpfr-2.4.1//include 
> -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid 
> -I../libdecnumber   -fno-omit-frame-pointer ../../gcc/gcc/ada/tracebak.c -o 
> ada/tracebak.o
> In file included from ../../gcc/gcc/ada/tracebak.c:396:
> ../../gcc/gcc/ada/tb-gcc.c: In function '_Unwind_Reason_Code 
> trace_callback(_Unwind_Context*, uw_data_t*)':
> ../../gcc/gcc/ada/tb-gcc.c:86: error: pointer of type 'void *' used in 
> arithmetic

Here pc has type "void *", but the code computes "pc + PC_ADJUST".  This
is not permitted in C either, and is actually a gcc extension.  The fix
is to change pc to "char *".

Ian

Re: Any ideas how to get the IRA to choose one subclass of registers over another in the same cover class?

[Dave Hudson]

Jeff Law wrote:

Dave Hudson wrote:



I would have hoped that having done the analysis early on that the 
register allocator would try to allocate from the preferred register 
class rather than the cover class but it seems that doesn't happen?
So you're saying that the register preferences look reasonable, but in 
low pressure situations the allocator appears to largely ignore the 
preferred register class?


I did some more digging into this over the last couple of days and it 
seems that the RA appears to over-emphasize the benefits of propagating 
hard regs - in this case one or more hard regs that are holding incoming 
function arguments.  The RA ends up believing that the hard reg (a data 
register here) has the same cost as copying and using an address 
register, but this means we end up with reload trying to clean up the 
result after the RA has assigned a register that can't actually be used 
for a MEM.


As an experiment I modified the weighting for a MEM in 
record_operand_costs(), multiplying frequency by 33/16 instead of 2 and 
that shifts the balance sufficiently to get the correct choice. 
Obviously thought that's not a solution - it just indicates something 
about the problem.


Curiously though (and seemingly quite unrelated to what I'm seeing) I 
did noticed that if the RA chooses to use a callee-saved register it 
only adjusts the cost associated with that register by a very small 
amount - the comment in assign_hard_reg() in ira-color.c mentions the 
need to increase the cost of the hard reg because of the need to 
save/restore in the prologue/epilogue (actually it appears to have these 
back-to-front in the comment), but the value is never adjusted by any 
frequency, just the sum of the 2 memory move costs - 1.


It might help if you could provide some debugging dumps.  The .ira dump 
in particular contains a wealth of information about the decisions the 
allocator is making.


They don't show anything terribly helpful unfortunately because they 
don't appear to show any of the costs associated with the hard regs - I 
ended up instrumenting the code to work out what I've found so far.




Anyone have any ideas other than writing a pass that runs before 
reload and tries to fix this up?
The first thing is to understand why IRA is doing what it's doing.  
We're generally better off generating a good allocation rather than 
trying to clean it up post-allocation.


No arguments there :-)


Cheers,
Dave

Re: Failure building current 4.5 snapshot on Cygwin

[Tim Prince]

Angelo Graziosi wrote:
> I want to flag the following failure I have seen on Cygwin 1.5 trying to
> build current 4.5-20090625 gcc snapshot:

> checking whether the C compiler works... configure: error: in
> `/tmp/build/intl':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.

I met the same failure on Cygwin 1.7 with yesterday's and last week's
snapshots.  I didn't notice that it refers to intl/config.log, so will go
back and look, as you didn't show what happened there.

On a slightly related subject, I have shown that the libgfortran.dll.a and
libgomp.dll.a are broken on cygwin builds, including those released for
cygwin, as shown on the test case I submitted on cygwin list earlier this
week.  The -enable-shared has never been satisfactory for gfortran cygwin.

Re: Phase 1 of gcc-in-cxx now complete

[Jack Howarth]

On Fri, Jun 26, 2009 at 01:33:06AM -0500, Gabriel Dos Reis wrote:
> On Thu, Jun 25, 2...@5:47 PM, Joe Buck wrote:
> > On Thu, Jun 25, 2...@03:19:19PM -0700, Joseph S. Myers wrote:
> >> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
> >>
> >> > * Test starting the bootstrap with earlier versions of the compiler to
> >> >   see which C++ compiler version is required, and document that.
> >>
> >> I think the right approach is not documenting observations like that, but
> >> investigating the causes of failures with older compilers and making it
> >> build with as wide a range of versions of GCC (and idea...@least one
> >> non-GCC C++ compiler, probably an EDG-based one such as the Intel
> >> compiler) as is reasonable.
> >
> > Microsoft's and Sun's compilers would be more likely to run into issues,
> > particularly Sun's; Sun has had a policy of preferring solid backward
> > compatibility to standards compliance, so I've tended to have more
> > problems getting correct, standard C++ to run on their compiler than on
> > others.  This is particularly true of template-based code and nested
> > classes.
> 
> Yes, but I also think that we should aim for a conservative subset
> of C++ -- that is solid enough for the last decade.  I don't pretend
> that is an easy task, but I believe that can only help us.
> 
> -- Gaby
> 
> 

Certainly the minimum version of gcc required for compiling with the
cxx support should be well defined. On Mac OS X for instance, the ppl
required for the graphite support in gcc >= 4.4 doesn't compile with
Apple's g++-4.0.1 compilers and requires their g++-4.2.1 compilers 
instead. 
Jack

Re: Failure building current 4.5 snapshot on Cygwin

[Kai Tietz]

2009/6/26 Seiji Kachi :
> Angelo Graziosi wrote:
>>
>> Dave Korn ha scritto:
>>>
>>> Angelo Graziosi wrote:

 I want to flag the following failure I have seen on Cygwin 1.5 trying to
 build current 4.5-20090625 gcc snapshot:
>>>
>>>  So what's in config.log?  And what binutils are you using?
>>
>> The config logs are attached, while binutils is the current in Cygwin-1.5,
>> i.e. 20080624-2.
>>
>>
>> Cheers,
>> Angelo.
>
> I have also seen similar faulure, and the reason on my environment is as
> follows.
>
> (1) In my case, gcc build complete successfully.  But a.exe which is
> compiled from the new compiler fails. Error message is
>
> $ ./a.exe
> bash: ./a.exe: Permission denied
>
> Source code of a.exe is quite simple:
> main()
> {
>  printf("Hello\n");
> }
>
> (2) This failuer occurres from gcc trunk r148408.  r148407 is OK.
>
> (3) r148408 removed "#ifdef DEBUG_PUBTYPES_SECTION".  r148407 does not
> generate debug_pubtypes section, but r148408 and later version generates
>  debug_pubtypes section in object when we set debug option.
>
> (4) gcc build sequence usually uses debug option.
>
> (5) My cygwin environment seems not to accept debug_pubtypes section, and
> pop up "Permission denied" error.
>
> When I reverted "#ifdef DEBUG_PUBTYPES_SECTION" in dearf2out.c, the failuer
> disappeared.
>
> Does this failure occurr only on cygwin?
>
> Regards,
> Seiji Kachi
>

No, this bug appeared on all windows pe-coff targets. A fix for this
is already checked in yesterday on binutils. Could you try it with the
current binutils head version?

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: Failure building current 4.5 snapshot on Cygwin

[Seiji Kachi]

Angelo Graziosi wrote:

Dave Korn ha scritto:

Angelo Graziosi wrote:

I want to flag the following failure I have seen on Cygwin 1.5 trying to
build current 4.5-20090625 gcc snapshot:


  So what's in config.log?  And what binutils are you using?


The config logs are attached, while binutils is the current in 
Cygwin-1.5, i.e. 20080624-2.



Cheers,
Angelo.


I have also seen similar faulure, and the reason on my environment is as 
follows.


(1) In my case, gcc build complete successfully.  But a.exe which is 
compiled from the new compiler fails. Error message is


$ ./a.exe
bash: ./a.exe: Permission denied

Source code of a.exe is quite simple:
main()
{
  printf("Hello\n");
}

(2) This failuer occurres from gcc trunk r148408.  r148407 is OK.

(3) r148408 removed "#ifdef DEBUG_PUBTYPES_SECTION".  r148407 does not 
generate debug_pubtypes section, but r148408 and later version generates 
 debug_pubtypes section in object when we set debug option.


(4) gcc build sequence usually uses debug option.

(5) My cygwin environment seems not to accept debug_pubtypes section, 
and pop up "Permission denied" error.


When I reverted "#ifdef DEBUG_PUBTYPES_SECTION" in dearf2out.c, the 
failuer disappeared.


Does this failure occurr only on cygwin?

Regards,
Seiji Kachi

Re: Failure building current 4.5 snapshot on Cygwin

[Angelo Graziosi]

Dave Korn ha scritto:

Angelo Graziosi wrote:

I want to flag the following failure I have seen on Cygwin 1.5 trying to
build current 4.5-20090625 gcc snapshot:


  So what's in config.log?  And what binutils are you using?


The config logs are attached, while binutils is the current in 
Cygwin-1.5, i.e. 20080624-2.



Cheers,
Angelo.


config_logs.tar.bz2
Description: Binary data

Re: Failure building current 4.5 snapshot on Cygwin

[Dave Korn]

Angelo Graziosi wrote:
> I want to flag the following failure I have seen on Cygwin 1.5 trying to
> build current 4.5-20090625 gcc snapshot:

  So what's in config.log?  And what binutils are you using?

cheers,
  DaveK

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Laurent GUERBY]

On Thu, 2009-06-25 at 15:28 -0700, Ian Lance Taylor wrote:
> Richard Guenther  writes:
> 
> >> I guess this has to do with reserved word conflict on "new":
> >>
> >> <<
> >> tree
> >> substitute_in_type (tree t, tree f, tree r)
> >> {
> >>  tree new;
> 
> >>
> >> Do you have some way to deal with this?
> >
> > Use a non-reserved identifier.  I guess on trunk Ada doesn't build
> > with -Wc++-compat, does it?
> 
> Interesting.  I've been testing my -Wc++-compat patches with full
> bootstraps including Ada, but I just looked at my make log and it does
> indeed appear that -Wc++-compat doesn't make it onto the Ada files.
> 
> It seems to be because of this line in ada/gcc-interface/Make-lang.in:
> 
> ada-warn = $(ADA_CFLAGS) $(WERROR)
> 
> The other languages use
> 
> DIR-warn = $(STRICT_WARN)
> 
> which is what brings in -Wc++-compat.

What is the way forward: fixing in some way the Ada Makefile? Or doing
search and replace in case of keyword/identifier conflict? If
search/replace, do AdaCore people have an opinion on the best way
to proceed to avoid maintenance issues in the various trees? (eg: commit
of those trivial patches directly on trunk or on AdaCore tree then
trunk?)

I don't know much about C++/C compatibilities and the way to solve
them choosen on the gcc-in-cxx branch, is there a document somewhere?

Next error is related to enum in for loop:

g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-fno-common  -DHAVE_CONFIG_H -I.. -I. -Iada -I../../gcc/gcc
-I../../gcc/gcc/ada -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4//include
-I/opt/cfarm/mpfr-2.4.1//include -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber../../gcc/gcc/ada/gcc-interface/misc.c -o
ada/misc.o
../../gcc/gcc/ada/gcc-interface/misc.c: In function 'void
enumerate_modes(void (*)(int, int, int, int, int, int, unsigned int))':
../../gcc/gcc/ada/gcc-interface/misc.c:734: error: invalid conversion
from 'int' to 'machine_mode'
../../gcc/gcc/ada/gcc-interface/misc.c:734: error: no 'operator++(int)'
declared for postfix '++', trying prefix operator instead
../../gcc/gcc/ada/gcc-interface/misc.c:734: error: no match for
'operator++' in '++i'

<<
void
enumerate_modes (void (*f) (int, int, int, int, int, int, unsigned int))
{
  enum machine_mode i;

  for (i = 0; i < NUM_MACHINE_MODES; i++)
>>

Another kind of error on struct declarations:

<<
g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-fno-common  -DHAVE_CONFIG_H -I.. -I. -Iada -I../../gcc/gcc
-I../../gcc/gcc/ada -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4//include
-I/opt/cfarm/mpfr-2.4.1//include -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber../../gcc/gcc/ada/gcc-interface/trans.c -o
ada/trans.o
../../gcc/gcc/ada/gcc-interface/trans.c:111: error: conflicting
declaration 'typedef struct parm_attr* parm_attr'
../../gcc/gcc/ada/gcc-interface/trans.c:103: error: 'struct parm_attr'
has a previous declaration as 'struct parm_attr'
>>

Last error is on void* arithmetic:

<<
g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-fno-common -Wno-error -DHAVE_CONFIG_H  -I. -Iada -I../../gcc/gcc
-I../../gcc/gcc/ada -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4//include
-I/opt/cfarm/mpfr-2.4.1//include -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber\
  -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/opt/cfarm/gmp-4.2.4//include -I/opt/cfarm/mpfr-2.4.1//include
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber   -fno-omit-frame-pointer ../../gcc/gcc/ada/tracebak.c
-o ada/tracebak.o
In file included from ../../gcc/gcc/ada/tracebak.c:396:
../../gcc/gcc/ada/tb-gcc.c: In function '_Unwind_Reason_Code
trace_callback(_Unwind_Context*, uw_data_t*)':
../../gcc/gcc/ada/tb-gcc.c:86: error: pointer of type 'void *' used in
arithmetic
>>

Patch welcomed as these three are not obvious to me :).

I did "touch xx.o" to get past and with the quick search/replace
of new/class/template patch below it then tried to link libbackend.o.

Thanks in advance,

Laurent

Index: gcc/ada/gcc-interface/utils.c
===
--- gcc/ada/gcc-interface/utils.c   (revision 148953)
+++ gcc/ada/gcc-interface/utils.c   (working copy)
@@ -1014,33 +1014,33 @@
 bool has_rep)
 {
   tree type = TREE_TYPE (last_size);
-  tree new;
+  tree new_tree;
 
   if (!special || TREE_CODE (size) != COND_EXPR)
 {
-  new = size_binop (PLUS_EXPR, first_bit, size);
+  new_tree = size_binop (PLUS_EXPR, first_bit, size);
   if (has_rep)
-   new = size_binop (MAX_EXPR, last_size, new);
+   new_tree = size_binop (MAX_EXPR, last_size, new_tree);
 }
 
   else
-new = fold_build3 (

Failure building current 4.5 snapshot on Cygwin

[Angelo Graziosi]

I want to flag the following failure I have seen on Cygwin 1.5 trying to 
build current 4.5-20090625 gcc snapshot:


---
[...]
make[2]: Entering directory `/tmp/build'
Configuring stage 2 in ./intl
Configuring stage 2 in ./libiberty
Configuring stage 2 in ./libdecnumber
configure: creating cache ./config.cache
configure: creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo --split-size=500 --split-size=500
checking whether make sets $(MAKE)... checking for perl... perl
yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether NLS is requested... yes
checking build system type... checking for msgfmt... configure: creating 
cache ./config.cache

/usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... i686-pc-cygwin
checking whether make sets $(MAKE)... /usr/bin/xgettext
checking for msgmerge... checking host system type... /usr/bin/msgmerge
yes
checking for i686-pc-cygwin-gcc...  /tmp/build/./prev-gcc/xgcc 
-B/tmp/build/./prev-gcc/ -B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem 
/usr/local/gfortran/i686-pc-cygwin/include -isystem 
/usr/local/gfortran/i686-pc-cygwin/sys-include
checking for i686-pc-cygwin-gcc...  /tmp/build/./prev-gcc/xgcc 
-B/tmp/build/./prev-gcc/ -B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem 
/usr/local/gfortran/i686-pc-cygwin/include -isystem 
/usr/local/gfortran/i686-pc-cygwin/sys-include

i686-pc-cygwin
checking for i686-pc-cygwin-ar... ar
checking for i686-pc-cygwin-ranlib... ranlib
checking for i686-pc-cygwin-gcc...  /tmp/build/./prev-gcc/xgcc 
-B/tmp/build/./prev-gcc/ -B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem 
/usr/local/gfortran/i686-pc-cygwin/include -isystem 
/usr/local/gfortran/i686-pc-cygwin/sys-include
checking for C compiler default output file name... checking for C 
compiler default output file name... a.exe

checking whether the C compiler works... a.exe
checking whether the C compiler works... configure: error: in 
`/tmp/build/intl':

configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
checking for C compiler default output file name... configure: error: in 
`/tmp/build/libdecnumber':

configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-stage2-libdecnumber] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [configure-stage2-intl] Error 1
a.exe
checking whether the C compiler works... configure: error: in 
`/tmp/build/libiberty':

configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-stage2-libiberty] Error 1
make[2]: Leaving directory `/tmp/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/tmp/build'
make: *** [all] Error 2
---

I have configured with:

===
CC='gcc-4' CXX='g++-4' CPP='cpp-4' ${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-languages=c,c++,fortran \
--enable-bootstrap \
--enable-decimal-float=bid \
--enable-libgomp \
--enable-threads \
--enable-sjlj-exceptions \
--enable-version-specific-runtime-libs \
--enable-nls \
--enable-checking=release \
--disable-fixed-point \
--disable-libmudflap \
--disable-shared \
--disable-win32-registry \
--with-arch=i686 \
--with-system-zlib \
--with-tune=generic \
--without-included-gettext \
--without-x || return 1
===

The source comes from the following files:

gcc-core-4.5-20090625.tar.bz2
gcc-fortran-4.5-20090625.tar.bz2
gcc-g++-4.5-20090625.tar.bz2


I have tried using 'make -j2[or -j4]'


Cheers,
Angelo.

Re: (known?) Issue with bitmap iterators

[Alexander Monakov]

On Thu, 25 Jun 2009, Jeff Law wrote:
I wasn't suggesting we make them "safe" in the sense that one could modify 
the bitmap and everything would just work.  Instead I was suggesting we make 
the bitmap readonly for the duration of the iterator and catch attempts to 
modify the bitmap -- under the control of ENABLE_CHECKING of course.  If that 
turns out to still be too expensive, it could be conditional on 
ENABLE_BITMAP_ITERATOR_CHECKING or whatever, which would normally be off.


My biggest concern would be catching all the exit paths from the gazillion 
iterators we use and making sure they all reset the readonly flag.  Ick...


Unless I'm missing something, one can avoid that by checking whether the 
bitmap has been modified in the iterator increment function.  To be 
precise, what I have in mind is:


1. Add bool field `modified_p' in bitmap structure.
2. Make iterator setup functions (e.g. bmp_iter_set_init) reset it to 
false.

3. Make functions that modify the bitmap set it to true.
4. Make iterator increment function (e.g. bmp_iter_next) assert 
!modified_p.


This approach would also allow to modify the bitmap on the iteration 
ending with break, which IMHO is fine.


--
Alexander Monakov

About machine.md in insight-gdb debug

[daniel tian]

Hi:

I check the MIPS and ARM, both those cc1 files opened in Insight debug
tool contain the mips.md and arm.md file. It is convenient while break
point can be set in it.
My port md file doesn't appear in the insight.

How can I make it?

Thank you very much.

-- 
Best Regards
daniel tian
Mavrix Technology, Inc.
Address：200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech
Park, Shanghai, P.R.China (201204)
Tel:86(21)51095958 - 8125
Fax:86(21)50277658
email：daniel.t...@mavrixtech.com.cn
www.mavrixtech.com

unsigned integer wrap 'trap'.

[samboy]

Wasn't sure whether to post this to gcc Dev or Patches so its both to start
with.

Its my first posting to this forum so first some background:

I have a storage application to which I can record or retrieve files. Its
multi-process C/C++ compiled 
to run on the SPARC platform. The problem is the maximum file size which can
be stored is 4GB due to 
the size being internally conveyed using an unsigned integer. I need to
extend the range so it accepts
much larger files i.e. convert all uints to long longs. The approach at
first was to work through the code 
line-by-line to locate and upsize all variables as required. The problem is
there's almost a million lines of
code and no guarantee every instance of filesize usage will be located &
upsized. Another more elegant
approach which came to mind was to somehow 'trap' the occurrence of
*unsigned* integer overflow...or
should that be wrapping - yes I know its completely acceptable behaviour. If
I could get gcc to do this 
for me I could simply run a full suite of end-to-end functional testing then
wait for the trap to fire and 
abort. After each abort I can identify the undersized variable (via the
backtrace) then apply a fix and
repeat the process. This approach guarantees I'll target all variables
restricting >4GB file records.

I'm not for a moment suggesting this be added as an option to gcc. I'm just
wanting to build a temporary 
tool to serve a purpose as outlined above. Want I'm looking for are some
fast-track, high-level pointers 
as to how to achieve this. 

Bear in mind I've spent a good week gazing at the gcc source but need some
guidance to go forward.
As a starting point I've had a stab at modifying the -ftrapv option to work
with unsigned int arithmetic.
Preliminary testing appears to work ok with test apps aborting when wrapping
occurs (I'm also mindful 
of -ftrapv possibly being flaky according to some other posts).

What I'm desperately lacking is the ability to also trap/abort when ANY
unsigned int be it a function arg,
return variable, local variable, etc WRAPS on being assigned or passed a
value to large in RUNTIME.

Any advice as detailed as you like in relation to the source would be very
much appreciated.
Thanks for taking the time to read this and any other ideas on how to do
this are also welcome.

-- 
View this message in context: 
http://www.nabble.com/unsigned-integer-wrap-%27trap%27.-tp24215937p24215937.html
Sent from the gcc - Dev mailing list archive at Nabble.com.