On Fri, 3 Feb 2012, DJ Delorie wrote:
Jan Kara j...@suse.cz writes:
we've spotted the following mismatch between what kernel folks expect
from a compiler and what GCC really does, resulting in memory corruption on
some architectures. Consider the following structure:
struct x {
On Fri, Feb 03, 2012 at 09:37:22AM +, Richard Guenther wrote:
On Fri, 3 Feb 2012, DJ Delorie wrote:
Jan Kara j...@suse.cz writes:
we've spotted the following mismatch between what kernel folks expect
from a compiler and what GCC really does, resulting in memory corruption
On 2012-01-31 09:16:09 +0100, David Brown wrote:
For normal variables, a = b = 0 is just ugly - but that is a
matter of opinion.
and it is handled badly by GCC:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52106
(this is just a missing warning... Still, inconsistency is bad.)
--
Vincent
Hi,
Consider minimal reproduction code:
#include math.h
#include stdio.h
double __attribute__ ((noinline))
slip(double a)
{
return (cos(a) + sin(a));
}
int main(void)
{
double a = 4.47460300787e+182;
double slipped = slip(a);
printf(slipped = %lf\n, slipped);
return 0;
}
Compiling
On Fri, Feb 3, 2012 at 2:26 PM, Konstantin Vladimirov
konstantin.vladimi...@gmail.com wrote:
Hi,
Consider minimal reproduction code:
#include math.h
#include stdio.h
double __attribute__ ((noinline))
slip(double a)
{
return (cos(a) + sin(a));
}
int main(void)
{
double a =
On 2/3/2012 10:01 AM, Michael Matz wrote:
No normal math library supports such an extreme range, even basic
identities (like cos^2+sin^2=1) aren't retained with such inputs.
I agree: the program is complete nonsense. It would be useful to know
what the intent was.
Ciao,
Michael.
On 2012-02-03 10:13:58 -0500, Robert Dewar wrote:
On 2/3/2012 10:01 AM, Michael Matz wrote:
No normal math library supports such an extreme range, even basic
identities (like cos^2+sin^2=1) aren't retained with such inputs.
I agree: the program is complete nonsense.
I disagree: there may be
On 2/3/2012 10:28 AM, Vincent Lefevre wrote:
On 2012-02-03 10:13:58 -0500, Robert Dewar wrote:
On 2/3/2012 10:01 AM, Michael Matz wrote:
No normal math library supports such an extreme range, even basic
identities (like cos^2+sin^2=1) aren't retained with such inputs.
I agree: the program is
On 2012-02-03 10:33:58 -0500, Robert Dewar wrote:
On 2/3/2012 10:28 AM, Vincent Lefevre wrote:
If the user requested such a computation, there should at least be
some intent. Unless an option like -ffast-math is given, the result
should be accurate.
What is the basis for that claim? to me
Hi,
On Fri, 3 Feb 2012, Vincent Lefevre wrote:
No normal math library supports such an extreme range, even basic
identities (like cos^2+sin^2=1) aren't retained with such inputs.
I agree: the program is complete nonsense.
I disagree: there may be cases where large inputs can be
On 2012-02-03 16:57:19 +0100, Michael Matz wrote:
And it may be important that some identities (like cos^2+sin^2=1) be
preserved.
Well, you're not going to get this without much more work in sin/cos.
If you use the glibc sin() and cos(), you already have this (possibly
up to a few ulp's).
On 2/3/2012 10:55 AM, Vincent Lefevre wrote:
On 2012-02-03 10:33:58 -0500, Robert Dewar wrote:
On 2/3/2012 10:28 AM, Vincent Lefevre wrote:
If the user requested such a computation, there should at least be
some intent. Unless an option like -ffast-math is given, the result
should be accurate.
And I assume that since the compiler does them, that would now make it
impossible for us to gather a list of all the 'lock' prefixes so that
we can undo them if it turns out that we are running on a UP machine.
When we do SMP operations, we don't just add a lock prefix to it. We do this:
While I fail to see how the correct value of
cos(4.47460300787e+182)+sin(4.47460300787e+182)
can be defined in the 'double' world, cos^2(x)+sin^2(x)=1 and
sin(2*x)=2*sin(x)*cos(x) seems to be verified (at least for this value)
even if the actual values of sin and cos depends on the optimisation
Hi,
On Fri, 3 Feb 2012, Vincent Lefevre wrote:
For the glibc, I've finally reported a bug here:
http://sourceware.org/bugzilla/show_bug.cgi?id=13658
That is about 1.0e22, not the obscene 4.47460300787e+182 of the
original poster.
But 1.0e22 cannot be handled correctly.
On Fri, 3 Feb 2012, Dominique Dhumieres wrote:
Note that sqrt(2.0)*sin(4.47460300787e+182+pi/4) gives a diffeent value
for the sum.
In double: 4.47460300787e+182 + pi/4 == 4.47460300787e+182
Ciao,
Michael.
On Fri, Feb 3, 2012 at 8:38 AM, Andrew MacLeod amacl...@redhat.com wrote:
The atomic intrinsics were created for c++11 memory model compliance, but I
am certainly open to enhancements that would make them more useful. I am
planning some enhancements for 4.8 now, and it sounds like you may
Hi,
I agree, that this case have no practical value. It was autogenerated
between other thousands of tests and showed really strange results, so
I decided to ask. I thought, this value fits double precision range
and, according to C standard, all double-precision arithmetics must be
avaliable for
On 2/3/2012 1:12 PM, Konstantin Vladimirov wrote:
Hi,
I agree, that this case have no practical value. It was autogenerated
between other thousands of tests and showed really strange results, so
I decided to ask. I thought, this value fits double precision range
and, according to C standard,
On 02/03/2012 04:13 PM, Robert Dewar wrote:
On 2/3/2012 10:01 AM, Michael Matz wrote:
No normal math library supports such an extreme range, even basic
identities (like cos^2+sin^2=1) aren't retained with such inputs.
I agree: the program is complete nonsense. It would be useful to know
On 02/03/2012 12:16 PM, Linus Torvalds wrote:
So we have several atomics we use in the kernel, with the more common being
- add (and subtract) and cmpchg of both 'int' and 'long'
This would be __atomic_fetch_add, __atomic_fetch_sub, and
__atomic_compare_exchange.
For 4.8
On Fri, Feb 3, 2012 at 11:16 AM, Andrew MacLeod amacl...@redhat.com wrote:
The special cases are because older x86 cannot do the generic
add_return efficiently - it needs xadd - but can do atomic versions
that test the end result and give zero or sign information.
Since these are older x86
On Fri, Feb 03, 2012 at 12:00:03PM -0800, Linus Torvalds wrote:
On Fri, Feb 3, 2012 at 11:16 AM, Andrew MacLeod amacl...@redhat.com wrote:
[ . . . ]
Having access to __ATOMIC_ACQUIRE would actually be an improvement -
it's just that the architectures that really care about things like
that
Hello,
compiling the following:
---8---8---8---8---
templatetypename T
struct Base
{
typename T::Typevar;
};
templatetypename U
struct Derived : BaseDerivedU
{
typedef U Type;
};
void foo()
{
Derivedint i;
}
---8---8---8---8---
gives the error
On 2012-02-03 11:35:39 -0500, Robert Dewar wrote:
On 2/3/2012 10:55 AM, Vincent Lefevre wrote:
On 2012-02-03 10:33:58 -0500, Robert Dewar wrote:
What is the basis for that claim? to me it seems useless to expect
anything from such absurd arguments. Can you site a requirement to
the contrary
On 2012-02-03 17:44:21 +0100, Michael Matz wrote:
Hi,
On Fri, 3 Feb 2012, Vincent Lefevre wrote:
For the glibc, I've finally reported a bug here:
http://sourceware.org/bugzilla/show_bug.cgi?id=13658
That is about 1.0e22, not the obscene 4.47460300787e+182 of the
On 2/3/2012 4:32 PM, Vincent Lefevre wrote:
Yes, I do! The floating-point representation of this number
This fact is not even necessarily correct because you don't know the
intent of the programmer. In the program,
double a = 4.47460300787e+182;
could mean two things:
1. A number
On 3 February 2012 21:28, Peter A. Felvegi wrote:
on all tested gcc versions (4.4, 4.5, 4.6,4.7). There is definitely a type
called 'Type' in struct 'Derived'. I'm not sure, the above code might be
ill-formed, but then I'd like to see a specific error message.
I think the problem is that
Snapshot gcc-4.6-20120203 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120203/
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
On 3 February 2012 16:24, Vincent Lefevre vincent+...@vinc17.org wrote:
On 2012-02-03 16:57:19 +0100, Michael Matz wrote:
And it may be important that some identities (like cos^2+sin^2=1) be
preserved.
Well, you're not going to get this without much more work in sin/cos.
If you use the
On 3 February 2012 18:12, Konstantin Vladimirov
konstantin.vladimi...@gmail.com wrote:
Hi,
I agree, that this case have no practical value. It was autogenerated
between other thousands of tests and showed really strange results, so
I decided to ask. I thought, this value fits double precision
On 2012-02-03 17:40:05 +0100, Dominique Dhumieres wrote:
While I fail to see how the correct value of
cos(4.47460300787e+182)+sin(4.47460300787e+182)
can be defined in the 'double' world, cos^2(x)+sin^2(x)=1 and
sin(2*x)=2*sin(x)*cos(x) seems to be verified (at least for this value)
even if
On 2012-02-03 16:51:22 -0500, Robert Dewar wrote:
All machines that implement IEEE arithmetic :-) As we know only too well
from the universe of machines on which we implement GNAT, this is not
all machines :-)
But I think that machines with no IEEE support will tend to disappear
(and already
On 2012-02-03 22:57:31 +, James Courtier-Dutton wrote:
On 3 February 2012 16:24, Vincent Lefevre vincent+...@vinc17.org wrote:
But 1.0e22 cannot be handled correctly.
Of course it can't.
You only have 52 bits of precision in double floating point numbers.
Wrong. 53 bits of precision.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52102
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #39 from Iain Sandoe iains at gcc dot gnu.org 2012-02-03 08:22:56
UTC ---
(In reply to comment #37)
(In reply to comment #36)
You would probably have to use Availability.h and something like...
This is not required, (and likely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #40 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
08:46:20 UTC ---
Created attachment 26558
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26558
disable __GTHREAD_RECURSIVE_MUTEX_INIT for Lion
Thanks, Iain.
I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #32 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
08:50:24 UTC ---
Created attachment 26559
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26559
proposed patch
Since a similar problem exists for darwin11's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
08:52:17 UTC ---
Oops, this hunk would be needed too
--- a/libstdc++-v3/src/c++11/condition_variable.cc
+++ b/libstdc++-v3/src/c++11/condition_variable.cc
@@ -36,7 +36,7 @@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #41 from Iain Sandoe iains at gcc dot gnu.org 2012-02-03 09:04:02
UTC ---
(In reply to comment #40)
Created attachment 26558 [details]
disable __GTHREAD_RECURSIVE_MUTEX_INIT for Lion
Thanks, Iain.
I'm thinking of something
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52103
Bug #: 52103
Summary: need a finer control over -Woverloaded-virtual
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52103
--- Comment #1 from mlg mlg7 at yandex dot ru 2012-02-03 09:14:36 UTC ---
$ g++ --version
g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc. [...]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #42 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
09:18:36 UTC ---
That header isn't even installed, let alone included, on other targets
Jack, if you test it please change == to = in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49204
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.7.0 |4.8.0
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48512
--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-03 09:42:46
UTC ---
Author: ktietz
Date: Fri Feb 3 09:42:42 2012
New Revision: 183867
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183867
Log:
PR libjava/48512
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2012-02-03 09:48:15 UTC ---
Since a similar problem exists for darwin11's
PTHREAD_RECURSIVE_MUTEX_INITIALIZER this solution is not OSF-specific. This
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2012-02-03 09:50:39 UTC ---
--- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
08:52:17 UTC ---
Oops, this hunk would be needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
Bug #: 52104
Summary: go1 fails to link on Solaris 8/9 x86 with native TLS
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52103
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
--- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-02-03 10:05:14 UTC
---
Created attachment 26560
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26560
preprocessed input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
--- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2012-02-03 10:05:57 UTC
---
Created attachment 26561
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26561
assembler input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52100
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
10:11:40 UTC ---
Looks as though we need an extra explicit instantiation in src/c++11/future.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52095
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52103
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
10:13:55 UTC ---
You can use C++11 explicit override control:
struct B {
virtual void f(int);
};
struct D : B {
void f(long) override; // error: doesn't override
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2012-02-03 10:21:03 UTC ---
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
10:11:40 UTC ---
Looks as though we need an extra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48512
--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-03 10:35:11
UTC ---
Author: ktietz
Date: Fri Feb 3 10:35:06 2012
New Revision: 183868
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183868
Log:
PR libjava/48512
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48512
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
10:48:16 UTC ---
Are you sure this is using native TLS?
This part of the 49204 commit:
(__future_base::_Async_state_common::_M_join): Serialize attempts to
join
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-03
10:50:02 UTC ---
If I try the example of comment 4 with the line break before undone and
using the newest 4.7 trunk (clean build), I see in valgrind:
==14154== Invalid read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2012-02-03 10:55:07 UTC ---
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
10:48:16 UTC ---
Are you sure this is using native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
11:08:47 UTC ---
So fixing that configure test should make the problem go away?
There's still a problem on non-TLS targets though. I have no idea how to
explicitly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52092
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-03
11:55:33 UTC ---
Author: jakub
Date: Fri Feb 3 11:55:29 2012
New Revision: 183869
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183869
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52092
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52105
Bug #: 52105
Summary: Improved dead code identifying -Wunused-function?
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52106
Bug #: 52106
Summary: missing -Wunused-but-set-variable warning with the a =
b = ... construct
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52095
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52095
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-03
12:50:33 UTC ---
Created attachment 26562
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26562
gcc47-pr52095.patch
Untested fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52106
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52107
Bug #: 52107
Summary: IBM 128bit long double constant loaded inefficiently
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52095
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2012-02-03 13:06:19 UTC ---
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-03
12:50:33 UTC ---
Untested fix.
I've just re-built cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
CC||bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52102
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-03
13:21:43 UTC ---
From the dump:
two.a._data.data = (void * restrict) __builtin_malloc (8);
__builtin_memset (two.a._data.data, 0, 8);
two.a._data.offset = -1;
{
struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52106
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52105
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52106
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52107
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52102
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-03
13:37:39 UTC ---
Related issue with MOLD=, here one gets with x = 5 default initialization and
allocate (two%a(8), mold=t(4))
print '(*(i2))', two%a(:)%x
the result:
0 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52108
Bug #: 52108
Summary: declval() with incomplete type
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51514
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51514
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-03
14:28:56 UTC ---
cf. also PR 51514.
? wrong pr?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52108
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52109
Bug #: 52109
Summary: Apparently endless recursive instantiation
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
--- Comment #36 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-03
15:05:55 UTC ---
I lost a bit the overview, but I think the following still needs to be done:
- 4.4/4.5/4.6: Backporting the fix for nonpresent actuals to elemental procs,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52109
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
15:06:38 UTC ---
fixed in 4.7.0, you get a nice 14 line error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51514
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-03
15:09:16 UTC ---
(In reply to comment #2)
cf. also PR 51514.
? wrong pr?
No, why should it be wrong? - Clearly this PR is related to itself...
(I meant PR 50981 - and in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110
Bug #: 52110
Summary: s-osinte.ads:447:09: clockid_t conflicts with
declaration at line 194
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52109
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110
--- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-02-03
16:21:17 UTC ---
Removing declaration at s-taspri-hpux-dce.ads, I get:
/xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52111
Bug #: 52111
Summary: [OOP] procedure pointer with polymorphic passed dummy
argument
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52111
--- Comment #1 from alexander tismer nagl46 at web dot de 2012-02-03 16:22:36
UTC ---
Created attachment 26564
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26564
program that produces compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060
Ian Bolton ibolton at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #43 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-03
17:00:49 UTC ---
(In reply to comment #42)
That header isn't even installed, let alone included, on other targets
Jack, if you test it please change == to = in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52112
Bug #: 52112
Summary: Vectorizer fails when using CRTP
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #44 from Iain Sandoe iains at gcc dot gnu.org 2012-02-03 17:14:43
UTC ---
if you are saying that:
code targeted at 10.6 produced on 10.7 (using the correct 10.6 SDK) doesn't run
properly on 10.7
- no surprise - that's just exposing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #45 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
17:16:38 UTC ---
Then I think we have to disable __GTHREAD_RECURSIVE_MUTEX_INIT unconditionally
on darwin.
If the bug is later fixed in (say) 10.8 then we could use the init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52106
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Summary|warning for useless |[C11] missing
1 - 100 of 219 matches
Mail list logo
