GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hi,

In a build of GCC 4.7.0-RC-20120302 with --enable-languages=c,c++ [0],
I’m seeing C++-mangled name for common functions, like:

  $ objdump -T cc1 | grep build1_stat_loc
  00640a00 gDF .text  007a  Base
_Z20fold_build1_stat_locj9tree_codeP9tree_nodeS1_

Indeed, ‘tree.c’, for instance, eventually gets built with g++, not gcc:

  
/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/./prev-gcc/g++
 
-B/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/./prev-gcc/
 
-B/nix/store/glikf0cfxhhswagdh7wdwgmp20n9bfcl-gcc-debug-4.7.0rc20120302/x86_64-unknown-linux-gnu/bin/
 -nostdinc++ 
-B/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
 
-B/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 
-I/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 
-I/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 
-I/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/gcc-4.7.0-RC-20120302/libstdc++-v3/libsupc++
 
-L/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
 
-L/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -c   -O2 -g -I/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/include 
-B/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib/ -idirafter 
/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/include -idirafter 
/nix/store/fghwm2dz41sz9b2l87ffgv11zadq7dxr-gcc-4.6.3/lib/gcc/*/*/include-fixed 
 -Wl,-L/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib -Wl,-rpath 
-Wl,/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib 
-Wl,-L/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib 
-Wl,-dynamic-linker 
-Wl,/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib/ld-linux-x86-64.so.2
 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. 
-I../../gcc-4.7.0-RC-20120302/gcc -I../../gcc-4.7.0-RC-20120302/gcc/. 
-I../../gcc-4.7.0-RC-20120302/gcc/../include 
-I../../gcc-4.7.0-RC-20120302/gcc/../libcpp/include 
-I/nix/store/z5hcwkvzbzhy85lm3ibxzqmal22jgjwj-gmp-5.0.3/include 
-I/nix/store/xjks1ifzrh9ylnsjj15sy267r30b1ca5-mpfr-3.1.0/include 
-I/nix/store/36b2ghjhi40gyzfqx0qqqc034mc3ziii-mpc-0.9/include  
-I../../gcc-4.7.0-RC-20120302/gcc/../libdecnumber 
-I../../gcc-4.7.0-RC-20120302/gcc/../libdecnumber/bid -I../libdecnumber 
-I/nix/store/3fk4lylmhsyqkq2vna2gqwssgfr51ynd-ppl-0.11.2/include  
-I/nix/store/gq2pi083kf1vkl48j0wigpqzhga0bx9v-cloog-0.16.3/include 
-DCLOOG_INT_GMP -DCLOOG_ORG  ../../gcc-4.7.0-RC-20120302/gcc/tree.c -o tree.o

I believe this is not intentional, right?

What am I doing wrong?

Thanks,
Ludo’.

[0] Full log at .

Re: GCC 4.7.0RC: Mangled names in cc1

[Andrew Pinski]

2012/3/9 Ludovic Courtès :

> I believe this is not intentional, right?

No, this is intentional.  We bootstrap the compiler using the C++
front-end now.  We build stage1 with the C compiler and then build
stages 2 and 3 with the C++ compiler.

This is a documented change too.

Thanks,
Andrew Pinski

Re: GCC 4.7.0RC: Mangled names in cc1

[Jakub Jelinek]

On Fri, Mar 09, 2012 at 01:53:52AM -0800, Andrew Pinski wrote:
> 2012/3/9 Ludovic Courtès :
> 
> > I believe this is not intentional, right?
> 
> No, this is intentional.  We bootstrap the compiler using the C++
> front-end now.  We build stage1 with the C compiler and then build
> stages 2 and 3 with the C++ compiler.
> 
> This is a documented change too.

You can configure with --disable-build-poststage1-with-cxx
to disable that (or --disable-build-with-cxx in addition
to that, but that is the default in 4.7).

Jakub

subreg:HI of PSI HW register issue

[Aurelien Buhrig]

Hi,

It seems there is an issue around subreg:HI of PSI hardware register,
which occurs either during expand or reload (GCC 4.6.1).

