[Bug fortran/32137] New: [4.3 regression] func_result_3.f90 ICEs on powerpc-apple
>From the gfortran testsuite log: Executing on host: /Users/brooks/gcc-trunk/build3/gcc/testsuite/gfortran/../../gfortran -B/Users/brooks/gcc-trunk/build3/gcc/testsuite/gfortran/../../ /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90 -O -pedantic-errors -S -o func_result_3.s(timeout = 300) /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90: In function 'quadric': /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90:8: internal compiler error: in gfc_trans_dummy_array_bias, at fortran/trans-array.c:4046 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90: In function 'quadric': /Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90:8: internal compiler error: in gfc_trans_dummy_array_bias, at fortran/trans-array.c:4046 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. FAIL: gfortran.dg/func_result_3.f90 -O (internal compiler error) FAIL: gfortran.dg/func_result_3.f90 -O (test for errors, line 18) FAIL: gfortran.dg/func_result_3.f90 -O (test for excess errors) -- Summary: [4.3 regression] func_result_3.f90 ICEs on powerpc-apple Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin8.9.0 GCC host triplet: powerpc-apple-darwin8.9.0 GCC target triplet: powerpc-apple-darwin8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug fortran/32137] [4.3 regression] func_result_3.f90 ICEs on powerpc-apple
--- Comment #1 from brooks at gcc dot gnu dot org 2007-05-29 07:27 --- I should have noted: I think this showed up within the last week, but I can confirm that it's not in my saved testsuite results from 2007-05-07. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug middle-end/32083] [4.3 Regression] bug in transfer integer->real->integer
--- Comment #8 from kloedej at knmi dot nl 2007-05-29 07:29 --- (In reply to comment #7) Hi, this is just to report that my code works again as expected. Thanks a lot for the fast fix of this bug! Jos de Kloe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32083
[Bug fortran/32137] [4.3] func_result_3.f90 ICEs on powerpc-apple
--- Comment #2 from brooks at gcc dot gnu dot org 2007-05-29 07:35 --- Update: This isn't a regression; the testcase is new. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression]|[4.3] func_result_3.f90 ICEs |func_result_3.f90 ICEs on |on powerpc-apple |powerpc-apple | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug fortran/32138] New: Scanner not picking up code is in string context, warning about inline comment
Using > gfortran --version GNU Fortran 95 (GCC) 4.3.0 20070131 (experimental) > uname -a Linux loanamd25 2.6.12-rc1-mm-smp #13 SMP Fri Jun 3 17:14:40 BST 2005 x86_64 x86_64 x86_64 GNU/Linux and compiling the file WRITE(*,*) 'A continued comment& &!' END as > gfortran gf_test.f90 results in the erroneous warning from the Fortran scanner "Warning: '&' not allowed by itself with comment in line 2" -- Summary: Scanner not picking up code is in string context, warning about inline comment Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mathewc at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32138
[Bug fortran/32137] [4.3] func_result_3.f90 ICEs on powerpc-apple
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-29 07:51 --- Test case came from PR32088. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug fortran/32138] Scanner not picking up code is in string context, warning about inline comment
--- Comment #1 from mathewc at nag dot co dot uk 2007-05-29 08:02 --- I suppose that the code example could be made clearer if it were WRITE(*,*) 'A continued string& &!' END for which the output is the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32138
[Bug fortran/32138] Scanner not picking up code is in string context, warning about inline comment
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-29 08:05 --- You might want to update your compiler: 4.3.0 20070131 is almost 5 months out of date (in this case this is getting old because you are using a prerelease after all). This is a dup of bug 31495 which was fixed a little over a month ago. *** This bug has been marked as a duplicate of 31495 *** *** This bug has been marked as a duplicate of 31495 *** -- 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=32138
[Bug fortran/31495] Is this continuation line legal?
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-29 08:05 --- *** Bug 32138 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mathewc at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31495
[Bug target/29498] FTZ/DAZ for SSE should be ported to mingw32
--- Comment #4 from dannysmith at gcc dot gnu dot org 2007-05-29 08:09 --- Subject: Bug 29498 Author: dannysmith Date: Tue May 29 08:09:16 2007 New Revision: 125160 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125160 Log: libgcc PR target/29498 * config.host (i[34567]86-*-cygwin* | i[34567]86-*-mingw*) Add crtfastmath.o to extra_parts. Add i386/t-crtfm to tmake_file. * config/i386/t-crtfm: Compile crtfastmath.o with -minline-all-stringops. gcc PR target/29498 * config/i386/t-crtfm: Compile crtfastmath.o with -minline-all-stringops. * config/i386/cygwin.h (ENDFILE_SPECS): Add crtfastmath.o. * config/i386/mingw32.h (ENDFILE_SPECS): Add crtfastmath.o. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygwin.h trunk/gcc/config/i386/mingw32.h trunk/libgcc/ChangeLog trunk/libgcc/config.host trunk/libgcc/config/i386/t-crtfm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29498
[Bug fortran/32137] [4.3] func_result_3.f90 ICEs on powerpc-apple
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-29 08:16 --- The error is in gfc_trans_dummy_array_bias, where the assert fails: gcc_assert (GFC_ARRAY_TYPE_P (type)); The question is: Why does it fail on powerpc-apple but not on x86_64-unknown-linux-gnu? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug target/29498] FTZ/DAZ for SSE should be ported to mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-05-29 08:16 --- Fixed on trunk. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29498
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #6 from pluto at agmk dot net 2007-05-29 08:50 ---
(In reply to comment #5)
> Which shows for sure r may be used unitialized.
yes, but even if i catch possible i/o failure, gcc still produces warning.
--- auHexCastTest.ii.orig
+++ auHexCastTest.ii
@@ -18958,7 +18958,12 @@
R r;
stlp_std::istringstream str ( s );
- str >> stlp_std::hex >> r;
+ str.exceptions ( stlp_std::istringstream::eofbit ||
stlp_std::istringstream::badbit || stlp_std::istringstream::failbit );
+ try {
+str >> stlp_std::hex >> r;
+ } catch ( stlp_std::istringstream::failure ) {
+throw;
+ }
return r;
}
so, is it still an invalid testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug middle-end/32135] [4.3 Regression] bogus array-ref fold triggering array overflow warning
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-29 09:21 --- 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 |2007-05-29 09:21:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32135
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #7 from pluto at agmk dot net 2007-05-29 10:17 --- (In reply to comment #6) > + str.exceptions ( stlp_std::istringstream::eofbit || > stlp_std::istringstream::badbit || stlp_std::istringstream::failbit ); of course it should be '|' instead of '||' (shame on me) but the warning is still presents. it is also presents when i use the fail() method instead of exceptions machinery. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug fortran/32103] Module with equivalence draws "unsatisfied reference"
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-29 10:39 ---
The patch below works and regtests OK. I am trying to devise a safe method of
gettting rid of the redundant symbols if none of the equivalence members is
USEd. If I cannot see something by tonight, I will submit anyway.
Paul
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(révision 125056)
+++ gcc/fortran/module.c(copie de travail)
@@ -189,7 +189,7 @@ static gfc_use_rename *gfc_rename_list;
static pointer_info *pi_root;
static int symbol_number; /* Counter for assigning symbol numbers */
-/* Tells mio_expr_ref not to load unused equivalence members. */
+/* Tells mio_expr_ref to make symbols for unused equivalence members. */
static bool in_load_equiv;
@@ -1501,10 +1501,10 @@ mio_internal_string (char *string)
typedef enum
{ AB_ALLOCATABLE, AB_DIMENSION, AB_EXTERNAL, AB_INTRINSIC, AB_OPTIONAL,
AB_POINTER, AB_SAVE, AB_TARGET, AB_DUMMY, AB_RESULT, AB_DATA,
- AB_IN_NAMELIST, AB_IN_COMMON, AB_FUNCTION, AB_SUBROUTINE, AB_SEQUENCE,
- AB_ELEMENTAL, AB_PURE, AB_RECURSIVE, AB_GENERIC, AB_ALWAYS_EXPLICIT,
- AB_CRAY_POINTER, AB_CRAY_POINTEE, AB_THREADPRIVATE, AB_ALLOC_COMP,
- AB_VALUE, AB_VOLATILE, AB_PROTECTED
+ AB_IN_NAMELIST, AB_IN_EQUIVALENCE, AB_IN_COMMON, AB_FUNCTION,
+ AB_SUBROUTINE, AB_SEQUENCE, AB_ELEMENTAL, AB_PURE, AB_RECURSIVE,
+ AB_GENERIC, AB_ALWAYS_EXPLICIT, AB_CRAY_POINTER, AB_CRAY_POINTEE,
+ AB_THREADPRIVATE, AB_ALLOC_COMP, AB_VALUE, AB_VOLATILE, AB_PROTECTED
}
ab_attribute;
@@ -1525,6 +1525,7 @@ static const mstring attr_bits[] =
minit ("RESULT", AB_RESULT),
minit ("DATA", AB_DATA),
minit ("IN_NAMELIST", AB_IN_NAMELIST),
+minit ("IN_EQUIVALENCE", AB_IN_EQUIVALENCE),
minit ("IN_COMMON", AB_IN_COMMON),
minit ("FUNCTION", AB_FUNCTION),
minit ("SUBROUTINE", AB_SUBROUTINE),
@@ -1610,6 +1611,8 @@ mio_symbol_attribute (symbol_attribute *
MIO_NAME (ab_attribute) (AB_DATA, attr_bits);
if (attr->in_namelist)
MIO_NAME (ab_attribute) (AB_IN_NAMELIST, attr_bits);
+ if (attr->in_equivalence)
+ MIO_NAME (ab_attribute) (AB_IN_EQUIVALENCE, attr_bits);
if (attr->in_common)
MIO_NAME (ab_attribute) (AB_IN_COMMON, attr_bits);
@@ -1700,6 +1703,9 @@ mio_symbol_attribute (symbol_attribute *
case AB_IN_NAMELIST:
attr->in_namelist = 1;
break;
+ case AB_IN_EQUIVALENCE:
+ attr->in_equivalence = 1;
+ break;
case AB_IN_COMMON:
attr->in_common = 1;
break;
@@ -2234,9 +2240,25 @@ mio_symtree_ref (gfc_symtree **stp)
require_atom (ATOM_INTEGER);
p = get_integer (atom_int);
- /* An unused equivalence member; bail out. */
+ /* An unused equivalence member; make a symbol and a symtree
+for it. */
if (in_load_equiv && p->u.rsym.symtree == NULL)
- return;
+ {
+ /* Since this is not used, it must have a unique name. */
+ p->u.rsym.symtree = get_unique_symtree (gfc_current_ns);
+
+ /* Make the symbol. */
+ if (p->u.rsym.sym == NULL)
+ {
+ p->u.rsym.sym = gfc_new_symbol (p->u.rsym.true_name,
+ gfc_current_ns);
+ p->u.rsym.sym->module = gfc_get_string (p->u.rsym.module);
+ }
+
+ p->u.rsym.symtree->n.sym = p->u.rsym.sym;
+ p->u.rsym.symtree->n.sym->refs++;
+ p->u.rsym.referenced = 1;
+ }
if (p->type == P_UNKNOWN)
p->type = P_SYMBOL;
@@ -3206,13 +3228,13 @@ load_equiv (void)
mio_expr (&tail->expr);
}
-/* Unused variables have no symtree. */
-unused = false;
+/* Unused equivalence members have a unique name. */
+unused = true;
for (eq = head; eq; eq = eq->eq)
{
- if (!eq->expr->symtree)
+ if (!check_unique_name (eq->expr->symtree->name))
{
- unused = true;
+ unused = false;
break;
}
}
Index: gcc/testsuite/gfortran.dg/module_equivalence_3.f90
===
--- gcc/testsuite/gfortran.dg/module_equivalence_3.f90 (révision 0)
+++ gcc/testsuite/gfortran.dg/module_equivalence_3.f90 (révision 0)
@@ -0,0 +1,38 @@
+! { dg-do run }
+! This checks the fix for PR32103 in which not using one member
+! of an equivalence group would cause all memory of the equivalence
+! to be lost and subsequent incorrect referencing of the remaining
+! members.
+!
+! Contributed by Toon Moene <[EMAIL PROTECTED]>
+!
+module aap
+ real :: a(5) = (/1.0,2.0,3.0,4.0,5.0/)
+ real :: b(3)
+ real :: d(5) = (/1.0,2.0,3.0,4.0,5.0/)
+ equivalence (a(3),b(1))
+end module aap
+
+ use aap, only : b
+ call foo
+ call bar
+ call foobar
+contains
+ subroutine foo
+use aap, only : c=>b
+if
[Bug bootstrap/29382] Bootstrap comparison failure!
--- Comment #4 from jakub at gcc dot gnu dot org 2007-05-29 10:40 ---
When using gcc-3.2.3 as bootstrap compiler, i386.c is miscompiled
with -O0 -fkeep-inline-functions (the latter option is what is new
in gcc 4.2 and why 4.1.x bootstrap didn't suffer from this, see
2006-07-04 Eric Botcazou <[EMAIL PROTECTED]>
PR bootstrap/18058
* configure.in: Add -fkeep-inline-functions to CFLAGS for stage 1
if the bootstrap compiler is a GCC version that supports it.
* configure: Regenerate.
).
typedef struct rtx_def *rtx;
enum machine_mode
{
VOIDmode = 0,
DImode = 13
};
extern rtx gen_rtx_CONST_INT (enum machine_mode, long);
extern rtx gen_x86_shld_1 (rtx, rtx, rtx);
static __inline__ rtx
gen_x86_64_shld(rtx a, rtx b, rtx c)
{
return 0;
}
extern rtx emit_insn (rtx);
void
foo (rtx *high, rtx *low, enum machine_mode mode, int count)
{
emit_insn ((mode == DImode ? gen_x86_shld_1 : gen_x86_64_shld)
(high[0], low[0], gen_rtx_CONST_INT (VOIDmode, count)));
}
(extracted from i386.i) is miscompiled (tested latest RHEL3 gcc-3.2.3 as well
as current branches/gcc-3_2-branch), it calls gen_x86_64_shld unconditionally.
Removing -fkeep-inline-functions (or adding asm volatile ("") into the inline
function or making gen_x86_64_shld extern instead of static inline cures this).
Now, gcc-3_2-branch is long time closed, so IMNSHO gcc-4.2+ should work around
this bug.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot org
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSFORME |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382
[Bug libstdc++/32092] Can't create directory link when build libstdc++ (gcc-4.2.0)
--- Comment #2 from dragzhb at yahoo dot com dot cn 2007-05-29 10:46 --- Sorry, I copy error. it should be $GCC_SRC_ROOT\libstdc++-v3\include\ext\pb_ds\detail I build it in another directory. steps : mkdir mingw_build cd mingw_build ../gcc-4.2.0/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --disable-shared --enable-interpreter --enable-hash-synchronization make CFLAGS='-O2' CXXFLAGS='-mthreads -O2' LIBCFLAGS='-O2' LIBCXXFLAGS='-mthreads -O2' bootstrap make install -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32092
[Bug bootstrap/29382] Bootstrap comparison failure!
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-29 10:47 --- > Now, gcc-3_2-branch is long time closed, so IMNSHO gcc-4.2+ should work around > this bug. Agreed, we can simply say that GCC 3.2.x is not "is a GCC version that supports it". Would you mind writing the patch? I don't have GCC 3.2.x handy. TIA. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382
[Bug c++/32085] "warning: deleting void* is undefined" sometimes bogus
--- Comment #4 from andrew dot stubbs at st dot com 2007-05-29 10:57 --- Well, obviously I'll let people who really understand the details of this decide whether it can be solved. However, on the principle that warnings which one can safely ignore, but cannot silence, are at best unhelpful, and at worst cry wolf, I would ask that somebody looks into how this can be improved. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32085
[Bug c++/32085] "warning: deleting void* is undefined" sometimes bogus
--- Comment #5 from gdr at cs dot tamu dot edu 2007-05-29 11:11 --- Subject: Re: "warning: deleting void* is undefined" sometimes bogus "andrew dot stubbs at st dot com" <[EMAIL PROTECTED]> writes: | Well, obviously I'll let people who really understand the details of this | decide whether it can be solved. | | However, on the principle that warnings which one can safely ignore, but cannot | silence, are at best unhelpful, and at worst cry wolf, I would ask that | somebody looks into how this can be improved. The code does not make sense in the first place, why would anybody would want to ignore the diagnostic? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32085
[Bug c++/32085] "warning: deleting void* is undefined" sometimes bogus
--- Comment #6 from andrew dot stubbs at st dot com 2007-05-29 11:18 --- It's a cut down example to demonstrate the problem, not real world code. I do ignore warnings in code that does exactly what I want it to do, provided that I understand them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32085
[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3
--- Comment #29 from markus dot duft at salomon dot at 2007-05-29 11:37 --- Hi everybody! gcc 4.2.0 works fine on interix 3.5 using the native binutils (at least as and ld must be native...) with patch i will attach, and the following commands: $ ../gcc-4.2.0/configure --enable-languages=c,c++ --enable-threads=posix --with-stabs --disable-nls --enable-shared --disable-libssp --with-gnu-as --with-gnu-ld --disable-werror --prefix=/testing/gcc/installed $ gmake bootstrap $ gmake install i used GNU make, since the interix native make has some problems, but i don't know if gcc would build fine with the native one... i applied the two interix patches attached here allready, and changed libstdc++v3 to not include -ffunction-sections, which breaks any C++ compiled program on interix, maybe somebody could change GCC to just ignore this flag on interix/windows? have fun compiling... Cheers, Markus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3
--- Comment #30 from markus dot duft at salomon dot at 2007-05-29 11:40 --- Created an attachment (id=13625) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13625&action=view) GCC 4.2.0 on interix 3.5 The patch includes the two previous diffs posted here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug bootstrap/29382] Bootstrap comparison failure!
--- Comment #6 from jakub at gcc dot gnu dot org 2007-05-29 11:42 ---
Seems there were 2 separate bugs that are causing this miscompilation.
1) common_type (in contemporary gcc's common_pointer_type) will for the type
of the whole conditional expression use pointer to attribute const function
rather than non-const:
int fn1 (void);
int fn2 (void) __attribute__((const));
...
(cond ? fn1 : fn2)
I'd say that's an unfortunate effect from representing __attribute__((const))
as TREE_READONLY on the FUNCTION_TYPE rather than as an attribute. Say for
cond expr where one ptr target is volatile and the other is not the result
needs to be ptr to volatile and similarly for say
int *ptr1;
const int *ptr2;
cond ? ptr1 : ptr2
where the result should be pointer to const, a conservative choice. But for
__attribute__((const)) functions the conservative choise is the exact opposite,
if I have (cond ? fn1 : fn2) one of the functions isn't const and therefore
nothing should assume the whole thing is pointer to __attribute__((const))
function. gcc trunk handles this the same way.
2) because of 1), but also e.g. on
typedef struct rtx_def *rtx;
enum machine_mode
{
VOIDmode = 0,
DImode = 13
};
extern rtx gen_rtx_CONST_INT (enum machine_mode, long);
extern rtx gen_x86_shld_1 (rtx, rtx, rtx) __attribute__((const));
extern rtx gen_x86_64_shld (rtx, rtx, rtx) __attribute__((const));
extern rtx emit_insn (rtx);
void
foo (rtx *high, rtx *low, enum machine_mode mode, int count)
{
emit_insn ((mode == DImode ? gen_x86_shld_1 : gen_x86_64_shld)
(high[0], low[0], gen_rtx_CONST_INT (VOIDmode, count)));
}
where 1) doesn't apply a properly emitted expanded COND_EXPR into rtl is
passed through emit_libcall_block which changes:
(insn 31 0 32 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -20 [0xffec])) [0 mode+0 S4 A32])
(const_int 13 [0xd]))) -1 (nil)
(nil))
(jump_insn 32 31 34 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 37)
(pc))) -1 (nil)
(nil))
(insn 34 32 35 (set (reg:DI 63)
(symbol_ref:DI ("gen_x86_shld_1"))) -1 (nil)
(nil))
(jump_insn 35 34 36 (set (pc)
(label_ref 40)) -1 (nil)
(nil))
(barrier 36 35 37)
(code_label 37 36 39 2 "" "" [0 uses])
(insn 39 37 40 (set (reg:DI 63)
(symbol_ref:DI ("gen_x86_64_shld"))) -1 (nil)
(nil))
(code_label 40 39 42 3 "" "" [0 uses])
(insn 42 40 44 (set (reg:DI 1 rdx)
(reg:DI 60)) -1 (nil)
(nil))
(insn 44 42 46 (set (reg:DI 4 rsi)
(mem:DI (reg/f:DI 61) [0 S8 A64])) -1 (nil)
(nil))
(insn 46 44 47 (set (reg:DI 5 rdi)
(mem:DI (reg/f:DI 62) [0 S8 A64])) -1 (nil)
(nil))
(call_insn/u 47 46 0 (set (reg:DI 0 rax)
(call (mem:QI (reg:DI 63) [0 S1 A8])
(const_int 0 [0x0]))) -1 (nil)
(nil)
(expr_list (use (reg:DI 5 rdi))
(expr_list (use (reg:DI 4 rsi))
(expr_list (use (reg:DI 1 rdx))
(nil)
into
(insn 34 30 39 (set (reg:DI 63)
(symbol_ref:DI ("gen_x86_shld_1"))) -1 (nil)
(nil))
(insn 39 34 31 (set (reg:DI 63)
(symbol_ref:DI ("gen_x86_64_shld"))) -1 (nil)
(nil))
(insn 31 39 32 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -20 [0xffec])) [0 mode+0 S4 A32])
(const_int 13 [0xd]))) -1 (nil)
(nil))
(jump_insn 32 31 35 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 37)
(pc))) -1 (nil)
(nil))
(jump_insn 35 32 36 (set (pc)
(label_ref 40)) -1 (nil)
(nil))
(insn 34 30 39 (set (reg:DI 63)
(symbol_ref:DI ("gen_x86_shld_1"))) -1 (nil)
(nil))
(insn 39 34 31 (set (reg:DI 63)
(symbol_ref:DI ("gen_x86_64_shld"))) -1 (nil)
(nil))
(insn 31 39 32 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -20 [0xffec])) [0 mode+0 S4 A32])
(const_int 13 [0xd]))) -1 (nil)
(nil))
(jump_insn 32 31 35 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 37)
(pc))) -1 (nil)
(nil))
(jump_insn 35 32 36 (set (pc)
(label_ref 40)) -1 (nil)
(nil))
(barrier 36 35 37)
(code_label 37 36 40 2 "" "" [0 uses])
(code_label 40 37 42 3 "" "" [0 uses])
(insn 42 40 44 (set (reg:DI 1 rdx)
(reg:DI 60)) -1 (nil)
(nil))
(insn 44 42 46 (set (reg:DI 4 rsi)
(mem:DI (reg/f:DI 61) [0 S8 A64])) -1 (nil)
(nil))
(insn 46 44 47 (set (reg:DI 5 rdi)
(mem:DI (reg/f:DI 62) [0 S8 A64])) -1 (nil)
(nil))
(call_insn/u 47 46 49 (set (reg:DI 0 rax)
(call (mem:QI (reg:DI 63) [0 S1 A8])
(const_int 0 [0x0]))) -1 (n
[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3
--- Comment #31 from markus dot duft at salomon dot at 2007-05-29 12:13 --- Created an attachment (id=13626) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13626&action=view) Fixed GCC 4.2.0 on interix 3.5 The patch includes the two previous diffs posted here. This is a fixed version, which also should work fine for cross compilers... -- markus dot duft at salomon dot at changed: What|Removed |Added Attachment #13625|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug tree-optimization/31767] [4.3 Regression] 25% slowdown in gas_dyn since 2007-04-27
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-29 12:23 --- Seems to be essentially back to the old speed. -> Close -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31767
[Bug c++/32085] "warning: deleting void* is undefined" sometimes bogus
--- Comment #7 from manu at gcc dot gnu dot org 2007-05-29 12:26 --- (In reply to comment #6) > It's a cut down example to demonstrate the problem, not real world code. Could you provide an example of real-world code where the warning is triggered? We would prefer minimal but anything is better than nothing. -- 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=32085
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #8 from manu at gcc dot gnu dot org 2007-05-29 12:31 --- (In reply to comment #6) > > so, is it still an invalid testcase? Does the warning show up with -O1 and -O2 ? -- 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=32132
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #9 from pluto at agmk dot net 2007-05-29 12:35 --- (In reply to comment #8) > (In reply to comment #6) > > > > so, is it still an invalid testcase? > > Does the warning show up with -O1 and -O2 ? > only with -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #10 from pluto at agmk dot net 2007-05-29 12:42 --- Created an attachment (id=13627) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13627&action=view) update for the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug bootstrap/29382] Bootstrap comparison failure!
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-29 12:48 --- 2) is apparently PR11557, fixed in GCC 3.3.1+. So, I'd say as workaround we should not use -fkeep-inline-functions for GCC < 3.3.1. Testing a patch for that. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-29 12:48:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #11 from manu at gcc dot gnu dot org 2007-05-29 12:57 --- (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > > > > so, is it still an invalid testcase? > > > > Does the warning show up with -O1 and -O2 ? > > > > only with -O3. > That is a bug by itself. Using more optimisations could result in some cases clearing out (and thus, less warnings). It should never result in more warnings. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-29 13:17 --- (In reply to comment #3) > Paul, I don't think that's solving the right problem. The code is legal; the > inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which > conforms with a CHARACTER scalar of len=20. I do not agree. The standard does not demand that the arguments conform but that 9.3.96 MERGE (TSOURCE, FSOURCE, MASK) Description: Selects between two values or between corresponding elements in two arrays, according to the condition specified by a logical mask. Class: Elemental function; Generic Arguments: TSOURCE Must be a scalar or array (of any data type). FSOURCE Must be a scalar or array of the same type and type parameters as TSOURCE. MASK Must be a logical array. Results: The result type is the same as TSOURCE. The value of MASK determines whether the result value is taken from TSOURCE (if MASK is true) or FSOURCE (if MASK is false). According to 2.4.1.1, the type parameters are KIND and LEN. I think that the g95 and sun messages are correct. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-05-29 13:22 --- The __div0 function is called by the division routines when an attempt to divide by zero is detected. On a linux system, it is expected that this will cause SIGFPE to be raise(3)d, so the default implementation of this call does precisely this. There's two ways you can avoid this problem when trying to build uboot (which isn't a linux application). 1) Provide your own implementation of __div0 that does the right thing for your system. 2) Use a different configuration of the compiler. Either way, this isn't a bug in the compiler. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798
[Bug tree-optimization/32139] New: [4.1 Regression] ICE in mark_operand_necessary
int foo (void);
int bar (void) __attribute__((const));
int
test (int x)
{
int a = (x == 1 ? foo : bar) ();
int b = (x == 1 ? foo : bar) ();
return a + b;
}
ICEs in mark_operand_necessary.
3.4.x works and so does 4.2 and trunk.
Related to in PR29382 described common_pointer_type, but perhaps not just that.
--
Summary: [4.1 Regression] ICE in mark_operand_necessary
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32139
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-29 13:39 ---
(In reply to comment #4)
> I misunderstood something slightly in that last comment; MERGE is elemental,
> so
> the conforming I mentioned doesn't matter. Also, my guess that fixing the
> transfer("A", "x", 20) problem would fix the whole thing proved to be
> incorrect.
See comment #6.
> So, even once the first bit is fixed, if we change the code to be legitimate,
> as follows, then it still has an error:
> character(len=20) :: string
> logical :: a(20)
> write(*,*) transfer (merge (transfer("A", "x", 20), "b", a), string )
> end
It also fails with a character(len = 1) array of size 20.
> Specifically, we ICE by failing the "gcc_assert (integer_zerop (loop ->
> from[n]))" at line 593 of trans-array.c, when doing gfc_conv... stuff to the
> arguments of the outer transfer function.
> I'm having a bear of a time tracking down why this is happening. The problem
> is that we're generating a temporary, so loop->temp_dim is 1 (as set in
> gfc_trans_constant_array_constructor, line 1576). However, the loop seems to
> be picking up dimensions from the result of the inner transfer function
> somehow. Walking through the ss list for the loop gives a GFC_SS_CONSTRUCTOR,
> a GFC_SS_SCALAR, and a GFC_SS_SECTION, and the GFC_SS_SECTION causes the
> info->start[0] and info->end[0] values to be set (to 1 and 20, respectively)
> in
> gfc_conv_ss_startstride, which then propagate to the from[0] and to[0] values
> for the loop.
> I can't seem to duplicate this with any other set of functions. It's only
> happening with characters, not integers, and if I break up the expression or
> substitute other things for transfer and merge, it doesn't replicate this
> behavior.
> Help?
I'll have a think about this tonight. I NEVER find debugging the scalarizer
easy; not in small part because I have to re-understand it every time I go near
it.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug c/32102] -Wall stomps on -Wstrict-overflow
--- Comment #2 from ian at airs dot com 2007-05-29 13:48 --- I think that having -Wall clobber -Wstrict-overflow in this way is confusing. This isn't reversing the setting of the option, it's changing its level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #8 from burnus at gcc dot gnu dot org 2007-05-29 14:05 ---
> In reducing this, I discovered that gfortran currently hangs on the following
> much simpler code. I suspect that if we fix this, it'll fix the original code
> too.
> write(*,*) transfer("A", "x", 20)
NAG f95 and g95 print for that case the (default-shown) warning:
Warning: Intrinsic TRANSFER has partly undefined result
and
Warning (148): Not enough data to produce the requested array size in
TRANSFER function at (1)
NAG f95, ifort and g95 print "A" (sunf95 prints "A2�Uh2�U").
Such a compile-time warning for transfer(...,...,size) would be also nice to
have in gfortran.
For the original test case (comment 0, see also comment 1):
- f95 and g95 print the same warning plus the error (g95: see comment 2):
Error: Unequal character lengths (1 and 20) in MERGE intrinsic
- ifort accepts it and returns a zero-length string
- sunf95 prints an error (see comment 1)
> character(len=20) :: string
> logical :: a(20)
> write(*,*) transfer (merge (transfer("A", "x", 20), "b", a), string )
> end
This gives still a warning with g95 and NAG f95; NAG outputs "Abb",
ifort/g95/sunf95 show "".
I agree with Paul, NAGf95 and g95 that merge needs to have
same-character-length strings.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #9 from dominiq at lps dot ens dot fr 2007-05-29 14:25 --- > This gives still a warning with g95 and NAG f95; > NAG outputs "Abb", > ifort/g95/sunf95 show "". Since a(:) is not initialized, the output can be anything. with a = .false. a(1) = .true. I get 'Abbb' with both xlf and g95, otherwise the outputs differ. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/32140] New: wrong code
The following (reduced from CP2K, PR 29975) generates wrong code with gfortran
(gcc version 4.3.0 20070526)
MODULE TEST
CONTAINS
PURE FUNCTION s2a_3(s1,s2,s3) RESULT(a)
CHARACTER(LEN=*), INTENT(IN) :: s1, s2, s3
CHARACTER(LEN=4), DIMENSION(3):: a
a(1)=s1; a(2)=s2; a(3)=s3
END FUNCTION
END MODULE
USE TEST
write(6,*) s2a_3("a","bb","ccc")
END
gfortran -O0 test.f90
> ./a.out
a bb ccc
> gfortran -O2 test.f90
> ./a.out
abb ccc
the latter case also shows:
==21268== Syscall param write(buf) points to uninitialised byte(s)
==21268==at 0x4FF9CB0: __write_nocancel (in /lib64/libc-2.4.so)
==21268==by 0x4BB8E10: do_write (unix.c:336)
==21268==by 0x4BB8EB1: fd_flush (unix.c:386)
==21268==by 0x4BB9AE7: fd_write (unix.c:761)
==21268==by 0x4BB65E5: _gfortrani_next_record (transfer.c:2526)
==21268==by 0x4BB69F5: finalize_transfer (transfer.c:2663)
==21268==by 0x4BB6A38: _gfortran_st_write_done (transfer.c:2801)
==21268==by 0x40090D: MAIN__ (in /users/vondele/g95/a.out)
==21268==by 0x400AEB: main (fmain.c:22)
==21268== Address 0x517A3CF is 151 bytes inside a block of size 8,344 alloc'd
==21268==at 0x4A20A56: malloc (vg_replace_malloc.c:149)
==21268==by 0x4B39518: _gfortrani_get_mem (memory.c:53)
==21268==by 0x4BB9879: fd_to_stream (unix.c:1043)
==21268==by 0x4BB86BB: _gfortrani_init_units (unit.c:515)
==21268==by 0x4B39267: init (main.c:152)
==21268==by 0x4BC8B61: (within
/data/vondele/gcc_trunk/build/lib64/libgfortran.so.3.0.0)
==21268==by 0x4B35F8A: (within
/data/vondele/gcc_trunk/build/lib64/libgfortran.so.3.0.0)
--
Summary: wrong code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #104 from jv244 at cam dot ac dot uk 2007-05-29 15:07 --- Even at optimisations levels lower than the one needed to generate the ICE of PR 32096 (thanks tobias burnus), CP2K seems miscompiled. One possible testcase has been added as PR 32140. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c/31128] __builtin_stack_restore/__builtin_stack_save should not be exposed to the user
--- Comment #8 from sabre at nondot dot org 2007-05-29 15:14 --- Right, you could do that, but it is a) not guaranteed to work going forward, and b) expects properly structured (e.g. nested) control flow. If I had b, I could just make a vla :) -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-29 15:32 --- Regression happens between 2007-05-25-r125057 and 2007-05-29-r125159. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.3.0 Known to work||4.2.0 4.1.3 Last reconfirmed|-00-00 00:00:00 |2007-05-29 15:32:38 date|| Summary|wrong code |[4.3 Regression] ||Miscompilation with -O1 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #2 from jv244 at cam dot ac dot uk 2007-05-29 15:41 ---
I assume this is another incarnation of this bugs but leads to a segfault and a
slightly different valgrind output:
MODULE TEST
CONTAINS
PURE FUNCTION s2a_3(s1,s2,s3) RESULT(a)
CHARACTER(LEN=*), INTENT(IN) :: s1, s2, s3
CHARACTER(LEN=1000), DIMENSION(3):: a
a(1)=s1; a(2)=s2; a(3)=s3
END FUNCTION
END MODULE
USE TEST
character(LEN=80) :: b(3)
b=s2a_3("Distribution by marix blocks", "Distribution by matrix rows",&
"Distribution by matrix columns")
write(6,*) b(3)
END
==21561==at 0x4A21AF0: memset (mc_replace_strmem.c:490)
==21561==by 0x400A8B: __test_MOD_s2a_3 (in /users/vondele/g95/a.out)
==21561==by 0x40089D: MAIN__ (in /users/vondele/g95/a.out)
==21561==by 0x400B4B: main (fmain.c:22)
==21561== Address 0x7FF005B80 is not stack'd, malloc'd or (recently) free'd
==21561==
==21561== Process terminating with default action of signal 11 (SIGSEGV)
==21561== Access not within mapped region at address 0x7FF005B80
==21561==at 0x4A21AF0: memset (mc_replace_strmem.c:490)
==21561==by 0x400A8B: __test_MOD_s2a_3 (in /users/vondele/g95/a.out)
==21561==by 0x40089D: MAIN__ (in /users/vondele/g95/a.out)
==21561==by 0x400B4B: main (fmain.c:22)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug c++/32141] New: default init doesn't work in ctor initializer list
A POD struct is not correctly initialized when default
initialization is requested in the initialization list of a
constructor, and it is a base class. Consider the following
program:
-
#include
#include
#include
#include
void*
operator new( size_t n ) throw (std::bad_alloc)
{
void* p = malloc( n ) ;
if ( p == NULL ) {
throw std::bad_alloc() ;
}
memset( p, 0xAA, n ) ;
return p ;
}
void
operator delete( void* p ) throw ()
{
free( p ) ;
}
struct POD
{
short l ;
unsigned char s[ 6 ] ;
} ;
class A : public POD
{
public:
A() : POD() {}
} ;
class B
{
public:
B() : myPOD() {}
POD myPOD ;
} ;
int
main()
{
A* pA = new A ;
std::cout.setf( std::ios::hex, std::ios::basefield ) ;
std::cout << "length A = " << pA->l << std::endl ;
B* pB = new B ;
std::cout << "length B = " << pB->myPOD.l << std::endl ;
return 0 ;
}
-
(The replacement new and delete are just to ensure that the
memory doesn't accidentally happen to be correctly initialized.)
According to the standard, "An object whose initializer is an
empty set of parentheses, i.e., (), shall be
default-initialized", and default initialization of a POD type
is zero-initialization. When compiled, however, this program
outputs:
-
length A =
length B = 0
-
The default initialization has correctly taken place for the
member object, but not for the base class.
--
James Kanze (GABI Software) email:[EMAIL PROTECTED]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'Ãcole, France, +33 (0)1 30 23 00 34
--
Summary: default init doesn't work in ctor initializer list
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: james dot kanze at gmail dot com
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=32141
[Bug c++/32142] New: gcc crashes when creating coverage info and optimization
When compiling the attached file, g++ crashes. Trying to reduce the file size, random crashes occurred, ranging from endless loops to glibc detecting memory corruption. Removing the "#line" directives cures the crash. Call: g++ -O3 -fprofile-arcs pp.C -- Summary: gcc crashes when creating coverage info and optimization Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominik dot strasser at onespin-solutions dot com 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=32142
[Bug c++/32142] gcc crashes when creating coverage info and optimization
--- Comment #1 from dominik dot strasser at onespin-solutions dot com 2007-05-29 17:29 --- Created an attachment (id=13628) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13628&action=view) bzip2ed preprocessor output for reproducing the crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32142
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #5 from tkoenig at alice-dsl dot net 2007-05-29 17:47 --- Subject: Re: knowing that stride==1 when using allocated arrays and escaping allocatable arrays On Tue, 2007-05-29 at 04:52 +, pinskia at gcc dot gnu dot org wrote: > we think we change a's stride > which we don't (and cannot in this case). I can see two ways to address this issue (both of them worth pursuing): a) For allocatable arrays, we can always assume stride=1. b) We can tell the middle-end that our random number generator doesn't modify the array descriptor (similar to PR 20165). Once we've fixed PR 20165, this should be easy, but I don't see anybody working on it. So, maybe looking at a) is better. Personally, I like the allocatable array feature of Fortran 95 very much. It'd be a pity if this carried a big performance overhead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #6 from jb at gcc dot gnu dot org 2007-05-29 17:51 --- Reopening. This vectorizes only partly, with -ffast-math to boot. We should be able to vectorize it without doing any "unsafe" math. gfortran -O2 -ffast-math -march=native -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=6 allocate-loop.f90 allocate-loop.f90:15: note: LOOP VECTORIZED. allocate-loop.f90:14: note: LOOP VECTORIZED. allocate-loop.f90:10: note: Vectorizing an unaligned access. allocate-loop.f90:10: note: LOOP VECTORIZED. allocate-loop.f90:9: note: not vectorized: data ref analysis failed D.1424_40 = (*D.1371_14)[D.1423_39] allocate-loop.f90:1: note: vectorized 3 loops in function. and without -ffast-math: gfortran -O2 -march=native -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=6 allocate-loop.f90 allocate-loop.f90:15: note: not vectorized: unsupported use in stmt. allocate-loop.f90:14: note: LOOP VECTORIZED. allocate-loop.f90:10: note: not vectorized: unsupported use in stmt. allocate-loop.f90:9: note: not vectorized: data ref analysis failed D.1424_40 = (*D.1371_14)[D.1423_39] allocate-loop.f90:1: note: vectorized 1 loops in function. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug c++/32143] New: decl rtl generated with incorrect visibility
Because of the patch for PR19238, make_decl_rtl is called before the visibility of variables is determined. You can see this when you compile g++.old-deja/g++.mike/ns12.c with -fpic. default_binds_local_p_1 (decl, 1) does not return true for (anonymous namespace)::i when its decl rtl is created, and hence its symbol_ref flags don't have SYMBOL_FLAG_LOCAL set. Although default_binds_local_p_1 konws how to use the visibility of the decl, it has no way of calling decl_anon_ns_mem_p in the c++ frontend, like decl2.c:determine_visibility does. That also means that TARGET_IN_SMALL_DATA_P has no usable visibility information that it acn use to guide the decision if something should be put into a small data section. -- Summary: decl rtl generated with incorrect visibility Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32143
[Bug middle-end/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-29 18:09 --- More regression hunting: FAILS with r125059, Works with r125057. Conclusion: The patch causing or revealing this wrong-code error is: r125058 | rguenth | 2007-05-25 11:07:29 +0200 (Fr, 25 Mai 2007) | 10 lines 2007-05-24 Richard Guenther <[EMAIL PROTECTED]> Andrew Pinski <[EMAIL PROTECTED]> PR tree-optimization/31982 Andrew or Richard, could you have a look? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org, burnus at gcc dot ||gnu dot org Component|fortran |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/29240] optional argument for signal intrinsic not supported
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-05-29 18:13 --- I am currently looking at the implementation of signal, so adding this may be not too much effort. Some questions/remarks: > The third argument "flag" is an integer that plays the role of SIG_DFL > in the C library version of signal(). [...] for example, it says that > when flag=-1, control is passed to the user's signal handler function > "ctrlco" when signal number "signum" is encountered. If flag=0, the > user's signal handler function is ignored and the default action is > taken instead. (1) There is no 3-argument version of signal(2) in glibc-2.[56]?! (2) You are aware of the differnt ways to invoke the SIGNAL function? You can _either_ set a handler function or use handler=1 (SIG_IGN) or handler=0 (SIG_DFL): INTEGER, PARAMETER :: SIG_DFL = 0, SIG_IGN = 1 status = signal(number, handler) ! install a signal handler status = signal(number, SIG_DFL) ! restore default handler status = signal(number, SIG_IGN) ! ignore signal This won't compile your code out of the box, but gives the functionality you are asking for (as I understand it). Introducing a third argument seems to be redundant. FX, you confirmed this enhancement: is do-as-the-others-do really good enough a reason to implement this? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29240
[Bug middle-end/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-29 18:15 --- > I assume this is another incarnation of this bugs but leads to a segfault and > a slightly different valgrind output This test works for me with gfortran as of this morning and also with gfortran r12505 (on x86_64-unknown-linux-gnu, no valgrind error). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug bootstrap/31039] [4.3 Regression] Latest CVS-stage 2-Cannot create executables
--- Comment #9 from rob1weld at aol dot com 2007-05-29 18:21 --- Created an attachment (id=13629) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13629&action=view) Fix Cygwin __sgetc_r bug with GCC 4.3.0 The information above is for patching the _source_ tree. If you obtained Cygwin gcc 3.4.4 by using the setup.exe program, the included /usr/include/stdio.h can not be used to bootstrap GCC 4.3.0. This patch is for Cygwin's /usr/include/stdio.h - it is NOT for patching GCC. It is slightly different from what is suggested for patching the _source_ ONLY in that this patch does not cause offset warning messages - otherwise it is equal (plus a few comments). It was derived from the two patches listed at: http://sourceware.org/ml/newlib/2007/msg00296.html and http://sourceware.org/ml/newlib/2007/msg00326.html combined together and applied to the "setup.exe"'s version version of /usr/include/stdio.h . It has been tested on Cygwin with GCC 4.3.0 revision 125164 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug middle-end/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 18:26 --- Plus forwprop only does: D.1046_37 = &(*__result.0_23)[0]; D.1048_41 = (char *) _s1_2(D); D.1049_42 = D.1046_37 + D.1048_41; Into: D.1046_37 = &(*__result.0_23)[0]; ... D.1048_41 = (char *) _s1_2(D); D.1049_42 = &(*__result.0_23)[_s1_2(D)]; Which is not wrong. I wonder if my patch at: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01769.html Fixes the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32137] [4.3] func_result_3.f90 ICEs on powerpc-apple
--- Comment #5 from brooks at gcc dot gnu dot org 2007-05-29 18:45 --- As of SVN 125160, this is working again. Weird, indeed. I guess I'll close it as a chimera. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
[Bug java/32098] New libtool doesn't support libjava
-- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-29 18:53:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32098
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
--- Comment #5 from jdgressett at amli-denton dot com 2007-05-29 18:59 --- (In reply to comment #4) > Now ACATS c380004 passes in gcc-4.3-20070518. > But it is still in the relesed 4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug tree-optimization/32144] New: [pointer_plus] Ice in chrec_fold_plus_poly_poly, at tree-chrec.c:110
Hello, I get an ICE when compiling linux-2.6.20 with a host-gcc from today's pointer_plus branch. gcc -m32 -Wp,-MD,fs/hfs/.extent.o.d -nostdinc -isystem /home/mstein/host-gcc/pointer_plus-2007-05-29/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -pipe -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -Iinclude/asm-i386/mach-default -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(extent)" -D"KBUILD_MODNAME=KBUILD_STR(hfs)" -c -o fs/hfs/.tmp_extent.o fs/hfs/extent.c fs/hfs/extent.c: In function 'hfs_free_fork': fs/hfs/extent.c:273: internal compiler error: in chrec_fold_plus_poly_poly, at tree-chrec.c:110 -- Summary: [pointer_plus] Ice in chrec_fold_plus_poly_poly, at tree-chrec.c:110 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC host triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32144
[Bug tree-optimization/32144] [pointer_plus] Ice in chrec_fold_plus_poly_poly, at tree-chrec.c:110
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-29 19:11 --- Created an attachment (id=13630) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13630&action=view) from linux-2.6.20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32144
[Bug tree-optimization/32144] [pointer_plus] Ice in chrec_fold_plus_poly_poly, at tree-chrec.c:110
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-29 19:15 --- I have a fix, just reducing the testcase right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-29 19:15:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32144
[Bug tree-optimization/32145] New: [pointer_plus] Ice in build2_stat, at tree.c:3074
Hello, I get an ICE when compiling linux-2.6.20 with a host-gcc from today's pointer_plus branch. gcc -m32 -Wp,-MD,fs/xfs/.xfs_dir2.o.d -nostdinc -isystem /home/mstein/host-gcc/pointer_plus-2007-05-29/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -pipe -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -Iinclude/asm-i386/mach-default -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -Ifs/xfs -Ifs/xfs/linux-2.6 -funsigned-char -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(xfs_dir2)" -D"KBUILD_MODNAME=KBUILD_STR(xfs)" -c -o fs/xfs/.tmp_xfs_dir2.o fs/xfs/xfs_dir2.c fs/xfs/xfs_dir2.c: In function 'xfs_dir2_grow_inode': fs/xfs/xfs_dir2.c:447: internal compiler error: in build2_stat, at tree.c:3074 -- Summary: [pointer_plus] Ice in build2_stat, at tree.c:3074 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC host triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32145
[Bug tree-optimization/32145] [pointer_plus] Ice in build2_stat, at tree.c:3074
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-29 19:37 --- Created an attachment (id=13631) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13631&action=view) from linux-2.6.20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32145
[Bug tree-optimization/32144] [pointer_plus] Ice in chrec_fold_plus_poly_poly, at tree-chrec.c:110
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 19:37 ---
Reduced testcase:
typedef unsigned short __u16;
typedef unsigned int u32;
typedef __u16 __be16;
struct hfs_extent {
__be16 count;
};
int hfs_free_fork( int type)
{
u32 total_blocks, blocks, start;
struct hfs_extent *extent;
int res, i;
for (i = 0; i < 3; extent++, i++)
blocks += __fswab16((( __u16)(__be16)(extent[i].count)));
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|i686-gnu-linux |
GCC target triplet||i686-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32144
[Bug tree-optimization/32144] [pointer_plus] Ice in chrec_fold_plus_poly_poly, at tree-chrec.c:110
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-29 19:40 --- The fix: Index: ../../gcc/tree-chrec.c === --- ../../gcc/tree-chrec.c (revision 125151) +++ ../../gcc/tree-chrec.c (working copy) @@ -107,7 +107,10 @@ chrec_fold_plus_poly_poly (enum tree_cod gcc_assert (poly1); gcc_assert (TREE_CODE (poly0) == POLYNOMIAL_CHREC); gcc_assert (TREE_CODE (poly1) == POLYNOMIAL_CHREC); - gcc_assert (chrec_type (poly0) == chrec_type (poly1)); + if (POINTER_TYPE_P (chrec_type (poly0))) +gcc_assert (chrec_type (poly1) == sizetype); + else +gcc_assert (chrec_type (poly0) == chrec_type (poly1)); gcc_assert (type == chrec_type (poly0)); /* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32144
[Bug tree-optimization/32145] [pointer_plus] Ice in build2_stat, at tree.c:3074
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-29 19:49 --- I have a fix, just getting a reduced testcase (the ICE comes from VRP). The fix is: Index: ../../gcc/tree-vrp.c === --- ../../gcc/tree-vrp.c(revision 125036) +++ ../../gcc/tree-vrp.c(working copy) @@ -1482,10 +1482,14 @@ extract_range_from_assert (value_range_t } max = negative_overflow_infinity (TREE_TYPE (var_vr->min)); } - else + else if (!POINTER_TYPE_P (TREE_TYPE (var_vr->min))) max = fold_build2 (MINUS_EXPR, TREE_TYPE (var_vr->min), anti_min, build_int_cst (TREE_TYPE (var_vr->min), 1)); + else + max = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (var_vr->min), + anti_min, + size_int (-1)); min = real_min; set_value_range (vr_p, VR_RANGE, min, max, vr_p->equiv); } -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC host triplet|i686-gnu-linux | GCC target triplet||i686-gnu-linux Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-05-29 19:49:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32145
[Bug fortran/32136] ICE with transfer in gfc_conv_array_initializer
--- Comment #1 from pault at gcc dot gnu dot org 2007-05-29 20:01 --- I don't hit an ICE (Cygwin/amd64) but see a wrong result. It works fine with anything other than logical, as long as the SIZE parameter is set to ensure that truncation of the source data does not occur. Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-29 20:01:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32136
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-29 20:25 --- Following the Steve Kargl's suggestion in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01945.html I have done the following test: [archimede] test/fortran> cat > sec_prec_1.f90 implicit none integer j, k, l, m, n integer i, ifa, ifb, ifc real a, b, c i = 0 ; ifa = 0 ; ifb = 0 ; ifc = 0 do m = 0, 23 do l = 0, 59 do k = 0, 59 do j = 0, 999 i = i + 1 a = 3600.0*real(m)+ 60.0*real(l) + real(k) + 0.001*real(j) b = 0.001*real(j) + real(k) + 60.0*real(l) + 3600.0*real(m) c = (360*m + 6*l + 1000*k + j)/1000.0 if (b /= c) ifa = ifa + 1 if (a /= c) ifb = ifb + 1 if (a /= b) ifc = ifc + 1 end do end do end do end do print *, i, ifa, ifb, ifc end On PPC OSX and AMD64 Linux (with and without -O), I get: 86401931201617523130 2683738 It seems hard to decide what is the right solution, expect that the same has to be used in the test cases. On a Pentium Linux, I get the same result if I use -ffloat-store. Without this flag I get: 864019341934 0 without -O and 86408631360086313600 0 with -O. Since I understand that in the later cases, the right hand side is computed as real(10), hence a and b are the same after rounding to real(4). However I don't see why the optimization has such a dramatic effect. I have also run the following test: [archimede] test/fortran> cat > sec_prec.f90 integer i, j, k, l, m, n real a, b, c k = 59 l = 59 m = 23 do i = 0, 9 a = 86399.0 + 0.001*real(990+i) b = 0.001*real(990+i) + real(k) + 60.0*real(l) + 3600.0*real(m) c = (8630 + i)/1000.0 print '(I3,3(1PG20.10))', i, a, b, c end do end which gives: 0 86399.99219 86399.99219 86399.99219 1 86399.99219 86399.99219 86399.99219 2 86399.99219 86399.99219 86399.99219 3 86399.99219 86399.99219 86399.99219 4 86399.99219 86399.99219 86399.99219 5 86399.99219 86399.99219 86399.99219 6 86399.99219 86400.0 86400.0 7 86400.0 86400.0 86400.0 8 86400.0 86400.0 86400.0 9 86400.0 86400.0 86400.0 i.e., the last 3/4 ms gives 86400.0, hence the result of secnds(0.0) is inside the interval [0.0,86400.0] and not inside [0.0,86400.0[ as I naively expected. This is the cryptic point (2) in my comment #1. A side effect is that if your are within this time frame and do t1=secnds(0.0); t2=secnds(t1) you get 86400.0 instead of 0.0. A possible solution is to add a t1=min(86399.996,t1) to force the output in the semiopen interval. With the reversal of the time computation and putting everything in float, it leads to the following patch: --- gcc-4.3-20070525/libgfortran/intrinsics/date_and_time.c Fri Apr 6 18:47:23 2007 +++ gcc-4.3-20070526/libgfortran/intrinsics/date_and_time.c Mon May 28 21:40:46 2007 @@ -341,12 +341,15 @@ free_mem (avalues); - temp1 = 3600.0 * (GFC_REAL_4)values[4] + - 60.0 * (GFC_REAL_4)values[5] + - (GFC_REAL_4)values[6] + - 0.001 * (GFC_REAL_4)values[7]; - temp2 = fmod (*x, 86400.0); - temp2 = (temp1 - temp2 >= 0.0) ? temp2 : (temp2 - 86400.0); + temp1 = 0.001f * (GFC_REAL_4)values[7] + + (GFC_REAL_4)values[6] + + 60.0f * (GFC_REAL_4)values[5] + + 3600.0f * (GFC_REAL_4)values[4]; + + /* Fix the round-off errors for the 3ms before midnight. */ + temp1= (86399.996f>=temp1)? temp1 : 86399.996f; + temp2 = fmod (*x, 86400.0f); + temp2 = (temp1 - temp2 >= 0.0f) ? temp2 : (temp2 - 86400.0f); return temp1 - temp2; } I have implemented part of it (without the reversal for temp1) on my last build on OSX and it seems to work. For the other platforms I rely on binaries, so I need some outside help to test the patch on them!-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug fortran/28484] system_clock with real-type count_rate does not compile
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-05-29 20:44 --- Taking over. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-22 16:16:25 |2007-05-29 20:44:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug tree-optimization/32145] [pointer_plus] Ice in build2_stat, at tree.c:3074
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 21:04 ---
And here is a reduced testcase:
void xfs_dir2_grow_inode(void)
{
int map;
int *mapp;
int nmap;
mapp = ↦
if (nmap == 0 )
mapp = ((void *)0);
if (mapp != &map)
kmem_free(mapp);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32145
[Bug c++/32142] gcc crashes when creating coverage info and optimization
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-29 21:12 --- This works for me in the 4.2 release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32142
[Bug c++/32142] gcc crashes when creating coverage info and optimization
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 21:14 --- But fails on the 4.1 branch. The ICE is in GC related code (inside GCC). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||GC, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32142
[Bug tree-optimization/32146] New: Bad matrix layout transformations
I got /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/ /export/gnu/src/gcc-dfp/gcc/gcc/testsuite/gcc.dg/matrix/matrix-6.c -O3 -fipa-matrix-reorg -fdump-ipa-matrix-reorg -fwhole-program -combine -fno-show-column -S -o matrix-6.s(timeout = 300) /export/gnu/src/gcc-dfp/gcc/gcc/testsuite/gcc.dg/matrix/matrix-6.c: In function 'mem_init':^M /export/gnu/src/gcc-dfp/gcc/gcc/testsuite/gcc.dg/matrix/matrix-6.c:92: warning: cast to pointer from integer of different size^M output is: /export/gnu/src/gcc-dfp/gcc/gcc/testsuite/gcc.dg/matrix/matrix-6.c: In function 'mem_init':^M /export/gnu/src/gcc-dfp/gcc/gcc/testsuite/gcc.dg/matrix/matrix-6.c:92: warning: cast to pointer from integer of different size^M FAIL: gcc.dg/matrix/matrix-6.c (test for excess errors) Excess errors: /export/gnu/src/gcc-dfp/gcc/gcc/testsuite/gcc.dg/matrix/matrix-6.c:92: warning: cast to pointer from integer of different size *** glibc detected *** /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/testsuite/gcc/transpose-1.x02: free(): invalid next size (normal): 0x00601010 *** === Backtrace: = /lib64/libc.so.6[0x335a26ea30] /lib64/libc.so.6(cfree+0x8c)[0x335a27214c] /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/testsuite/gcc/transpose-1.x02[0x400a54] /lib64/libc.so.6(__libc_start_main+0xf4)[0x335a21da44] /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/testsuite/gcc/transpose-1.x02[0x400699] === Memory map: 0040-00401000 r-xp 08:11 17762580 /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/testsuite/gcc/transpose-1.x02 0060-00601000 rw-p 08:11 17762580 /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/testsuite/gcc/transpose-1.x02 00601000-00622000 rw-p 00601000 00:00 0 [heap] 3359e0-3359e1a000 r-xp 08:06 13880069 /lib64/ld-2.5.so 335a019000-335a01a000 r--p 00019000 08:06 13880069 /lib64/ld-2.5.so 335a01a000-335a01b000 rw-p 0001a000 08:06 13880069 /lib64/ld-2.5.so 335a20-335a344000 r-xp 08:06 13880090 /lib64/libc-2.5.so 335a344000-335a544000 ---p 00144000 08:06 13880090 /lib64/libc-2.5.so 335a544000-335a548000 r--p 00144000 08:06 13880090 /lib64/libc-2.5.so 335a548000-335a549000 rw-p 00148000 08:06 13880090 /lib64/libc-2.5.so 335a549000-335a54e000 rw-p 335a549000 00:00 0 335a60-335a682000 r-xp 08:06 13880345 /lib64/libm-2.5.so 335a682000-335a881000 ---p 00082000 08:06 13880345 /lib64/libm-2.5.so 335a881000-335a882000 r--p 00081000 08:06 13880345 /lib64/libm-2.5.so 335a882000-335a883000 rw-p 00082000 08:06 13880345 /lib64/libm-2.5.so 2aaab000-2aaae000 rw-p 2aaab000 00:00 0 2aac6000-2aac8000 rw-p 2aac6000 00:00 0 2aac8000-2aadb000 r-xp 08:11 17729566 /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/libgcc_s.so.1 2aadb000-2acda000 ---p 00013000 08:11 17729566 /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/libgcc_s.so.1 2acda000-2acdb000 rw-p 00012000 08:11 17729566 /export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/libgcc_s.so.1 2c00-2c021000 rw-p 2c00 00:00 0 2c021000-2aaab000 ---p 2c021000 00:00 0 7fffc2229000-7fffc2241000 rw-p 7fffc2229000 00:00 0 [stack] ff60-ff601000 r-xp 00:00 0 [vdso] FAIL: gcc.dg/matrix/transpose-1.c execution,-fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program -combine -- Summary: Bad matrix layout transformations Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32146
[Bug tree-optimization/32146] Bad matrix layout transformations
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-29 21:29 --- I get the same failure on powerpc64-linux-gnu. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu, ||powerpc64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32146
[Bug c++/31923] g++ accepts a storage-class-specifier on a template explicit specialization
--- Comment #1 from patchapp at dberlin dot org 2007-05-29 22:54 --- Subject: Bug number PR c++/31923 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-05/msg02033.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug tree-optimization/31756] Doesn't optimize the following (obvious) sequence
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 23:22 --- I am wrong since this is a loop linear issue: Won't transform loop. Optimal transform is the identity transform -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|32075 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31756
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #18 from rob1weld at aol dot com 2007-05-29 23:47 --- I un-did all _my_ work and re-got the SVN to check that it builds - it doesn't. Here is proof and result: # cd /root/downloads/gcc-4_3-trunk # cat LAST_UPDATED Tue May 29 15:18:17 UTC 2007 (revision 125164) # svn di -r 125164 (Prints NOTHING) # gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-examples --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-haifa --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.3.0 20070529 (experimental) # cd /opt/gcc-4_3-build # make ...(Many Many lines) make[3]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava' make create-headers make[4]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava' echo > gcjh.stamp make[4]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava' depbase=`echo jni-libjvm.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \ if /bin/sh ./libtool --tag=CXX --mode=compile /opt/gcc-4_3-build/./gcc/xgcc -o jni-libjvm.lo /root/downloads/gcc-4_3-trunk/libjava/jni-libjvm.cc; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi libtool: compile: /opt/gcc-4_3-build/./gcc/xgcc -c /root/downloads/gcc-4_3-trunk/libjava/jni-libjvm.cc -fPIC -DPIC -o .libs/jni-libjvm.o libtool: compile: /opt/gcc-4_3-build/./gcc/xgcc -c /root/downloads/gcc-4_3-trunk/libjava/jni-libjvm.cc -o jni-libjvm.o >/dev/null 2>&1 ...(Many lines) if /bin/sh ./libtool --tag=CXX --mode=compile /opt/gcc-4_3-build/./gcc/xgcc -o posix-threads.lo /root/downloads/gcc-4_3-trunk/libjava/posix-threads.cc; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi libtool: compile: /opt/gcc-4_3-build/./gcc/xgcc -c /root/downloads/gcc-4_3-trunk/libjava/posix-threads.cc -fPIC -DPIC -o .libs/posix-threads.o libtool: compile: /opt/gcc-4_3-build/./gcc/xgcc -c /root/downloads/gcc-4_3-trunk/libjava/posix-threads.cc -o posix-threads.o >/dev/null 2>&1 here=`pwd`; cd /root/downloads/gcc-4_3-trunk/libjava/classpath/lib; \ find gnu java javax org sun -name .svn -prune -o -name '*.class' -print | \ jar -cfM@ $here/libgcj-4.3.0.jar Note the above section uses "./libtool --tag=CXX --mode=compile" and works fine. Note the next section uses "./libtool --tag=GCJ --mode=compile" and fails after a few files. /bin/sh ./libtool --tag=GCJ --mode=compile /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Object.class libtool: compile: /opt/gcc-4_3-build/gcc/gcj /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Object.class libtool: compile: mv -f "Object.o" "java/lang/.libs/Object.o" libtool: compile: /opt/gcc-4_3-build/gcc/gcj /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Object.class >/dev/null 2>&1 libtool: compile: mv -f "Object.o" "java/lang/Object.o" /bin/sh ./libtool --tag=GCJ --mode=compile /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Class.class libtool: compile: /opt/gcc-4_3-build/gcc/gcj /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Class.class libtool: compile: mv -f "Class.o" "java/lang/.libs/Class.o" libtool: compile: /opt/gcc-4_3-build/gcc/gcj /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Class.class >/dev/null 2>&1 libtool: compile: mv -f "Class.o" "java/lang/Class.o" echo /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/PosixProcess*.class > java/process-Posix.list /bin/sh ./libtool --tag=GCJ --mode=compile ... java/process-Posix.deps @java/process-Posix.list libtool: compile: /opt/gcc-4_3-build/gcc/gcj java/process-Posix.deps @java/p
[Bug fortran/32147] New: Module files change due to rivial changes in source code
With different versions of gfortran, I find that the .mod files often change even if I just added a debugging print statement somewhere in a subroutine -- i.e. even when the interface to the module (that the .mod file is supposed to represent) has not changed. I attach a test file and a Makefile that returns something like `Found 34 differences', but should just find ~2 differences due to differing time stamp and MD5 sum. I find this e.g. with (the 64-bit version of) GNU Fortran (GCC) 4.3.0 20070501 (experimental) [SVN version], but also with GNU Fortran 95 (GCC) 4.1.2 (Gentoo 4.1.2). W o l f g a n g PS: The same probem occurred with g95, but is fixed now. PPS: Rationale: I have a tool that backdates .f90 and .o files after compilation if the module file has not changed. This avoids the `recompilation cascade', but can only work if the .mod files don't change spuriously. -- Summary: Module files change due to rivial changes in source code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wdobler at ucalgary dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32147
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-30 00:07 --- Subject: Re: Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory" > libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o" > mv: cannot stat `process-Posix.o': No such file or directory Had a similar error on hppa-unknown-linux-gnu in last night's build but for a different file. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug fortran/32147] Module files change due to trivial changes in source code
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-30 00:07 --- This should have been fixed with PR 31587 which was fixed on 2007-04-24. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32147
[Bug fortran/32147] Module files change due to trivial changes in source code
--- Comment #2 from wdobler at ucalgary dot ca 2007-05-30 00:08 --- Created an attachment (id=13632) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13632&action=view) .tgz archive -- unpack, cd, run `make' tar xzf gfortran-mod-irreproducibility.tgz cd gfortran-mod-irreproducibility vi Makefile # set FC to `grfortran' or whatever make -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32147
[Bug fortran/32147] Module files change due to trivial changes in source code
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-30 00:11 --- This works for me with: gcc version 4.3.0 20070529 (experimental) I tested it by using a function in a module which takes one variable and returns that argument. I had accidently switched around the assignment and I fixed that and looked at the modification date of the module and they were the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32147
[Bug fortran/32147] Module files change due to trivial changes in source code
--- Comment #4 from wdobler at ucalgary dot ca 2007-05-30 00:15 --- (In reply to comment #1) > This should have been fixed with PR 31587 which was fixed on 2007-04-24. You are way too fast for me :-). My SVN version must be (slightly) more recent than 2007-05-01, so I doubt this is fixed. I'll try to install the latest SVN version, just to be sure. (In reply to comment #3) > This works for me with: > gcc version 4.3.0 20070529 (experimental) > > I tested it by using a function in a module which takes one variable and > returns that argument. I had accidently switched around the assignment and I > fixed that and looked at the modification date of the module and they were the > same. I am not claiming that the .mod file is _always_ different. Could you try my test? W o l f g a n g -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32147
[Bug fortran/32147] Module file change due to order of writting out changes
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-30 00:24 --- So what is happening here is the order changes. Now I don't have enough experence in the module writting code to understand why this changes. Note also your testcase is not correct because there will be at least two differences always (the filename changes and the date). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Module files change due to |Module file change due to |trivial changes in source |order of writting out |code|changes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32147
[Bug fortran/32147] Module file change due to order of writting out changes
--- Comment #6 from wdobler at ucalgary dot ca 2007-05-30 00:31 --- (In reply to comment #5) > Note also your test case is not correct because there will be at least two > differences always (the filename changes and the date). Sure, but that is documented in the README. And I just didn't bother to do arithmetics in Bash that is easier done in your head. If this is an issue, let me know and I'll improve it. So currently the diagnostic is: - `Found 2 differences' is OK. - `Found 36 differences' is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32147
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #20 from hjl at lucon dot org 2007-05-30 00:46 --- Fixed. We will need to fix PR 32098 for libjava. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #7 from hjl at lucon dot org 2007-05-30 00:51 --- It doesn't work on Linux/x86: FAIL: gfortran.dg/allocate_stat_1.f90 -O0 execution test FAIL: gfortran.dg/allocate_stat_1.f90 -O1 execution test FAIL: gfortran.dg/allocate_stat_1.f90 -O2 execution test FAIL: gfortran.dg/allocate_stat_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/allocate_stat_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/allocate_stat_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/allocate_stat_1.f90 -O3 -g execution test FAIL: gfortran.dg/allocate_stat_1.f90 -Os execution test -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug fortran/32148] New: FAIL: gfortran.dg/sizeof.f90 -O0 (internal compiler error)
I got Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/sizeof.f90 -O0 -pedantic-errors -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/./libgfortran/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/./libgfortran/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/./libiberty -lm -o ./sizeof.exe(timeout = 300) /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/sizeof.f90: In function 'check_int':^M /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/sizeof.f90:3: internal compiler error: in copy_to_mode_reg, at explow.c:645^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M compiler exited with status 1 -- Summary: FAIL: gfortran.dg/sizeof.f90 -O0 (internal compiler error) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32148
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-30 00:54 --- (In reply to comment #7) > It doesn't work on Linux/x86: It also fails on powerpc-linux (32bits). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug fortran/32103] Module with equivalence draws "unsatisfied reference"
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2007-05-30 01:18 --- Subject: Re: Module with equivalence draws "unsatisfied reference" pault at gcc dot gnu dot org wrote: > --- Comment #4 from pault at gcc dot gnu dot org 2007-05-29 10:39 --- > The patch below works and regtests OK. I am trying to devise a safe method of > gettting rid of the redundant symbols if none of the equivalence members is > USEd. If I cannot see something by tonight, I will submit anyway. Yep - that worked. Thanks ! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32103
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-30 02:09 --- I would like to do a couple of tests here, Then I will "oversee" this patch. -- 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|NEW |ASSIGNED Last reconfirmed|2007-05-28 22:15:12 |2007-05-30 02:09:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug other/32149] New: libdecnumber is configured wrong for i686-pc-cygwin see comparison with i686-pc-linux-gnu
$ gcc/xgcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: /cygdrive/C/makecygwin/gcc-4_3-trunk/configure --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/4.3 --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree Thread model: single (NOTE: this should be posix (by default), even for WinXP) gcc version 4.3.0 20070528 (experimental) # gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-examples --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-haifa --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.3.0 20070529 (experimental) Here is i686-pc-cygwin: # ls -lrtA /cygdrive/c/gcc-4_3-trunk-build/libdecnumber total 485 -rw-r--r-- 1 HP_Administrator None 4153 May 29 00:19 config.cache -rwxr-xr-x 1 HP_Administrator None 43709 May 29 00:19 config.status -rw-r--r-- 1 HP_Administrator None 5446 May 29 00:19 Makefile -rw-r--r-- 1 HP_Administrator None 2386 May 29 00:19 config.h -rw-r--r-- 1 HP_Administrator None 10 May 29 00:19 stamp-h1 -rw-r--r-- 1 HP_Administrator None872 May 29 00:19 gstdint.h -rw-r--r-- 1 HP_Administrator None 32251 May 29 00:19 config.log -rw-r--r-- 1 HP_Administrator None 86065 May 29 00:19 decNumber.o -rw-r--r-- 1 HP_Administrator None 18675 May 29 00:19 decContext.o -rw-r--r-- 1 HP_Administrator None 20262 May 29 00:19 decUtility.o -rw-r--r-- 1 HP_Administrator None 20508 May 29 00:19 decimal32.o -rw-r--r-- 1 HP_Administrator None 20640 May 29 00:19 decimal64.o -rw-r--r-- 1 HP_Administrator None 20657 May 29 00:19 decimal128.o -rw-r--r-- 1 HP_Administrator None 188416 May 29 00:19 libdecnumber.a Here is i686-pc-linux-gnu: # ls -lrtA /opt/gcc-4_3-build/libdecnumber/ total 606 -rw-r--r-- 1 root root 4087 May 29 13:53 config.cache -rw-r--r-- 1 root root 10 May 29 13:53 stamp-h1 -rw-r--r-- 1 root root872 May 29 13:53 gstdint.h -rwxr-xr-x 1 root root 45795 May 29 13:53 config.status -rw-r--r-- 1 root root 2386 May 29 13:53 config.h -rw-r--r-- 1 root root 5390 May 29 13:53 Makefile -rw-r--r-- 1 root root 31474 May 29 13:53 config.log -rw-r--r-- 1 root root 74764 May 29 13:53 decNumber.o -rw-r--r-- 1 root root 6628 May 29 13:53 decContext.o -rw-r--r-- 1 root root 12408 May 29 13:53 decimal32.o -rw-r--r-- 1 root root 11668 May 29 13:53 decUtility.o -rw-r--r-- 1 root root 12592 May 29 13:53 decimal64.o -rw-r--r-- 1 root root 12776 May 29 13:53 decimal128.o -rw-r--r-- 1 root root 257208 May 29 13:53 libdecnumber.a -rw-r--r-- 1 root root 5012 May 29 13:53 host-ieee64.o -rw-r--r-- 1 root root 5004 May 29 13:53 host-ieee32.o -rw-r--r-- 1 root root 5148 May 29 13:53 host-ieee128.o -rw-r--r-- 1 root root 108744 May 29 13:53 bid2dpd_dpd2bid.o Here are some hand-edited diffs. Obviously these files will have some differences since the directories are not the same, I have edited these out and left only what seems to be suspicious differences. Here is an example of the "type" of stuff I hand edited out: -ac_cv_env_CC_value=' /cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/xgcc -B/cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/' +ac_cv_env_CC_value=' /opt/gcc-4_3-build/./prev-gcc/xgcc -B/opt/gcc-4_3-build/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/' -ac_cv_env_build_alias_value=i686-pc-cygwin +ac_cv_env_build_alias_value=i686-pc-linux-gnu I edited out that "sort-of-thing" out, but left the rest. Type this in Linux (with WinXP drive mounted on /mnt/windows/) (few can do this): # diff -u /mnt/windows/gcc-4_3-trunk-build/libdecnumber/config.cache /opt/gcc-4_3-build/libdecnumber/config.cache --- /mnt/windows/gcc-4_3-trunk-build/libdecnumber/config.cache 2007-05-29 00:19:2
[Bug java/32098] New libtool doesn't support libjava
--- Comment #4 from rob1weld at aol dot com 2007-05-30 03:30 --- Note to people other than [EMAIL PROTECTED] (who is aware of this), see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078 After configuring, libtool-1.5.22 's libtool works great when simply copied into gcc-4_3-build/i686-pc-linux-gnu/libjava; of course it would be proper to use ltmain.sh and let gcc's configure do the work. I tried adding libtool-1.5.22 to _all_ of GCC 4.3.0 the _correct_ way but it breaks in other directories without some fixing. It works fine in the libjava directory without _any_ "fixing". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32098
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #21 from rob1weld at aol dot com 2007-05-30 03:34 --- Dave, it depends on the options used to configure Java, which files would be compiled and where the breakage occurs. [EMAIL PROTECTED] says it is being fixed. If you can't wait then wget libtool as explained above, configure it, and drop it in hppa-unknown-linux-gnu/libjava. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-30 03:37 --- I modified the program given in comment #4 to display the exact values at the end of the cycle along with the three methods. Method "a" and method "c" give identical results. Method "b" has a different phase and its the end point sooner. The exact true value is shown in the fourth column of the output below. -- snippet -- a = 3600.0*real(m)+ 60.0*real(l) + real(k) + 0.001*real(j) b = 0.001*real(j) + real(k) + 60.0*real(l) + 3600.0*real(m) c = real(3600*m + 60*l + k) c = c + real(j)/1000.0 exact1 = 3600*m + 60*l + k exact2 = j write(6,100)a, b, c, exact1, exact2 100 format (3(f11.5,2x),i5,".",i3) Result: 86399.98438 86399.98438 86399.98438 86399.988 86399.99219 86399.99219 86399.99219 86399.989 86399.99219 86399.99219 86399.99219 86399.990 86399.99219 86399.99219 86399.99219 86399.991 86399.99219 86399.99219 86399.99219 86399.992 86399.99219 86399.99219 86399.99219 86399.993 86399.99219 86399.99219 86399.99219 86399.994 86399.99219 86399.99219 86399.99219 86399.995 86399.99219 86400.0 86399.99219 86399.996 86400.0 86400.0 86400.0 86399.997 86400.0 86400.0 86400.0 86399.998 86400.0 86400.0 86400.0 86399.999 a and c are actually a little more accurate at the end. Its also interesting that this deviation between the methods appears to happen only near the end of the sequence. I have visually scanned in quite a few places and all three are identical until this point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug other/32149] libdecnumber is configured wrong for i686-pc-cygwin see comparison with i686-pc-linux-gnu
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-30 04:04 --- Well for one, there is no defined ABI for DFP on cygwin so the differences are because the ABI is different. There is no problem with cygwin being different from linux with respect of dec float. In fact this is normal for OS's to have different ABIs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords|accepts-invalid, compile- | |time-hog| Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32149
[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap
--- Comment #16 from daney at gcc dot gnu dot org 2007-05-30 04:21 --- Subject: Bug 31975 Author: daney Date: Wed May 30 04:21:24 2007 New Revision: 125178 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125178 Log: PR gcc/31975 * config/mips/mips.c (mips_output_mi_thunk): Emit NOTE_INSN_PROLOGUE_END at beginning of the thunk. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap
--- Comment #17 from daney at gcc dot gnu dot org 2007-05-30 04:38 --- Fix committed to the trunk. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
[Bug target/27387] Thumb thunk is not PIC
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-30 05:03 --- (In reply to comment #5) > Just checked in a patch. This testcase does not work as you put it into the C testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27387
