headers
Jerry DeLisle | 1 Jun 2009 03:10
Picon

Re: Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]

Tobias Burnus wrote:
> Dave Korn wrote:
>> Dave Korn wrote:
>>> Dave Korn wrote:
>>>> Tobias Burnus wrote:
>>>>> I agree that for "main" the call to "__main()" should happend and thus
>>>>> expand_main_function should be called. I'm not sure in about the exact
>>>>> assumptions of the middle end. In principle, it would be OK if the
>>>>> MAIN__ function would show up as MAIN__ in gimple/-fdump-tree-original.
>>>>> The only potential inconvenience I see, is the mentioned reference to
>>>>> MAIN__ instead of <program name> in middle-end warnings, which can
>>>>> confuse users.
>>   Is it legitimate to have a space in an IDENTIFIER_NODE?  I have a cheeky idea:
> 
>> -  gfc_get_symbol (name, ns, &main_program);
>> +  identifier = gfc_get_string ("PROGRAM %s", name);
> 
>>   That should give reasonable warnings from the middle end, no?  I don't know
>> what it might do to debugging though.
> 
> Currently one can use "b MAIN__" and "b helloworld" in the debugger:
> 
> (gdb) b helloworld
> Breakpoint 1 at 0x400737: file test.f90, line 3.
> (gdb) b MAIN__
> Note: breakpoint 1 also set at pc 0x400737.
> Breakpoint 2 at 0x400737: file test.f90, line 3.
> (gdb) b main
> Breakpoint 3 at 0x4007b9: file test.f90, line 9.
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
顏呈育 | 1 Jun 2009 07:23
Picon

Having trouble printing the subvars of structs, under certain conditions

I am using gcc 4.1.1 to do research involving gimple.  For this work I need to
know the sizes of all of my variables, without running the program and calling
"sizeof".

To accomplish this, I inserted a call to:
   dump_referenced_vars(dump_file_ptr);

At first, everything looked fine.  The output looks something like this:

...
Variable: ibin, UID 1428, char[16], is global, call clobbered, default
def: ibin_100
Variable: ie, UID 1429, struct great, sub-vars: { SFT.124 SFT.123 SFT.122 }
Variable: itmp, UID 1430, long unsigned int
...

From this information, I can work out the sizes of all 3 variables
(ibin, ie, and itmp).
The ie variable is a struct with 3 subbvariables (SFT.124, SFT.123,
SFT.122). To
compute the size of ie, I need to recursively find the name of each
subvar, but this
is not the problem that I want to ask about.

The problem is that the subvars of a struct do not always print. I
specifically see that
it does not print subvars if one of the subvars is an array or itself
a struct.  For
example, here is a code snippet for a struct with an array element:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 Jun 2009 09:01
Picon

Re: Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]

Jerry DeLisle wrote:
> I tested the above on x86-64 Linux.  OK to commit.
Thanks for the review. Committed:

Sending        gcc/fortran/ChangeLog
Sending        gcc/fortran/trans-decl.c
Transmitting file data ..
Committed revision 148035.

Tobias
Permalink | Reply | 2 comments |
headers
Dave Korn | 1 Jun 2009 11:18

Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]

Tobias Burnus wrote:
> Jerry DeLisle wrote:
>> I tested the above on x86-64 Linux.  OK to commit.
> Thanks for the review. Committed:
> 
> Sending        gcc/fortran/ChangeLog
> Sending        gcc/fortran/trans-decl.c
> Transmitting file data ..
> Committed revision 148035.
> 
> Tobias

  Thank you both :)

    cheers,
      DaveK
Permalink | Reply | 0 comments |
headers
Tobias Schlüter | 1 Jun 2009 12:07
Picon
Favicon

Bootstrap broken on darwin / fink


Hi,

I'm seeing this error:

/Users/tobi/src/hggcc/build/./prev-gcc/xgcc 
-B/Users/tobi/src/hggcc/build/./prev-gcc/ 
-B/usr/local/i386-apple-darwin8.11.1/bin/ 
-B/usr/local/i386-apple-darwin8.11.1/bin/ 
-B/usr/local/i386-apple-darwin8.11.1/lib/ -isystem 
/usr/local/i386-apple-darwin8.11.1/include -isystem 
/usr/local/i386-apple-darwin8.11.1/sys-include    -c  -g -O2 
-fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototype
  -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. 
-I../../gcc -I../../gcc/. -I../..
gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/sw/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd 
-I../libdecnumber    ../../gcc/
retty-print.c -o pretty-print.o
cc1: warnings being treated as errors
../../gcc/pretty-print.c: In function 'identifier_to_locale':
../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv' 
from incompatible pointer type
/sw/include/iconv.h:83: note: expected 'char **' but argument is of type 
'const char **'
make[3]: *** [pretty-print.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-stage2-gcc] Error 2
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joseph S. Myers | 1 Jun 2009 12:44

Re: Bootstrap broken on darwin / fink