For my big endian target,
(subreg:HI (reg:PSI A0_REGNO) 0) is not representable but
(subreg:HI (reg:PSI A0_REGNO) 2) is (reg:HI A0_REGNO).

The issue occurs when storing a pointer from hardware PSI register
(incoming pointer param) into a misaligned field of a packed structure.
GCC emits (subreg:HI (reg:PSI A0_REGNO) 0) and (subreg:HI (reg:PSI
A0_REGNO) 2) patterns and during reload, (subreg:HI (reg:PSI A0_REGNO)
0) is wrongly simplified  into (reg:HI A0_REGNO).

So:
- Is it correct that gcc emits such a subreg pattern in Pmode=PSI during
expand ? Or should it be in ptr_mode=SImode (in this case, both
(subreg:HI (reg:SI) 0/2) are representable)?

- Or should reload be able to handle unrepresentable subregs?

Thank you by advance,
Aurélien

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hi,

Andrew Pinski  skribis:

> 2012/3/9 Ludovic Courtès :
>
>> I believe this is not intentional, right?
>
> No, this is intentional.  We bootstrap the compiler using the C++
> front-end now.  We build stage1 with the C compiler and then build
> stages 2 and 3 with the C++ compiler.

OK.

However, this means that plug-ins must now be built with g++, except
when GCC was configured with --disable-build-poststage1-with-cxx.  This
seems difficult to deal with, for plug-in writers.

Is there a recommended approach for plug-ins?  (I couldn’t find one at
.)

Thanks,
Ludo’.

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hi,

ludovic.cour...@inria.fr (Ludovic Courtès) skribis:

> Andrew Pinski  skribis:
>
>> 2012/3/9 Ludovic Courtès :
>>
>>> I believe this is not intentional, right?
>>
>> No, this is intentional.  We bootstrap the compiler using the C++
>> front-end now.  We build stage1 with the C compiler and then build
>> stages 2 and 3 with the C++ compiler.
>
> OK.
>
> However, this means that plug-ins must now be built with g++, except
> when GCC was configured with --disable-build-poststage1-with-cxx.  This
> seems difficult to deal with, for plug-in writers.

I’m really concerned about the maintenance difficulties that this change
entails for external plug-ins.

Would something along these lines be acceptable at this stage?

diff --git a/gcc/tree.h b/gcc/tree.h
index 0a2d619..ce7acf2 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -22,6 +22,10 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef GCC_TREE_H
 #define GCC_TREE_H
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 #include "hashtab.h"
 #include "machmode.h"
 #include "input.h"
@@ -6102,4 +6106,8 @@ builtin_decl_implicit_p (enum built_in_function fncode)
 	  && builtin_info.implicit_p[uns_fncode]);
 }
 
+#ifdef __cplusplus
+}
+#endif
+
 #endif  /* GCC_TREE_H  */

(The same should be applied to all the headers listed in
‘PLUGIN_HEADERS’, at least.)

Or was it already considered and rejected?

Thanks,
Ludo’.

Question about -Wnonnull

[Fredrik Hederstierna]

Hi

I'm testing __attribute__((nonnull)) and -Wnonnull.
It seems like it does warn before constant/vrp propagations.

Example code does not warn for first 2 calls to f(NULL),
but warns for last 2 calls to f(NULL).

Couldn't this checker be improved/extended to do checks also after some basic 
optimizations like constant propagation pass?
(This could improve possibilities for static code analysis in compile time.)


#include 

static void f(const char *s) __attribute__((nonnull(1)));

int main(void)
{ 
  const char *p = NULL;

  f(p);  /* No warning? */
  f(p = NULL);   /* No warning? */

  f((const char*)NULL);  /* gives warning */
  f(NULL);   /* gives warning */
  return 0;
}

static void f(const char *s)
{
  printf("%s",s);
}


Thanks & Best Regards
Fredrik Hederstierna

Re: subreg:HI of PSI HW register issue

[Bernd Schmidt]

