[Bug middle-end/23369] [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison
--- Additional Comments From tausq at debian dot org 2005-08-15 05:31 --- Do I understand correctly that there are two distinct problems: 1) gcc should not be canonicalizing constants casted as function pointers 2) gcc should not generate relational comparisons against function pointers ? it seems from my quick tests that #1 is not affected by build_range_test (i.e. something else is wrong). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug rtl-optimization/23393] catchall-1.m and finally-1.m fails at -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 02:15 --- Seen: http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00850.html http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00821.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23393
[Bug rtl-optimization/23392] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
-- What|Removed |Added Summary|objc/execute/exceptions/fowa|foward-1.m fails with - |rd-1.m fails with -funroll- |funroll-loops -O3 -fgnu- |loops -O3 -fgnu-runtime |runtime http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug rtl-optimization/23393] New: catchall-1.m and finally-1.m fails at -Os
This PR is to record the following failures on x86_64-linux-gnu: FAIL: objc/execute/exceptions/catchall-1.m execution, -Os -fgnu-runtime FAIL: objc/execute/exceptions/finally-1.m execution, -Os -fgnu-runtime -- Summary: catchall-1.m and finally-1.m fails at -Os Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23393
[Bug rtl-optimization/23392] objc/execute/exceptions/foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 02:07 --- Here is the backtrace: #0 _Unwind_fallback_frame_state_for (context=0xb2cc, fs=0xb530) at /Users/pinskia/src/ local3/gcc/gcc/config/rs6000/darwin-fallback.c:96 #1 0x000b90d4 in uw_frame_state_for (context=0xb2cc, fs=0xb530) at /Users/pinskia/src/ local3/gcc/gcc/unwind-dw2.c:982 #2 0x000baa34 in _Unwind_RaiseException (exc=0x3014c0) at /Users/pinskia/src/local3/gcc/gcc/ unwind.inc:103 #3 0x0006abd8 in objc_exception_throw (value=0x3014b0) at /Users/pinskia/src/local3/gcc/libobjc/ exception.c:371 #4 0x2b94 in -[Thrower forward::] (self=0x22000228, _cmd=0x46, s=0x2, a=0x0) at foward -1.m:18 Current language: auto; currently c I think the dwarf-2 eh information is messed up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug rtl-optimization/23392] objc/execute/exceptions/foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 01:57 --- PR 15023 is the bug for -frename-registers being broken. -- What|Removed |Added OtherBugsDependingO||15023 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug rtl-optimization/23392] objc/execute/exceptions/foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 01:56 --- This fails at -O1 -frename-registers also. We get a bus error. In a way this almost be considered a regression as -frename-registers was enabled at -funroll-loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug rtl-optimization/23392] New: objc/execute/exceptions/foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
This PR is to record the following failures: FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer -funroll-loops -fgnu-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fgnu-runtime I have not looked into what is causing the failure yet. -- Summary: objc/execute/exceptions/foward-1.m fails with -funroll- loops -O3 -fgnu-runtime Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug target/15617] building groff-1.19.1 with "-Os -march=pentium4" causes sig 11
--- Additional Comments From mueller at kde dot org 2005-08-15 00:46 --- duplicate of #13685 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15617
[Bug rtl-optimization/17700] -Os causes bad build of libgcj.so.5.0.0 file
-- What|Removed |Added CC||mueller at kde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17700
[Bug tree-optimization/23391] [4.1 regression] Tree checking failure due to scev
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-08-15 00:34 ---
Subject: Re: [4.1 regression] Tree checking failure due to scev
This patch should fix the problem. There are some more cases that use
build_int_cst instead of build_real. I'll propose a more complete
patch later.
*** tree-scalar-evolution.c.~2.35.~ 2005-08-13 19:06:26.0 +0200
--- tree-scalar-evolution.c 2005-08-15 02:36:50.0 +0200
***
*** 1680,1686
opnd10 = TREE_OPERAND (opnd1, 0);
chrec10 = analyze_scalar_evolution (loop, opnd10);
chrec10 = chrec_convert (type, chrec10, at_stmt);
! res = chrec_fold_minus (type, build_int_cst (type, 0), chrec10);
break;
case MULT_EXPR:
--- 1680,1688
opnd10 = TREE_OPERAND (opnd1, 0);
chrec10 = analyze_scalar_evolution (loop, opnd10);
chrec10 = chrec_convert (type, chrec10, at_stmt);
! res = chrec_fold_multiply (type, chrec10, SCALAR_FLOAT_TYPE_P (type)
! ? build_real (type, dconstm1)
! : build_int_cst_type (type, -1));
break;
case MULT_EXPR:
*** tree-chrec.c.~2.23.~2005-08-13 19:06:26.0 +0200
--- tree-chrec.c2005-08-15 02:20:51.0 +0200
***
*** 284,291
return build_polynomial_chrec
(CHREC_VARIABLE (op1),
chrec_fold_minus (type, op0, CHREC_LEFT (op1)),
! chrec_fold_multiply (type, CHREC_RIGHT (op1),
! build_int_cst_type (type, -1)));
default:
{
--- 284,292
return build_polynomial_chrec
(CHREC_VARIABLE (op1),
chrec_fold_minus (type, op0, CHREC_LEFT (op1)),
! chrec_fold_multiply (type, CHREC_RIGHT (op1),
SCALAR_FLOAT_TYPE_P (type)
! ? build_real (type, dconstm1)
! : build_int_cst_type (type, -1)));
default:
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug tree-optimization/23391] [4.1 regression] Tree checking failure due to scev
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 00:09 --- This is related to PR 19899 which was fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug tree-optimization/23391] [4.1 regression] Tree checking failure due to scev
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-15 00:05 --- Note that part of the problem is that build_int_cst_type, which scev uses here, should check that the type given to it is an integral type. That would have caught the checking failure much earlier. Right now scev tries to use build_int_cst_type with type==double. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug tree-optimization/23391] [4.1 regression] Tree checking failure due to scev
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 00:01 --- Confirmed, only -O1 is required to reproduce this. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-15 00:01:26 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug middle-end/23391] New: [4.1 regression] Tree checking failure due to scev
Test case:
==
void
foo (int N)
{
int C;
double R;
R = 0.0;
do
{
R += 0.001;
C = (int) (R * N);
if (-R * N <= R * N)
{
C++;
}
}
while (C < 0);
return;
}
==
$ ./cc1 -fno-unit-at-a-time -O1 -ffast-math t.c
foo
t.c: In function 'foo':
t.c:3: internal compiler error: tree check: expected real_cst, have
integer_cst in const_binop, at fold-const.c:1512
The test case comes from SPEC twolf. The problem appeared after this patch
was committed: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00801.html
--
Summary: [4.1 regression] Tree checking failure due to scev
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,spop at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug awt/21747] JAWT_X11DrawingSurfaceInfo missing depth field
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-14 22:08:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21747
[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-08-14 22:02 ---
Subject: Re: MAXPATHLEN usage in fortran/{scanner,module}.c
Steve Kargl wrote:
> The attached patches uses alloca to remove the use of PATH_MAX
> from gfortran. It also fixes one other nearby hardcoded buffer.
>
> This has been bubblestrapped and regression tested on amd64-*-freebsd.
>
> 2005-08-01 Steven G. Kargl <[EMAIL PROTECTED]>
>
> PR fortran/23065
> * gfortran.h: Remove PATH_MAX definition.
> * module.c (write_module,gfc_dump_module): Use alloca to allocate
> buffers.
> * scanner.s (gfc_release_include_path,form_from_filename): Ditto.
^
typo.
> --- 1131,1142
> const char *fileext;
> int i;
>
> ! /* Find end of file name. Note, filename is either a NULL pointer or
> ! a NUL terminated string. */
> i = 0;
> ! while (filename[i] != '\0')
> i++;
>
> /* Find last period. */
> while (i >= 0 && (filename[i] != '.'))
> i--;
If filename ever were a NULL pointer this would break, but it won't ever be
because gfc_post_options explicitly sets it to the empty string if no filename
is supplied on the command line.
The patch is ok if you remove the if in the beginning of gfc_new_file, i.e.
change
try
gfc_new_file (const char *filename, gfc_source_form form)
{
try result;
if (filename != NULL)
{
gfc_source_file = gfc_getmem (strlen (filename) + 1);
strcpy (gfc_source_file, filename);
}
else
gfc_source_file = NULL;
to gcc_assert(filename) plus the if part.
thanks,
- Tobi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065
[Bug middle-end/21137] Convert (a >> 2) & 1 != 0 into a & 4 != 0
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-14 21:56 --- Actually, doing (a >> c1) & 2**c2 -> (a & (1<> c1 looks worse, but can be transformed into (a & (1
[Bug fortran/21432] gfortran does not support printing of namelists
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 21:46 --- Subject: Bug 21432 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-14 21:46:52 Modified files: gcc/fortran: gfortran.texi ChangeLog Log message: 2005-08-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21432. * gfortran.texi: Document PRINT namelist. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.8.6&r2=1.10.8.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.106&r2=1.335.2.107 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21432
[Bug fortran/21432] gfortran does not support printing of namelists
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 21:43 --- Subject: Bug 21432 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-14 21:43:14 Modified files: gcc/fortran: gfortran.texi ChangeLog Log message: 2005-08-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21432. * gfortran.texi: Document PRINT namelist. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.texi.diff?cvsroot=gcc&r1=1.21&r2=1.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.522&r2=1.523 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21432
[Bug libfortran/23321] Direct unformatted read beyond EOF cores
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-14 21:39 --- If HAVE_MMAP is undefined, then the test case gets to "should not get here", so this is buggy as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23321
[Bug ada/23390] New: abstract function in private part not overloading previous function is not allowed
Unit one.1.ada should not have compiled. RM 3.9.3(10.
For an abstract type declared in a visible part, an abstract
primitive subprogram shall not be declared in the private part, unless
it is overriding an abstract subprogram implicitly declared in the
visible part.
---
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc-4.0.1/configure --prefix=/a/projects/gcc --enable-
languages=ada,c,c++
Thread model: single
gcc version 4.0.1
Built using CYGWIN on a Windows laptop.
--
lap-67: ls -al
total 8
drwxrwxr-x+ 2 geb None0 Aug 14 13:57 .
drwxrwxrwx+ 12 geb None0 Aug 14 13:37 ..
-rw-rw-r-- 1 geb None 3909 Aug 11 22:29 common.gpr
-rw-rw-r-- 1 geb None 331 Aug 14 13:51 one.1.ada
-rw-rw-r-- 1 geb None 312 Aug 14 13:51 one.two.1.ada
-rw-rw-r-- 1 geb None 228 Aug 14 13:52 one.two.2.ada
-rw-rw-r-- 1 geb None 460 Aug 14 13:49 three.2.ada
lap-68: gnat make -P common.gpr three.2.ada
gcc -c -gnata -gnatE -fstack-check -gnatf -gnatm100 -gnatn -gnato -gnatU -
gnatwa -gnatwe -gnatwi -gnatwj -gnatwK -gnatwl -Wuninitialized -gnatVa -pass-
exit-codes -O -g -I- -gnatA -x ada /home/geb/foo.dir/three.2.ada
gcc -c -gnata -gnatE -fstack-check -gnatf -gnatm100 -gnatn -gnato -gnatU -
gnatwa -gnatwe -gnatwi -gnatwj -gnatwK -gnatwl -Wuninitialized -gnatVa -pass-
exit-codes -O -g -I- -gnatA -x ada /home/geb/foo.dir/one.1.ada
gcc -c -gnata -gnatE -fstack-check -gnatf -gnatm100 -gnatn -gnato -gnatU -
gnatwa -gnatwe -gnatwi -gnatwj -gnatwK -gnatwl -Wuninitialized -gnatVa -pass-
exit-codes -O -g -I- -gnatA -x ada /home/geb/foo.dir/one.two.2.ada
gnatbind -E -m50 -Sin -static -we -v -I- -x /home/geb/foo.dir/three.2.ali
GNATBIND 4.0.1
Copyright 1995-2005 Free Software Foundation, Inc.
Binding: three.2.ali
No errors
gnatlink /home/geb/foo.dir/three.2.ali -g -o /home/geb/foo.dir/three
lap-69: ./three
Start
I1 128
I2 128
Finish
lap-70:
Unit one.1.ada should not have compiled.
--
common.gpr
--
project Common is
for Exec_Diruse ".";
for Languages use ( "Ada" );
for Object_Dir use ".";
for Source_Dirs use (".");
package Binder is
for Default_Switches ("Ada")
use ("-E", -- store stack backtrace on raise
"-m50", -- max errors
"-Sin", -- pragma Initialize_Scalars, use inv. val.
"-static", -- use static GNAT runtimes
"-we", -- warnings are errors
"-v"-- verbose output
);
end Binder;
package Builder is
for Default_Switches ("Ada") use ();
for Global_Configuration_Pragmas use "";
for Executable_Suffix use "";
end Builder;
package Compiler is
for Default_Switches ("Ada")
use (
-- is default "-c", -- create .o file
"-gnata", -- pragma Assert
"-gnatE", -- full elab checks
"-fstack-check",-- real stack checking
"-gnatf", -- full errors
"-gnatm100",-- max errors
"-gnatn", -- Allow inlines
"-gnato", -- numeric ovfl chk
-- ASIS "-gnatt", -- ASIS/tree file
-- annoying "-gnatu", -- list unit names
"-gnatU", -- errors say error:
--"-gnatv", -- verbose on errors and more sigh
-- not on Cygwin "-gnatZ", -- 0 cost exceptions
"-gnatwa", -- all warnings
"-gnatwe", -- warning==error
-- does not work well "-gnatwh", -- hiding warnings
"-gnatwi", -- implem. units
"-gnatwj", -- obsolete features
"-gnatwK", -- don't bother me about possible constants
"-gnatwl", -- elab warnings
"-Wuninitialized", -- uninit vars
"-gnatVa", -- all validity chks
"-pass-exit-codes", -- tell me about errors
"-O", -- try to optimize some
"-g"-- debugging
);
for Local_Configuration_Pragmas use "";
end Compiler;
package Cross_Reference is
for Default_Switches ("Ada")
use ("-a", -- do everything, not just locals
"-d", -- reference parent types for deriveds
"-f"-- output full file paths
-- "-u"-- only output unused symbols
);
end
[Bug tree-optimization/22615] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2858
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-14 20:58 --- Fixed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22615
[Bug libfortran/23380] [mingw32] cpu_time intrinsic malfunction
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-08-14 20:56 ---
>From my libgfortran/config.h, configured with --host=mingw32 --target=mingw32
and mingw runtime as distributed by mingw.org
/* Define to 1 if you have the `getrusage' function. */
/* #undef HAVE_GETRUSAGE */
and
/* Define to 1 if you have the `times' function. */
/* #undef HAVE_TIMES */
So maybe you should query the source of your binaries.
FWIW, here is how to get cpu time on NT
#define WIN32_LEAN_AND_MEAN
#include
static void
__winnt_cpu_time (long *sec, long *usec)
{
union {
FILETIME ft;
unsigned long long ulltime;
} kernel_time, user_time;
FILETIME unused1, unused2;
unsigned long long total_time;
/* No support for Win9x. The high order bit of the DWORD
returned by GetVersion is 0 for NT and higher. */
if (GetVersion () >= 0x8000)
{
*sec = -1;
*usec = 0;
return;
}
/* The FILETIME structs filled in by GetProcessTimes represent
time in 100 nanosecond units. */
GetProcessTimes (GetCurrentProcess (), &unused1, &unused2,
&kernel_time.ft, &user_time.ft);
total_time = (kernel_time.ulltime + user_time.ulltime)/10;
*sec = total_time / 100;
*usec = total_time % 100;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23380
[Bug ada/23389] New: subtype declared in generic child can't be used, same subtype elsewhere works
In parent generic declare
type Type_T (<>) is tagged private;
and complete it in the private part.
In generic child unit declare
subtype Subtype_T is One.Type_T;
Then try to use the subtype even with initialization
I2a : Twoo.Subtype_T := Twoo.Init;
and the compiler says: three.2.ada:15:37: error: invalid constraint: type has
no discriminant
But declare the subtype anywhere else and all is happy.
---
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc-4.0.1/configure --prefix=/a/projects/gcc --enable-
languages=ada,c,c++
Thread model: single
gcc version 4.0.1
Built using CYGWIN on a Windows laptop.
--
lap-43: ls -la
total 8
drwxrwxr-x+ 2 geb None0 Aug 14 13:25 .
drwxrwxrwx+ 12 geb None0 Aug 14 13:21 ..
-rw-rw-r-- 1 geb None 3909 Aug 11 22:29 common.gpr
-rw-rw-r-- 1 geb None 239 Aug 11 22:39 one.1.ada
-rw-rw-r-- 1 geb None 118 Aug 11 22:42 one.2.ada
-rw-rw-r-- 1 geb None 180 Aug 11 22:42 one.two.1.ada
-rw-rw-r-- 1 geb None 594 Aug 14 13:25 three.2.ada
lap-44: gnat make -P common.gpr three.2.ada
gcc -c -gnata -gnatE -fstack-check -gnatf -gnatm100 -gnatn -gnato -gnatU \
-gnatwa -gnatwe -gnatwi -gnatwj -gnatwK -gnatwl -Wuninitialized -gnatVa \
-pass-exit-codes -O -g -I- -gnatA -x ada /home/geb/foo.dir/three.2.ada
three.2.ada:15:37: error: invalid constraint: type has no discriminant
gnatmake: "/home/geb/foo.dir/three.2.ada" compilation error
lap-45:
Line 15 of three.2.ada and line 16 are the same except that line 15 is a
subtype that simply renames the type explicitly named on line 16. They
should both compile equally well but they don't. The subtype is declared in
a generic child unit of the generic unit that defines the type. That seems
to be the key. If the subtype is declared anywhere else then all works as
expected. But if declared in the generic child unit then it can't be used.
--
common.gpr
--
project Common is
for Exec_Diruse ".";
for Languages use ( "Ada" );
for Object_Dir use ".";
for Source_Dirs use (".");
package Binder is
for Default_Switches ("Ada")
use ("-E", -- store stack backtrace on raise
"-m50", -- max errors
"-Sin", -- pragma Initialize_Scalars, use inv. val.
"-static", -- use static GNAT runtimes
"-we", -- warnings are errors
"-v"-- verbose output
);
end Binder;
package Builder is
for Default_Switches ("Ada") use ();
for Global_Configuration_Pragmas use "";
for Executable_Suffix use "";
end Builder;
package Compiler is
for Default_Switches ("Ada")
use (
-- is default "-c", -- create .o file
"-gnata", -- pragma Assert
"-gnatE", -- full elab checks
"-fstack-check",-- real stack checking
"-gnatf", -- full errors
"-gnatm100",-- max errors
"-gnatn", -- Allow inlines
"-gnato", -- numeric ovfl chk
-- ASIS "-gnatt", -- ASIS/tree file
-- annoying "-gnatu", -- list unit names
"-gnatU", -- errors say error:
--"-gnatv", -- verbose on errors and more sigh
-- not on Cygwin "-gnatZ", -- 0 cost exceptions
"-gnatwa", -- all warnings
"-gnatwe", -- warning==error
-- does not work well "-gnatwh", -- hiding warnings
"-gnatwi", -- implem. units
"-gnatwj", -- obsolete features
"-gnatwK", -- don't bother me about possible constants
"-gnatwl", -- elab warnings
"-Wuninitialized", -- uninit vars
"-gnatVa", -- all validity chks
"-pass-exit-codes", -- tell me about errors
"-O", -- try to optimize some
"-g"-- debugging
);
for Local_Configuration_Pragmas use "";
end Compiler;
package Cross_Reference is
for Default_Switches ("Ada")
use ("-a", -- do everything, not just locals
"-d", -- reference parent types for deriveds
"-f"-- output full file paths
-- "-u"-- only output unused symbols
);
end Cross_Reference;
package Finder is
[Bug target/21833] simd tests fail in 3.4.4, but not in 3.3.6 or 4.0.1
--- Additional Comments From tg42 at gmx dot de 2005-08-14 19:40 --- Meanwhile, i compiled the simd tests with gcc 4.0.1. It compiles them correctly, i. e. the tests run successfully. It, again, uses the movaps instruction, as does gcc 3.3.6 and unlike 3.4.4. Since all these tests were performed under an otherwise unaltered environment, this looks like a strong indication for a bug in the 3.4.4 P3 code generator. It is well possible, that this bug is not present in 3.4.0. (Which instructions exactly are generated there, BTW?) -- What|Removed |Added Summary|simd tests fail |simd tests fail in 3.4.4, ||but not in 3.3.6 or 4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21833
[Bug fortran/21432] gfortran does not support printing of namelists
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-14 19:30 --- Fixed on mainline and 4.02 There's just the documentation to do, now. Paul T -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21432
[Bug tree-optimization/22615] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2858
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 19:24 --- Subject: Bug 22615 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-14 19:23:57 Modified files: gcc: ChangeLog tree-ssa-structalias.c Added files: gcc/testsuite/g++.dg/tree-ssa: pr22615.C Log message: 2005-08-14 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/22615 * tree-ssa-structalias.c (solution_set_add): Handle first_vi_for_offset returning NULL. (do_da_constraint): Ditto. (do_sd_constraint): Ditto. (do_ds_constraint): Ditto (find_func_aliases): Ditto. (build_constraint_graph): RHS is allowed be ANYTHING. (first_vi_for_offset): Return NULL if we couldn't find anything at the offset. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9728&r2=2.9729 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-structalias.c.diff?cvsroot=gcc&r1=2.26&r2=2.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr22615.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22615
[Bug rtl-optimization/21254] [4.0 regression] Incorrect code with -funroll-loops for multiple targets with same code
--- Additional Comments From dirtyepic dot sk at gmail dot com 2005-08-14 19:24 --- since this is marked critical i want to make sure it doesn't fall between the cracks. this patch still applies cleanly to the 4.0 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21254
[Bug c++/23388] Internal compiler error when -frepo is specified
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 19:22 --- This has already been fixed in 4.0.2. This is a dup of bug 22204. I think Debian should be updating to 4.0.2 soon. *** This bug has been marked as a duplicate of 22204 *** *** This bug has been marked as a duplicate of 22204 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23388
[Bug c++/22204] [4.0/4.1 Regression] [repo] internal compiler error: Segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 19:22 --- *** Bug 23388 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||g dot u dot g dot i at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
[Bug c++/23388] Internal compiler error when -frepo is specified
--- Additional Comments From g dot u dot g dot i at gmx dot de 2005-08-14 19:20 --- Sorry, forgot gcc -v output: [EMAIL PROTECTED]:~/tmp/gccbug$ gcc -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 --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.1 (Debian 4.0.1-2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23388
[Bug middle-end/21137] Convert (a >> 2) & 1 != 0 into a & 4 != 0
--- Additional Comments From roger at eyesopen dot com 2005-08-14 19:17 --- Hi James, Unfortunately, there are a few mistakes in your proposed patch for PR21137. Firstly Kazu's proposed transformation is only valid when the results of the bitwise-AND are being tested for equality or inequality with zero. i.e. its safe to transform "((a >> 2) & 1) != 0" into "(a & 4) != 0" but not "x = (a >> 2) & 1;" into "x = (a & 4)". Your patch is in the general fold path for BIT_AND_EXPR, so you'll transform both. It's surprising there are no testsuite checks for the second example above; it might be worth adding them to prevent anyone making a similar mistake in future. Secondly, this transformation is only valid is c1 + c2 < TYPE_PRECISION(type). Consider the following code: signed char c; if ((c >> 6) & 64) ... this is not equivalent to if (c & (char)(64<<6)) ... i.e. if (c & (char)4096) ... i.e. if (c & 0) ... i.e. if (0) Of course, when c1+c2 >= TYPE_PRECISION(type), there are two additional optimizations that can be performed. If TYPE_UNSIGNED(type) the result is always false, and if !TYPE_UNSIGNED(type), the condition is equivalent to "a < 0". So in the example of mine above, optimization should produce: if (c < 0) ... Finally, in your patch, you use "break", if the transformation is invalid. This isn't really the correct "idiom/style" for fold, where if the guard for a transformation fails, you shouldn't drop out of the switch, but instead continue onto the following/next transformation "in the list". So instead of "if (!guard) break; return transform();", this optimization should be written as "if (guard) return transform();". I haven't looked for other examples for "break" in fold_unary/fold_binary/fold_ternary, but if there are any, they're probably (latent) missed-optimization bugs. Other than that the patch looks good. Thanks for looking into this. -- What|Removed |Added CC||phython at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
[Bug c++/23388] New: Internal compiler error when -frepo is specified
Compiling the following short test code with '-frepo' switch on triggers a
segfault in Debian Sid's current gcc-4.0.
--test.cpp-
class A
{
};
void foo()
{
do
{
throw new A;
} while (0);
}
---
[EMAIL PROTECTED]:~/tmp/gccbug$ g++ -c -Wall -frepo test.cpp
test.cpp:10: 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.
For Debian GNU/Linux specific bug reporting instructions,
see .
Without -frepo there's no error.
Output of g++ -v follows. As it should be trivial to check for anyone with a
newer release/snapshot installed I haven't checked if this bug persists in newer
versions.
--
Summary: Internal compiler error when -frepo is specified
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: g dot u dot g dot i at gmx dot de
CC: g dot u dot g dot i at gmx dot de,gcc-bugs at gcc dot
gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23388
[Bug objc/23381] [4.1 Regression] Next runtime objc exceptions are broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 19:00 --- It works with "4.0.2 20050802" so this is a 4.1 regression for sure. -- What|Removed |Added Known to work||4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23381
[Bug target/23387] New: Weak support
This PR is a placeholder for known limitations regarding the weak support of the HP PA_RISC target under HP-UX 11 and later. This support is available in GCC 3.3 and later. Weak support on this target is implemented using SOM secondary definition (sdef) symbols. While sdef symbols have some of the attributes of weak symbols as defined in the ELF SYSV ABI, they differ in behavior in the following ways: 1) Undefined sdef symbols generate linker and/or runtime errors. 2) The first definition seen by the linker is used (i.e., a primary definition doesn't replace an earlier secondary definition). 3) Secondary symbols in objects linked into a shared object become primary symbols (sdef symbols never appear in shared objects). -- Summary: Weak support Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: hppa*-hp-hpux11* (32-bit only) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23387
[Bug regression/23256] gcc-3.3.6 ICE during bootstrap on arm
--- Additional Comments From buytenh at wantstofly dot org 2005-08-14 18:53 --- Seemingly triggered by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12527#c21 gcc 3.3.3 on armeb appears to miscompile itself when SUBTARGET_CPU_DEFAULT is TARGET_CPU_arm6, but with TARGET_CPU_arm7tdmi it all works fine. I know the 3.3.x branch is closed, but I'm putting this note here just in case anyone else bumps into this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23256
[Bug bootstrap/12527] [3.3/3.4 regression] [arm] bootstrap error on arm-linux, miscompiling genconstants
--- Additional Comments From buytenh at wantstofly dot org 2005-08-14 18:53 --- doko's patch triggers PR23256. gcc 3.3.3 on armeb appears to miscompile itself when SUBTARGET_CPU_DEFAULT is TARGET_CPU_arm6, but with TARGET_CPU_arm7tdmi it all works fine. I know the 3.3.x branch is closed, but I'm putting this note here just in case anyone else bumps into this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12527
[Bug fortran/21432] gfortran does not support printing of namelists
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 18:45 --- Subject: Bug 21432 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-14 18:45:42 Modified files: gcc/fortran: io.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: namelist_print_1.f namelist_print_2.f Log message: 2005-08-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21432. * io.c (match_io): Add code to implement PRINT namelist. 2005-08-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21432. * gfortran.dg/namelist_print_1.f: New test of functionality of PRINT namelist. * gfortran.dg/namelist_print_2.f: New test to check that PRINT namelist generates error with -std=f95. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19.10.8&r2=1.19.10.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.105&r2=1.335.2.106 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/namelist_print_1.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/namelist_print_2.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.334&r2=1.5084.2.335 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21432
[Bug tree-optimization/23386] [4.1 Regression] bitmap.c is being miscompiled (VRP)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
18:02 ---
Here is a testcase which also fail on 64bit targets too:
int f[100];
int g[100];
unsigned char
f1 (int a, int b)
{
__SIZE_TYPE__ ix;
if (a)
return 1;
for (ix = 4; ix--;)
if (f[ix] != g[ix])
return 0;
return 1;
}
int main(void)
{
if (!f1 (0, 2))
__builtin_abort();
return 0;
}
---
--
What|Removed |Added
GCC target triplet|any 32bit taget |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
I have a bad day, output is not the same, in pointer to unsigned long long int bits field.
Today seems that I am stupid , but I can not find process difference
between
function raw_to_ull1 and raw_to_ull_11, if you can see the difference
this is not a bug.
/*
Output:
ull.bit_6 = *(raw + len - 2) = #
ull.bit_7 = *(raw + len - 1) = (
--->llu=8960
ull.bit_7 = *(raw + len - 1) = (
ull.bit_6 = *(raw + len - 2) = #
--->llu=9000
CFLAGS=-Wall -O3 -m32 -march=pentium3 -mcpu=pentium3 --ansi
> Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
*/
/* Fco. J. */
#include
#include
typedef struct Ull
{
unsigned char bit_7:8;
unsigned char bit_6:8;
unsigned char bit_5:8;
unsigned char bit_4:8;
unsigned char bit_3:8;
unsigned char bit_2:8;
unsigned char bit_1:8;
unsigned char bit_0:8;
} Num;
unsigned char
raw_to_ull_1 (register unsigned char *raw, unsigned long long int
*number)
{
register struct Ull ull = { 0, 0, 0, 0, 0, 0, 0, 0 };
register unsigned char len;
unsigned long long int *u;
len = strlen (raw);
if ((len > 8) || (len == 0))
{
return (0);
};
u = (unsigned long long int *) &ull;
switch (len)
{
case 8:
printf ("ull.bit_0 = *(raw + len - 8) = %c\n", *(raw + len - 8));
ull.bit_0 = *(raw + len - 8);
case 7:
printf ("ull.bit_1 = *(raw + len - 7) = %c\n", *(raw + len - 7));
ull.bit_1 = *(raw + len - 7);
case 6:
printf ("ull.bit_2 = *(raw + len - 6) = %c\n", *(raw + len - 6));
ull.bit_2 = *(raw + len - 6);
case 5:
printf ("ull.bit_3 = *(raw + len - 5) = %c\n", *(raw + len - 5));
ull.bit_3 = *(raw + len - 5);
case 4:
printf ("ull.bit_4 = *(raw + len - 4) = %c\n", *(raw + len - 4));
ull.bit_4 = *(raw + len - 4);
case 3:
printf ("ull.bit_5 = *(raw + len - 3) = %c\n", *(raw + len - 3));
ull.bit_5 = *(raw + len - 3);
case 2:
printf ("ull.bit_6 = *(raw + len - 2) = %c\n", *(raw + len - 2));
ull.bit_6 = *(raw + len - 2);
case 1:
printf ("ull.bit_7 = *(raw + len - 1) = %c\n", *(raw + len - 1));
ull.bit_7 = *(raw + len - 1);
*number = *u;
/* printf ("--> %u,%u,%u,%u,%u,%u,%u,%u --> %llu\n", ull.bit_7,
ull.bit_6, ull.bit_5, ull.bit_4, ull.bit_3, ull.bit_2, ull.bit_1,
ull.bit_0, *u);*/
return 1;
default:
return 0;
};
} unsigned char
raw_to_ull_11 (unsigned char *raw, unsigned long long int *number)
{
struct Ull ull = { 0, 0, 0, 0, 0, 0, 0, 0 };
register unsigned char len;
unsigned long long int *u;
len = strlen (raw);
if ((len > 8) || (len == 0))
{
return (0);
};
u = (unsigned long long int *) &ull;
switch (len)
{
case 1:
printf ("ull.bit_7 = *(raw + len - 1) = %c\n", *(raw + len - 1));
ull.bit_7 = *(raw + len - 1);
*number = *u;
return 1;
case 2:
printf ("ull.bit_7 = *(raw + len - 1) = %c\n", *(raw + len - 1));
ull.bit_7 = *(raw + len - 1);
printf ("ull.bit_6 = *(raw + len - 2) = %c\n", *(raw + len - 2));
ull.bit_6 = *(raw + len - 2);
*number = *u;
return 1;
case 3:
printf ("ull.bit_7 = *(raw + len - 1) = %c\n", *(raw + len - 1));
ull.bit_7 = *(raw + len - 1);
printf ("ull.bit_6 = *(raw + len - 2) = %c\n", *(raw + len - 2));
ull.bit_6 = *(raw + len - 2);
printf ("ull.bit_5 = *(raw + len - 3) = %c\n", *(raw + len - 3));
ull.bit_5 = *(raw + len - 3);
*number = *u;
return 1;
case 4:
printf ("ull.bit_7 = *(raw + len - 1) = %c\n", *(raw + len - 1));
ull.bit_7 = *(raw + len - 1);
printf ("ull.bit_6 = *(raw + len - 2) = %c\n", *(raw + len - 2));
ull.bit_6 = *(raw + len - 2);
printf ("ull.bit_5 = *(raw + len - 3) = %c\n", *(raw + len - 3));
ull.bit_5 = *(raw + len - 3);
printf ("ull.bit_4 = *(raw + len - 4) = %c\n", *(raw + len - 4));
ull.bit_4 = *(raw + len - 4);
*number = *u;
return 1;
case 5:
printf ("ull.bit_7 = *(raw + len - 1) = %c\n", *(raw + len - 1));
ull.bit_7 = *(raw + len - 1);
printf ("ull.bit_6 = *(raw + len - 2) = %c\n", *(raw + len - 2));
ull.bit_6 = *(raw + len - 2);
printf ("ull.bit_5 = *(raw + len - 3) = %c\n", *(raw + len - 3));
ull.bit_5 = *(raw + len - 3);
printf ("ull.bit_4 = *(raw + len - 4) = %c\n", *(raw + len - 4));
ull.bit_4 = *(raw + len - 4);
printf ("ull.bit_3 = *(raw + len - 5) = %c\n", *(raw + len - 5));
ull.bit_3 = *(raw + len - 5);
*number = *u;
return 1;
case 6:
printf ("ull.bit_7 = *(raw + len - 1) = %c\n", *(raw + len - 1));
ull.bit_7 = *(raw + len - 1);
printf ("ull.bit_6 = *(raw + l
[Bug tree-optimization/23386] [4.1 Regression] bitmap.c is being miscompiled (VRP)
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-14
17:57 ---
Subject: Re: [4.1 Regression] bitmap.c is
being miscompiled (VRP)
On Sun, 2005-08-14 at 17:32 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
> 17:32 ---
> Here is something which is a little more reduced:
> int f[100];
> int g[100];
> unsigned char
> f1 (int a, int b)
> {
> unsigned ix;
> if (a == b)
> return 1;
> for (ix = 4; ix--;)
> if (f[ix] != g[ix])
> return 0;
> return 1;
> }
>
> int main(void)
> {
> if (!f1 (1, 2))
> __builtin_abort();
> return 0;
> }
>
>
The SSA version used in the pointer arithmetic doesn't wrap. The other
SSA versions do.
We can't afford to simply assume that everything wraps, or else we can't
calculate the number of iterations on pretty much any loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
Re: [Bug tree-optimization/23386] [4.1 Regression] bitmap.c is being miscompiled (VRP)
On Sun, 2005-08-14 at 17:32 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
> 17:32 ---
> Here is something which is a little more reduced:
> int f[100];
> int g[100];
> unsigned char
> f1 (int a, int b)
> {
> unsigned ix;
> if (a == b)
> return 1;
> for (ix = 4; ix--;)
> if (f[ix] != g[ix])
> return 0;
> return 1;
> }
>
> int main(void)
> {
> if (!f1 (1, 2))
> __builtin_abort();
> return 0;
> }
>
>
The SSA version used in the pointer arithmetic doesn't wrap. The other
SSA versions do.
We can't afford to simply assume that everything wraps, or else we can't
calculate the number of iterations on pretty much any loop.
[Bug tree-optimization/23386] [4.1 Regression] bitmap.c is being miscompiled (VRP)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
17:32 ---
Here is something which is a little more reduced:
int f[100];
int g[100];
unsigned char
f1 (int a, int b)
{
unsigned ix;
if (a == b)
return 1;
for (ix = 4; ix--;)
if (f[ix] != g[ix])
return 0;
return 1;
}
int main(void)
{
if (!f1 (1, 2))
__builtin_abort();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug tree-optimization/23386] [4.1 Regression] bitmap.c is being miscompiled (VRP)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
17:18 ---
We get:
ix_14: [0, 3] EQUIVALENCES: { } (0 elements)
which is wrong as it should be the union of [0,3] and [-1,-1].
so we are folding:
Folding predicate ix_14 != 4294967295 to 1
--
What|Removed |Added
Summary|[4.1 Regression] ICE: |[4.1 Regression] bitmap.c is
|SIGSEGV at bitmap.c:780 |being miscompiled (VRP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug tree-optimization/23386] [4.1 Regression] ICE: SIGSEGV at bitmap.c:780
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
17:16 ---
Confirmed now, testcase:
typedef unsigned long BITMAP_WORD;
typedef struct bitmap_element_def
{
struct bitmap_element_def *next;
struct bitmap_element_def *prev;
unsigned int indx;
BITMAP_WORD bits[4];
} bitmap_element;
typedef struct bitmap_head_def {
bitmap_element *first;
bitmap_element *current;
unsigned int indx;
} bitmap_head;
typedef struct bitmap_head_def *bitmap;
int f[100];
int g[100];
unsigned char
bitmap_equal_p (bitmap a, bitmap b)
{
bitmap_element *a_elt;
bitmap_element *b_elt;
unsigned ix;
for (a_elt = a->first, b_elt = b->first;
a_elt && b_elt;
a_elt = a_elt->next, b_elt = b_elt->next)
{
if (a_elt->indx != b_elt->indx)
return 0;
for (ix = 4; ix--;)
{
if (f[ix] != g[ix])
{
return 0;
}
}
}
return 1;
}
int main(void)
{
bitmap a;
a = __builtin_calloc (sizeof(*a),1);
bitmap b;
b = __builtin_calloc (sizeof(*b),1);
a->first = __builtin_calloc(sizeof(*a->first), 1);
b->first = __builtin_calloc(sizeof(*b->first), 1);
for(int i = 0;i<5;i++)
{
a->first->bits[i] = i;
b->first->bits[i] = i;
}
if (!bitmap_equal_p (a, b))
__builtin_abort();
return 0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-14 17:16:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug libfortran/23380] [mingw32] cpu_time intrinsic malfunction
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-14 16:48 --- (In reply to comment #3) > I don't know why you say that "MingW claims to have a HAVE_TIMES". > It doesn't. > Read the code for __cpu_time_1. The only way that cpu_time can return zero is if HAVE_TIMES is defined or if MingW has getrusage() and getrusage is broken. > Would an ifdef _WIN32 clause be acceptable in cpu_time.c. IMO, no. There are no other _WIN32 clauses in gfortran. As soon as you add the first one, there will be a proliferation of OS specific clauses in gfortran. What we need to understand is why cpu_time isn't returning -1, which is standard conforming. So, does config.h contain HAVE_GETRUSAGE or HAVE_TIMES defined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23380
[Bug c++/21498] clause 7.1.5.3/2 of the c++ is not enforced
--- Additional Comments From fn_x at hotmail dot com 2005-08-14 16:48 --- *** Bug 23385 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||fn_x at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21498
[Bug c++/23385] gcc accepts "class typedefname" when typedefname is defined in a nested class and references a template parameter
--- Additional Comments From fn_x at hotmail dot com 2005-08-14 16:48 --- Yeah, this is just slightly different code, but it is covered by that bug's summary and description. Sorry for the noise. *** This bug has been marked as a duplicate of 21498 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23385
[Bug fortran/21432] gfortran does not support printing of namelists
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 16:15 --- Subject: Bug 21432 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-14 16:15:46 Modified files: gcc/fortran: io.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: namelist_print_1.f namelist_print_2.f Log message: 2005-08-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21432. * io.c (match_io): Add code to implement PRINT namelist. 2005-08-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21432. * gfortran.dg/namelist_print_1.f: New test of functionality of PRINT namelist. * gfortran.dg/namelist_print_2.f: New test to check that PRINT namelist generates error with -std=f95. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&r1=1.29&r2=1.30 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.521&r2=1.522 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/namelist_print_1.f.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/namelist_print_2.f.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5920&r2=1.5921 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21432
[Bug tree-optimization/23386] [4.1 Regression] ICE: SIGSEGV at bitmap.c:780
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 15:53 --- (In reply to comment #2) > Compiling bitmap.c at -O0 make bootstrap past this point. On ppc-darwin that is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From tobi at gcc dot gnu dot org 2005-08-14 15:53 --- An alternative approach to setting up a temporary in the caller would be to have pointer-valued functions use a fake result variable, which only immediately before returning gets assigned to the real result. This would allow the optimizers to do a good job if nothing bad can happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug tree-optimization/23386] [4.1 Regression] ICE: SIGSEGV at bitmap.c:780
-- What|Removed |Added Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-14 15:50 --- Updated patch for Part 2 posted in: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00195.html -- What|Removed |Added URL|http://gcc.gnu.org/ml/java- |http://gcc.gnu.org/ml/java- |patches/2005- |patches/2005- |q2/msg00742.html|q3/msg00195.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug middle-end/23386] [4.1 Regression] ICE: SIGSEGV at bitmap.c:780
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 15:50 --- Compiling bitmap.c at -O0 make bootstrap past this point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug target/23303] [4.1 Regression] 4.1 generates sall + addl instead of leal
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
15:48 ---
Smaller test case:
=
typedef struct {
char **visbuf;
char **allbuf;
} TScreen;
void
VTallocbuf(TScreen *screen, unsigned long savelines)
{
screen->visbuf = &screen->allbuf[savelines];
}
=
On AMD64 this gives me:
salq$3, %rsi
addq8(%rdi), %rsi
movq%rsi, (%rdi)
ret
instead of
movq8(%rdi), %rax
leaq(%rax,%rsi,8), %rsi
movq%rsi, (%rdi)
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23303
[Bug middle-end/23386] [4.1 Regression] ICE: SIGSEGV at bitmap.c:780
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 15:40 --- This effects all 32bit targets it seems. See also http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00831.html which is what I reported about which patch caused it. -- What|Removed |Added CC||spop at gcc dot gnu dot org Severity|normal |critical GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu |any 32bit taget Keywords||build, wrong-code Summary|ICE: SIGSEGV at bitmap.c:780|[4.1 Regression] ICE: ||SIGSEGV at bitmap.c:780 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug middle-end/23386] New: ICE: SIGSEGV at bitmap.c:780
In stage2, the following fault occurs:
mv tmp-libgcc.mk libgcc.mk
./xgcc -B./ -B/home/dave/opt/gnu/gcc/gcc-4.1.0/hppa-linux/bin/ -isystem /home/da
ve/opt/gnu/gcc/gcc-4.1.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-
4.1.0/hppa-linux/sys-include -L/home/dave/gnu/gcc-4.0/objdir/gcc/../ld -O2 -O2 -
g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-protot
ypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc/gcc -I../..
/gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -g0 -f
inhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initializ
ed-in-bss -fno-unit-at-a-time \
-c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
xgcc: Internal error: Segmentation fault (program cc1)
(gdb) r `cat xx.sh`
Starting program: /home/dave/gnu/gcc-4.0/objdir/gcc/cc1 `cat xx.sh`
GNU C version 4.1.0 20050814 (experimental) (hppa-linux)
compiled by GNU C version 4.1.0 20050814 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed: -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -iprefix
-isystem -DIN_GCC -DCRT_BEGIN -isystem -isystem -isystem -auxbase-strip -g
-g0 -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-unit-at-a-time
options enabled: -falign-loops -fargument-alias -fbranch-count-reg
-fcaller-saves -fcommon -fcprop-registers -fcrossjumping
-fcse-follow-jumps -fcse-skip-blocks -fdefer-pop -fdelayed-branch
-fdelete-null-pointer-checks -fearly-inlining
-feliminate-unused-debug-types -fexpensive-optimizations -ffunction-cse
-fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion
-fif-conversion2 -finhibit-size-directive -fipa-pure-const -fipa-reference
-fipa-type-escape -fivopts -fkeep-static-consts -fleading-underscore
-floop-optimize -floop-optimize2 -fmath-errno -fmerge-constants
-fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls
-fpeephole -fpeephole2 -freg-struct-return -fregmove -freorder-blocks
-freorder-functions -frerun-cse-after-loop -frerun-loop-opt
-fsched-interblock -fsched-spec -fsched-stalled-insns-dep -fschedule-insns
-fschedule-insns2 -fshow-column -fsplit-ivs-in-unroller -fstrength-reduce
-fstrict-aliasing -fthread-jumps -ftrapping-math -ftree-ccp -ftree-ch
-ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts
-ftree-dse -ftree-fre -ftree-loop-im -ftree-loop-ivcanon
-ftree-loop-optimize -ftree-lrs -ftree-pre -ftree-salias -ftree-sink
-ftree-sra -ftree-store-ccp -ftree-store-copy-prop -ftree-ter -ftree-vrp
-fvar-tracking -mbig-switch -mgas -mno-space-regs
Compiler executable checksum: f95f669b69fe7f9c73b928e96fbc74e7
vprintf getchar getc_unlocked getchar_unlocked putchar fputc_unlocked
putc_unlocked putchar_unlocked getline feof_unlocked ferror_unlocked
__strcspn_c1
__strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3 __strpbrk_c2
__strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c strtod strtol
strtoul strtof strtold strtoq strtouq strtoll strtoull atof atoi atol atoll
get_cie next_fde last_fde __do_global_dtors_aux
Program received signal SIGSEGV, Segmentation fault.
bitmap_and_compl_into (a=0x5999fc, b=Variable "b" is not available.
) at ../../gcc/gcc/bitmap.c:780
780 BITMAP_WORD cleared = a_elt->bits[ix] & b_elt->bits[ix];
(gdb) p/x $pc
$3 = 0x12fcd4
0x0012fcd4 : ldw 18(,r20),r19
(gdb) p/x $r20
$2 = 0x4e1fe4
(gdb) x/x 0x4e1fe4
0x4e1fe4: Cannot access memory at address 0x4e1fe4
(gdb) bt
#0 bitmap_and_compl_into (a=0x5999fc, b=Variable "b" is not available.
) at ../../gcc/gcc/bitmap.c:780
#1 0x000c5540 in insert_phi_nodes_for (var=0x403e2898,
phi_insertion_points=0x5999fc, update_p=1 '\001')
at ../../gcc/gcc/tree-into-ssa.c:806
#2 0x000c6074 in insert_updated_phi_nodes_for (var=0x403e2898, dfs=0x80,
blocks=0x5998a4, update_flags=2) at ../../gcc/gcc/tree-into-ssa.c:2476
#3 0x000c9b84 in update_ssa (update_flags=128)
at ../../gcc/gcc/tree-into-ssa.c:2771
My first guess is that this loop has been miscompiled:
for (ix = BITMAP_ELEMENT_WORDS; ix--;)
{
BITMAP_WORD cleared = a_elt->bits[ix] & b_elt->bits[ix];
BITMAP_WORD r = a_elt->bits[ix] ^ cleared;
a_elt->bits[ix] = r;
changed |= cleared;
ior |= r;
}
In the call to bitmap_and_compl_into that fails, the loop iterates
94061 times before the SIGSEGV.
The last successful build was updated at Aug 13 01:18:00 UTC 2005.
--
Summary: ICE: SIGSEGV at bitmap.c:780
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priori
[Bug java/22113] Buffer overflow in the lexical analyser while reading FP literals
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-14 15:16 --- These days, this bug manifests itself on mainline regularly as: FAIL: 3.10.2-round-6 in the Jacks testsuite. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-14 15:16:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22113
[Bug target/23360] [4.1 regression] -ffast-math startup broken on i686 (maybe Athlon-xp)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 14:29 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23360
[Bug target/23360] [4.1 regression] -ffast-math startup broken on i686 (maybe Athlon-xp)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 14:27 --- Subject: Bug 23360 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-14 14:26:51 Modified files: gcc: ChangeLog gcc/config/i386: crtfastmath.c Log message: 2005-08-14 H.J. Lu <[EMAIL PROTECTED]> PR target/23360 * config/i386/crtfastmath.c (set_fast_math): Check if DAZ is available for setting it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9726&r2=2.9727 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/crtfastmath.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23360
[Bug c++/23385] gcc accepts "class typedefname" when typedefname is defined in a nested class and references a template parameter
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 14:22 --- I think this is a dup of bug 21498 but I don't time to double check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23385
[Bug target/23378] [4.1 Regression] code quality regression for complicated loop
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 14:06 --- I think this is related to PR 23302 and PR 23303 since those look like they were caused by the same patch. -- What|Removed |Added BugsThisDependsOn||23302, 23303 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
[Bug tree-optimization/23320] [4.1 Regression] ICE in in base_addr_differ_p, at tree-data-ref.c:430
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 14:03 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23320
[Bug tree-optimization/22228] [4.1 regression] ICE with -ftree-vectorize in verify_ssa
--- Additional Comments From dorit at il dot ibm dot com 2005-08-14 14:00 --- patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00826.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug target/23378] [4.1 Regression] code quality regression for complicated loop
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14 13:57 --- Ouch. This badly needs reducing... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
[Bug target/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14 12:55 --- This patch is a bit paradoxical: There is an insn that we want to expand in the unroller, so we know that have_insn_for *should* return true if the MD is sane. But the MD can't be sane for an insane ISA combination like x87/mmx. So indeed, the insn that src comes from is valid but the insn does not exist according to have_insn_for. This happens because have_insn_for checks that there is an optab for this combination of operation and mode. The patch is obviously suboptimal (Uros' patch would fix the problem for real, someone review it please! :-) but probably this kind of precaution is a good idea anyway... Index: loop-unroll.c === RCS file: /cvs/gcc/gcc/gcc/loop-unroll.c,v retrieving revision 1.37 diff -u -3 -p -r1.37 loop-unroll.c --- loop-unroll.c 3 Aug 2005 13:34:35 - 1.37 +++ loop-unroll.c 14 Aug 2005 12:51:16 - @@ -1574,6 +1574,9 @@ analyze_insn_to_expand_var (struct loop && GET_CODE (src) != MINUS && GET_CODE (src) != MULT) return NULL; + + if (!have_insn_for (GET_CODE (src), GET_MODE (src))) +return NULL; if (!XEXP (src, 0)) return NULL; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug fortran/23379] compiler segfault with internal write
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-14 12:40 --- (In reply to comment #2) > Confirmed. This is really pr15966, although this latter has been marked as being resolved. Feng Wang's patch allowed arrays to be used as internal units when there is no editing involving records. Array sections violate the same section of the compiler. Jerry DeLisle and I are working on this. I have provided a front-end patch that transmits the array descriptor to the library. Jerry is putting together the library part. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23379
[Bug target/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14 12:26 --- There is a patch t fix the issue mentioned in that mmx.md comment, see http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html -- What|Removed |Added CC||rth at gcc dot gnu dot org, ||uros at gcc dot gnu dot org BugsThisDependsOn||19161 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug target/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14 12:22 --- >From config/i386/mmx.md: ;; Note! Except for the basic move instructions, *all* of these ;; patterns are outside the normal optabs namespace. This is because ;; use of these registers requires the insertion of emms or femms ;; instructions to return to normal fpu mode. The compiler doesn't ;; know how to do that itself, which means it's up to the user. Which ;; means that we should never use any of these patterns except at the ;; direction of the user via a builtin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug target/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14 11:40 --- My uneducated guess is that expand_binop can't find an appropriate obtab. That means that this problem is target specific (e.g. missing named pattern). -- What|Removed |Added Component|rtl-optimization|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug rtl-optimization/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
11:36 ---
GCC tries to unroll and expand this insn:
(insn 28 26 30 2 (set (reg/v:V2SI 65 [ sum ])
(plus:V2SI (reg/v:V2SI 65 [ sum ])
(reg/v:V2SI 68 [ ref1 ]))) 1023 {mmx_addv2si3} (nil)
(nil))
But for some reason the force_operand call in combine_var_copies_in_loop_exit
returns NULL, in other words it fails to synthesize this insn in the unrolled
copies. At that point we have:
2088 expr = force_operand (sum, ve->reg);
(gdb) p debug_rtx(ve->insn)
(insn 28 26 30 2 (set (reg/v:V2SI 65 [ sum ])
(plus:V2SI (reg/v:V2SI 65 [ sum ])
(reg/v:V2SI 68 [ ref1 ]))) -1 (nil)
(nil))
$42 = void
(gdb) p debug_rtx(ve->reg)
(reg/v:V2SI 65 [ sum ])
$43 = void
(gdb) p debug_rtx(sum)
(plus:V2SI (reg:V2SI 76)
(reg/v:V2SI 65 [ sum ]))
$44 = void
(gdb)
2089 if (expr != ve->reg)
(gdb) p expr
$45 = 0x0
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug c++/23385] New: gcc accepts "class typedefname" when typedefname is defined in a nested class and references a template parameter
Hello,
All versions of gcc I tried (2.95.3, 3.3.6, 3.4.4, 4.0-20050811, and
4.1-20050813) accept this code without any warnings or errors (using -ansi
-pedantic -Wall -W, just in case)
template
class A {
struct helper { typedef T type; };
friend class helper::type;
};
class B { A m; } b;
int main() {}
I don't believe this code is valid. icc 9.0.021 rejects this code with
error: typedef "type" may not be used in an elaborated type specifier
and gcc 4.0-20050811 rejects it when I try the same thing with A::type,
rather than A::helper::type, with
error: using template type parameter T after class
Additionally, any attempts at using "class A::helper::type" outside of the
template definition result in
error: using typedef-name A::helper::type after class
So I think my code should result in either of the above two errors as well.
I can't find any other reports of this, but sorry if I missed anything.
--
Summary: gcc accepts "class typedefname" when typedefname is
defined in a nested class and references a template
parameter
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fn_x at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23385
[Bug libfortran/23380] [mingw32] cpu_time intrinsic malfunction
--- Additional Comments From edunlop at utvinternet dot ie 2005-08-14 09:41 --- Subject: RE: [mingw32] cpu_time intrinsic malfunction Danny I would consider your suggestion very acceptable - it is obviously not 100% but would sort the problem for many users, including myself. Thank you to all who replied re this problem. Edmund. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23380
[Bug libfortran/23380] [mingw32] cpu_time intrinsic malfunction
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-08-14 07:29 --- I don't know why you say that "MingW claims to have a HAVE_TIMES". It doesn't. To get process times on mingw we need to use the win32api function GetProcessTimes. This is available on NT4 and later but not on win9x. Would an ifdef _WIN32 clause be acceptable in cpu_time.c. If so, I will submit a patch. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23380
