[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #7 from jakub at gcc dot gnu dot org 2008-06-06 08:03 ---
Ok, I'll bootstrap/regtest patch 1).
To answer your question about 2), consider e.g.:
__attribute__((noinline))
void foo (int, int)
{
static int n = 0;
void *esp;
asm volatile ("movl %%esp, %0" : "=r" (esp));
__builtin_printf ("foo %p\n", esp);
if (n++ == 0)
throw 1;
}
__attribute__((noinline))
void baz (int, int, int, int, int, int, int)
{
static int n = 1;
void *esp;
asm volatile ("movl %%esp, %0" : "=r" (esp));
__builtin_printf ("baz %p\n", esp);
if (n++ == 0)
throw 1;
}
struct A { A () { }; ~A (); char c[24]; };
__attribute__((noinline))
A::~A ()
{
asm volatile ("" : : : "memory");
}
__attribute__((noinline))
void bar ()
{
A a;
try
{
foo (1, 2);
baz (3, 4, 5, 6, 7, 8, 9);
}
catch (...)
{
}
foo (1, 2);
baz (3, 4, 5, 6, 7, 8, 9);
}
int
main ()
{
bar ();
return 0;
}
with -m32 -Os -fasynchronous-unwind-tables -mpreferred-stack-boundary=4 vs.
-m32 -Os -mpreferred-stack-boundary=4. The generated .text
is identical between both, yet without -fa-u-t it shows correct stack alignment
(both foo calls have the same %esp, baz 16 bytes below it), but with -fa-u-t
the second foo call has %esp 8 bytes below the first foo call's %esp (so
clearly
one of them is not aligned to the preferred stack boundary), and baz is 16
bytes below it.
The problem is that at the first call _Z3fooii in bar -fa-u-t computed
args_size
8, while without -fa-u-t it is 16. The first call _Z3baziii has wrong
args_size too (with -fa-u-t 28, without -fa-u-t 32). The second call _Z3fooii
already has the same args_size between the two (16) and second call
_Z3baziii
too (in both cases 32).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug middle-end/36342] [4.4 Regression] Missing file name in compilation diagnostics of preprocessed fortran source
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-06-06 08:26 --- Currently doing reghunt: r134936 works, r135050 fails. Expect more results later ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
[Bug middle-end/36342] [4.4 Regression] Missing file name in compilation diagnostics of preprocessed fortran source
--- Comment #5 from P dot Schaffnit at access dot rwth-aachen dot de 2008-06-06 08:30 --- Thanks! Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
[Bug middle-end/36447] simplify_subreg ICE with right shift more than length type AVR
--- Comment #3 from hutchinsonandy at aim dot com 2008-06-06 11:55 ---
Subject: Re: simplify_subreg ICE with right shift more than
length type AVR
Thanks for quick response,
I will give this a try and no doubt it will work.
I was trying to think of how the other case should be simplified,
rather than left as shift.
or put another way, how should we take sign?
Andy
--
Sent from my Dingleberry wired device.
-Original Message-
From: bonzini at gnu dot org <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Fri, 6 Jun 2008 1:04 am
Subject: [Bug middle-end/36447] simplify_subreg ICE with right shift
more than length type AVR
--- Comment #2 from bonzini at gnu dot org 2008-06-06 05:04 ---
Can you try and possibly submit this patch:
Index: /Users/bonzinip/cvs/gcc/gcc/simplify-rtx.c
===
--- /Users/bonzinip/cvs/gcc/gcc/simplify-rtx.c (revision 134435)
+++ /Users/bonzinip/cvs/gcc/gcc/simplify-rtx.c (working copy)
@@ -5247,6 +5247,7 @@ simplify_subreg (enum machine_mode outer
&& GET_MODE_BITSIZE (innermode) >= (2 * GET_MODE_BITSIZE
(outermode))
&& GET_CODE (XEXP (op, 1)) == CONST_INT
&& (INTVAL (XEXP (op, 1)) & (GET_MODE_BITSIZE (outermode) - 1))
== 0
+ && INTVAL (XEXP (op, 1)) < GET_MODE_BITSIZE (innermode)
&& byte == subreg_lowpart_offset (outermode, innermode))
{
int shifted_bytes = INTVAL (XEXP (op, 1)) / BITS_PER_UNIT;
Thanks!
--
bonzini at gnu dot org changed:
What|Removed |Added
-
---
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-06-06 05:04:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36447
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36447
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #10 from jakub at gcc dot gnu dot org 2008-06-06 12:14 --- Doesn't --with-pic build just one set of *.o files? If yes, then you are out of luck, either configure libstdc++ without symbol versioning, or you need to use a version script when linking --with-pic libstdc++.a statically. If no and --with-pic builds everything twice and it is possible to compile the *.o's intended for libstdc++.so with -DSHARED, then surely replacing uses of #ifdef PIC with #ifdef SHARED is the way to go. Or leave compatibility.o from libstdc++.a (not sure if it is easily doable with libtool). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #14 from joel at gcc dot gnu dot org 2008-06-06 13:16 --- ChangeLog entry for gcc-svn-ada-hwint-20080606.diff. Patch does not remove s-interr-vxworks.adb. As part of review please "diff -u s-interr-vxworks.adb s-interr-hwint.adb" You should only see changes to eliminate references to VxWorks specific packages and to use the adapter routines instead of VxWorks specific ones. 2008-06-06 Joel Sherrill <[EMAIL PROTECTED]> * Makefile.in: Switch RTEMS and VxWorks to s-interr-hwint.adb. * s-interr-hwint.adb: New file with portable implementation. This is a mechanical change of s-interr-vxworks.adb to use the new OS provided adapter. * s-interr-vxworks.adb: Removed. * s-osinte-rtems.ads, s-osinte-vxworks.adb, s-osinte-vxworks.ads: Add shared hardware interrupt adapter layer. RTEMS binds to OS provided adapter routines so there are no modifications to s-osinte-rtems.adb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #7 from jakub at gcc dot gnu dot org 2008-06-06 13:23 --- Subject: Bug 36362 Author: jakub Date: Fri Jun 6 13:23:04 2008 New Revision: 136434 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136434 Log: PR target/36362 * gimplify.c (gimplify_expr) : If *expr_p type is not bool, boolify the whole *expr_p and convert to the desired type. * gcc.c-torture/execute/20080529-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20080529-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #8 from jakub at gcc dot gnu dot org 2008-06-06 13:25 --- Subject: Bug 36419 Author: jakub Date: Fri Jun 6 13:24:45 2008 New Revision: 136435 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136435 Log: PR rtl-optimization/36419 * except.c (expand_resx_expr): Call do_pending_stack_adjust () before the emitting jump insn. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug c++/36449] New: Incorrect code generated for access to a large struct
Please refer to the attached example. When the struct 'ZIP' in this example is enlarged by one word, G++ silently generates incorrect code. -- Summary: Incorrect code generated for access to a large struct Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjk at acm dot org GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36449
[Bug c++/36449] Incorrect code generated for access to a large struct
--- Comment #1 from jjk at acm dot org 2008-06-06 13:28 --- Created an attachment (id=15725) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15725&action=view) C++ code for reproducing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36449
[Bug target/36450] New: ICE in insert_restore with GET_MODE_ALIGNMENT mem
/there.pentium4/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc -c libc/stdlib/strtod.c -o libc/stdlib/strtod.os -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -fno-strict-aliasing -Wnested-externs -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wformat=2 -Wmissing-prototypes -Wmissing-declarations -Wnonnull -Wundef -ffunction-sections -fdata-sections -m32 -fno-stack-protector -fno-builtin -nostdinc -I./include -I. -I./libc/sysdeps/linux/i386 --sysroot=/there.pentium4/build_i686/staging_dir/ -isysroot /there.pentium4/build_i686/staging_dir -I=/usr/include -pipe -O3 -ftree-vect-loop-version -ftree-vectorize -fvariable-expansion-in-unroller -funswitch-loops -funroll-all-loops -ftree-loop-distribution -ftree-loop-im -fivopts -fvect-cost-model -fira -I/there.pentium4/build_i686/staging_dir/usr/include -mtune=pentium4 -march=pentium4 -DUCLIBC_INTERNAL -std=gnu99 -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fomit-frame-pointer -mpreferred-stack-boundary=2 -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/i386 -I./libpthread/linuxthreads.old/sysdeps/i386 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/there.pentium4/toolchain_build_i686/linux/include/ -I/scratch/src/br.update.pentium4/build_i686/staging_dir/usr/bin/../lib/gcc/i686-linux-uclibc/4.4.0//include-fixed -I/scratch/src/br.update.pentium4/build_i686/staging_dir/usr/bin/../lib/gcc/i686-linux-uclibc/4.4.0/include In file included from libc/stdlib/strtod.c:8: libc/stdlib/_strtod.c: In function 'strtod': libc/stdlib/_strtod.c:580: internal compiler error: in insert_restore, at caller-save.c:2332 -- Summary: ICE in insert_restore with GET_MODE_ALIGNMENT mem Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: vmakarov at redhat dot com ReportedBy: aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug target/36450] [IRA] ICE in insert_restore with GET_MODE_ALIGNMENT mem
--- Comment #1 from aldot at gcc dot gnu dot org 2008-06-06 14:40 --- Created an attachment (id=15726) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15726&action=view) original testcase from uClibc ira-branch revision 136341 Works with -fno-ira works with -mpreferred-stack-boundary=4 (in i386) fails with =2: /there.pentium4/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc -c strtod.i -o bug.o -m32 -O2 -mpreferred-stack-boundary=2 -fira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug target/36028] [IRA] ICE in reload_cse_simplify_operands
--- Comment #5 from aldot at gcc dot gnu dot org 2008-06-06 14:44 --- maybe provoking PR36450 although this one is about a slightly different thing AFAICS? I'm curious if you can build your distro with -O3 and -Os ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36028
[Bug rtl-optimization/36438] gcc ICE compiling code with mmx builtin
--- Comment #7 from uros at gcc dot gnu dot org 2008-06-06 15:06 --- Subject: Bug 36438 Author: uros Date: Fri Jun 6 15:04:51 2008 New Revision: 136486 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136486 Log: PR rtl-optimization/36438 * cse.c (fold_rtx) [ASHIFT, LSHIFTRT, ASHIFTRT]: Break out early for vector shifts with constant scalar shift operands. Added: trunk/gcc/testsuite/gcc.target/i386/pr36438.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
[Bug libstdc++/36451] New: Broken links in libstdc++ online documentation
Hi, The links for the documentation for __mt_allocator and bitmap_allocator on page: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt04ch11.html point to: http://gcc.gnu.org/onlinedocs/libstdc++/ext/mt_allocator.html http://gcc.gnu.org/onlinedocs/libstdc++/ext/ballocator_doc.html however I the pages containing the information are: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch32.html#manual.ext.allocator.mt http://gcc.gnu.org/onlinedocs/libstdc++/manual/bitmap_allocator.html -- Summary: Broken links in libstdc++ online documentation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mjb at cs dot bath dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36451
[Bug bootstrap/36452] New: [4.4 Regression] Broken bootstrap while building libgomp.
On i686-apple-darwin9, building libgomp fails with: libtool: compile: /opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.4-work/libgomp -I. -I../../../gcc-4.4-work/libgomp/config/posix -I../../../gcc-4.4-work/libgomp -Wall -pthread -Werror -g -O2 -MT loop_ull.lo -MD -MP -MF .deps/loop_ull.Tpo -c ../../../gcc-4.4-work/libgomp/loop_ull.c -fno-common -DPIC -o .libs/loop_ull.o checking for i686-apple-darwin9-g++... /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc -B/opt/gcc/i686-darwin/./gcc -nostdinc++ -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include checking whether we are using the GNU C++ compiler... ../../../gcc-4.4-work/libgomp/loop_ull.c:486: error: conflicting types for 'GOMP_loop_ull_static_start' ../../../gcc-4.4-work/libgomp/libgomp_g.h:88: error: previous declaration of 'GOMP_loop_ull_static_start' was here cc1: warnings being treated as errors ../../../gcc-4.4-work/libgomp/loop_ull.c: In function 'GOMP_loop_ull_static_start': ../../../gcc-4.4-work/libgomp/loop_ull.c:489: error: passing argument 5 of 'gomp_loop_ull_static_start' makes integer from pointer without a cast ../../../gcc-4.4-work/libgomp/loop_ull.c:489: error: too few arguments to function 'gomp_loop_ull_static_start' ../../../gcc-4.4-work/libgomp/loop_ull.c: At top level:../../../gcc-4.4-work/libgomp/loop_ull.c:493: error: conflicting types for 'GOMP_loop_ull_dynamic_start'../../../gcc-4.4-work/libgomp/libgomp_g.h:94: error: previous declaration of 'GOMP_loop_ull_dynamic_start' was here ../../../gcc-4.4-work/libgomp/loop_ull.c: In function 'GOMP_loop_ull_dynamic_start': ../../../gcc-4.4-work/libgomp/loop_ull.c:496: error: passing argument 5 of 'gomp_loop_ull_dynamic_start' makes integer from pointer without a cast ../../../gcc-4.4-work/libgomp/loop_ull.c:496: error: too few arguments to function 'gomp_loop_ull_dynamic_start' ../../../gcc-4.4-work/libgomp/loop_ull.c: At top level: ../../../gcc-4.4-work/libgomp/loop_ull.c:500: error: conflicting types for 'GOMP_loop_ull_guided_start' ../../../gcc-4.4-work/libgomp/libgomp_g.h:100: error: previous declaration of 'GOMP_loop_ull_guided_start' was here ../../../gcc-4.4-work/libgomp/loop_ull.c: In function 'GOMP_loop_ull_guided_start':../../../gcc-4.4-work/libgomp/loop_ull.c:503: error: passing argument 5 of 'gomp_loop_ull_guided_start' makes integer from pointer without a cast ../../../gcc-4.4-work/libgomp/loop_ull.c:503: error: too few arguments to function 'gomp_loop_ull_guided_start'../../../gcc-4.4-work/libgomp/loop_ull.c: At top level:../../../gcc-4.4-work/libgomp/loop_ull.c:507: error: conflicting types for 'GOMP_loop_ull_ordered_static_start' ../../../gcc-4.4-work/libgomp/libgomp_g.h:112: error: previous declaration of 'GOMP_loop_ull_ordered_static_start' was here ../../../gcc-4.4-work/libgomp/loop_ull.c: In function 'GOMP_loop_ull_ordered_static_start':../../../gcc-4.4-work/libgomp/loop_ull.c:511: error: passing argument 5 of 'gomp_loop_ull_ordered_static_start' makes integer from pointer without a cast ../../../gcc-4.4-work/libgomp/loop_ull.c:511: error: too few arguments to function 'gomp_loop_ull_ordered_static_start' ../../../gcc-4.4-work/libgomp/loop_ull.c: At top level: ../../../gcc-4.4-work/libgomp/loop_ull.c:515: error: conflicting types for 'GOMP_loop_ull_ordered_dynamic_start' ../../../gcc-4.4-work/libgomp/libgomp_g.h:118: error: previous declaration of 'GOMP_loop_ull_ordered_dynamic_start' was here ../../../gcc-4.4-work/libgomp/loop_ull.c: In function 'GOMP_loop_ull_ordered_dynamic_start': ../../../gcc-4.4-work/libgomp/loop_ull.c:519: error: passing argument 5 of 'gomp_loop_ull_ordered_dynamic_start' makes integer from pointer without a cast ../../../gcc-4.4-work/libgomp/loop_ull.c:519: error: too few arguments to function 'gomp_loop_ull_ordered_dynamic_start' ../../../gcc-4.4-work/libgomp/loop_ull.c: At top level: ../../../gcc-4.4-work/libgomp/loop_ull.c:523: error: conflicting types for 'GOMP_loop_ull_ordered_guided_start' ../../../gcc-4.4-work/libgomp/libgomp_g.h:124: error: previous declaration of 'GOMP_loop_ull_ordered_guided_start' was here ../../../gcc-4.4-work/libgomp/loop_ull.c: In function 'GOMP_loop_ull_ordered_guided_start': ../../../gcc-4.4-work/libgomp/loop_ull.c:527: error: passing argument 5 of 'gomp_loop_ull_ordered_guided_start' makes integer from pointer without a cast ../../../gcc-4.4-work/libgomp/loop_ull.c:527: error: too few arguments to function 'gomp_loop_ull_ordered_guided_start' make[4]: *** [loop_ull.lo] Error 1 make[3]: *** [all-recursive
[Bug rtl-optimization/11820] Unoptimized complementary conditional instructions
--- Comment #2 from derek dot white at sun dot com 2008-06-06 16:08 ---
Not a duplicate of bug 5738 (?)
I don't think this can be handled by "GCSE code hoisting". The previous example
have the common subexpression independent of anything else, so code could be
hoisted or delayed. But common code could be dependent on, and depended upon by
non-common code in ways that tend to block CSE.
Look at this example and the addgt and addle instructions below.
--- c example ---
// arm-elf-gcc -S -g0 -Os -o comp-cond.s comp-cond.c
int x,y;
void foo(int b) {
if (b > 13) {
x = y + 0xFF;
} else {
y = x + 0xFF;
}
}
--- arm code ---
foo:
ldr r1, .L6
ldr r2, .L6+4
cmp r0, #13
ldrgt r3, [r2, #0]
ldrle r3, [r1, #0]
addgt r3, r3, #255 <-- DUPLICATE OF BELOW
addle r3, r3, #255 <-- replace both with: add 3, r3, #255
strgt r3, [r1, #0]
strle r3, [r2, #0]
bxlr
This is in gcc-4.2.1.
I don't know the phase order of gcc, but note that this common code is
generated by gcc in the ARM code generator somewhere, which may be too late for
CSE? It looks like a simple peephole optimization could clean this up though.
--
derek dot white at sun dot com changed:
What|Removed |Added
CC||derek dot white at sun dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11820
[Bug preprocessor/36453] New: PR36320 breaks boost
testcase:
=== Cut ===
#if !defined(BOOST_PP_IS_ITERATING)
#elif BOOST_PP_ITERATION_DEPTH() == 1
#endif
=== Cut ===
error: missing binary operator before token "("
from reading the PR36320, this behaviour doesn't seem to be intended. It was
intended to only add a check for non-null argument.
--
Summary: PR36320 breaks boost
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
[Bug testsuite/36440] [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-darwin8.5.0
--- Comment #2 from davidxl at google dot com 2008-06-06 18:00 ---
(In reply to comment #1)
> The failures disappear with the following patch:
>
> --- /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/cdce3.C2008-06-05
> 08:50:23.0 +0200
> +++ /opt/gcc/gcc-4.4-work/gcc/testsuite/g++.dg/cdce3.C 2008-06-06
> 13:50:12.0 +0200
> @@ -1,4 +1,4 @@
> -/* { dg-do run { target { ! "*-*-darwin" } } } */
> +/* { dg-do run { target { ! "*-*-darwin*" } } } */
> /* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details -lm" } */
> /* { dg-final { scan-tree-dump "cdce3.C:68: note: function call is
> shrink-wrapped into error conditions\." "cdce" } }*/
> /* { dg-final { scan-tree-dump "cdce3.C:69: note: function call is
> shrink-wrapped into error conditions\." "cdce" } }*/
>
> (at least on i686-apple-darwin9).
>
I wonder why gcc.dg/cdce1.c and gcc.dg/cdce2.c do not fail in the same way?
David
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
[Bug testsuite/36440] [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-darwin8.5.0
--- Comment #3 from dominiq at lps dot ens dot fr 2008-06-06 18:17 --- > I wonder why gcc.dg/cdce1.c and gcc.dg/cdce2.c do not fail in the same way? Because the tests pass (as far as I can tell from the tests oni686-apple-darwin9). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
[Bug target/36336] ICE push_reload - psuedo reg_equiv_constant
--- Comment #2 from eric dot weddington at atmel dot com 2008-06-06 19:24 --- Andy, I'm having a difficulty in trying to reproduce this bug. I use this command line: avr-gcc -O1 -mmcu=atmega128 -w -std=gnu99 -c memcpy-chk.c -o memcpy-chk.o But I'm using WinAVR 20080512, which is patched, and it does not give an ICE. Are you also getting this ICE with HEAD? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36336
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #9 from jakub at gcc dot gnu dot org 2008-06-06 19:27 --- Subject: Bug 36362 Author: jakub Date: Fri Jun 6 19:26:53 2008 New Revision: 136495 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136495 Log: PR target/36362 * gimplify.c (gimplify_expr) : If *expr_p type is not bool, boolify the whole *expr_p and convert to the desired type. * gcc.c-torture/execute/20080529-1.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/20080529-1.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/gimplify.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #10 from jakub at gcc dot gnu dot org 2008-06-06 19:30 --- Subject: Bug 36419 Author: jakub Date: Fri Jun 6 19:29:28 2008 New Revision: 136496 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136496 Log: PR rtl-optimization/36419 * except.c (expand_resx_expr): Call do_pending_stack_adjust () before the emitting jump insn. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug target/36362] [4.1/4.2/4.3/4.4 Regression] ICE in simplify_subreg
--- Comment #10 from jakub at gcc dot gnu dot org 2008-06-06 19:41 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36362
[Bug target/36336] ICE push_reload - psuedo reg_equiv_constant
--- Comment #3 from hutchinsonandy at aim dot com 2008-06-06 19:42 --- Subject: Re: ICE push_reload - psuedo reg_equiv_constant O2 -- Sent from my Dingleberry wired device. -Original Message- From: eric dot weddington at atmel dot com <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Fri, 6 Jun 2008 3:24 pm Subject: [Bug target/36336] ICE push_reload - psuedo reg_equiv_constant --- Comment #2 from eric dot weddington at atmel dot com 2008-06-06 19:24 --- Andy, I'm having a difficulty in trying to reproduce this bug. I use this command line: avr-gcc -O1 -mmcu=atmega128 -w -std=gnu99 -c memcpy-chk.c -o memcpy-chk.o But I'm using WinAVR 20080512, which is patched, and it does not give an ICE. Are you also getting this ICE with HEAD? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36336 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36336
[Bug target/36336] ICE push_reload - psuedo reg_equiv_constant
--- Comment #4 from eric dot weddington at atmel dot com 2008-06-06 19:48 --- Test case passes with -O[0123s], with WinAVR 20080512 (patched 4.3.0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36336
[Bug preprocessor/36453] PR36320 breaks boost
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at redhat dot com OtherBugsDependingO||36320 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-06 20:03:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-06 20:07 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.0 |4.3.0 4.3.1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-06-06 20:07 --- Subject: Bug 36262 Author: rguenth Date: Fri Jun 6 20:06:40 2008 New Revision: 136501 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136501 Log: 2008-06-06 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34244 * fold-const.c (tree_expr_nonnegative_warnv_p): Do not ask VRP. (tree_expr_nonzero_warnv_p): Likewise. * tree-vrp.c (vrp_expr_computes_nonnegative): Call ssa_name_nonnegative_p. (vrp_expr_computes_nonzero): Call ssa_name_nonzero_p. (extract_range_from_unary_expr): Use vrp_expr_computes_nonzero, not tree_expr_nonzero_warnv_p. PR tree-optimization/36262 Revert 2007-11-29 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/34244 * tree-vrp.c (adjust_range_with_scev): Clear scev cache. (record_numbers_of_iterations): New function. (execute_vrp): Cache the numbers of iterations of loops. * tree-scalar-evolution.c (scev_reset_except_niters): New function. (scev_reset): Use scev_reset_except_niters. * tree-scalar-evolution.h (scev_reset_except_niters): Declare. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c branches/gcc-4_3-branch/gcc/tree-scalar-evolution.c branches/gcc-4_3-branch/gcc/tree-scalar-evolution.h branches/gcc-4_3-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug tree-optimization/34244] [4.3 Regression] VRP/SCEV miscompiles Firefox
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-06-06 20:07 --- Subject: Bug 34244 Author: rguenth Date: Fri Jun 6 20:06:40 2008 New Revision: 136501 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136501 Log: 2008-06-06 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34244 * fold-const.c (tree_expr_nonnegative_warnv_p): Do not ask VRP. (tree_expr_nonzero_warnv_p): Likewise. * tree-vrp.c (vrp_expr_computes_nonnegative): Call ssa_name_nonnegative_p. (vrp_expr_computes_nonzero): Call ssa_name_nonzero_p. (extract_range_from_unary_expr): Use vrp_expr_computes_nonzero, not tree_expr_nonzero_warnv_p. PR tree-optimization/36262 Revert 2007-11-29 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/34244 * tree-vrp.c (adjust_range_with_scev): Clear scev cache. (record_numbers_of_iterations): New function. (execute_vrp): Cache the numbers of iterations of loops. * tree-scalar-evolution.c (scev_reset_except_niters): New function. (scev_reset): Use scev_reset_except_niters. * tree-scalar-evolution.h (scev_reset_except_niters): Declare. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c branches/gcc-4_3-branch/gcc/tree-scalar-evolution.c branches/gcc-4_3-branch/gcc/tree-scalar-evolution.h branches/gcc-4_3-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-06 20:13 --- Subject: Bug 36291 Author: rguenth Date: Fri Jun 6 20:12:27 2008 New Revision: 136502 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136502 Log: 2008-06-06 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/36291 * tree-flow. h (struct gimple_df): Remove var_anns member. * tree-flow-inline.h (gimple_var_anns): Remove. (var_ann): Simplify. * tree-dfa.c (create_var_ann): Simplify. (remove_referenced_var): Clear alias info from var_anns of globals. * tree-ssa.c (init_tree_ssa): Do not allocate var_anns. (delete_tree_ssa): Clear alias info from var_anns of globals. Do not free var_anns. (var_ann_eq): Remove. (var_ann_hash): Likewise. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-dfa.c branches/gcc-4_3-branch/gcc/tree-flow-inline.h branches/gcc-4_3-branch/gcc/tree-flow.h branches/gcc-4_3-branch/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug target/36336] ICE push_reload - psuedo reg_equiv_constant
--- Comment #5 from hutchinsonandy at aim dot com 2008-06-06 20:18 --- Subject: Re: ICE push_reload - psuedo reg_equiv_constant The patch for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786 removes one problematic part of LEGITIMIZE_RELOAD_ADDRESS. This is applied to WinAVR 20080512 (patched 4.3.0). But is still waiting for approval on avr-gcc 4.3/4.4 HEAD. Even with that patch, the other parts of L_R_A are bad and need fixing with added check of reg_equivalent_constant. So if register is equivalent constant LEGITIMIZE_RELOAD_ADDRESS should do nothing. The assert that triggers is an explicit check for this. I have not posted patch due to overlap with pending patch. BTW gcc list has short discussion on this bug, including explanation for the AVR code. Andy -- Sent from my Dingleberry wired device. -Original Message- From: eric dot weddington at atmel dot com <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Fri, 6 Jun 2008 3:48 pm Subject: [Bug target/36336] ICE push_reload - psuedo reg_equiv_constant --- Comment #4 from eric dot weddington at atmel dot com 2008-06-06 19:48 --- Test case passes with -O[0123s], with WinAVR 20080512 (patched 4.3.0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36336 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36336
[Bug tree-optimization/33237] [4.3/4.4 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-06 20:21 --- See PR36291 for a slightly different testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug preprocessor/36453] PR36320 breaks boost
--- Comment #1 from tromey at gcc dot gnu dot org 2008-06-06 20:23 --- By my reading of the standard, issuing an error here is correct. The restrictions on #elif are only lifted if it is in a skipped group. But, in this case, it is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
[Bug tree-optimization/36291] [4.3/4.4 Regression] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-06 20:26 --- Fixed. The remaining slowness is a dup of PR33237. Memory usage on the branch is now down to ~700MB peak VM usage on a 3GB machine at -O on x86_64. Compile time is down to tree find ref. vars : 12.26 (10%) usr 0.27 ( 4%) sys 12.44 (10%) wall 199898 kB (18%) ggc tree alias analysis : 5.04 ( 4%) usr 0.10 ( 2%) sys 5.15 ( 4%) wall 1716 kB ( 0%) ggc tree call clobbering : 12.50 (10%) usr 0.05 ( 1%) sys 12.54 (10%) wall 592 kB ( 0%) ggc tree memory partitioning: 32.74 (26%) usr 0.23 ( 4%) sys 32.94 (25%) wall 880 kB ( 0%) ggc tree SSA incremental : 3.29 ( 3%) usr 0.04 ( 1%) sys 3.25 ( 3%) wall 3714 kB ( 0%) ggc tree operand scan : 8.62 ( 7%) usr 0.17 ( 3%) sys 8.59 ( 7%) wall 59455 kB ( 5%) ggc TOTAL : 121.52 6.89 128.51 1141231 kB of course 4.1 took 34s and only 600MB. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.3.1 Known to work||4.1.3 Resolution||FIXED Summary|GCC is slow and memory- |[4.3/4.4 Regression] GCC is |hungry building |slow and memory-hungry |sipQtGuipart.cpp|building sipQtGuipart.cpp Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug c++/36404] [4.2/4.3 regression] ICE with invalid enum
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36404
[Bug c++/36405] [4.3/4.4 regression] ICE with typeid of member function
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36405
[Bug c++/36406] [4.1/4.2/4.3/4.4 regression] ICE with template delete operator
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug c++/36410] [4.1/4.2/4.3/4.4 regression] ICE with transparent union
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug bootstrap/36452] [4.4 Regression] Broken bootstrap while building libgomp.
--- Comment #1 from andreast at gcc dot gnu dot org 2008-06-06 20:31 --- Subject: Bug 36452 Author: andreast Date: Fri Jun 6 20:30:31 2008 New Revision: 136503 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136503 Log: 2008-06-06 Andreas Tobler <[EMAIL PROTECTED]> PR bootstrap/36452 * loop_ull.c (GOMP_loop_ull_static_start): Adjust API. (GOMP_loop_ull_dynamic_start): Likewise. (GOMP_loop_ull_guided_start): Likewise. (GOMP_loop_ull_ordered_static_start): Likewise. (GOMP_loop_ull_ordered_dynamic_start): Likewise. (GOMP_loop_ull_ordered_guided_start): Likewise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/loop_ull.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36452
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Comment #15 from eric dot weddington at atmel dot com 2008-06-06 20:39 --- This bug report is completely unclear. 'static const' will not be overloaded to imply that a variable is stored in flash. The relevant C language draft concerning mulitple memory spaces will have to be referred to when implementing such a feature. Closing bug as WONTFIX. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #5 from hjl dot tools at gmail dot com 2008-06-06 21:02 --- From: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00350.html the problem isn't limited to --disable-bootstrap. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com Summary|[4.3/4.4 Regression]: |[4.3/4.4 Regression]: HOSTCC |HOST_CC doesn't work with --|doesn't work with unstalled |disable-bootstrap |gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug bootstrap/36452] [4.4 Regression] Broken bootstrap while building libgomp.
-- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-06 21:07:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36452
[Bug bootstrap/36452] [4.4 Regression] Broken bootstrap while building libgomp.
--- Comment #2 from andreast at gcc dot gnu dot org 2008-06-06 21:07 --- Should be fixed now. -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36452
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #6 from hjl dot tools at gmail dot com 2008-06-06 21:09 --- You only see it your system compiler is gcc 4.3 or above [EMAIL PROTECTED] tmp]$ cat x.c #include [EMAIL PROTECTED] tmp]$ GCC_EXEC_PREFIX=/foo gcc -M x.c In file included from x.c:1: /usr/include/limits.h:125:26: error: no include path in which to search for limits.h [EMAIL PROTECTED] tmp]$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=x86_64-redhat-linux Thread model: posix gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) [EMAIL PROTECTED] tmp]$ [EMAIL PROTECTED] tmp]$ GCC_EXEC_PREFIX=/foo gcc -M x.c x.o: x.c /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/limits.h \ /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/syslimits.h \ /usr/include/limits.h /usr/include/features.h /usr/include/sys/cdefs.h \ /usr/include/bits/wordsize.h /usr/include/gnu/stubs.h \ /usr/include/gnu/stubs-64.h /usr/include/bits/posix1_lim.h \ /usr/include/bits/local_lim.h /usr/include/linux/limits.h \ /usr/include/bits/posix2_lim.h [EMAIL PROTECTED] tmp]$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) [EMAIL PROTECTED] tmp]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug middle-end/36149] -O2 optimization generates wrong code
--- Comment #11 from dino at concisoft dot com 2008-06-06 21:13 --- Created an attachment (id=15727) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15727&action=view) A relatively simple self contained piece of code that reproduces the problem. Please see the comments in the Makefile for info on how to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug middle-end/36149] -O2 optimization generates wrong code
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-06 21:32 --- Looks more like one of the known alias related miscompilations of the 4.1 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed|0 |1 Known to fail||4.0.4 4.1.3 Known to work||4.2.4 4.3.0 Last reconfirmed|-00-00 00:00:00 |2008-06-06 21:32:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug fortran/36454] New: too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)
It seems that the standard (or at least the standard literature) is not clear on this one, but Sun and Intel compilers agree that it's good. The problem we have is actually about a derived type that gets two different alias names in USE/ONLY statements. In the end, it should be treated as two different types but it is really one implementation. It works the same with plain integers, so I use these for illustration. Example program: module base integer :: baseint end module module a use base, ONLY: aint => baseint end module module b use base, ONLY: bint => baseint end module module c use a use b private public :: aint, bint end module program user use c, ONLY: aint, bint aint = 3 bint = 8 write(*,*) aint end program gfortran (4.1, 4.2, 4.3), and incidentally also g95 (if that interests anyone;-) refuse this with: public :: aint, bint 1 Error: ACCESS specification at (1) was already specified If you just remove the private/public stuff in module c, like that: module c use a use b end module The code compiles fine and I get the expected output fromt the main program: 8 ...which is the value of baseint, set through bint and read through aint. It feels like gfortran is too eager in error checking there on harmless code. I am not sure if this code is strictly Fortran90 conforming... but I read that a variable is allowed to have different aliases; just didn't find mentioning of one module making public several of these. -- Summary: too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36454
[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)
--- Comment #1 from thomas dot orgis at awi dot de 2008-06-06 21:45 --- Oh, btw: I reckon that this is independent of host system, but for reference: I tested this on x86-64-linux (gfortran 4.1.2 or such) and x86-linux (4.2.3 and 4.3.0). -- thomas dot orgis at awi dot de changed: What|Removed |Added Known to fail||4.2.3 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36454
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #7 from mmitchel at gcc dot gnu dot org 2008-06-06 22:59 --- We set GCC_EXEC_PREFIX when testing in-tree GCC because we want the GCC we're testing to search the right paths. Note that in creating site.exp, we do: @echo "set GCC_EXEC_PREFIX \"$(libdir)/gcc/\"" >> ./tmp0 If I understand correctly, the issue in: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01493.html may be that DejaGNU wants to compile testglue, and therefore needs GCC_EXEC_PREFIX set at that point, since testglue is of course built with the compiler being tested. Maybe HOSTCC should be "GCC_EXEC_PREFIX= gcc"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #10 from dannysmith at gcc dot gnu dot org 2008-06-07 00:40 --- Subject: Bug 35921 Author: dannysmith Date: Sat Jun 7 00:39:43 2008 New Revision: 136515 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136515 Log: PR target/35921 * optimize.c (maybe_clone_body): Copy DECL_DLLIMPORT_P flag to clone. Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/optimize.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #11 from dannysmith at users dot sourceforge dot net 2008-06-07 00:46 --- Fix backported to branch. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #8 from hjl dot tools at gmail dot com 2008-06-07 01:06 --- (In reply to comment #7) > We set GCC_EXEC_PREFIX when testing in-tree GCC because we want the GCC we're > testing to search the right paths. > How does gcc search the right paths when GCC_EXEC_PREFIX points to non-existent directory because gcc isn't installed? Even if there is a GCC_EXEC_PREFIX directory, it could be a very old gcc installation and you may search very old files, instead of the current ones, which are just built, but not installed yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug c/36455] New: gcc 3.4.6 evaluates wrong size for dynamic size arrays (hence binaries compiled with it can yield wrong results or even segfault)
gcc 3.4.6 evaluates wrong size for dynamic size arrays (hence binaries compiled
with it can yield wrong results or even segfault)
In the example source code below, the second array is incorrectly interpreted
by the code generated by gcc 3.4.6 as if it were at a different location than
it actually is. Instead, gcc 2.95.3 and 4.1.2 show the right behavior.
I've checked this both on x86 and ppc, and it happens on both platforms.
The difference in the x86 assembly seems to be the following, and in fact
pushing and popping with printf()s scattered all over the accesses to the
vector elements seems a viable yet horrible workaround:
| bash-3.00$ diff -U10 buglet.s-{mv3.4.3,2.95.3}
| --- buglet.s-3.4.32008-05-28 16:03:47.0 -0700
| +++ buglet.s-2.95.3 2008-05-28 16:01:53.0 -0700
| @@ -111,5 +111,5 @@
| leal-8(%ebp), %esp
| popl%esi
| popl%edi
| - popl%ebp
| + leave
| ret
| .size main, .-main
| .section.note.GNU-stack,"",@progbits
Reproducible: Always
Steps to Reproduce:
Try and build the following code:
int main(){
struct input_{
unsigned int num;
unsigned int key_siz;
unsigned int val_siz;
unsigned char key [ 5 ] [ 3 ];
unsigned char val [ 5 ] [ 6 ];
} __attribute__((packed)) input = {
5,
3,
6,
{
'a', 'b', 'c',
'd', 'e', 'f',
'g', 'h', 'i',
'j', 'k', 'l',
'm', 'n', 'o',
},
{
'A', 'B', 'C', 'D', 'E', 'F',
'G', 'H', 'I', 'J', 'K', 'L',
'M', 'N', 'O', 'P', 'Q', 'R',
'S', 'T', 'U', 'V', 'W', 'X',
'Y', 'Z', '0', '1', '2', '3',
},
};
unsigned int num = input.num;
unsigned int key_siz = input.key_siz;
unsigned int val_siz = input.val_siz;
struct payload_ {
unsigned int num;
unsigned int key_siz;
unsigned int val_siz;
unsigned char key [ num ] [ key_siz ];
unsigned char val [ num ] [ val_siz ];
} __attribute__((packed)) * data = (struct payload_ *)&input;
while(num--){
printf("%3.3s -> %6.6s\n", data->key[num], data->val[num]);
}
return 0;
}
Actual Results:
The binary produced by gcc 3.4.6 shows wrong results:
$ ./buglet-gcc-3.4.6
mno -> VWXYZ0
jkl -> MNOPQR
ghi -> DEFGHI
def -> jklmno
abc -> abcdef
Expected Results:
The binary produced by gcc 2.95.3 or 4.1.2 shows the correct results:
$ ./buglet-gcc-4.1.2 [or ./buglet-gcc-2.95.3]
mno -> YZ0123
jkl -> STUVWX
ghi -> MNOPQR
def -> GHIJKL
abc -> ABCDEF
In my actual code, perhaps because of the much larger indexes, I get
segmentation faults in unpredictable places... These don't happen with good
compilers, of course.
--
Summary: gcc 3.4.6 evaluates wrong size for dynamic size arrays
(hence binaries compiled with it can yield wrong results
or even segfault)
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sandr8+gcc at gmail dot com
GCC build triplet: 3.4.3, 3.4.6
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36455
[Bug c/36455] gcc 3.4.6 evaluates wrong size for dynamic size arrays (hence binaries compiled with it can yield wrong results or even segfault)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-07 01:55 --- Considering 3.4.x is no longer support and this works in 4.1.2, there is not much todo here really as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36455
[Bug target/30652] SSE expansion is missing for isinf() and other fpclassify functions
--- Comment #11 from ghazi at gcc dot gnu dot org 2008-06-07 04:02 --- What remains to be done for this PR? The generic FP classification implementations are all done, including builtin fpclassify(). Perhaps some optabs still need to be finished? Or can we close this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30652
[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables
--- Comment #11 from cnstar9988 at gmail dot com 2008-06-07 04:04 --- Ping... I have attached config.log for a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330
[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-07 06:18 --- CONFIRM. Paul, as out module.c expert, do you have an idea how to solve this? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail|4.2.3 4.3.0 |4.2.3 4.3.0 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-06-07 06:18:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36454