On 03/09/2012 11:20 AM, Aurelien Buhrig wrote:
> Hi,
> 
> It seems there is an issue around subreg:HI of PSI hardware register,
> which occurs either during expand or reload (GCC 4.6.1).
> 
> For my big endian target,
> (subreg:HI (reg:PSI A0_REGNO) 0) is not representable but
> (subreg:HI (reg:PSI A0_REGNO) 2) is (reg:HI A0_REGNO).

> - Is it correct that gcc emits such a subreg pattern in Pmode=PSI during
> expand ? Or should it be in ptr_mode=SImode (in this case, both
> (subreg:HI (reg:SI) 0/2) are representable)?

This, I think. I have a port with a rather similar situation, and I'm
betting you also have a failure in gcc.c-torture/execute/20040625-1.c. I
don't want to promise anything but I may have something for you next
week-ish.


Bernd

Re: GCC 4.7.0RC: Mangled names in cc1

[Duncan Sands]

Hi,


I believe this is not intentional, right?


No, this is intentional.  We bootstrap the compiler using the C++
front-end now.  We build stage1 with the C compiler and then build
stages 2 and 3 with the C++ compiler.


OK.

However, this means that plug-ins must now be built with g++, except
when GCC was configured with --disable-build-poststage1-with-cxx.  This
seems difficult to deal with, for plug-in writers.


I’m really concerned about the maintenance difficulties that this change
entails for external plug-ins.


does this mean that if built with --disable-bootstrap then symbols aren't
mangled, while otherwise they are?  I personally don't mind if symbols are
mangled or not, but it would be simpler if symbols can be relied upon to always
be mangled, or always not be mangled...

I guess I could work around it by detecting at build time whether the targeted
gcc has mangled symbols, and using extern "C" only if not mangled.  It would
help if there was a simple way to ask gcc if it is using mangled symbols or not.

Ciao, Duncan.

Re: GCC 4.7.0RC: Mangled names in cc1

[Ian Lance Taylor]

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> However, this means that plug-ins must now be built with g++, except
> when GCC was configured with --disable-build-poststage1-with-cxx.  This
> seems difficult to deal with, for plug-in writers.

This is an unfortunate truth during our transition to building gcc with
C++.  There is going to be a period of time when the compiler may be
built as either C or C++.  The end goal is for the compiler to always be
built with C++, but until we reach that state I think plugin writers
will have to test.

Ian

Re: subreg:HI of PSI HW register issue

[Aurelien Buhrig]

09/03/2012 15:08, Bernd Schmidt :
> On 03/09/2012 11:20 AM, Aurelien Buhrig wrote:
>> Hi,
>>
>> It seems there is an issue around subreg:HI of PSI hardware register,
>> which occurs either during expand or reload (GCC 4.6.1).
>>
>> For my big endian target,
>> (subreg:HI (reg:PSI A0_REGNO) 0) is not representable but
>> (subreg:HI (reg:PSI A0_REGNO) 2) is (reg:HI A0_REGNO).
> 
>> - Is it correct that gcc emits such a subreg pattern in Pmode=PSI during
>> expand ? Or should it be in ptr_mode=SImode (in this case, both
>> (subreg:HI (reg:SI) 0/2) are representable)?
> 
> This, I think. I have a port with a rather similar situation, and I'm
> betting you also have a failure in gcc.c-torture/execute/20040625-1.c. 

Yes,  gcc.c-torture/execute/20040625-1.c fails too.

> I don't want to promise anything but I may have something for you next
> week-ish.

Good news!
I'm not used to work at tree level for now and it is unclear for me what
part of the code should be tweaked. Can you tell me which part of the
code you are fixing/looking at, so that I can have a better
understanding of ptr_mode vs Pmode before your fix?

I will wait for your fix.

Thanks,
Aurélien

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Ian Lance Taylor  skribis:

> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>
>> However, this means that plug-ins must now be built with g++, except
>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>> seems difficult to deal with, for plug-in writers.
>
> This is an unfortunate truth during our transition to building gcc with
> C++.  There is going to be a period of time when the compiler may be
> built as either C or C++.  The end goal is for the compiler to always be
> built with C++, but until we reach that state I think plugin writers
> will have to test.