On Mon, 1 Jun 2009, Tobias Schlüter wrote:

> The complaint is about:
> 	      ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
> 	      [...snip...]
> 	      iconv_ret = iconv (cd, &inbuf, &inbytesleft,
> 				 &outbuf, &outbytesleft);

The types are exactly the same as in the corresponding code in 
libcpp/charset.c.

  ICONV_CONST char *inbuf;
      iconv (cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft);

You'll need to work out what's different on your system between gcc and 
libcpp to make it work in one place only.  Note that iconv.m4 comes from 
gettext; it's possible the configure support has since been refined 
upstream and should be updated.

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com
Permalink | Reply | 1 comment |
headers
Peter O'Gorman | 1 Jun 2009 15:18
Favicon
Gravatar

Re: Bootstrap broken on darwin / fink

Tobias Schlüter wrote:

> cc1: warnings being treated as errors
> ../../gcc/pretty-print.c: In function 'identifier_to_locale':
> ../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv'
> from incompatible pointer type
> /sw/include/iconv.h:83: note: expected 'char **' but argument is of type
> 'const char **'

This would probably have been more appropriate on a fink related mailing
list.

As Joseph pointed out, configure is finding a different iconv.h than the
compiler, and they provide different prototypes for iconv(). I suggest
looking at Jack Howarth's gcc package in fink to see what he's doing
with this.

Peter
--

-- 
Peter O'Gorman
http://pogma.com
Permalink | Reply | 0 comments |
headers
Tobias Schlüter | 1 Jun 2009 15:27
Picon
Favicon

Re: Bootstrap broken on darwin / fink

Joseph S. Myers wrote:
> On Mon, 1 Jun 2009, Tobias Schlüter wrote:
> 
>> The complaint is about:
>> 	      ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
>> 	      [...snip...]
>> 	      iconv_ret = iconv (cd, &inbuf, &inbytesleft,
>> 				 &outbuf, &outbytesleft);
> 
> The types are exactly the same as in the corresponding code in 
> libcpp/charset.c.
> 
>   ICONV_CONST char *inbuf;
>       iconv (cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft);
> 
> You'll need to work out what's different on your system between gcc and 
> libcpp to make it work in one place only.  Note that iconv.m4 comes from 
> gettext; it's possible the configure support has since been refined 
> upstream and should be updated.
> 
In gcc/auto-host.h I have #define HAVE_ICONV_H, whereas in libcpp/ I 
haven't.  From PR31932, I presume that HAVE_ICONV_H should never be 
defined.  The check is explicitly made in AC_CHECK_HEADERS in 
gcc/configure.ac.  I can't see what happens if I remove the check as 
fink symlinks autoconf-2.59 to autoconf which in turn is a symlink to 
autoconf-2.63.

Cheers,
- Tobi
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg-Johann Lay | 1 Jun 2009 16:02
Picon
Favicon

Re: Problems with sibling calls

Ulrich Weigand schrieb:
> Georg-Johann Lay wrote:
>>I'd like to support sibling calls for a target where function args can 
>>be passed in call-saved registers, namely AVR.
> The s390 back-end already has the very same issue.  You may want to have
> a look at config/s390/s390.c:s390_call_saved_register_used and how it is
> used by s390_function_ok_for_sibcall.

Hi Ulrich,

thank's much for this hint. It's the missing link I was after.

Georg-Johann
Permalink | Reply | 0 comments |
headers
Jack Howarth | 1 Jun 2009 16:20
Picon

Re: Bootstrap broken on darwin / fink

On Mon, Jun 01, 2009 at 12:07:56PM +0200, Tobias Schlüter wrote:
>
> Hi,
>
> I'm seeing this error:
>
> /Users/tobi/src/hggcc/build/./prev-gcc/xgcc  
> -B/Users/tobi/src/hggcc/build/./prev-gcc/  
> -B/usr/local/i386-apple-darwin8.11.1/bin/  
> -B/usr/local/i386-apple-darwin8.11.1/bin/  
> -B/usr/local/i386-apple-darwin8.11.1/lib/ -isystem  
> /usr/local/i386-apple-darwin8.11.1/include -isystem  
> /usr/local/i386-apple-darwin8.11.1/sys-include    -c  -g -O2  
> -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings 
> -Wstrict-prototype
>  -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat  
> -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros  
> -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.  
> -I../../gcc -I../../gcc/. -I../..
> gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/sw/include  
> -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd  
> -I../libdecnumber    ../../gcc/
> retty-print.c -o pretty-print.o
> cc1: warnings being treated as errors
> ../../gcc/pretty-print.c: In function 'identifier_to_locale':
> ../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv'  
> from incompatible pointer type
> /sw/include/iconv.h:83: note: expected 'char **' but argument is of type  
> 'const char **'
> make[3]: *** [pretty-print.o] Error 1
(Continue reading)

Permalink | Reply | 1 comment |

Gmane