[Bug fortran/31139] sum(w_re(1:nn,1)*fi(i(1:nn, ii))) up to 3.5x slower than C version
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-12 08:16 ---
> Can someone try instead of doing "__real__ a += w[j] *__real__ mfi[*index];"
> Use "a+= xxx* yyy" and also use -std=c99 to get the correct multiplication?
Well, -std=c99 was used already and the "real(!) * complex" calculation was
already correct. "c_cmplx" below uses now:
a += w[j] * mfi[*index++];
Compiled with:
gcc -std=c99 -O3 -funroll-loops -ftree-vectorize -march=opteron -msse3
-ffast-math -m64
gfortran -O3 -funroll-loops -ftree-vectorize -march=opteron -msse3 -ffast-math
-m64
Fortran: 0.4360271
Fortran: 0.4280267
c_nosse: 0.2440166
c_nosse: 0.2320151
c_sse: 0.2320137
c_sse: 0.2400150
c_struct: 0.2320151
c_struct: 0.2320147
c_cmplx: 0.2360163
c_cmplx: 0.2320147
And using a non-manually unrolled version: 0.3760242, 0.3760242
for(i = 0; i < np ; i++) {
for(j = 1; j < n; j++)
a += w[j] * mfi[*index++];
fo[i] = a;
}
Thus the unrolling seems to do most of the speed up. With -funroll-all-loops,
the timings of fortran an the non-unrolled version remain the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-12 08:50 --- Created an attachment (id=13193) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13193&action=view) Patch draft (by Paul Thomas) Notes by Paul: (i) gfc_find_symbol searches via proc_name->ns to overcome standard problem with interfaces in enclosed procedures. (ii) Add field imported to gfc_symtree (iii) Set it when a symbol is imported (iv)resolve.c 5658 to use imported to stop false error for individually imported symbols. Note, it does not fix the problem of comment 1 (which was found later). It causes some regressions (filelist below) with such errors: gfortran.fortran-torture/execute/der_io.f90:55.20: subroutine foo(t) 1 gfortran.fortran-torture/execute/der_io.f90:5.15: type xyz_type 2 Error: The type xyz_type cannot be host associated at (1) because it is blocked by an incompatible object of the same name at (2) Files: gfortran.dg/automatic_default_init_1.f90 gfortran.dg/char_result_11.f90 gfortran.dg/char_result_5.f90 gfortran.dg/char_result_6.f90 gfortran.dg/default_initialization_2.f90 gfortran.dg/dependency_19.f90 gfortran.dg/der_charlen_1.f90 gfortran.dg/der_io_2.f90 gfortran.dg/der_io_3.f90 gfortran.dg/der_pointer_3.f90 [...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug objc++/31134] [4.3 Regression] Objective-C++ has ran into the tree number limit
--- Comment #8 from pcarlini at suse dot de 2007-03-12 09:07 --- (In reply to comment #7) > Also adding new features should not break old features Here we are not talking about trade-offs, that should be rather clear by now. We are talking about fixing for real the underlying very serious issue with the tree code limit which otherwise blocks development in many new areas. Temporarily, Doug can well revert his patch but the limit **must** be removed anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134
[Bug c++/20599] variadic template support
--- Comment #15 from pcarlini at suse dot de 2007-03-12 09:26 --- Actually in the latest mailing there are two new papers, N2151 and N2152. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #10 from Andreas dot Kowarz at tu-dresden dot de 2007-03-12 09:30 --- THS (The Holy Standard :-) ) 3.7.4.2/3 reads to me that for standard library implementations the delete operators must be called in any case but return immediately if the first argument is NULL => NULL-check inside the operator. Taking the context into account, it reads to me as if standard library delete calls can be treated as special cases. In the more general case, i.e., the user supplied delete operators, no special assumptions can be done. Again, the operators must be called in any case but it is up to the user to handle special cases correctly. Whatever the latter may look like. Andreas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #7 from Woebbeking at web dot de 2007-03-12 09:37 --- Any news on this? It's really annoying if you've many pimpls which often use anonymous namespace. -- Woebbeking at web dot de changed: What|Removed |Added CC||Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/31145] New: ICE: in cse_find_path, at cse.c:5930 with -O3 -ftracer
I'm using SVN revision 122834.
> cat bug.cc
int buf[2];
int f(int x) {
return (x & 1) ? buf[0] : buf[1];
}
void g() {
for (int x = 0; x < 100 && f(x); ++x);
}
> g++ -O3 -ftracer bug.ccbug.cc: In function 'void g()':
bug.cc:7: internal compiler error: in cse_find_path, at cse.c:5930
> g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../configure -v --enable-languages=c,c++
--prefix=/home/wouter/gcc/local --enable-shared --with-system-zlib --enable-nls
--enable-threads=posix --without-included-gettext --disable-werror
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug i486-linux-gnu --enable-libmudflap
--enable-checking=release
Thread model: posix
gcc version 4.3.0 20070312 (experimental)
--
Summary: ICE: in cse_find_path, at cse.c:5930with -O3 -
ftracer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at pi dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31145
[Bug c++/28774] Request for warning where const/volatile is ignored in a cast
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-12 12:10 --- This seems a duplicate of PR 14710. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug tree-optimization/31146] New: forwprop does not look through casts
The following two testcases should produce the same code after forwprop1:
struct foo { int i[3]; };
void bar (void)
{
struct foo Foo;
int i;
for (i=0; i<3; ++i)
{
void *p = &Foo.i[i];
int *pi = (int *)p;
if (pi != 0)
{
*pi = 0;
}
}
}
---
struct foo { int i[3]; };
void bar (void)
{
struct foo Foo;
int i;
for (i=0; i<3; ++i)
{
void *p = &Foo.i[i];
int *pi = (int *)p;
if (p != 0)
{
*pi = 0;
}
}
}
(the difference is testing p != 0 vs. pi != 0)
This happens in tramp3d-v4 via placement new:
for (i=0; i<3; ++i)
new (&a[i]) double;
where placement new expands to the "wrong" test sequence.
Mine.
--
Summary: forwprop does not look through casts
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: rguenth at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug c++/31147] New: increased size of debug information
Hi, compared to 4.1.2 the size increased by 50% and more. E.g. Qt 4.2.2 libQtGui.so.4.2.2.debug - 4.2.0 97902763 bytes - 4.1.2 62435403 bytes We compile with -O2 -g. Is this a regression or just more (useful?) information? -- Summary: increased size of debug information Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)
--- Comment #30 from amacleod at redhat dot com 2007-03-12 13:11 --- Err, yeah. thats right. TER doesn't run without optimization, and I forgot this was more than just an optimization issue. Where is that work to do basic SSA optimizations at -O0 when you need it?? :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #10 from amacleod at redhat dot com 2007-03-12 13:33 --- They do all have the (ab) next to them, I was just indicating that they all occurred in a PHI together, and hence needed to be coalesced. I should have been more precise. Well, _t_3 definately does have the (ab) flag, and I don't know what all it does do, but it does introduce the situation where we have overlapping abnormal ssa-names which have to be coalesced. I see it does a bunch of replacements which include _t_3(ab), lines such as: Replaced (struct *) #ref#17#7_8338 with _t_3(ab) in #ref#17#7.2741_8343 = (struct *) #ref#17#7_8338; (Just an example, not meant to be the erroneous replacement). So it is clearly doing something with it. -- amacleod at redhat dot com changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug c++/31147] increased size of debug information
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-12 14:03 --- It's more information - whether it's useful depends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
[Bug c++/31147] increased size of debug information
--- Comment #2 from Woebbeking at web dot de 2007-03-12 14:22 --- Subject: Re: increased size of debug information On Monday 12 March 2007, rguenth at gcc dot gnu dot org wrote: > It's more information - whether it's useful depends. Wow, more than 50%. Are there any docs to this change? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype
--- Comment #5 from ingo dot donasch at L-3com dot com 2007-03-12 14:32
---
Subject: RE: ptr to member func __delta is 0 if ptr declar
ation does not match function porototype
I know our code is wrong, but my point is that gcc34 generated correct code
and gcc4x is not. A Gcc4x workaround that was mentioned to me is to double
cast.
The gcc4x compiler is NOT generating the offset to point into the correct
subclass, it should either be compatible w/ gcc34 or better signal an error!
I disagree with marking this bug report as "resolved invalid" but would
accept a deferral because 2 workarounds exists and the code was bad anyways.
Still I'm expecting the compiler to reject bad code if it can't generate
code for it!
ingo
Ps. (we ran into that problem because someone added a parameter to the
callback year ago w/o updating all the receiving function declarations #8-(
ingo
> -Original Message-
> From: bangerth at dealii dot org [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 08, 2007 23:41
> To: Donasch, Ingo
> Subject: [Bug c++/30975] ptr to member func __delta is 0 if
> ptr declaration does not match function porototype
>
>
>
>
> --- Comment #4 from bangerth at dealii dot org
> 2007-03-09 04:40 --- What exactly are you trying to achieve here:
> -
> typedef void (B::*FPTR)(int);
>
> ...
>
> struct C : public A , public B {
> virtual void C_bad() { }
> };
>
>
> c.t((FPTR)&C::C_bad);
> --
> Clearly, C::Cbad is a void function, but you assign it to a
> pointer to a function that takes an int. That can't possibly
> work. Indeed, if you let C_bad take an int, the segfault goes away.
>
> W.
>
>
> --
>
> bangerth at dealii dot org changed:
>
>What|Removed |Added
> --
> --
> CC||bangerth at
> dealii dot org
> Status|UNCONFIRMED |RESOLVED
> Resolution||INVALID
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #4 from patchapp at dberlin dot org 2007-03-12 14:50 --- Subject: Bug number PR30922 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00728.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug c++/31147] increased size of debug information
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-12 14:51 --- Figure out which source causes the increase and then attach the preprocessed source and then we might be able to decide. It could be that in 4.1.2, that we were not emitting enums and some other types which should have been emitting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
[Bug c++/31145] ICE: in cse_find_path, at cse.c:5930 with -O3 -ftracer
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-12 14:56 --- *** This bug has been marked as a duplicate of 31127 *** -- 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=31145
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-12 14:56 --- *** Bug 31145 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||wouter dot vermaelen at pi ||dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug tree-optimization/31146] forwprop does not look through casts
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-12 14:59 --- forwprop should NOT, I repeat should NOT look through casts for conditional if the SSA_NAME that defines the cast is still used after the conditional. Really this non zero optimization should be done by VRP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug tree-optimization/31146] forwprop does not look through casts
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-12 15:09 ---
I should mention, unless it can produce a constant result.
For an example this function:
void bar (void * a)
{
struct foo Foo;
int i;
for (i=0; i<3; ++i)
{
void *p = a;
int *pi = (int *)p;
if (pi != 0)
{
*pi = 0;
}
}
}
Should not be transformed into:
void bar (void * a)
{
struct foo Foo;
int i;
for (i=0; i<3; ++i)
{
void *p = a;
int *pi = (int *)p;
if (p != 0)
{
*pi = 0;
}
}
}
As VRP is not as smart as there is no back tracking of ranges.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-12 15:24 --- The testcase in comment 1 should be lifted and deposited in another PR; it is going to be quite difficult to fix because the type and kind of an interface function is established before the specification statements that inlude the IMPORT statement. This problem is related to that of implicit type definition within interfaces that I just fixed (PR30883). Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-02 16:14:27 |2007-03-12 15:24:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30870] GENERIC non-INTRINSIC procedure rejected as actual argument
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-12 15:25 --- I just submitted a patch for this PR. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30870
[Bug tree-optimization/31146] forwprop does not look through casts
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-12 15:35 ---
The problem is that for example FRE value numbers
void *p_4 = &a[0];
int *q_1 = (int *)p_4;
p_4 with void* type (even if &a[0] is of int* type) and so re-generates the
conversion to int* even though it is about to replace (int *)p_4 with p_4
(as tree_ssa_useless_type_conversion_1 is false for converting void* to int*).
At the same time tree-combining the conversion (int *)&a[0] leads to
&a[0] for which we have a value already, the void* p_4 :/
Maybe the new VN will fix this testcase as well. With the series of forwprop
patches in my queue (which you obviously don't like at all, but I blame you
for that) we get for
(void) (TARGET_EXPR ;,
D.2605 != 0B ? try
{
*D.2605 = 0.0;
}
catch
{
operator delete ((void *) D.2605, (void *) &a[i]);
}, D.2605 : D.2605;)
instead of
__p_5 = &a[i_3];
iftmp.3_6 = (double *) __p_5;
if (iftmp.3_6 != 0B) goto ; else goto ;
:;
*iftmp.3_6 = 0.0;
:;
just
a[i_3] = 0.0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug fortran/30879] Syntax error for derived type's compounds in a data-stmt-value-set
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-12 15:40 --- I just submitted a patch for this PR. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-02-20 17:00:22 |2007-03-12 15:40:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30879
[Bug fortran/31148] New: optional argument of elemental function
Since ivec is not passed to sub, I think the two calls to set_optional should be equivalent, but gfortran crashes upon the second call. u:\vrao\fortran type xopt_bug.f90 module sub_mod contains elemental subroutine set_optional(i,idef,iopt) ! set i to (iopt,idef) if iopt (is,is not) PRESENT integer, intent(out) :: i integer, intent(in) :: idef integer, intent(in), optional :: iopt if (present(iopt)) then i = iopt else i = idef end if end subroutine set_optional ! subroutine sub(ivec) integer , intent(in), optional :: ivec(:) integer :: ivec_(2) call set_optional(ivec_,(/1,2/)) print*,"ivec_=",ivec_ call set_optional(ivec_,(/1,2/),ivec) print*,"ivec_=",ivec_ end subroutine sub end module sub_mod program main use sub_mod, only: sub call sub() end program main U:\vrao\fortran>gfortran -v Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20061021 (experimental) U:\vrao\fortran>gfortran -W -Wall -pedantic-errors -std=f2003 -fbounds-check -Werror xopt_bug.f90 U:\vrao\fortran>a.exe Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of array 'ivec' (in file 'xopt_bug.f90', at line 20) ivec_= 1 2 -- Summary: optional argument of elemental function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31148
[Bug tree-optimization/31146] forwprop does not look through casts
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-12 15:41 --- I think really this comes down to our type system, I remember posting a patch for the LTO branch which adds back the explict cast to "void*", I can test that, it should fix this testcase also :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug tree-optimization/31146] forwprop does not look through casts
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-12 16:01 --- Well sure - if we then would get int *p_1 = &a[0]; void *q_1 = (void *)p_1; int *r_1 = (int *)q_1; if (r_1 != NULL) ... then FRE would figure out that r_1 == p_1 and the forwprop pass after FRE will fold the comparison. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug fortran/31149] New: gfortran: no diagnostics about too many arguments in legacy code (vs. g77)
Consider this code: SUBROUTINE FOO(I) I=0 END SUBROUTINE BAR() CALL FOO(1,2) END compiled with g77 3.4.6: f77.f: In subroutine `bar': f77.f:1: SUBROUTINE FOO(I) 1 f77.f:6: (continued): CALL FOO(1,2) 2 Too many arguments passed to `foo' at (2) versus definition at (1) [info -f g77 M GLOBALS] no object file is generated. gfortran, even with -Wall, emits are no warnings or errors at all and an object file is generated. With a module or interface block gfortran does a lot better but then it is no longer Fortran 77 of course. -- Summary: gfortran: no diagnostics about too many arguments in legacy code (vs. g77) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bartoldeman at users dot sourceforge dot net GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31149
[Bug c++/30108] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-03-12 16:24 --- Subject: Bug 30108 Author: mmitchel Date: Mon Mar 12 16:24:18 2007 New Revision: 122844 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122844 Log: PR c++/30108 * call.c (convert_default_arg): Copy non-constant arguments. PR c++/30108 * g++.dg/other/default6.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/default6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c++/31147] increased size of debug information
--- Comment #4 from Woebbeking at web dot de 2007-03-12 16:46 --- Created an attachment (id=13194) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13194&action=view) preprocessed qcombobox.cpp I added both versions (4.2.0 and 4.1.2). It's compiled with -c -fno-exceptions -pipe -O2 -g -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
[Bug middle-end/31150] New: [4.1/4.2/4.3 Regression] Not promoting an whole array to be static const
Take:
int main()
{
char str[2][34] = {"a","b"};
__builtin_puts(str[0]);
return 0;
}
In 4.0.2, we used to get:
static char C.0[2][34] = {"a", "b"};
char str[2][34];
str = C.0;
__builtin_puts (&str[0][0]);
But in 4.1.1 and above, we get:
char str[2][34];
str = {};
str[0] = "a";
str[1] = "b";
Which causes us to first zero out the array and then do load/stores on the
stack.
--
Summary: [4.1/4.2/4.3 Regression] Not promoting an whole array to
be static const
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
[Bug middle-end/31150] [4.1/4.2/4.3 Regression] Not promoting an whole array to be static const
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
[Bug c++/20478] poor diagnostic
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-12 16:47 --- It would be helpful if you could reduce the testcase. Thanks. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20478
[Bug bootstrap/31151] New: During 'make bootstrap': Syntax error at line 1 : `>' is not expected
Am receiving following error during 'make bootstrap' for GCC v4.1.2 on AIX 5.3: srcdir="/usr/local/gcc-4.1.2/fixincludes" /bin/sh /usr/local/gcc-4.1.2/f ixincludes/mkfixinc.sh powerpc-ibm-aix5.3.0.0 sed -e 's/@gcc_version@//' < > mkheadersT /bin/sh: 0403-057 Syntax error at line 1 : `>' is not expected. make: 1254-004 The error code from the last command is 2. This occurs after running for quite some time. Just don't know enough about this stuff to figure out the possible cause. -- Summary: During 'make bootstrap': Syntax error at line 1 : `>' is not expected Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkurpa at co dot volusia dot fl dot us http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31151
[Bug bootstrap/31151] During 'make bootstrap': Syntax error at line 1 : `>' is not expected
--- Comment #1 from jkurpa at co dot volusia dot fl dot us 2007-03-12 16:51 --- Created an attachment (id=13195) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13195&action=view) Screen output from 'make bootstrap' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31151
[Bug bootstrap/31151] During 'make bootstrap': Syntax error at line 1 : `>' is not expected
--- Comment #2 from jkurpa at co dot volusia dot fl dot us 2007-03-12 16:52 --- Created an attachment (id=13196) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13196&action=view) Screen output from configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31151
[Bug tree-optimization/31130] [4.3 Regression] VRP no longer derives range for division after negation
--- Comment #4 from ian at airs dot com 2007-03-12 17:08 ---
First test case:
int f(int a)
{
if (a < 0)
a = -a;
return a < 0;
}
As far as I can tell the behaviour of this test case in VRP is unchanged by the
patch in this PR. And the code is still fully optimized.
Second test case:
int f(int a)
{
if (a < 0)
a = -a;
if (a < 0)
a = -a;
return a < 0;
}
In my tests the second conditional is removed during the VRP pass with or
without the patch in this PR. It is cleaned up by jump threading.
Third test case:
extern void link_error ();
void foo (int a)
{
if (a < 0)
{
int y;
a *=-2;
y = a / 7;
if (y > 1 << 30)
link_error ();
}
}
int main()
{
return 0;
}
I agree that VRP does not sort this out, although the final generated code is
fine. I personally think the overflow infinity code does the right thing here.
Fourth test case:
extern void link_error ();
void foo (int a)
{
if (a < 0)
{
int y;
y = -a / 7;
if (y > 1 << 30)
link_error ();
}
}
This does give a warning with -Wstrict-overflow=4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
[Bug tree-optimization/31130] [4.3 Regression] VRP no longer derives range for division after negation
--- Comment #5 from ian at airs dot com 2007-03-12 17:21 ---
Unfortunately my patch in comment #1 doesn't handle this test case correctly:
extern void abort (void);
void
foo (int a)
{
if (a <= (int) 0x8001)
{
a = - a;
if (a > 0)
abort ();
}
}
It turns it into if (a > 0x8001) abort(); with no warning. The
transformation is OK with -fstrict-overflow, but we should get a warning with
-Wstrict-overflow, because it assumes that -INT_MIN > 0 is true.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
[Bug c/11051] -Wno-deprecated needed also for C
--- Comment #14 from manu at gcc dot gnu dot org 2007-03-12 17:22 --- Tom, your patch http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01853.html will also fix this by adding Wdeprecated to the C front-end. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug target/26090] IA-64 creates DT_TEXTREL binaries
--- Comment #6 from rth at gcc dot gnu dot org 2007-03-12 17:15 --- Subject: Bug 26090 Author: rth Date: Mon Mar 12 17:15:44 2007 New Revision: 122847 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122847 Log: PR target/26090 * config/alpha/alpha.c (alpha_elf_select_section): New. (alpha_elf_unique_section, alpha_elf_section_type_flags): New. (alpha_elf_select_rtx_section): Force flag_pic true. (TARGET_ASM_SELECT_SECTION, TARGET_ASM_UNIQUE_SECTION): New. (TARGET_SECTION_TYPE_FLAGS): New. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/alpha/alpha.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26090
[Bug preprocessor/23479] Implement binary constants with a "0b" prefix
--- Comment #19 from manu at gcc dot gnu dot org 2007-03-12 17:31 --- (In reply to comment #18) > Created an attachment (id=13025) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13025&action=view) [edit] > Updated patch, output from "svn diff" as of 2007-02-07 > Joerg, as Andrew said, you need a copyright assignment and you need to submit the patch to [EMAIL PROTECTED] You can find more info at http://gcc.gnu.org/contribute.html Thanks. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug tree-optimization/31152] New: -(x>y) generates wrong code
The actual gcc version is gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) When compiled and run with this gcc version, using the command line gcc -O xxx.c && a.out the attached program outputs -1, whereas the correct output is 0. If I use gcc 3.3.6 or leave away the -O flag, the program produces correct output. -- Summary: -(x>y) generates wrong code Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anton at mips dot complang dot tuwien dot ac dot at GCC host triplet: arm-linux-gnu GCC target triplet: arm-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug c++/23263] Incomprehensible message for invalid attempt to partially specialize a member
--- Comment #5 from manu at gcc dot gnu dot org 2007-03-12 17:39 --- (In reply to comment #4) > See also PR 23281 [snip] > Consequently I'm filing this as a DR against the gcc DR reporting machinery > itself, rather than against the compiler in particular. There needs to be > categories for QOI defects of varying severity; either that, or complaints > about > diagnostics and other QOI ussues should not by policy be filed as "enhancement > requests", and forgotten. It doesn't matter whether this is filled this way or that way. The problem is that there are more tan 2 thousand bugs opened. Logically, most developers tend to focus on fixing regressions, ICEs or optimisations rather on precise wording of correct diagnostics. We need more contributors in this area, you are welcome to participate! -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23263
[Bug tree-optimization/31152] -(x>y) generates wrong code
--- Comment #1 from anton at mips dot complang dot tuwien dot ac dot at
2007-03-12 17:43 ---
Subject: Re: New: -(x>y) generates wrong code
I cannot create an attachment in Bugzilla, so I'll just append the
test program here:
#include
#include
long foo(long x, long y);
int main()
{
printf("%d\n",foo(INT_MIN,INT_MAX));
return 0;
}
long foo(long x, long y)
{
return -(x>y);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug other/28002] decNumber sources need GPL+exception for use in libgcc
--- Comment #6 from janis at gcc dot gnu dot org 2007-03-12 17:45 --- The link in comment #5 is to David Edelsohn's message that RMS had approved the license change. Ben Elliston changed the license in the decNumber files for mainline and the 4.2 branch. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
[Bug c/24016] Missing warning for unspecified evaluation order
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-12 17:48 --- (In reply to comment #1) > > It is, however, at least unspecified order of evaluation and a warning > here would still make sense. > A candidate for -Wsequence-points ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24016
[Bug c++/30108] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #11 from mmitchel at gcc dot gnu dot org 2007-03-12 18:07 --- Subject: Bug 30108 Author: mmitchel Date: Mon Mar 12 18:07:33 2007 New Revision: 122848 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122848 Log: PR c++/30108 * call.c (convert_default_arg): Copy non-constant arguments. PR c++/30108 * g++.dg/other/default6.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/other/default6.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c++/30108] [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-12 18:09 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1 Regression] |internal compiler error: in |internal compiler error: in |make_decl_rtl, at |make_decl_rtl, at |varasm.c:890|varasm.c:890 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #4 from craig dot lawson at centrify dot com 2007-03-12 18:26 --- Perhaps there are different degrees of thread safety here. If I write my multi-threaded program such that only one thread does stream I/O with libstdc++, I would expect it to operate safely with respect to the locale issue. But it will not: any other thread which modifies errno (via set_errno) is potential trouble for my stream I/O thread. On the other hand, if __convert_to_v was compiled to use the errno address function, my program would be correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #22 from mmitchel at gcc dot gnu dot org 2007-03-12 18:27 --- Danny, please apply the patch to 4.2.0. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug target/28701] [4.1/4.2/4.3 regression] ABI test failures building libstdc++ on a glibc-2.4 based system
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-12 18:31 --- It appears from the audit trail that there is no GCC bug here, other than, perhaps, the configuration options not defaulting to ideal choices. If that's a problem, file a new PR; however, AFAICT, we do not have a P1 ABI failure here. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
[Bug c/31153] New: -Wconversion does not catch return value mismatch
In functions declared to return unsigned int, -Wconversion correctly warns when a constant signed int is returned. But -Wconversion fails to warn when the return value is an identifier with type signed int. Seen in gcc 3.2.3 (Red Hat) and 4.0.1 (Mac OS X) -- Summary: -Wconversion does not catch return value mismatch Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: craig dot lawson at centrify dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31153
[Bug middle-end/30433] [4.1 Regression] no longer folding __complex__(0.0, 1.0) == __complex__(1.0, 0.0)
--- Comment #6 from sayle at gcc dot gnu dot org 2007-03-12 18:41 --- Subject: Bug 30433 Author: sayle Date: Mon Mar 12 18:40:56 2007 New Revision: 122852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122852 Log: 2007-03-12 Roger Sayle <[EMAIL PROTECTED]> Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/30433 * fold-const.c (fold_relational_const): Add back compile-time evaluation of complex constant equality/inequality comparisons. * gcc.c-torture/compile/pr30433.c: New testcase to check that complex constant comparisions are folded. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr30433.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30433
[Bug middle-end/30433] [4.1 Regression] no longer folding __complex__(0.0, 1.0) == __complex__(1.0, 0.0)
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-12 18:45 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30433
[Bug middle-end/30761] [4.1/4.2/4.3 regression] Error: unsupported relocation against sfp
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-03-12 18:45 --- Ulrich -- Did your patch fix this PR on mainline? Is a backport to 4.1/4.2 possible? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #5 from pcarlini at suse dot de 2007-03-12 18:51 --- (In reply to comment #4) > Perhaps there are different degrees of thread safety here. > > If I write my multi-threaded program such that only one thread does stream I/O > with libstdc++, I would expect it to operate safely with respect to the locale > issue. But it will not: any other thread which modifies errno (via set_errno) > is potential trouble for my stream I/O thread. That's not correct. Anyone, anywhere, irrespective of I/O can do a "setlocale" and that will change the global locale, which is also changed in a thread-unsafe way at any I/O. Anyway, what happens in the GNU systems is that errno is a per-thread variable and the __convert_to_v code has to do nothing special, just safely use it. In the systems using the generic locale model a completely different strategy is needed if the C library of those systems doesn't provide a thread-safe implementation. I have no idea what that can be and in any case must be solved together with the setlocale one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug c/31153] -Wconversion does not catch return value mismatch
--- Comment #1 from craig dot lawson at centrify dot com 2007-03-12 18:53
---
Test program (Create a New Attachment is not working for me today):
const int i = -1;
unsigned int slip_one_by()
{
return i;
}
unsigned int caught_me()
{
return -1;
}
$ gcc -c unsigned_return.c -Wconversion
unsigned_return.c: In function `caught_me':
unsigned_return.c:10: warning: negative integer implicitly converted to
unsigned type
Expected a warning for line 5, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31153
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #10 from pault at gcc dot gnu dot org 2007-03-12 19:04 --- (In reply to comment #9) > > As a workaround, one could always use "minloc(...,dim=1)", then > we get the inline version. > Thomas, it's a bit kludgy, but why not add a constant expression = 1, if dim is not present? Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/31149] gfortran: no diagnostics about too many arguments in legacy code (vs. g77)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-12 19:09 --- This is do to the fact that gfortran does no same-file checking; this checking is outside the Fortran standard but still useful. It is planed for this year; cf. PR 26227 and references therein. *** This bug has been marked as a duplicate of 26227 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31149
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-12 19:09 --- *** Bug 31149 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||bartoldeman at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-03-12 19:09 --- Subject: Bug 28544 Author: dberlin Date: Mon Mar 12 19:09:05 2007 New Revision: 122857 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122857 Log: 2007-03-12 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/28544 * tree-ssa-operands.c (add_virtual_operand): Move assert triggering on aliasing violations into debugging define Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #24 from dberlin at gcc dot gnu dot org 2007-03-12 19:12 --- Fixed -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug fortran/31154] New: IMPORT fails for " FUNCTION (...)" kind of procedures
+++ This bug was initially created as a clone of Bug #30922 +++ gfortran currently does not like the following: module x implicit none integer, parameter :: d=8 interface real(d) function y() import end function end interface end module x real(d) function y() 1 Error: Parameter 'd' at (1) has not been declared or is a variable, which does not reduce to a constant expression (A real-world example for the latter is: http://users.erols.com/dnagle/pub/pthread.f03, which also needs ISO_C_BINDING support.) -- Summary: IMPORT fails for " FUNCTION (...)" kind of procedures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 30922 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31154
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #6 from craig dot lawson at centrify dot com 2007-03-12 19:23 --- > Anyway, what happens in the GNU systems is that errno is a per-thread variable > and the __convert_to_v code has to do nothing special, just safely use it. I agree. The problem is that this is not happening. __convert_to_v is not safely using the per-thread errno. Instead, it is using the global errno. The cause is not the __convert_to_v code but something in an include file or a gcc option which causes the code to be compiled incorrectly. Yet another file in the same library compiled with the same gcc options does access the thread-safe errno correctly. That a discrepancy exists indicates a problem somewhere. The intent of this bug is to call attention to this misuse of errno and the indication of an underlying problem. Thank you for explaining the issues with setlocale. Worse than I thought. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug middle-end/30761] [4.1/4.2 regression] Error: unsupported relocation against sfp
--- Comment #6 from uweigand at gcc dot gnu dot org 2007-03-12 19:34 --- I haven't verified that this problem is fixed -- the patch was originally intended to fix another bug uncovered by Peter Bergner, and I just added this PR number to the check-in due to Andrew's comment #3 on this bug. Andrew, have you verified that the problem is fixed now? I could backport the reload1.c change to 4.1/4.2 -- I haven't done so as there's always some risk associated with such backports, and it appeared from this bugzilla record that the bug was exposed only with a 4.3 change anyway. Was this impression mistaken? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug middle-end/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- Comment #2 from janis at gcc dot gnu dot org 2007-03-12 19:45 --- A regression hunt on powerpc-linux using the submitter's test case identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=96084 r96084 | law | 2005-03-08 03:39:19 + (Tue, 08 Mar 2005) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
[Bug c++/31155] New: priority_queue sorts wrong with std::less
#define protected public
#include
#include
typedef std::vector int_collection;
typedef std::priority_queue > int_queue;
void
print(int_queue & q)
{
for (int_collection::iterator iter(q.c.begin()); iter != q.c.end(); ++iter)
std::cout << *iter << " ";
std::cout << std::endl;
}
int
main()
{
int_queue q;
q.push(9); print(q);
q.push(8); print(q);
q.push(7); print(q);
q.push(6); print(q);
q.push(5); print(q);
q.push(4); print(q);
q.push(3); print(q);
q.push(2); print(q);
q.push(1); print(q);
}
// $ g++ --version -o priority_queue_test priority_queue_test.cpp;
./priority_queue_test
// g++ (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
// Copyright (C) 2006 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.
//
// 9
// 8 9
// 7 9 8
// 6 7 8 9
// 5 6 8 9 7
// 4 6 5 9 7 8
// 3 6 4 9 7 8 5
// 2 3 4 6 7 8 5 9
// 1 2 4 3 7 8 5 9 6
I have a cpp expanded version with configuration parameters, but I couldn't
figure out how to submit them from the web page.
--
Summary: priority_queue sorts wrong with std::less
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmecklenburg at s5w dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31155
[Bug c++/31155] priority_queue sorts wrong with std::less
--- Comment #1 from rmecklenburg at s5w dot com 2007-03-12 19:51 --- Created an attachment (id=13197) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13197&action=view) gcc -v -E version of the test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31155
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #7 from pcarlini at suse dot de 2007-03-12 19:51 --- (In reply to comment #6) > > Anyway, what happens in the GNU systems is that errno is a per-thread > > variable > > and the __convert_to_v code has to do nothing special, just safely use it. > > I agree. The problem is that this is not happening. __convert_to_v is not > safely using the per-thread errno. Instead, it is using the global errno. To be clear, *not* on Linux, right? Because in your report you said Linux and MacOSX were fine, and that is consistent with my expectations. Indeed, reading the glibc errno.h it is clear that errno is per-thread. > The cause is not the __convert_to_v code but something in an include file or a > gcc option which causes the code to be compiled incorrectly. Yet another file > in the same library compiled with the same gcc options does access the > thread-safe errno correctly. That a discrepancy exists indicates a problem > somewhere. I have no idea, frankly. Certainly all the sources are compiled with the same options. An idea I just had is that maybe we could try to avoid errno completely, at least in the generic locale model: we could simply check whether the functions return HUGE_VAL & co. That would mean we can't detect anymore underflows, but that errno is set on underflows is implementation dependent and, anyway, the C++ standard mandates that the behavior should be as-if the library used scanf, which has no notion of underflow. Maybe you can try the change yourself, and modify __convert_to_v (say the simple one, for double) to check, instead of errno != ERANGE, d != HUGE_VAL && d != -HUGE_VAL?? One final note: in the forthcoming C++0x standard things will be more tricky because the C++ library will be able to parse +INF & co, but we should be able to manage anyway, because we can first detect those and only otherwise, hands the string to strtod, which then will return HUGE_VAL / -HUGE_VAL only in case of real overflow (not input of +INF / -INF). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug preprocessor/23479] Implement binary constants with a "0b" prefix
--- Comment #20 from j at uriah dot heep dot sax dot de 2007-03-12 19:55 --- (In reply to comment #19) > Joerg, as Andrew said, you need a copyright assignment and you need to submit > the patch to [EMAIL PROTECTED] Patch submitted to list by 2007-02-09, message-id is <[EMAIL PROTECTED]> I've got a copyright assignment on file since 2003-03-19 (date of confirmation email from Jessica Natale). What else do you need? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug bootstrap/30635] --enable-stage1-langauges configure option is not documented.
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-12 20:03 --- Subject: Bug 30635 Author: brooks Date: Mon Mar 12 20:03:33 2007 New Revision: 122861 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122861 Log: PR 30635 * doc/install.texi: Document --enable-stage1-languages Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30635
[Bug c++/31155] priority_queue sorts wrong with std::greater
--- Comment #2 from pcarlini at suse dot de 2007-03-12 20:05 --- This is how priority_queue works: it makes an "heap" (in the exact computer science meaning), therefore, in particular, there is no guarantee that the contents are all fully sorted, only that the smallest is the first one (the largest with the default predicate). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31155
[Bug middle-end/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- Comment #3 from law at redhat dot com 2007-03-12 20:06 --- Subject: Re: [4.1/4.2/4.3 Regression] ICE with computed goto and constants On Mon, 2007-03-12 at 19:45 +, janis at gcc dot gnu dot org wrote: > > --- Comment #2 from janis at gcc dot gnu dot org 2007-03-12 19:45 --- > A regression hunt on powerpc-linux using the submitter's test case identified > this patch: > > http://gcc.gnu.org/viewcvs?view=rev&rev=96084 > > r96084 | law | 2005-03-08 03:39:19 + (Tue, 08 Mar 2005) Thanks for alerting me to this problem. I think the right fix is going to simply be to enforce a rule that we can only optimize a computed goto if the argument collapses down to a local LABEL_REF rather than a generic invariant. In the case where we have a constant or non-local LABEL_REF, the CFG (before optimizing) ought to be conservatively correct(*). Optimizing is impossible because we don't know which outgoing edge to keep and which ones to throw away. This ought to be a 1-2 line fix. Jeff (*) If the argument referred to a constant address in the current function which does not correspond to any known addressable LABEL_REF then we're hosed as the original unoptimized CFG is probably bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #8 from craig dot lawson at centrify dot com 2007-03-12 20:07 --- Not on Linux: correct. I could give it a try, but I haven't built this library before. If you could point me to a brief how-to, I could give it a try on a Solaris 10 SPARC. Rather than code around it, I would first review the preprocessor output from the two files which access errno. If the compiler options are the same, then problem is somewhere in a header file. And if that's the case, it would be useful to understand the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug bootstrap/30635] --enable-stage1-langauges configure option is not documented.
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-12 20:09 --- Fixed, as per the previous comment. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30635
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #9 from pcarlini at suse dot de 2007-03-12 20:14 --- (In reply to comment #8) > Not on Linux: correct. Ok. > I could give it a try, but I haven't built this library before. If you could > point me to a brief how-to, I could give it a try on a Solaris 10 SPARC. > > Rather than code around it, I would first review the preprocessor output from > the two files which access errno. If the compiler options are the same, then > problem is somewhere in a header file. And if that's the case, it would be > useful to understand the issue. Indeed, the issue is rather mysterious at the moment, because it's not at all clear why on the targets you are interested in apparently the thread-safe version is sometimes used, sometimes not. Anyway, I would suggest fetching the sources of a recent release, say 4.1.2 from our ftp servers and do a build of the full compiler, building the library alone is not easy: http://gcc.gnu.org/install/ In practice, you can probably use default for most of the configure switches, besides maybe the --prefix= to tell the build systems were you want the compiler installed (by default is /usr/local), and --languages for the languages you are interested in. Please let me know if you need more help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug preprocessor/23479] Implement binary constants with a "0b" prefix
--- Comment #21 from manu at gcc dot gnu dot org 2007-03-12 20:15 --- (In reply to comment #20) > Patch submitted to list by 2007-02-09, message-id is > <[EMAIL PROTECTED]> > > I've got a copyright assignment on file since 2003-03-19 (date of > confirmation email from Jessica Natale). > > What else do you need? > Unfortunately, I think your patch got missed. You need to ping the patch from time to time (every 2 weeks or so). See the archives of gcc-patches for examples. Some people check the patch queue http://www.dberlin.org/patches but adding the patch to the tracker does not ensure that it will be reviewed. You still need to ping the relevant maintainers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #3 from dje at gcc dot gnu dot org 2007-03-12 20:19 --- The problem appears to be occurring in real.c conversions from CONST_DOUBLE to TARGET_DOUBLE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug middle-end/30761] [4.1/4.2 regression] Error: unsupported relocation against sfp
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-12 20:19 --- > Andrew, have you verified that the problem is fixed now? Yes the patch fixed the problem for me. >Was this impression mistaken? Yes but in my own testing of a private tree of GCC 4.1.1 modifed for the PS3 game OS ABI, I found this bug happening there too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug preprocessor/23479] Implement binary constants with a "0b" prefix
--- Comment #22 from patchapp at dberlin dot org 2007-03-12 20:40 --- Subject: Bug number preprocessor/23479 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00810.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #17 from b33fc0d3 at gmail dot com 2007-03-12 20:48 --- I can confirm this patch works on an amd64 gentoo sytem too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #18 from pcarlini at suse dot de 2007-03-12 21:08 --- (In reply to comment #17) > I can confirm this patch works on an amd64 gentoo sytem too. And what happens if you just change that #include_next to #include , that would be useful in understanding the issue and how much of it has to do with #include_next (note that, at the moment, as far as I can see, the #include_next special features are still not used) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug c++/31156] New: creates reference to copy constructor on use of temporary object
The following code fails to compile:
begin
#include
class Foo
{
Foo(const Foo&); // private
public:
Foo(int x) { }
};
std::ostream &operator <<(std::ostream &out, const Foo &)
{
return out;
}
int main()
{
std::cout << Foo(5);
}
// test.cpp:5: error: 'Foo::Foo(const Foo&)' is private
// test.cpp:17: error: within this context
end
It does compile with EDG's C++ frontend.
reproduced on gcc version 4.1.2 (Gentoo 4.1.2)
reproduced on gcc version 4.1.1 (Gentoo 4.1.1-r3)
_not_ reproduced on gcc version 3.3.6 (Debian 1:3.3.6-15)
The following also fails on (Debian 4.1.1-21):
begin
class Foo
{
Foo(const Foo&); // private
public:
Foo(int x) { }
};
void foo(const Foo &) { }
int main()
{
foo(Foo(5));
}
// test.cpp:3: error: 'Foo::Foo(const Foo&)' is private
// test.cpp:12: error: within this context
end
Likewise, the following test, demonstrating that it's based on temporaries,
successfully compiles:
begin
class Foo
{
Foo(const Foo&); // private
public:
Foo(int x) { }
};
void foo(const Foo &) { }
int main()
{
Foo f(5);
foo(f);
}
end
--
Summary: creates reference to copy constructor on use of
temporary object
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: charles at vmware dot com
GCC build triplet: gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-
21)
GCC host triplet: gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-
21)
GCC target triplet: gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-
21)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31156
[Bug c++/28774] Request for warning where const/volatile is ignored in a cast
--- Comment #7 from simon_baldwin at yahoo dot com 2007-03-12 21:48 --- PR 14710 isn't really quite the same thing as PR 28774. PR 14170 is concerned with unnecessary casts; PR 28774 is concerned with unnecessary "const" or "volatile" qualifiers within otherwise valid and perhaps necessary casts. That said, this PR really isn't all that useful, is tiny, and hasn't received a lot of support, so I'm going to withdraw it (by setting resolution to "WONTFIX", which I hope will do the right thing). -- simon_baldwin at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug middle-end/30835] ICE with -O2 -ftree-loop-linear
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-03-12 21:56 --- Subject: Bug 30835 Author: rakdver Date: Mon Mar 12 21:56:12 2007 New Revision: 122866 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122866 Log: PR tree-optimization/30835 * lambda-code.c (can_convert_to_perfect_nest): Check whether bb_for_stmt is not NULL before accessing it. Modified: trunk/gcc/ChangeLog trunk/gcc/lambda-code.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30835
[Bug c++/31156] creates reference to copy constructor on use of temporary object
--- Comment #1 from fang at csl dot cornell dot edu 2007-03-12 21:56 --- See PR 25950 and PR 12226 (dup). The resolution is that you need an accessible copy-constructor, regardless of whether or not the compiler elides it during temporary creation. -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31156
[Bug c++/31156] creates reference to copy constructor on use of temporary object
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-12 21:59 --- *** This bug has been marked as a duplicate of 25950 *** -- 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=31156
[Bug c++/25950] [DR 391] Reference binding and explicit copy constructors
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-03-12 21:59 --- *** Bug 31156 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25950
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #4 from dje at gcc dot gnu dot org 2007-03-12 22:20 --- I do not believe this is an endian issue. It is a coincidence that the output value looks like the original constant. GCC converts the __builtin_memcpy() into a VIEW_CONVERT_EXPR. The constant is equivalent to a NaN and GCC uses the value CONST_DOUBLE NaN, not the original bits. real.c converts the CONST_DOUBLE NaN into a ieee_double NaN, which happens to look like the value printed. On little endian targets, the words are swapped, which just happens to look like the original constant. If the VIEW_CONVERT_EXPR is valid, manipulating it like a NaN seems valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug c/31153] -Wconversion does not catch return value mismatch
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-12 22:25 --- Wconversion is implemented in the front-end and there is no data-flow solving on front-ends, so basically it is impossible to know the value of i. In addition, up to GCC 4.3, Wconversion was not meant to warn about signed->unsigned conversion, just for the negative constant case. From GCC 4.3, the behaviour of Wconversion will change. See http://gcc.gnu.org/wiki/NewWconversion However, the new Wconversion will not produce warnings for signedness change as in your testcase, since it results in too many warnings in real-world code (Mozilla, libstdc++, Linux kernel, etc). -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31153
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-12 22:25 --- Index: ../../gcc/fold-const.c === --- ../../gcc/fold-const.c (revision 122864) +++ ../../gcc/fold-const.c (working copy) @@ -7357,6 +7357,7 @@ native_interpret_real (tree type, unsign up to 192 bits. */ REAL_VALUE_TYPE r; long tmp[6]; + long tmp1[6]; total_bytes = GET_MODE_SIZE (TYPE_MODE (type)); if (total_bytes > len || total_bytes > 24) @@ -7386,6 +7387,11 @@ native_interpret_real (tree type, unsign } real_from_target (&r, tmp, mode); + real_to_target (tmp1, &r, mode); + /* If the encoded real is going to decode differently, then reject the constant + conversion. */ + if (memcpy (tmp, tmp1, total_bytes) != 0) +return NULL; return build_real (type, r); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #19 from martin dot jansa at mk dot cvut dot cz 2007-03-12 22:30 --- (In reply to comment #18) > (In reply to comment #17) > > I can confirm this patch works on an amd64 gentoo sytem too. > > And what happens if you just change that #include_next to #include , > that would be useful in understanding the issue and how much of it has to do > with #include_next (note that, at the moment, as far as I can see, the > #include_next special features are still not used) this isn't enough even with building with this brand new gcc-4.3.0_alpha20070309. I'll repeat it with include of proper stdio.h, which looks in gentoo multilib like this jama gcc # cat /usr/include/stdio.h /* Autogenerated by create_ml_includes() in multilib.eclass */ #ifdef __i386__ # include #endif /* __i386__ */ #ifdef __x86_64__ # include #endif /* __x86_64__ */ and with #include without ".h" after that so I'll send results tomorrow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-12 22:38 ---
>From native_encode_int, we get:
(gdb) p/x *(unsigned int[2]*)ptr
$14 = {0x0f00, 0x}
Which is obviously wrong, it should have encoded it as:
{0x000f, 0x}
So we get the wrong answer to begin with and it is not an issue with
native_interpret_real, at least right at this moment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-12 22:44 ---
(In reply to comment #6)
> From native_encode_int, we get:
> (gdb) p/x *(unsigned int[2]*)ptr
> $14 = {0x0f00, 0x}
No that is right, I was looking at while doing a cross so (unsigned int[2]*)
meant we have byte endian swap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug c++/31157] New: Bitfield is not promoted
Following testcase compiles fine with gcc 3.4.6 but not with gcc 4.2.0 20070307
:
- cut here -
#include
using namespace std;
class Foo
{
public:
Foo() { x=1; y=0; };
unsigned int x:12;
unsigned int y;
};
int main()
{
Foo bar;
max(bar.y,bar.x);
return 0;
}
- cut here -
The error is :
max.cpp: In function 'int main()':
max.cpp:17: error: no matching function for call to 'max(unsigned int&, short
unsigned int:12&)'
--
Summary: Bitfield is not promoted
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ismail at pardus dot org dot tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31157
[Bug c++/31157] Bitfield is not promoted
--- Comment #1 from ismail at pardus dot org dot tr 2007-03-12 23:03 --- Original code was from WebKit SVN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31157
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-12 23:08 --- the issue is with native_interpret_real really, tmp is getting the wrong words order. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #20 from pcarlini at suse dot de 2007-03-12 23:09 --- (In reply to comment #19) ... > this isn't enough even with building with this brand new > gcc-4.3.0_alpha20070309. > I'll repeat it with include of proper stdio.h, which looks in gentoo multilib > like this > > jama gcc # cat /usr/include/stdio.h Ok, thanks. But then, an important question is: which (empty? not including any declaration of the expected facilities?!? What header is that?) stdio.h is instead included at build time if you don't specify explicitely the path? You should try to figure out that, whether on your system there are around (in the build directory or elsewhere) stdio.h which in fact are not the correct one. In order to do that, you could proceed as follows: go the build directory of the library and invoke by hand the same line which is failing the build of compatibility.cc, but running only the preprocessor, with -E. You save its output, it should tell us what a heck of wrong stdio.h is included. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-12 23:18 ---
Here is my new patch:
Index: ../../gcc/fold-const.c
===
--- ../../gcc/fold-const.c (revision 122864)
+++ ../../gcc/fold-const.c (working copy)
@@ -7357,6 +7357,7 @@ native_interpret_real (tree type, unsign
up to 192 bits. */
REAL_VALUE_TYPE r;
long tmp[6];
+ long tmp1[6];
total_bytes = GET_MODE_SIZE (TYPE_MODE (type));
if (total_bytes > len || total_bytes > 24)
@@ -7367,6 +7368,7 @@ native_interpret_real (tree type, unsign
for (byte = 0; byte < total_bytes; byte++)
{
int bitpos = byte * BITS_PER_UNIT;
+ int bytepos;
if (total_bytes > UNITS_PER_WORD)
{
word = byte / UNITS_PER_WORD;
@@ -7381,11 +7383,18 @@ native_interpret_real (tree type, unsign
else
offset = BYTES_BIG_ENDIAN ? (total_bytes - 1) - byte : byte;
value = ptr[offset];
+ bytepos = FLOAT_WORDS_BIG_ENDIAN ? total_bytes / 4 - bitpos / 32 - 1 :
bitpos / 32;
- tmp[bitpos / 32] |= (unsigned long)value << (bitpos & 31);
+ tmp[bytepos] |= (unsigned long)value << (bitpos & 31);
+ printf("%ld %ld [%d,%d]\n", tmp[0], tmp[1], bytepos, bitpos);
}
real_from_target (&r, tmp, mode);
+ real_to_target (tmp1, &r, mode);
+ /* If the encoded real is going to decode differently, then reject the
constant
+ conversion. */
+ if (memcmp (tmp, tmp1, total_bytes) != 0)
+return NULL;
return build_real (type, r);
}
I am not 100 % sure this is correct but we get the correct constant now for
this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
