[Bug libf2c/27751] New: install-sh not found while "make install" for lib2fc
When running make install for gcc 3.4.6 on solaris 2.10 it complains about a trivial "install-sh" not found in /sparc-sun-solaris2.10 The bug is trivial since it refers a full PATH for "install-sh" starting (relatively) from libf2c (/libf2c/../install-sh There is no install-sh there ! The path has to be corrected (in the Makefile) or a symbolic link has to be added in the sparc-sun-solaris2.10 directory (up to "../install-sh") I hope it will help -- Summary: install-sh not found while "make install" for lib2fc Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libf2c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manuel dot bettini at airbus dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27751
[Bug libf2c/27751] install-sh not found while "make install" for lib2fc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-24 07:36 --- Three things: first you should not be configuring with an relative path (it is not that supported), that was PR 13993 which was fixed for 3.4.4. second, if you are building in the source directory, that is not supported either. Third, 3.4.6 was the last release of 3.4.x and libf2c was removed in 4.0.x so this is not a bug which can be fixed in any other release. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27751
[Bug libf2c/27751] install-sh not found while "make install" for lib2fc
--- Comment #2 from manuel dot bettini at airbus dot com 2006-05-24 07:54 --- (In reply to comment #1) > Three things: >first you should not be configuring with an relative path (it is not that > supported), that was PR 13993 which was fixed for 3.4.4. First: this is not about configuring with a relative path. Configuring was correctly done with absolute path (I promisse) Second: that is not the same bug as the PR 13993 mentionned. Third: Even having configure with absolute PATH the generated Makefile for installing libf2c seems to be relative (on the contrary of other path in Makefiles) Then: it is not fixed in 3.4.6 (obviously since I got it ;-)) To be more clear see traces (for the error) below, when doing "make install" in the gcc-3.4.6 directory ../.././libf2c/../install-sh -c .libs/libg2c.so.0.0.0 /opt/install/gcc-3.4.6/lib/sparcv9/libg2c.so.0.0.0 ./libtool: ../.././libf2c/../install-sh: not found make[3]: *** [install] Error 1 make[3]: Leaving directory `/home/myaccount/gcc-3.4.6/sparc-sun-solaris2.10/sparcv9/libf2c' make[2]: *** [multi-do] Error 1 > second, if you are building in the source directory, that is not supported > either. I am building the normal way (I try) > Third, 3.4.6 was the last release of 3.4.x and libf2c was removed in 4.0.x > so Ok ! > this is not a bug which can be fixed in any other release. Sorry -- manuel dot bettini at airbus dot com changed: What|Removed |Added CC||manuel dot bettini at airbus ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27751
[Bug c/27752] New: Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so
All is in the title and in the error trace below ! ;-) When making gcc 4.1.0 on solaris 10: ... ld: warning: option -YP appears more than once, first setting taken ld: fatal: file /usr/ucblib/libucb.so: wrong ELF class: ELFCLASS32 ld: fatal: File processing errors. No output written to sparcv9/libgcc_s.so.1.tmp collect2: ld returned 1 exit status make[3]: *** [sparcv9/libgcc_s.so] Error 1 -- Summary: Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manuel dot bettini at airbus dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752
[Bug target/27752] Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-24 09:14 --- How did you configure? How did you invoke make? Do you have a 64bit userland? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752
[Bug libfortran/27524] -fbounds-check interracts *strangely* with an array of size 1
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-24 09:20
---
> function F()
> integer :: F(1)
> f = 1
> end function F
Compiling this simple function without and with -fbounds-check and dumping the
GIMPLE tree generated gives the following diff:
--- 003t.original.noboundscheck 2006-05-24 11:09:37.0 +0200
+++ 003t.original.boundscheck 2006-05-24 11:09:32.0 +0200
@@ -14,8 +14,16 @@ f (__result)
D.917 = __result->dim[0].stride;
stride.0 = D.917 == 0 ? 1 : D.917;
__result.0 = (int4[0:D.918] *) __result->data;
+if ((logical4) __builtin_expect (__result->dim[0].ubound !=
__result->dim[0].lbound, 0))
+ {
+_gfortran_runtime_error ("Array bound mismatch", "test.f90", 1);
+ }
+else
+ {
+(void) 0;
+ }
size.2 = NON_LVALUE_EXPR ;
-offset.1 = -stride.0;
+offset.1 = __result->dim[0].lbound - __result->dim[0].ubound;
D.918 = size.2 - 1;
D.919 = (bit_size_type) () size.2 *
I think the cuplrit here is gfc_trans_dummy_array_bias(), around line 3728
(where the offset is built), although I'm not skilled enough in all this to
understand how exactly to fix it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-05-19 16:59:16 |2006-05-24 09:20:48
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27524
[Bug target/27752] Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so
--- Comment #2 from manuel dot bettini at airbus dot com 2006-05-24 09:20 --- I have configured this way: just doing: configure --prefix=/somewhere (nothing else... thinking all is automatic) Then just trying to do a normal "make" (thinking most of the things are automatic) My machine is: SunOS lucius1 5.10 Generic_118822-26 sun4u sparc SUNW,Sun-Fire-480R -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752
[Bug target/27752] Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so
--- Comment #3 from manuel dot bettini at airbus dot com 2006-05-24 09:25 --- Subject: RE: Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so I have configured this way: just doing: configure --prefix=/somewhere (nothing else... thinking all is automatic) Then just trying to do a normal "make" (thinking most of the things are automatic) My machine is: SunOS lucius1 5.10 Generic_118822-26 sun4u sparc SUNW,Sun-Fire-480R Regards -Message d'origine- De : pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Envoyé : mercredi 24 mai 2006 11:15 À : BETTINI, Manuel Objet : [Bug target/27752] Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so --- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-24 09:14 --- How did you configure? How did you invoke make? Do you have a 64bit userland? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the recipient, for system management and security reasons. This access is controlled under Regulation of Investigatory Powers Act 2000, Lawful Business Practises. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752
[Bug target/27752] Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-24 09:26 --- try with --disable-multilib. I bet you don't have the 64bit userland installed. Please read: http://gcc.gnu.org/install/specific.html#x-x-solaris2 When configuring on a Solaris 7 or later system that is running a kernel that supports only 32-bit binaries, one must configure with --disable-multilib, since we will not be able to build the 64-bit target libraries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752
[Bug c++/27568] [4.0/4.1/4.2 Regression] ICE in check_classfn, at cp/decl2.c:607
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-24 09:30 --- The problem is in essence the same as in PR 20173, which was fixed on mainline by Mark. We now get a suitable error message instead of an ICE: bug.cc:20: error: template-id 'meth<>' for 'void bar::meth(foo&)' does not match any template declaration *** This bug has been marked as a duplicate of 20173 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27568
[Bug c++/20173] [4.0/4.1 regression] gcc accepts invalid partial specialization attempt of member function
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-05-24 09:30 --- *** Bug 27568 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||benoit dot sigoure at lrde ||dot epita dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
[Bug middle-end/27743] [4.1/4.2 Regression] Wrong code for ((unsigned) ((a) >> 2)) >> 15
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-24 09:44 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-23 14:17:09 |2006-05-24 09:44:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27743
[Bug c++/14494] Rejected valid specialization of member template
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-24 09:51 --- The case with A<0>::B() instead of A<0>::B() which was also rejected was fixed with Mark's patch for PR20173. The original testcase with A<0>::B() still fails, though. Mark, would you mind having a look at this one, too, as you were just working in that area? -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14494
[Bug rtl-optimization/27735] [4.2 Regression] ice with -O3 on legal code [unswitch]
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-05-24 09:54 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01229.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg01229.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27735
[Bug middle-end/27609] [4.2 Regression] FAIL: gcc.dg/torture/nested-fn-1.c -O0 scan-assembler-not should_not_appear
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-24 09:57 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27609
[Bug c++/27739] "expected primary-expression before double" error caused by simple varaible name
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 10:03 --- Also there is a bug about reporting or as the keyword instead of `||'. If you read the documention, you will also notice there an option to turn off these keywords. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27739
[Bug rtl-optimization/27735] [4.2 Regression] ice with -O3 on legal code [unswitch]
--- Comment #5 from patchapp at dberlin dot org 2006-05-24 10:10 --- Subject: Bug number PR 27735 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/2006-05/msg01229.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27735
[Bug tree-optimization/27753] New: ICE in make_ssa_name on autovect-branch
/usr/local/vect/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-vect/configure --enable-languages=c,c++
--prefix=/usr/local/vect
Thread model: posix
gcc version 4.2.0-autovect 20060518 (experimental)
Reduced testcase below ICEs:
/usr/local/vect/bin/g++ -O3 -ftree-vectorize -march=pentium-m -c vecreduced.cpp
vecreduced.cpp: In member function vector& vector::add(T) [with T =
ppoint]:
vecreduced.cpp:14: internal compiler error: in make_ssa_name, at
tree-ssanames.c:129
template
struct ppoint {
int x, y;
inline ppoint& operator+=(const ppoint& p) {
x+=p.x;
y+=p.y;
return *this;
}
};
template
class vector {
public:
vector& add(T cst) {
for (int i=0; i >;
--
Summary: ICE in make_ssa_name on autovect-branch
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at pdoerfler dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27753
[Bug tree-optimization/27753] ICE in make_ssa_name on autovect-branch
--- Comment #1 from gcc at pdoerfler dot com 2006-05-24 11:41 ---
This is probably related to or a duplicate of PR26362.
Anyways, this is now a C++ testcase instead of fortran.
The patch by rth posted in that PR makes the ICE go away.
Here is an updated version that applies cleanly:
Index: targhooks.c
===
--- targhooks.c (revision 114040)
+++ targhooks.c (working copy)
@@ -455,7 +455,8 @@
tree type;
enum machine_mode mode;
block_stmt_iterator bsi;
- tree th, tl, result, x;
+ tree t1, t2, x;
+ int i, n;
/* If the first argument is a type, just check if support
is available. Return a non NULL value if supported, NULL_TREE otherwise.
@@ -479,31 +480,36 @@
return NULL;
bsi = bsi_for_stmt (stmt);
-
- th = make_rename_temp (type, NULL);
- x = build2 (VEC_INTERLEAVE_HIGH_EXPR, type, vec1, vec2);
- x = build2 (MODIFY_EXPR, type, th, x);
- th = make_ssa_name (th, x);
- TREE_OPERAND (x, 0) = th;
- bsi_insert_before (&bsi, x, BSI_SAME_STMT);
+ n = exact_log2 (GET_MODE_NUNITS (mode)) - 1;
+ for (i = 0; i < n; ++i)
+{
+ t1 = create_tmp_var (type, NULL);
+ add_referenced_tmp_var (t1);
+ x = build2 (VEC_INTERLEAVE_HIGH_EXPR, type, vec1, vec2);
+ x = build2 (MODIFY_EXPR, type, t1, x);
+ t1 = make_ssa_name (t1, x);
+ TREE_OPERAND (x, 0) = t1;
+ bsi_insert_before (&bsi, x, BSI_SAME_STMT);
- tl = make_rename_temp (type, NULL);
- x = build2 (VEC_INTERLEAVE_LOW_EXPR, type, vec1, vec2);
- x = build2 (MODIFY_EXPR, type, tl, x);
- tl = make_ssa_name (tl, x);
- TREE_OPERAND (x, 0) = tl;
- bsi_insert_before (&bsi, x, BSI_SAME_STMT);
+ t2 = create_tmp_var (type, NULL);
+ add_referenced_tmp_var (t2);
+ x = build2 (VEC_INTERLEAVE_LOW_EXPR, type, vec1, vec2);
+ x = build2 (MODIFY_EXPR, type, t2, x);
+ t2 = make_ssa_name (t2, x);
+ TREE_OPERAND (x, 0) = t2;
+ bsi_insert_before (&bsi, x, BSI_SAME_STMT);
- result = make_rename_temp (type, NULL);
- /* ??? Endianness issues? */
+ if (BYTES_BIG_ENDIAN)
+vec1 = t1, vec2 = t2;
+ else
+vec1 = t2, vec2 = t1;
+}
+
x = build2 (odd_p ? VEC_INTERLEAVE_HIGH_EXPR : VEC_INTERLEAVE_LOW_EXPR,
- type, th, tl);
- x = build2 (MODIFY_EXPR, type, result, x);
- result = make_ssa_name (result, x);
- TREE_OPERAND (x, 0) = result;
- bsi_insert_before (&bsi, x, BSI_SAME_STMT);
+ type, vec1, vec2);
+ x = build2 (MODIFY_EXPR, type, dest, x);
- return result;
+ return x;
}
tree
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27753
[Bug java/27754] New: Stack overflow in gcj
Compile the attached file with gcj -c -findirect-dispatch parser.class -O2 This compiles successfully with gcc 4.1, although it consumes a lot of memory. With 4.2 it fails with a stack overflow. -- Summary: Stack overflow in gcj Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: aph at gcc dot gnu dot org ReportedBy: aph at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27754
[Bug java/27754] Stack overflow in gcj
--- Comment #1 from aph at gcc dot gnu dot org 2006-05-24 11:57 --- Created an attachment (id=11503) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11503&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27754
[Bug fortran/23375] show location for runtime errors
--- Comment #5 from jjcogliati-r1 at yahoo dot com 2006-05-24 12:49 --- (In reply to comment #4) > (In reply to comment #3) > > > So in GCC 4.1.0, the only problem seems to be that _gfortran_runtime_error > > is > > not printing the filename and the line number and the line number seems to > > be > > the line number of the previous statement, not the one that errors. > > runtime_error is also called from lots of places from within libgfortran, > and there is currently no way to pass line number information to intrinsics. > So, make a new function like runtime_error_with_lineinfo, and have that called instead when there is line information. I believe that gfor_fndecl_runtime_error declared in gcc-4.1.0/gcc/fortran/trans-decl.c is only used by trans.c in gfc_trans_runtime_check which always has line number information. So, how to make a patch for this: Create a runtime_error_with_loc in gcc-4.1.0/libgfortran/runtime/error.c that uses the a line number and filename. Change the gfor_fndecl_runtime_error to call runtime_error_with_loc instead of runtime_error in gcc-4.1.0/gcc/fortran/trans-decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
Re: [Bug preprocessor/27750] New: bogus 'backslash-newline at end of file' warning
sabre at nondot dot org wrote:- > $ gcc bug.c -Wall -pedantic -fsyntax-only -trigraphs -std=c99 > > yields: > bug.c:2:9: warning: trigraph ??/ converted to \ > bug.c:2:9: warning: backslash-newline at end of file > bug.c:2:1: warning: multi-line comment > bug.c:1: warning: ISO C forbids an empty source file > > A couple of issues. First, the diagnostics are not sorted. The last one > should be issued first. Second, more importantly, the 2nd diagnostic is > incorrect. There is no backslash-newline at the end of the file. The first > and third diagnostics are accurate. The empty source file diagnostic is clearly incorrect, it has text in it 8-) However I think it's quite logical it appear last as that it where it can be discovered. The backslash diagnostic is clearly bogus too. Neil.
[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning
--- Comment #8 from neil at daikokuya dot co dot uk 2006-05-24 12:55 --- Subject: Re: New: bogus 'backslash-newline at end of file' warning sabre at nondot dot org wrote:- > $ gcc bug.c -Wall -pedantic -fsyntax-only -trigraphs -std=c99 > > yields: > bug.c:2:9: warning: trigraph ??/ converted to \ > bug.c:2:9: warning: backslash-newline at end of file > bug.c:2:1: warning: multi-line comment > bug.c:1: warning: ISO C forbids an empty source file > > A couple of issues. First, the diagnostics are not sorted. The last one > should be issued first. Second, more importantly, the 2nd diagnostic is > incorrect. There is no backslash-newline at the end of the file. The first > and third diagnostics are accurate. The empty source file diagnostic is clearly incorrect, it has text in it 8-) However I think it's quite logical it appear last as that it where it can be discovered. The backslash diagnostic is clearly bogus too. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750
[Bug tree-optimization/27755] New: load-PRE confused by control flow
In the following testcase load-PRE is not able to hoist the load of *x
out of the loop because of the empty loop.
int foo(int k, int *x)
{
int j=0;
int res;
do {
for (int n=0;n<3;++n);
res = *x;
} while (++jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=27755
[Bug rtl-optimization/27357] 20 % increase code size in 4.1 vs 3.4.5
--- Comment #2 from etienne_lorrain at yahoo dot fr 2006-05-24 13:22 --- [EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/home/etienne/projet/toolchain --enable-languages=c Thread model: posix gcc version 4.1.1 20060517 (prerelease) [EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc tmp1.c -Os -c -o tmp.o && size tmp.o textdata bss dec hex filename 279 0 0 279 117 tmp.o [EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc tmp1.c -Os -c -o tmp.o -fno-optimize-sibling-calls && size tmp.o textdata bss dec hex filename 251 0 0 251 fb tmp.o So "tail return optimization" disabled by -fno-optimize-sibling-calls has at least something to do with the size increase. Note that this new GCC-4.1.1 prerelease also produce such code: addl$12, %esp leal-12(%ebp), %esp pop allregs ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27357
[Bug fortran/27709] Using size of array pointer component as dimension of function result causes gfortran internal error.
--- Comment #3 from pault at gcc dot gnu dot org 2006-05-24 13:37 --- I agree - see the list. In fact, I have just been hit by the same problem and have to fix it. I'll be as quick as I can! 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27709
[Bug java/27754] Stack overflow in gcj
--- Comment #2 from tromey at gcc dot gnu dot org 2006-05-24 13:38 --- Method name:"" static Signature: 70=()void Attribute "Code", length:58278, max_stack:7, max_locals:0, code_length:58266 Nice -- don't recall seeing a function that long before outside of jacks. -- 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 |2006-05-24 13:38:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27754
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-05-24 13:48 --- Look in Changelog and you will see the most recent two in trunk have not gone to 4.1 yet. The namelist patch for expanded reads does touch io.h The other was a simple problem. I changed a return; to return NULL; to get rid of a warning. That leaves the namelist patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug tree-optimization/27755] PRE confused by control flow
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-24 13:36 ---
Not only loads:
int foo(int k, int b)
{
int j=0;
int res;
do {
for (int n=0;n<3;++n);
res = b+1;
} while (++jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=27755
[Bug java/27754] Stack overflow in gcj
--- Comment #3 from aph at gcc dot gnu dot org 2006-05-24 14:31 --- Subject: Bug 27754 Author: aph Date: Wed May 24 14:31:23 2006 New Revision: 114043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114043 Log: 2006-05-24 Andrew Haley <[EMAIL PROTECTED]> PR java/27754 * decl.c (java_add_stmt): Use a STATEMENT_LIST rather than a COMPOUND_EXPR. Modified: trunk/gcc/java/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27754
[Bug tree-optimization/27755] PRE confused by control flow
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-24 14:35 ---
The CFG looks like
int foo(int, int) (k, b)
{
int pretmp.21;
int n;
int res;
int j;
# BLOCK 2 freq:367
# PRED: ENTRY [100.0%] (fallthru,exec)
# SUCC: 3 [100.0%] (fallthru,exec)
# BLOCK 3 freq:
# PRED: 2 [100.0%] (fallthru,exec) 8 [100.0%] (fallthru)
# j_1 = PHI <0(2), j_7(8)>;
:;
# SUCC: 4 [100.0%] (fallthru,exec)
# BLOCK 4 freq:1
# PRED: 7 [100.0%] (fallthru) 3 [100.0%] (fallthru,exec)
# n_13 = PHI ;
:;
n_12 = n_13 + 1;
if (n_12 <= 2) goto ; else goto ;
# SUCC: 7 [66.7%] (dfs_back,true,exec) 5 [33.3%] (loop_exit,false,exec)
# BLOCK 7 freq:6667
# PRED: 4 [66.7%] (dfs_back,true,exec)
:;
goto ();
# SUCC: 4 [100.0%] (fallthru)
# BLOCK 5 freq:
# PRED: 4 [33.3%] (loop_exit,false,exec)
:;
res_6 = b_5 + 1;
j_7 = j_1 + 1;
if (j_7 < k_8) goto ; else goto ;
# SUCC: 8 [89.0%] (dfs_back,true,exec) 6 [11.0%] (loop_exit,false,exec)
# BLOCK 8 freq:2966
# PRED: 5 [89.0%] (dfs_back,true,exec)
:;
goto ();
# SUCC: 3 [100.0%] (fallthru)
# BLOCK 6 freq:367
# PRED: 5 [11.0%] (loop_exit,false,exec)
:;
return res_6;
# SUCC: EXIT [100.0%]
}
where block #7 is the problematic one because ANTIC_IN of it never get's
the value handle for b+1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27755
[Bug java/27756] New: ICE in update_aliases, at java/decl.c:192
Compile the attached bytecode to see the ICE: opsy. gcj -c -findirect-dispatch ./bin/org/eclipse/jdt/internal/core/NameLookup.class org/eclipse/jdt/internal/core/NameLookup.java: In class 'org.eclipse.jdt.internal.core.NameLookup': org/eclipse/jdt/internal/core/NameLookup.java: In method 'org.eclipse.jdt.internal.core.NameLookup.seekTypesInBinaryPackage(java.lang.String,org.eclipse.jdt.core.IPackageFragment,boolean,int,org.eclipse.jdt.internal.core.IJavaElementRequestor)': org/eclipse/jdt/internal/core/NameLookup.java:980: internal compiler error: in update_aliases, at java/decl.c:192 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. This happens for me with 4.1 and svn head. The bytecode is a class generated by ecj; the corresponding source code also comes from ecj. -- Summary: ICE in update_aliases, at java/decl.c:192 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: aph at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27756
[Bug java/27756] ICE in update_aliases, at java/decl.c:192
--- Comment #1 from tromey at gcc dot gnu dot org 2006-05-24 14:56 --- Created an attachment (id=11504) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11504&action=view) failing class file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27756
[Bug fortran/27757] New: Problems with direct access io
I have a relatively stable, relatively large fortran program (500,000+ lines). This program works correctly on linux, 64 bit linux, solaris, and windows when compiled with g77 3.4.4. When I complile it with gfortran 4.1.0, 26 out of 384 of my regerssion tests fail because of i/o errors. Basically, I have databases which are accesses via direct access, unformatted io. All transactions pass through two routines: a writter and a reader. I have attached a tar file which contains the two routines. Basically, they write two words at the beginning of each record - the current numbers of "saus" (sort integers) and the record which continues this record. Also attached is a file, trans, which shows the reads and writes. Each line in the file contains the action (dba_read or dba_write), the fortran unit number, the record number, the number of short integers on this record, the continuation record, and finally the record length. (The print statements that created this file are commentd out in the source). If you notice the last line in this file says that record 2958 on logical unit 15 has 1 short integer, but 4 lines up, it has 122 and is continued on 2959. Notice that there have been writes to this file, but at different record numbers. I would really like to give you a better report, but the fact that 350 tests work properly says that any attempt to create a simple test will probably fail (the code will work properly). I will be happy to do anything you would like to help in the resolution of this problem. In particular, it you would like for me to test any changes, please just send me the library and I can get back to you within a couple of hours. -- Summary: Problems with direct access io Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug fortran/27757] Problems with direct access io
--- Comment #1 from ray at ultramarine dot com 2006-05-24 14:58 --- Created an attachment (id=11505) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11505&action=view) source and results -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug c++/14494] Rejected valid specialization of member template
--- Comment #5 from mark at codesourcery dot com 2006-05-24 15:09 --- Subject: Re: Rejected valid specialization of member template reichelt at gcc dot gnu dot org wrote: > --- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-24 09:51 > --- > The case with A<0>::B() instead of A<0>::B() which was also > rejected was fixed with Mark's patch for PR20173. > > The original testcase with A<0>::B() still fails, though. > > Mark, would you mind having a look at this one, too, as you > were just working in that area? I probably won't get there any time soon, sadly; too many regressions to which I'm already assigned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14494
[Bug libgcj/27731] Math cbrt(), cosh(), expm1(), hypot(), log1p(), sinh() and tanh() not implemented
--- Comment #1 from tromey at gcc dot gnu dot org 2006-05-24 15:15 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-22 20:26:44 |2006-05-24 15:15:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27731
[Bug libgcj/27726] LocalSocketImpl not implemented
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-24 15:18:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27726
[Bug target/27758] New: [4.1 regression] -O0 -fpic link failure
/* { dg-do run { target fpic } } */
/* { dg-options "-O0 -fpic" } */
typedef int (*fn) (void);
static inline int
foo (void)
{
return 1;
}
fn
test (void)
{
return foo;
}
int
main (void)
{
fn f = test ();
return f () != 1;
}
doesn't link on i386/x86_64 in 4.1 (regression from 4.0) - function foo isn't
marked as referenced and therefore not emitted.
This was fixed on the trunk in PR25758.
--
Summary: [4.1 regression] -O0 -fpic link failure
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i386-linux, x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27758
[Bug c/27759] New: ICE using -mfloat-abi=softfp -mfpu=vfp -O1
I use gcc-4.0.3, binutils-2.16.1, linux-libc-headers-2.6.12.0, glibc-2.3.6.
My building host is debian (gcc 3.3.5).
'arm-linux-gcc -v' outputs:
-
Configured with: ../gcc-4.0.3/configure --target=arm-linux
--prefix=/my-install-path/tools
--with-sysroot=/my-install-path/sys-root-arm-linux
--with-headers=/my-install-path/sys-root-arm-linux/usr/include
--enable-languages=c --disable-threads --disable-shared --with-float=softfp
--with-fpu=vfp
-
My simplified sources:
-- v.c --
double v(double f){
if(f < 1.){
f=-3.40282347e+38F;
}else{
f=3.0;
}
return f*.1;
}
-
When I compile v.c, with:
'arm-linux-gcc -mfloat-abi=softfp -mfpu=vfp -O3 -c v.c'
I have this message:
-
v.c: In function 'v':
v.c:9: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
-
'arm-linux-gcc -mfloat-abi=softfp -mfpu=vfp -c v.c' is ok
'arm-linux-gcc -mfloat-abi=softfp -mfpu=vfp -O0 -c v.c' is ok
'arm-linux-gcc -mfloat-abi=softfp -mfpu=vfp -O1 -c v.c' fails
'arm-linux-gcc -mfloat-abi=softfp -mfpu=vfp -O2 -c v.c' fails
'arm-linux-gcc -mfloat-abi=softfp -mfpu=vfp -O3 -c v.c' fails
'arm-linux-gcc -mfloat-abi=softfp -mfpu=fpa -c v.c' is ok
'arm-linux-gcc -mfloat-abi=softfp -mfpu=fpa -O0 -c v.c' is ok
'-O1', '-O2', '-O3' are ok
'arm-linux-gcc -mfloat-abi=softfp -mfpu=maverick -c v.c' outputs
'/tmp/ccwfEXjq.s:11: Error: selected processor does not support ' so
cc1 is ok
'-O1', '-O2', '-O3' writes the same kind of message.
'arm-linux-gcc -mfloat-abi=softfp -mfpu=fpe2 -c v.c' is ok
'-O1', '-O2', '-O3' are ok
'arm-linux-gcc -mfloat-abi=softfp -mfpu=fpe3 -c v.c' is ok
'-O1', '-O2', '-O3' are ok
'arm-linux-gcc -mfloat-abi=soft -mfpu=vfp -c v.c' is ok
'-O1', '-O2', '-O3' are ok
Note: with 'ok', I mean 'no error is returned by arm-linux-gcc'. I did not test
the resulting binaries.
Analyse:
arm-linux-gcc excutes cc1 with something like this:
'/path-to/cc1 -quiet v.c -dumpbase v.c -mfloat-abi=softfp -mfpu=vfp -auxbase v
-O1 -o /tmp/ccJycUj7.s'
cc1 SegFaults at line 3636 of 'optabs.c' in 'prepare_float_lib_cmp'.
This function is called from 'prepare_cmp_insn'.
In function 'prepare_cmp_insn', 'can_compare_p' returns false, so
'prepare_float_lib_cmp' is called. With the working cases, 'can_compare_p'
returns true. So I think it should returns true, but you should be faster than
me to figure out why it returns false in this case.
--
Summary: ICE using -mfloat-abi=softfp -mfpu=vfp -O1
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent_galceran at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27759
[Bug target/27758] [4.1 regression] -O0 -fpic link failure
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-24 15:50 --- Created an attachment (id=11506) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11506&action=view) gcc41-pr27758.patch -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27758
[Bug target/27758] [4.1 regression] -O0 -fpic link failure
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 15:53 --- I am ok with the back port. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||link-failure Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27758
[Bug tree-optimization/27755] PRE confused by control flow
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-24 15:56 --- This seems to fix it: Index: tree-ssa-pre.c === --- tree-ssa-pre.c (revision 114040) +++ tree-ssa-pre.c (working copy) @@ -1696,6 +1713,7 @@ compute_antic_aux (basic_block block, bo worklist = VEC_alloc (basic_block, heap, EDGE_COUNT (block->succs)); FOR_EACH_EDGE (e, ei, block->succs) +if (!(e->flags & EDGE_DFS_BACK)) VEC_quick_push (basic_block, worklist, e->dest); first = VEC_index (basic_block, worklist, 0); set_copy (ANTIC_OUT, ANTIC_IN (first)); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27755
[Bug fortran/27757] Problems with direct access io
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug target/27752] Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so
--- Comment #5 from manuel dot bettini at airbus dot com 2006-05-24 16:37 --- Subject: RE: Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so Thank you ! I was thinking it was automatically discovered ! Sorry ! -Message d'origine- De : pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Envoyé : mercredi 24 mai 2006 11:27 À : BETTINI, Manuel Objet : [Bug target/27752] Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so --- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-24 09:26 --- try with --disable-multilib. I bet you don't have the 64bit userland installed. Please read: http://gcc.gnu.org/install/specific.html#x-x-solaris2 When configuring on a Solaris 7 or later system that is running a kernel that supports only 32-bit binaries, one must configure with --disable-multilib, since we will not be able to build the 64-bit target libraries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the recipient, for system management and security reasons. This access is controlled under Regulation of Investigatory Powers Act 2000, Lawful Business Practises. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #25 from paolo at gcc dot gnu dot org 2006-05-24 16:37 --- Subject: Bug 24704 Author: paolo Date: Wed May 24 16:37:42 2006 New Revision: 114044 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114044 Log: 2006-05-24 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/24704 * include/bits/atomicity.h (__exchange_and_add_single, __atomic_add_single): New, single thread versions of the atomic functions. (__exchange_and_add_dispatch, __atomic_add_dispatch): New, depending on __GTHREADS and __gthread_active_p() dispatch either to the above or to the existing atomic functions. * include/ext/pool_allocator.h: Update callers. * include/ext/rc_string_base.h: Likewise. * include/bits/locale_classes.h: Likewise. * include/bits/basic_string.h: Likewise. * include/bits/ios_base.h: Likewise. * include/tr1/boost_shared_ptr.h: Likewise. * src/ios.cc: Likewise. * src/locale.cc: Likewise. * src/ios_init.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomicity.h trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/ios_base.h trunk/libstdc++-v3/include/bits/locale_classes.h trunk/libstdc++-v3/include/ext/pool_allocator.h trunk/libstdc++-v3/include/ext/rc_string_base.h trunk/libstdc++-v3/include/tr1/boost_shared_ptr.h trunk/libstdc++-v3/src/ios.cc trunk/libstdc++-v3/src/ios_init.cc trunk/libstdc++-v3/src/locale.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug target/27752] Complaint when building gcc 4.1.0 on solaris 10 about /usr/ucblib/libucb.so
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-24 16:39 --- There is another bug about not being auto discovered and this is documented as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27752
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #26 from pcarlini at suse dot de 2006-05-24 16:41 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug fortran/27760] New: possible bug for array of strings passed to function
For the following program, compiled on Windows with the 20060504 Mingw gfortran with the -fbounds-check option, program xfoo integer, parameter :: n = 3 integer :: i,istat(n) character (len=6):: words(n) character (len=1000) :: text text = "abcdef ghijkl mnopqr" read (text,*) words print*,(words(i)," ",i=1,n) istat = foo(words) print*,istat print*,(words(i)," ",i=1,n) ! contains function foo(str) result(istat) character (len=*), intent(in) :: str(:) integer :: istat(size(str)) istat = 0 end function foo end program xfoo the output is abcdef ghijkl mnopqr 0 0 4268384 abcdef ghijkl mn The array "words" changes, but it should not. This problem occurs only when the -fbounds-check option is used. Vivek Rao -- Summary: possible bug for array of strings passed to function Product: gcc Version: 4.2.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=27760
[Bug libgcj/27731] Math cbrt(), cosh(), expm1(), hypot(), log1p(), sinh() and tanh() not implemented
--- Comment #2 from tromey at gcc dot gnu dot org 2006-05-24 17:14 --- Subject: Bug 27731 Author: tromey Date: Wed May 24 17:14:45 2006 New Revision: 114045 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114045 Log: PR libgcj/27731: * java/lang/natMath.cc (cbrt, cosh, expm1, hypot, log1p, sinh, tanh): New methods. * java/lang/Math.java (cbrt, cosh, expm1, hypot, log1p, sinh, tanh): Declare. Modified: trunk/libjava/ChangeLog trunk/libjava/java/lang/Math.java trunk/libjava/java/lang/natMath.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27731
[Bug tree-optimization/27755] PRE confused by control flow
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-24 17:15 ---
Unfortunately it ICEs during bootstrap compiling mf-runtime.c with
mf-runtime.8.i: In function '__mfu_check':
mf-runtime.8.i:8: internal compiler error: in find_or_generate_expression, at
tree-ssa-pre.c:2279
testcase:
typedef unsigned long int uintptr_t;
unsigned mudflap_mode;
typedef struct __mf_object {
uintptr_t low, high;
} __mf_object_t;
void __mfu_check (void *ptr, unsigned obj_count,
uintptr_t ptr_lower, uintptr_t ptr_higher, __mf_object_t** all_ovr_obj)
{
int judgement = 0;
uintptr_t ptr_low = (uintptr_t) ptr;
uintptr_t ptr_high = (uintptr_t) ptr;
switch (mudflap_mode) {
case 0:
while (judgement == 0)
{
unsigned i;
unsigned uncovered = 0;
for (i = 0; i < obj_count; i++)
{
__mf_object_t *obj = all_ovr_obj[i];
int j, uncovered_low_p, uncovered_high_p;
uncovered_low_p = ptr_low < obj->low;
uncovered_high_p = ptr_high > obj->high;
for (j = 0; j < obj_count; j++)
{
__mf_object_t *obj2 = all_ovr_obj[j];
if (ptr_lower >= obj2->low && ptr_lower <= obj2->high)
uncovered_low_p = 0;
if (ptr_high >= obj2->low && ptr_higher <= obj2->high)
uncovered_high_p = 0;
}
if (uncovered_low_p || uncovered_high_p)
uncovered++;
}
if (uncovered == 0)
judgement = 1;
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27755
[Bug libgcj/27731] Math cbrt(), cosh(), expm1(), hypot(), log1p(), sinh() and tanh() not implemented
--- Comment #3 from tromey at gcc dot gnu dot org 2006-05-24 17:21 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27731
[Bug libgcj/27729] Field, Method and Constructor need isSynthetic() implemetation
--- Comment #2 from tromey at gcc dot gnu dot org 2006-05-24 17:22 --- Subject: Bug 27729 Author: tromey Date: Wed May 24 17:21:52 2006 New Revision: 114046 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114046 Log: gcc/java: PR libgcj/27729: * jcf.h (ACC_INVISIBLE): Changed value. libjava: PR libgcj/27729: * java/lang/reflect/natField.cc (getAddr): Added parens. * java/lang/reflect/natConstructor.cc (getModifiersInternal): Renamed. Don't mask flags. * java/lang/reflect/Constructor.java (CONSTRUCTOR_MODIFIERS): New constant. (getModifiersInternal): Renamed. (getModifiers): Rewrote. (isSynthetic, isVarArgs): New methods. (hashCode): Rewrote. (addTypeParameters, toGenericString): New methods. (getTypeParameters): Rewrote. (getSignature): New method. (getGenericParameterTypes, getGenericExceptionTypes): Likewise. * java/lang/reflect/natMethod.cc (getModifiersInternal): Renamed. Don't mask flags. * java/lang/reflect/natField.cc (getModifiersInternal): Renamed. Don't mask flags. * java/lang/reflect/Modifier.java (BRIDGE, VARARGS, SYNTHETIC, ENUM): New constants. (INVISIBLE): Changed value. * java/lang/reflect/Method.java: Mostly merged with Classpath. (getModifiersInternal): Renamed. (getModifiers): Rewrote. (isBridge, isSynthetic, isVarArgs): New methods. (toGenericString): Likewise. (getTypeParameters): Likewise. (getSignature): Likewise. (getGenericExceptionTypes, getGenericParameterTypes, getGenericReturnType): Likewise. (METHOD_MODIFIERS): New constant. * java/lang/reflect/Field.java: Mostly merged with Classpath. Added javadoc everywhere. (getModifiersInternal): Renamed. (getModifiers, isSynthetic, isEnumConstant): Rewrote. (toGenericString): New method. (getGenericType, getSignature): Likewise. (FIELD_MODIFIERS): New constant. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/jcf.h trunk/libjava/ChangeLog trunk/libjava/java/lang/reflect/Constructor.java trunk/libjava/java/lang/reflect/Field.java trunk/libjava/java/lang/reflect/Method.java trunk/libjava/java/lang/reflect/Modifier.java trunk/libjava/java/lang/reflect/natConstructor.cc trunk/libjava/java/lang/reflect/natField.cc trunk/libjava/java/lang/reflect/natMethod.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27729
[Bug libgcj/27729] Field, Method and Constructor need isSynthetic() implemetation
--- Comment #3 from tromey at gcc dot gnu dot org 2006-05-24 17:22 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27729
[Bug java/27643] ICE in java_mark_cni_decl_local compiling bytecode->native
--- Comment #4 from tromey at gcc dot gnu dot org 2006-05-24 17:23 --- I have a patch I'm testing. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-18 16:01:56 |2006-05-24 17:23:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27643
[Bug tree-optimization/27755] PRE confused by control flow
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-24 17:30 ---
Cannot get it smaller than
unsigned mudflap_mode;
void __mfu_check (unsigned obj_count,
unsigned long ptr_lower, unsigned long* all_ovr_obj)
{
unsigned uncovered = 1, i;
switch (mudflap_mode) {
case 0:
while (uncovered)
{
uncovered = 0;
for (i = 0; i < obj_count; i++)
{
int j, uncovered_low_p = 1, uncovered_high_p = 1;
for (j = 0; j < obj_count; j++)
{
if (ptr_lower <= *all_ovr_obj)
{
uncovered_low_p = 0;
uncovered_high_p = 0;
}
}
if (uncovered_low_p || uncovered_high_p)
uncovered++;
}
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27755
[Bug fortran/27709] Using size of array pointer component as dimension of function result causes gfortran internal error.
--- Comment #4 from pault at gcc dot gnu dot org 2006-05-24 18:11 --- Created an attachment (id=11507) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11507&action=view) The fix for this PR The enclosed patch fixes the problem. It has been regtested on FC5/Athlon and fixes the gfortran build of tonto-2.1 I will submit it tomorrow morning Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27709
[Bug rtl-optimization/27761] New: combine miscompiles
This testcase is miscompiled by g++ -O2 on ia64:
---
typedef long int intptr_t;
struct A {
void* mem1;
void* mem2;
};
static int off1() { return (intptr_t)(&(((struct A*)0x0)->mem1) ); }
static int off2() { return (intptr_t)(&(((struct A*)0x0)->mem2) ); }
int func( int length)
{
int off = off2() + 8;
if( length )
off = off1() + 4;
if( 4 == (off & 4) )
off += 4;
return off;
}
extern "C" void abort (void);
int main(void) {
if (func(0) == 0)
abort();
}
---
The two functions must be a bit complicated that not already the tree
optimizers optimize everything to a constant. For the same reason
__builtin_offsetof also hides the bug. The C compiler also optimizes those
two functions too early, so the code as it goes into the combiner is
already Okay. But with g++ you can see the error in combine. The problem
is, that the following instructions:
(insn 60 12 31 0 (set (reg/v:SI 341 [ off ])
(if_then_else:SI (ne (reg:BI 344)
(const_int 0 [0x0]))
(const_int 4 [0x4])
(const_int 16 [0x10]))) 249 {*cmovsi_internal}
(expr_list:REG_DEAD (reg:BI 344)
(insn 31 60 32 0 (set (reg:DI 345)
(and:DI (subreg:DI (reg/v:SI 341 [ off ]) 0)
(const_int 4 [0x4]))) 228 {anddi3}
(insn 32 31 33 0 (set (reg:SI 346)
(subreg:SI (reg:DI 345) 0)) 4 {*movsi_internal}
(expr_list:REG_DEAD (reg:DI 345)
(insn 33 32 34 0 (set (reg:BI 347)
(eq:BI (reg:SI 346)
(const_int 0 [0x0]))) 233 {*cmpsi_normal}
(expr_list:REG_DEAD (reg:SI 346)
in endeffect are combined into:
(insn 33 32 34 0 (set (reg/v:SI 341 [ off ])
(if_then_else:SI (ne (reg:BI 344)
(const_int 0 [0x0]))
(const_int 4 [0x4])
(const_int 0 [0x0]))) 249 {*cmovsi_internal}
Note especially that pseudo 341 was not dead in the first sequence and it's
value is indeed used later (it's simply returned). Without that combination
r341 will have values {4,16}, after that {4,0}. What the combiner
tries to do, is to combine that conditional set and that (and 4), which indeed
would correctly result in the above {4,0} conditional set.
The problem is, that an instruction is created which modifies the r341,
which it shouldn't. I debugged this a bit and it's not a simple problem
of combine not noticing that r341 is necessary later (it recognizes that),
but instead it's an RTL sharing problem in subst().
Reading the code a bit I think combine.c has multiple RTL sharing problems,
but here is the issue at hand:
try_combine() is called with these instructions in the call which finally
does the invalid transformation:
i1: (insn 60 12 31 0 (set (reg/v:SI 341 [ off ])
(if_then_else:SI (ne (reg:BI 344)
(const_int 0 [0x0]))
(const_int 4 [0x4])
(const_int 16 [0x10])))
i2: (insn 33 32 34 0 (set (reg:BI 347)
(eq:BI (zero_extract:DI (subreg:DI (reg/v:SI 341 [ off ]) 0)
(const_int 1 [0x1])
(const_int 2 [0x2]))
(const_int 0 [0x0])))
i3: (jump_insn 34 33 36 0 (set (pc)
(if_then_else (ne (reg:BI 347)
(const_int 0 [0x0]))
(label_ref 39)
(pc))) 242 {*br_true}
In the course of it's action to modify i3, it will somewhen have modified
i1 (!) into:
(insn 60 12 31 0 (set (reg/v:SI 341 [ off ])
(if_then_else:SI (ne (reg:BI 344)
(const_int 0 [0x0]))
(const_int 4 [0x4])
(const_int 0 [0x0])))
This is because i1src is given uncopied to subst(). Anyway, i1src
starts as expected as
(if_then_else:SI (ne (reg:BI 344)
(const_int 0 [0x0]))
(const_int 4 [0x4])
(const_int 16 [0x10]))
Then, in line 2216 it will be used in a subst call:
/* If we already got a failure, don't try to do more. Otherwise,
try to substitute in I1 if we have it. */
if (i1 && GET_CODE (newpat) != CLOBBER)
{
/* Before we can do this substitution, we must redo the test done
above (see detailed comments there) that ensures that I1DEST
isn't mentioned in any SETs in NEWPAT that are field assignments. */
if (! combinable_i3pat (NULL_RTX, &newpat, i1dest, NULL_RTX,
0, (rtx*) 0))
{
undo_all ();
return 0;
}
n_occurrences = 0;
subst_low_cuid = INSN_CUID (i1);
newpat = subst (newpat, i1dest, i1src, 0, 0);
substed_i1 = 1;
}
What combine tries to do, is also to fold i1 into the resulting instruction
which it is in the process of construction. i1src still points right into
the i1 pattern, i.e. is not a copy of it. The problem is, that in some
situations subst() not only changes the pattern where it substitutes something
into, but also the TO argument. I'm fairly sure that this was not as
initially designed. But the code in subst d
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-24 18:17 --- (intptr_t)(&(((struct A*)0x0)->mem1) ); That is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 18:19 --- > For the same reason __builtin_offsetof also hides the bug. Because it gets lowered correctly to a constant while "(intptr_t)(&(((struct A*)0x0)->mem1) )" is not a constant. Why is someone using that method of offsetof? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #3 from matz at gcc dot gnu dot org 2006-05-24 18:22 --- Created an attachment (id=11508) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11508&action=view) possible patch I was wrong about simplify_if_then_else, it uses pc_rtx in all subst calls. But that leaves three others which use their TO argument unprotected. The patch here solves the miscompilation for me. As of yet, untested otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug c/27747] [4.2 Regression] ice _Pragma and macros
--- Comment #3 from janis at gcc dot gnu dot org 2006-05-24 18:23 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=109336 r109336 | rth | 2006-01-04 16:33:38 + (Wed, 04 Jan 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27747
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #4 from matz at gcc dot gnu dot org 2006-05-24 18:26 --- Andrew, I know that this is undefined. Let us ignore this issue for this bug. I tried some time to come up with two nicer functions which still get inlined but are not optimized too early to hide the bug, but failed. Probably the testcase can be made using __builtin_offset, and then switching off certain tree-optimizer passes, but I didn't try. Debugging combine was painful enough :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #8 from dir at lanl dot gov 2006-05-24 18:27 --- Hi Jerry, I tried rev 113947 and rev 113923 that I think are just before your patches and gfortran still failed. I did a "svn update -r 113923 gcc" to create the old version. I hope that is the correct way to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-24 18:58
---
(In reply to comment #18)
> it is still broken on powerpc{,64}
Hi Jakub, I'm not sure exactly what is still broken. On
powerpc-apple-darwin7.9.0, with mainline gfortran 20060512:
$ cat foo.f90
! { dg-do run }
! { dg-require-effective-target fortran_large_real }
program huge_real10_formatted
! This should be kind=10 on systems that support it
integer, parameter :: k = selected_real_kind (precision (0.0_8) + 1)
real(kind=k) :: a,b(2), c
character(len=180) :: tmp
! Test real(k) scalar and array formatted IO with big value
b(:) = huge (1.0_k)/2
print *, 'real(10) big value: ', b(1)
write (tmp, *) b
read (tmp, *) a, c
print *, 'same value read again: ', a
print *, 'difference: ', a-b(1)
! Test with really big value
b(:) = huge (1.0_k)
print *, 'huge value: ', b(1)
write (tmp, *) b
read (tmp, *) a, c ! This is line 19
print *, "We don't get this far!"
if (a /= b(1)) call abort ()
if (c /= b(2)) call abort ()
end program huge_real10_formatted
$ gfortran foo.f90 && ./a.out
real(10) big value: 4.4942328371557897693232629769725618E+0307
same value read again: 4.4942328371557897693232629769725618E+0307
difference:0.0
huge value: 8.9884656743115795386465259539451237E+0307
We don't get this far!
$ gfortran foo.f90 -mlong-double-128 && ./a.out
real(10) big value: 4.4942328371557897693232629769725618E+0307
same value read again: 4.4942328371557897693232629769725618E+0307
difference:0.0
huge value: 8.9884656743115795386465259539451237E+0307
We don't get this far!
$ cat real16.f90
character(len=100) :: a
real(kind=16) :: x, y, z
x = huge(x)
write(a,*) x
read(a,*) y
if (x /= y) print *, x, y, x-y
end
$ gfortran real16.f90 && ./a.out
$ gfortran real16.f90 -mlong-double-128 && ./a.out
All this looks like it's working fine...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot org
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
Re: [Bug libfortran/24685] real(16) formatted input is broken for huge values
>
>
>
> --- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-24 18:58
> ---
> (In reply to comment #18)
> > it is still broken on powerpc{,64}
>
> Hi Jakub, I'm not sure exactly what is still broken. On
> powerpc-apple-darwin7.9.0, with mainline gfortran 20060512:
Darwin is broken a different way and it is a mess that I was trying to fix but
it
is still broken because I don't care that much anymore.
-- Pinski
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- Comment #20 from pinskia at physics dot uc dot edu 2006-05-24 19:01
---
Subject: Re: real(16) formatted input is broken for huge values
>
>
>
> --- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-24 18:58
> ---
> (In reply to comment #18)
> > it is still broken on powerpc{,64}
>
> Hi Jakub, I'm not sure exactly what is still broken. On
> powerpc-apple-darwin7.9.0, with mainline gfortran 20060512:
Darwin is broken a different way and it is a mess that I was trying to fix but
it
is still broken because I don't care that much anymore.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug c++/27762] New: map of valarray produces bad output
I created a map >. When I retrieve a valarray from the map, all of its data has been set to 0. System: i386-redhat-linux Options: --prefix=/usr --mandir=/usr/share/man --infodir=/ sr/share/info --enable-shared --enable-threads=posix --enable-checking=release -with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enabl -java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2 0/jre --with-cpu=generic --host=i386-redhat-linux Command Line: g++ -Wall foo.cpp Compiler Output: None I'm not sure how to attach the .ii file. I'll work on that next. -- Summary: map of valarray produces bad output Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: woessner at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27762
[Bug bootstrap/27763] New: add_referenced_var missing on bootstrap
Booting with CC=/usr/bin/cc (because booting with a fresh gcc is broken), I get cc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libbackend.a(tree-ssa-loop-manip.o): In function `create_iv': ../../../gcc/trunk/gcc/tree-ssa-loop-manip.c:63: undefined reference to `add_referenced_var' libbackend.a(tree-ssa-loop-manip.o): In function `tree_unroll_loop': ../../../gcc/trunk/gcc/tree-ssa-loop-manip.c:919: undefined reference to `add_referenced_var' libbackend.a(tree-ssa-loop-im.o): In function `determine_invariantness_stmt': ../../../gcc/trunk/gcc/tree-ssa-loop-im.c:627: undefined reference to `add_referenced_var' libbackend.a(tree-tailcall.o): In function `adjust_accumulator_values': ../../../gcc/trunk/gcc/tree-tailcall.c:565: undefined reference to `add_referenced_var' libbackend.a(tree-tailcall.o): In function `adjust_return_value': ../../../gcc/trunk/gcc/tree-tailcall.c:644: undefined reference to `add_referenced_var' libbackend.a(tree-tailcall.o):../../../gcc/trunk/gcc/tree-tailcall.c:659: more undefined references to `add_referenced_var' follow collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[3]: Leaving directory `/home/ig25/gcc-bin/trunk/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/ig25/gcc-bin/trunk' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/ig25/gcc-bin/trunk' make: *** [bootstrap] Error 2 $ configure command was CC=cc ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran cc is $ cc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) -- Summary: add_referenced_var missing on bootstrap Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27763
[Bug c++/27762] map of valarray produces bad output
--- Comment #1 from woessner at gmail dot com 2006-05-24 19:44 ---
Couldn't attach the .ii file (too big). Here's the source that generates the
problem:
#include
#include
#include
int main()
{
std::map > m;
std::valarray v(3);
v[0] = 13;
v[1] = 42;
v[2] = 99;
m[0] = v;
std::cout << m[0][0] << ", " << m[0][1] << ", " << m[0][2] << '\n';
return EXIT_SUCCESS;
}
I expect "13, 42, 99" but get "0, 0, 0".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27762
[Bug bootstrap/27763] add_referenced_var missing on bootstrap
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-05-24 19:47 --- I forget, this is i686-pc-linux-gnu, running Debian testing, on an Athlon XP 2600. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27763
[Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Summary|add_referenced_var missing |[4.2 regression] |on bootstrap|add_referenced_var missing ||on bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27763
Compiling files not encoded with system settings
Hello, A few weeks ago, I posted on the general GCC mailing-list an issue that arises when compiling with GCC on Linux files created on Windows and saved in "unicode". The problem seems to be that when CPP reads a source file, it uses the parameter passed with the -finput-charset option or LC_CTYPE, as encoding, which is fine. But then, it uses the same encoding to read system header files which fails if these are not encoded in the same way as passed with -finput-charset. To make a reproducible test, I created a simple hello world program that includes stdio.h. The file hi-utf16.c, created with Notepad and saved in "unicode", contains a BOM which is, in essence, a small header at the beginning of the file that indicates the encoding. nicolas:~> gcc -finput-charset=UTF-16 hi-utf16.c hi-utf16.c:1:19:failure to convert UTF-16 to UTF-8 It appears that CPP is telling libiconv to convert the source file from UTF-16 to UTF-8, which works, but as soon as it hits the include file, it fails. Of course, stdio.h is stored in UTF-8 on the system so trying to convert it from UTF-16 will fail right away. It would be nice if every file used the same unicode encoding, but that's not always possible, especially when source control is involved. This issue touches interoperability between Windows and UNIX and also "legacy" (ie. pre-UTF-8) source files in general. My suggestion is to have CPP open a file, read the first up to 4 bytes to figure out if there is a BOM. If so, calculate the encoding and pass it libiconv. I believe that's what vim does, btw. In short, I suggest that the encoding be detected in the following order: 1-BOM 2-finput-charset option 3-LC_CTYPE I would appreciate some feedback on the subject, including how to proceed. Thank you in advance, Nicolas
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2006-05-24 20:34 --- (In reply to comment #20) > Darwin is broken a different way and it is a mess that I was trying to fix but > it is still broken because I don't care that much anymore. Could you give a Fortran testcase that is not behaving as expected? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2006- | |04/msg00264.html| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug fortran/23375] show location for runtime errors
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-24 20:48 --- (In reply to comment #5) > So, how to make a patch for this: > Create a runtime_error_with_loc in gcc-4.1.0/libgfortran/runtime/error.c that > uses the a line number and filename. > > Change the gfor_fndecl_runtime_error to call runtime_error_with_loc instead of > runtime_error in gcc-4.1.0/gcc/fortran/trans-decl.c Looks doable. Correct line number information would be preferable, of course (I currently have no idea why this goes wrong right now). Do you already have a copyright assignment with the FSF? If so, maybe you can prepare a patch. I promise speedy review :-) Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug c++/27762] map of valarray produces bad output
--- Comment #2 from pcarlini at suse dot de 2006-05-24 20:48 --- This triggers undefined behavior: map::operator[] inserts a default-constructed (i.e., empty) valarray (C++03, 23.3.1.2), then valarray::operator= has undefined behavior because the argument has 3 elements and *this zero (26.3.2.2). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27762
[Bug libfortran/27524] -fbounds-check interacts with array function
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-24 20:52 --- (In reply to comment #3) > I think the cuplrit here is gfc_trans_dummy_array_bias(), around line 3728 > (where the offset is built), although I'm not skilled enough in all this to > understand how exactly to fix it. OK, I think I made it. It's a typo, where the stride variable is used as a temporary variable for creating a bounds-checking tree, but its value is needed (and reused) later, leading to the bug. Index: trans-array.c === --- trans-array.c (revision 113849) +++ trans-array.c (working copy) @@ -3564,7 +3564,7 @@ tree dumdesc; tree tmp; tree stmt; - tree stride; + tree stride, stride2; tree stmt_packed; tree stmt_unpacked; tree partial; @@ -3711,9 +3711,9 @@ tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, ubound, lbound); - stride = build2 (MINUS_EXPR, gfc_array_index_type, + stride2 = build2 (MINUS_EXPR, gfc_array_index_type, dubound, dlbound); - tmp = fold_build2 (NE_EXPR, gfc_array_index_type, tmp, stride); + tmp = fold_build2 (NE_EXPR, gfc_array_index_type, tmp, stride2); gfc_trans_runtime_check (tmp, gfc_strconst_bounds, &block); } } -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-24 09:20:48 |2006-05-24 20:52:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27524
[Bug c++/27748] [4.2 Regression] rejects _Pragma with macros
--- Comment #3 from janis at gcc dot gnu dot org 2006-05-24 21:17 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=109336 r109336 | rth | 2006-01-04 16:33:38 + (Wed, 04 Jan 2006) This is the same one that started the ICE for the corresponding C test in 27747. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27748
[Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 21:33 --- I cannot reproduce this on x86-linux-gnu with rev 114052. I bet some dependecies are incorrect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27763
[Bug java/27764] New: gcj-4.1: error trying to exec 'cc1': execvp: No such file or directory
This is a fresh installation from Debian testing (Etch). (Well, I downgraded
to gcj-4.0, and then upgraded to gcj-4.1).
It's been about a month since I've used this at all, but it was "sort of"
working then. I attribute the "sort of" to my skill level.
The compile command was: gcj-4.1 --main=Hello -o Hello Hello.java
Yielding: gcj-4.1: error trying to exec 'cc1': execvp: No such file or
directory
FWIW, the Hello.java file was:
public class Hello
{
public static voidmain(String argv[])
{ System.out.println ("Hello, World!"); }
}
I suspect that this should have failed, as I suspect that I needed to import
System...the example in the book didn't show any import, however, so I didn't
include one.
--
Summary: gcj-4.1: error trying to exec 'cc1': execvp: No such
file or directory
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: charleshixsn at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27764
[Bug fortran/27765] New: -fbounds-check gives undue warning with
I ran the gfortran testsuite with -fbounds-check and found a few failures (on i686-linux), among which was gfortran.dg/aliasing_dummy_1.f90. Here is a reduced testcase: program test_lex type :: dtype character*5 :: word end type dtype type :: list type(dtype) :: list(1) end type list type(list) :: table call foo1 (table%list(1)%word) contains subroutine foo1 (slist) character(*), dimension(*) :: slist write (slist(1), '(i5)') 0 end subroutine foo1 end program test_lex $ gfortran -fbounds-check bug.f90 && ./a.out Fortran runtime error: Array reference out of bounds -- Summary: -fbounds-check gives undue warning with Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27765
[Bug java/27764] gcj-4.1: error trying to exec 'cc1': execvp: No such file or directory
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-24 21:42 --- You forgot to also install the C compiler. I am assuming you isntalled gcj via apt-get which means you also need to install gcc-4.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27764
[Bug fortran/27765] -fbounds-check gives undue warning with
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-24 21:44 --- I bet $ 100 (or a beer at the GCC summit if you come) that the problem is with dimension(*) Which means this is a dup of bug 19777. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|-fbounds-check gives undue |-fbounds-check gives undue |warning with|warning with http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27765
[Bug libgcj/27024] Implement URLConnection.getFileNameMap
--- Comment #4 from tromey at gcc dot gnu dot org 2006-05-24 21:44 --- Subject: Bug 27024 Author: tromey Date: Wed May 24 21:44:34 2006 New Revision: 114056 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114056 Log: PR libgcj/27024: * sources.am, Makefile.in: Rebuilt. * gnu/java/net/DefaultContentHandlerFactory.java: Removed. * java/net/URLConnection.java: Removed. Removed: trunk/libjava/gnu/java/net/DefaultContentHandlerFactory.java trunk/libjava/java/net/URLConnection.java Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/sources.am -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27024
[Bug c/20410] Add support for UTF-16 string syntax to C and C++
--- Comment #3 from grhoten at jtcsv dot com 2006-05-24 21:45 --- FYI I think other people have created patches to gcc to implement this feature. It would be nice if this feature was supported in gcc by default. http://ftp4.de.freesbie.org/pub/misc/sapdb/i18N/utf16/ugcc-3.2/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20410
[Bug libgcj/27024] Implement URLConnection.getFileNameMap
--- Comment #5 from tromey at gcc dot gnu dot org 2006-05-24 21:45 --- Fixed in 4.2 now as well. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27024
[Bug fortran/27766] New: [meta] -fbounds-check related bugs
This PR is opened for tracking all bugs related to the -fbounds-check option. -- Summary: [meta] -fbounds-check related bugs Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org BugsThisDependsOn: 19777,24401,26801,27524,27588,27765 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-24 21:51 --- With gfortran mainline 20060517 (and the patch for PR 27524), here is a list of failures recorder when the testsuite is run with -fbounds-check (command line is make check-gfortran RUNTESTFLAGS="-target_board=unix/-fbounds-check"): gfortran.dg/aliasing_dummy_1.f90 gfortran.dg/cray_pointers_2.f90 gfortran.dg/pr15140.f90 gfortran.dg/pr25603.f gfortran.dg/g77/dnrm2.f gfortran.dg/gomp/appendix-a/a.12.1.f90 gfortran.dg/gomp/appendix-a/a.30.1.f90 gfortran.dg/gomp/appendix-a/a.31.1.f90 gfortran.dg/gomp/appendix-a/a.31.2.f90 gfortran.dg/gomp/appendix-a/a.8.1.f90 gfortran.fortran-torture/execute/assumed_size.f90 gfortran.fortran-torture/execute/forall_3.f90 gfortran.fortran-torture/execute/where_7.f90 gfortran.fortran-torture/execute/where_8.f90 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-24 21:51:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug fortran/19777] -fbounds-check catches non-existent bounds violation
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-05-24 22:00 --- Short enough for commit. Will do some testing before, and then check it in. Thanks Andrew! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |fxcoudert at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19777
Re: Compiling files not encoded with system settings
Nicolas De Rico wrote: > The file hi-utf16.c, created with Notepad and saved in "unicode", >contains a BOM which is, in essence, a small header at the beginning of >the file that indicates the encoding. It's not a header that indicates the encoding. It's a header that indicates the byte order of the 16-bit values that follow when the encoding is already known to be UTF-16. When then encoding is known to be UTF-16LE or UTF-16BE there shouldn't be any "BOM" present at the start of a C file, since a "BOM" in the correct byte order is actually the Unicode "zero-width non-breaking space" character, which isn't valid as the first character in a C file. Similarly, there shouldn't be a BOM mark at the start of a UTF-8 C file, especially since UTF-8 encoded files don't have a byte-order. The presence of what looks to be UTF-16 BOM header can be used a part of a heuristic to guess the encoding of file, but I don't think it's a good idea for GCC to be guessing the encoding of files. >Of course, stdio.h is stored in UTF-8 on the system so trying to convert >it from UTF-16 will fail right away. It would probably be more accurate to describe "stdio.h" as an ASCII file. Ross Ridge
[Bug fortran/22629] Would like to access "long double" equivalent type as real*16
--- Comment #6 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-24 22:11 --- > Gfortran will never support a real*16 data type on IA32 hardware. > This would require software emulation of all of basic floating-point > arthimetic This is what Intel's Fortran Compiler does - it emulates quads in software on IA32/EM64T/Itanium. Steve Lionel mentions another possibilty: "IBM has an odd implementation where they use two doubles with offset exponents. It's fast but it isn't a uniform type and doesn't give you extended range, so it's useless for a lot of what people use higher precision types for." See http://softwareforums.intel.com/ids/board/message?board.id=5&message.id=17632 g95, NAGWare f95, Pathscale and Portland's pgf95 all fail to compile real(16) [most of them use GCC as backend, though] on AMD64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629
[Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-24 22:18 --- The bug is with Path: . URL: svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 114050 Node Kind: directory Schedule: normal Last Changed Author: jsm28 Last Changed Rev: 113935 Last Changed Date: 2006-05-20 19:51:30 +0200 (Sat, 20 May 2006) Properties Last Updated: 2006-05-20 21:30:42 +0200 (Sat, 20 May 2006) The call to add_referenced_var in tree-ssa-loop-manip.c appears to have been introduced by revision 114018, by Andrew MacLeod. In tree-dfa.c, I see a static inline function of this name. There are several other uses, without prototypes or function definitions: $ grep add_referenced_var *.[ch] tree-complex.c: add_referenced_var (r); tree-dfa.c:static void add_referenced_var (tree, struct walk_state *); tree-dfa.c:add_referenced_var (*tp, walk_state); tree-dfa.c:add_referenced_var (tree var, struct walk_state *walk_state) tree-dfa.c: add_referenced_var, but is used by passes that need to add new temps to tree-dfa.c: add_referenced_var (var, NULL); tree-ssa-alias.c:add_referenced_var in the above loop will take care of tree-ssa-loop-im.c: add_referenced_var (var); tree-ssa-loop-manip.c: add_referenced_var (var); tree-ssa-loop-manip.c:add_referenced_var (var); tree-ssa-operands.c: a VUSE for .GLOBAL_VAR if it has been created. See add_referenced_var tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); Could it be that this function was exported, despite being declared static? It is possible that the compiler I used for bootstrapping exposes this bug. Also note that there is a discrepancy in the number of arguments. Possible solution: Declare the function global in the appropriate header (whatever that may be) and call it with the correct number of arguments. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27763
Re: [Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap
> > > > --- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-24 22:18 > --- > The bug is with > > Path: . > URL: svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk > Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 > Revision: 114050 > Node Kind: directory > Schedule: normal > Last Changed Author: jsm28 > Last Changed Rev: 113935 > Last Changed Date: 2006-05-20 19:51:30 +0200 (Sat, 20 May 2006) > Properties Last Updated: 2006-05-20 21:30:42 +0200 (Sat, 20 May 2006) > > The call to add_referenced_var in tree-ssa-loop-manip.c appears > to have been introduced by revision 114018, by Andrew MacLeod. > In tree-dfa.c, I see a static inline function of this name. There are > several other uses, without prototypes or function definitions: Something must be wrong with your download of GCC. gimplify.c: add_referenced_var (t); lambda-code.c: add_referenced_var (resvar); lambda-code.c: add_referenced_var (resvar); lambda-code.c: add_referenced_var (ivvar); lambda-code.c: add_referenced_var (ivvar); lambda-code.c: add_referenced_var (uboundvar); tree-complex.c: add_referenced_var (r); tree-dfa.c: add_referenced_var (t); tree-dfa.c:add_referenced_var (*tp); tree-dfa.c:add_referenced_var (tree var) tree-dfa.c: add_referenced_var (t); tree-flow.h:extern void add_referenced_var (tree); tree-if-conv.c: add_referenced_var (var); tree-outof-ssa.c: add_referenced_var (tmp); tree-outof-ssa.c: /* add_referenced_var will create the annotation and set up some tree-ssa-alias.c: add_referenced_var (tag); tree-ssa-alias.c: add_referenced_var (global_var); tree-ssa-alias.c: add_referenced_var (subvar); tree-ssa-alias.c:add_referenced_var in the above loop will take care of tree-ssa-loop-im.c: add_referenced_var (var); tree-ssa-loop-ivopts.c: add_referenced_var (cand->var_before); tree-ssa-loop-manip.c: add_referenced_var (var); tree-ssa-loop-manip.c:add_referenced_var (var); tree-ssa-operands.c: a VUSE for .GLOBAL_VAR if it has been created. See add_referenced_var tree-ssa-phiopt.c: add_referenced_var (tmp); tree-ssa-phiopt.c:add_referenced_var (tmp); tree-ssa-phiopt.c: add_referenced_var (tmp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (SSA_NAME_VAR (TREE_OPERAND (stmt, 0))); tree-ssa-structalias.c: add_referenced_var (heapvar); tree-ssa-structalias.c: add_referenced_var (heapvar); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-vect-patterns.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (dest); tree-vect-transform.c: add_referenced_var (tmp); tree-vect-transform.c: add_referenced_var (addr_expr); tree-vect-transform.c: add_referenced_var (vect_ptr); tree-vect-transform.c: add_referenced_var (vec_dest); tree-vect-transform.c: add_referenced_var (new_var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (addr_tmp); tree-vect-transform.c: add_referenced_var (or_tmp); tree-vect-transform.c: add_referenced_var (and_tmp); That is what I get. Are you sure that you are not having a mix of 4.1 code and trunk code. -- Pinski
[Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap
--- Comment #4 from pinskia at physics dot uc dot edu 2006-05-24 22:23 --- Subject: Re: [4.2 regression] add_referenced_var missing on bootstrap > > > > --- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-24 22:18 > --- > The bug is with > > Path: . > URL: svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk > Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 > Revision: 114050 > Node Kind: directory > Schedule: normal > Last Changed Author: jsm28 > Last Changed Rev: 113935 > Last Changed Date: 2006-05-20 19:51:30 +0200 (Sat, 20 May 2006) > Properties Last Updated: 2006-05-20 21:30:42 +0200 (Sat, 20 May 2006) > > The call to add_referenced_var in tree-ssa-loop-manip.c appears > to have been introduced by revision 114018, by Andrew MacLeod. > In tree-dfa.c, I see a static inline function of this name. There are > several other uses, without prototypes or function definitions: Something must be wrong with your download of GCC. gimplify.c: add_referenced_var (t); lambda-code.c: add_referenced_var (resvar); lambda-code.c: add_referenced_var (resvar); lambda-code.c: add_referenced_var (ivvar); lambda-code.c: add_referenced_var (ivvar); lambda-code.c: add_referenced_var (uboundvar); tree-complex.c: add_referenced_var (r); tree-dfa.c: add_referenced_var (t); tree-dfa.c:add_referenced_var (*tp); tree-dfa.c:add_referenced_var (tree var) tree-dfa.c: add_referenced_var (t); tree-flow.h:extern void add_referenced_var (tree); tree-if-conv.c: add_referenced_var (var); tree-outof-ssa.c: add_referenced_var (tmp); tree-outof-ssa.c: /* add_referenced_var will create the annotation and set up some tree-ssa-alias.c: add_referenced_var (tag); tree-ssa-alias.c: add_referenced_var (global_var); tree-ssa-alias.c: add_referenced_var (subvar); tree-ssa-alias.c:add_referenced_var in the above loop will take care of tree-ssa-loop-im.c: add_referenced_var (var); tree-ssa-loop-ivopts.c: add_referenced_var (cand->var_before); tree-ssa-loop-manip.c: add_referenced_var (var); tree-ssa-loop-manip.c:add_referenced_var (var); tree-ssa-operands.c: a VUSE for .GLOBAL_VAR if it has been created. See add_referenced_var tree-ssa-phiopt.c: add_referenced_var (tmp); tree-ssa-phiopt.c:add_referenced_var (tmp); tree-ssa-phiopt.c: add_referenced_var (tmp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (SSA_NAME_VAR (TREE_OPERAND (stmt, 0))); tree-ssa-structalias.c: add_referenced_var (heapvar); tree-ssa-structalias.c: add_referenced_var (heapvar); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-vect-patterns.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (dest); tree-vect-transform.c: add_referenced_var (tmp); tree-vect-transform.c: add_referenced_var (addr_expr); tree-vect-transform.c: add_referenced_var (vect_ptr); tree-vect-transform.c: add_referenced_var (vec_dest); tree-vect-transform.c: add_referenced_var (new_var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (addr_tmp); tree-vect-transform.c: add_referenced_var (or_tmp); tree-vect-transform.c: add_referenced_var (and_tmp); That is what I get. Are you sure that you are not having a mix of 4.1 code and trunk code. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27763
[Bug tree-optimization/27639] [4.1/4.2 regression] VRP miscompilation of simple loop
--- Comment #25 from rakdver at gcc dot gnu dot org 2006-05-24 22:55 --- Subject: Bug 27639 Author: rakdver Date: Wed May 24 22:55:15 2006 New Revision: 114057 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114057 Log: PR tree-optimization/27639 PR tree-optimization/26719 * tree-vrp.c (adjust_range_with_scev): Use scev_direction and adjust call to scev_probably_wraps_p. * tree-ssa-loop-niter.c (compare_trees, convert_step_widening, used_in_pointer_arithmetic_p, convert_step): Removed. (nowrap_type_p): New function. (scev_probably_wraps_p): Rewritten. * tree-scalar-evolution.c (instantiate_parameters_1): Do not call chrec_convert if chrec_convert_aggressive might have been used. * tree-chrec.c (convert_affine_scev, chrec_convert_1, scev_direction): New functions. (chrec_convert): Changed to a wrapper over chrec_convert_1. * tree-ssa-loop-ivopts.c (idx_find_step): Use convert_affine_scev instead of convert_step. * tree-flow.h (scev_probably_wraps_p): Declaration changed. (convert_step): Declaration removed. (convert_affine_scev, nowrap_type_p, scev_direction): Declare. * gcc.dg/pr27639.c: New test. * gcc.dg/pr26719.c: New test. * gcc.dg/tree-ssa/scev-cast.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr26719.c trunk/gcc/testsuite/gcc.dg/pr27639.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-24 22:55 --- Subject: Bug 26719 Author: rakdver Date: Wed May 24 22:55:15 2006 New Revision: 114057 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114057 Log: PR tree-optimization/27639 PR tree-optimization/26719 * tree-vrp.c (adjust_range_with_scev): Use scev_direction and adjust call to scev_probably_wraps_p. * tree-ssa-loop-niter.c (compare_trees, convert_step_widening, used_in_pointer_arithmetic_p, convert_step): Removed. (nowrap_type_p): New function. (scev_probably_wraps_p): Rewritten. * tree-scalar-evolution.c (instantiate_parameters_1): Do not call chrec_convert if chrec_convert_aggressive might have been used. * tree-chrec.c (convert_affine_scev, chrec_convert_1, scev_direction): New functions. (chrec_convert): Changed to a wrapper over chrec_convert_1. * tree-ssa-loop-ivopts.c (idx_find_step): Use convert_affine_scev instead of convert_step. * tree-flow.h (scev_probably_wraps_p): Declaration changed. (convert_step): Declaration removed. (convert_affine_scev, nowrap_type_p, scev_direction): Declare. * gcc.dg/pr27639.c: New test. * gcc.dg/pr26719.c: New test. * gcc.dg/tree-ssa/scev-cast.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr26719.c trunk/gcc/testsuite/gcc.dg/pr27639.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug target/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc
--- Comment #9 from danglin at gcc dot gnu dot org 2006-05-24 23:23 --- Subject: Bug 27627 Author: danglin Date: Wed May 24 23:23:10 2006 New Revision: 114059 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114059 Log: PR target/27627 * pa/pa-modes.def: Use mips_single_format, mips_double_format and mips_quad_format formats instead of ieee_single_format, ieee_double_format and ieee_quad_format formats, respectively. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa-modes.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
Re: [Bug target/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc
> > > > --- Comment #9 from danglin at gcc dot gnu dot org 2006-05-24 23:23 > --- > Subject: Bug 27627 > > Author: danglin > Date: Wed May 24 23:23:10 2006 > New Revision: 114059 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114059 > Log: > PR target/27627 > * pa/pa-modes.def: Use mips_single_format, mips_double_format and > mips_quad_format formats instead of ieee_single_format, > ieee_double_format and ieee_quad_format formats, respectively. You might not want to us MIPS_QUAD format because it is not even close to IEEE Quad format but instead it is more like the PPC quad format. -- Pinski
[Bug target/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc
--- Comment #10 from pinskia at physics dot uc dot edu 2006-05-24 23:26
---
Subject: Re: __builtin_nanf("") doesn't return a _quiet_ nan on parisc
>
>
>
> --- Comment #9 from danglin at gcc dot gnu dot org 2006-05-24 23:23
> ---
> Subject: Bug 27627
>
> Author: danglin
> Date: Wed May 24 23:23:10 2006
> New Revision: 114059
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114059
> Log:
> PR target/27627
> * pa/pa-modes.def: Use mips_single_format, mips_double_format and
> mips_quad_format formats instead of ieee_single_format,
> ieee_double_format and ieee_quad_format formats, respectively.
You might not want to us MIPS_QUAD format because it is not even close
to IEEE Quad format but instead it is more like the PPC quad format.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
