[Bug libstdc++/38233] New: 'map' value type + new uninitted const member warnings causes error
Consider the code:
#include
class a {
public:
a();
};
class b {
public:
// implicit default ctor
bool operator<(const b& rhs) const;
private:
a a_val;
};
typedef std::map my_map;
void func() {
my_map::value_type x;
}
That compiled correctly with 4.3.2. It fails to compile with pre-4.4 trunk:
Using built-in specs.
Target: i686-linux
Configured with: ../trunk/configure --enable-languages=c,c++ --build=i686-linux
--host=i686-linux --target=i686-linux
--prefix=/g/users/cgd/proj/gcc-trunk/bld/../inst
Thread model: posix
gcc version 4.4.0 20081123 (experimental) (GCC)
with the error:
In file included from
[...]/bin/../lib/gcc/i686-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_algobase.h:71,
from
[...]/bin/../lib/gcc/i686-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_tree.h:67,
from
[...]/bin/../lib/gcc/i686-linux/4.4.0/../../../../include/c++/4.4.0/map:65,
from test2.cc:1:
[...]/bin/../lib/gcc/i686-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h:
In constructor 'std::pair<_T1, _T2>::pair() [with _T1 = const b, _T2 = int]':
test2.cc:20: instantiated from here
[...]/bin/../lib/gcc/i686-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h:84:
error: uninitialized member 'std::pair::first' with 'const' type
'const b'
Looking at the preprocessed source (which i'll attach shortly), I see that
pair's default ctor is:
pair()
: first(), second() { }
I don't know if that's "right," but the C++98 std says that:
"Initializes its members as if implemented: pair() : first(T1()), second(T2())
{}"
(20.2.2, paragraph 2.)
If I change the pair() ctor to be:
pair()
: first(_T1()), second(_T2()) { }
(by hacking the preprocessed source), the result compiles correctly.
(I'm *so* far from an expert on STL that I'm not 100% sure that sample code is
actually valid, but on its face it seems reasonable at least, and 4.3.x
accepted it, and Comeau's test drive accepts it as well.)
--
Summary: 'map' value type + new uninitted const member warnings
causes error
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cgd at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38233
[Bug libstdc++/38233] 'map' value type + new uninitted const member warnings causes error
--- Comment #1 from cgd at google dot com 2008-11-23 08:48 --- Created an attachment (id=16750) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16750&action=view) preprocessed source from test case in bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38233
[Bug libfortran/38234] New: [4.4 Regression] In Reshape, SOURCE can be bigger than result
As noted by Dominique in PR 27766, the following test case is valid: program main real, dimension(2,2) :: result real, dimension(6) :: source real, dimension(2) :: pad call random_number (source) call random_number (pad) result = reshape(source, shape(result),pad=pad(1:0)) result = reshape(source, shape(result)) end program main Currently, this gets rejected with -fbounds-check ( a regression introduced by a recent patch of mine). -- Summary: [4.4 Regression] In Reshape, SOURCE can be bigger than result Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38234
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-11-23 08:54 --- (In reply to comment #6) > (2) The failure of gfortran.dg/bound_2.f90 comes from " Incorrect size in > SOURCE argument to RESHAPE intrinsic: is 9, should be 4". This is wrong, the > standard says: > > "If PAD is absent or of size zero, the size of SOURCE shall be greater than or > equal to PRODUCT (SHAPE)." You're right; this is now PR 38234. > (3) I think the failure of gfortran.dg/forall_13.f90: "Array reference out of > bounds for array 'p', upper bound of dimension 1 exceeded (4 > 3)", is also > wrong. This is PR 36091. We should run the testsuite with -fbounds-check to catch this kind of thing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|38234 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug libfortran/38234] [4.4 Regression] In Reshape, SOURCE can be bigger than result
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-23 09:39:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38234
[Bug testsuite/38235] New: gfortran.dg/pr37243.f has undefined variables / bounds error
$ ifort -CB pr37243.f $ ./a.out forrtl: severe (408): fort: (3): Subscript #2 of the array V has value 0 which is less than the lower bound of 1 Image PCRoutineLineSource a.out 0808C357 Unknown Unknown Unknown a.out 0808B977 Unknown Unknown Unknown a.out 0805934E Unknown Unknown Unknown a.out 0804B106 Unknown Unknown Unknown a.out 0804A79F Unknown Unknown Unknown a.out 0804A26E Unknown Unknown Unknown a.out 08049BAF Unknown Unknown Unknown a.out 08049B61 Unknown Unknown Unknown libc.so.6 B7E52455 Unknown Unknown Unknown a.out 08049A91 Unknown Unknown Unknown $ gfortran -fbounds-check pr37243.f $ ./a.out At line 37 of file pr37243.f Fortran runtime error: Array reference out of bounds for array 'v', lower bound of dimension 2 exceeded (-1081884012 < 1) -- Summary: gfortran.dg/pr37243.f has undefined variables / bounds error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38235
[Bug libstdc++/38210] num_put<>::do_put(void*) performs padding incorrectly when adjustfield==internal
--- Comment #4 from dominiq at lps dot ens dot fr 2008-11-23 11:12 --- On *-apple-darwin9, the following tests are now failing: FAIL: 22_locale/num_put/put/char/38210.cc execution test FAIL: 22_locale/num_put/put/wchar_t/38210.cc execution test -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
[Bug testsuite/38235] gfortran.dg/pr37243.f has undefined variables / bounds error
--- Comment #1 from dominiq at lps dot ens dot fr 2008-11-23 10:08 --- The variable II in "CALL DAXPY(N,DUM,V(1,II),1,V(1,I),1)" is not initialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38235
[Bug middle-end/38236] New: [4.4 Regression] SMT aliases incomplete
struct X { int i; };
int __attribute__((noinline))
foo (struct X *p, int *q, int a, int b)
{
struct X x, y;
if (a)
p = &x;
if (b)
q = &x.i;
else
q = &y.i;
*q = 1;
return p->i;
}
extern void abort (void);
int main()
{
if (foo((void *)0, (void *)0, 1, 1) != 1)
abort ();
return 0;
}
is miscompiled (the store to *q is deleted as unused) because the SMT used
for *p misses the x and y aliases as x and y are neither directly stored
nor is their SMT (but only the aliasing SMT for int).
--
Summary: [4.4 Regression] SMT aliases incomplete
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 38151
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38236
[Bug middle-end/38236] [4.4 Regression] SMT aliases incomplete
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-23 12:11 --- Mine. Patch posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-23 12:11:01 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38236
[Bug middle-end/38236] [4.4 Regression] SMT aliases incomplete
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-23 12:17 ---
GCC 4.3 is "safe" because it doesn't fall back to anything for p, but uses
{ x, y, ANYTHING } instead. In turn it heavily relies on correct call clobbers
if you obfuscate the pointers. Which makes me not entirely convinced that
I cannot make this latent problem trigger on the 4.3 branch ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38236
[Bug c++/38232] [4.4 Regression] "value-initialization of reference" warning too strict
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-23 12:20 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to work||4.3.2 Last reconfirmed|-00-00 00:00:00 |2008-11-23 12:20:31 date|| Summary|"value-initialization of|[4.4 Regression] "value- |reference" warning too |initialization of reference" |strict |warning too strict Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38232
[Bug libstdc++/38233] [4.4 Regression] 'map' value type + new uninitted const member warnings causes error
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid Known to work||4.3.2 Summary|'map' value type + new |[4.4 Regression] 'map' value |uninitted const member |type + new uninitted const |warnings causes error |member warnings causes error Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38233
[Bug libstdc++/38210] num_put<>::do_put(void*) performs padding incorrectly when adjustfield==internal
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-23 12:02 --- Apparently the failures I have reported in comment #4 disappear if I rebuild libstdc++. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #16 from steven at gcc dot gnu dot org 2008-11-23 13:07 --- Created an attachment (id=16751) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16751&action=view) Proof-of-concept patch It is not terribly complicated to add hoisting to tree-ssa-pre.c. I have attached the result of roughly half a day of hacking. It is a proof-of-concept patch that demonstrates how hoisting could be added. It's not finished, tested, or even correct ;-) but it shows the general idea. For a "production-quality" version, one would have to make sure not to hoist expressions up too far (e.g. not further up than above the first block that generates the expression). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #17 from steven at gcc dot gnu dot org 2008-11-23 13:11 ---
For the test case of comment #0, the proof-of-concept patch does the following
in the .084t.pre dump (relevant excerpts only):
VBEOUT[2] := { {lshift_expr,a_2(D),1} (0004) }
Inserting expression 5 into AVAIL_OUT[2]
Inserted pretmp.12_8 = a_2(D) << 1;
in predecessor 2
AVAIL_OUT[2] := { a_2(D) (0002), a.0_3 (0003), pretmp.12_8 (0004) }
Successor 1 not dominated by 5 -> empty set
VBEOUT[5] := { }
AVAIL_OUT[5] := { a_2(D) (0002), a.0_3 (0003), a_1 (0001), pretmp.12_8 (0004) }
Successor 5 not dominated by 4 -> empty set
VBEOUT[4] := { }
AVAIL_OUT[4] := { a_2(D) (0002), a.0_3 (0003), pretmp.12_8 (0004) }
Successor 5 not dominated by 3 -> empty set
VBEOUT[3] := { }
AVAIL_OUT[3] := { a_2(D) (0002), a.0_3 (0003), a_5 (0005), pretmp.12_8 (0004) }
Replaced a_2(D) << 1 with pretmp.12_8 in a_4 = a_2(D) << 1;
Replaced a_2(D) << 1 with pretmp.12_8 in a_6 = a_2(D) << 1;
...
f (short unsigned int a)
{
short unsigned int pretmp.12;
short int a.0;
:
a.0_3 = (short int) a_2(D);
pretmp.12_8 = a_2(D) << 1;
if (a.0_3 < 0)
goto ;
else
goto ;
:
a_4 = pretmp.12_8;
a_5 = a_4 ^ 4129;
goto ;
:
a_6 = pretmp.12_8;
:
# a_1 = PHI
return a_1;
}
which eventually leads to the following in the .126t.final_cleanup dump:
;; Function f (f)
f (short unsigned int a)
{
short unsigned int a.22;
:
a.22 = a << 1;
if ((short int) a < 0)
goto ;
else
goto ;
:
a.22 = a.22 ^ 4129;
:
return a.22;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #18 from steven at gcc dot gnu dot org 2008-11-23 13:22 ---
The test case of PR38204 shows one of the problems with proof-of-concept patch,
namely the "don't move up too much" problem. The .pre dump looks like this:
test (int a, int b, int c, int g)
{
int pretmp.11;
int e;
int d;
int D.1257;
int D.1256;
:
pretmp.11_11 = b_3(D) * c_4(D);
pretmp.11_12 = g_8(D) + pretmp.11_11; // No need to move this up to here.
if (a_2(D) != 0)
goto ;
else
goto ;
:
d_5 = pretmp.11_11;
goto ;
:
d_6 = b_3(D) - c_4(D);
:
# d_1 = PHI
D.1256_7 = pretmp.11_11;
e_9 = pretmp.11_12;
D.1257_10 = e_9 + d_1;
return D.1257_10;
}
Eventually this gives (in the .final_cleanup dump):
;; Function test (test)
test (int a, int b, int c, int g)
{
int d.21;
int d;
:
d.21 = c * b;
if (a != 0)
goto ;
else
goto ;
:
d = d.21;
goto ;
:
d = b - c;
:
return (d.21 + g) + d;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-11-23 13:32 --- Nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-11-23 13:43
---
We also need to make sure not to do hoisting where we should do sinking like
for
int foo(int b, int i)
{
int res;
if (b)
res = i + 1;
else
res = i + 1;
return res;
}
(add some more code that shows the increased life-range of res would hurt)
I guess sinking doesn't really fit the PRE framework.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug libstdc++/38210] num_put<>::do_put(void*) performs padding incorrectly when adjustfield==internal
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-23 14:01 --- (In reply to comment #5) > Apparently the failures I have reported in comment #4 disappear if I rebuild > libstdc++. Not surprising ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
[Bug middle-end/38237] New: [4.4 regression] multiple weak directives
This is a fallout of
2008-08-19 Rafael EspÃndola <[EMAIL PROTECTED]>
* varasm.c (weak_decls): Move earlier in the file.
(assemble_external): Add weak decls to the weak_decls list.
(declare_weak): Don't add decls to the weak_decls list.
[EMAIL PROTECTED]:~/build/gcc/native32> cat t.c
extern int i __attribute__((weak));
void foo(void)
{
int a = i + i + i + i;
}
[EMAIL PROTECTED]:~/build/gcc/native32> cat t.s
.file "t.c"
.text
.globl foo
.type foo, @function
foo:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
movli, %edx
movli, %eax
addl%eax, %edx
movli, %eax
addl%eax, %edx
movli, %eax
leal(%edx,%eax), %eax
movl%eax, -4(%ebp)
leave
ret
.size foo, .-foo
.weak i
.weak i
.weak i
.weak i
.ident "GCC: (GNU) 4.4.0 20081122 (experimental) [trunk revision
142117]"
.section.note.GNU-stack,"",@progbits
--
Summary: [4.4 regression] multiple weak directives
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38237
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #21 from steven at gcc dot gnu dot org 2008-11-23 14:20 --- I'll work on something that bootstraps and passes testing. But cost-related decisions (like the one from comment #20) are not on my TODO list right now. The pass that should do this is called sched1 ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug middle-end/38237] [4.4 regression] multiple weak directives
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38237
[Bug libstdc++/38233] [4.4 Regression] 'map' value type + new uninitted const member warnings causes error
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-23 14:41 --- There is a defect report which changed C++98 dealing with default initialization which might be causing this issue, see DR178. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38233
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #16 from tkoenig at gcc dot gnu dot org 2008-11-23 15:10 --- Subject: Bug 38135 Author: tkoenig Date: Sun Nov 23 15:08:32 2008 New Revision: 142134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142134 Log: 2008-11-23 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/38135 Backport from trunk. * m4/reshape.m4: Tread PAD as if it were SOURCE when SOURCE is empty. * intrinsics/reshape_generic.c: Likewise. * generated/reshape_c10.c Regenerated. * generated/reshape_c16.c Regenerated. * generated/reshape_c4.c Regenerated. * generated/reshape_c8.c Regenerated. * generated/reshape_i16.c Regenerated. * generated/reshape_i4.c Regenerated. * generated/reshape_i8.c Regenerated. * generated/reshape_r10.c Regenerated. * generated/reshape_r16.c Regenerated. * generated/reshape_r4.c Regenerated. * generated/reshape_r8.c Regenerated. 2008-11-23 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/38135 Backport from trunk. * gfortran.dg/reshape_pad_1.f90: New test case. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/reshape_pad_1.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/generated/reshape_c10.c branches/gcc-4_3-branch/libgfortran/generated/reshape_c16.c branches/gcc-4_3-branch/libgfortran/generated/reshape_c4.c branches/gcc-4_3-branch/libgfortran/generated/reshape_c8.c branches/gcc-4_3-branch/libgfortran/generated/reshape_i16.c branches/gcc-4_3-branch/libgfortran/generated/reshape_i4.c branches/gcc-4_3-branch/libgfortran/generated/reshape_i8.c branches/gcc-4_3-branch/libgfortran/generated/reshape_r10.c branches/gcc-4_3-branch/libgfortran/generated/reshape_r16.c branches/gcc-4_3-branch/libgfortran/generated/reshape_r4.c branches/gcc-4_3-branch/libgfortran/generated/reshape_r8.c branches/gcc-4_3-branch/libgfortran/intrinsics/reshape_generic.c branches/gcc-4_3-branch/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #17 from tkoenig at gcc dot gnu dot org 2008-11-23 15:10 --- Fixed on 4.3. Closing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #18 from tkoenig at gcc dot gnu dot org 2008-11-23 15:17 --- ... and now really closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug libstdc++/38238] New: std::tr1::bind fails to compile with pointer to member function
The following example fails to compile:
#include
#include
using namespace std::tr1::placeholders;
class player
{
public:
void play(int time) { printf("player::play(%d);\n", time);}
void stop() { printf("player::stop();\n"); }
};
int main()
{
player thePlayer;
std::tr1::bind(&player::play, &thePlayer, _1)(2);
return 0;
}
Here is the output of the compiler:
test_bind.cpp: In function int main():
test_bind.cpp:19: error: no match for call to
(std::tr1::_Bind ()(player*,
std::tr1::_Placeholder<1>)>) (int)
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1190:
note: candidates are: typename std::tr1::result_of<_Functor ()(typename
std::tr1::result_of 0)>
()(_Bound_args, std::tr1::tuple<_UElements ...>)>::type ...)>::type
std::tr1::_Bind<_Functor ()(_Bound_args ...)>::operator()(_Args& ...) [with
_Args = int, _Functor = std::tr1::_Mem_fn, _Bound_args =
player*, std::tr1::_Placeholder<1>]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1201:
note: typename std::tr1::result_of 0)>
()(_Bound_args, std::tr1::tuple<_UElements ...>)>::type ...)>::type
std::tr1::_Bind<_Functor ()(_Bound_args ...)>::operator()(_Args& ...) const
[with _Args = int, _Functor = std::tr1::_Mem_fn,
_Bound_args = player*, std::tr1::_Placeholder<1>]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1213:
note: typename std::tr1::result_of 0)>
()(_Bound_args, std::tr1::tuple<_UElements ...>)>::type ...)>::type
std::tr1::_Bind<_Functor ()(_Bound_args ...)>::operator()(_Args& ...) volatile
[with _Args = int, _Functor = std::tr1::_Mem_fn,
_Bound_args = player*, std::tr1::_Placeholder<1>]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1226:
note: typename std::tr1::result_of 0)>
()(_Bound_args, std::tr1::tuple<_UElements ...>)>::type ...)>::type
std::tr1::_Bind<_Functor ()(_Bound_args ...)>::operator()(_Args& ...) const
volatile [with _Args = int, _Functor = std::tr1::_Mem_fn, _Bound_args = player*, std::tr1::_Placeholder<1>]
The example compiles fine by replacing tr1::bind with boost::bind.
Best regards,
Teodor Petrov
--
Summary: std::tr1::bind fails to compile with pointer to member
function
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fuscated at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38238
[Bug middle-end/38237] [4.4 regression] multiple weak directives
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-23 16:14 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-23 16:14:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38237
[Bug target/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-23 16:47 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-23 16:47:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug c++/38228] ICE when abusing std::function
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-23 16:49 --- Reducing ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug c/38239] New: mcount in gmon.o change register ecx
Following program
cat >test-pg-src.c <
int
main(int argc, char **argv)
{
printf("argc: %d argv: %p\n", argc, argv);
return 0;
}
EOF
compiled with "-pg" options
gcc -pg -o test-pg test-pg-src.c
results in following code (disassembled with mdb)
main: leal 0x4(%esp),%ecx
main+4: andl $0xfff0,%esp
main+7: pushl -0x4(%ecx)
main+0xa: pushl %ebp
main+0xb: movl %esp,%ebp
main+0xd: pushl %ecx
main+0xe: subl $0x14,%esp
main+0x11: movl $0x8049ed0,%edx
main+0x16: call -0x5d3 <_mcount>
main+0x1b: movl 0x4(%ecx),%eax ; either _mcount should not change ecx
; or the compiler should restore ecx -
; for example "movl 0x14(%esp), %ecx"
; (the number 0x14 is taken from the line
; "main+0xe: subl $0x14,%esp")
main+0x1e: movl %eax,0x8(%esp)
main+0x22: movl (%ecx),%eax
main+0x24: movl %eax,0x4(%esp)
main+0x28: movl $0x8048d6c,(%esp)
main+0x2f: call -0x6c8
main+0x34: movl $0x0,%eax
main+0x39: addl $0x14,%esp
main+0x3c: popl %ecx
main+0x3d: popl %ebp
main+0x3e: leal -0x4(%ecx),%esp
main+0x41: ret
After call to mcount register ecx is changed, but commands, following call to
mcount, assume the register ecx unchanged.
--
Summary: mcount in gmon.o change register ecx
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: YLitvinenko at astana dot oilfield dot slb dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38239
[Bug target/38239] The function mcount in gmon.o changes register ecx
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38239
[Bug c++/38228] ICE when abusing std::function
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-23 18:25 ---
Reduced testcase:
namespace std {
template class function;
template struct
function<_Res(_ArgTypes...)>
{
template function(_Functor __f);
};
}
struct foo {
void bar();
};
foo f;
void (foo::*a)()=&foo::bar;
std::function funct=((f).*(a));
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-11-23 18:25:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-11-23 18:28 --- >But -mavx -msse5 will generate codes which won't run on any machines. It could run on a simulator that has both (or a new processor which has not come out yet). Or are there conflicts with the opcodes themselves? So I don't see why this is a really a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #22 from dberlin at gcc dot gnu dot org 2008-11-23 18:30
---
Subject: Re: missed fully redundant expression
Sinking fits into the reverse framework.
Apparently the SSUPRE person plans on submitting when 4.5 opens, and
you can fit sinking frameworks into there.
On Sun, Nov 23, 2008 at 8:43 AM, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #20 from rguenth at gcc dot gnu dot org 2008-11-23 13:43
> ---
> We also need to make sure not to do hoisting where we should do sinking like
> for
>
> int foo(int b, int i)
> {
> int res;
> if (b)
>res = i + 1;
> else
>res = i + 1;
> return res;
> }
>
> (add some more code that shows the increased life-range of res would hurt)
>
> I guess sinking doesn't really fit the PRE framework.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug c++/38232] [4.4 Regression] "value-initialization of reference" warning too strict
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-23 18:31 --- DR 178 changed some of the behavior here and I think what GCC is doing is now the correct behavior according to that Defect report. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#178 See Also PR 36394 and PR 11309. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38232
[Bug testsuite/38221] [4.3 Regression]FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for warnings, line )
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to work||4.3.2 Summary|FAIL: gcc.c-|[4.3 Regression]FAIL: gcc.c- |torture/compile/sync-3.c - |torture/compile/sync-3.c - |O0 (test for warnings,|O0 (test for warnings, |line ) |line ) Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38221
[Bug target/38222] gcc.target/i386/sse4_2-popcntl.c fails on i686-apple-darwin9
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|testsuite |target Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38222
[Bug c/38218] gcc.dg/and-1.c scan-assembler-not nand fails on powerpc-apple-darwin9
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-23 18:45 --- *** This bug has been marked as a duplicate of 33512 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38218
[Bug tree-optimization/33512] Simple bitwise simplification missed
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-11-23 18:45 --- *** Bug 38218 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33512
[Bug testsuite/38216] gcc.target/powerpc/pr18096-1.c fails to compile on powerpc-*-*
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-23 18:46 --- This is just a testsuite issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|target |testsuite Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin9 | GCC host triplet|powerpc-apple-darwin9 | GCC target triplet|powerpc-apple-darwin9 |powerpc*-*-* Last reconfirmed|-00-00 00:00:00 |2008-11-23 18:46:30 date|| Summary|gcc.target/powerpc/pr18096- |gcc.target/powerpc/pr18096- |1.c fails to compile on |1.c fails to compile on |powerpc-apple-darwin* |powerpc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38216
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc-apple-darwin9
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-23 18:44 --- The patch which introduced this testcase: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01925.html I thought I reported this failure to Paolo but I can't find the email. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-11-23 18:44:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219
[Bug c++/38211] [4.2 regression] g++ 4.2 SIGSEGV in tree_inlinable_function_p
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|g++ 4.2 SIGSEGV in |[4.2 regression] g++ 4.2 |tree_inlinable_function_p |SIGSEGV in ||tree_inlinable_function_p Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38211
[Bug libgomp/28708] FAIL: libgomp.fortran/vla6.f90 -O0 execution test
--- Comment #3 from danglin at gcc dot gnu dot org 2008-11-23 18:46 --- This test also fails on linux SMP machines. Test fails on 4.3.x and 4.4.0. -- danglin at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa*-hp-hpux11* (32 bit) |hppa*-*-* (32 bit) GCC host triplet|hppa*-hp-hpux11* (32 bit) |hppa*-*-* (32 bit) GCC target triplet|hppa*-hp-hpux11* (32 bit) |hppa*-*-* (32 bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28708
[Bug middle-end/38240] New: Vector type definitions not compatible with attribute target
The attached test case segfaults because the definition of V would differ with and without -msse. Without, we would use vector emulation and the type has BLKmode; with, we would have native instructions and the type has V4SFmode. Vector types probably need a functional query for TYPE_MODE, so that we get different modes based on the target flags for the current function. -- Summary: Vector type definitions not compatible with attribute target Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rth at gcc dot gnu dot org GCC target triplet: i386-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38240
[Bug middle-end/38209] branch optimisation generates worse code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-23 18:55 ---
This happens on i386-darwin also (-m64 -O2 -fomit-frame-pointer):
movl%edi, %edx
testb %dil, %dil
movl$-1, %eax
notl%edx
cmovne %edx, %eax
Using the following source:
unsigned char negate(unsigned char val)
{
if (val)
val = ~val;
else
val = ~val;
return val;
}
We should be able to just do ~val but this comes down to hoisting before
applying VRP/DOM.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i386-linux-gnu |
GCC host triplet|i386-linux-gnu |
GCC target triplet|avr-*-* |
Last reconfirmed|-00-00 00:00:00 |2008-11-23 18:55:59
date||
Summary|[avr] branch optimisation |branch optimisation
|generates worse code|generates worse code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38209
[Bug middle-end/38240] Vector type definitions not compatible with attribute target
--- Comment #1 from rth at gcc dot gnu dot org 2008-11-23 18:56 --- Created an attachment (id=16752) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16752&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38240
[Bug target/38208] [4.4 Regression] gcc.c-torture/compile/20080806-1.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38208
[Bug middle-end/38240] Vector type definitions not compatible with attribute target
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-23 18:58:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38240
[Bug c++/38206] g++ crashes when compiling trivial code (~10 line test case)
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-11-23 19:01 --- This was fixed with the fix for PR 5247. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38206
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-23 19:07 --- Confirmed, trying to figure out what is going wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-23 19:07:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #20 from burnus at gcc dot gnu dot org 2008-11-23 19:07 ---
Mikael, Daniel: Have I missed something or is everything in this PR fixed in
4.4 ("trunk") and only some 4.3 back porting is needed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug libfortran/38234] [4.4 Regression] In Reshape, SOURCE can be bigger than result
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-11-23 19:27 --- Subject: Bug 38234 Author: tkoenig Date: Sun Nov 23 19:25:42 2008 New Revision: 142137 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142137 Log: 2008-11-23 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/38234 * intrinsics/reshape_generic.c (reshape_internal): Source can be larger than shape. * m4/reshape.m4: Likewise. * generated/reshape_c10.c Regenerated. * generated/reshape_c16.c Regenerated. * generated/reshape_c4.c Regenerated. * generated/reshape_c8.c Regenerated. * generated/reshape_i16.c Regenerated. * generated/reshape_i4.c Regenerated. * generated/reshape_i8.c Regenerated. * generated/reshape_r10.c Regenerated. * generated/reshape_r16.c Regenerated. * generated/reshape_r4.c Regenerated. * generated/reshape_r8.c Regenerated. 2008-11-23 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/38234 * gfortran.dg/reshape_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/reshape_4.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/reshape_c10.c trunk/libgfortran/generated/reshape_c16.c trunk/libgfortran/generated/reshape_c4.c trunk/libgfortran/generated/reshape_c8.c trunk/libgfortran/generated/reshape_i16.c trunk/libgfortran/generated/reshape_i4.c trunk/libgfortran/generated/reshape_i8.c trunk/libgfortran/generated/reshape_r10.c trunk/libgfortran/generated/reshape_r16.c trunk/libgfortran/generated/reshape_r4.c trunk/libgfortran/generated/reshape_r8.c trunk/libgfortran/intrinsics/reshape_generic.c trunk/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38234
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-23 19:30 --- Can you provide the preprocessed source and the output of adding -v to the invocation line? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|other |target Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug libfortran/38234] [4.4 Regression] In Reshape, SOURCE can be bigger than result
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-11-23 19:32 --- Fixed. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38234
[Bug target/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-11-23 20:41 --- Patch for this problem Index: calls.c === --- calls.c (revision 142122) +++ calls.c (working copy) @@ -2077,7 +2077,7 @@ } #ifdef REG_PARM_STACK_SPACE - reg_parm_stack_space = REG_PARM_STACK_SPACE (fndecl); + reg_parm_stack_space = REG_PARM_STACK_SPACE (!fndecl ? fntype : fndecl); #endif if (! OUTGOING_REG_PARM_STACK_SPACE ((!fndecl ? NULL_TREE : TREE_TYPE (fndecl))) Index: config/i386/i386.c === --- config/i386/i386.c (revision 142122) +++ config/i386/i386.c (working copy) @@ -4547,9 +4547,11 @@ /* For libcalls it is possible that there is no fndecl at hand. Therefore assume for this case the default abi of the target. */ if (!fndecl) -call_abi = DEFAULT_ABI; +call_abi = (cfun ? cfun->machine->call_abi : DEFAULT_ABI); + else if (TREE_CODE (fndecl) == FUNCTION_DECL) +call_abi = ix86_function_abi (fndecl); else -call_abi = ix86_function_abi (fndecl); +call_abi = ix86_function_type_abi (fndecl); if (call_abi == 1) return 32; return 0; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #8 from dominiq at lps dot ens dot fr 2008-11-23 20:52 --- For gfortran.dg/g77/dnrm2.f the failure comes from the old style array declaration: double precision dx(1), cutlo, cuthi, hitest, sum, xmax,zero,one If 'dx(1)' is replaced by 'dx(*)', -fbounds-check does not detect any error (which may be wrong, but I don't think there is any way to detect the problem with a local analysis). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #9 from dominiq at lps dot ens dot fr 2008-11-23 21:02 --- In addition to comment #8, the bound check would be possible using: double precision dx(n), cutlo, cuthi, hitest, sum, xmax,zero,one -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug target/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #4 from m dot b dot lankhorst at gmail dot com 2008-11-23 21:11 --- Patch seems to fix the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug fortran/38184] invariant RESHAPE not expanded if SOURCE is empty
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-23 21:27 --- (In reply to comment #2) > How about packaging your patch and submitting it? > It seems you missed it. http://gcc.gnu.org/ml/fortran/2008-11/msg00249.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38184
[Bug fortran/37735] Allocatable components in vectors of derived types cause ICE on assignment
--- Comment #4 from pault at gcc dot gnu dot org 2008-11-23 21:36 --- Subject: Bug 37735 Author: pault Date: Sun Nov 23 21:34:44 2008 New Revision: 142142 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142142 Log: 2008-11-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37735 * trans-array.c (structure_alloc_comps): Do not duplicate the descriptor if this is a descriptorless array! 2008-11-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37735 * gfortran.dg/alloc_comp_assign_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37735
[Bug testsuite/38241] New: g++.old-deja/g++.pt/const2.C fails on *-apple-darwin9
Currently we are failing g++.old-deja/g++.pt/const2.C at both -m32 and -m64 on i686-apple-darwin9 and powerpc-apple-darwin9 because the darwin linker returns the error... Undefined symbols: "A::i", referenced from: _p in ccXjnF0c.o ld: symbol(s) not found collect2: ld returned 1 exit status compiler exited with status 1 output is: Undefined symbols: "A::i", referenced from: _p in ccXjnF0c.o ld: symbol(s) not found collect2: ld returned 1 exit status PASS: g++.old-deja/g++.pt/const2.C (test for warnings, line ) FAIL: g++.old-deja/g++.pt/const2.C (test for excess errors) Excess errors: ld: symbol(s) not found compared to... /tmp/ccYcm70t.o:(.data+0x0): undefined reference to `A::i' collect2: ld returned 1 exit status ...on linux. An additional dg-message line in this test case needs to be added to either find the Undefined on the first line or the "i" on the second line of the darwin linker error message. -- Summary: g++.old-deja/g++.pt/const2.C fails on *-apple-darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *-apple-darwin9 GCC host triplet: *-apple-darwin9 GCC target triplet: *-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38241
[Bug testsuite/38241] g++.old-deja/g++.pt/const2.C fails on *-apple-darwin9
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-23
22:20 ---
Is there any documentation available for dg-message? Specifically what is the
purpose of the last digit in...
// { dg-message "i" "" { target *-*-* } 0 }
So far I am not having much luck recrafting a line like...
// { dg-message "Undefined symbols:" "" { target *-*-darwin* } 0 }
or
// { dg-message "i" "" { target *-*-darwin* } 1 }
to allow the const2.C test to pass on darwin. From the comment in the testcase
of...
// This test should get a linker error for the reference to A::i.
we should be passing this on darwin, no?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38241
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #10 from dominiq at lps dot ens dot fr 2008-11-23 22:39 --- With the following changes: Only in ../_gcc_clean/gcc/testsuite/gfortran.dg/: array_memset_2.f90 Only in gcc/testsuite/gfortran.dg/: array_setmem_2.f90 --- ../_gcc_clean/gcc/testsuite/gfortran.dg/pr37243.f 2008-09-04 19:10:20.0 +0200 +++ gcc/testsuite/gfortran.dg/pr37243.f 2008-11-23 22:54:23.0 +0100 @@ -34,7 +34,7 @@ IF (J .GT. N) GO TO 320 DO 240 K = 1,N 240 V(K,I) = ZERO - CALL DAXPY(N,DUM,V(1,II),1,V(1,I),1) + CALL DAXPY(N,DUM,V(1,I),1,V(1,I),1) 260 CONTINUE DUMI = ZERO DO 280 K = 1,N --- ../_gcc_clean/gcc/testsuite/gfortran.dg/g77/dnrm2.f 2007-11-07 10:25:55.0 +0100 +++ gcc/testsuite/gfortran.dg/g77/dnrm2.f 2008-11-23 22:53:37.0 +0100 @@ -26,7 +26,7 @@ double precision function dnrm2 ( n, dx, incx) integer i, incx, ix, j, n, next - double precision dx(1), cutlo, cuthi, hitest, sum, xmax,zero,one + double precision dx(n), cutlo, cuthi, hitest, sum, xmax,zero,one data zero, one /0.0d0, 1.0d0/ data cutlo, cuthi / 8.232d-11, 1.304d19 / j = 0 I only get the following failures with -fbounds-check: FAIL: gfortran.dg/forall_13.f90 -O0 execution test FAIL: gfortran.dg/forall_13.f90 -O1 execution test FAIL: gfortran.dg/forall_13.f90 -O2 execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/forall_13.f90 -O3 -g execution test FAIL: gfortran.dg/forall_13.f90 -Os execution test FAIL: gfortran.dg/ldist-1.f90 -O scan-tree-dump-times ldist "distributed: split to 4 loops" 1 FAIL: gfortran.dg/ltrans-7.f90 -O scan-tree-dump-times ltrans "transformed loop" 1 FAIL: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1 "[0-9] \* " 22 FAIL: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times vect "Alignment of access forced using peeling" 1 FAIL: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times vect "Vectorizing an unaligned access" 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect "Alignment of access forced using peeling" 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect "Vectorizing an unaligned access" 1 FAIL: gfortran.dg/vect/pr19049.f90 -O scan-tree-dump-times vect "complicated access pattern" 1 So, but for pr36091, the failures are expected regexps changed by -fbounds-check which is not too surprising. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug c++/38242] New: Overeager ADL searches associated namespaces of base class's template arguments
The following code compiles. It shouldn't. The operator+ should not be found.
According to 3.4.2/2, the associated namespace of a type includes those of its
bases and of its template arguments, but not its bases' template arguments.
namespace N
{
struct S {};
template
void operator+(T const &, U const &) {}
}
template struct X {};
struct Y : X {};
int main()
{
Y y;
y+y; // this should fail.
}
--
Summary: Overeager ADL searches associated namespaces of base
class's template arguments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
GCC build triplet: g++ 4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38242
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #2 from special at dereferenced dot net 2008-11-23 23:46 --- Created an attachment (id=16753) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16753&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #3 from special at dereferenced dot net 2008-11-23 23:48 --- Output of the failed command with -v (removed irrelevant lines of 'ignoring nonexistant/duplicate directory' for incldues): Reading specs from /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/specs Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2) COLLECT_GCC_OPTIONS='-B/var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/' '-B/usr/i686-pc-linux-gnu/bin/' '-c' '-O2' '-pipe' '-fprofile-generate' '-DIN_GCC' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wold-style-definition' '-Wmissing-format-attribute' '-pedantic' '-Wno-long-long' '-Wno-variadic-macros' '-Wno-overlength-strings' '-DHAVE_CONFIG_H' '-I.' '-I.' '-I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc' '-I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/.' '-I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../include' '-I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libcpp/include' '-I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libdecnumber' '-I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libdecnumber/bid' '-I../libdecnumber' '-I../../build/gcc/' '-v' '-o' 'sbitmap.o' /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/cc1 -quiet -v -I. -I. -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/. -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../include -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libcpp/include -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libdecnumber/bid -I../libdecnumber -I../../build/gcc/ -iprefix /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/prev-gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.2/ -isystem /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/include -isystem /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/include-fixed -DIN_GCC -DHAVE_CONFIG_H /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/sbitmap.c -march=amdfam10 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 -mtune=amdfam10 -quiet -dumpbase sbitmap.c -auxbase-strip sbitmap.o -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -version -fprofile-generate -o - | /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/as -V -Qy -o sbitmap.o - #include "..." search starts here: #include <...> search starts here: . /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../include /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libcpp/include /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libdecnumber /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libdecnumber/bid ../../build/gcc/ /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/include /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/include-fixed /usr/include End of search list. GNU C (Gentoo 4.3.2) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1. GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.18 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 930702400f402cfbdac6d055d258069e /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/sbitmap.c: In function 'sbitmap_popcount': /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/sbitmap.c:1047: internal compiler error: in memory_address_length, at config/i386/i386.c:16380 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug c++/38232] [4.4 Regression] "value-initialization of reference" warning too strict
--- Comment #3 from crowl at google dot com 2008-11-23 23:50 --- The relevant change in DR 178 is To value-initialize an object of type T means: * if T is a class type (clause 9 [class]) with a user-declared constructor (12.1 [class.ctor]), then the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor); The default constructor for derived should call the default constructor for base. The base constructor is defined in another file, and so any incorrect code in the base constructor should be flagged in another compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38232
[Bug testsuite/38241] g++.old-deja/g++.pt/const2.C fails on *-apple-darwin9
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-11-24 00:54 --- The patch submitted in... http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01231.html ...prunes the output lines for those containing "ld: symbol" which eliminates the bogus execessive errors failure on *-*-darwin*.est Run By root on Sun Nov 23 19:42:57 2008 Native configuration is i686-apple-darwin10 === g++ tests === Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /sw/src/fink.build/gcc44-4.3.999-20081122/gcc-4.4-20081122/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /sw/src/fink.build/gcc44-4.3.999-20081122/gcc-4.4-20081122/gcc/testsuite/g++.old-deja/old-deja.exp ... === g++ Summary for unix/-m32 === # of expected passes2 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /sw/src/fink.build/gcc44-4.3.999-20081122/gcc-4.4-20081122/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /sw/src/fink.build/gcc44-4.3.999-20081122/gcc-4.4-20081122/gcc/testsuite/g++.old-deja/old-deja.exp ... === g++ Summary for unix/-m64 === # of expected passes2 === g++ Summary === # of expected passes4 /sw/src/fink.build/gcc44-4.3.999-20081122/darwin_objdir/gcc/testsuite/g++/../../g++ version 4.4.0 20081122 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38241
[Bug fortran/38066] bug6 ambiguous reference
--- Comment #9 from clerman at fuse dot net 2008-11-24 02:18 --- Subject: Re: bug6 ambiguous reference Mikael, Thank you for responding to this bug report, and please excuse my delay in replying. I have rewritten the code in question, and it now works fine. Thanks to everyone for their attention and assistance. Norm Clerman mikael at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #8 from mikael at gcc dot gnu dot org 2008-11-20 13:43 > --- > Created an attachment (id=16727) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16727&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16727&action=view) > much more manageable testcase > > I think the testcase is invalid as both PBit4set and PBit8set contain a > getNullSet function and are included together in module bug6 without > renaming. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug c/38243] New: Restrict constraint violation not an error with -pedantic-errors
The following violates constraint C99 6.7.3p2 yet is only a warning with -pedantic-errors: restrict struct s; -- Summary: Restrict constraint violation not an error with - pedantic-errors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38243
[Bug libstdc++/38244] New: bitset initialization from 0 rejected.
g++ compiled as of yesterday afternoon:
Using built-in specs.
Target: i686-linux
Configured with: ../trunk/configure --enable-languages=c,c++ --build=i686-linux
--host=i686-linux --target=i686-linux
--prefix=/g/users/cgd/proj/gcc-trunk/bld/../inst
Thread model: posix
gcc version 4.4.0 20081123 (experimental) (GCC)
rejects the AFAICT-valid code:
#include
class C0 {
public:
C0() : b(0) { } // FAILS.
private:
std::bitset<1> b;
};
class C1 {
public:
C1() : b(1) { } // OK!
private:
std::bitset<1> b;
};
void func() {
C0 val0;
C1 val1;
}
(in particular, the 'C0' initialization) with the error:
test.cc: In constructor 'C0::C0()':
test.cc:5: error: call of overloaded 'bitset(int)' is ambiguous
/g/users/cgd/proj/gcc-trunk/inst/bin/../lib/gcc/i686-linux/4.4.0/../../../../include/c++/4.4.0/bitset:808:
note: candidates are: std::bitset<_Nb>::bitset(const char*, char, char) [with
unsigned int _Nb = 1u]
/g/users/cgd/proj/gcc-trunk/inst/bin/../lib/gcc/i686-linux/4.4.0/../../../../include/c++/4.4.0/bitset:744:
note: std::bitset<_Nb>::bitset(long unsigned int) [with
unsigned int _Nb = 1u]
/g/users/cgd/proj/gcc-trunk/inst/bin/../lib/gcc/i686-linux/4.4.0/../../../../include/c++/4.4.0/bitset:652:
note: std::bitset<1u>::bitset(const std::bitset<1u>&)
I'm not completely sure what's going on here, but I'm thinking it's related to
the fact that the 'char*' ctor actually has two default arguments, and 0 is
convertible to a pointer.
This code is accepted by GCC 4.3.2 and the Comeau test drive.
--
Summary: bitset initialization from 0 rejected.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cgd at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug libstdc++/38244] bitset initialization from 0 rejected.
--- Comment #1 from cgd at google dot com 2008-11-24 03:54 --- Created an attachment (id=16754) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16754&action=view) preprocessed source from test case in bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug c/38245] New: apparent improper segfault in compiler output
This is seen using r142142 on Ubuntu Hardy on x86.
I don't think anything in the source code justifies the segfault.
[EMAIL PROTECTED]:~/volatile/tmp66$ current-gcc -O2 small.c -o small
[EMAIL PROTECTED]:~/volatile/tmp66$ ./small
Segmentation fault
[EMAIL PROTECTED]:~/volatile/tmp66$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr : (reconfigured) ../configure
--program-prefix=current- --enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20081123 (experimental) (GCC)
[EMAIL PROTECTED]:~/volatile/tmp66$ cat small.c
#include
#include
static inline int8_t
safe_sub_int8_t_s_s (int8_t si1, int8_t si2)
{
if (((si1^si2)
& (((si1 ^ ((si1^si2)
& (1 <<
(sizeof(int8_t)*CHAR_BIT-1-si2)^si2)) < 0) {
return si1;
}
return si1 - si2;
}
static inline int32_t
safe_div_int32_t_s_s (int32_t si1, int32_t si2)
{
if ((si2 == 0) || ((si1 == INT_MIN) && (si2 == -1))) {
return si1;
}
return si1 / si2;
}
static inline uint64_t
safe_mod_uint64_t_u_u (uint64_t ui1, uint64_t ui2)
{
if (ui2 == 0) return ui1;
return ui1 % ui2;
}
uint8_t g_2;
volatile uint32_t g_9;
int32_t func_3 (void);
int32_t func_3 (void)
{
return g_2;
}
void func_1 (void);
void func_1 (void)
{
uint32_t l_10 = 0x084BL;
if (safe_sub_int8_t_s_s
((safe_div_int32_t_s_s
(0, (safe_mod_uint64_t_u_u (func_3 (), l_10, 1))
{
}
else if (g_9)
{
}
}
int main (void)
{
func_1 ();
return 0;
}
--
Summary: apparent improper segfault in compiler output
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug middle-end/17982] stop calling assemble_external before final assembly output time
--- Comment #31 from hackbunny at reactos dot com 2008-11-24 04:32 --- Created an attachment (id=16755) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16755&action=view) testcase.c:10: warning: y renamed after being referenced in assembly Compile test case with -funit-at-a-time gcc -v: Using built-in specs. Target: mingw32 Configured with: ../gcc-4.1.3/configure --prefix=/gcc-4.1.3 --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --build=mingw32 --enable-languages=c,c++ --enable-checking=release --enable-threads=win32 --disable-win32-registry --disable-nls --disable-shared Thread model: win32 gcc version 4.1.3 20071015 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug middle-end/17982] stop calling assemble_external before final assembly output time
--- Comment #32 from hackbunny at reactos dot com 2008-11-24 04:32 --- I've been told that this is related to the test case I just attached -- hackbunny at reactos dot com changed: What|Removed |Added CC||hackbunny at reactos dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug c/38246] New: Restrict constraint violation not an error with -pedantic-errors
The following violates constraint C99 6.7.3p2 yet is only a warning with -pedantic-errors: restrict struct s; -- Summary: Restrict constraint violation not an error with - pedantic-errors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38246
[Bug fortran/37803] Call mpfr_check_range after setting emin/emax
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-24 04:37 --- I will see if we can get this cleaned up. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-24 04:37:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37803
[Bug fortran/32795] allocatable components are nullified prematurely
--- Comment #15 from pault at gcc dot gnu dot org 2008-11-24 06:35 --- Subject: Bug 32795 Author: pault Date: Mon Nov 24 06:34:16 2008 New Revision: 142148 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142148 Log: 2008-11-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34820 * trans-expr.c (gfc_conv_function_call): Remove all code to deallocate intent out derived types with allocatable components. (gfc_trans_assignment_1): An assignment from a scalar to an array of derived types with allocatable components, requires a deep copy to each array element and deallocation of the converted rhs expression afterwards. * trans-array.c : Minor whitespace. * trans-decl.c (init_intent_out_dt): Add code to deallocate allocatable components of derived types with intent out. (generate_local_decl): If these types are unused, set them referenced anyway but allow the uninitialized warning. PR fortran/34143 * trans-expr.c (gfc_trans_subcomponent_assign): If a conversion expression has a null data pointer argument, nullify the allocatable component. PR fortran/32795 * trans-expr.c (gfc_trans_subcomponent_assign): Only nullify the data pointer if the source is not a variable. 2008-11-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34820 * gfortran.dg/alloc_comp_constructor_6.f90 : New test. * gfortran.dg/alloc_comp_basics_1.f90 : Reduce expected refs to 'builtin_free' from 24 to 18. PR fortran/34143 * gfortran.dg/alloc_comp_constructor_5.f90 : New test. PR fortran/32795 * gfortran.dg/alloc_comp_constructor_4.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_4.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32795
[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8
--- Comment #14 from pault at gcc dot gnu dot org 2008-11-24 06:35 --- Subject: Bug 34143 Author: pault Date: Mon Nov 24 06:34:16 2008 New Revision: 142148 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142148 Log: 2008-11-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34820 * trans-expr.c (gfc_conv_function_call): Remove all code to deallocate intent out derived types with allocatable components. (gfc_trans_assignment_1): An assignment from a scalar to an array of derived types with allocatable components, requires a deep copy to each array element and deallocation of the converted rhs expression afterwards. * trans-array.c : Minor whitespace. * trans-decl.c (init_intent_out_dt): Add code to deallocate allocatable components of derived types with intent out. (generate_local_decl): If these types are unused, set them referenced anyway but allow the uninitialized warning. PR fortran/34143 * trans-expr.c (gfc_trans_subcomponent_assign): If a conversion expression has a null data pointer argument, nullify the allocatable component. PR fortran/32795 * trans-expr.c (gfc_trans_subcomponent_assign): Only nullify the data pointer if the source is not a variable. 2008-11-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34820 * gfortran.dg/alloc_comp_constructor_6.f90 : New test. * gfortran.dg/alloc_comp_basics_1.f90 : Reduce expected refs to 'builtin_free' from 24 to 18. PR fortran/34143 * gfortran.dg/alloc_comp_constructor_5.f90 : New test. PR fortran/32795 * gfortran.dg/alloc_comp_constructor_4.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_4.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
[Bug fortran/34820] internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
--- Comment #9 from pault at gcc dot gnu dot org 2008-11-24 06:35 --- Subject: Bug 34820 Author: pault Date: Mon Nov 24 06:34:16 2008 New Revision: 142148 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142148 Log: 2008-11-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34820 * trans-expr.c (gfc_conv_function_call): Remove all code to deallocate intent out derived types with allocatable components. (gfc_trans_assignment_1): An assignment from a scalar to an array of derived types with allocatable components, requires a deep copy to each array element and deallocation of the converted rhs expression afterwards. * trans-array.c : Minor whitespace. * trans-decl.c (init_intent_out_dt): Add code to deallocate allocatable components of derived types with intent out. (generate_local_decl): If these types are unused, set them referenced anyway but allow the uninitialized warning. PR fortran/34143 * trans-expr.c (gfc_trans_subcomponent_assign): If a conversion expression has a null data pointer argument, nullify the allocatable component. PR fortran/32795 * trans-expr.c (gfc_trans_subcomponent_assign): Only nullify the data pointer if the source is not a variable. 2008-11-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34820 * gfortran.dg/alloc_comp_constructor_6.f90 : New test. * gfortran.dg/alloc_comp_basics_1.f90 : Reduce expected refs to 'builtin_free' from 24 to 18. PR fortran/34143 * gfortran.dg/alloc_comp_constructor_5.f90 : New test. PR fortran/32795 * gfortran.dg/alloc_comp_constructor_4.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_4.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
[Bug middle-end/17982] stop calling assemble_external before final assembly output time
--- Comment #33 from dannysmith at users dot sourceforge dot net 2008-11-24 06:41 --- (In reply to comment #32) > I've been told that this is related to the test case I just attached Your testcase is more closely related to PR 38054. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