What about wrapping the C API in extern "C"?

Thanks,
Ludo’.

Re: GCC 4.7.0RC: Mangled names in cc1

[Ian Lance Taylor]

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> Ian Lance Taylor  skribis:
>
>> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>
>>> However, this means that plug-ins must now be built with g++, except
>>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>>> seems difficult to deal with, for plug-in writers.
>>
>> This is an unfortunate truth during our transition to building gcc with
>> C++.  There is going to be a period of time when the compiler may be
>> built as either C or C++.  The end goal is for the compiler to always be
>> built with C++, but until we reach that state I think plugin writers
>> will have to test.
>
> What about wrapping the C API in extern "C"?

We eventually will want the internal APIs to be C++, so this transition
will inevitably happen at some point.

I agree that the well-defined plugin API should be extern "C", and
indeed plugin-api.h does use extern "C".  Unfortunately, as we all know,
plugins need to use more than the well-defined API.

Ian

Re: subreg:HI of PSI HW register issue

[Bernd Schmidt]

On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
> I'm not used to work at tree level for now and it is unclear for me what
> part of the code should be tweaked. Can you tell me which part of the
> code you are fixing/looking at, so that I can have a better
> understanding of ptr_mode vs Pmode before your fix?

I'm thinking the bitfield code in expmed.c (extract_bit_field_1 etc.)
needs a subreg_offset_representable_p check, followed by looking for the
next larger integer mode if that fails. Then, if necessary, cast the
result back to the original mode in case of extraction.


Bernd

Re: subreg:HI of PSI HW register issue

[Aurelien Buhrig]

Le 09/03/2012 17:10, Bernd Schmidt a écrit :
> On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
>> I'm not used to work at tree level for now and it is unclear for me what
>> part of the code should be tweaked. Can you tell me which part of the
>> code you are fixing/looking at, so that I can have a better
>> understanding of ptr_mode vs Pmode before your fix?
> 
> I'm thinking the bitfield code in expmed.c (extract_bit_field_1 etc.)
> needs a subreg_offset_representable_p check, followed by looking for the
> next larger integer mode if that fails. Then, if necessary, cast the
> result back to the original mode in case of extraction.
> 

Thanks. My current bug seems to be related to the dual store_bit_field_1
function.

I submitted a bug and a patch some times ago about extract_bit_field_1,
which seems to only apply to my BIG_ENDIAN target. If you have a quite
similar target, perhaps it will help.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893

Aurélien

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Ian Lance Taylor  skribis:

> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>
>> Ian Lance Taylor  skribis:
>>
>>> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>>
 However, this means that plug-ins must now be built with g++, except
 when GCC was configured with --disable-build-poststage1-with-cxx.  This
 seems difficult to deal with, for plug-in writers.
>>>
>>> This is an unfortunate truth during our transition to building gcc with
>>> C++.  There is going to be a period of time when the compiler may be
>>> built as either C or C++.  The end goal is for the compiler to always be
>>> built with C++, but until we reach that state I think plugin writers
>>> will have to test.
>>
>> What about wrapping the C API in extern "C"?
>
> We eventually will want the internal APIs to be C++, so this transition
> will inevitably happen at some point.

I understand the goal.  However, should a C++ API be added, the C-only
part could still be kept extern "C".

For 4.7.0, as Duncan Sands writes, it would be a very helpful for the
ABI to be independent of configuration options–i.e., either mangled or
unmangled symbols.

WDYT?

Thanks,
Ludo’.

Re: GCC 4.7.0RC: Mangled names in cc1

[Ian Lance Taylor]

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> Ian Lance Taylor  skribis:
>
>> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>
>>> Ian Lance Taylor  skribis:
>>>
 ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> However, this means that plug-ins must now be built with g++, except
> when GCC was configured with --disable-build-poststage1-with-cxx.  This
> seems difficult to deal with, for plug-in writers.

 This is an unfortunate truth during our transition to building gcc with
 C++.  There is going to be a period of time when the compiler may be
 built as either C or C++.  The end goal is for the compiler to always be
 built with C++, but until we reach that state I think plugin writers
 will have to test.
