[Bug target/48897] mn10300.c:extract_bundle’: error: variable ‘s’ set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48897 --- Comment #2 from Nick Clifton nickc at gcc dot gnu.org 2011-05-09 08:38:54 UTC --- Author: nickc Date: Mon May 9 08:38:50 2011 New Revision: 173559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173559 Log: PR target/48897 * config/mn10300/mn10300.c (extract_bundle): Remove spurious local variable 's'. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mn10300/mn10300.c
[Bug middle-end/46399] Missing type promotion for library call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |krebbel at gcc dot gnu.org |gnu.org |
[Bug target/48897] mn10300.c:extract_bundle’: error: variable ‘s’ set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48897 Nick Clifton nickc at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Nick Clifton nickc at redhat dot com 2011-05-09 09:03:20 UTC --- The variable was left over from an attempt to simplify the code. It is not needed and so I have checked in the obvious patch to remove it.
[Bug middle-end/46399] Missing type promotion for library call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.09 08:54:00 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org 2011-05-09 08:54:00 UTC --- Fixed for mainline with: Re: [PING] Fix PR46399 - missing mode promotion for libcall args http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01354.html plus the requested changes from: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01988.html and a build failure for PROMOTE_MODE targets fixed with: svn revision: 173376 I'll request applying the backported patch after the fix did hang around for a while in mainline.
[Bug debug/48928] [4.7 Regression] ICE: in decimal_to_decnumber, at dfp.c:113 with -O -g and decimal float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48928
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 |
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-09
09:32:23 UTC ---
Created attachment 24211
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24211
gcc47-pr48928.patch
Ugh, dfp is complete mess, in many places in the folder, middle-end and
optimizers dconst{1,2,m1,half} are used even for decimal types/modes, but those
real formats are binary, not decimal. The following patch just accepts the
status quo and handles those 4 standard constants specially instead of ICEing
on them.
[Bug c/48913] gcc -flto hangs and allocates all memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48913 Sven C. Dack sdack at gmx dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #3 from Sven C. Dack sdack at gmx dot de 2011-05-09 09:26:27 UTC --- The problem disappeared after a distribution update. I have updated the Linux distribution (Debian stable to testing) and it stopped doing it. I cannot say what caused it, but it only showed with GCC and no other application and only when -flto was being used.
[Bug debug/48928] [4.7 Regression] ICE: in decimal_to_decnumber, at dfp.c:113 with -O -g and decimal float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48928
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-09 09:56:56 UTC ---
On Mon, 9 May 2011, jakub at gcc dot gnu.org wrote:
Ugh, dfp is complete mess, in many places in the folder, middle-end and
optimizers dconst{1,2,m1,half} are used even for decimal types/modes, but
those
real formats are binary, not decimal. The following patch just accepts the
status quo and handles those 4 standard constants specially instead of ICEing
on them.
There should probably be a separate PR filed for the underlying problem of
using those values for decimal floating-point - given that all these
constants have multiple decimal floating-point representations (with
different quantum exponents), a decimal floating-point expert ought to
look at all the uses to figure out what is actually correct in terms of
getting the right quantum for results, and I doubt the code gets this
right at present.
[Bug c/48913] gcc -flto hangs and allocates all memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48913 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-09 09:48:19 UTC --- LTO does indeed partition the program - but the process that does this partitioning reads in (parts of) the whole program, thus this is usually where we require arbitrary amounts of memory. The lto1 process that is involved with that has the -fwpa flag passed. The lto1 processes dealing with partitions have the -fltrans flag passed. Yust FYI.
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #64 from Alan Modra amodra at gmail dot com 2011-05-09 09:52:44 UTC --- Re: comment #56 gcc generates a single function per CU that runs all the static constructors for that CU Note that if you add __attribute__ (( constructor )) into the mix this is no longer true. See http://sourceware.org/bugzilla/show_bug.cgi?id=12730 for an example.
[Bug libstdc++/48933] New: Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933
Summary: Infinite recursion in tr1/cmath functions with complex
parameters
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi
CC: w...@iki.fi
All of the function calls in this example code produce a stack overflow due to
infinite recursion, regardless of optimization level.
Compile with: g++ code.cc
Tested on the following gcc versions: 4.2.4 4.3.5 4.4.6 4.5.2 4.6.1
No compiler warnings or errors are emitted. (Tried even -Wall -W -pedantic
-ansi).
Does not happen on gcc 4.0.4, because tr1/cmath is unavailable.
#include tr1/cmath
#include complex
int main()
{
std::tr1::tgamma( std::complexdouble (0.5, 0.0) );
std::tr1::cbrt( std::complexdouble (0.5, 0.0) );
std::tr1::asinh( std::complexdouble (0.5, 0.0) );
std::tr1::acosh( std::complexdouble (1.5, 0.0) );
std::tr1::atanh( std::complexdouble (0.5, 0.0) );
std::tr1::erf( std::complexdouble (0.5, 0.0) );
std::tr1::hypot( std::complexdouble (1.0, 0.0) ,
std::complexdouble (1.0, 0.0) );
std::tr1::logb( std::complexdouble (0.5, 0.0) );
std::tr1::round( std::complexdouble (0.5, 0.0) );
std::tr1::trunc( std::complexdouble (0.5, 0.0) );
}
The bug can be traced to all functions in tr1/cmath that look like this:
templatetypename _Tp
inline typename __gnu_cxx::__promote_Tp::__type
cbrt(_Tp __x)
{
typedef typename __gnu_cxx::__promote_Tp::__type __type;
return cbrt(__type(__x)); // -- infinite recursion here
}
[Bug target/48899] enum conversion initializing global_options_init.x_iq2000_tune
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48899 --- Comment #1 from Nick Clifton nickc at gcc dot gnu.org 2011-05-09 10:04:39 UTC --- Author: nickc Date: Mon May 9 10:04:36 2011 New Revision: 173562 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173562 Log: PR target/48899 * config/iq2000/iq2000.opt (iq2000_tune): Initialise to PROCESSOR_DEFAULT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/iq2000/iq2000.opt
[Bug target/48899] enum conversion initializing global_options_init.x_iq2000_tune
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48899 --- Comment #2 from Nick Clifton nickc at redhat dot com 2011-05-09 10:07:20 UTC --- I have checked in a patch to initialise the iq2000_tune variable, thus eliminating the warning.
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.09 10:26:00 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 10:26:00 UTC --- Apparently we need enable_ifs.
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09
10:46:40 UTC ---
Yes, we should disable the TR1 math functions for anything that isn't integral
or floating point, because it happens with any non-integral, non-float type:
#include tr1/cmath
struct Foo { };
int main()
{
std::tr1::acosh( Foo() );
}
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933 --- Comment #4 from Joel Yliluoma bisqwit at iki dot fi 2011-05-09 10:51:28 UTC --- There is, however, an asinh, a cbrt, a hypot etc. for complex types. I don't know about standard, but mathematically they are well defined. (for example, hypot(x,y) = sqrt(x*x + y*y), asinh(x) = log(x + sqrt(x*x + 1))) For trunc other rounding functions probably not so.
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09 10:57:06 UTC --- They're in C++0x but I don't think they're in TR1
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 10:39:07 UTC --- Note of course, those infinite recursions can at best transformed to hard errors, there is no, eg, trunc, for std::complex types.
[Bug c++/48930] [C++0x] Invalid implicitly declared default c'tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930 --- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com 2011-05-09 10:55:06 UTC --- (In reply to comment #4) Indeed, C has no user-provided constructors, so it is an aggregate. Jason, what about c1? It seems that it is default-initialized, which would want to call the default constructor. Am I missing something?
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 11:01:44 UTC --- The way tr1/cmath is currently implemented, roughly speaking *when* an overload does not exist anyway an infinite recursion can happen. Thus, this is just a QoI issue. But it's easy to fix, I'll do that momentarily.
[Bug c++/48934] New: no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934
Summary: no rejection reason given for SFINAE
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: froy...@gcc.gnu.org
int foo(int);
templatetypename T
struct sfinae
{ };
template
struct sfinaefloat
{
typedef double type;
};
templatetypename T
typename sfinaeT::type
foo(T t)
{ return t; }
struct Bar { };
Bar b = foo( Bar() );
The error prints the two candidate functions and reason they weren't viable (I
love this feature, thanks Nathan!)
reason.cc:20:20: error: no matching function for call to 'foo(Bar)'
reason.cc:20:20: note: candidates are:
reason.cc:1:5: note: int foo(int)
reason.cc:1:5: note: no known conversion for argument 1 from 'Bar' to 'int'
reason.cc:15:10: note: templateclass T typename sfinae::type foo(T)
But no reason is given for the template.
I think the reason Clang++ gives is pretty good:
note: candidate template ignored: substitution failure [with T = Bar]
The key points to include in the reason are the template arguments and that
substitution failed (more formally, type deduction failed because substitution
resulted in an invalid type)
I've only checked this with 4.6 so apologies if it's already been improved on
trunk.
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934
--- Comment #1 from froydnj at codesourcery dot com froydnj at codesourcery
dot com 2011-05-09 11:53:58 UTC ---
On Mon, May 09, 2011 at 11:39:35AM +, redi at gcc dot gnu.org wrote:
int foo(int);
templatetypename T
struct sfinae
{ };
template
struct sfinaefloat
{
typedef double type;
};
templatetypename T
typename sfinaeT::type
foo(T t)
{ return t; }
struct Bar { };
Bar b = foo( Bar() );
The error prints the two candidate functions and reason they weren't viable (I
love this feature, thanks Nathan!)
reason.cc:20:20: error: no matching function for call to 'foo(Bar)'
reason.cc:20:20: note: candidates are:
reason.cc:1:5: note: int foo(int)
reason.cc:1:5: note: no known conversion for argument 1 from 'Bar' to 'int'
reason.cc:15:10: note: templateclass T typename sfinae::type foo(T)
But no reason is given for the template.
I've only checked this with 4.6 so apologies if it's already been improved on
trunk.
I submitted a patch for this:
http://gcc.gnu.org/ml/libstdc++/2011-02/msg9.html
I need to clean it up a bit and possibly fix some testsuite failures.
Does that patch do what you want?
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09 12:03:48 UTC --- I forgot about that mail - I'll try the patch and get back to you, thanks
[Bug rtl-optimization/48927] Issues with enable attribute and IRA register preferences
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48927 --- Comment #4 from uros at gcc dot gnu.org 2011-05-09 12:11:31 UTC --- Author: uros Date: Mon May 9 12:11:25 2011 New Revision: 173568 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173568 Log: PR rtl-optimization/48927 * ira-conflicts.c (commutative_constraint_p): Use recog_data.alternative_enabled_p to disable alternatives where enabled attribute is false. (get_dup_num): Ditto. * ira-lives.c (single_reg_class): Ditto. (ira_implicitly_set_insn_hard_regs): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-conflicts.c trunk/gcc/ira-lives.c
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09 12:18:12 UTC --- That patch makes no difference for the example in this PR
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 --- Comment #19 from Dodji Seketeli dodji at gcc dot gnu.org 2011-05-09 12:32:11 UTC --- Author: dodji Date: Mon May 9 12:32:06 2011 New Revision: 173570 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173570 Log: Fix PR c++/48574 gcc/cp/ PR c++/48574 * class.c (fixed_type_or_null): Use type_dependent_p_push to test if the instance has a dependent initializer. gcc/testsuite/ PR c++/48574 * g++.dg/template/dependent-expr8.C: New test case. Added: trunk/gcc/testsuite/g++.dg/template/dependent-expr8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/48927] Issues with enable attribute and IRA register preferences
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48927 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-05-09 12:25:40 UTC --- Fixed.
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 --- Comment #20 from Dodji Seketeli dodji at gcc dot gnu.org 2011-05-09 12:34:22 UTC --- Author: dodji Date: Mon May 9 12:34:19 2011 New Revision: 173571 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173571 Log: Fix PR c++/48574 gcc/cp/ PR c++/48574 * class.c (fixed_type_or_null): Use type_dependent_p_push to test if the instance has a dependent initializer. gcc/testsuite/ PR c++/48574 * g++.dg/template/dependent-expr8.C: New test case. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/dependent-expr8.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/class.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-09 12:56:14 UTC --- Fixed.
[Bug c++/48930] [C++0x] Invalid implicitly declared default c'tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2011.05.09 13:32:58 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-05-09 13:32:58 UTC --- Ah, I didn't notice c1 in the testcase. That is indeed a bug.
[Bug middle-end/48932] ICE in check_dep, at sched-deps.c:4097
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48932 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-05-09 13:44:04 UTC --- On Sun, 08 May 2011, danglin at gcc dot gnu.org wrote: Appears to be fixed in 4.5 and 4.6. Actually, bug is in 4.5.1 but not 4.5.3. The only relevant fix that I see is: 2010-09-15 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/45593 * reorg.c (relax_delay_slots): Use emit_copy_of_insn_after to re-emit insns that were in delay slots as stand-alone insns. Dave
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09
14:05:06 UTC ---
Another example:
templatetypename T struct S1 { typedef char type; };
templatetypename T
typename S1T::type
foo(typename S1T::typo)
{ return t; }
char c = fooint(1);
Here the return type is valid, but the parameter is not (typo vs type).
Ideally the diagnostic would indicate that, which would help when the template
arguments are substituted in more than one place.
My dream compiler would tell me exactly where it failed e.g.
templatebool struct S2 { typedef char type; };
templatetypename U struct S3 { static const bool V = true; };
templatetypename T
typename S2S3T::val::type // no 'val'
foo(T t)
{ return t; }
char c = foo(1);
This fails because S3T::val is an invalid expression (val vs V)
My dream compiler would tell me which sub-expression was invalid, as this could
be a huge help when debugging complex SFINAE cases with nested expressions and
types.
I realise that might be very difficult to do and that as a library implementor
my wishlist may not be typical of most users. Simply saying something like
substitution failed would already be a nice improvement.
[Bug c++/48935] Name lookup error at enum class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48935 --- Comment #1 from Takeshi Watanabe takechi101010 at gmail dot com 2011-05-09 14:02:33 UTC --- Created attachment 24212 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24212 code
[Bug c++/48935] New: Name lookup error at enum class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48935 Summary: Name lookup error at enum class Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: takechi101...@gmail.com I got the following error: gcc-enum-class-test.cxx:9:7: internal compiler error: in constructor_name_p, at cp/name-lookup.c:1862 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. compiling the attached code. I don't know much about c++0x but I think that should be an error.
[Bug c++/48935] [C++0x] Name lookup error at enum class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48935
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.05.09 14:30:51
Summary|Name lookup error at enum |[C++0x] Name lookup error
|class |at enum class
Ever Confirmed|0 |1
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09
14:30:51 UTC ---
reduced:
enum class ENUM { a };
ENUM::Type func() { return ENUM::a; }
possibly related to PR 43509
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 Leo Barnes barnes.leo at gmail dot com changed: What|Removed |Added CC||barnes.leo at gmail dot com --- Comment #6 from Leo Barnes barnes.leo at gmail dot com 2011-05-09 14:41:58 UTC --- I also just spent quite some time solving a bug that was caused by switch-case falling through and was thinking of writing some kind of parser to check for this. If gcc could check for it instead, that would be great. Suggestion: If possible, also add some kind of tag that can be used in code where you actually want a fall-through to happen.
[Bug tree-optimization/48921] Value numbering takes infinite time on nested infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48921 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-09 15:23:30 UTC --- I think this is a dup of PR48822. Can you check if the bug still occurs with a more current trunk? I can't reproduce it at least.
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 15:42:17 UTC --- Done.
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-09 15:38:25 UTC --- Author: paolo Date: Mon May 9 15:38:21 2011 New Revision: 173574 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173574 Log: 2011-05-09 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/48933 * include/c_global/cmath (acosh, asinh, atanh, cbrt, copysign, erf, erfc, exp2, expm1, fdim, fma, fmax, hypot, ilogb, lgamma, llrint, llround, log1p, log2, logb, lrint, lround, nearbyint, nextafter, nexttoward, remainder, remquo, rint, round, scalbln, scalbn, tgamma, trunc): Use __enable_if on the return type. * include/tr1/cmath: Likewise. * testsuite/26_numerics/headers/cmath/overloads_c++0x_neg.cc: New. * testsuite/tr1/8_c_compatibility/cmath/overloads_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/overloads_c++0x_neg.cc trunk/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath/overloads_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/c_global/cmath trunk/libstdc++-v3/include/tr1/cmath
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934
--- Comment #5 from froydnj at codesourcery dot com froydnj at codesourcery
dot com 2011-05-09 15:38:14 UTC ---
Thanks for checking. I'll attempt to the make the patch do something
intelligent on at least the original testcase and this:
templatetypename T struct S1 { typedef char type; };
templatetypename T
typename S1T::type
foo(typename S1T::typo)
{ return t; }
char c = fooint(1);
Here the return type is valid, but the parameter is not (typo vs type).
Ideally the diagnostic would indicate that, which would help when the template
arguments are substituted in more than one place.
Thanks for the additional testcases!
I realise that might be very difficult to do and that as a library implementor
my wishlist may not be typical of most users. Simply saying something like
substitution failed would already be a nice improvement.
substitution failed will probably be the default message if we can't
provided anything more intelligent.
[Bug c++/48936] New: [4.3/4.4/4.5/4.6 Regression] sizeof template parm not considered constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48936
Summary: [4.3/4.4/4.5/4.6 Regression] sizeof template parm not
considered constant expression
Product: gcc
Version: 4.4.7
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ja...@gcc.gnu.org
template bool C int foo (void);
template class T struct S
{
static const unsigned int a = sizeof (T);
enum { c = sizeof (foo (a == 0) ()) };
};
Sint x;
compiles fine with 3.3, 3.4, 4.6 and trunk, fails in 4.0 - 4.5 with:
x.C: In instantiation of ‘Sint’:
x.C:7: instantiated from here
x.C:5: error: ‘(((unsigned int)Sint::a) == 0u)’ is not a valid template
argument for type ‘bool’ because it is a non-constant expression
x.C:5: error: no matching function for call to ‘foo()’
http://gcc.gnu.org/viewcvs?root=gccview=revrev=163895
http://gcc.gnu.org/viewcvs?root=gccview=revrev=166164
is what fixed it for 4.6/4.7, but Jason has a smaller fix for the older release
branches.
[Bug tree-optimization/48794] [4.7 Regression] ICE: SIGSEGV in remap_eh_region_nr (tree-inline.c:1194) with -Os -fopenmp -fexceptions -fno-tree-ccp -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794 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 | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-09 15:51:28 UTC --- Created attachment 24213 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24213 gcc47-pr48794.patch Untested fix, which fixes also PR48611 if I back out the tree-eh.c change that was committed for it.
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934
--- Comment #6 from froydnj at codesourcery dot com froydnj at codesourcery
dot com 2011-05-09 16:10:51 UTC ---
On Mon, May 09, 2011 at 02:08:05PM +, redi at gcc dot gnu.org wrote:
templatetypename T struct S1 { typedef char type; };
templatetypename T
typename S1T::type
foo(typename S1T::typo)
{ return t; }
char c = fooint(1);
Running this example given an error about `t' not being declared. What
did you mean to return there? Or is that part of the point?
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09
16:24:51 UTC ---
(In reply to comment #6)
Oops, no, that's a mistake, the parameter should be named 't'
templatetypename T struct S1 { typedef char type; };
templatetypename T
typename S1T::type
foo(typename S1T::typo t)
{ return t; }
char c = fooint(1);
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09 16:28:51 UTC --- The point of that example is that even clang's substitution failed could be improved, because T is substituted successfully into the return type S1T::type but not into the parameter type S1T::typo (in the general case they wouldn't both use S1 and there could be several parameters) So a better reason would be substitution failed for parameter 1 but I don't know how easy that is, if it's even possible in the current G++ codebase
[Bug target/44643] ice in c-typeck.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44643 Eric Weddington eric.weddington at atmel dot com changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 Nathan Froyd froydnj at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #9 from Nathan Froyd froydnj at gcc dot gnu.org 2011-05-09 17:10:31 UTC --- (In reply to comment #8) The point of that example is that even clang's substitution failed could be improved, because T is substituted successfully into the return type S1T::type but not into the parameter type S1T::typo (in the general case they wouldn't both use S1 and there could be several parameters) So a better reason would be substitution failed for parameter 1 but I don't know how easy that is, if it's even possible in the current G++ codebase It is possible; it's just a bit tedious, since you'd need to thread the unification_info all the way through template substitution, not just function type deduction. I don't know how Jason would feel about the extra parameter and corresponding call overhead to tsubst, though. Jason? (IIUC, doing this would also enable you to precisely report which sub-expression substitution failed in.) The hackish way of doing this would be to notice during deduction that substitution of a function type failed, then go back and substitute piece-wise into return type and argument types until you find the failing type. That could be done without the changes above, but it'd be a bit gross.
[Bug fortran/48937] New: Discrepancy in computation between 32 and 64-bit builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48937 Summary: Discrepancy in computation between 32 and 64-bit builds Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thatcad...@gmail.com Created attachment 24214 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24214 zip file of the two source files in question and a makefile I have created a subroutine to solve pentadiagonal systems of equations according to H.L. Stone's 1968 paper. I have tested this subroutine on a homework problem requiring such a system and observed similar results from gfortran and MATLAB. For thoroughness, I have made a test program that creates a random matrix to solve. Basically, in solving Ax = B, it creates a random A and adds a fixed number to the diagonal to ensure the matrix is well-conditioned. Exact x is hardcoded in the program and B is computed. Then, A and B are given to the subroutine to find x iteratively and finally it prints the absolute error between the iteratively solved x and the exact x. I have compiled these files without error on both 32 and 64-bit versions of mingw, both running under Windows 7. The 32-bit system is an Intel Atom processor and the 64-bit system is an Intel CORE i7. When run on the 32-bit system, the solution converges within 23 iterations every time and shows an absolute error of zero, as should be expected. When run on the 64-bit system, it almost never converges and seems to stay at a constant residual around 1e-11 or will alternate between two or three values. Basically, the same exact code converges on one system and fails to solve on the other. These files are very simple in nature and only use simple loops and arithmetic. About the only thing special that's used is the RANDOM_NUMBER intrinsic. Note: I obtained these binaries from TDM-GCC. That may be to blame, or perhaps mingw; anyone with a 64-bit Windows build should be able to quickly confirm this bug or disprove it.
[Bug fortran/48937] Discrepancy in computation between 32 and 64-bit builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48937 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09 17:36:34 UTC --- The difference is almost certainly due to 64-bit defaulting to -mfpmath=sse, but 32-bit defaulting to -mfpmath=387
[Bug c++/34772] [4.3/4.4/4.5/4.6/4.7 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34772 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2011-05-09 17:34:48 UTC --- Author: jason Date: Mon May 9 17:34:44 2011 New Revision: 173582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173582 Log: PR c++/34772 * decl.c (initialize_local_var): Use DECL_INITIAL for simple initialization. Added: trunk/gcc/testsuite/c-c++-common/uninit-D-O0.c - copied, changed from r173581, trunk/gcc/testsuite/gcc.dg/uninit-D-O0.c trunk/gcc/testsuite/c-c++-common/uninit-D.c - copied, changed from r173581, trunk/gcc/testsuite/gcc.dg/uninit-D.c trunk/gcc/testsuite/c-c++-common/uninit-E-O0.c - copied, changed from r173581, trunk/gcc/testsuite/gcc.dg/uninit-E-O0.c trunk/gcc/testsuite/c-c++-common/uninit-E.c - copied, changed from r173581, trunk/gcc/testsuite/gcc.dg/uninit-E.c trunk/gcc/testsuite/c-c++-common/uninit-F-O0.c - copied, changed from r173581, trunk/gcc/testsuite/gcc.dg/uninit-F-O0.c trunk/gcc/testsuite/c-c++-common/uninit-F.c - copied, changed from r173581, trunk/gcc/testsuite/gcc.dg/uninit-F.c trunk/gcc/testsuite/c-c++-common/uninit-G-O0.c - copied, changed from r173581, trunk/gcc/testsuite/gcc.dg/uninit-G-O0.c trunk/gcc/testsuite/c-c++-common/uninit-G.c - copied, changed from r173581, trunk/gcc/testsuite/gcc.dg/uninit-G.c Removed: trunk/gcc/testsuite/gcc.dg/uninit-D-O0.c trunk/gcc/testsuite/gcc.dg/uninit-D.c trunk/gcc/testsuite/gcc.dg/uninit-E-O0.c trunk/gcc/testsuite/gcc.dg/uninit-E.c trunk/gcc/testsuite/gcc.dg/uninit-F-O0.c trunk/gcc/testsuite/gcc.dg/uninit-F.c trunk/gcc/testsuite/gcc.dg/uninit-G-O0.c trunk/gcc/testsuite/gcc.dg/uninit-G.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 --- Comment #5 from fabien at gcc dot gnu.org 2011-05-09 17:42:24 UTC --- Author: fabien Date: Mon May 9 17:42:21 2011 New Revision: 173583 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173583 Log: Fix PR C++/48859 Added: trunk/gcc/testsuite/g++.dg/init/pr48859.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48937] Discrepancy in computation between 32 and 64-bit builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48937 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-09 17:57:00 UTC --- To add to Jonathan's comment: 32 bit x86 (i686, IA-32) systems can do calculations in the mathematical coprocessor (x87); this processor calculates internally with 80 bit variables thus as long as a variable remains in the register, you are actually calculating with 80 bits instead of 32 bit (single) or 64 (double precision). A proper IEEE 754 however ensures that no excess precision occurs, which happens for instance with SSE, which is used under 64bit x86-64 (AMD64, Intel64) by default. Usually, one does not want to have the excess precision as it is unpredictable. If the variable is stored in between in the memory, the extra precision is lost. -ffloat-store does so, which is one way to get to more deterministic results by never using the excess precision. Another means is to use -mfpmath=sse also under 32bit. If the precision is not enough, you can go the a higher precision for all variables; gfortran supports 32, 64, 80 and 128 bit precision via the data types REAL(4), REAL(8), REAL(10) and REAL(16). - If you change the the real type, remember to also update the literal constants. Further reference: - http://gcc.gnu.org/wiki/x87note - http://www.validlab.com/goldberg/paper.pdf - http://hal.archives-ouvertes.fr/hal-00128124 PS: GCC's C/C++ compiler also supports -fexcess-precision=standard, which GCC's Fortran compiler doesn't.
[Bug c++/48936] [4.3/4.4/4.5/4.6 Regression] sizeof template parm not considered constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48936 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-05-09 18:00:40 UTC --- Author: jason Date: Mon May 9 18:00:37 2011 New Revision: 173585 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173585 Log: PR c++/48936 * decl2.c (mark_used): Instantiate constant variables even in unevaluated context. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/nontype23.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/decl2.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug c++/48936] [4.3/4.4/4.5 Regression] sizeof template parm not considered constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48936 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.3/4.4/4.5/4.6|[4.3/4.4/4.5 Regression] |Regression] sizeof template |sizeof template parm not |parm not considered |considered constant |constant expression |expression --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-05-09 18:01:30 UTC --- Fixed in 4.4 and 4.5.
[Bug fortran/48937] Discrepancy in computation between 32 and 64-bit builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48937
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org 2011-05-09 18:05:04 UTC ---
Have you read Goldberg's paper on floating point computations?
On x86_64-*-freebsd, I get the following results
fc4x ${OPT} -o z sip.f95 sip_test.f95
OPT=''
1000 0.695040E-11
Error: 0.20815460466394597E-10
OPT='-O'
1000 0.646004E-11
Error: 0.20326407224047216E-10
OPT='-O2'
1000 0.694955E-11
Error: 0.21079360479347997E-10
OPT='-O3'
1000 0.504164E-11
Error: 0.10621281631983948E-10
OPT='-O3 -funroll-loops'
1000 0.502817E-11
Error: 0.11637135699515966E-10
OPT='-O3 -funroll-loops -ftree-vectorize'
1000 0.669018E-11
Error: 0.18756551867227245E-10
[Bug c++/48936] [4.3/4.4/4.5/4.6 Regression] sizeof template parm not considered constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48936 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-05-09 18:00:29 UTC --- Author: jason Date: Mon May 9 18:00:26 2011 New Revision: 173584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173584 Log: PR c++/48936 * decl2.c (mark_used): Instantiate constant variables even in unevaluated context. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/nontype23.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/decl2.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853 --- Comment #21 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-05-09 18:16:06 UTC --- Author: hjl Date: Mon May 9 18:16:04 2011 New Revision: 173587 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173587 Log: One more POINTERS_EXTEND_UNSIGNED fix in mem_loc_descriptor. 2011-05-09 H.J. Lu hongjiu...@intel.com PR debug/48853 * dwarf2out.c (mem_loc_descriptor) case SUBREG: If POINTERS_EXTEND_UNSIGNED is defined, don't give up if mode is Pmode and mem_mode is not VOIDmode. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug middle-end/48907] [4.7 Regression] ICE in bitmap_first_set_bit, at bitmap.c:782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48907 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.09 18:09:42 Ever Confirmed|0 |1 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-05-09 18:09:42 UTC --- Also occurs on hppa2.0w-hp-hpux11.11.
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2011-05-09 18:17:17 UTC --- (In reply to comment #9) The hackish way of doing this would be to notice during deduction that substitution of a function type failed, then go back and substitute piece-wise into return type and argument types until you find the failing type. That could be done without the changes above, but it'd be a bit gross. It sounds to me like that would be both simpler and better than trying to pass back information about why the substitution failed. If we get to the point where we're trying to explain substitution failure, we can just do the substitution again with tf_warning_or_error and we'll find out exactly what the problem is with the usual error messages.
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09 18:01:37 UTC --- Thanks, Fabien! N.B. the svn commit message should be the ChangeLog entry (look at the svn log for any file to see what's normally done)
[Bug target/48862] New: A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48862
Summary: A Bug When Assembler Instructions with C Expression
Operands in arm-elf-gcc 4.5
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shangyun...@gmail.com
CC: casca...@holoscopio.com
Thadeu Lima de Souza Cascardo cascardo at holoscopio dot com changed:
What|Removed |Added
CC||cascardo at holoscopio dot
||com
Assembler instructions with C expression operands, gcc(arm-elf-gcc) compiler
may produce the wrong instrctions sequence with option -O2.There is a case only
for test below.
In the case, the second instruction (mov r0, r1) destroyed r0 without saving,
but r0 kept the value of variable fd and the variable should be passed to swi
0. I think it's a serious bug, gcc compiler does not consider that unsigned
high = length / 23 may produce a function call.
case start
static __inline__ int __syscall_test(int fd, unsigned pad, unsigned long high,
unsigned low)
{
unsigned int __sys_result;
{
register int _a1 __asm__ (r0) = fd;
register int _a2 __asm__ (r1) = pad;
register int _a3 __asm__ (r2) = high;
register int _a4 __asm__ (r3) = low;
__asm__ __volatile__ (swi 0
: =r(_a1)
: 0(_a1),r(_a3), r(_a4));
__sys_result = _a1;
}
return __sys_result;
}
int f_test(int fd, long long length)
{
unsigned low = length 0x;
unsigned high = length / 23;
return __syscall_test(fd, 0, high, low);
}
-- compile result --
.file case.c
.global __divdi3
.text
.align 2
.global f_test
.type f_test, %function
f_test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, lr}
mov r0, r1
mov r4, r1
mov r3, #0
mov r1, r2
mov r2, #23
bl __divdi3
mov r3, r4
mov r2, r0
@ 10 case.c 1
swi 0
@ 0 2
ldmfd sp!, {r4, pc}
.size f_test, .-f_test
.ident GCC: (GNU) 4.5.2
end ===
--- Comment #1 from Thadeu Lima de Souza Cascardo cascardo at holoscopio dot
com 2011-05-09 18:31:50 UTC ---
This is a duplicate of 48863. Reporter sent the same bug three times. Please,
mark as resolved/duplicate.
[Bug c++/48936] [4.3/4.4/4.5/4.6 Regression] sizeof template parm not considered constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48936 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.09 17:52:31 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.4.7 Ever Confirmed|0 |1
[Bug fortran/48937] Discrepancy in computation between 32 and 64-bit builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48937 Jacob Abel thatcadguy at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #4 from Jacob Abel thatcadguy at gmail dot com 2011-05-09 18:20:49 UTC --- Thank you both. Mingw32 shows the same behavior when I compiled with -ffloatstore. Had no idea that 32-bit systems still used separate math co-processors or that they had 80-bit precision.
[Bug target/48861] New: A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48861
Summary: A Bug When Assembler Instructions with C Expression
Operands in arm-elf-gcc 4.5
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shangyun...@gmail.com
CC: casca...@holoscopio.com
Thadeu Lima de Souza Cascardo cascardo at holoscopio dot com changed:
What|Removed |Added
CC||cascardo at holoscopio dot
||com
Assembler instructions with C expression operands, gcc(arm-elf-gcc) compiler
may produce the wrong instrctions sequence with option -O2.There is a case only
for test below.
In the case, the second instruction (mov r0, r1) destroyed r0 without saving,
but r0 kept the value of variable fd and the variable should be passed to swi
0. I think it's a serious bug, gcc compiler does not consider that unsigned
high = length / 23 may produce a function call.
case start
static __inline__ int __syscall_test(int fd, unsigned pad, unsigned long high,
unsigned low)
{
unsigned int __sys_result;
{
register int _a1 __asm__ (r0) = fd;
register int _a2 __asm__ (r1) = pad;
register int _a3 __asm__ (r2) = high;
register int _a4 __asm__ (r3) = low;
__asm__ __volatile__ (swi 0
: =r(_a1)
: 0(_a1),r(_a3), r(_a4));
__sys_result = _a1;
}
return __sys_result;
}
int f_test(int fd, long long length)
{
unsigned low = length 0x;
unsigned high = length / 23;
return __syscall_test(fd, 0, high, low);
}
-- compile result --
.file case.c
.global __divdi3
.text
.align 2
.global f_test
.type f_test, %function
f_test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, lr}
mov r0, r1
mov r4, r1
mov r3, #0
mov r1, r2
mov r2, #23
bl __divdi3
mov r3, r4
mov r2, r0
@ 10 case.c 1
swi 0
@ 0 2
ldmfd sp!, {r4, pc}
.size f_test, .-f_test
.ident GCC: (GNU) 4.5.2
end ===
--- Comment #1 from Thadeu Lima de Souza Cascardo cascardo at holoscopio dot
com 2011-05-09 18:32:20 UTC ---
This is a duplicate of 48863. Reporter sent the same bug three times. Please,
mark as resolved/duplicate.
[Bug lto/48938] New: [4.7 Regression] ICE: in lto_wpa_write_files, at lto/lto.c:1992 with -O -flto --param lto-min-partition=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48938 Summary: [4.7 Regression] ICE: in lto_wpa_write_files, at lto/lto.c:1992 with -O -flto --param lto-min-partition=1 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24215 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24215 reduced testcase Compiler output: $ gcc -r -nostdlib -O -flto --param lto-min-partition=1 testcase.C lto1: internal compiler error: in lto_wpa_write_files, at lto/lto.c:1992 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-latest/bin/gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status Tested revisions: r173549 - crash 4.6 r173059 - OK
[Bug fortran/48939] New: ICE in code involving procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48939 Summary: ICE in code involving procedure pointers Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu Created attachment 24216 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24216 Source code for ICE-causing module The attached module source code causes an Internal Compiler Error during compilation (gfortran -c gfortran_ice.f90). I'm guessing this might have something to do with the use of procedure pointers. This is on OS X 10.6.7 with gfortran 4.6.1 (20110325) built within macports.
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09 19:13:45 UTC --- (In reply to comment #11) foo.C:blahblah: error: no matching function for call to foo foo.C:blahblah: note: candidate is foo(blahblah) foo.c:blahblah: note: substitution failed for parameter `F' At least, that's what I understood Jonathan asking for--perhaps he wanted something more detailed about why substitution failed, which is a debate for another time, I think. I would love to get more information, but I'd be very happy with the diagnostic above (that's already better than I'd get from any compiler I've tried) This PR is really just to get *anything* printed, so just a basic substition failed with no mention of which template parameter failed would be enough to resolve this IMHO. Improving on that would be a nice-to-have, for a later date.
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-09 19:16:39 UTC --- (In reply to comment #12) This PR is really just to get *anything* printed, so just a basic substition failed with no mention of which template parameter failed would be enough to resolve this IMHO. To clarify: I would like to get the usual list of template args e.g. [with T = foo, U = bar] but I don't mind if it doesn't say for which one substitution failed.
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934
--- Comment #11 from froydnj at codesourcery dot com froydnj at codesourcery
dot com 2011-05-09 18:59:55 UTC ---
On Mon, May 09, 2011 at 06:26:44PM +, jason at gcc dot gnu.org wrote:
The hackish way of doing this would be to notice during deduction that
substitution of a function type failed, then go back and substitute
piece-wise
into return type and argument types until you find the failing type. That
could be done without the changes above, but it'd be a bit gross.
It sounds to me like that would be both simpler and better than trying to pass
back information about why the substitution failed. If we get to the point
where we're trying to explain substitution failure, we can just do the
substitution again with tf_warning_or_error and we'll find out exactly what
the
problem is with the usual error messages.
I'm not sure what you suggest is a win. The desired (or, at least,
consistent with what we do now) behavior is to say:
foo.C:blahblah: error: no matching function for call to foo
foo.C:blahblah: note: candidate is foo(blahblah)
foo.c:blahblah: note: substitution failed for parameter `F'
At least, that's what I understood Jonathan asking for--perhaps he
wanted something more detailed about why substitution failed, which is a
debate for another time, I think.
If I understand your proposal correctly, we'd get something more like:
foo.C:blahblah: error: no matching function for call to foo
foo.C:blahblah: note: candidate is foo(blahblah)
foo.C:blahblah: error: [some explanation]
which doesn't seem quite right.
To make the hack suggestion more concrete, we currently have,
pt.c:fn_type_unification:
/* All is well so far. Now, check:
[temp.deduct]
When all template arguments have been deduced, all uses of
template parameters in nondeduced contexts are replaced with
the corresponding deduced argument values. If the
substitution results in an invalid type, as described above,
type deduction fails. */
{
tree substed = tsubst (TREE_TYPE (fn), targs, tf_none, NULL_TREE);
if (substed == error_mark_node)
return 1;
and I was proposing to replace the bare 'return 1' with something more
like:
{
/* Check to see if return types were the reason substitution
failed. */
tree t = tsubst on return types
if (t == error_mark_node)
return unify_return_type_substitution_failure ...
/* Loop over the arguments of TREE_TYPE (FN) and TARGS. */
foreach ...
{
tree t = tsubst on argument type
if (t == error_mark_node)
return unify_argument_substitution_failure
}
and then we would handle return_type_substitution_failure or
argument_substitution_failure in call.c's error handling.
I'm sure that code doesn't work as-is, but hopefully you get the idea.
This is getting a bit convoluted. I thought the original patch posted
back in February was pretty sane, but as I look into a little more, it's
starting to get hairy.
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #14 from froydnj at codesourcery dot com froydnj at codesourcery dot com 2011-05-09 19:20:49 UTC --- On Mon, May 09, 2011 at 07:16:49PM +, redi at gcc dot gnu.org wrote: foo.C:blahblah: error: no matching function for call to foo foo.C:blahblah: note: candidate is foo(blahblah) foo.c:blahblah: note: substitution failed for parameter `F' At least, that's what I understood Jonathan asking for--perhaps he wanted something more detailed about why substitution failed, which is a debate for another time, I think. I would love to get more information, but I'd be very happy with the diagnostic above (that's already better than I'd get from any compiler I've tried) This PR is really just to get *anything* printed, so just a basic substition failed with no mention of which template parameter failed would be enough to resolve this IMHO. OK, well that's easy enough to provide, then. :)
[Bug c++/48737] [C++0x][SFINAE] Hard errors with array list-construction with too many elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48737 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-09 19:24:53 UTC --- Author: paolo Date: Mon May 9 19:24:50 2011 New Revision: 173590 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173590 Log: /cp 2011-05-09 Paolo Carlini paolo.carl...@oracle.com PR c++/48737 PR c++/48744 * decl.c (reshape_init): Take a complain parameter and do not call error if tf_error is not set. (check_initializer, reshape_init_r, reshape_init_array, reshape_init_array_1, reshape_init_vector, reshape_init_class): Adjust. * typeck2.c (digest_init_r): Take a complain parameter and pass it to convert_for_initialization. (digest_init, digest_init_flags, process_init_constructor_array, process_init_constructor_record, process_init_constructor_union, process_init_constructor, digest_init_r): Adjust. * init.c (expand_default_init, build_new_1): Likewise. * typeck.c (cp_build_modify_expr): Likewise. * decl2.c (grokfield): Likewise. * call.c (convert_like_real, convert_default_arg): Likewise. * semantics.c (finish_compound_literal): Pass complain to reshape_init and digest_init. * cp-tree.h: Adjust declarations. /testsuite 2011-05-09 Paolo Carlini paolo.carl...@oracle.com PR c++/48737 PR c++/48744 * g++.dg/template/sfinae28.C: New. * g++.dg/template/sfinae29.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/sfinae28.C trunk/gcc/testsuite/g++.dg/template/sfinae29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/init.c trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48744] [C++0x][SFINAE] Hard errors with list-initialization and void initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48744 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-09 19:24:53 UTC --- Author: paolo Date: Mon May 9 19:24:50 2011 New Revision: 173590 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173590 Log: /cp 2011-05-09 Paolo Carlini paolo.carl...@oracle.com PR c++/48737 PR c++/48744 * decl.c (reshape_init): Take a complain parameter and do not call error if tf_error is not set. (check_initializer, reshape_init_r, reshape_init_array, reshape_init_array_1, reshape_init_vector, reshape_init_class): Adjust. * typeck2.c (digest_init_r): Take a complain parameter and pass it to convert_for_initialization. (digest_init, digest_init_flags, process_init_constructor_array, process_init_constructor_record, process_init_constructor_union, process_init_constructor, digest_init_r): Adjust. * init.c (expand_default_init, build_new_1): Likewise. * typeck.c (cp_build_modify_expr): Likewise. * decl2.c (grokfield): Likewise. * call.c (convert_like_real, convert_default_arg): Likewise. * semantics.c (finish_compound_literal): Pass complain to reshape_init and digest_init. * cp-tree.h: Adjust declarations. /testsuite 2011-05-09 Paolo Carlini paolo.carl...@oracle.com PR c++/48737 PR c++/48744 * g++.dg/template/sfinae28.C: New. * g++.dg/template/sfinae29.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/sfinae28.C trunk/gcc/testsuite/g++.dg/template/sfinae29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/init.c trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48939] ICE in code involving procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48939 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-05-09 19:34:29 UTC --- Your code compiles on x86_64-*-freebsd with 4.6.1 20110509 and gcc version 4.7.0 20110509. There have only been a handful of patches to the 4.6 branch since 20110325, but it isn't clear if these should help. valgrind on the 4.6.1 f951 does not show anything bad. This could be target specific. Can you get a backtrace with a debuggers?
[Bug c++/48737] [C++0x][SFINAE] Hard errors with array list-construction with too many elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48737 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 19:26:47 UTC --- Done.
[Bug c++/48744] [C++0x][SFINAE] Hard errors with list-initialization and void initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48744 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 19:27:28 UTC --- Done.
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2011-05-09 20:10:23 UTC --- (In reply to comment #11) If I understand your proposal correctly, we'd get something more like: foo.C:blahblah: error: no matching function for call to foo foo.C:blahblah: note: candidate is foo(blahblah) foo.C:blahblah: error: [some explanation] which doesn't seem quite right. Having it use the error tag rather than note is suboptimal, but I think getting helpful error messages with relatively minimal compiler changes outweighs that aesthetic concern. :)
[Bug fortran/48939] ICE in code involving procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48939 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-09 20:27:30 UTC --- I can reproduce the failure with 4.6.1 20110421 (rev. 172818) and with openSUSE's 4.6.0 20110427 (Rev. 173021). However, it works with 4.7. Valgrind shows: ==10880== Invalid read of size 4 ==10880==at 0x5A3453: gfc_get_nodesc_array_type (trans-types.c:1433) ==10880==by 0x5A59D7: gfc_sym_type (trans-types.c:1977) ==10880==by 0x5A5164: gfc_get_function_type (trans-types.c:2575) ==10880==by 0x5A5B2A: gfc_get_ppc_type (trans-types.c:2136) ==10880==by 0x5A4CFF: gfc_get_derived_type (trans-types.c:2289) ==10880==by 0x5A5048: gfc_typenode_for_spec (trans-types.c:1060) (I think it could be a duplicate of PR 48588 (fixed Apr 19 for 4.7 and Apr 26 for 4.6). Or not - the program also fails with -fno-whole-file whereas PR 48588's example works with that option.)
[Bug c++/34772] [4.3/4.4/4.5/4.6 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34772 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Known to work||4.7.0 Summary|[4.3/4.4/4.5/4.6/4.7|[4.3/4.4/4.5/4.6 |Regression] |Regression] |self-initialisation does|self-initialisation does |not silence uninitialised |not silence uninitialised |warnings (-Winit-self |warnings (-Winit-self |ignored)|ignored) Known to fail|| --- Comment #17 from Jason Merrill jason at gcc dot gnu.org 2011-05-09 20:48:47 UTC --- Fixed on trunk so far.
[Bug c++/20039] uninitialized const in `new' of `const struct'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20039 --- Comment #5 from fabien at gcc dot gnu.org 2011-05-09 20:56:33 UTC --- Author: fabien Date: Mon May 9 20:56:29 2011 New Revision: 173592 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173592 Log: gcc/testsuite/ChangeLog: 2011-05-09 Fabien Chene fab...@gcc.gnu.org PR c++/20039 * g++.dg/init/pr20039.C: New. Added: trunk/gcc/testsuite/g++.dg/init/pr20039.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/48745] [C++0x] Segmentation fault with list-initialization, void initializers and variadics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48745 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.09 21:08:04 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/48735] [C++0x][SFINAE] Hard errors with array list-construction and deleted default c'tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48735 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.09 22:51:56 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 22:51:56 UTC --- Is already fixed in mainline, I'm going to add the testcase and close the PR.
[Bug c++/48735] [C++0x][SFINAE] Hard errors with array list-construction and deleted default c'tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48735 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-09 22:57:22 UTC --- Author: paolo Date: Mon May 9 22:57:19 2011 New Revision: 173597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173597 Log: 2011-05-09 Paolo Carlini paolo.carl...@oracle.com PR c++/48735 * g++.dg/cpp0x/sfinae21.C: New. 2011-05-09 Paolo Carlini paolo.carl...@oracle.com * g++.dg/template/sfinae28.C: Rename to... * g++.dg/cpp0x/sfinae19.C: ... this. * g++.dg/template/sfinae29.C: Rename to... * g++.dg/cpp0x/sfinae20.C: ... this. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae19.C - copied unchanged from r173596, trunk/gcc/testsuite/g++.dg/template/sfinae28.C trunk/gcc/testsuite/g++.dg/cpp0x/sfinae20.C - copied unchanged from r173596, trunk/gcc/testsuite/g++.dg/template/sfinae29.C trunk/gcc/testsuite/g++.dg/cpp0x/sfinae21.C Removed: trunk/gcc/testsuite/g++.dg/template/sfinae28.C trunk/gcc/testsuite/g++.dg/template/sfinae29.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/48735] [C++0x][SFINAE] Hard errors with array list-construction and deleted default c'tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48735 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 23:01:26 UTC --- Done.
[Bug c++/48522] [C++0x] decltype((object)) with templated classes crashes g++ 4.5.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48522 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.09 23:22:32 Known to work||4.7.0 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 23:22:32 UTC --- Indeed. I'm going to add the testcase to mainline and 4_6-branch and close the PR.
[Bug c++/48522] [C++0x] decltype((object)) with templated classes crashes g++ 4.5.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48522 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-09 23:24:23 UTC --- Author: paolo Date: Mon May 9 23:24:21 2011 New Revision: 173599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173599 Log: 2011-05-09 Paolo Carlini paolo.carl...@oracle.com PR c++/48522 * g++.dg/cpp0x/pr48522.C: New. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/pr48522.C Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/48522] [C++0x] decltype((object)) with templated classes crashes g++ 4.5.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48522 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 23:27:23 UTC --- Done.
[Bug c++/48522] [C++0x] decltype((object)) with templated classes crashes g++ 4.5.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48522 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-09 23:24:04 UTC --- Author: paolo Date: Mon May 9 23:24:01 2011 New Revision: 173598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173598 Log: 2011-05-09 Paolo Carlini paolo.carl...@oracle.com PR c++/48522 * g++.dg/cpp0x/pr48522.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr48522.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-09 23:52:04 UTC --- 4.5.3, 4.6 and mainline say: 44160.C: In lambda function: 44160.C:3:27: error: return-statement with a value, in function returning 'void' [-fpermissive] Is it good enough?
[Bug tree-optimization/48921] Value numbering takes infinite time on nested infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48921 --- Comment #3 from Arthur O'Dwyer arthur.j.odwyer at gmail dot com 2011-05-10 00:02:51 UTC --- (In reply to comment #2) You're right. It no longer reproduces in revision 173589 (2011-05-09).
[Bug target/48862] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48862 Dillon shangyunhai at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Dillon shangyunhai at gmail dot com 2011-05-10 00:41:40 UTC --- This is a duplicate of 48863 *** This bug has been marked as a duplicate of bug 48863 ***
[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863 --- Comment #3 from Dillon shangyunhai at gmail dot com 2011-05-10 00:41:40 UTC --- *** Bug 48862 has been marked as a duplicate of this bug. ***
[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863 --- Comment #2 from Dillon shangyunhai at gmail dot com 2011-05-10 00:40:16 UTC --- *** Bug 48861 has been marked as a duplicate of this bug. ***
[Bug target/48861] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48861 Dillon shangyunhai at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Dillon shangyunhai at gmail dot com 2011-05-10 00:40:16 UTC --- This is a duplicate of 48863 *** This bug has been marked as a duplicate of bug 48863 ***
[Bug c++/48940] New: GCC fails to issue expected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48940 Summary: GCC fails to issue expected error Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanc...@gmail.com Created attachment 24217 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24217 Test case which should not compile The expected error with the attached test case should be: test.cpp: In function ‘int main()’: test.cpp:18: error: ‘B::B(const B)’ is private test.cpp:24: error: within this context This is issued by versions around 4.2 (not specifically noted; I only have the mac version of 4.2, and while I had someone verify on another machine I don't have their exact version info). However, in GCC 4.4.5, the file instead compiles, which is correct for the new C++0x standard, but incorrect in C++98. -- g++ -v -save-temp -std=c++98 test.cpp Using built-in specs. g++-4.4.real: unrecognized option '-save-temp' Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --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.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) COLLECT_GCC_OPTIONS='-v' '-save-temp' '-std=c++98' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.4.5/cc1plus -quiet -v -D_GNU_SOURCE test.cpp -D_FORTIFY_SOURCE=2 -quiet -dumpbase test.cpp -mtune=generic -march=i686 -auxbase test -std=c++98 -version -fstack-protector -o /tmp/ccxISrDQ.s ignoring nonexistent directory /usr/local/include/i686-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../i686-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/include/c++/4.4 /usr/include/c++/4.4/i686-linux-gnu /usr/include/c++/4.4/backward /usr/local/include /usr/lib/gcc/i686-linux-gnu/4.4.5/include /usr/lib/gcc/i686-linux-gnu/4.4.5/include-fixed /usr/include/i686-linux-gnu /usr/include End of search list. GNU C++ (Ubuntu/Linaro 4.4.4-14ubuntu5) version 4.4.5 (i686-linux-gnu) compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 1fe36891f4a5f71e4a498e712867261c COLLECT_GCC_OPTIONS='-v' '-save-temp' '-std=c++98' '-shared-libgcc' '-mtune=generic' '-march=i686' as -V -Qy -o /tmp/ccxHGSfp.o /tmp/ccxISrDQ.s GNU assembler version 2.20.51 (i686-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.20.51-system.20100908 COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.4.5/:/usr/lib/gcc/i686-linux-gnu/4.4.5/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.4.5/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.4.5/:/usr/lib/gcc/i686-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.4.5/:/usr/lib/gcc/i686-linux-gnu/4.4.5/:/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/:/usr/lib/i686-linux-gnu/ COLLECT_GCC_OPTIONS='-v' '-save-temp' '-std=c++98' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.4.5/collect2 --build-id --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro /usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/crt1.o /usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/crti.o /usr/lib/gcc/i686-linux-gnu/4.4.5/crtbegin.o -L/usr/lib/gcc/i686-linux-gnu/4.4.5 -L/usr/lib/gcc/i686-linux-gnu/4.4.5 -L/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i686-linux-gnu/4.4.5/../../.. -L/usr/lib/i686-linux-gnu /tmp/ccxHGSfp.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i686-linux-gnu/4.4.5/crtend.o /usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/crtn.o
[Bug target/48941] New: [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 Summary: [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function. Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: jul...@cayzac.name Created attachment 24218 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24218 Source showcasing the problem Using some float32x4x2_t temporaries, some stack space is allocated even though the temporaries are made registers and stack never gets accessed inside the function. See attachment for C source and a corresponding assembly, produced with: arm-elf-gcc-4.5 -O3 -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=softfp -S -o - test.c | grep -vE '^[[:space:]]*[\.@].*$' (the grep is just there to remove lines of comments and directives) The problem also happens in C++. $ arm-elf-gcc-4.5 --version -v Using built-in specs. COLLECT_GCC=arm-elf-gcc-4.5 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/arm-elf/4.5.0/lto-wrapper arm-elf-gcc-4.5 (GCC) 4.5.0 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: arm-elf Configured with: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_arm-elf-gcc/work/gcc-4.5.0/configure --prefix=/opt/local --infodir=/opt/local/share/info --mandir=/opt/local/share/man --target=arm-elf --program-prefix=arm-elf- --program-suffix=-4.5 --without-included-gettext --enable-obsolete --with-newlib --disable-__cxa_atexit --enable-multilib --enable-biendian --disable-libgfortran --with-gxx-include-dir=/opt/local/arm-elf/include/c++/4.5.0/ --enable-languages=c,c++,objc --build=x86_64-apple-darwin10 --enable-fpu Thread model: single gcc version 4.5.0 (GCC) COLLECT_GCC_OPTIONS='-fversion' '-v' /opt/local/libexec/gcc/arm-elf/4.5.0/cc1 -quiet -v -D__USES_INITFINI__ help-dummy -quiet -dumpbase help-dummy -auxbase help-dummy -version -fversion -o /var/folders/Gn/GnNf6VbPEc4MTtfs4l39zU+++TI/-Tmp-//cc1shhZd.s GNU C (GCC) version 4.5.0 (arm-elf) compiled by GNU C version 4.2.1 (Apple Inc. build 5666) (dot 3), GMP version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2 warning: MPFR header version 3.0.0-p8 differs from library version 3.0.1-p3. warning: MPC header version 0.8.2 differs from library version 0.9. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-fversion' '-v' /opt/local/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/bin/as --version -o /var/folders/Gn/GnNf6VbPEc4MTtfs4l39zU+++TI/-Tmp-//ccuztVa3.o /var/folders/Gn/GnNf6VbPEc4MTtfs4l39zU+++TI/-Tmp-//cc1shhZd.s GNU assembler (Linux/GNU Binutils) 2.20.51.0.9.20100526 Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `arm-elf'. COMPILER_PATH=/opt/local/libexec/gcc/arm-elf/4.5.0/:/opt/local/libexec/gcc/arm-elf/4.5.0/:/opt/local/libexec/gcc/arm-elf/:/opt/local/lib/gcc/arm-elf/4.5.0/:/opt/local/lib/gcc/arm-elf/:/opt/local/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/bin/ LIBRARY_PATH=/opt/local/lib/gcc/arm-elf/4.5.0/:/opt/local/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/lib/ COLLECT_GCC_OPTIONS='-fversion' '-v' /opt/local/libexec/gcc/arm-elf/4.5.0/collect2 -X --version /opt/local/lib/gcc/arm-elf/4.5.0/crti.o /opt/local/lib/gcc/arm-elf/4.5.0/crtbegin.o /opt/local/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/lib/crt0.o -L/opt/local/lib/gcc/arm-elf/4.5.0 -L/opt/local/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/lib /var/folders/Gn/GnNf6VbPEc4MTtfs4l39zU+++TI/-Tmp-//ccuztVa3.o --start-group -lgcc -lc --end-group /opt/local/lib/gcc/arm-elf/4.5.0/crtend.o /opt/local/lib/gcc/arm-elf/4.5.0/crtn.o GNU ld (Linux/GNU Binutils) 2.20.51.0.9.20100526 Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.
[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-05-10 04:54:14 UTC --- No, the return type should be deduced as const char *.
