[Bug rtl-optimization/16968] [3.4 Regression] loop optimizer miscompilation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 07:58 --- Subject: Bug 16968 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-18 07:58:12 Modified files: gcc: ChangeLog loop.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20041218-1.c Log message: PR rtl-optimization/16968 * loop.c (scan_loop): Stop scanning the loop for movable insns as soon as an optimization barrier is encountered. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.746&r2=2.2326.2.747 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.488.2.5&r2=1.488.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.331&r2=1.3389.2.332 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20041218-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16968
[Bug rtl-optimization/16968] [3.4 Regression] loop optimizer miscompilation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 07:55 --- Subject: Bug 16968 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-18 07:55:42 Modified files: gcc: ChangeLog loop.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20041218-1.c Log message: PR rtl-optimization/16968 * loop.c (scan_loop): Stop scanning the loop for movable insns as soon as an optimization barrier is encountered. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6872&r2=2.6873 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop.c.diff?cvsroot=gcc&r1=1.517&r2=1.518 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4779&r2=1.4780 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20041218-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16968
[Bug target/18863] [4.0 Regression] ICE in find_reloads
-- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18863
[Bug target/19046] [4.0 Regression] MOVE_RATIO should be tweaked on ppc
-- What|Removed |Added Summary|[4.0 Regression] MOVE_RATIO |[4.0 Regression] MOVE_RATIO |should be tweaked |should be tweaked on ppc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19046
[Bug middle-end/18897] [4.0 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: putchar (first referenced in build/gengenrtl.o) (data)
--- Additional Comments From zack at gcc dot gnu dot org 2004-12-18 06:42 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18897
[Bug middle-end/18897] [4.0 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: putchar (first referenced in build/gengenrtl.o) (data)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 06:38 --- Subject: Bug 18897 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-18 06:38:26 Modified files: gcc: ChangeLog toplev.c Log message: PR 18897 * toplev.c (compile_file): Call process_pending_assemble_externals just before targetm.asm_out.file_end. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6871&r2=2.6872 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcc&r1=1.934&r2=1.935 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18897
[Bug bootstrap/18972] Regression: bootstrap failure of gcc-4.0-20041212 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1): Bootstrap comparison failure
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2004-12-18 05:38 --- please note (I might not have stated this clearly enough in comment #4): the bootstrap doesn't fail if: '-fomit-frame-pointer' is omitted (by specifying BOOT_CFLAGS="-O2 -g" instead of BOOT_CFLAGS="- O2 -g -fomit-frame-pointer" (which is the default and doesn't need to be specified) or if: '-save-temps' is specified (for instance: BOOT_CFLAGS="-O2 -g -fomit-frame-pointer -save-temps" works) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18972
[Bug bootstrap/18972] Regression: bootstrap failure of gcc-4.0-20041212 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1): Bootstrap comparison failure
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2004-12-18 05:22 --- Created an attachment (id=7776) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7776&action=view) diff between stage2 and stage3 reload.o otool -tV output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18972
[Bug bootstrap/18972] Regression: bootstrap failure of gcc-4.0-20041212 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1): Bootstrap comparison failure
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2004-12-18 05:21 --- Created an attachment (id=7775) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7775&action=view) reload.o of stage3 mangled through otool -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18972
[Bug bootstrap/18972] Regression: bootstrap failure of gcc-4.0-20041212 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1): Bootstrap comparison failure
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2004-12-18 05:20 --- Created an attachment (id=7774) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7774&action=view) reload.o of stage2 mangled through otool -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18972
[Bug bootstrap/18972] Regression: bootstrap failure of gcc-4.0-20041212 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1): Bootstrap comparison failure
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2004-12-18 05:18 --- (In reply to comment #6) > (In reply to comment #5) > > Indeed a Heisenbug: > > > > Does anyone know how I could disassemble those .o files to get something > > more > > human readable? > > Use otool. Did so. I copied the reload.o files that were created by: make restage2 BOOT_CFLAGS="-O2 -g -fomit-frame-pointer" and: make restage3 BOOT_CFLAGS="-O2 -g -fomit-frame-pointer" into: GCC/FSF/bootstrap-failure_gcc-4.0-20041212/stage2 and: GCC/FSF/bootstrap-failure_gcc-4.0-20041212/stage3 and then did the following with them: otool -tV GCC/FSF/bootstrap-failure_gcc-4.0-20041212/stage3/reload.o &> stage3.reload.o.otool.s otool -tV GCC/FSF/bootstrap-failure_gcc-4.0-20041212/stage2/reload.o &> stage2.reload.o.otool.s which yielded two nice assembler files that I'll attach here (plus a diff for quick overview) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18972
[Bug rtl-optimization/8361] [3.3/3.4/4.0 regression] C++ compile-time performance regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 04:13 --- (In reply to comment #39) > Here is the current results for 3.3.2 vs the mainline: Now I am getting results that -O3 is faster than -O2, that is not right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
[Bug c++/19004] [3.4/4.0 regression] ICE in uses_template_parms at cp/pt.c:4860
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19004
[Bug target/19051] m6811-elf-gcc ICE
-- What|Removed |Added Known to fail||3.4.4 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19051
[Bug tree-optimization/19050] [4.0 Regression] optimization bug in 4.0-20041212 snapshot
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 03:50 --- Thanks for testing, closing as fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19050
[Bug tree-optimization/19050] [4.0 Regression] optimization bug in 4.0-20041212 snapshot
--- Additional Comments From jasonp at boo dot net 2004-12-18 03:48 --- (In reply to comment #1) > I could reproduce it with 20041208 but with 20041214 it is fixed, can you test a newer GCC? Latest CVS works fine. Ticket can close. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19050
[Bug libfortran/19064] runtime error when reading complex*16 using formatted I/O
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 03:48 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-18 03:48:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19064
[Bug target/17471] glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 03:43 --- Does this happen in 3.4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17471
[Bug other/17543] #pragma weak undocumented
-- What|Removed |Added Component|c |other Keywords||documentation Last reconfirmed|2004-09-18 01:21:22 |2004-12-18 03:42:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17543
[Bug libgcj/14009] libgcj HttpURLConnection does not handle situation where retrieving url without trailing slash after domain.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 02:29 --- *** Bug 19066 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||zhsoft88 at sohu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14009
[Bug libgcj/19066] the URL and URLConnection class should be enhanced
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 02:29 --- This is a dup of bug 14009 which is fixed on the mainline. *** This bug has been marked as a duplicate of 14009 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19066
[Bug libgcj/19066] the URL and URLConnection class should be enhanced
-- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19066
[Bug java/19066] New: the URL and URLConnection class should be enhanced
1. create B.java:
import java.io.*;
import java.net.*;
public class B {
public static void main(String[] args) {
URL javacodingURL = null;
try {
javacodingURL = new URL(args[0]);
System.out.println("protocol = " + javacodingURL.getProtocol());
System.out.println("host = " + javacodingURL.getHost());
System.out.println("filename = " + javacodingURL.getFile());
System.out.println("port = " + javacodingURL.getPort());
}catch(MalformedURLException e){
// Malformed URL
System.out.println("Error in given URL");
return;
}
try {
URLConnection connection = javacodingURL.openConnection();
System.out.println("conn="+connection);
System.out.println(connection.getContentType());
BufferedReader br = new BufferedReader(new
InputStreamReader(connection.getInputStream()));
String line = "";
while ((line = br.readLine()) != null)
System.out.println(line);
br.close();
}catch(UnknownHostException e){
System.out.println("Unknown Host");
return;
}catch(IOException e){
System.out.println("Error in opening URLConnection, Reading or Writing");
return;
}
}
}
2. Compile it:
gcj -fjni --main=B B.java
3. Run it:
./a.out http://www.opendesktop.net
The output is:
protocol = http
host = www.opendesktop.net
filename =
port = -1
conn=gnu.gcj.protocol.http.Connection:http://www.opendesktop.net
null
Error in opening URLConnection, Reading or Writing
Error happened. But, if you compile B.java with javac, then run
java B http://www.opendesktop.net
The output is OK, no error happened.
And I also found that when you run like this:
./a.out http://www.opendesktop.net/
The output is also OK.
I think the URL and URLConnection class should be enhanced .
--
Summary: the URL and URLConnection class should be enhanced
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zhsoft88 at sohu dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19066
[Bug target/18916] [4.0 Regression] mis-aligned vector code with copy memory (-maltivec)
--- Additional Comments From fjahanian at apple dot com 2004-12-18 01:46
---
And this is the patch that I had in mind. Can this break ABI compatibily? My
limited testing shows
that it does not.
Index: rs6000.c
===
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.332.2.46.2.84
diff -c -p -r1.332.2.46.2.84 rs6000.c
*** rs6000.c16 Dec 2004 03:23:30 - 1.332.2.46.2.84
--- rs6000.c18 Dec 2004 01:44:28 -
*** function_arg_boundary (enum machine_mode
*** 5190,5195
--- 5190,5201
|| (type && TREE_CODE (type) == VECTOR_TYPE
&& int_size_in_bytes (type) >= 16))
return 128;
+ else if (DEFAULT_ABI == ABI_DARWIN && mode == BLKmode
+ && TYPE_ALIGN (type) >= 128)
+ {
+ TYPE_ALIGN (type) = PARM_BOUNDARY;
+ return PARM_BOUNDARY;
+ }
else
return PARM_BOUNDARY;
}
(In reply to comment #5)
> Followin patch fixes the alignment problem. But it cannot be applied because
> it breaks ABI
> compatibilty.
>
> A possible solution is to relax alignment of the type in question (with
> alignment of 128) to that of the
> PARM_BOUNDARY (32). This will not (should not ?) break the ABI compatibility
> (because it is currently
> on PARM_BOUNDARY). But it will prevent vector code to be generated (which is
> cause of the abort).
> Comments are most welcome.
>
>
> Index: rs6000.c
>
===
>
> RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
> retrieving revision 1.332.2.46.2.84
> diff -c -p -r1.332.2.46.2.84 rs6000.c
> *** rs6000.c16 Dec 2004 03:23:30 - 1.332.2.46.2.84
> --- rs6000.c18 Dec 2004 00:20:54 -
> *** function_arg_boundary (enum machine_mode
> *** 5190,5195
> --- 5190,5197
>|| (type && TREE_CODE (type) == VECTOR_TYPE
>&& int_size_in_bytes (type) >= 16))
> return 128;
> + else if (DEFAULT_ABI == ABI_DARWIN && mode == BLKmode)
> + return MAX (TYPE_ALIGN (type), PARM_BOUNDARY);
> else
> return PARM_BOUNDARY;
> }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18916
[Bug c++/17456] [3.3 regression] ICE when brackets missing from member function call
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-18 01:36 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01329.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17456
[Bug target/18371] [3.4/4.0 Regression] array subscript out of range in gcc sources
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 01:28 --- Obvious patch posted here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01328.html This is not a wrong-code bug. At worst it will crash the compiler, but probably it just works by luck, because of stack alignment. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18371
[Bug c++/19044] Alternate asm name for atan ignored when calling __builtin_atan
--- Additional Comments From austern at apple dot com 2004-12-18 01:17
---
The code in the C front end that handles this is in finish_decl, in c-decl.c:
if (TREE_CODE (decl) == FUNCTION_DECL && asmspec)
{
if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
{
tree builtin = built_in_decls [DECL_FUNCTION_CODE (decl)];
set_user_assembler_name (builtin, asmspec);
if (DECL_FUNCTION_CODE (decl) == BUILT_IN_MEMCPY)
init_block_move_fn (asmspec);
else if (DECL_FUNCTION_CODE (decl) == BUILT_IN_MEMSET)
init_block_clear_fn (asmspec);
}
set_user_assembler_name (decl, asmspec);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044
[Bug target/18916] [4.0 Regression] mis-aligned vector code with copy memory (-maltivec)
--- Additional Comments From fjahanian at apple dot com 2004-12-18 00:43 --- Followin patch fixes the alignment problem. But it cannot be applied because it breaks ABI compatibilty. A possible solution is to relax alignment of the type in question (with alignment of 128) to that of the PARM_BOUNDARY (32). This will not (should not ?) break the ABI compatibility (because it is currently on PARM_BOUNDARY). But it will prevent vector code to be generated (which is cause of the abort). Comments are most welcome. Index: rs6000.c === RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v retrieving revision 1.332.2.46.2.84 diff -c -p -r1.332.2.46.2.84 rs6000.c *** rs6000.c16 Dec 2004 03:23:30 - 1.332.2.46.2.84 --- rs6000.c18 Dec 2004 00:20:54 - *** function_arg_boundary (enum machine_mode *** 5190,5195 --- 5190,5197 || (type && TREE_CODE (type) == VECTOR_TYPE && int_size_in_bytes (type) >= 16)) return 128; + else if (DEFAULT_ABI == ABI_DARWIN && mode == BLKmode) + return MAX (TYPE_ALIGN (type), PARM_BOUNDARY); else return PARM_BOUNDARY; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18916
[Bug target/19065] Make CRIS libstdc++ asms autoincrement-safe
-- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-18 00:40:27 date|| Summary|Make CRIS asms |Make CRIS libstdc++ asms |autoincrement-safe |autoincrement-safe Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
[Bug target/19065] New: Make CRIS asms autoincrement-safe
This is a FIXME that I need to free a constraint letter (probably the existing R) as a constraint for (MEM reg), or more to the point, a side-effect-free memory constraint: the libstdc++ asms are buggy and could get autoincrement. Actually, there should be a generic constraint letter for that: just as "V" is disjoint to "o", there needs to be a disjunction for "<>". You may think so, but "o" is not always usable for this case. -- Summary: Make CRIS asms autoincrement-safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: hp at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: cris-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme->C compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
00:38 ---
(In reply to comment #6)
> Andrew, your testcase is invalid. You cannot access a variable of long type
> through a pointer to int. I know the original code disables strict aliasing,
> but I did not test if your testcase also aborts with -fno-strict-aliasing.
Oops, here is one which is just changes the cast to long* instead of int*,
it is still broken at -O1 -fno-tree-lrs also:
long fff[10];
long f(long a, long b)
{
long crcc = b;
long d = *((long*)(a+1));
int i;
a = d >= b? d:b;
for(i=0;i<10;i++)
fff[i] = a;
}
int main(void)
{
int i;
long a = 10;
f((long)(&a)-1,0);
for(i = 0;i<10;i++)
if (fff[i]!=10)
abort ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug libfortran/19064] New: runtime error when reading complex*16 using formatted I/O
gfortran (snapshot as of 12/17/04) compiled code gives a runtime error when reading formatted complex*16 values using the following program: program testIO implicit none integer i complex*16 values(5) open(7,file='test1.dat',status='old') read ( 7, '(5E15.8)' ) ( values (i), i = 1, 5 ) print *, ( values (i), i = 1, 5 ) end The text file "test1.dat" contains: 2.E+00 0.E+00 2.52505826E-01 0.E+00 1.44380768E-04 -1.11464849E-18 1.01002561E-01 0.E+00-2.52507036E-02 0.E+00 The code was compiled and executed with "gfortran bug.f; a.out", and produced the following error message: At line 8 of file bug2.f Fortran runtime error: End of file The code works correctly when compiled with g77 and ifort (Intel Fortran), and produces the output (g77): (2.,0.) (0.252505826,0.) (0.000144380768,-1.11464849E-18) (0.101002561,0.) (-0.0252507036,0.) The code and data was extracted from the Harwell-Boeing collection of sparse matrices, which is a commonly used format for sparse matrix computations. See http://math.nist.gov/MatrixMarket/collections/hb.html. Additional information: "gfortran -v" gives: Reading specs from /auto/home0/rmunk/temp_gfortran/irun/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --enable-languages=c,f95 --prefix=/usr/work/2004352/irun Thread model: posix gcc version 4.0.0 20041217 (experimental) Best regards, Rasmus Munk Larsen, Stanford University -- Summary: runtime error when reading complex*16 using formatted I/O Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmunk at quake dot stanford dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19064
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme->C compiler
--- Additional Comments From giovannibajo at libero dot it 2004-12-18 00:33 --- Andrew, your testcase is invalid. You cannot access a variable of long type through a pointer to int. I know the original code disables strict aliasing, but I did not test if your testcase also aborts with -fno-strict-aliasing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18999] gimplify_init_ctor_eval does not support RANGE_EXPRs
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 00:30 --- My patch for Bug 18191 includes Andrew's patch for this bug. -- What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |steven at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999
[Bug middle-end/18999] gimplify_init_ctor_eval does not support RANGE_EXPRs
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 00:24 --- Note the fixed up patch is here with the fix for 18191 also: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01322.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 00:22 --- Posted a patch: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01322.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug target/19061] IA64 GCC pointer confusion results in optimization error
--- Additional Comments From giovannibajo at libero dot it 2004-12-18 00:12 --- The program is correct, because you are still accessing a MGS object through a MGS pointer, so GCC should not segfault here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme->C compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
00:02 ---
Here is at least a testcase for the MAX_EXPR problem:
Compile with -O0, works, compiling with -O2 -fno-tree-lrs does not.
long fff[10];
long f(long a, long b)
{
long crcc = b;
long d = *((int*)(a+1));
int i;
a = d >= b? d:b;
for(i=0;i<10;i++)
fff[i] = a;
}
int main(void)
{
int i;
long a = 10;
f((long)(&a)-1,0);
for(i = 0;i<10;i++)
if (fff[i]!=10)
abort ();
}
-fno-tree-lrs is needed so we don't split the live range of a which we need to
do so we hit the bug.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-12-18 00:02:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug c/18809] ICE after a couple of errors with a simple invalid C code
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-18 00:02 --- It's indeed not a regression. Testing patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18809
[Bug c++/17456] [3.3 regression] ICE when brackets missing from member function call
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-18 00:00 --- Testing patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17456
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme->C compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
23:50 ---
(In reply to comment #3)
> We expanding this:
Yes it is, here is an small example of where we produce wrong code, I have to
think of a full working
testcase which we can run:
int *fff;
int f(int a, int b)
{
int crcc = b;
int d = *((int*)(a+1));
int i;
a = d >= b? d:b;
for(i=0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug c++/18733] [4.0 Regression] friend rejected
--- Additional Comments From giovannibajo at libero dot it 2004-12-17 23:48 --- Yes, that's the problem. The whole point is that the parser does not have enough context information to fully check for the number of template headers: there is an off-by-one possible error it has to allow. For instance: template <> void A::foo(void); The correctness of this depends on whether A uses an explicit specialization or not. So yes, we could unify this for 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733
[Bug tree-optimization/5035] Incorrectly produces '`' might be used uninitialized in this function'
--- Additional Comments From giovannibajo at libero dot it 2004-12-17 23:35 --- Some discussion about how this warning interacts with the tree-ssa framework can be found here: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01309.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme->C compiler
--- Additional Comments From belyshev at lubercy dot com 2004-12-17 23:28 --- We expanding this: ___r2.303 = MAX_EXPR <___r3.316, *((int *) ___r2.303 + 1B)>; into this: (insn 12778 12777 12779 1127 (set (reg/v:SI 1280 [ ___r2.303 ]) (reg/v:SI 1273 [ ___r3.316 ])) -1 (nil) (nil)) (insn 12779 12778 12780 1127 (set (reg:CCGC 17 flags) (compare:CCGC (reg/v:SI 1280 [ ___r2.303 ]) (mem:SI (plus:SI (reg/v:SI 1280 [ ___r2.303 ]) (const_int 1 [0x1])) [0 S4 A32]))) -1 (nil) (nil)) ... which is wrong. So the problem is with expander, unless i am mistaken. -- What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 23:25 --- : Search converges between 2004-11-25-014001-trunk (#656) and 2004-11-25-161001-trunk (#657). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug c++/19063] [3.4/4.0 regresion] ICE on invalid template parameter
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 23:20 --- : Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160). Confirmed. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 23:20:38 date|| Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19063
[Bug c++/19063] New: [3.4/4.0 regresion] ICE on invalid template parameter
The following testcase causes an ICE since gcc 3.4.0:
===
template struct A {};
===
PR13268B.cc:5: error: expected identifier before 'operator'
PR13268B.cc:5: error: declaration of 'operator>' as non-function
PR13268B.cc:5: internal compiler error: tree check: expected class
'declaration', have 'type' (void_type) in process_template_parm, at cp/pt.c:2318
Please submit a full bug report, [etc.]
The bug is similar to PR13268 in that grokdeclarator returns values that
the caller cannot handle gracefully.
But in this case we actually have a regression.
Btw, if an error occurs, grokdeclarator might be returning 0 (which should
probably be NULL_TREE), error_mark_node (which is not documented) or
void_type_node (even if the caller expects a declaration as in this bug)
or ...
Is this intended, or is some heavy cleanup required?
--
Summary: [3.4/4.0 regresion] ICE on invalid template parameter
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19063
[Bug tree-optimization/5035] Incorrectly produces '`' might be used uninitialized in this function'
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 23:13 --- *** Bug 19062 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug tree-optimization/19062] -Wuninitialized tricked by conditional assignments
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 23:12 --- So closing as a dup then. *** This bug has been marked as a duplicate of 5035 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug tree-optimization/5035] Incorrectly produces '`' might be used uninitialized in this function'
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug tree-optimization/19062] -Wuninitialized tricked by conditional assignments
--- Additional Comments From dnovillo at redhat dot com 2004-12-17 22:54 --- Subject: Re: -Wuninitialized tricked by conditional assignments pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 > 22:41 --- > Isn't this just a dup of the long standing bug 5035? > Indeed. I must've searched for the wrong string. Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug tree-optimization/19062] -Wuninitialized tricked by conditional assignments
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 22:41 --- Isn't this just a dup of the long standing bug 5035? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug tree-optimization/18501] [4.0 Regression] Missing 'used unintialized' warning
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-17 22:21 --- Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01314.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug tree-optimization/19062] New: -Wuninitialized tricked by conditional assignments
With the fix for PR 18501 we are now emitting false positives on gcc.dg/uninit-5.c and gcc.dg/uninit-9.c. Analysis of problem: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01309.html -- Summary: -Wuninitialized tricked by conditional assignments Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: dnovillo at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug target/19061] IA64 GCC pointer confusion results in optimization error
-- What|Removed |Added GCC host triplet||ia64-hp-hpux11.23 Summary|ia64-hp-hpux11.23 |IA64 GCC pointer confusion ||results in optimization ||error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug tree-optimization/18792] ICE with -O1 -ftree-loop-linear on small test case
--- Additional Comments From dberlin at dberlin dot org 2004-12-17 21:12 --- Subject: Re: ICE with -O1 -ftree-loop-linear on small test case Because the submitted patch has not yet been approved and applied. On Fri, 17 Dec 2004, fjahanian at apple dot com wrote: > > --- Additional Comments From fjahanian at apple dot com 2004-12-17 19:40 > --- > Why hasn't been there be a resolution of this PR? It seems that all issues, > including elimination of > loop numbers, etc. have been taken care of. Thanks. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18792
[Bug c++/19034] [3.4/4.0 Regression] internal compiler error: in cp_tree_equal, at cp/tree.c:1633
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17 20:59 --- Nathan, this was caused by your patch http://gcc.gnu.org/ml/gcc-cvs/2003-06/msg00871.html Apparently we have a tcc_exceptional in the last switch statement of cp_tree_equal so that we hit gcc_unreachable. I don't know whether tcc_exceptional should be handled more gracefully or whether it shouldn't appear there at all. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19034
[Bug fortran/17675] [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE
--- Additional Comments From phython at gcc dot gnu dot org 2004-12-17 20:42 --- I haven't tested this yet, but perhaps something as simple as Index: trans-common.c === RCS file: /cvsroot/gcc/gcc/gcc/fortran/trans-common.c,v retrieving revision 1.18 diff -u -p -r1.18 trans-common.c --- trans-common.c 16 Sep 2004 16:00:43 - 1.18 +++ trans-common.c 17 Dec 2004 20:41:48 - @@ -269,6 +269,9 @@ build_equiv_decl (tree union_type, bool TREE_ADDRESSABLE (decl) = 1; TREE_USED (decl) = 1; + DECL_ALIGN (decl) = BIGGEST_ALIGNMENT; + DECL_USER_ALIGN (decl) = 0; + /* The source location has been lost, and doesn't really matter. We need to set it to something though. */ gfc_set_decl_location (decl, &gfc_current_locus); Would fix the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675
[Bug rtl-optimization/18942] Do loop is not as optimized as 3.3.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 20:15 --- Confirming as and removing regression marker as suggested by David. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 20:15:35 date|| Summary|[4.0 Regression] Do loop is |Do loop is not as optimized |not as optimized as 3.3.2 |as 3.3.2 Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18942
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
19:44 ---
Indeed, this can be demonstrated with the following testcase:
===
struct A;
namespace N
{
struct A;
}
using namespace N;
int A::i;
int A::i;
namespace N
{
struct C;
struct C {};
}
class D : N::C {};
===
With mainline I get the bogus error message:
PR19030.cc:10: error: 'A' has not been declared
PR19030.cc:11: error: 'A' has not been declared
PR19030.cc:11: error: redefinition of 'int i'
PR19030.cc:10: error: 'int i' previously declared here
PR19030.cc:16: error: conflicting declaration 'struct N::C'
^
PR19030.cc:15: error: 'struct N::C' has a previous declaration as 'struct N::C'
PR19030.cc:16: internal compiler error: tree check: expected class
'declaration', have 'exceptional' (error_mark) in pushtag, at
cp/name-lookup.c:4672
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug tree-optimization/18792] ICE with -O1 -ftree-loop-linear on small test case
--- Additional Comments From fjahanian at apple dot com 2004-12-17 19:40 --- Why hasn't been there be a resolution of this PR? It seems that all issues, including elimination of loop numbers, etc. have been taken care of. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18792
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From nathan at codesourcery dot com 2004-12-17 19:38 --- Subject: Re: [4.0 Regression] ice on tree check reichelt at gcc dot gnu dot org wrote: > --- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17 > 19:02 --- > Please ignore my previous comment. > The fix is not that easy. :-( yes, it's harder. tracing in GDB shows wierdness happening before that point. nathan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug libfortran/19014] print *,maxloc(array) segfaults
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-17 19:32 --- The assertion failure happens for me on an i686-pc-linux-gnu, as well. Looks like different bugs on different architectures for the same test case. (The assertion failure is a bug, too!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19014
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17 19:02 --- Please ignore my previous comment. The fix is not that easy. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug target/19061] New: ia64-hp-hpux11.23
The included program coredumps during execution when compiled with -O2 but not
when compiled with -O0. The problem appears to be with combine and the use of
the ptr_extend_plus_2 instruction. GCC is losing track of what is and isn't a
pointer. I am not entirely sure if the program is legal given all the casts.
struct magic_state {
void *mgs_sv;
};
typedef struct magic_state MGS;
MGS *PL_savestack;
void
restore_magic(void *p)
{
MGS* mgs = ((MGS*) ((char*)PL_savestack + (long)(p)));
if (!mgs->mgs_sv)
return;
mgs->mgs_sv = ((void *)0);
}
MGS s;
main()
{
PL_savestack = &s;
restore_magic((void *) 0);
}
--
Summary: ia64-hp-hpux11.23
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:44 --- First time i see this problem in september-october. Now i only fill PR. Program work for me only if it used gcc 3.4.x shared libraries. ~/pkg/gcc/bin/g++ test.cc setenv LD_LIBRARY_PATH $HOME/pkg/gcc_34/lib ./a.out setenv LD_LIBRARY_PATH $HOME/pkg/gcc/lib ./a.out Assertion failed: (endpos != startpos), function main, file test.cc, line 15. Abort (core dumped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 18:33 --- Hmm, it works for me on ppc-darwin with the mainline (20041215 and 20041214 and 20041213). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:31 --- Created an attachment (id=7773) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7773&action=view) .s file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:31 --- Created an attachment (id=7772) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7772&action=view) .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libstdc++/19060] New: fstream.tellp() result not changed after some output
Program:
---8X---
#include
int main() {
std::ofstream file("test.txt");
std::streampos startpos = file.tellp();
file << 10;
std::streampos endpos = file.tellp();
assert(endpos != startpos);
return 0;
}
---X8---
compile at g++ 3.4.3 and work fine, but fail after compile at g++ 4.0.0
20041215 (mainline).
Also note: if set LD_LIBRARY_PATH point to gcc_34/lib (my gcc 3.4 lib
directory)
compiled with g++ 4.0 program work fine (using old gcc 3.4 shared libraries).
I think problem in code of "libstdc++.so.6" or "libgcc_s.so.1"
Vladimir
--
Summary: fstream.tellp() result not changed after some output
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wanderer at rsu dot ru
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-freebsd5.3-RC1
GCC host triplet: i386-unknown-freebsd5.3-RC1
GCC target triplet: i386-unknown-freebsd5.3-RC1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libf2c/17636] "truncation failed in endfile" error when closing a file appended to
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 18:14 --- Patch at http://gcc.gnu.org/ml/fortran/2004-12/msg00177.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17636
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
--- Additional Comments From pmcnary at cameron dot net 2004-12-17 18:07 --- I have same problems building on OSR5 with UP3 and MP3. math.h unmatch #ENDIF same error as above for eh_alloc.cc Exact problem building 3.4.2 Building 3.3.x problem with math.h and unmatched #ENDIF and build stops compiling at eh_alloc.cc with syntax error at end of file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
[Bug tree-optimization/15678] [4.0 Regression] Compilation time increased by 10-20%
--- Additional Comments From belyshev at lubercy dot com 2004-12-17 17:57 --- 3.4.4 4.0.0 (*A) 4.0.0 (*B) deltaA deltaB time to compile one empty function, ms: cc1-O0 0.4334 0.5908 0.5836 36% 35% cc1plus-O0 0.6155 0.4700 0.4613 -24%-25% cc1-O2 0.8090 1.3886 1.3090 71% 62% cc1plus-O2 0.9213 1.4436 1.3767 57% 49% startup time, i.e. time to "compile" empty file, ms: cc1-O0 18.318.117.4 -1% -5% cc1plus-O0 22.221.020.4 -5% -8% cc1-O2 20.419.319.1 -5% -6% cc1plus-O2 23.722.321.7 -6% -8% *A -- gcc 4.0.0 20041217 compiled by gcc 3.4.4 20041217 *B -- gcc 4.0.0 20041217 compiled by itself. All errors are within 0.05 .. 0.5 % -- What|Removed |Added Last reconfirmed|2004-11-16 21:59:16 |2004-12-17 17:57:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15678
[Bug target/19059] New: Atmel AVR Tiny13 and Tiny2313 support corrupted
AtTiny13 and AtTiny2313 are considered as avr4 architecture. But they do not
support all the instructions of avr4.
For example the "mul" instruction does not exist. See bellow a test case for
mul.
avr-gcc -mmcu=attiny2313 test_mul.c
int main(void) {
uint8_t a, b;
uint16_t res;
res = a * b;
}
--
Summary: Atmel AVR Tiny13 and Tiny2313 support corrupted
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frouleau at naotek dot com
CC: ericw at evcohs dot com,gcc-bugs at gcc dot gnu dot org
GCC build triplet: Any
GCC host triplet: Any
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19059
[Bug java/18931] jar -> .so optimization problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 17:24 --- Fixed on the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
[Bug c++/18975] [4.0 regression] Copying objects with mutable non-static data members
-- What|Removed |Added Keywords||rejects-valid Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/18975] [4.0 regression] Copying objects with mutable non-static data members
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-17 17:21 --- Nathan, this is stage3, you *are* allowed to apply non-regression fixes. By not applying it there you've just created a new 4.0 regression... -- What|Removed |Added Known to fail|3.4.3 4.0.0 |4.0.0 Known to work||3.4.3 Summary|Copying objects with mutable|[4.0 regression] Copying |non-static data members |objects with mutable non- ||static data members http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
17:12 ---
Hi Nathan, the following patch fixes the ICE for me:
Index: gcc/gcc/cp/name-lookup.c
===
RCS file: /home/reichelt/GCC/CVS/gcc-cvs/gcc/gcc/cp/name-lookup.c,v
retrieving revision 1.101
diff -u -p -r1.101 name-lookup.c
--- gcc/gcc/cp/name-lookup.c9 Dec 2004 21:06:59 - 1.101
+++ gcc/gcc/cp/name-lookup.c17 Dec 2004 16:46:40 -
@@ -4663,7 +4663,12 @@ pushtag (tree name, tree type, int globa
pushdecl_class_level (d);
}
else
- d = pushdecl_with_scope (d, b);
+ {
+ d = pushdecl_with_scope (d, b);
+
+ if (d == error_mark_node)
+ return error_mark_node;
+ }
/* FIXME what if it gets a name from typedef? */
if (ANON_AGGRNAME_P (name))
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug rtl-optimization/16968] [3.4 Regression] loop optimizer miscompilation
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 17:11 --- Present on x86 and x86-64 too as of today on 3.4 branch. -- What|Removed |Added GCC target triplet|powerpc-redhat-linux| Last reconfirmed|2004-10-22 17:38:25 |2004-12-17 17:11:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16968
[Bug c++/19030] [4.0 Regression] ice on tree check
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug c++/18733] [4.0 Regression] friend rejected
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-17 16:44 --- The patch looks correct although the code is messy. With the patch, when is_friend is true and processing_specialization is false, we no longer count the number of template header to see if there are too many - but we've already done that in cp_parser_check_template_parameters. The code duplication in cp_parser_check_template_parameters and current_tmpl_spec_kind could be removed in GCC 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733
[Bug c++/18975] Copying objects with mutable non-static data members
--- Additional Comments From bangerth at dealii dot org 2004-12-17 16:34 --- Nathan, if this isn't a regression but a patch has been applied to the 3.4 branch, then you should also apply it to mainline. Otherwise you have just created a regression (3.4.4 will work as expected, but 4.0.0 will not). You therefore just came up with your own excuse to also commit the patch to present mainline (future 4.0.0). W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/18975] Copying objects with mutable non-static data members
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 16:19 --- Subject: Bug 18975 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-17 16:19:24 Modified files: gcc/cp : ChangeLog method.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: synth1.C Log message: cp: PR c++/18975 * method.c (do_build_copy_constructor): Refactor. Don't const qualify a mutable field. (do_build_assign_ref): Likewise. testsuite: PR c++/18975 * g++.dg/other/synth1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.185&r2=1.3892.2.186 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.275.4.4&r2=1.275.4.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.330&r2=1.3389.2.331 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/synth1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c/19058] setjmp: 4.0 fails to give 'clobbered' warning (regression from 3.4.1)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 16:18 --- This is because sum is not used outside of the loop with optimization turned on. We always use 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19058
[Bug c++/18721] [4.0 Regression] template conversion function regression
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 16:17 --- fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug c++/18975] Copying objects with mutable non-static data members
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 16:10 --- Fix for 3.4 branch 2004-12-17 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/18975 * method.c (do_build_copy_constructor): Refactor. Don't const qualify a mutable field. (do_build_assign_ref): Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c/19058] New: setjmp: 4.0 fails to give 'clobbered' warning (regression from 3.4.1)
In the code that follows, gcc-3.4.1 says:
> gcc -W -Wall -Wno-unused-parameter qux.c -O2
qux.c:13: warning: variable 'x' might be clobbered by `longjmp' or `vfork'
gcc-4.0 with those same options gives no warning.
Note that neither version warns about 'sum' being clobbered.
#include
#include
#include
static jmp_buf jmpbuf;
static void segv_handler(int sig) {
longjmp(jmpbuf, 1);
}
int main() {
int y = 1;
volatile int *x = &y;
int sum = 0;
signal(SIGSEGV, segv_handler);
if(setjmp(jmpbuf) == 0) {
while(1) {
sum += *x;
x++;
}
}
printf("%d\n", sum);
return sum;
}
--
Summary: setjmp: 4.0 fails to give 'clobbered' warning
(regression from 3.4.1)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bh at techhouse dot brown dot edu
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=19058
[Bug c++/18721] [4.0 Regression] template conversion function regression
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 16:00 --- 2004-12-17 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/18721 * class.c (add_method): Do not push conversion operators into a binding level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug c++/17821] [3.4/4.0 Regression] Poor diagnostic for using . instead of ->
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 15:58 --- Subject: Bug 17821 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-17 15:58:05 Modified files: gcc/cp : ChangeLog class.c cp-tree.h error.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: conv-5.C Log message: cp: PR c++/17821 * class.c (add_method): Do not push conversion operators into a binding level. * cp-tree.h (CLASSTYPE_PRIMARY_TEMPLATE_TYPE): Reformat. * error.c (dump_decl): Remove extraneous braces. testsuite: PR c++/17821 * g++.dg/lookup/conv-5.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4539&r2=1.4540 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.695&r2=1.696 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1081&r2=1.1082 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&r1=1.273&r2=1.274 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4773&r2=1.4774 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/conv-5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17821
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
15:35 ---
Oooops. That was the error message. ;-)
Here's the testcase:
===
struct A;
namespace N
{
struct A;
}
using namespace N;
int A::i;
int A::i;
namespace N
{
struct A;
}
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17 15:34 --- Here's a reduced testcase: === PR19030.cc:10: error: 'A' has not been declared PR19030.cc:11: error: 'A' has not been declared PR19030.cc:11: error: redefinition of 'int i' PR19030.cc:10: error: 'int i' previously declared here PR19030.cc:15: error: conflicting declaration 'struct N::A' PR19030.cc:5: error: 'struct N::A' has a previous declaration as 'struct N::A' PR19030.cc:15: internal compiler error: tree check: expected class 'declaration', have 'exceptional' (error_mark) in pushtag, at cp/name-lookup.c:4672 === -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|pentium3-pld-linux | GCC host triplet|pentium3-pld-linux | GCC target triplet|pentium3-pld-linux | Keywords||error-recovery, monitored Known to work|3.3.2 |3.3.5 3.4.3 Last reconfirmed|-00-00 00:00:00 |2004-12-17 15:34:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug target/18932] [3.4/4.0 regression] ICE in copyprop_hardreg_forward_1, at regrename.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 15:32 --- *** Bug 19057 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18932
[Bug c/19057] gcc-3_4-branch as of 2004/12/10 fails to compile linux 2.6.10-rc3-mm1 on x86
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 15:32 --- This is a dup of bug 18932, which got fixed on the 12th. *** This bug has been marked as a duplicate of 18932 *** *** This bug has been marked as a duplicate of 18932 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19057
[Bug c/19057] gcc-3_4-branch as of 2004/12/10 fails to compile linux 2.6.10-rc3-mm1 on x86
--- Additional Comments From bero at arklinux dot org 2004-12-17 15:31 --- Created an attachment (id=7769) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7769&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19057
[Bug c/19057] New: gcc-3_4-branch as of 2004/12/10 fails to compile linux 2.6.10-rc3-mm1 on x86
CC [M] fs/ncpfs/inode.o
fs/ncpfs/inode.c: In function `ncp_notify_change':
fs/ncpfs/inode.c:202: error: insn does not satisfy its constraints:
(insn 1089 333 335 19 include/asm/string.h:410 (parallel [
(set (reg:CCNO 17 flags)
(compare:CCNO (and:QI (reg:QI 5 di [orig:109 newmode ] [109])
(const_int -110 [0xff92]))
(const_int 0 [0x0])))
(set (reg:QI 5 di [orig:109 newmode ] [109])
(and:QI (reg:QI 5 di [orig:109 newmode ] [109])
(const_int -110 [0xff92])))
]) 205 {*andqi_2} (nil)
(expr_list:REG_UNUSED (reg:QI 5 di [orig:109 newmode ] [109])
(nil)))
fs/ncpfs/inode.c:202: internal compiler error: in copyprop_hardreg_forward_1,
at regrename.c:1549
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: gcc-3_4-branch as of 2004/12/10 fails to compile linux
2.6.10-rc3-mm1 on x86
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-ark-linux
GCC host triplet: i686-ark-linux
GCC target triplet: i686-ark-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19057
[Bug c/19056] 4.0 optimizes away a SEGV; 3.4.1 does not
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 15:18 --- The code is undefined, once you get into that, anything can happen so closing as invalid. We just optimize away the add and the load since the load is no longer needed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19056
[Bug c/19056] New: 4.0 optimizes away a SEGV; 3.4.1 does not
A minimized test case:
int main() {
int y = 1;
int *x = &y;
volatile int sum = 0;
while(1) {
sum += *x;
x++;
}
return 0;
}
Clearly, this should crash; under 3.4.1 it does. Under my checkout of a few
hours ago, however, it does not: instead, it enters an infinite loop (everything
inside the while(1) gets optimized away and we're left with just a jmp).
Workaround: make either x or sum volatile. This forces it to actually do the
computations inside the loop.
I'm not sure whether to view this as a compiler bug: this code is, at heart,
morally unbalanced. But it is a change in behaviour so I figured I'd report it.
--
Summary: 4.0 optimizes away a SEGV; 3.4.1 does not
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bh at techhouse dot brown dot edu
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=19056
[Bug libgcj/15001] Using JNI with interpreter and interface methods yields SIGSEGV
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 15:13 --- Subject: Bug 15001 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-17 15:13:44 Modified files: libjava: ChangeLog libjava/java/lang/reflect: natMethod.cc Log message: 2004-12-10 Andrew Haley <[EMAIL PROTECTED]> PR java/15001 * java/lang/reflect/natMethod.cc (_Jv_CallAnyMethodA): Look up abstract methods by name. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3261&r2=1.3262 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/reflect/natMethod.cc.diff?cvsroot=gcc&r1=1.42&r2=1.43 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15001
[Bug java/18931] jar -> .so optimization problem
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 15:09 --- Subject: Bug 18931 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-17 15:09:12 Modified files: gcc/java : ChangeLog convert.h expr.c typeck.c Log message: 2004-12-17 Andrew Haley <[EMAIL PROTECTED]> PR java/18931 * typeck.c (convert): Use a CONVERT_EXPR when converting to BOOLEAN_TYPE or CHAR_TYPE. (convert_to_boolean, convert_to_char) : Remove. * convert.h (convert_to_boolean, convert_to_char) : Remove. * expr.c (expand_load_internal): Do type conversion if type is not as required. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1522&r2=1.1523 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/convert.h.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.214&r2=1.215 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/typeck.c.diff?cvsroot=gcc&r1=1.73&r2=1.74 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant
--- Additional Comments From jbeulich at novell dot com 2004-12-17 14:28 --- Now that I have an Itanium2 system to test with, I can confirm that the problem still exists in 3.4.3, and looking at the delta to 4.0.0's ia64.md there is no reason to believe the problem would have been fixed there. fnorm.d.s0 (as example, I tested with double) does set ar.fpsr.sf0.d, and thus would raise an exception if that was unmasked, and even if it's masked may confuse subsequent code in making it incorrectly assume some floating point operation happened on denormal input(s). -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7285