>>>
>>> What about wrapping the C API in extern "C"?
>>
>> We eventually will want the internal APIs to be C++, so this transition
>> will inevitably happen at some point.
>
> I understand the goal.  However, should a C++ API be added, the C-only
> part could still be kept extern "C".

We are talking here about internal GCC functions.  We are not talking
about an actual defined API.  The defined API is in plugin-api.h, and
that remains extern "C".  There is no "C-only part" of the internal API.


> For 4.7.0, as Duncan Sands writes, it would be a very helpful for the
> ABI to be independent of configuration options–i.e., either mangled or
> unmangled symbols.

That just postpones the pain to gcc 4.8.0.

Ian

Re: Building libstdc++ with current glibc, NULL and pthread.h

[Joseph S. Myers]

The answer from the Austin Group list was that the POSIX requirement
*does* mean all symbols from time.h are to be defined by pthread.h and
it's a bug in the change history that it refers to allowing rather
than requiring the symbols to be made visible.  Thus, I propose this
patch to make pthread.h define all symbols from time.h again, so that
NULL is defined and libstdc++ can build again.  (Given that the POSIX
change resulted from an interpretation request I think we don't need
to make this conditional on the version of POSIX selected but can
treat the omission of this requirement / permission as a defect in
older POSIX versions.)

Tested x86_64.

2012-03-09  Joseph Myers  

* sysdeps/pthread/pthread.h (__need_clockid_t, __need_timespec):
Do not define before including .

diff --git a/nptl/sysdeps/pthread/pthread.h b/nptl/sysdeps/pthread/pthread.h
index 0d33cbd..bd97e85 100644
--- a/nptl/sysdeps/pthread/pthread.h
+++ b/nptl/sysdeps/pthread/pthread.h
@@ -21,10 +21,6 @@
 #include 
 #include 
 #include 
-#ifdef __USE_XOPEN2K
-# define __need_clockid_t
-#endif
-#define __need_timespec
 #include 
 
 #include 

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Building libstdc++ with current glibc, NULL and pthread.h

[Roland McGrath]

The change seems fine.  But I think the log entry should have an explicit
pointer to the POSIX interpretation citation by way of rationale.

Thanks,
Roland

Re: Building libstdc++ with current glibc, NULL and pthread.h

[Joseph S. Myers]

On Fri, 9 Mar 2012, Roland McGrath wrote:

> The change seems fine.  But I think the log entry should have an explicit
> pointer to the POSIX interpretation citation by way of rationale.

I've committed it with references in the log to

https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-group-l&id=17302

and the two relevant POSIX interpretations.

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-4.6-20120309 is now available

[gccadmin]

Snapshot gcc-4.6-20120309 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120309/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch 
revision 185159

You'll find:

 gcc-4.6-20120309.tar.bz2 Complete GCC

  MD5=5d510275bc7934d1cdfc66b094420b24
  SHA1=508e65c1c22f7c0d829dd264f68eb4057842ba47

Diffs from 4.6-20120302 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: GCC 4.7.0RC: Mangled names in cc1

[David Malcolm]

On Fri, 2012-03-09 at 11:41 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Andrew Pinski  skribis:
> 
> > 2012/3/9 Ludovic Courtès :
> >
> >> I believe this is not intentional, right?
> >
> > No, this is intentional.  We bootstrap the compiler using the C++
> > front-end now.  We build stage1 with the C compiler and then build
> > stages 2 and 3 with the C++ compiler.

Aha - we've been running into problems with this when people try to
build the gcc python plugin on different distibution's builds of gcc [1]

> OK.
> 
> However, this means that plug-ins must now be built with g++, except
> when GCC was configured with --disable-build-poststage1-with-cxx.  This
> seems difficult to deal with, for plug-in writers.

Agreed; this makes life much more difficult for GCC plugins.

Dave

[1]
https://fedorahosted.org/pipermail/gcc-python-plugin/2012-March/000203.html