gmane.comp.gcc.devel

Re: Should --with-build-sysroot be default to --with-sysroot?

NightStrike — 2012-05-25T23:00:03

Happens to the best of us :)

gcc-4.6-20120525 is now available

2012-05-25T22:54:17

Snapshot gcc-4.6-20120525 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120525/
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 187900

You'll find:

 gcc-4.6-20120525.tar.bz2             Complete GCC

  MD5=b61c517c13afbfc306bebdfc33a2dd57
  SHA1=758ede6ec739e7bb8206f52c2a67dc937d761d10

Diffs from 4.6-20120518 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: Status of the PPH implementation

Jonathan Wakely — 2012-05-25T22:46:32

I'm not sure what this refers to (<ext/algorithm> either defines
__gnu_cxx::is_sorted or has a using declaration for std::is_sorted in
C++11 mode) but I'm very much in favour of anything that moves towards
support for modules, so if there's anything libstdc++-related I can do
to help please let me know.

Re: Status of the PPH implementation

Lawrence Crowl — 2012-05-25T22:00:10

Not off the top of my head.  While some of the problem is artifacts
of implementation, those artifacts are often driven by conflicting
standards requirements.  The C standard says x.h only exports symbols
a, b, and c.  The Posix standard says x.h exports d.  From there
you descend into what the OS folks fondly call "header hell".  :-)
The root problem is in the standards, and given the legacy code
base, it's going to be really hard to fix.  I suspect that with
convincing we could get alternate headers (or modules) defined with
better behavior.  I doubt we could change the existing headers.

[cxx-conversion] gcc-4.7.0 on Cygwin and MinGW32 with --enable-build-with-cxx successes

Aaron Gray — 2012-05-25T21:53:11

Hi,

Just to let people know I have succeeded in building gcc-4.7.0 with
--enable-build-with-cxx (All stages built as C++) on latest Cygwin
with GCC 4.5.3 and on MinGW32 with a rebuilt GCC 4.6.2 as the GCC
4.6.2 that came with MinGW was missing stdarg.h and stddef.h and
possibly other headers.

Many thanks,

Aaron

Re: Should --with-build-sysroot be default to --with-sysroot?

H.J. Lu — 2012-05-25T21:13:38

It was a pilot error.

Re: Status of the PPH implementation

Diego Novillo — 2012-05-25T20:26:26

There were several problems:

- Lack of double inclusion guards.

- Lack of modularity. For instance, accepting parameters to change the 
meaning of the file, stddef.h is the canonical example.

- Mutually recursive inclusion.  Some files seem to work in tandem, they 
include each other conditionally just in case the other has not been 
included yet.

