2012/7/4 Jonathan Wakely :
> At some point in the past few weeks it became impossible to build
> trunk from a sparse checkout that omits certain directories.
>
> Because I nearly always configure with --enable-languages=c,c++ I use
> git's core.sparseCheckout=true config or "svn update --set-depth"
After sending the email below, I found that an older gfortran version,
4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) does not have my bug 1 but does
have bug 2. Version 4.6.2 20120120 (prerelease) (GCC) has both bugs,
like version 4.8.0 20120701 (experimental) (GCC) mentioned below.
I showed this by co
My program testpublic5.f90 (see below) when compiled with -std=f95
using gfortran version 4.8.0 20120701 (experimental) (GCC)
reveals two compiler bugs, giving an unjustified warning and failing
to mention that the program violates an f95 constraint. It compiles
and runs with -std=f95 the same way
At some point in the past few weeks it became impossible to build
trunk from a sparse checkout that omits certain directories.
Because I nearly always configure with --enable-languages=c,c++ I use
git's core.sparseCheckout=true config or "svn update --set-depth" to
avoid checking out the front-end
Hello,
On Thu, 28 Jun 2012, Dimitrios Apostolou wrote:
http://teras-ics.mooo.com:8003/
I've updated the page with some more measurements, please let me know what
you think.
The primary issue I've not been able to resolve is with function name
demangling: Valgrind uses libiberty's demangle
On Wed, Jul 4, 2012 at 4:25 PM, Uros Bizjak wrote:
> Hello!
>
>> Since r188786, expmed.c has this code:
>
>> This results in warnings for expmed.c during bootstrap on
>> powerpc64-unknown-linux-gnu:
>>
>> ../../trunk/gcc/expmed.c: In function ‘rtx_def* expand_mult(machine_mode,
>> rtx,
>> rtx, rt
On 07/04/2012 09:41 AM, Richard Guenther wrote:
Btw, why use a bitmask? Isn't it enough to have a single number, viewed
as an ABI suffix?
Well, I think the question is whether we want to create a mechanism
which is only useful for libstdc++ versioning or one which is useful for
ABI changes i
Hello!
> Since r188786, expmed.c has this code:
> This results in warnings for expmed.c during bootstrap on
> powerpc64-unknown-linux-gnu:
>
> ../../trunk/gcc/expmed.c: In function ‘rtx_def* expand_mult(machine_mode, rtx,
> rtx, rtx, int)’:
> ../../trunk/gcc/expmed.c:3215:7: warning: ‘is_neg’ may
On Wed, 4 Jul 2012, Michael Matz wrote:
> It will by the way not break unnoticed: interfaces using the problematic
> types would be mangled differently, and hence c++98 code would silently
... would _not_ silently ...
> be resolved to a c++11 variant expecting a different layout.
On Wed, Jul 4, 2012 at 3:22 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 4 Jul 2012, Richard Guenther wrote:
>
>> > [... mangling change ...]
>>
>> That would not address the issue of interoperability of a C++03 library
>> with a C++11 program or vice versa if they are using any of the changed
>> int
Hi,
On Wed, 4 Jul 2012, Richard Guenther wrote:
> > [... mangling change ...]
>
> That would not address the issue of interoperability of a C++03 library
> with a C++11 program or vice versa if they are using any of the changed
> interfaces for interoperability. Passing pointers to such objec
On Wed, Jul 4, 2012 at 8:14 AM, Jakub Jelinek wrote:
> On Tue, Jul 03, 2012 at 05:01:29PM -0400, Jason Merrill wrote:
>> On 07/03/2012 03:18 PM, Jason Merrill wrote:
>> >It seems that ELF symbol versioning could be useful for this purpose. If
>> >we were to extend the visibility attribute to also
12 matches
Mail list logo
