[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48086 --- Comment #21 from Jack Howarth howarth at nitro dot med.uc.edu 2011-03-14 06:10:09 UTC --- We also need to scratch the section of http://gcc.gnu.org/gcc-4.6/changes.html under Darwin/Mac OS X which says... LTO-support. Darwin has benefited from ongoing work on LTO; support for this is now stable and enabled by default.
[Bug bootstrap/48102] [4.6 Regression] Bootstrap failure: error: macro build_cloog_prog requires 4 arguments, but only 3 given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48102 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 08:18:57 UTC --- Author: jakub Date: Mon Mar 14 08:18:52 2011 New Revision: 170933 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170933 Log: PR bootstrap/48102 * graphite-cloog-compat.h (build_cloog_prog): Remove STATE parameter. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-cloog-compat.h
[Bug bootstrap/48102] [4.6 Regression] Bootstrap failure: error: macro build_cloog_prog requires 4 arguments, but only 3 given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48102 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 08:23:02 UTC --- Should be fixed now.
[Bug lto/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108
--- Comment #3 from Iain Sandoe iains at gcc dot gnu.org 2011-03-14 09:00:52
UTC ---
(In reply to comment #2)
Another fix might be to have pure elf .o files... ld I think will read elf .o
files... [s] Don't tell anyone I said that. If not, we might be able
to
get Apple to do that. This might then require an FSF binutils.
In the short term, a wrapper around the LTO stuff with a more sophisticated
index seems a lot easier.
However, it is in the back of my mind to split the machopic stuff out of
darwin* somewhen in 4.7 so that darwin sections could be used in an elf (or
other supporting named sections) container (and give us a route for removing
the conditionalization on TARGET_MACHO from config/{i386,rs6000}/ )
WDYT?
[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42566 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Known to work||4.5.2 Keywords||ice-on-valid-code Last reconfirmed||2011.03.14 09:21:19 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 Summary|internal compiler error: in |[4.6 Regression] internal |build_vector_from_val, at |compiler error: in |tree.c:1380 |build_vector_from_val, at ||tree.c:1380 Target Milestone|--- |4.6.0 Known to fail||4.6.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 09:21:19 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=166136 together with the earlier http://gcc.gnu.org/viewcvs?view=revisionrevision=166102 change.
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14
09:29:02 UTC ---
Smaller testcase:
void
foo (int n)
{
static char *__restrict *p;
int i;
p = __builtin_malloc (n);
for (i = 0; i n; i++)
p[i] = 0;
}
The reason why the conversion between char * types isn't useless is that one of
the pointers is TYPE_RESTRICT, while the other one is not.
--- gcc/tree.c.jj2011-03-11 12:16:39.0 +0100
+++ gcc/tree.c2011-03-14 10:27:25.0 +0100
@@ -1376,8 +1376,8 @@ build_vector_from_val (tree vectype, tre
if (sc == error_mark_node)
return sc;
- gcc_assert (useless_type_conversion_p (TREE_TYPE (sc),
- TREE_TYPE (vectype)));
+ gcc_assert (useless_type_conversion_p (TYPE_MAIN_VARIANT (TREE_TYPE (sc)),
+ TYPE_MAIN_VARIANT (TREE_TYPE (vectype;
v = VEC_alloc (constructor_elt, gc, nunits);
for (i = 0; i nunits; ++i)
fixes the ICE, but I wonder whether it isn't instead a bug in the vectorizer.
[Bug objc/48109] New: Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 Summary: Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: ia...@gcc.gnu.org Host: *-apple-darwin* Target: *-apple-darwin* Build: *-apple-darwin* This is a FE bug that manifests only on Darwin/NeXT (m32) under LTO. (originally reported as part of PR48094) e.g. -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libobjc/.libs -lobjc -m32 -o objc-dg-lto-trivial-1-21(timeout = 300) ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in /var/tmp//ccMlEsXS.lto.o^M Undefined symbols for architecture i386:^M .objc_class_name_myRootObject, referenced from:^M pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M ld: symbol(s) not found for architecture i386^M --- The reason is an anachronism in using target macros to emit efficient representations of class presence and requirement (ASM_DECLARE_CLASS_REFERENCE/ASM_DECLARE_UNRESOLVED_REFERENCE). .. because of this, there are no real vars representing the presence/requirement for the classes and, when LTO is engaged, the information is lost. The separate external defs/refs are required because the class metadata structures are all local to a given TU. The refs meet the linkage requirements. For the m64 ABI-2 this is not longer an issue, since class metadata definitions are now external and thus visible without additional action.
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P3 Target Milestone|4.6.0 |--- --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 09:38:12 UTC --- Though, apparently make_vector_type intentionally uses TYPE_MAIN_VARIANT of innertype as VECTOR_TYPE's type, and puts the quals on the vector type itself. Richard, what do you prefer?
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 2011-03-14 09:40:07 UTC --- (In reply to comment #3) (In reply to comment #2) (b) the second needs more checking - the tests pass on darwin9 (and darwin10 with 3.2.5 - last time I tried) it looks like the .lazy_reference to . objc_class_name_myRootObject is getting dropped somewhere; in this instance, because the code is self-contained, it works OK (when ld doesn't barf). ... in other cases in the test-suite, the only external object is usually Object which is in libobjc and therefore it also works. I have an idea about getting rid of the TARGET_ASM method to make these references and use a real variable to carry the information (just make it zero-sized, and use that + a meta-data tag to emit the efficient asm). I was intending to make that a stage-1 investigation -- but perhaps it might warrant trying sooner. this is now PR48109 -- and a separate issue, please use PR48094 to track the image_info issue.
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 09:59:32 UTC --- Just swapping the order of arguments to useless_type_conversion_p works too. If we consider build_vector_from_val as conversion from sc's type to the inner type of the vector, then vectype's inner type as outer_type needs to go first: --- gcc/tree.c.jj2011-03-11 12:16:39.0 +0100 +++ gcc/tree.c2011-03-14 10:57:21.0 +0100 @@ -1376,8 +1376,8 @@ build_vector_from_val (tree vectype, tre if (sc == error_mark_node) return sc; - gcc_assert (useless_type_conversion_p (TREE_TYPE (sc), - TREE_TYPE (vectype))); + gcc_assert (useless_type_conversion_p (TREE_TYPE (vectype), + TREE_TYPE (sc))); v = VEC_alloc (constructor_elt, gc, nunits); for (i = 0; i nunits; ++i)
[Bug tree-optimization/48052] loop not vectorized if index is unsigned int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
--- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch
2011-03-14 10:08:29 UTC ---
It is interesting to note that in case of fixed size (such as in these trivial
or template examples)
vectorization works also for unsigned int
void loop10( double const * __restrict__ x_in, double * __restrict__ x_out,
double const * __restrict__ c) {
for(unsigned int i=0; i!=10; ++i)
x_out[i] = c[i]*x_in[i];
}
templatetypename T, unsigned int N
void loopTu( T const * __restrict__ x_in, T * __restrict__ x_out, T const *
__restrict__ c) {
for(unsigned int i=0; i!=N; ++i)
x_out[i] = c[i]*x_in[i];
}
templatetypename T, unsigned long long N
void loopTull( T const * __restrict__ x_in, T * __restrict__ x_out, T const *
__restrict__ c) {
for(unsigned long long i=0; i!=N; ++i)
x_out[i] = c[i]*x_in[i];
}
void go(double const * __restrict__ x_in, double * __restrict__ x_out, double
const * __restrict__ c) {
loopTudouble,10(x_in, x_out, c);
loopTulldouble,10(x_in, x_out, c);
}
[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 --- Comment #1 from Mike Stump mikestump at comcast dot net 2011-03-14 10:23:19 UTC --- Not sure it matters, but, marking them as used should be enough... Note, there are a couple of ways to mark things. TREE_USED and the lto incantation.
[Bug target/48077] [Code Improvement] Poor expansion of multiply on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48077 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 10:26:33 UTC --- Thus, works fine.
[Bug target/48082] Problem compiling function that returns va_list on 64 bit system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48082 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 10:27:06 UTC --- .
[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.14 10:29:40
Ever Confirmed|0 |1
--- Comment #2 from Iain Sandoe iains at gcc dot gnu.org 2011-03-14 10:29:40
UTC ---
(In reply to comment #1)
Not sure it matters, but, marking them as used should be enough... Note,
there
are a couple of ways to mark things. TREE_USED and the lto incantation.
they never exist to be marked:
handle_next_class_ref (tree chain)
{
const char *name = IDENTIFIER_POINTER (TREE_VALUE (chain));
char *string = (char *) alloca (strlen (name) + 30);
sprintf (string, .objc_class_name_%s, name);
#ifdef ASM_DECLARE_UNRESOLVED_REFERENCE
ASM_DECLARE_UNRESOLVED_REFERENCE (asm_out_file, string);
this just emits .lazy_reference .objc_class_name_x
#else
return ; /* NULL build for targets other than Darwin. */
#endif
}
[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48088 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.14 10:29:28 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 10:29:28 UTC --- Yeah. Confirmed. You need -Wframe-larger-than=500 -Werror=frame-larger-than which hopefully doesn't reset the value to 1.
[Bug middle-end/48110] New: __attribute__ ((optimize(...))) version of -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48110 Summary: __attribute__ ((optimize(...))) version of -Ofast Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch gcc 4.6 introduces a new global optimization switch -Ofast. Independently of what actually it is composed of, it seems not supported by __attribute__ ((optimize(...))) for instance __attribute__ ((optimize(fast-math))) works __attribute__ ((optimize(3))) works while __attribute__ ((optimize(fast))) produces error: unrecognized command line option '-ffast' is this a bug or shall I use a different syntax?
[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48090 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Component|c |target Known to work||4.4.5, 4.6.0 Target Milestone|--- |4.5.3 Summary|gcc 4.5.2 miscompilation|[4.5 Regression] gcc 4.5.2 |when building on arm|miscompilation when ||building on arm
[Bug c/48091] No warning when given function arguments mismatch earlier, old style KR function definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48091 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 10:33:21 UTC --- That's how KR works. The function definition isn't a prototype.
[Bug c/46028] Regression from GCC 4.4: storage size of 'test_array' isn't constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46028
philipp at marek dot priv.at changed:
What|Removed |Added
CC||philipp at marek dot
||priv.at
--- Comment #4 from philipp at marek dot priv.at 2011-03-14 10:37:15 UTC ---
This fails, too: error: storage size of ‘sv’ isn’t constant
int main(void)
{
const int len = 20;
static char sv[len];
}
Similarly, gcc 4.4 accepted
#define CONST_STRING aaa
static char x[strlen(CONST_STRING)];
but gcc-4.5 does not.
(Of course, I could overload strlen ... but whether that's enough reason to
reject that?)
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 10:43:09 UTC --- (In reply to comment #5) Just swapping the order of arguments to useless_type_conversion_p works too. If we consider build_vector_from_val as conversion from sc's type to the inner type of the vector, then vectype's inner type as outer_type needs to go first: --- gcc/tree.c.jj2011-03-11 12:16:39.0 +0100 +++ gcc/tree.c2011-03-14 10:57:21.0 +0100 @@ -1376,8 +1376,8 @@ build_vector_from_val (tree vectype, tre if (sc == error_mark_node) return sc; - gcc_assert (useless_type_conversion_p (TREE_TYPE (sc), - TREE_TYPE (vectype))); + gcc_assert (useless_type_conversion_p (TREE_TYPE (vectype), + TREE_TYPE (sc))); v = VEC_alloc (constructor_elt, gc, nunits); for (i = 0; i nunits; ++i) The assert is supposed to make sure that in vectorized code vector extracts use the correct type for assignments to scalars. Thus if we have before vectorization scalar = X; and we vectorized the code that produced X we should use a vector type for the vector result X that has an element type that is trivially convertible to that of the above scalar. Thus, before and after vectorization useless_type_conversion_p (type-of-scalar, type-of-vector-element-type) should be true. The scalar X is sc above which is trivially convertible to scalar, so if type-of-vector-element-type is trivially convertible to X then it's trivially convertible to scalar. Thus the assert is correct. I think treating restrict as ordinary qualifier in make_vector_type is bogus, similarly not properly maintaining a ref-all qualification. I suppose nobody thought of pointer vector element types before. I'll cook up a patch.
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 10:50:57 UTC --- It doesn't seem to strip ref-all, that isn't a variant kind.
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 10:58:06 UTC --- Hm, we also want the elements to be trivially convertible to the vector element type. So we really want to assert types_compatible_p. I can't see any real problems with the restrict case in question, apart from maybe ICEing in a different place. Any fix at this point seems to be more risky than just disabling the assert.
[Bug lto/48100] [4.6 Regression] Assertion failed in lto_varpool_replace_node, at lto-symtab.c:304 with mixed LTO/non-LTO objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48100 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.14 11:23:58 CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.6.0 Summary|[4.6 Regression] Assertion |[4.6 Regression] Assertion |failed in |failed in |lto_varpool_replace_node, |lto_varpool_replace_node, |at lto-symtab.c:304 |at lto-symtab.c:304 with ||mixed LTO/non-LTO objects Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 11:23:58 UTC --- Confirmed. We do not handle commons (multiple defs) gracefully that the linker plugin chooses the prevailing def from a non-IL file from. 2 i.o 1 79 a37d8495 RESOLVED_EXEC i m.o 2 79 c7371d0 PREVAILING_DEF main 84 c7371d0 RESOLVED_EXEC i so it chose i-nonlto.o to provide i but we don't see that (obviously). It works when re-ordering the object files on the command-line so it chooses i.o as the provider. Something to think about (also in the context of C++ comdat groups).
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Component|lto |target Severity|normal |enhancement
[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 11:27:31 UTC --- I suppose a special kind of alias could be invented here.
[Bug lto/48100] [4.6 Regression] Assertion failed in lto_varpool_replace_node, at lto-symtab.c:304 with mixed LTO/non-LTO objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48100 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #32 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-14 11:34:00 UTC --- Created attachment 23648 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23648 Proposed patch
[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 --- Comment #4 from Iain Sandoe iains at gcc dot gnu.org 2011-03-14 11:36:29 UTC --- (In reply to comment #3) I suppose a special kind of alias could be invented here. I was thinking of a normal var - tagged with our ObjC meta-data attribute - and then handled in the back end. - this is supposing that varasm.c would be a valid place to recognize ASM_DECLARE_CLASS_REFERENCE/ASM_DECLARE_UNRESOLVED_REFERENCE (or a suitable hook to replace them) - alternatively, the var could be zero-sized, which (together with the ObjC meta-data attribute) can be picked up in darwin.c (but that's maybe kinda hacky).
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 11:41:53 UTC --- I think you should add below the hunk defining conditionally GF_CLOCK_MONOTONIC: #ifndef GF_CLOCK_MONOTONIC #undef HAVE_CLOCK_GETTIME #undef HAVE_CLOCK_GETTIME_LIBRT #endif now that you don't define GF_CLOCK_MONOTONIC if CLOCK_REALTIME isn't defined.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #34 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-14 11:42:47 UTC --- (In reply to comment #31) That being said, I'd prefer to postpone this fix to stage 1 due to - I'm currently moving flats so my stuff is all over and I'm very busy - AFAIU 4.6 release is imminent? - I lack the ability to test all weird and wonderful targets. - This close to release I'd very much like to avoid regressions in primary or secondary targets. - As can be seen in the reopening of this PR, for less used targets there might anyway be a month latency between something landing in trunk and getting test reports. Not really: the delay was caused because the test system broke and it took me quite some time to get myself a replacement. Normally, I bootstrap everywhere once a week and analyse results. Ok, that's nice to hear. Of course, it doesn't change the fact that this time it did take a month, and, one might add, at almost the worst possible moment. ;) Thus, I'd suggest fixing this in stage 1, then, after getting reports that the fix works, backport hopefully in time for 4.6.1. Of course, the above is only my own justifications and constraints; if someone else wants to fix it ASAP, go right ahead. I'd really like to see this fixed before 4.6.0: it is a regression from 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively minor gain on other platforms. Well, do we really have any actual gfortran users on Tru64? Whereas a high-resolution monotonic clock, while admittedly not a huge feature per se, is something that is now available to gfortran users on some rather more popular platforms. If all else fails, I'd go as far as advocating to revert the patch that introduced clock_gettime There has been a number of patches in this area more or less related to clock_gettime, so IMHO fixing it properly is simpler and less prone to introduce new regressions. My previous message in this PR hopefully does exactly this and introduces a patch which should fix it along the lines previously discussed. As my normal gcc development machine is packed in a box, I haven't been able to test it. Also, note that it won't apply cleanly as the paths are messed up (but the contents should otherwise apply fine). As I mentioned previously, I'd prefer to commit it after the 4.6 release, but if the reviewer(s) feel it's safe I'm fine with getting it in for 4.6. (and quite late in the release cycle, I might say). Yes, it started out as a simple patch which turned into a morass of system-dependent stuff wrt. where clock_gettime lives and various levels of weakref support. Sorry about that.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #35 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-14 11:50:26 UTC --- (In reply to comment #33) I think you should add below the hunk defining conditionally GF_CLOCK_MONOTONIC: #ifndef GF_CLOCK_MONOTONIC #undef HAVE_CLOCK_GETTIME #undef HAVE_CLOCK_GETTIME_LIBRT #endif now that you don't define GF_CLOCK_MONOTONIC if CLOCK_REALTIME isn't defined. Thanks; that should protect against the case where clock_gettime is available but neither CLOCK_REALTIME nor CLOCK_MONOTONIC are. Ideally, this shouldn't be necessary as POSIX specifies that CLOCK_REALTIME must always be available if clock_gettime exists, but I suppose both belts and suspenders are nice in this case.. :)
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #36 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 12:07:54 UTC --- CLOCK_REALTIME should be available, at least on POSIX compliant systems, but must it be defined as preprocessor macro? http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html talks about manifest constants, not macros. So it wouldn't surprise me if it was defined in an enum rather than using #define. Alternatively to those undefs would be to do #ifdef CLOCK_MONOTONIC #define GF_CLOCK_MONOTONIC CLOCK_MONOTONIC #else #define GF_CLOCK_MONOTONIC CLOCK_REALTIME #endif and just keep using GF_CLOCK_MONOTONIC only in code guarded with HAVE_CLOCK_GETTIME or HAVE_CLOCK_GETTIME_LIBRT, or #ifdef CLOCK_MONOTONIC #define GF_CLOCK_MONOTONIC CLOCK_MONOTONIC #elif defined (HAVE_CLOCK_GETTIME) || defined (HAVE_CLOCK_GETTIME_LIBRT) #define GF_CLOCK_MONOTONIC CLOCK_REALTIME #endif if you prefer that.
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 12:22:32 UTC --- Author: rguenth Date: Mon Mar 14 12:20:48 2011 New Revision: 170934 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170934 Log: 2011-03-14 Richard Guenther rguent...@suse.de PR middle-end/48098 * tree.c (build_vector_from_val): Adjust assert to requirements and reality. * gcc.dg/torture/pr48098.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48098.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug other/48111] New: libquadmath: strtoflt128 bug on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48111 Summary: libquadmath: strtoflt128 bug on MinGW Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net Created attachment 23649 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23649 Output of test case The test case from http://gcc.gnu.org/bugzilla/attachment.cgi?id=23382 fails in very strange ways. Tested with MinGW gcc version 4.6.0 20110312 (experimental) (GCC) build from equation.com Attaching output. strtoflt128 (.125) test 3BAD returns 0.12500029103830463509967191315652712546580005437135696411, expected 0.125 ... strtoflt128 (5.9e-76) test 7BAD returns 5.908177078951814709694457648319260185199116900204171e-76, expected 5.859059012423657042231762819e-76
[Bug tree-optimization/48098] [4.6 Regression] internal compiler error: in build_vector_from_val, at tree.c:1380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48098 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 12:35:29 UTC --- Fixed.
[Bug fortran/48112] New: generic interface to external function in module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48112 Summary: generic interface to external function in module Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: mh...@gmx.at Created attachment 23650 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23650 test case Compiling the Fortran module module module_m interface test function test1( ) result( test ) integer :: test end function test1 end interface test end module module_m with gfortran-4.6.0 leads to an internal compiler error. The error occurs because the name of the result variable is equal to the generic name. If the same interface is in a Fortran program no error occurs. $ gfortran-4.6 -v -c module_m.f90 Using built-in specs. COLLECT_GCC=gfortran-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6-20110227-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.0 20110227 (experimental) [trunk revision 170543] (Debian 4.6-20110227-1) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.0/f951 module_m.f90 -quiet -dumpbase module_m.f90 -mtune=generic -march=x86-64 -auxbase module_m -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/4.6.0/finclude -o /tmp/ccrmvWWY.s GNU Fortran (Debian 4.6-20110227-1) version 4.6.0 20110227 (experimental) [trunk revision 170543] (x86_64-linux-gnu) compiled by GNU C version 4.6.0 20110227 (experimental) [trunk revision 170543], GMP version 4.3.2, MPFR version 3.0.0-p8, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (Debian 4.6-20110227-1) version 4.6.0 20110227 (experimental) [trunk revision 170543] (x86_64-linux-gnu) compiled by GNU C version 4.6.0 20110227 (experimental) [trunk revision 170543], GMP version 4.3.2, MPFR version 3.0.0-p8, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 module_m.f90:7.19: end module module_m 1 Internal Error at (1): f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
[Bug rtl-optimization/47166] [4.5 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #31 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-14 13:46:20 UTC --- Author: rsandifo Date: Mon Mar 14 13:46:12 2011 New Revision: 170939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170939 Log: gcc/testsuite/ PR rtl-optimization/47166 * gcc.c-torture/execute/postmod-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/postmod-1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/47166] [4.5 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #32 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-14 13:48:48 UTC --- Author: rsandifo Date: Mon Mar 14 13:48:46 2011 New Revision: 170940 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170940 Log: gcc/testsuite/ PR rtl-optimization/47166 * gcc.c-torture/execute/postmod-1.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/postmod-1.c Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug inline-asm/37895] AVR inline assembly clobbers input value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37895 --- Comment #3 from Rudolf Leitgeb Rudolf.Leitgeb at gmx dot at 2011-03-14 13:52:15 UTC --- Wow, it's a while since I reported this issue... and the problem seems to have gone away with newer versions of avr-gcc, I just tried version 4.3.5 which comes with Ubuntu 10.10. So, please go ahead and close it.
[Bug libstdc++/48113] New: [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113
Summary: [C++0x] bind with tuple argument fails
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: martin.kronbich...@it.uu.se
Compiler version:
$ gcc-4.6 -v
Using built-in specs.
COLLECT_GCC=gcc-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran,objc,obj-c++,go
--prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --without-included-gettext
--enable-threads=posix --program-suffix=-4.6 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=core2 --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-cpu=core2
Thread model: posix
gcc version 4.6.0 20110312 (experimental) (GCC)
(weekly snapshot on x86_64)
On the following code:
#include functional
void test_1 (std::tupleint);
void test (int tst) {
const std::functionvoid() fun (std::bind(test_1, std::tupleint(tst)));
};
with the command line g++-4.6 -std=c++0x -c bind_test.cc -o bind_tst.o, I get
the following error message:
In file included from bind_test.cc:2:0:
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/functional:
In static member function ‘static void std::_Function_handlervoid(_ArgTypes
...), _Functor::_M_invoke(const std::_Any_data, _ArgTypes ...) [with _Functor
= std::_Bindvoid (*(std::tupleint))(std::tupleint), _ArgTypes = {}]’:
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/functional:2135:6:
instantiated from ‘std::function_Res(_ArgTypes ...)::function(_Functor,
typename std::enable_if(! std::is_integral_Functor::value),
std::function_Res(_ArgTypes ...)::_Useless::type) [with _Functor =
std::_Bindvoid (*(std::tupleint))(std::tupleint), _Res = void, _ArgTypes
= {}, typename std::enable_if(! std::is_integral_Functor::value),
std::function_Res(_ArgTypes ...)::_Useless::type =
std::functionvoid()::_Useless]’
bind_test.cc:6:76: instantiated from here
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/functional:1765:9:
error: no matching function for call to ‘std::tupleint::tuple(const volatile
std::tupleint)’
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/functional:1765:9:
note: candidates are:
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:441:32:
note: templateclass _U1 std::tuple_T1::tuple(std::tuple_U1)
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:437:37:
note: templateclass _U1 std::tuple_T1::tuple(const std::tuple_U1)
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:433:7:
note: std::tuple_T1::tuple(std::tuple_T1) [with _T1 = int,
std::tuple_T1 = std::tupleint]
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:433:7:
note: no known conversion for argument 1 from ‘const volatile
std::tupleint’ to ‘std::tupleint’
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:431:17:
note: constexpr std::tuple_T1::tuple(const std::tuple_T1) [with _T1 = int,
std::tuple_T1 = std::tupleint]
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:431:17:
note: no known conversion for argument 1 from ‘const volatile
std::tupleint’ to ‘const std::tupleint’
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:418:17:
note: constexpr std::tuple_T1::tuple() [with _T1 = int]
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:418:17:
note: candidate expects 0 arguments, 1 provided
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/functional:1765:9:
error: no matching function for call to ‘std::tupleint::tuple(volatile
std::tupleint)’
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/functional:1765:9:
note: candidates are:
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:441:32:
note: templateclass _U1 std::tuple_T1::tuple(std::tuple_U1)
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:437:37:
note: templateclass _U1 std::tuple_T1::tuple(const std::tuple_U1)
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:433:7:
note: std::tuple_T1::tuple(std::tuple_T1) [with _T1 = int,
std::tuple_T1 = std::tupleint]
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:433:7:
note: no known conversion for argument 1 from ‘volatile std::tupleint’ to
‘std::tupleint’
/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:431:17:
note: constexpr std::tuple_T1::tuple(const std::tuple_T1) [with _T1 = int,
std::tuple_T1 = std::tupleint]
[Bug libstdc++/48113] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.14 14:09:41 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-14 14:09:41 UTC --- harrumph, I thought we'd solved these problems with the volatile overloads, apparently not. I'll look into it later
[Bug inline-asm/37895] AVR inline assembly clobbers input value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37895 Eric Weddington eric.weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #4 from Eric Weddington eric.weddington at atmel dot com 2011-03-14 14:13:35 UTC --- (In reply to comment #3) So, please go ahead and close it. Ok. Closing as WORKSFORME.
[Bug libstdc++/48113] [4.6 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7 Regression]|[4.6 Regression] [C++0x] |[C++0x] bind with tuple |bind with tuple argument |argument fails |fails --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-14 14:19:36 UTC --- N.B. as a workaround you can specify the return type of the bind expression: std::bindvoid(test_1, std::tupleint(tst)) ^^ This avoids the problem code, which is trying to determine the return type.
[Bug libstdc++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|[4.6 Regression] [C++0x]|[4.6/4.7 Regression] |bind with tuple argument|[C++0x] bind with tuple |fails |argument fails
[Bug c++/48046] [4.5/4.6/4.7 Regression] Expected diagnostic reference to 'type' is ambiguous not given for function-local static declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48046 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.3
[Bug libstdc++/48114] New: random binomial_distribution incorrect for p .5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114
Summary: random binomial_distribution incorrect for p .5
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@althenia.net
Created attachment 23651
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23651
Probability table for binomial_distribution.
The attached program samples binomial_distribution(10, .75) and
calculates the correct probabilities of each outcome. The output shows
that the probabilities are reversed. With p .5 the distribution should
be biased toward higher values.
sample correct
p_0 0.056 0.000
p_1 0.185 0.000
p_2 0.283 0.000
p_3 0.252 0.003
p_4 0.147 0.016
p_5 0.058 0.058
p_6 0.016 0.146
p_7 0.003 0.250
p_8 0.000 0.282
p_9 0.000 0.188
p_100.000 0.056
The problem is here, __param.p() is a double.
--- include/c++/bits/random.tcc
+++ include/c++/bits/random.tcc
@@ -1434,7 +1434,7 @@
{
result_type __ret;
const _IntType __t = __param.t();
- const _IntType __p = __param.p();
+ const double __p = __param.p();
const double __p12 = __p = 0.5 ? __p : 1.0 - __p;
__detail::_Adaptor_UniformRandomNumberGenerator, double
__aurng(__urng);
[Bug libstdc++/48114] random binomial_distribution incorrect for p .5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 15:08:08 UTC --- Oops, luckily the fix seems easy. Thanks. Let me have a look.
[Bug libstdc++/48114] random binomial_distribution incorrect for p .5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.14 15:17:49 Target Milestone|--- |4.5.3 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 15:17:49 UTC --- Ok, I'm going to apply the simple fix to both 4.6 and 4.5. Then I'll finally work on the testsuite for these distributions, long overdue.
[Bug libstdc++/48114] random binomial_distribution incorrect for p .5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114
--- Comment #3 from Andrey Zholos aaz at althenia dot net 2011-03-14 15:23:25
UTC ---
I'll add this here since it's in the same place and the test will be
similar.
For geometric_distribution(.25) the first 10 probabilities are:
sample correct
p_0 0.000 0.250
p_1 0.750 0.188
p_2 0.187 0.141
p_3 0.046 0.105
p_4 0.012 0.079
p_5 0.003 0.059
p_6 0.001 0.044
p_7 0.000 0.033
p_8 0.000 0.025
p_9 0.000 0.019
The smallest value returned is 1, but should be 0 (and d.min() is
correctly 0); and p is used as 1-p.
Fix:
--- include/c++/bits/random.h
+++ include/c++/bits/random.h
@@ -3628,8 +3628,8 @@
void
_M_initialize()
- { _M_log_p = std::log(_M_p); }
+ { _M_log_1_p = std::log(1 - _M_p); }
double _M_p;
- double _M_log_p;
+ double _M_log_1_p;
};
--- include/c++/bits/random.tcc
+++ include/c++/bits/random.tcc
@@ -1027,3 +1027,3 @@
do
- __cand = std::ceil(std::log(__aurng()) / __param._M_log_p);
+ __cand = std::floor(std::log(__aurng()) / __param._M_log_1_p);
while (__cand = __thr);
Also, there's a line in random.h
_GLIBCXX_DEBUG_ASSERT((_M_p = 0.0)
(_M_p = 1.0));
but the standard only requires 0 p 1.
[Bug libstdc++/48114] random binomial_distribution incorrect for p .5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #4 from Andrey Zholos aaz at althenia dot net 2011-03-14 15:25:14 UTC --- Created attachment 23652 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23652 Probability table for geometric_distribution.
[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
--- Comment #4 from Jeffrey A. Law law at redhat dot com 2011-03-14 15:39:53
UTC ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/11 05:01, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||gnu.org
--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-09
12:01:10 UTC ---
As of the register moves you are seeing, we have the long-time known problem
that we fail to allocate registers in a way to have the function return
value in-place. Maybe we are just confusing IRA with the explicit move
to that register?
(insn 13 11 18 2 (set (reg:V2DF 72)
(vec_concat:V2DF (reg:DF 67)
(reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
(expr_list:REG_DEAD (reg:DF 69)
(expr_list:REG_DEAD (reg:DF 67)
(nil
(insn 18 13 21 2 (set (reg/i:V2DF 21 xmm0)
(reg:V2DF 72)) t.c:10 1127 {*movv2df_internal}
(expr_list:REG_DEAD (reg:V2DF 72)
(nil)))
why is combine not able to change this to
(insn 13 11 18 2 (set (reg/i:V2DF 21 xmm0)
(vec_concat:V2DF (reg:DF 67)
(reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
(expr_list:REG_DEAD (reg:DF 69)
(expr_list:REG_DEAD (reg:DF 67)
(nil
? (it doesn't even try this combination)
Probably because of the check in cant_combine_insn_p (SSE_FIRST_REG is likely
spilled on x86).
Right. I recently looked into a similar problem; ISTM we ought to be
able to come up with better rules than never combine if one of the regs
is a likely spilled reg.
Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNfja3AAoJEBRtltQi2kC7OD4H/AxEqn3YJ/BeFNLQ3wkkz7FO
5OrwKdN4HBjVHwg8jAy5NyAtc0g+iDS3fG7CEMRc2GS8ndO6F1qiecI3E/cHyvkL
4SzaoWpL+ZCs+hp9PXKCBLUf2OzIEG2lzxOB9YkpntpNtzDNobl7qG6bchusHLme
ECLTQdrMDBVVMWJJI5kTxhFxpQRvy1tF/Cx/WlnoTVWE1Yf4K+teNI+O8CEZOwa3
oemGlmxifE1dQ9ebFprMeehdVuKK+C6j7q4yJr32aGk7CTt0v4yM/hiHA6tBu7EE
4kgdHcust8LBMgSmYAYbWnbp8SVFx9t6DEGg6ICAf02/uWY4JTxpE2zhCUNCcwE=
=heUd
-END PGP SIGNATURE-
[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14
15:45:53 UTC ---
(In reply to comment #4)
--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-09
12:01:10 UTC ---
As of the register moves you are seeing, we have the long-time known
problem
that we fail to allocate registers in a way to have the function return
value in-place. Maybe we are just confusing IRA with the explicit move
to that register?
(insn 13 11 18 2 (set (reg:V2DF 72)
(vec_concat:V2DF (reg:DF 67)
(reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
(expr_list:REG_DEAD (reg:DF 69)
(expr_list:REG_DEAD (reg:DF 67)
(nil
(insn 18 13 21 2 (set (reg/i:V2DF 21 xmm0)
(reg:V2DF 72)) t.c:10 1127 {*movv2df_internal}
(expr_list:REG_DEAD (reg:V2DF 72)
(nil)))
why is combine not able to change this to
(insn 13 11 18 2 (set (reg/i:V2DF 21 xmm0)
(vec_concat:V2DF (reg:DF 67)
(reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
(expr_list:REG_DEAD (reg:DF 69)
(expr_list:REG_DEAD (reg:DF 67)
(nil
? (it doesn't even try this combination)
Probably because of the check in cant_combine_insn_p (SSE_FIRST_REG is
likely
spilled on x86).
Right. I recently looked into a similar problem; ISTM we ought to be
able to come up with better rules than never combine if one of the regs
is a likely spilled reg.
True, though relying on the combiner is also somewhat odd. Why does
the RA not consider coalescing the return register with a pseudo?
[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
--- Comment #6 from Jeffrey A. Law law at redhat dot com 2011-03-14 15:54:57
UTC ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/14/11 09:46, rguenth at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14
15:45:53 UTC ---
(In reply to comment #4)
--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-09
12:01:10 UTC ---
As of the register moves you are seeing, we have the long-time known
problem
that we fail to allocate registers in a way to have the function return
value in-place. Maybe we are just confusing IRA with the explicit move
to that register?
(insn 13 11 18 2 (set (reg:V2DF 72)
(vec_concat:V2DF (reg:DF 67)
(reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
(expr_list:REG_DEAD (reg:DF 69)
(expr_list:REG_DEAD (reg:DF 67)
(nil
(insn 18 13 21 2 (set (reg/i:V2DF 21 xmm0)
(reg:V2DF 72)) t.c:10 1127 {*movv2df_internal}
(expr_list:REG_DEAD (reg:V2DF 72)
(nil)))
why is combine not able to change this to
(insn 13 11 18 2 (set (reg/i:V2DF 21 xmm0)
(vec_concat:V2DF (reg:DF 67)
(reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
(expr_list:REG_DEAD (reg:DF 69)
(expr_list:REG_DEAD (reg:DF 67)
(nil
? (it doesn't even try this combination)
Probably because of the check in cant_combine_insn_p (SSE_FIRST_REG is
likely
spilled on x86).
Right. I recently looked into a similar problem; ISTM we ought to be
able to come up with better rules than never combine if one of the regs
is a likely spilled reg.
True, though relying on the combiner is also somewhat odd. Why does
the RA not consider coalescing the return register with a pseudo?
It certainly considers it. I haven't looked the IRA dumps for this
particular testcase.
In the case I was looking a recently, IRA had two hard reg copies to
consider (one from an arg register and one to the return register), thus
either was considered the same cost. I'd tried to do some hacks to
combine but didn't get far. See PR47521.
jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNfjpEAAoJEBRtltQi2kC7GW8IAJtaQozSKemLZo+0W+2Ei90n
81BJbJjuh6ZPyNMrv3XU3xkswlBzwbVN1yIDg4lthZkgSUCsavjZalI63DoOgdNo
N6lQuGvO9/nNLzZB0NbJX5EZivGVJnsZA0CfHJAN1UICXGzA5d4x6cLk3+erDY3E
8qudvAb+hl30yIlGuAulp0KDHCCAYSzEuTRKF+2I+0yNPTn+XsBkk18SuEVoSTad
GVB+mkoGJm97h0kAwdIE7Z0M4P+2EX3L1Ba1i9U13zQIoVYp2TSLnQMNF/gKiQxQ
DKWncl08kIScsRNICNiUcOeo78/8J6fASvHYUf4L9KYdk3OfIknB+6zANR1JKkI=
=t2/L
-END PGP SIGNATURE-
[Bug other/46542] GCC 4.7 pending patches meta-bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542 --- Comment #4 from Jeffrey A. Law law at redhat dot com 2011-03-14 15:57:29 UTC --- http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00609.html Patch to improve XOR optimizations.
[Bug other/46542] GCC 4.7 pending patches meta-bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542 --- Comment #5 from Jeffrey A. Law law at redhat dot com 2011-03-14 15:58:57 UTC --- http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01443.html Vlad approved this on the main gcc list in Mar 2011.
[Bug other/46542] GCC 4.7 pending patches meta-bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542 --- Comment #6 from Jeffrey A. Law law at redhat dot com 2011-03-14 16:00:44 UTC --- http://gcc.gnu.org/ml/gcc/2011-03/msg00098.html Minor IRA patch from Vlad.
[Bug c++/48115] New: [4.6/4.7 Regression] [C++0x] internal compiler error: in type_has_nontrivial_copy_init, at cp/tree.c:2482
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48115
Summary: [4.6/4.7 Regression] [C++0x] internal compiler error:
in type_has_nontrivial_copy_init, at cp/tree.c:2482
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
templatetypename struct templ { };
typedef void (*F2)(...);
templatetypename F, typename T
struct S
{
templatetypename A
decltype( F()(T()) )
f(A);
};
int main()
{
SF2, templint().f(0);
}
compiles ok with 4.5, ICE with 4.6.o 20110305
[Bug c++/48115] [4.6/4.7 Regression] [C++0x] internal compiler error: in type_has_nontrivial_copy_init, at cp/tree.c:2482
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48115 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.14 16:06:09 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-14 16:06:09 UTC --- Confirmed.
[Bug libstdc++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-14
16:22:44 UTC ---
Jason, could you take a look at this reduced testcase, which has no libstdc++
dependency?
templatetypename T T declval();
struct tuple { };
struct F1
{
void operator()(tuple);
};
typedef void (*F2)(tuple);
templatetypename F, typename T
struct Bind
{
decltype( F()(declvalT()) )
f();
decltype( F()(declvalvolatile T()) )
f() volatile;
};
int main()
{
BindF1, tuple().f(); // OK
BindF2, tuple().f(); // ERROR
}
This shows that SFINAE removes the Bind::f() volatile overload if F is a
functor, but not if it's a function pointer. I can't see why it should be
different.
Is this a FE bug, or do I need to handle function pointers differently in
std::bind? Thanks
[Bug libstdc++/48114] random binomial_distribution incorrect for p .5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 16:30:34 UTC --- Thanks, the second issue is ultimately due to the fact that we have been implementing, at variance with the Standard, a slightly different definition, see the formula before the class.
[Bug libstdc++/48114] random binomial_distribution incorrect for p .5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 16:31:46 UTC --- I meant geometric, of course.
[Bug libstdc++/48114] random binomial_distribution incorrect for p .5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 16:36:06 UTC --- ... and the reason is, the code has been too blindly adapted from the TR1 version.
[Bug c++/48115] [4.6/4.7 Regression] internal compiler error: in type_has_nontrivial_copy_init, at cp/tree.c:2482
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48115
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.6/4.7 Regression]|[4.6/4.7 Regression]
|[C++0x] internal compiler |internal compiler error: in
|error: in |type_has_nontrivial_copy_in
|type_has_nontrivial_copy_in |it, at cp/tree.c:2482
|it, at cp/tree.c:2482 |
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-14
16:52:30 UTC ---
Here's a C++03 version which works with 4.5, clang and EDG, but ICEs with 4.6
templatetypename struct templ { };
templatetypename T T declval();
typedef int (*F2)(...);
templateint struct Int { };
templatetypename F, typename T
struct S
{
templatetypename A
Intsizeof( declvalF()(T()) )
f(A);
};
int main()
{
SF2, templint ().f(0);
}
[Bug c/48116] New: -Wreturn-type does not work as advertised
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48116
Summary: -Wreturn-type does not work as advertised
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org
I'm using svn trunk gcc as of today.
-Wreturn-type is documented as:
[... warn] about a `return' statement with a expression
in a function whose return-type is `void'.
I tried it with this test case:
void x (void) { }
void y(void) { return x(); }
I expected a warning on the `return', but did not get one:
I used gcc -Wreturn-type -O2 -c q.c
[Bug c/48116] -Wreturn-type does not work as advertised
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48116 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-03-14 17:18:20 UTC --- apinski@apinskidesktop:~$ gcc t.c -W -Wall -pedantic -S t.c: In function ‘y’: t.c:2: warning: ISO C forbids ‘return’ with expression, in function returning void
[Bug c/48116] -Wreturn-type does not work as advertised
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48116 --- Comment #2 from Tom Tromey tromey at gcc dot gnu.org 2011-03-14 17:20:47 UTC --- Thanks, but I think it is still a bug as-is. I don't see why -pedantic should be required here.
[Bug libstdc++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org
|gnu.org |
--- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-14
17:24:36 UTC ---
SFINAE is not removing an overload; it doesn't work like that. SFINAE only
applies to function templates, not non-template member functions of class
templates. It's just that for some reason we aren't complaining about the
functor case. Reduced further:
struct A { };
volatile A f();
struct F1
{
void operator()(A);
};
typedef void (*F2)(A);
typedef decltype (F1()(f())) t1;
typedef decltype (F2()(f())) t2;
The inconsistency is odd. I would expect both lines to give an error.
[Bug libstdc++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|jason at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-03-14 17:33:44 UTC --- Indeed, EDG 4.2 rejects both. So the bug report is indeed a library issue. I'll open a separate report for the accepts-invalid example.
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #8 from Andrey Zholos aaz at althenia dot net 2011-03-14 17:34:01 UTC --- Ah, yes, I only looked at the C++0x formulas. By the way, testcases for these don't need to sample probabilities. They can just check, say, the first 100 values drawn using a deterministic generator.
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 17:43:33 UTC --- Yes, but really I'd like to have something quite serious in terms of testing, for 4.7.0 at this point. I even have some half-baked code around. By the way, if you are interested in contributing more in this area or elsewhere, your help is welcome but in case I would ask you to assign the copyright, it takes a bit of time but then you are set forever. See: http://gcc.gnu.org/contribute.html
[Bug libstdc++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 17:55:53 UTC --- I suspect Jon reduced the testcase a bit too much, because we have been through this kind of discussion/misunderstanding already, indeed normally we have only function *templates* in the actual code, no SFINAE to the help otherwise, agreed. Thanks Jon (and Jason) for looking into this.
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #10 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-03-14 17:57:53 UTC --- Author: paolo Date: Mon Mar 14 17:57:48 2011 New Revision: 170946 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170946 Log: 2011-03-14 Andrey Zholos a...@althenia.net PR libstdc++/48114 * include/bits/random.h (geometric_distribution): Correct formula in comment, per C++0x. (geometric_distribution::param_type::param_type(double)): Fix check. (geometric_distribution::param_type::_M_initialize): Store log(1 - p). * include/bits/random.tcc (geometric_distribution::operator()): Fix computation. (binomial_distribution::operator()): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-14
18:01:51 UTC ---
Doh, yes I got carried away reducing it and made it no longer a template
function, so of course SFINAE doesn't apply - sorry!
Should it apply in the case below?
templatetypename T T declval();
struct tuple { };
struct F1
{
void operator()(tuple);
};
typedef void (*F2)(tuple);
templatetypename F, typename T
struct Bind
{
templatetypename A, typename R = decltype( F()(declvalT()) )
R f(A);
templatetypename A, typename R = decltype( F()(declvalvolatile T()) )
R f(A) volatile;
};
int main()
{
BindF1, tuple().f(0); // OK
BindF2, tuple().f(0); // ERROR
}
Currently Bind::f() volatile gives an error during overload resolution but the
other overload doesn't. Will your fix make both fail?
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 18:02:41 UTC --- In 4_5-branch I'm going to fix only the first issue.
[Bug libstdc++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-14 18:03:52 UTC --- (In reply to comment #7) Currently Bind::f() volatile gives an error during overload resolution but the other overload doesn't. Will your fix make both fail? brain really not firing today ... I meant: Currently Bind::f() volatile gives an error for F2, but not F1. Will you fix make both fail?
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #12 from Andrey Zholos aaz at althenia dot net 2011-03-14 18:07:22 UTC --- The double __p also fixes an infinite (maybe) loop in both binomial_distribution(100, .75) and binomial_distribution(100, .25) when _GLIBCXX_USE_C99_MATH_TR1 is defined. I guess the proper way to test the algorithms is to generate a lot of values and do a Pearson's chi-square test to check that the distribution is correct. Then that can be used to make a faster testcase for just a few values.
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 18:08:35 UTC --- Good idea, yes, something like that.
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 18:16:36 UTC --- (In reply to comment #11) In 4_5-branch I'm going to fix only the first issue. Please don't forget about 4_6-branch too. I guess #c14 change would be fine even before 4.6.0 release.
[Bug libstdc++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-14
18:10:19 UTC ---
here's one even closer to what we actually have in the library, where the
default template argument R involves the deduced type A as well:
templatetypename T T declval();
struct tuple { };
struct F1
{
void operator()(tuple, int);
};
typedef void (*F2)(tuple, int);
templatetypename F, typename T
struct Bind
{
templatetypename A,
typename R = decltype( F()(declvalT(), A()) )
R f(A);
templatetypename A,
typename R = decltype( F()(declvalvolatile T(), A()) )
R f(A) volatile;
};
int main()
{
BindF1, tuple().f(0); // OK
BindF2, tuple().f(0); // ERROR
}
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #16 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-03-14 18:17:55 UTC --- Author: paolo Date: Mon Mar 14 18:17:51 2011 New Revision: 170951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170951 Log: 2011-03-14 Andrey Zholos a...@althenia.net PR libstdc++/48114 * include/bits/random.h (geometric_distribution): Correct formula in comment, per C++0x. (geometric_distribution::param_type::param_type(double)): Fix check. (geometric_distribution::param_type::_M_initialize): Store log(1 - p). * include/bits/random.tcc (geometric_distribution::operator()): Fix computation. (binomial_distribution::operator()): Likewise. Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/bits/random.h branches/gcc-4_6-branch/libstdc++-v3/include/bits/random.tcc
[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 2011-03-14 18:20:15 UTC --- Created attachment 23653 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23653 possible fix - shifting the special case output of objc_class_name_ to the back-end. this solves the problem of propagating the class refs/defs through LTO ... although it reveals that we have further issues when -flto-partition=none is used (duplicate meta-data definitions - however, this latter problem is not specific to darwin and will be posted as a different PR) ... only lightly tested on i686-darwin9. opinions?
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 18:20:33 UTC --- Jakub thanks for reminding me, luckily I noticed your message to the mailing list announcing the branching. Anyway, I went ahead and applied both fixes to 4_6 too, if you want me to go with #c14 only just let me know and I'll revert the other bits.
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 --- Comment #14 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-03-14 18:10:47 UTC --- Author: paolo Date: Mon Mar 14 18:10:36 2011 New Revision: 170950 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170950 Log: 2011-03-14 Andrey Zholos a...@althenia.net PR libstdc++/48114 * include/bits/random.tcc (binomial_distribution::operator()): Fix thinko in computation, __param.p() is a double. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/48114] [C++0x] binomial_distribution incorrect for p .5 and geometric_distribution wrongly implements the TR1 definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48114 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-14 18:28:02 UTC --- Done.
[Bug fortran/48117] New: ICE: OpenMP; in build_int_cst_wide, at tree.c:1178
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117 Summary: ICE: OpenMP; in build_int_cst_wide, at tree.c:1178 Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com cat test.f90 MODULE mo_real_timer IMPLICIT NONE PRIVATE PUBLIC :: get_new_timer INTEGER, PARAMETER :: timer_max = 1024 INTEGER :: top_timer = 0 ! shared part of timer TYPE srt_type LOGICAL :: reserved ! usage flag CHARACTER(len=80) :: text ! description of timer END TYPE srt_type ! thread private part of timer TYPE(srt_type), PARAMETER :: srt_init = srt_type(.FALSE., 'noname') TYPE(srt_type) :: srt(timer_max) CONTAINS SUBROUTINE get_new_timer(itimer, text) INTEGER, VOLATILE, INTENT(inout):: itimer ! itimer should not be threadprivate CHARACTER(len=*), INTENT(in), OPTIONAL :: text ! works like new_timer(), ! but can be called from within a parallel region !$OMP MASTER IF (PRESENT(text)) srt(top_timer)%text = adjustl(text) !$OMP END MASTER END SUBROUTINE get_new_timer END MODULE mo_real_timer gfortran -c -O2 test.f90 gfortran -c -fopenmp test.f90 gfortran -c -fopenmp -O2 test.f90 test.f90: In function 'get_new_timer': test.f90:22:0: internal compiler error: in build_int_cst_wide, at tree.c:1178 ... gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc/4.5.2/bin/../snos/bin/gfortran ... Thread model: posix gcc version 4.5.2 20101216 (Cray Inc.) (GCC) Compiles OK with either -O2 or -fopenmp, but ICE when both used together.
[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.1 --- Comment #6 from Iain Sandoe iains at gcc dot gnu.org 2011-03-14 18:31:13 UTC --- BTW, if we go this route (or almost any I can think of) we could have a separate patch to remove ASM_DECLARE_CLASS_REFERENCE/ASM_DECLARE_UNRESOLVED_REFERENCE which are only used for this one purpose AFAICT.
[Bug c++/48118] New: g++ sometimes incorrectly allows copying a volatile trivially-copyable class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48118
Summary: g++ sometimes incorrectly allows copying a volatile
trivially-copyable class
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
As noticed in PR 48113, we fail to give an error for the call to f below even
though it involves copying a volatile object and A doesn't have a copy
constructor that allows a volatile argument.
struct A { };
void f (A);
void (*g)(A);
int main()
{
volatile A a;
f(a);
g(a);
}
[Bug c++/48118] [4.3/4.4/4.5/4.6/4.7 regression] g++ sometimes allows copying a volatile class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48118 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||2.95, 3.4.6 Keywords||accepts-invalid Last reconfirmed||2011.03.14 18:43:43 CC||redi at gcc dot gnu.org Ever Confirmed|0 |1 Summary|g++ sometimes incorrectly |[4.3/4.4/4.5/4.6/4.7 |allows copying a volatile |regression] g++ sometimes |trivially-copyable class|allows copying a volatile ||class Known to fail||4.0.4, 4.6.0
[Bug rtl-optimization/47899] [4.5 Regression] ICE in get_loop_body, at cfgloop.c:831
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47899 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #10 from Zdenek Sojka zsojka at seznam dot cz 2011-03-14 18:44:24 UTC --- The testcase still ICEs the same way with custom flags: (r170934, x86_64-linux) $ gcc -O -funroll-loops -fthread-jumps -fno-tree-ch gcc.dg/pr47899.c gcc.dg/pr47899.c: In function 'main': gcc.dg/pr47899.c:26:1: internal compiler error: in get_loop_body, at cfgloop.c:831 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Component|libstdc++ |c++ AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2011-03-14 18:47:53 UTC --- That is indeed a SFINAE bug.
[Bug c++/48113] [4.6/4.7 Regression] [C++0x] bind with tuple argument fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48113 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-14 18:59:45 UTC --- (In reply to comment #10) That is indeed a SFINAE bug. phew! cos I'm all out of better ideas for fixing std::bind ;) Thanks for your help, sorry for the mixup with my overeager testcase reduction, but at least we found a new bug out of it
[Bug c++/48115] [4.6/4.7 Regression] internal compiler error: in type_has_nontrivial_copy_init, at cp/tree.c:2482
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48115 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 19:18:26 UTC --- Started failing with http://gcc.gnu.org/viewcvs?root=gccview=revrev=161582
[Bug c++/48119] New: -Wtype-limits should warn when bit masking cannot possibly be true due to type size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48119
Summary: -Wtype-limits should warn when bit masking cannot
possibly be true due to type size
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ete...@alum.rit.edu
I recently encountered a bug in some old code which boiled down to this
situation:
snip
#include stdint.h
#include iostream
int main() {
uint16_t x = 0x;
++x;
// did the value get to big?
if(x 0x1) {
x = 0xc000;
}
// I wanted it to say c000...
std::cout std::hex x std::endl;
}
snip
Obviously, this was an issue where I needed to use a uint32_t, but mistakenly
used a smaller type, clearly my fault. However, I was surprised that there was
no warning, since the condition is clearly impossible given the uint16_t
datatype.
As far as I know, a conformant compiler is not required to emit a warning for
such code, but it would be a nice improvement to help catch this type of error
in the future.
[Bug target/48053] ICE in in build_int_cst_wide, when building cpu2000 galgel/equake/ammp/fma3d/sixtrack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48053 --- Comment #6 from Michael Meissner meissner at gcc dot gnu.org 2011-03-14 19:37:14 UTC --- Created attachment 23654 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23654 Patch to fix 32-bit error on splititng loading 0 into VSX register After this patch was installed, it was discovered that in 32-bit if the compiler decides to load 0 into a VSX register, the compiler will complain when it tries to split the load into two separate insns (for each gpr), and it can't allocate a temporary GPR after reload.
[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.14 19:40:04 CC||jakub at gcc dot gnu.org Known to work||4.4.5, 4.6.0 Target Milestone|--- |4.5.3 Summary|ICE: OpenMP; in |[4.5 Regression] ICE: |build_int_cst_wide, at |OpenMP; in |tree.c:1178 |build_int_cst_wide, at ||tree.c:1178 Ever Confirmed|0 |1 Known to fail||4.5.2 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 19:40:04 UTC --- This has apparently been fixed by the 4th hunk of http://gcc.gnu.org/viewcvs/trunk/gcc/omp-low.c?r1=161655r2=161654pathrev=161655 (the only one not actually related to MEM_REF, unfortunately committed together with those changes) and caused by PR39958 fix.
[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org |
