[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #117 from pinskia at gcc dot gnu dot org 2007-06-22 07:24 --- (In reply to comment #116) There is currently a new ICE If you can reproduce it still, please CC me on the bug (as I caused this bug). I might already have a fix for this bug already too (though the trip to Japan has kept me from testing the patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32459] New: internal compiler error: in build2_stat, at tree.c:3074
As mentioned in the CP2K PR 29975, current gcc generates and ICE: [EMAIL PROTECTED]:/scratch/vondele/gcc_test/gfortran/test/src gfortran -Os all.f90 all.f90: In function compute_screening_matrices: all.f90:305498: internal compiler error: in build2_stat, at tree.c:3074 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED]:/scratch/vondele/gcc_test/gfortran/test/src gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /scratch/vondele/gcc_trunk/gcc/configure --prefix=/scratch/vondele/gcc_trunk/build --with-mpfr_include=/scratch/vondele/mpfr-2.2.0/ --with-mpfr_lib=/scratch/vondele/mpfr-2.2.0/ --with-gmp=/users/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070622 (experimental) The source can be obtained as explained in comment 112 of PR 29975 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975#c112 -- Summary: internal compiler error: in build2_stat, at tree.c:3074 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32459
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #118 from jv244 at cam dot ac dot uk 2007-06-22 07:34 --- (In reply to comment #117) (In reply to comment #116) There is currently a new ICE If you can reproduce it still, please CC me on the bug (as I caused this bug). I might already have a fix for this bug already too (though the trip to Japan has kept me from testing the patch). yes still happening, now PR 32459 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #6 from spop at gcc dot gnu dot org 2007-06-22 07:52 --- Subject: Re: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize) It is not the vectorizer that is in fault here: applying my patch does not impact the output of -fdump-tree-vect-all-all except for one of the dependence tests that is now classified as SIV (single induction variable). The error should be downstream, after the vectorizer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #7 from spop at gcc dot gnu dot org 2007-06-22 08:09 --- Subject: Re: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize) I fail to see what changes. Both before and after applying my patch the assembly diff is the same. I cannot reproduce the bug on i686-linux. Can somebody send me the diff of where that crashes: 1. compile with -fdump-tree-all-all and move the dumps in some other dir, 2. revert my patch, 3. compile with -fdump-tree-all-all, 4. diff the diffs, see what changes in the assembly and in the dumps Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #4 from daney at gcc dot gnu dot org 2007-06-22 08:38 ---
Looking at the rtl dumps of unwind-dw2.c compiled with -O1 I find:
In unwind-dw2.c.135r.subreg (_Unwind_Resume):
.
.
.
(insn 72 71 73 6 ../../../trunk/libgcc/../gcc/unwind.inc:216 (parallel [
(unspec [
(reg:SI 223)
] 7)
(clobber (scratch:SI))
]) 349 {eh_set_lr_si} (nil))
.
.
.
And in unwind-dw2.c.137r.cse1 (_Unwind_Resume):
.
.
.
DCE: Deleting insn 72
deleting insn with uid = 72.
.
.
.
The insn eh_set_lr_si (see the patch) only clobbers a scratch register, and
since we cannot split it to say we set the return address until after reload, I
don't know how to keep it from being deleted unless we say it is volatile.
I am a bit surprised that the very first thing I tried worked, but after more
thought I cannot come up with anything else.
The patch fixes all c++ and libstdc++ testsuite regressions caused by the
dateflow merge (on mipsel-linux), so I would like to commit it.
Thoughts?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug tree-optimization/31280] segfault in remove_referenced_var
--- Comment #6 from spop at gcc dot gnu dot org 2007-06-22 08:40 --- I cannot reproduce the ICE on trunk at 125915, on i686-linux -- spop at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
[Bug tree-optimization/31611] [4.3 regression] ICE with -ftree-loop-linear in remove_referenced_var for loc == *0
--- Comment #7 from spop at gcc dot gnu dot org 2007-06-22 08:49 --- I cannot reproduce this bug on trunk rev.125915, on i686-linux. -- spop at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31611
[Bug tree-optimization/31762] ICE in tree-dfa.c:791 with -ftree-loop-linear (and -O1 -ffast-math)
--- Comment #5 from spop at gcc dot gnu dot org 2007-06-22 08:53 --- I cannot reproduce the ICE on trunk at 125915, and i686-linux. -- spop at gcc dot gnu dot org changed: What|Removed |Added CC|sebastian dot pop at cri dot|spop at gcc dot gnu dot org |ensmp dot fr| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31762
[Bug fortran/32460] New: structure constructor not allowed if a USEd type has private components
gfortran accepts this code while INTEL and SUN compilers reject it: $ cat private.f90 MODULE foomod TYPE :: footype PRIVATE integer :: dummy END TYPE END MODULE PROGRAM foo_test USE foomod TYPE(footype) :: foo foo = footype(1) END $ sunf95 -w4 private.f90 foo = footype(1) ^ private.f90, Line = 11, Column = 9: ERROR: Derived type FOOTYPE has private components, therefore a structure constructor must not be defined for this type. $ ifort -warn all private.f90 fortcom: Error: private.f90, line 11: The type of this structure constructor is use associated with the PRIVATE fields attribute [FOOTYPE] foo = footype(1) ^ -- Summary: structure constructor not allowed if a USEd type has private components Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32460
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #5 from rsandifo at gcc dot gnu dot org 2007-06-22 09:11 --- I'm not surprised that converting it to an unspec_volatile stops us from deleting the instruction, but that wasn't really my concern. As I said earlier, several other ports use top-level unspecs (rather than unspec_volatiles), and it appears that after the dataflow merge, that construct is no longer allowed. Thus I think we should first nail down whether this is a deliberate change. If it is (and I can see that it might be), then I think we should change the RTL generators so that top-level unspecs are not allowed in define_insns. I do not think we should the MIPS port until we have established what the new rules are. (This isn't an issue about dataflow being more accurate per se; the old code could also have deleted top-level unspecs with no register dependencies, if it had thought that doing so was allowed.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #7 from rob1weld at aol dot com 2007-06-22 09:18 ---
Uros Bizjak - has to include warnings about not drying animals in it
I have an older model with no such label therefore I am OK. ;)
--- Here is another program that demonstrates that there is some problem ---
/*
--- Comment #4 From Andrew Pinski 2007-06-21 09:06 [reply] ---
abs converts the float/double to an integer type so this is not a bug. If you
use 4.3, you can use -Wconversion.
Notice that b and d are different - there is no (equal or otherwise)
conversion.
The operation of abs (according to printf output) seems to be:
If it is an integer accept and use it. If it is a float then it is = 0 .
Look what printf does to i, thats an easy conversion.
*/
#include math.h
#include stdio.h
int main ( ) {
/* float a, b, c, d, e, f, g, h, i, j; */ /* gives warning argument x
has type 'double', it */
double a, b, c, d, e, f, g, h, i, j; /* might be better to say type float
instead */
a = 16.000;
b = abs(a);
c = fabs(a);
d = abs((int)(a));
e = fabs((int)(a));
f = abs((float)(a));
g = fabs((float)(a));
h = (int)abs(a);
i = (float)abs(a);
j = 0.0;
printf(a = %.2f b = %.2f c = %.2f d = %.2f e = %.2f , a, b, c, d, e);
printf(f = %.2f g = %.2f h = %.2f i = %.2f j = %.2f\n, f, g, h, i, j);
printf(a = %d b = %d c = %d d = %d e = %d , a, b, c, d, e);
printf(f = %d g = %d h = %d i = %d j = %d\n, f, g, h, i, j);
return 0;
}
/* /usr/test/bin/gcc -Wall -Wconversion -o math_test_7 math_test_7.c */
/* Output:
a = 16.00 b = 0.00 c = 16.00 d = 16.00 e = 16.00 f = 0.00 g = 16.00 h =
0.00 i = 0.00 j = 0.00
a = 0 b = 1076887552 c = 0 d = 0 e = 0 f = 0 g = 0 h = 0 i = 1076887552
j = 0
*/
How can that be correct conversion ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug middle-end/32459] internal compiler error: in build2_stat, at tree.c:3074
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-22 09:24 --- Can you provide a backtrace? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32459
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #23 from burnus at gcc dot gnu dot org 2007-06-22 09:41 --- All Used Variables intialized Do you actually get still wrong results with gfortran? If yes, which platform and compiler version? Here, I fail to get a wrong result with ifort, NAG f95, sunf95, gfortran 4.1.3, 4.2.0 and 4.3(of today) with several optimization flags and both for 32 and 64 bit on x86-64. As Dominique, I still get an error for g95 -O2, but that is a different compiler (usually found with GCC 4.0.x backend; note GCC 4.1.x is no longer maintained.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug target/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #2 from ubizjak at gmail dot com 2007-06-22 09:50 --- The problem here is exposed with core2_cost table, where mmxsse_to_integer is as low (2 units) as move between integer registers (2 units). Such a low value causes gcc to happily move SImode values between SSE and integer registers. The problem itself is in ix86_modes_tieable_p(). Since all integer modes are tieable, They have to be tieable in ALL register classes. Due to this, we must enable HImode and QImode moves to, from and between SSE and MMX register. A question arises, if this is a wise thing to do. Having all integer modes wandering around in SSE as well as integer registers is not a good thing, as we will have many moves between these sets (you can't add a SImode value in SSE, SSE regs can't be index registers, etc). Due to this, perhaps the best solution is to artifically raise mmxsse_to_integer to 8 units, and this will effectively prevent moves to and from register sets. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-22 09:50:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #10 from sebpop at gmail dot com 2007-06-22 10:12 --- Subject: Re: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize) Grrr, I mean, I will test the patch now on amd64 ;-) On 6/22/07, Sebastian Pop [EMAIL PROTECTED] wrote: Okay, I'm testing that on an amd64 machine. Sorry for the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug middle-end/32459] internal compiler error: in build2_stat, at tree.c:3074
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-22 10:13 ---
(In reply to comment #1)
Can you provide a backtrace?
1 compute_screening_matrices
Breakpoint 1, internal_error (gmsgid=0xae1dff in %s, at %s:%d)
at /scratch/vondele/gcc_trunk/gcc/gcc/diagnostic.c:596
596 {
(gdb) bt
#0 internal_error (gmsgid=0xae1dff in %s, at %s:%d)
at /scratch/vondele/gcc_trunk/gcc/gcc/diagnostic.c:596
#1 0x00514a3c in fancy_abort (file=Variable file is not available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/diagnostic.c:656
#2 0x007f4818 in build2_stat (code=MULT_EXPR, tt=0x2a95a5c6c0,
arg0=0x2ac292cc00,
arg1=0x2ab6eca810) at /scratch/vondele/gcc_trunk/gcc/gcc/tree.c:3074
#3 0x00a2fa90 in aff_combination_add_elt (comb=0x7fbfffe9b0,
elt=0x2aebf44b40, scale=
{low = 8, high = 0}) at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-affine.c:175
#4 0x00a2ff26 in aff_combination_add (comb1=0x7fbfffe9b0,
comb2=0x7fbfffe7d0)
at /scratch/vondele/gcc_trunk/gcc/gcc/tree-affine.c:202
#5 0x00764511 in get_computation_aff (loop=0x2ab16d95a0, use=Variable
use is not available.
)
at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-ivopts.c:2669
#6 0x00765fd3 in rewrite_use_address (data=0x7fbfffedf0,
use=0x31199330, cand=0x20bc1650)
at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-ivopts.c:5086
#7 0x0076687e in rewrite_uses (data=0x7fbfffedf0)
at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-ivopts.c:5147
#8 0x00768c93 in tree_ssa_iv_optimize_loop (data=0x7fbfffedf0,
loop=Variable loop is not available.
)
at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-ivopts.c:5346
#9 0x007691c0 in tree_ssa_iv_optimize ()
at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-ivopts.c:5379
#10 0x00775d7d in tree_ssa_loop_ivopts ()
at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop.c:514
#11 0x0062b709 in execute_one_pass (pass=0xd32b80)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32459
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #9 from spop at gcc dot gnu dot org 2007-06-22 10:11 --- Subject: Re: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize) Okay, I'm testing that on an amd64 machine. Sorry for the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #8 from rob1weld at aol dot com 2007-06-22 09:42 --- A earlier version of this program had these lines in it: ... f = abs((float)(a)); g = fabs((float)(a)); h = (int)abs(a); i = 0.0; printf(a = %.2f b = %.2f c = %.2f d = %.2f e = %.2f , a, b, c, d, e); printf(f = %.2f g = %.2f h = %.2f i = %.2f\n, f, g, h, i); printf(a = %d b = %d c = %d d = %d e = %d , a, b, c, d, e); printf(f = %d g = %d h = %d i = %d\n, f, g, h, i); printf(i2 = %d\n, i); return 0; ... Here is the output: /* Output: a = 16.00 b = 0.00 c = 16.00 d = 16.00 e = 16.00 f = 0.00 g = 16.00 h = 0.00 i = 0.00 a = 0 b = 1076887552 c = 0 d = 0 e = 0 f = 0 g = 0 h = 0 i = 1076887552 i2 = 0 */ Notice that the prior time that the 9th variable was 1076887552 (as it is in comment 7). Using gdb I see that print /x 1076887552 = 0x4030 . It might be using the stack pointer for the value. Notice that i and i2 both print the value of i and that it is different - it is as if gcc is using a pointer into memory instead of the actual value. I'll work on some debugging and see if I can find out how it derives the value of i that it prints differently each time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #13 from hubicka at ucw dot cz 2007-06-22 09:36 --- Subject: Re: [4.3 Regression] cannot take address of bit field After you solve that there is that little matter of udivdi3. udivdi3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #8 from ubizjak at gmail dot com 2007-06-22 09:36 --- (In reply to comment #7) I fail to see what changes. Both before and after applying my patch the assembly diff is the same. I cannot reproduce the bug on i686-linux. This bug can be reproduced only on x86_64 host for -m32. I was not able to trigger it when compiled on i686. I'll provide the diffs (in the evening, so perhaps Tobias could provide them in shorter time...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #12 from hubicka at ucw dot cz 2007-06-22 09:35 --- Subject: Re: [4.3 Regression] cannot take address of bit field Hi, I've experimented with this a bit - the problem is that the error is produced during gimplification: gimplifier translates the expression into the addr_expr form and later gimplifying the addr_expr it calls the mark_addressable langhook that porudces the error. It seems to me that this langhook call is unnecesary. Removing it breaks since C++ is sometimes producing references to objects not having addr_expr during gimplification, but it seems to me that adding just generic code that takes gimple addr_expr and marks bit addressable (just as aliasing does) instead the full blown langhook should just work? THe typechecking in frontend should be enough to catch this sort of syntax errors (when address is taken form something language prohibits). Does this seem sane? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #14 from rguenther at suse dot de 2007-06-22 09:45 --- Subject: Re: [4.3 Regression] cannot take address of bit field On Fri, 22 Jun 2007, hubicka at ucw dot cz wrote: --- Comment #12 from hubicka at ucw dot cz 2007-06-22 09:35 --- Subject: Re: [4.3 Regression] cannot take address of bit field Hi, I've experimented with this a bit - the problem is that the error is produced during gimplification: gimplifier translates the expression into the addr_expr form and later gimplifying the addr_expr it calls the mark_addressable langhook that porudces the error. It seems to me that this langhook call is unnecesary. Removing it breaks since C++ is sometimes producing references to objects not having addr_expr during gimplification, but it seems to me that adding just generic code that takes gimple addr_expr and marks bit addressable (just as aliasing does) instead the full blown langhook should just work? THe typechecking in frontend should be enough to catch this sort of syntax errors (when address is taken form something language prohibits). Does this seem sane? Yes. It looks like a frontend bug if the tree was not marked addressable before gimplification but would need to after. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug ada/30036] ICE using interfaces: Assert_Failure sem_util.adb:1033
--- Comment #2 from charlet at gcc dot gnu dot org 2007-06-22 10:43 --- This now compiles cleanly on trunk. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30036
[Bug ada/31415] Illegal program not detected, Ada 2005, 3.9.4(12/2) and 7.5(6.1/2)
--- Comment #1 from charlet at gcc dot gnu dot org 2007-06-22 10:44 --- This now generates a proper error on trunk. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31415
[Bug libgcj/17002] java.util.TimeZone.getDefault() is broken
--- Comment #9 from jakub at gcc dot gnu dot org 2007-06-22 12:17 ---
Subject: Bug 17002
Author: jakub
Date: Fri Jun 22 12:17:00 2007
New Revision: 125946
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125946
Log:
2007-02-24 Jakub Jelinek [EMAIL PROTECTED]
libjava/classpath/
* java/util/TimeZone.java (getDefaultDisplayName): Don't
check if TimeZone is instanceof SimpleTimeZone.
2007-02-22 Jakub Jelinek [EMAIL PROTECTED]
libjava/
PR libgcj/17002
PR classpath/28550
* java/util/VMTimeZone.java (getDefaultTimeZoneId): To read
/etc/localtime, use ZoneInfo.readTZFile instead of
VMTimeZone.readtzFile. Get better timezone name for /etc/localtime,
either if it is a symlink or through /etc/sysconfig/clock.
(readSysconfigClockFile): New static method.
(readtzFile): Removed.
* java/lang/System.java: Add gnu.java.util.zoneinfo.dir to comments.
* posix.cc (_Jv_platform_initProperties): Set
gnu.java.util.zoneinfo.dir.
* sources.am (gnu_java_util_source_files): Add
classpath/gnu/java/util/ZoneInfo.java.
* Makefile.in: Regenerated.
libjava/classpath/
* java/util/Date.java (parse): Properly parse 09:01:02 as
hours/minutes/seconds, not as hours/minutes/year.
* java/util/SimpleTimeZone.java (SimpleTimeZone): Simplify
{start,end}TimeMode constructor by calling shorter constructor,
set {start,end}TimeMode fields after it returns.
(setStartRule): Don't adjust startTime into WALL_TIME. Set
startTimeMode to WALL_TIME.
(endStartRule): Similarly.
(getOffset): Handle properly millis + dstOffset overflowing into the
next day. Adjust startTime resp. endTime based on startTimeMode
resp. endTimeMode.
* java/util/TimeZone.java (zoneinfo_dir, availableIDs, aliases0): New
static fields.
(timezones): Remove synchronized keyword. Set zoneinfo_dir.
If non-null, set up aliases0 and don't put anything into
timezones0.
(defaultZone): Call getTimeZone instead of timezones().get.
(getDefaultTimeZone): Fix parsing of EST5 or EST5EDT6. Use
getTimeZoneInternal instead of timezones().get.
(parseTime): Parse correctly hour:minute.
(getTimeZoneInternal): New private method.
(getTimeZone): Do the custom ID checking first, canonicalize
ID for custom IDs as required by documentation. Call
getTimeZoneInternal to handle the rest.
(getAvailableIDs(int)): Add locking. Handle zoneinfo_dir != null.
(getAvailableIDs(File,String,ArrayList)): New private method.
(getAvailableIDs()): Add locking. Handle zoneinfo_dir != null.
* gnu/java/util/ZoneInfo.java: New file.
2007-02-14 Jakub Jelinek [EMAIL PROTECTED]
Andrew Haley [EMAIL PROTECTED]
libjava/classpath/
* java/util/TimeZone.java (getDateParams): Negate dayOfWeek.
2007-02-09 Jakub Jelinek [EMAIL PROTECTED]
libjava/
* java/util/VMTimeZone.java: Rewrite to handle both the old
'TZif\0' format and the new one.
libjava/classpath/
* java/util/TimeZone.java: Handle default (one hour) daylight
savings.
PR 23566
* java/util/TimeZone.java (timezones): Regenerate from tzdata2007a.
Added:
branches/redhat/fc6-4_1-branch/libjava/classpath/gnu/java/util/ZoneInfo.java
Modified:
branches/redhat/fc6-4_1-branch/libjava/ChangeLog
branches/redhat/fc6-4_1-branch/libjava/Makefile.in
branches/redhat/fc6-4_1-branch/libjava/classpath/ChangeLog
branches/redhat/fc6-4_1-branch/libjava/classpath/java/util/Date.java
branches/redhat/fc6-4_1-branch/libjava/classpath/java/util/SimpleTimeZone.java
branches/redhat/fc6-4_1-branch/libjava/classpath/java/util/TimeZone.java
branches/redhat/fc6-4_1-branch/libjava/java/lang/System.java
branches/redhat/fc6-4_1-branch/libjava/java/util/VMTimeZone.java
branches/redhat/fc6-4_1-branch/libjava/posix.cc
branches/redhat/fc6-4_1-branch/libjava/sources.am
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17002
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #9 from ubizjak at gmail dot com 2007-06-22 12:26 --- (In reply to comment #8) I'll work on some debugging and see if I can find out how it derives the value of i that it prints differently each time. Don't worry, it works correctly. The non-problem you are going after is in printf(). It takes variable arguments from the stack and interprets them according to the format string. Argument are pushed to the stack by the caller without any other communication with callee, so it is obvious that format string _must_ reflect the type of values on stack. Also note, that %f inherently converts float type to double, so your values on the stack are FUBAR as far as printf is concerned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug target/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #3 from ubizjak at gmail dot com 2007-06-22 12:02 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01615.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg01615.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
[Bug tree-optimization/30563] [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #7 from tbm at cyrius dot com 2007-06-22 12:56 --- This bug is extremely common (seen while compiling the Debian archive). Honza, can you take a look soon? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #15 from malitzke at metronets dot com 2007-06-22 12:51 --- After you solve that there is that little matter of udivdi3. udivdi3? In comment 7 somebody (dcb) remarked about PR31654 (marked duplicate to this bug) was impeding kernel compilation. In comment 10 it was reiterated that the importance of the present bug related to kernel compilation. At least for the x86 kernels I never got to the present bug because with gcc-4.3 there is the ugly fact that a recognized __stupid__ and unwarranted optimization per PR31990 downgraded to less than trivial status as an enhancement in PR32044 is impeding kernel compilation. Great fun (not function). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug fortran/32157] intrinsic function name conflicts with subroutine if present in the same file
--- Comment #2 from pault at gcc dot gnu dot org 2007-06-22 13:03 --- This fixes it: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (révision 125706) +++ gcc/fortran/resolve.c (copie de travail) @@ -1568,6 +1568,8 @@ resolve_function (gfc_expr *expr) /* If the procedure is not internal, a statement function or a module procedure,it must be external and should be checked for usage. */ if (sym !sym-attr.dummy !sym-attr.contained + !(sym-attr.intrinsic +|| gfc_intrinsic_name (sym-name, sym-attr.subroutine)) sym-attr.proc != PROC_ST_FUNCTION !sym-attr.use_assoc sym-name ) We paybe need a helper function, gfc_is_external - I'll check if there are other clients. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-05-30 16:58:58 |2007-06-22 13:03:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32157
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #24 from burnus at gcc dot gnu dot org 2007-06-22 13:26 --- Additional note - as pointed out by Ian of NAG: program main implicit none integer :: jt, it(100) real:: tt equivalence(jt,tt) do i=1,100 tt=i it(i)=jt end do end program main Here jt is *undefined*. The Fortran 2003 standard has in Section 16.5.6: When a variable of a given type becomes defined, all associated variables of different type become undefined. (There is an exception for real vs. complex variables.) That mean jt can contain any value according to the standard (cf. union in C). In reality, after assigning real(ii) to tt, jt has a defined value - which some programs make use of. Fortran 2003 standard conform would be not: it(i) = jt, but it(i)=transfer(tt,0), which gives however the same result in practice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/27589] Add compiler flag to check for uninitalized values at runtime
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-22 13:15 --- (In reply to comment #3) Dump a valid program which contains equivalence to show a harder case for the checks (NAG f95 chokes on it). Actually this is wrong according to the Section 16.5.6 of the F2003 standard: When a variable of a given type becomes defined, all associated variables of different type become undefined. There then follows an exception that allows REAL and COMPLEX to be equivalenced and not be undefined in this circumstance. Thus one should check for this as well (but having a note in the documentation for this case would make sense too.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #26 from burnus at gcc dot gnu dot org 2007-06-22 14:32 --- (In reply to comment #25) I was tracking what appeared to be the similar bugs in gfortran and g95, but some where in the last few steps when I could not test with gfortran - I lost the gfortran link. You are looking for the following, are you? http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #25 from dir at lanl dot gov 2007-06-22 14:28 --- I was tracking what appeared to be the similar bugs in gfortran and g95, but some where in the last few steps when I could not test with gfortran - I lost the gfortran link. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug regression/32461] New: [4.3 Regression] internal compiler error: Segmentation fault
svn revision 125948 $ gcc -mno-cygwin -O4 bit_allocate.c -save-temps bit_allocate.c: In function 'a52_bit_allocate': bit_allocate.c:127: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.3 Regression] internal compiler error: Segmentation fault Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jojelino at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug regression/32461] [4.3 Regression] internal compiler error: Segmentation fault
--- Comment #1 from jojelino at gmail dot com 2007-06-22 16:01 --- Created an attachment (id=13762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13762action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug regression/32461] [4.3 Regression] internal compiler error: Segmentation fault
--- Comment #2 from jojelino at gmail dot com 2007-06-22 16:06 --- fails if given -Olevel level2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug libgcj/32462] New: Linking libgcj.so fails on Solaris 10/x86
A mainline bootstrap as of 20070618 on Solaris 10/x86 with the bundled gas 2.15 fails to link libgcj.so: ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::queueLock: relocation must bind locally collect2: ld returned 1 exit status make[3]: *** [libgcj.la] Error 1 Performing the same link on Solaris 11 gives ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::queueLock: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::queueLock: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::processManager: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::queueLock: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::processManager: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::processManager: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::processManager: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::processManager: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::queueLock: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o: symbol java::lang::PosixProcess::processManager: a GOT relative relocation must reference a local symbol collect2: ld returned 1 exit status I'm currently investigating if using the native /usr/ccs/bin/as, gas 2.17 or gld 2.17 makes a difference. Environment: System: SunOS erebus 5.11 snv_60 i86pc i386 i86pc Architecture: i86pc host: i386-pc-solaris2.10 build: i386-pc-solaris2.10 target: i386-pc-solaris2.10 configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --with-gnu-as --with-as=/usr/sfw/bin/gas --disable-multilib --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap mainline as described above. -- Summary: Linking libgcj.so fails on Solaris 10/x86 Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug fortran/32360] GFORTRAN WON'T COMPILE 'DATA PTR1 /NULL ()/' WHEN PTR1 HAS POINTER ATTRIBUTE
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-06-22 16:21 --- Subject: Bug 32360 Author: jvdelisle Date: Fri Jun 22 16:21:23 2007 New Revision: 125949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125949 Log: 2007-06-22 Jerry DeLisle [EMAIL PROTECTED] PR fortran/32360 * expr.c (gfc_check_assign): If the rvalue expression type is NULL_EXPR, check to see if the lvalue has attribute pointer and data. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32360
[Bug fortran/32360] GFORTRAN WON'T COMPILE 'DATA PTR1 /NULL ()/' WHEN PTR1 HAS POINTER ATTRIBUTE
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-06-22 16:25 --- Fixed on trunk (4.3) closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32360
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #16 from dje at watson dot ibm dot com 2007-06-22 16:44 --- Subject: Re: ICE on gcc/testsuite/gcc-dg/vmx/ops.c There are much more constructive ways in which to interact with the GCC community, GCC developers, and port maintainers than you have chosen to pursue. I am sorry that we are not addressing your particular bug as quickly as you would like. Insisting on action after one week and making personal attacks are not appropriate. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug fortran/32360] GFORTRAN WON'T COMPILE 'DATA PTR1 /NULL ()/' WHEN PTR1 HAS POINTER ATTRIBUTE
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-22 16:24 --- Subject: Bug 32360 Author: jvdelisle Date: Fri Jun 22 16:23:55 2007 New Revision: 125950 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125950 Log: 2007-06-22 Jerry DeLisle [EMAIL PROTECTED] PR fortran/32360 * gfortran.dg/pointer_assign_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_assign_3.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32360
[Bug fortran/32464] ICE [4.3 regression]: USE in contained subroutine
--- Comment #1 from anlauf at gmx dot de 2007-06-22 17:33 --- Created an attachment (id=13763) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13763action=view) Demo code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug rtl-optimization/32463] [4.0.2|4.1.0] bitwise shift optimization error
--- Comment #2 from alan dot hardin at paulsson dot com 2007-06-22 17:36 --- The attached code fails if compiled with any optimization. I am trying to use = operation to calculate the valid range of a bitfield. -- alan dot hardin at paulsson dot com changed: What|Removed |Added Summary|[4.0.2 |[4.0.2|4.1.0] bitwise shift ||optimization error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32463
[Bug libgcj/32465] New: Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code despite -fPIC
A mainline bootstrap as of 20070618 on Solaris 10/x86 with the bundled gas 2.15 and my patch to support boehm-gc for x86-64 http://gcc.gnu.org/ml/java-patches/2007-q2/msg00330.html fails when linking the 64-bit libgcj: [ca. 6800 lines omitted] gnu::gcj::runtime::FinalizerThread::finalizer_ready0x602 gnu/gcj/.libs/runtime.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I've checked for some of the affected object files that they have been built with -fPIC, nonetheless text relocations remain, thus breaking the link. Environment: System: SunOS erebus 5.11 snv_60 i86pc i386 i86pc Architecture: i86pc host: i386-pc-solaris2.10 build: i386-pc-solaris2.10 target: i386-pc-solaris2.10 configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --with-gnu-as --with-as=/usr/sfw/bin/gas --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap mainline as described above. --- Comment #1 from ro at techfak dot uni-bielefeld dot de 2007-06-22 17:42 --- Fix: It is possible to link with -mimpure-text as a workaround. -- Summary: Linking 64-bit libgcj.so fails on Solaris 10/x86: non- PIC code despite -fPIC Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32465
[Bug target/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #4 from uros at gcc dot gnu dot org 2007-06-22 17:51 --- Subject: Bug 32413 Author: uros Date: Fri Jun 22 17:51:06 2007 New Revision: 125951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125951 Log: PR target/32413 * config/i386/i386.c (ix86_register_move_cost): Rise the cost of moves between MMX/SSE registers to at least 8 units to prevent ICE caused by non-tieable SI/HI/QImodes in SSE registers. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
[Bug rtl-optimization/26026] power of 2 mod missing optimisation
--- Comment #7 from bergner at gcc dot gnu dot org 2007-06-22 17:56 --- Subject: Bug 26026 Author: bergner Date: Fri Jun 22 17:56:14 2007 New Revision: 125952 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125952 Log: Reassociation rewrite backport from mainline. 2006-03-22 Jeff Law [EMAIL PROTECTED] * loop-unroll.c (analyze_iv_to_split_insn): Handle iv_analyze_result returning false. 2006-04-20 Jeff Law [EMAIL PROTECTED] * tree-ssa-reassoc.c (negate_value): Avoid num_imm_uses when checking for zero or one use. (reassociate_bb): Similarly. 2006-04-19 Alan Modra [EMAIL PROTECTED] PR rtl-optimization/26026 * fold-const.c (fold_binary): Optimize div and mod where the divisor is a known power of two shifted left a variable amount. 2006-01-06 Jeff Law [EMAIL PROTECTED] * tree-cfg.c (bsi_replace): Rename final argument from PRESERVE_EH_INFO to UPDATE_EH_INFO. Fix typo in last change (stmt - orig_stmt). * tree-eh.c (verify_eh_throw_stmt_node): New function. (bsi_remove): Add new argument. Remove EH information if requested. (verify_eh_throw_table_statements): New function. (bsi_remove): Add new argument REMOVE_EH_INFO. All callers updated. * tree-optimize.c (execute_free_cfg_annotations): Verify the EH throw statement table after removing annotations. * except.h (verify_eh_throw_table_statements): Prototype. * tree-flow.h (bsi_remove): Update prototype. * tree-vrp.c (remove_range_assertions): Add new argument to bsi_remove call. * tree-ssa-loop-im.c (move_computations_stmt): Likewise. * tree-complex.c (expand_complex_div_wide): Likewise. * tree-ssa-threadupdate.c (remove_ctrl_stmt_and_useless_edges): Likewise * tree-tailcall.c (eliminate_tailcall): Likewise. * tree-ssa-dse.c (dse_optimize_stmt): Likewise. * tree-ssa-loop-ivopts.c (remove_statement): Likewise. * tree-nrv.c (tree_nrv): Likewise. * tree-vectorizer.c (slpeel_make_loop_iterate_ntimes): Likewise. * tree-if-conv.c (tree_if_convert_cond_expr): Likewise. (combine_blocks): Likewise. * tree-ssa-phiopt.c (replace_phi_edge_with_variable): Likewise. * tree-cfgcleanup.c (cleanup_ctrl_expr_graph): Likewise. (cleanup_control_flow): Likewise. (remove_forwarder_block): Likewise. * tree-ssa-pre.c (remove_dead_inserted_code): Likewise. * tree-sra.c (sra_replace): Likewise. * tree-ssa-forwprop.c (forward_propagate_into_cond): Likewise. (forward_propagate_single_use_vars): Likewise. * tree-ssa-dce.c (remove_dead_stmt): Likewise. * tree-inline.c (expand_call_inline): Likewise. * tree-vect-transform.c (vect_transform_loop): Likewise. * tree-outof-ssa.c (rewrite_trees): Likewise. * tree-cfg.c (make_goto_expr_edges): Likewise. (cleanup_dead_labels): Likewise. (tree_merge_blocks, remove_bb, disband_implicit_edges): Likewise. (bsi_move_before, bsi_move_after): Likewise. (bsi_move_to_bb_end, try_redirect_by_replacing_jump): Likewise (tree_redirect_edge_and_branch, tree_split_block): Likewise. 2006-01-04 Jeff Law [EMAIL PROTECTED] * tree-cfg.c (bsi_replace): Remove the original statement from the EH throw statement table. 2005-12-19 Roger Sayle [EMAIL PROTECTED] * combine.c (try_combine): Improve splitting of binary operators by taking advantage of reassociative transformations. 2005-12-12 Jeff Law [EMAIL PROTECTED] * tree-ssa-dom.c (simplify_rhs_and_lookup_avail_expr): Remove reassociation code. * passes.c (init_optimization_passes): Run reassociation again after loop optimizations. 2005-12-12 Daniel Berlin [EMAIL PROTECTED] * tree-ssa-dom.c (thread_across_edge): Canonicalize condition if necessary. (optimize_stmt): Ditto. (canonicalize_comparison): New function. * tree-ssa-operands.c (swap_tree_operands): Make external. (get_expr_operands): Stop auto-canonicalization. * tree-ssa-reassoc.c: Rewrite. (init_optimization_passes): * tree-flow.h (swap_tree_operands): Prototype. * Makefile.in (tree-ssa-reassoc.o): Update dependencies. * gcc.dg/tree-ssa/ssa-pre-2.c: Update due to reassociation changes. * gcc.dg/tree-ssa/reassoc-1.c: Likewise. * gcc.dg/tree-ssa/reassoc-2.c: Likewise. * gcc.dg/tree-ssa/reassoc-3.c: Likewise. * gcc.dg/tree-ssa/reassoc-4.c: Likewise. * gcc.dg/tree-ssa/reassoc-5.c: New. * gcc.dg/tree-ssa/reassoc-6.c: New. * gcc.dg/tree-ssa/reassoc-7.c: New. * gcc.dg/tree-ssa/reassoc-8.c: New. * gcc.dg/tree-ssa/reassoc-9.c: New. *
[Bug rtl-optimization/32463] New: [4.0.2
-- Summary: [4.0.2 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alan dot hardin at paulsson dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32463
[Bug fortran/32464] New: ICE [4.3 regression]: USE in contained subroutine
Hi, the attached code started to ICE with gfortran 4.3.0 shortly after 20070416: % gfortran -c gfcbug64.f90 gfcbug64.f90:12: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Cheers, -ha -- Summary: ICE [4.3 regression]: USE in contained subroutine Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug rtl-optimization/32463] [4.0.2
--- Comment #1 from alan dot hardin at paulsson dot com 2007-06-22 17:33 --- Created an attachment (id=13764) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13764action=view) Test code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32463
[Bug fortran/32464] ICE [4.3 regression]: USE in contained subroutine
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-22 18:15 --- Herald, Both cases work for me on latest trunk. x86-64 I tried several compiler switches as well, no problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug target/32389] [4.1/4.2 Regression] ICE in extract_constrain_insn_cached when using -msse
--- Comment #7 from vapier at gentoo dot org 2007-06-22 18:17 --- the testcase was distilled by Harald van Dijk [EMAIL PROTECTED], not myself -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32389
[Bug fortran/32464] [4.3 regression] ICE: USE in contained subroutine
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-22 18:17 --- I can only partially reproduce this: I don't get a crash, but valgrind shows: ==12017== Conditional jump or move depends on uninitialised value(s) ==12017==at 0x45229B: gfc_resolve_expr (resolve.c:3272) ==12017==by 0x40BC7C: resolve_array_bound (array.c:218) ==12017==by 0x40BD2C: gfc_resolve_array_spec (array.c:252) ==12017==by 0x456B6C: resolve_symbol (resolve.c:6438) where resolve.c:3272: gcc_assert (expr sym == expr-symtree-n.sym); There are no valgrind errors with 4.2.0. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code Known to fail||4.3.0 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-06-22 18:17:45 date|| Summary|ICE [4.3 regression]: USE in|[4.3 regression] ICE: USE in |contained subroutine|contained subroutine Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug fortran/32464] [4.3 regression] ICE: USE in contained subroutine
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-06-22 18:26 --- Reduced testcase and backtrace: module gfcbug64_mod1 contains function copy (d) real, intent(in) :: d(:) real :: copy(size (d)) copy = d end function copy end module gfcbug64_mod1 module gfcbug64_mod2 contains subroutine foo (x_o) real, intent(in) :: x_o(5) integer :: s(size (x_o)) contains subroutine bar () use gfcbug64_mod1, only: copy end subroutine bar end subroutine foo end module gfcbug64_mod2 Program received signal SIGSEGV, Segmentation fault. 0x08095f00 in gfc_resolve_expr (e=0x88d1920) at ../../../gcc/gcc/fortran/resolve.c:3265 3265 gcc_assert (expr sym == expr-symtree-n.sym); (gdb) bt #0 0x08095f00 in gfc_resolve_expr (e=0x88d1920) at ../../../gcc/gcc/fortran/resolve.c:3265 #1 0x08051f8b in resolve_array_bound (e=0x88d1920, check_constant=0) at ../../../gcc/gcc/fortran/array.c:218 #2 0x0805202b in gfc_resolve_array_spec (as=0x88d1858, check_constant=0) at ../../../gcc/gcc/fortran/array.c:252 #3 0x0809acac in resolve_symbol (sym=0x88d0c08) at ../../../gcc/gcc/fortran/resolve.c:6444 #4 0x080a5327 in traverse_ns (st=0x88d0c90, func=0x809ab40 resolve_symbol) at ../../../gcc/gcc/fortran/symbol.c:2731 #5 0x080983fa in resolve_types (ns=0x88d0800) at ../../../gcc/gcc/fortran/resolve.c:7403 #6 0x080984c7 in resolve_types (ns=0x88d0218) at ../../../gcc/gcc/fortran/resolve.c:7414 #7 0x080984c7 in resolve_types (ns=0x888d1b0) at ../../../gcc/gcc/fortran/resolve.c:7414 #8 0x0809ab1c in gfc_resolve (ns=0x888d1b0) at ../../../gcc/gcc/fortran/resolve.c:7477 #9 0x0808e6ec in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3256 #10 0x080b005d in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:301 #11 0x08312f28 in toplev_main (argc=2, argv=0xbff77ce4) at ../../../gcc/gcc/toplev.c:1051 Due to the backtrace, I'd think this is related to PR30746. Adding Paul Thomas as CC. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, pault at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug libgcj/32465] Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code despite -fPIC
--- Comment #2 from hjl at lucon dot org 2007-06-22 18:26 --- On Linux, I got 02e1b960 1 OBJECT LOCAL HIDDEN 25 gnu::gcj::runtime::FinalizerThread::finalizer_ready It looks like assembler/linker on Solaris don't have proper visibility support. BTW, the last symbol visibility bug in GNU binutils was fixed on 2006-12-12. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32465
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
--- Comment #3 from ubizjak at gmail dot com 2007-06-22 18:29 ---
The testcase:
--cut here--
typedef struct
{
unsigned char exp[256];
}
expbap_t;
void
a52_bit_allocate (expbap_t * expbap)
{
int i;
unsigned char *exp;
exp = expbap-exp;
int lowcomp;
do
{
if (exp[i + 1] == exp[i] - 2)
lowcomp = 384;
else if (lowcomp (exp[i + 1] exp[i]))
lowcomp -= 64;
i++;
}
while ((i 3) || ((i 7) (exp[i] exp[i - 1])));
}
--cut here--
gcc -O3 -m32:
#0 build_classic_dist_vector_1 (ddr=0xf84eb0, ddr_a=0xf84460, ddr_b=0xf84f50,
dist_v=0x2e0aa260, init_b=0x7ed24dd7
\001#65533;\206#65533;#65533;#65533;*,
index_carry=0x7ed24dd0) at ../../gcc-svn/trunk/gcc/tree-data-ref.c:2700
#1 0x006c2175 in subscript_dependence_tester (ddr=0xf84eb0,
loop_nest=0x2dff86e0) at ../../gcc-svn/trunk/gcc/tree-data-ref.c:2998
#2 0x006c3068 in compute_all_dependences (datarefs=0xf781d0,
dependence_relations=0x7ed25108, loop_nest=0xf73920,
compute_self_and_rr=1 '\001')
at ../../gcc-svn/trunk/gcc/tree-data-ref.c:3805
#3 0x006c3ebd in compute_data_dependences_for_loop (
loop=0x2dff86e0, compute_self_and_read_read_dependences=22 '\026',
datarefs=0x7ed25110, dependence_relations=0x7ed25108)
at ../../gcc-svn/trunk/gcc/tree-data-ref.c:4117
#4 0x00a1d992 in tree_predictive_commoning_loop (loop=0x2dff86e0)
at ../../gcc-svn/trunk/gcc/tree-predcom.c:2488
#5 0x00a1ee85 in tree_predictive_commoning ()
at ../../gcc-svn/trunk/gcc/tree-predcom.c:2596
#6 0x00766ee7 in run_tree_predictive_commoning ()
at ../../gcc-svn/trunk/gcc/tree-ssa-loop.c:184
(gdb) list
2695 for (i = 0; i DDR_NUM_SUBSCRIPTS (ddr); i++)
2696{
2697 tree access_fn_a, access_fn_b;
2698 struct subscript *subscript = DDR_SUBSCRIPT (ddr, i);
2699
2700 if (chrec_contains_undetermined (SUB_DISTANCE (subscript)))
2701{
2702 non_affine_dependence_relation (ddr);
2703 return false;
2704}
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|regression |tree-optimization
Ever Confirmed|0 |1
GCC host triplet||i686-pc-linux-gnu
GCC target triplet||i686-pc-linux-gnu
Last reconfirmed|-00-00 00:00:00 |2007-06-22 18:29:05
date||
Summary|[4.3 Regression] internal |[4.3 Regression]
|compiler error: Segmentation|Segmentation fault in
|fault |build_classic_dist_vector_1(
||) at tree-data-ref.c:2700
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug fortran/31473] gfortran does not detect duplicate EXTERNAL or INTRINSIC declarations
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-22 18:33 --- Subject: Bug 31473 Author: dfranke Date: Fri Jun 22 18:33:35 2007 New Revision: 125954 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125954 Log: 2007-06-22 Daniel Franke [EMAIL PROTECTED] PR fortran/31473 * symbol.c (gfc_copy_attr): Emit errors for duplicate EXTERNAL/INTRINSIC statements. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31473
[Bug fortran/32464] [4.3 regression] ICE: USE in contained subroutine
--- Comment #5 from burnus at gcc dot gnu dot org 2007-06-22 18:34 --- Regression testing shows that it was introduced between 2007-05-11-r124613 and 2007-05-12-r124634. There were two Fortran patches checked in during that period: http://gcc.gnu.org/viewcvs?view=revrevision=124613 r124613 | pault | 2007-05-11 08:19:57 +0200 (Fri, 11 May 2007) | 12 lines 2007-05-11 Paul Thomas [EMAIL PROTECTED] PR fortran/31474 (decl.c) http://gcc.gnu.org/viewcvs?view=revrevision=124615 r124615 | pault | 2007-05-11 13:42:56 +0200 (Fri, 11 May 2007) | 19 lines 2007-05-11 Paul Thomas [EMAIL PROTECTED] PR fortran/30878 (resolve.c, symbol.c, trans-io.c) http://gcc.gnu.org/viewcvs?view=revrevision=124633 r124633 | pault | 2007-05-12 08:19:43 +0200 (Sat, 12 May 2007) | 15 lines 2007-05-12 Paul Thomas [EMAIL PROTECTED] PR fortran/30746 (resolve.c, match.h, gfortran.h) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug fortran/31473] gfortran does not detect duplicate EXTERNAL or INTRINSIC declarations
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-06-22 18:34 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31473
[Bug fortran/32464] [4.3 regression] ICE: USE in contained subroutine
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-06-22 18:38 --- r124633 | pault | 2007-05-12 08:19:43 +0200 (Sat, 12 May 2007) | 15 lines 2007-05-12 Paul Thomas [EMAIL PROTECTED] PR fortran/30746 (resolve.c, match.h, gfortran.h) The assert is triggered in check_host_association() which was introduced in this revision - that's why I added Paul as CC :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug fortran/20888] dereferencing NULL still accepted
--- Comment #2 from patchapp at dberlin dot org 2007-06-22 18:50 --- Subject: Bug number PR20888 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01656.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20888
[Bug middle-end/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #8 from uros at gcc dot gnu dot org 2007-06-22 18:51 --- Subject: Bug 32374 Author: uros Date: Fri Jun 22 18:51:28 2007 New Revision: 125955 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125955 Log: PR middle-end/32374 * expr.c (store_constructor): Do not clobber non-zeroed memory. testsuite/ChangeLog: PR middle-end/32374 * gcc.dg/pr32374.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32374.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #11 from burnus at gcc dot gnu dot org 2007-06-22 18:51 --- Grrr, I mean, I will test the patch now on amd64 ;-) Do you still need the stuff mentioned in comment #7 or not? I would guess not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug target/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #5 from ubizjak at gmail dot com 2007-06-22 18:55 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
[Bug middle-end/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #9 from ubizjak at gmail dot com 2007-06-22 18:55 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug c++/32466] New: illegal loop store motion of bitfield
#include stdio.h
void __attribute__ ((__noinline__))
add14(unsigned short int nextID)
{
struct {
unsigned short int id: 14;
} hdr;
hdr.id = nextID;
do {
hdr.id++;
if (printf (should print 0x: 0x%04X\n, (unsigned int)hdr.id))
break;
} while (1);
}
main()
{
add14 (0x3FFF);
return 0;
}
G++ miscompiles with optimization. GCC compiles correctly. Regression from
3.3.
--
Summary: illegal loop store motion of bitfield
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
GCC build triplet: i386-apple-darwin9
GCC host triplet: i386-apple-darwin9
GCC target triplet: i386-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32466
[Bug fortran/32464] [4.3 regression] ICE: USE in contained subroutine
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-22 19:16 --- One of the problems is that gfc_match_rvalue (expr); does not set expr to NULL by default or when an error occurs. Therefore gcc_assert (expr sym == expr-symtree-n.sym); does not fail but crashes randomly. One probably should fix gfc_match_rvalue rather than using simply expr = NULL in check_host_association. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug fortran/32467] New: STRUCTURE CONTAINING ALLOCATABLE ARRAY 'A' APPEARS IN COPYIN CLAUSE
Description: This negative test case was derived from OpenMP test omp1/F2_6_1_5a.f90. On p. 85 of the OpenMP API Version 2.5 May 2005 line 22 states: * Allocatable arrays may not appear in a copyin clause. The structure struct1 is made up of an allocatable array a. The structure appears in a threadprivate directive and in a copyin clause. This error should probably be detected at compile-time. gfortran -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../xt-gcc-4.2.0/configure --prefix=/opt/gcc/4.2.0/snos --disable-nls --libdir=/opt/gcc/4.2.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/4.2.0/snos/include/g++ --with-slibdir=/opt/gcc/4.2.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 4.2.0 20070514 (rpm:4) cat bug2832.f90 ! Derived from OpenMP test omp1/F2_6_1_5a.f90 use omp_lib implicit none integer, parameter :: NT = 4 integer :: nThreads(NT) type structure_1 integer, allocatable :: a(:) end type structure_1 type(structure_1),save :: struc1 !$omp threadprivate(struc1) !$call omp_set_dynamic(.true.) !$call omp_set_num_threads(NT) allocate(struc1 % a(2)) struc1 % a(1) = 1 struc1 % a(2) = 2 !$omp parallel copyin(struc1) nThreads(omp_get_thread_num()+1) = struc1 % a(1) !$omp end parallel print *, nThreads deallocate(struc1 % a) END ftn -O3 -fopenmp -o x bug2832.f90 /opt/xt-pe/2.1/bin/snos64/ftn: INFO: linux target is being used aprun -n 1 ./x 1 0 0 0 Application 217647 resources: utime 0, stime 0 NOTE: A compile-time message rejecting the use of struc1 in copyin is expected. Or, the restriction imposed by the API version 2.5 should be ignored and the correct answer produced, which is four 1's. -- Note: ftn is an alias for: /opt/gcc/4.2.0/bin/../snos/bin/gfortran -static -v -I/opt/xt-mpt/2.1/mpich2-64/GP/include -I/opt/xt-mpt/2.1/mpich2-64/GP/include -L/opt/xt-mpt/2.1/mpich2-64/GP/lib -I/opt/acml/3.6.1/gnu64/include -I/opt/xt-libsci/10.1.0/gnu/snos64/include -I/opt/xt-libsci/10.1.0/gnu/snos64/include/superlu -I/opt/xt-mpt/2.1/sma/P/include -L/opt/acml/3.6.1/gnu64/lib -L/opt/xt-libsci/10.1.0/gnu/snos64/lib -L/opt/xt-mpt/2.1/sma/P/lib -lmpichf90 -lsci -lacml -lsma -lmpichf90 -lmpich -lrt -D__CRAYXT_COMPUTE_LINUX_TARGET -D__TARGET_LINUX__ -fno-second-underscore -I/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/include -I/opt/xt-catamount/2.1/catamount/linux/include -I/opt/xt-service/2.1/include -L/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/lib/snos64 -L/opt/xt-pe/2.1/cnos/linux/64/lib -L/opt/xt-mpt/2.1/lib/snos64 -L/opt/xt-service/2.1/lib/snos64 -Wl,--start -lpct -lalpslli -lalpsutil -lportals -lpthread -Wl,--end -lgfortranbegin -lgfortran -lm -- Summary: STRUCTURE CONTAINING ALLOCATABLE ARRAY 'A' APPEARS IN COPYIN CLAUSE Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
[Bug middle-end/32459] internal compiler error: in build2_stat, at tree.c:3074
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-22 19:48 --- Then it's a dup of PR32417. *** This bug has been marked as a duplicate of 32417 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32459
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-22 19:48 --- *** Bug 32459 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug fortran/24965] Wrong file name in error message
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24965
[Bug fortran/32468] New: PRESENCE OF SECTIONS W/ 1 SECTION CAUSES PARALLEL REGION TO HAVE 1 THREAD, NOT 4
Description: This test case exhibits the problem that the presence of a SECTIONS directive with only one SECTION inside of a PARALLEL region causes only one thread to be created when omp_set_num_threads was previously called with 4 threads. If the directives internal to this PARALLEL region are commented out, 4 threads are created and the program produces expected output. The compiler used was GNU gfortran. The test case works as expected when compiled with PGI. gfortran -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../xt-gcc-4.2.0/configure --prefix=/opt/gcc/4.2.0/snos --disable-nls --libdir=/opt/gcc/4.2.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/4.2.0/snos/include/g++ --with-slibdir=/opt/gcc/4.2.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 4.2.0 20070514 (rpm:4) cat bug2831.f90 ! Derived from OpenMP test omp1/F2_1_1_2_1c.f90 use omp_lib implicit none integer, parameter :: NT = 4 integer :: nth !$call omp_set_dynamic(.false.) !$call omp_set_num_threads(NT) !$omp parallel default(none) shared(nth) print *, omp_get_thread_num(), omp_get_num_threads() !$omp sections !$omp section nth=omp_get_num_threads() !$omp endsections !$omp endparallel print *, 'nth=',nth,' NT=',NT END diff bug2831.f90 bug2831a.f90 11,12d10 !$omp sections !$omp section 14d11 !$omp endsections Incorrect output is produced: ftn -O0 -fopenmp -o x bug2831.f90 /opt/xt-pe/2.1/bin/snos64/ftn: INFO: linux target is being used aprun -n 1 ./x 0 1 nth= 1 NT= 4 Application 217361 resources: utime 0, stime 0 Correct output from program with sections/section directives removed: ftn -O0 -fopenmp -o xa bug2831a.f90 /opt/xt-pe/2.1/bin/snos64/ftn: INFO: linux target is being used aprun -n 1 ./xa 0 4 1 4 3 4 2 4 nth= 4 NT= 4 Application 217362 resources: utime 0, stime 0 -- Note: ftn is an alias for: /opt/gcc/4.2.0/bin/../snos/bin/gfortran -static -v -I/opt/xt-mpt/2.1/mpich2-64/GP/include -I/opt/xt-mpt/2.1/mpich2-64/GP/include -L/opt/xt-mpt/2.1/mpich2-64/GP/lib -I/opt/acml/3.6.1/gnu64/include -I/opt/xt-libsci/10.1.0/gnu/snos64/include -I/opt/xt-libsci/10.1.0/gnu/snos64/include/superlu -I/opt/xt-mpt/2.1/sma/P/include -L/opt/acml/3.6.1/gnu64/lib -L/opt/xt-libsci/10.1.0/gnu/snos64/lib -L/opt/xt-mpt/2.1/sma/P/lib -lmpichf90 -lsci -lacml -lsma -lmpichf90 -lmpich -lrt -D__CRAYXT_COMPUTE_LINUX_TARGET -D__TARGET_LINUX__ -fno-second-underscore -I/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/include -I/opt/xt-catamount/2.1/catamount/linux/include -I/opt/xt-service/2.1/include -L/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/lib/snos64 -L/opt/xt-pe/2.1/cnos/linux/64/lib -L/opt/xt-mpt/2.1/lib/snos64 -L/opt/xt-service/2.1/lib/snos64 -Wl,--start -lpct -lalpslli -lalpsutil -lportals -lpthread -Wl,--end -lgfortranbegin -lgfortran -lm -- Summary: PRESENCE OF SECTIONS W/ 1 SECTION CAUSES PARALLEL REGION TO HAVE 1 THREAD, NOT 4 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32468
[Bug fortran/32464] [4.3 regression] ICE: USE in contained subroutine
--- Comment #8 from burnus at gcc dot gnu dot org 2007-06-22 20:04 --- One probably should fix gfc_match_rvalue rather than using simply expr = NULL in check_host_association. At least setting result = NULL at the top of gfc_match_rvalue is wrong. (I don't know whether a single test case passes afterwards.) I think I stick to gfc_expr *expr = NULL; in check_host_association. The ICE fails for old_sym-name == size, i.e. for the intrinsic function SIZE. While old_sym != sym, they are both in the (old_)sym-module (intrinsic). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug libfortran/31501] libgfortran internal unit I/O performance issues
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-06-22 20:20 --- Keeping track of these here. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|20278 |32382 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31501
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #12 from spop at gcc dot gnu dot org 2007-06-22 20:20 --- Subject: Re: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize) Do you still need the stuff mentioned in comment #7 or not? I would guess not. No, I'm debugging that on an amd64. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug fortran/32467] structure containing allocatable array is accepted in COPYIN clause
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-22 20:28 --- Reduced testcase: $ cat pr32467.f90 use omp_lib integer, save, allocatable :: a(:) !$omp threadprivate(a) allocate(a(2)) a = 1 !$omp parallel copyin(a) print *, a(1) !$omp end parallel deallocate(a) end This code is accepted by gfortran and ifort alike, but rejected by sunf95. the original code with allocatable array components is accepted by sunf95 as well. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-suse-linux | GCC host triplet|x86_64-suse-linux | GCC target triplet|x86_64-suse-linux | Keywords||accepts-invalid, openmp Known to fail||4.2.1 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-06-22 20:28:31 date|| Summary|STRUCTURE CONTAINING|structure containing |ALLOCATABLE ARRAY 'A' |allocatable array is |APPEARS IN COPYIN CLAUSE|accepted in COPYIN clause http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
[Bug ada/32442] Ada 05 Null Exclusion Problem
--- Comment #1 from tiberius1 at gmx dot li 2007-06-22 20:35 --- The GNAT bug box is not showing up in SVN snapshot gcc-4.3-20070615 (configured with the same options as above) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32442
[Bug fortran/32467] structure containing allocatable array is accepted in COPYIN clause
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-22 20:38 --- Barf. The testcase in comment #1 is detected by gfortran-svn (20070522), the original testcase (allocatable structure components) is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
[Bug fortran/32467] structure containing allocatable array is accepted in COPYIN clause
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-22 20:42 --- Mine. Fix should be easy :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-06-22 20:28:31 |2007-06-22 20:42:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
[Bug fortran/32467] structure containing allocatable array is accepted in COPYIN clause
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-22 21:06 --- Thanks for the report. (By the way, ifort does accept the program and gives the right result whereas sunf95 has the same problem as gfortran.) There are actually two problems: a) Allocatable arrays may not appear in a copyin clause. This is violated for copyin(struc1) One should at least print a warning with -Wall, but I'm not sure whether one need to reject it as GCC seems to do the right thing (cf. (b)) b) If one replaces the allocatable :: a(:) by a(2) this constrain is met, but the number of threads is still (one thread per CPU core online) instead of being omp_set_num_threads(4). Reading and re-reading 2.4.1 I fail to find the place which says that with omp_set_dynamic(.true.) omp_set_num_threads(4) the number of threads is guaranteed to be 4. Using omp_set_dynamic(.false.) the situation is clear and gfortran (and sunf95) produce the same result. I have the feeling that the result of gfortran is perfectly valid. ifort seems to default for dyn-var = true to the specified number number of processors whereas sunf95 and gfortran seem to use min(CPU cores online, specified num_threads). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org URL||http://www.openmp.org/drupal ||/mp-documents/spec25.pdf Keywords|accepts-invalid |wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
[Bug fortran/32468] number of threads in a parallel region depends on number of SECTIONs and MAX_THREADS
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-22 21:37 --- Toying with the example shows that the number of threads in the parallel region always equals the minimum of the number of SECTIONs or the MAX_NUM_THREADS. I.e. adding another SECTION will create two threads, having 5 sections will result in 4 threads as NT==4. This is true for both, 4.2 and latest svn (20070622). Adding Jakub as CC. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, jakub at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-suse-linux | GCC host triplet|x86_64-suse-linux | GCC target triplet|x86_64-suse-linux | Keywords||openmp Known to fail||4.2.1 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-06-22 21:37:31 date|| Summary|PRESENCE OF SECTIONS W/ 1 |number of threads in a |SECTION CAUSES PARALLEL |parallel region depends on |REGION TO HAVE 1 THREAD, NOT|number of SECTIONs and |4 |MAX_THREADS http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32468
[Bug fortran/32468] number of threads in a parallel region depends on number of SECTIONs and MAX_THREADS
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-22 21:54 --- There are several issues, will fix them on Monday. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-22 21:37:31 |2007-06-22 21:54:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32468
[Bug fortran/32217] segfaults (at runtime) on UNPACK with zero-sized arrays
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-06-22 22:16 --- Created an attachment (id=13765) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13765action=view) proposed patch This fixes the test case. It'll be a while before I can regression-test and submit this, because I'm about to go on holiday :-) Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32217
[Bug rtl-optimization/32466] illegal loop store motion of bitfield
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-22 22:29 --- The tree level looks exactly the same between C and C++ front-ends while the C++ front-end gets the wrong code for some reason. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |rtl-optimization Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32466
[Bug driver/32469] New: error trying to exec 'cc1': execvp: No such file or directory
every invocation of gcc fails with such error: $ i386-mingw32-gcc hello_c.c -c -v Using built-in specs. Target: i386-mingw32 Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/i386-mingw32/bin --libdir=/usr/lib64 --libexecdir=/usr/lib64 --includedir=/usr/i386-mingw32/include --disable-shared --enable-threads --disable-nls --with-gnu-as --with-gnu-ld --with-mangler-in-ld --disable-sjlj-exceptions --enable-languages=c,c++ --enable-c99 --enable-long-long --disable-libstdcxx-pch --enable-__cxa_atexit --enable-libstdcxx-allocator=new --enable-cmath --with-long-double-128 --with-gxx-include-dir=/usr/i386-mingw32/include/c++/4.3.0 --build=x86_64-pld-linux --host=x86_64-pld-linux --target=i386-mingw32 Thread model: win32 gcc version 4.3.0 20070615 (experimental) cc1 -quiet -v -iprefix /usr/bin/../../lib64/gcc/i386-mingw32/4.3.0/ hello_c.c -quiet -dumpbase hello_c.c -mtune=i386 -auxbase hello_c -version -o /tmp/ccxepOxf.s i386-mingw32-gcc: error trying to exec 'cc1': execvp: No such file or directory as far i can see the `gcc' hasn't hardcoded path to cc1. e.g. /usr/lib64/gcc/i386-mingw32/4.3.0/cc1. -- Summary: error trying to exec 'cc1': execvp: No such file or directory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: x86_64-gnu-linux GCC host triplet: x86_64-gnu-linux GCC target triplet: i386-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32469
[Bug driver/32469] error trying to exec 'cc1': execvp: No such file or directory
--- Comment #1 from pluto at agmk dot net 2007-06-22 23:13 --- stat(/usr/bin/../../lib64/gcc/i386-mingw32/4.3.0/cc1, 0x7fff0e91cb00) = -1 ENOENT (No such file or directory) stat(/usr/bin/../../lib64/gcc/cc1, 0x7fff0e91cb00) = -1 ENOENT (No such file or directory) stat(/usr/bin/../../lib64/gcc/i386-mingw32/4.3.0/../../../../i386-mingw32/bin/i386-mingw32/4.3.0/cc1, 0x7fff0e91cb00) = -1 ENOENT (No such file or directory) stat(/usr/bin/../../lib64/gcc/i386-mingw32/4.3.0/../../../../i386-mingw32/bin/cc1, 0x7fff0e91cb00) = -1 ENOENT (No such file or directory) the /usr/bin/../../ looks bad. it should be rather a /usr/bin/../ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32469
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #16 from hubicka at ucw dot cz 2007-06-22 23:59 ---
Subject: Re: [4.3 Regression] cannot take address of bit field
Yes. It looks like a frontend bug if the tree was not marked addressable
before gimplification but would need to after.
This does not seem to be so easy, sadly. The occurences of missing
addressables are in a cases gimplifier expanding stuff into address
expression (so the address is not strictly taken in the language sense)
The attached patch bootstraps/regtests. I am simply using the gimple
code a-la ssa-alias.c to set the addressable flag instead of hooking
into frontend.
In some sense I like it because I don't think frontends needs to be in
busyness in computing TREE_ADDRESSABLE bit for middle end. On the other
hand I guess I should spend some time tomorrow to produce simple C++
testcases where the FE fails to set the bit.
Index: gimplify.c
===
--- gimplify.c (revision 125921)
+++ gimplify.c (working copy)
@@ -117,6 +117,17 @@ static enum gimplify_status gimplify_com
static bool cpt_same_type (tree a, tree b);
#endif
+/* Mark X addressable. Unlike the langhook we expect X to be in gimple
+ form and we don't do any syntax checking. */
+static void
+mark_addressable (tree x)
+{
+ while (handled_component_p (x))
+x = TREE_OPERAND (x, 0);
+ if (TREE_CODE (x) != VAR_DECL TREE_CODE (x) != PARM_DECL)
+return ;
+ TREE_ADDRESSABLE (x) = 1;
+}
/* Return a hash value for a formal temporary table entry. */
@@ -3434,7 +3445,7 @@ gimplify_modify_expr_rhs (tree *expr_p,
if (use_target)
{
CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1;
- lang_hooks.mark_addressable (*to_p);
+ mark_addressable (*to_p);
}
}
@@ -3957,6 +3968,8 @@ gimplify_addr_expr (tree *expr_p, tree *
the address of a call that returns a struct; see
gcc.dg/c99-array-lval-1.c. The gimplifier will correctly make
the implied temporary explicit. */
+
+ /* Mark the RHS addressable. */
ret = gimplify_expr (TREE_OPERAND (expr, 0), pre_p, post_p,
is_gimple_addressable, fb_either);
if (ret != GS_ERROR)
@@ -3972,8 +3985,7 @@ gimplify_addr_expr (tree *expr_p, tree *
is set properly. */
recompute_tree_invariant_for_addr_expr (expr);
- /* Mark the RHS addressable. */
- lang_hooks.mark_addressable (TREE_OPERAND (expr, 0));
+ mark_addressable (TREE_OPERAND (expr, 0));
}
break;
}
@@ -4011,7 +4023,7 @@ gimplify_asm_expr (tree *expr_p, tree *p
allows_mem, allows_reg, is_inout);
if (!allows_reg allows_mem)
- lang_hooks.mark_addressable (TREE_VALUE (link));
+ mark_addressable (TREE_VALUE (link));
tret = gimplify_expr (TREE_VALUE (link), pre_p, post_p,
is_inout ? is_gimple_min_lval : is_gimple_lvalue,
@@ -4140,7 +4152,7 @@ gimplify_asm_expr (tree *expr_p, tree *p
{
tret = gimplify_expr (TREE_VALUE (link), pre_p, post_p,
is_gimple_lvalue, fb_lvalue | fb_mayfail);
- lang_hooks.mark_addressable (TREE_VALUE (link));
+ mark_addressable (TREE_VALUE (link));
if (tret == GS_ERROR)
{
error (memory input %d is not directly addressable, i);
@@ -5562,7 +5574,7 @@ gimplify_expr (tree *expr_p, tree *pre_p
if (fallback == fb_lvalue)
{
*expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p);
- lang_hooks.mark_addressable (*expr_p);
+ mark_addressable (*expr_p);
}
break;
@@ -5575,7 +5587,7 @@ gimplify_expr (tree *expr_p, tree *pre_p
if (fallback == fb_lvalue)
{
*expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p);
- lang_hooks.mark_addressable (*expr_p);
+ mark_addressable (*expr_p);
}
break;
@@ -5763,7 +5775,7 @@ gimplify_expr (tree *expr_p, tree *pre_p
else if (fallback == fb_lvalue)
{
*expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p);
- lang_hooks.mark_addressable (*expr_p);
+ mark_addressable (*expr_p);
}
else
ret = GS_ALL_DONE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug tree-optimization/30563] [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #8 from hubicka at ucw dot cz 2007-06-23 00:00 --- Subject: Re: [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time This bug is extremely common (seen while compiling the Debian archive). Honza, can you take a look soon? I will check it tomorrow. However why users use -fno-unit-at-a-time at all? Do you have some idea what packages, except for kernel, use it? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-23 01:57 --- Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c The same failures occur on hppa-unknown-linux-gnu. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #7 from zadeck at naturalbridge dot com 2007-06-23 02:12 --- dave, i have a patch for this. i am doing regtests now and will have a patch posted first thing tomorrow. the bug is in dce.c:deletable_insn_p. The problem is that it does not look inside of parallels. so even though it supposed to not delete top level unspecs and top level sets, if they are buried inside a parallel, it does not consider them top level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug fortran/32446] F0.n output format fails with large numbers
--- Comment #10 from patchapp at dberlin dot org 2007-06-23 03:05 --- Subject: Bug number PR32446 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01683.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32446
[Bug fortran/32382] missed optimization in internal read
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-23 03:13
---
This problem is frontend related. We are building the switch case that tests
for the error conditions outside the loop that is constructed to do the scaler
transfers. Thus:
i = 1;
if (i = 100)
{
while (1)
{
{
logical4 D.1371;
_gfortran_transfer_integer (dt_parm.2,
intvalues[(int8) i + -1], 4);
L.4:;
D.1371 = i == 100;
i = i + 1;
if (D.1371) goto L.5;
}
}
}
L.5:;
_gfortran_st_read_done (dt_parm.2);
switch (dt_parm.2.common.flags 3)
{
case 1:;
goto __label_20;
case 2:;
goto __label_20;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug c++/32470] New: fvisibility=hidden without effect in some casses
Compiling the following code with fvisibility=hidden exports Test::test().
(The used compiler is 4.2.1 20070622. Version 4.2.0 on a i686 gives the same
results).
~$ cat test.cc
#include streambuf
class Test
{
void test();
};
void Test::test() { }
~$ g++ -fvisibility=hidden -fPIC -c -o test.o test.cc
~$ readelf -s test.o
Symbol table '.symtab' contains 12 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS test.cc
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT2
4: 0 SECTION LOCAL DEFAULT3
5: 0 SECTION LOCAL DEFAULT4
6: 0 SECTION LOCAL DEFAULT6
7: 0 SECTION LOCAL DEFAULT9
8: 0 SECTION LOCAL DEFAULT8
9: 10 FUNCGLOBAL DEFAULT1 _ZN4Test4testEv
10: 0 NOTYPE GLOBAL DEFAULT UND __gxx_personality_v0
11: 8 OBJECT WEAK HIDDEN6
DW.ref.__gxx_personality_
After removing #include streambuf from the testcase, Test::test() is hidden
as expected.
~$ g++ -fvisibility=hidden -fPIC -c -o test.o test.cc
~$ readelf -s test.o
Symbol table '.symtab' contains 12 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS test.cc
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT2
4: 0 SECTION LOCAL DEFAULT3
5: 0 SECTION LOCAL DEFAULT4
6: 0 SECTION LOCAL DEFAULT6
7: 0 SECTION LOCAL DEFAULT9
8: 0 SECTION LOCAL DEFAULT8
9: 10 FUNCGLOBAL HIDDEN1 _ZN4Test4testEv
10: 0 NOTYPE GLOBAL DEFAULT UND __gxx_personality_v0
11: 8 OBJECT WEAK HIDDEN6
DW.ref.__gxx_personality_
--
Summary: fvisibility=hidden without effect in some casses
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gd at spherenet dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32470
[Bug libfortran/32456] IO error message should show Unit/Filename
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-23 03:58 --- Fairly straight forward I think. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-23 03:58:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32456
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #10 from rob1weld at aol dot com 2007-06-23 04:21 --- (In reply to comment #9) Don't worry, it works correctly. ... Argument are pushed to the stack by the caller without any other communication with callee, so it is obvious that format string _must_ reflect the type of values on stack. Also note, that %f inherently converts float type to double, so your values on the stack are FUBAR as far as printf is concerned. That is working correctly ?!? Very well, but not so obvious. _IF_ we had argflaps (taken from the word mudflaps) we could get printf (or any other function) to type-check the variable on the stack (or anywhere!) at run-time and compare it to what it thought it should be. This could be a very powerful feature - but lack of it is not a bug :( . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
-- rob1weld at aol dot com changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #11 from kargl at gcc dot gnu dot org 2007-06-23 05:06 --- (In reply to comment #10) (In reply to comment #9) Don't worry, it works correctly. ... Argument are pushed to the stack by the caller without any other communication with callee, so it is obvious that format string _must_ reflect the type of values on stack. Also note, that %f inherently converts float type to double, so your values on the stack are FUBAR as far as printf is concerned. That is working correctly ?!? Very well, but not so obvious. _IF_ we had argflaps (taken from the word mudflaps) we could get printf (or any other function) to type-check the variable on the stack (or anywhere!) at run-time and compare it to what it thought it should be. This could be a very powerful feature - but lack of it is not a bug :( . (1) Try -Wformat (2) Send a patch that implements your argflaps (3) There is an expectation someone writing C might actually adhere to the Standard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