- Some files refuse to be compiled in isolation because they are always 
included by a wrapper file (e.g. the bits/* files).

- Files that use #include_next (they cannot be compiled in isolation).

- Some files give syntax errors when compiled in isolation because they 
are missing symbols. for example, ext/algorithm needs __gnu_cxx::is_sorted.

Those are the ones I could gather on a quick grep through my build logs. 
  Lawrence may remember more.


Diego.

Re: Status of the PPH implementation

Joseph S. Myers — 2012-05-25T18:54:07


If feature test macros (or, similarly, assert.h depending on NDEBUG) are 
the problem then that would need to be addressed for standards - but if 
it's __need_* conditionals then those are an implementation detail for GCC 
and glibc and any changes would need sorting out in the communities for 
those toolchain components.  (I don't know how good the libstdc++ headers 
are at modularity, so I'm thinking about C headers, both those provided by 
GCC and those provided by glibc.)  Or is the issue with system headers 
something else entirely?

Re: Should --with-build-sysroot be default to --with-sysroot?

H.J. Lu — 2012-05-25T18:40:58

I am building GCC 4.7 with sysroot at /usr/gcc-x32-4.7/x86_64-linux
to support i386, x86-64 and x32.  I configured GCC 4.7 with

--target=x86_64-linux \
--enable-languages=c,c++,fortran --with-demangler-in-ld --enable-initfin
i-array --with-multilib-list=m32,m64,mx32 \
 \
--with-sysroot=/usr/gcc-x32-4.7/x86_64-linux \
--prefix=/usr/gcc-x32-4.7 \
--with-local-prefix=/usr/local

Build fails when compiling libgcc since ./gcc/xgcc -B.../gcc/ can't
find stdio.h.  After adding --with-build-sysroot=/usr/gcc-x32-4.7/x86_64-linux,
it builds fine.

Re: Should --with-build-sysroot be default to --with-sysroot?

NightStrike — 2012-05-25T18:36:55

Under what conditions does it fail?  We use it daily at mingw-w64.

On Fri, May 25, 2012 at 2:33 PM, H.J. Lu <hjl.tools< at >gmail.com> wrote:

Should --with-build-sysroot be default to --with-sysroot?

H.J. Lu — 2012-05-25T18:33:48

When --with-sysroot is used to configure gcc, build will usually fail
if  --with-build-sysroot isn't set.  Should  --with-build-sysroot be set to
the same value as --with-sysroot by default if --with-sysroot is used?

Re: Status of the PPH implementation

Diego Novillo — 2012-05-25T16:31:55

Yes.  Increased modularity in system headers is a must.  That is likely 
going to be one of the hard things to fix.  I'd rather have that 
discussion in the standards forums, as I suspect some of the same will 
be discussed for the module proposal.

In this context, I would like to discuss g++ specific issues.  Perhaps 
we can wait until the Cauldron meeting or we could start on e-mail. 
Whatever is more convenient.


Diego.

Re: Status of the PPH implementation

Jason Merrill — 2012-05-25T16:25:56

I was thinking the same thing.

Jason

Re: Status of the PPH implementation

Joseph S. Myers — 2012-05-25T15:37:43


One thing I wonder from this document is whether there are changes it 
would be useful to make to system headers (both in GCC and in glibc) to 
improve modularity.  You can't really get away from the dependence on 
feature test macros such as _GNU_SOURCE, but it seems reasonable to 
suppose that all source files in a project will use the same feature test 
macros, and it should be possible to eliminate the __need_* special cases 
for some system headers by having more, smaller headers set up to define 
individual types.

Re: Status of the PPH implementation

Diego Novillo — 2012-05-24T23:07:59

Geez, we can't attach pdf files on message to the list.

The document is at:
http://gcc.gnu.org/wiki/pph?action=AttachFile&do=view&target=pph-in-gcc.pdf


Diego.

gcc-4.5-20120524 is now available

2012-05-24T22:48:57

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

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

You'll find:

 gcc-4.5-20120524.tar.bz2             Complete GCC

  MD5=987f323fd9b4de2df8bec010a85f9253
  SHA1=aa914051b2e82adb1026a6f52f71665a05d4aa42

Diffs from 4.5-20120517 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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: error: call of overloaded ‘foo(int)’ is ambiguous (0 vs null ptr)

Jonathan Wakely — 2012-05-24T19:44:50

Please note that "is this valid" questions are not appropriate on this
mailing list, please use the gcc-help mailing list for questions about
using GCC or a general C++ forum, thanks.

There are (at least) two high-quality online compilers you can use to
see whether something you find surprising is a GCC bug or not:

http://comeaucomputing.com/tryitout/
http://llvm.org/demo/

They both agree with GCC.


IMHO no. The warning issues a diagnostic that may be desirable for
style reasons, your suggestion alters the language and makes any
program relying on it non-portable.

You can make it an error with -Werror=zero-as-null-pointer-constant
but that doesn't resolve any ambiguity.


Yes,an explicit cast works, or a literal that doesn't require
conversion, e.g. 0ul (assuming size_t is a synonym for unsigned long)
or an enumerator with value zero which would only allow conversion to
size_t, or in C++11 use the keyword nullptr.

Re: error: call of overloaded ‘foo(int)’ is ambiguous (0 vs null ptr)

Gabriel Dos Reis — 2012-05-24T19:38:52

On Thu, May 24, 2012 at 2:26 PM, Peter A. Felvegi
<petschy< at >praire-chicken.com> wrote:

this list is not the appropriate place to discuss this.
Check a C++ forum.


Welcome to null pointer constant madness.  It is standard semantics.

Fortunately 0-0 is no longer a null pointer constant
in C++11 appropriately amended.

error: call of overloaded ‘foo(int)’ is ambiguous (0 vs null ptr)

Peter A. Felvegi — 2012-05-24T19:26:46

Hello,

I'm not sure whether this is standard behaviour or not; nonetheless I 
was quite surprised:

----8<----8<----8<----
void foo(long);
void foo(const char*);

void bar()
{
         foo(0);
         foo(0+0); // !
         foo(1-1); // !
         foo(1);
}
----8<----8<----8<----

The first call to foo() in bar() is ambiguous, all right (integral or 
ptr), but the next two (marked w/ !) ? Shouldn't the compiler know that 
0+0 or 1-1, etc can't be a null pointer? I tried all minor versions from 
4.4 to 4.8.

Somewhat connected question: if I use |-Wzero-as-null-pointer-constant 
to detect cases where 0 means null pointer, shouldn't there be a switch 
that forbids conversion from 0 to null ptr? I have a class that has 
operator() overloaded for size_t and for const char* (access elements by 
index or by name). All is well, except for the index 0: the call would 
be ambiguous. I tried to trick this with 0+0, etc, hence the whole post. 
0.0 works, though. Any better ideas? Explicit cast?

Supposing that I eli

[gimplefe] Merge from trunk, preparation for gimple testsuite

Diego Novillo — 2012-05-24T18:32:29

I've merged trunk into gimple-front-end (rev 187836).

I've added a manifest file to use with 
contrib/testsuite-management/validate_failures.py.

Sandeep, this will be useful when we start having more gimple tests (see 
http://gcc.gnu.org/wiki/Testing_GCC#Using_validate_failures.py).  You 
can use the validator to filter out all the "expected" FAIL/XPASS 
results from other parts of the testsuite.

I will be posting the patches to add the basic dejagnu support for 
having gimple tests.


Tested on x86_64.


Diego.

RMS to present at the Cauldron

Diego Novillo — 2012-05-24T16:44:05

For those of you attending the Cauldron meeting in Prague in July, RMS 
will be in town and will come by to give a talk on the first day of the 
meeting.

See you there!