[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941
Ramana Radhakrishnan changed:
What|Removed |Added
Target|arm-elf |arm-elf, arm-eabi
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.05.12 07:07:51
CC||ramana at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Ramana Radhakrishnan 2011-05-12
07:07:51 UTC ---
Occurs with trunk as well.
This is what I see with "GCC: (GNU) 4.7.0 20110413 (experimental) [trunk
revision 172363
strfp, [sp, #-4]!
addfp, sp, #0
subsp, sp, #20
vldmiar0, {d20-d21}
vmovq11, q10 @ v4sf
subsp, sp, #48
addr3, sp, #15
bicr3, r3, #15
vzip.32q10, q11
vstrd22, [r3, #16]
vstrd23, [r3, #24]
vstmiar3, {d20-d21}
vldmiar1, {d18-d19}
vmovq8, q9 @ v4sf
vmovd24, d21
vzip.32q9, q8
vstrd16, [r3, #16]
vstrd17, [r3, #24]
vstmiar3, {d18-d19}
vmovd26, d22
vmovd25, d16
vmovd23, d18
vmul.f32d16, d24, d25
vmul.f32d22, d26, d23
vmovd18, d19
vmul.f32d17, d20, d18
vmls.f32d16, d26, d18
vmls.f32d22, d20, d25
vmls.f32d17, d24, d23
vuzp.32d16, d22
vmovd18, d16
vmovd19, d17
vmovr0, r1, d18 @ v4sf
vmovr2, r3, d19
addsp, fp, #0
ldmfdsp!, {fp}
bxlr
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #2 from Jakub Jelinek 2011-05-12
07:20:30 UTC ---
extern void abort (void);
struct S { int f : 1; } s;
int v = -1;
void
foo (void)
{
s.f = (v & 1) > 0;
}
void
bar (unsigned int x)
{
if (x != -1U)
abort ();
}
int
main ()
{
foo ();
bar (s.f);
return 0;
}
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 rsand...@gcc.gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | --- Comment #2 from rsandifo at gcc dot gnu.org 2011-05-12 07:18:13 UTC --- The problem seems to be that arm_neon.h implementation of vzip* is returning the result by reference rather than by value.
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #3 from Jakub Jelinek 2011-05-12
07:29:37 UTC ---
extern void abort (void);
struct S { int f : 1; } s;
int v = -1;
void
foo (unsigned int x)
{
if (x != -1U)
abort ();
}
int
main ()
{
s.f = (v & 1) > 0;
foo (s.f);
return 0;
}
Smaller testcase which failed already in 4.2, apparently introduced in between
r97500 and r98750.
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #4 from Jakub Jelinek 2011-05-12
07:36:07 UTC ---
And even more reduced:
extern void abort (void);
struct S { int f : 1; } s;
int v = -1;
int
main ()
{
s.f = (v & 1) > 0;
if ((unsigned int) s.f != -1U)
abort ();
return 0;
}
[Bug tree-optimization/48975] New: ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975
Summary: ICE in execute_cse_reciprocals() with
-fno-tree-slp-vectorize
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com
Created attachment 24232
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24232
Output of "ajo-gcc -w -O1 -finline-functions -ftree-vectorize -ffast-math
-fno-tree-slp-vectorize -c test1281247203.c"
This reproduces for me with svn revision 173589 (2011-05-09). It doesn't
reproduce with gcc 4.5.1. I'm on Ubuntu 10.10, x86-64.
cat >test1281247203.c < 0) ? 0 : x+1;
}
void func_65(unsigned int x) {
int l_376 = -1;
lbl_469:
while (x) {
x = ADD(x);
}
}
EOF
gcc -w -O1 -finline-functions -ftree-vectorize -ffast-math
-fno-tree-slp-vectorize -c test1281247203.c
test1281247203.c: In function ‘func_65’:
test1281247203.c:5:6: internal compiler error: in execute_cse_reciprocals, at
tree-ssa-math-opts.c:512
This test case is reduced from the output of Csmith 2.1.0 (git hash 541a6480,
https://github.com/csmith-project/csmith/), using the following command line:
csmith --no-paranoid --longlong --no-pointers --arrays --jumps --consts
--no-volatiles --no-checksum --no-divs --no-muls --no-bitfields
--no-packed-struct -s 1281247203
[Bug target/48743] -march=native mis-detects AMD K6-2+ / K6-3 as Athlon - compiled C fails with "illegal instruction"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743 --- Comment #3 from Zuxy 2011-05-12 08:27:56 UTC --- Created attachment 24233 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24233 Proposed patch For a brief time AMD produced K6-2+ and K6-3+ processors, targeting mobile market. These processors support Extended 3DNow! but not CMOV or Extended MMX (a subset of SSE) and are detected as Athlon by GCC so GCC will generate CMOV for them, leading to #UD. The patch solves the problem by differentiating K6 and Athlon by Extended MMX rather than Extended 3DNow!.
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.12 07:19:50 CC||jakub at gcc dot gnu.org Known to work||4.2.3 Target Milestone|--- |4.3.6 Summary|Inliner bug with one-bit|[4.3/4.4/4.5/4.6/4.7 |(1-bit) bitfield|Regression] Inliner bug ||with one-bit (1-bit) ||bitfield Ever Confirmed|0 |1 Known to fail||4.3.3, 4.6.0, 4.7.0 --- Comment #1 from Jakub Jelinek 2011-05-12 07:19:50 UTC --- Confirmed, started in between r11 and r112000, but strangely works in 4.2 which has branched off in r117923. Looking into it.
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #3 from rsandifo at gcc dot gnu.org 2011-05-12 08:46:54 UTC --- Created attachment 24234 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24234 Proposed patch The attached patch seems to fix the testcase and doesn't regress neon.exp. I'll test it fully next week. We still generate more moves than necessary, but that's a separate problem.
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #5 from Jakub Jelinek 2011-05-12
08:29:09 UTC ---
Even smaller:
extern void abort (void);
struct S { int f : 1; } s;
int v = -1;
int
main ()
{
s.f = v < 0;
if ((unsigned int) s.f != -1U)
abort ();
return 0;
}
I'd say the bug is during expansion of a comparison with signed 1 bit type.
Then the comparison needs to result 0 / -1 instead of 0 / 1. I think it would
be difficult to adjust all the conditional expansion to handle this very rare
special case, so probably it will be better to expand such conditionals as
if it was unsigned:1 or unsigned char typed comparison, followed by cast from
that type to signed:1.
[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 Richard Guenther changed: What|Removed |Added CC||iant at google dot com --- Comment #5 from Richard Guenther 2011-05-12 08:51:25 UTC --- (In reply to comment #4) > I checked those errors with both binutils 2.21 release and 2.22 CVS (10th of > May). > > > gcc -### > Using built-in specs. > COLLECT_GCC=/???/x86_64-gcc-4.6.0/bin/gcc > COLLECT_LTO_WRAPPER=/???/x86_64-gcc-4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper > Target: x86_64-unknown-linux-gnu > Configured with: ../configure --prefix=/???/x86_64-gcc-4.6.0 --enable-shared > --with-arch=native --enable-languages=c,c++ --enable-lto --enable-plugin > --enable-gold --enable-linker-build-id --disable-multilib --enable-ld=default > --with-plugin-ld=ld.gold > Thread model: posix > gcc version 4.6.0 (GCC) > > If you mean CC=gcc -flto -fuse-linker-plugin, I get the same errors. With "using GNU ld" I mean configuring with --with-plugin-ld=ld.bfd (or omitting that configure option). I'm CCing a gold expert, maybe he can shed some light on that error. I suppose all object files _are_ built with -fPIC (eventually LTO takes some symbols local by making them have hidden visibility - can that cause issues?).
[Bug c++/48969] ICE with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48969 --- Comment #1 from Jonathan Wakely 2011-05-12 08:56:57 UTC --- it looks like tsubst recurses until it runs out of stack clang also segfaults with -std=c++0x, and not without
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||ice-checking Last reconfirmed||2011.05.12 09:14:00 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Summary|ICE in |[4.6/4.7 Regression] ICE in |execute_cse_reciprocals() |execute_cse_reciprocals() |with|with |-fno-tree-slp-vectorize |-fno-tree-slp-vectorize Target Milestone|--- |4.6.1 Known to fail||4.6.0, 4.7.0 --- Comment #1 from Jakub Jelinek 2011-05-12 09:14:00 UTC --- Confirmed, started in between r160500 and r161170, ICEs even on 4.6 branch if --enable-checking.
[Bug middle-end/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 --- Comment #6 from Richard Guenther 2011-05-12 09:00:59 UTC --- "Fixed" with bitfield lowering where we expand from v.0_1 = v; BF.1_3 = MEM[(struct S *)&s]; D.2700_4 = BF.1_3 & -2; D.2702_6 = v.0_1 < 0; BF.1_7 = D.2702_6 | D.2700_4; MEM[(struct S *)&s] = BF.1_7; D.2693_9 = () BF.1_7; D.2694_10 = (unsigned int) D.2693_9; if (D.2694_10 != 4294967295) similar to what Jakub proposed to do manually.
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 --- Comment #2 from Richard Guenther 2011-05-12 09:11:45 UTC --- Well, XXXevent is scalarized by SRA (-fno-tree-sra gets rid of the error) and I suppose nothing prevents that register to be propagated to other indirect uses. So it might be indeed live over the setjmp call.
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 --- Comment #2 from Jakub Jelinek 2011-05-12 09:25:46 UTC --- tree-if-conv.c fails to free_bb_predicate on some bbs, thus bb->aux is non-NULL on entry to following passes.
[Bug middle-end/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #7 from Jakub Jelinek 2011-05-12 09:04:30 UTC --- Created attachment 24235 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24235 gcc46-pr48973.patch Untested fix.
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #8 from Richard Guenther 2011-05-12 10:40:02 UTC --- Created attachment 24236 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24236 patch Patch I'm going to test.
[Bug middle-end/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 --- Comment #8 from Jakub Jelinek 2011-05-12 10:31:42 UTC --- (In reply to comment #6) > "Fixed" with bitfield lowering where we expand from > > v.0_1 = v; > BF.1_3 = MEM[(struct S *)&s]; > D.2700_4 = BF.1_3 & -2; > D.2702_6 = v.0_1 < 0; > BF.1_7 = D.2702_6 | D.2700_4; > MEM[(struct S *)&s] = BF.1_7; > D.2693_9 = () BF.1_7; > D.2694_10 = (unsigned int) D.2693_9; > if (D.2694_10 != 4294967295) > > similar to what Jakub proposed to do manually. Well, if bitfield lowering does this and nothing cleans it up, there is room for improvement. It would be sad if it couldn't be optimized already at the tree level back to: v.0_1 = v; BF.1_3 = MEM[(struct S *)&s]; D.2700_4 = BF.1_3 & -2; D.2702_6 = v.0_1 < 0; BF.1_7 = D.2702_6 | D.2700_4; MEM[(struct S *)&s] = BF.1_7; D.2693_9 = () D.2702_6; // change here. Assuming D.2702 // is either > 1 precision, or // unsigned D.2694_10 = (unsigned int) D.2693_9; if (D.2694_10 != 4294967295)
[Bug fortran/45823] Bogus warning for intrinsic module procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823
--- Comment #2 from Tobias Burnus 2011-05-12
10:35:23 UTC ---
(In reply to comment #1)
> This bug basically makes the option -Wsurprising useless in combination with
> iso_fortran_env.
Well, you can still use ONLY - which is a decent work around, unless you really
need the two functions.
Regarding the test case from comment 0: resolve_intrinsic is called twice -
once from resolve_symbol (which sets then ts.type) and then again for
resolve_function; the second call to resolve_intrinsic generates then the
warning.
The following patch should work. It prevents the warning but if one tries to
modify the type, one gets the normal module warning:
Error: Symbol 'compiler_options' at (1) already has basic type of CHARACTER
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1454,7 +1454,7 @@ resolve_intrinsic (gfc_symbol *sym, locus *loc)
if (isym)
{
if (sym->ts.type != BT_UNKNOWN && gfc_option.warn_surprising
- && !sym->attr.implicit_type)
+ && !sym->attr.implicit_type && !sym->from_intmod)
gfc_warning ("Type specified for intrinsic function '%s' at %L is"
" ignored", sym->name, &sym->declared_at);
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 --- Comment #3 from Jakub Jelinek 2011-05-12 11:09:36 UTC --- Created attachment 24237 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24237 gcc46-pr48975.patch The problem was that combine_blocks removes most of the bbs in the loop, keeps around only header, latch and maybe exit_bb, but free_bb_predicate is called in the caller on ifc_bbs entries starting with 0 (loop->header which stays, fine) up to number of remaining bbs in the loop - 1 (that number can be at most 3). But nothing reordered ifc_bbs entries, so it very well can free_bb_predicate of a removed bb (use after free) and can fail to free_bb_predicate for latch or exit_bb. This patch fixes it by free_bb_predicate for all bbs in the loop already before (some of) the bbs are removed and ensures the caller doesn't try to do that again.
[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952 --- Comment #3 from Jan Hubicka 2011-05-12 11:30:48 UTC --- Author: hubicka Date: Thu May 12 11:30:42 2011 New Revision: 173700 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173700 Log: PR lto/48952 * lto.c (do_whole_program_analysis): Do not register cgraph hooks. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #13 from Richard Guenther 2011-05-12 10:52:54 UTC --- (In reply to comment #12) > (In reply to comment #3) > > I have a patch that makes it fail on trunk as well. IVOPTs generates > > > > for (p = &a; p != &a - 3; --p) > > *(p + 3) = ... > > > > and alias analysis doesn't like this invalid pointer. > > > I wonder why ivopt does not select the iv candidate whose base is &a+3. I think that one is not in the list of initial candidates. I think for that sake we would want to add stripped &base + object size (+ 1?) (if we know it) as IV candidate iff iv->step is negative, iff iv->step is positive continue to add &base. I don't like the alias oracle fixups too much, but I guess we have to benchmark both alternatives.
[Bug middle-end/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 --- Comment #9 from Richard Guenther 2011-05-12 11:36:21 UTC --- (In reply to comment #8) > (In reply to comment #6) > > "Fixed" with bitfield lowering where we expand from > > > > v.0_1 = v; > > BF.1_3 = MEM[(struct S *)&s]; > > D.2700_4 = BF.1_3 & -2; > > D.2702_6 = v.0_1 < 0; > > BF.1_7 = D.2702_6 | D.2700_4; > > MEM[(struct S *)&s] = BF.1_7; > > D.2693_9 = () BF.1_7; > > D.2694_10 = (unsigned int) D.2693_9; > > if (D.2694_10 != 4294967295) > > > > similar to what Jakub proposed to do manually. > > Well, if bitfield lowering does this and nothing cleans it up, there is room > for improvement. It would be sad if it couldn't be optimized already at the > tree level back to: >v.0_1 = v; >BF.1_3 = MEM[(struct S *)&s]; >D.2700_4 = BF.1_3 & -2; >D.2702_6 = v.0_1 < 0; >BF.1_7 = D.2702_6 | D.2700_4; >MEM[(struct S *)&s] = BF.1_7; >D.2693_9 = () D.2702_6; // change here. Assuming D.2702 > // is either > 1 precision, or > // unsigned >D.2694_10 = (unsigned int) D.2693_9; >if (D.2694_10 != 4294967295) Yeah, we can combine that with the comparison - but I'm not sure we want to have compares with 1-bit precision quantities, do we? Or we want to optimize this to tem = D.2702_6 & CST; if (tem != 0) instead?
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #9 from Ira Rosen 2011-05-12 11:48:56 UTC --- (In reply to comment #8) > Created attachment 24236 [details] > patch > > Patch I'm going to test. So, segment_length = scalar_step * vf * scalar_niters? I think we don't need vf here. Also, why not do that only for different steps? Thanks, Ira
[Bug debug/48967] [4.6/4.7 Regression] ICE during use_narrower_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48967 --- Comment #3 from Jakub Jelinek 2011-05-12 11:59:34 UTC --- Author: jakub Date: Thu May 12 11:59:32 2011 New Revision: 173702 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173702 Log: PR debug/48967 * var-tracking.c (use_narrower_mode_test) : Return 1 if validate_subreg fails. * g++.dg/opt/pr48967.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/opt/pr48967.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/var-tracking.c
[Bug fortran/45823] Bogus warning for intrinsic module procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823 Thomas Henlich changed: What|Removed |Added CC||thenlich at users dot ||sourceforge.net --- Comment #1 from Thomas Henlich 2011-05-12 09:40:37 UTC --- Here is another example. The warning appears even if there are no calls to to compiler_options() or compiler_version(). This bug basically makes the option -Wsurprising useless in combination with iso_fortran_env. test_mod.f90: module test_mod use iso_fortran_env end module test_mod test.f90: use test_mod end >gcc -c test_mod.f90 >gfortran -c -Wsurprising test.f90 test.f90:1.12: use test_mod 1 Warning: Type specified for intrinsic function 'compiler_options' at (1) is ignored test.f90:1.12: use test_mod 1 Warning: Type specified for intrinsic function 'compiler_version' at (1) is ignored
[Bug fortran/48976] New: INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 Summary: INQUIRE with STREAM= not supported Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org Fortran 2003/2008 support INQUIRE for STREAM: "9.10.2.31 STREAM= specifier in the INQUIRE statement "The scalar-default-char-variable in the STREAM= specifier is assigned the value YES if STREAM is included in the set of allowed access methods for the file, NO if STREAM is not included in the set of allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether STREAM is included in the set of allowed access methods for the file or if the unit identified by file-unit-number is not connected to a file." However, gfortran rejects it with: INQUIRE(99, stream=str) 1 Error: Syntax error in INQUIRE statement at (1) character(len=20) :: str INQUIRE(99, stream=str) end
[Bug debug/48967] [4.6/4.7 Regression] ICE during use_narrower_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48967 --- Comment #2 from Jakub Jelinek 2011-05-12 11:54:36 UTC --- Author: jakub Date: Thu May 12 11:54:33 2011 New Revision: 173701 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173701 Log: PR debug/48967 * var-tracking.c (use_narrower_mode_test) : Return 1 if validate_subreg fails. * g++.dg/opt/pr48967.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr48967.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #2 from Tobias Burnus 2011-05-12 12:39:32 UTC --- Created attachment 24238 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24238 Test case (In reply to comment #1) > For the diagnostic, the following untested patch should do. Well, almost. It fails for FORMAT/fmt=; I have to admit that I do not quite understand why only for e->expr_type == EXPR_CONSTANT a default-kind character is tested for in io.c's resolve_tag_format. Jerry, could you have a look? I am a bit lost.
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #10 from Richard Guenther 2011-05-12 12:14:48 UTC --- Author: rguenth Date: Thu May 12 12:14:45 2011 New Revision: 173703 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173703 Log: 2011-05-12 Richard Guenther PR tree-optimization/48172 * tree-vect-loop-manip.c (vect_vfa_segment_size): Do not exclude the number of iterations from the segment size calculation. (vect_create_cond_for_alias_checks): Adjust. * gcc.dg/vect/pr48172.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr48172.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 --- Comment #3 from Andreas Schwab 2011-05-12 11:00:16 UTC --- That function doesn't actually call setjmp.
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172
--- Comment #12 from Richard Guenther 2011-05-12
12:46:10 UTC ---
Like this?
Index: gcc/tree-vect-loop-manip.c
===
--- gcc/tree-vect-loop-manip.c (revision 173703)
+++ gcc/tree-vect-loop-manip.c (working copy)
@@ -2353,23 +2353,19 @@ vect_create_cond_for_align_checks (loop_
Input:
DR: The data reference.
- VECT_FACTOR: vectorization factor.
- SCALAR_LOOP_NITERS: number of iterations.
+ LENGTH_FACTOR: segment length to consider.
Return an expression whose value is the size of segment which will be
accessed by DR. */
static tree
-vect_vfa_segment_size (struct data_reference *dr, int vect_factor,
+vect_vfa_segment_size (struct data_reference *dr, tree length_factor,
tree scalar_loop_niters)
{
tree segment_length;
segment_length = size_binop (MULT_EXPR,
fold_convert (sizetype, DR_STEP (dr)),
- size_int (vect_factor));
- segment_length = size_binop (MULT_EXPR,
- segment_length,
- fold_convert (sizetype, scalar_loop_niters));
+ fold_convert (sizetype, length_factor));
if (vect_supportable_dr_alignment (dr, false)
== dr_explicit_realign_optimized)
{
@@ -2465,10 +2461,12 @@ vect_create_cond_for_alias_checks (loop_
vect_create_addr_base_for_vector_ref (stmt_b, cond_expr_stmt_list,
NULL_TREE, loop);
- segment_length_a = vect_vfa_segment_size (dr_a, vect_factor,
- scalar_loop_iters);
- segment_length_b = vect_vfa_segment_size (dr_b, vect_factor,
- scalar_loop_iters);
+ if (!operand_equal_p (DR_STEP (dr_a), DR_STEP (dr_b), 0))
+ length_factor = scalar_loop_iters;
+ else
+ length_factor = size_int (vect_factor);
+ segment_length_a = vect_vfa_segment_size (dr_a, length_factor);
+ segment_length_b = vect_vfa_segment_size (dr_b, length_factor);
if (vect_print_dump_info (REPORT_DR_DETAILS))
{
I also think that the re-alignment adjustment needs to be multiplied
by DR_STEP (maybe we only support it for DR_STEP == 1 at the moment).
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #11 from Richard Guenther 2011-05-12 12:38:15 UTC --- (In reply to comment #9) > (In reply to comment #8) > > Created attachment 24236 [details] > > patch > > > > Patch I'm going to test. > > So, segment_length = scalar_step * vf * scalar_niters? > I think we don't need vf here. Hm, right. I'll prepare a followup. > Also, why not do that only for different steps? We don't know this at this point. Maybe we can change the structure of the code somewhat. I'll have a look. > Thanks, > Ira
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #13 from Ira Rosen 2011-05-12 13:02:39 UTC --- (In reply to comment #12) > Like this? > Yes, looks good to me. > > I also think that the re-alignment adjustment needs to be multiplied > by DR_STEP (maybe we only support it for DR_STEP == 1 at the moment). The realignment adjustment is for the case when we load two consecutive aligned vectors and extract the relevant elements from them (in Altivec): for a[1:4] we load a[0:3] and a[4:7]. So, the adjustment adds one more vector size to cover that additional loaded vector. I don't see why it needs to be multiplied by DR_STEP. Thanks, Ira
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Janne Blomqvist 2011-05-12 12:56:07 UTC --- Wouldn't a standard-conforming way to support Unicode file names be for gfortran to - Specify that the default character set is UTF-8. - Then an internal read or write could be used to do a UTF-8 <-> UTF-32 conversion, if the user program uses kind=4 characters. Or if the user program stuffs utf-8 data into default character variables, nothing needs to be done. - When passing a filename in the open statement, on posix this can be passed as-is to open(), on mingw the library would need to do a utf-8 -> utf-16 conversion, then call wopen(). And similarly for other syscalls where we pass path names (e.g. stat(), access() and so on). In any case, initially something like your patch in #c1 looks good; regardless of how/if we decide to support Unicode filenames, currently we don't do anything sensible for kind=4 file names. And as you say, it's a standard violation. Similarly to specifying the default character set as UTF-8, we could specify the default encoding as UTF-8 (see ENCODING= in OPEN (9.5.6.9) and INQUIRE (9.10.2.10)). That way we wouldn't need to handle the non-Unicode cases in 10.7.1 at all. I think we're mostly there already, really, what's lacking is perhaps a "GFortran and Unicode" chapter in the manual.
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972
--- Comment #4 from Tobias Burnus 2011-05-12
13:37:34 UTC ---
(In reply to comment #3)
> Wouldn't a standard-conforming way to support Unicode file names be for
> gfortran to
I am admittedly a bit lost.
> - Specify that the default character set is UTF-8.
What do you mean by that? I know 1 byte and 4 byte character variables, but I
do not see where UTF-8 fits in there. (One can place UTF-8 into
character(kind=1) - and it also kind of works OK. But if one wants to use
len(), string manipulation ("change 3 character to ..."), or tabulated I/O that
will fail. But as quirky workaround, one can use UTF-8 file names with kind=1
character variables - at least under Unix/Linux.)
Regarding the ENCODING= specifier: That's already used for the encoding of the
file content - one shan't use it to also modify the interpretation of the FILE
string.
I still think that the default character encoding should remain 1 byte
(kind=1), which is simply passed as is to "open()". And UCS-4 as FILE= argument
should simply be supported as vendor extension. One just needs to tell the
library that the string is in UCS-4. This wide string could then directly used
for Windows' _wopen or converted to UTF-8 for Unix/Linux. (The conversion
routine exists for UCS-4 <-> UTF-8 I/O.)
[Bug fortran/48977] New: -fpe-trap=denormal on x86 GLIBC systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48977 Summary: -fpe-trap=denormal on x86 GLIBC systems Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Kind of follow up to PR 38810 - and motivated by http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/894fb77cabc6e8c7 GLIBC (and POSIX) do not support FE_DENORMAL and thus -fpe-trap=denormal does not work. However, gfortran has a target version for denormal trapping: fpu-387.h has: if (options.fpe & GFC_FPE_DENORMAL) cw &= ~_FPU_MASK_DM; [...] if (has_sse()) [...] if (options.fpe & GFC_FPE_DENORMAL) cw_sse &= ~(_FPU_MASK_DM << 7); Expected: If FE_DENORMAL is not supported and target == fpu-387.h, the latter is used. (It could also be of interest for the IEEE modules.)
[Bug tree-optimization/48822] [4.5 Regression] G++ gets stucks and never finishes compilation when enabling -O2/3 optimization options.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48822 Richard Guenther changed: What|Removed |Added Known to work||4.6.1 Summary|[4.5/4.6 Regression] G++|[4.5 Regression] G++ gets |gets stucks and never |stucks and never finishes |finishes compilation when |compilation when enabling |enabling -O2/3 optimization |-O2/3 optimization options. |options.| --- Comment #9 from Richard Guenther 2011-05-12 14:08:22 UTC --- .
[Bug lto/48978] New: excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 Summary: excessive hash table allocation for large lto build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org I tried a large LTO build with gcc version 4.7.0 20110511 (experimental) (GCC) on a 18GB machine. It ended with lto1: out of memory allocating 8589934312 bytes after a total of 6827421696 bytes Since a 7+GB single malloc seems somewhat excessive I put a break point on xmalloc_failed. It looks like the hash tables are growing too aggressively? #0 xmalloc_failed (size=8589934312) at ../../gcc/libiberty/xmalloc.c:118 #1 0x00b1b8a8 in xcalloc (nelem=1073741789, elsize=8) at ../../gcc/libiberty/xmalloc.c:164 #2 0x00b16696 in htab_expand (htab=0x11949c0) at ../../gcc/libiberty/hashtab.c:558 #3 0x00b16faa in htab_find_slot_with_hash (htab=0x11949c0, element=0x7fff64c7d0c0, hash=2685589897, insert=INSERT) at ../../gcc/libiberty/hashtab.c:653 #4 0x005a9701 in lookup_type_pair (ob_p=0x1022380, visited_p=0x1022370, t1=, t2=) at ../../gcc/gcc/gimple.c:3284 #5 0x005b1235 in gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/gimple.c:3557 #6 gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/gimple.c:3473 #7 0x005b0d69 in gimple_types_compatible_p_1 (t1=0x2aff61dc3b28, t2=0x2affd032b150, p=0x197c33a70, sccstack=0x7fff64c7d188, sccstate=0x9817ee40, sccstate_obstack=0x7fff64c7d190) at ../../gcc/gcc/gimple.c:3717 #8 0x005af31e in gimple_types_compatible_p (t2=0x2affd032b150, t1=0x2aff61dc3b28) at ../../gcc/gcc/gimple.c:3987 #9 gimple_type_eq (t2=0x2affd032b150, t1=0x2aff61dc3b28) at ../../gcc/gcc/gimple.c: #10 0x00b16f1e in htab_find_slot_with_hash (htab=0x2aff56172a10, element=0x2affd032b150, hash=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/libiberty/hashtab.c:687 #11 0x005af4cd in gimple_register_type (t=0x2affd032b150) at ../../gcc/gcc/gimple.c:4480 #12 0x0049c670 in lto_ft_common (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:296 #13 0x0049c6b9 in lto_ft_decl_minimal (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:309 #14 lto_ft_decl_common (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:319 ---Type to continue, or q to quit--- #15 0x0049d25d in lto_ft_field_decl (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:364 #16 lto_fixup_types (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:542 #17 0x0049ddd0 in uniquify_nodes (from=671, data_in=) at ../../gcc/gcc/lto/lto.c:618 #18 lto_read_decls (from=671, data_in=) at ../../gcc/gcc/lto/lto.c:697 #19 lto_file_finalize (from=671, data_in=) at ../../gcc/gcc/lto/lto.c:921 #20 lto_create_files_from_ids (from=671, data_in=) at ../../gcc/gcc/lto/lto.c:939 #21 0x00b1b6cf in splay_tree_foreach_helper (data=0x7fff64c7d520, fn=0x49dca0 , node=0x825f6550) at ../../gcc/libiberty/splay-tree.c:242 #22 splay_tree_foreach (data=0x7fff64c7d520, fn=0x49dca0 , node=0x825f6550) at ../../gcc/libiberty/splay-tree.c:566 #23 0x0049f53c in lto_file_read (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:979 #24 read_cgraph_and_symbols (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:2321 #25 lto_main (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:2621 #26 0x006cf4aa in compile_file () at ../../gcc/gcc/toplev.c:570 #27 do_compile () at ../../gcc/gcc/toplev.c:1905 #28 toplev_main () at ../../gcc/gcc/toplev.c:1977 #29 0x2aff56c32a7d in __libc_start_main () from /lib64/libc.so.6 #30 0x00486c49 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Bug fortran/48979] New: FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Summary: FRACTION und EXPONENT return invalid results for infinity/NaN Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net program test_fractnan real, parameter :: pinfp = transfer(z'7F80', 0.0) real, parameter :: ninfp = transfer(z'FF80', 0.0) real, parameter :: nanp = transfer(z'7FD0', 0.0) real, parameter :: zerop = 0.0 real :: nan = nanp, pinf = pinfp, ninf = ninfp, zero = zerop print 100, zero, zero, fraction(zero), fraction(zero), exponent(zero) print 100, zerop, zerop, fraction(zerop), fraction(zerop), exponent(zerop) print 100, nan, nan, fraction(nan), fraction(nan), exponent(nan) print 100, nanp, nanp, fraction(nanp), fraction(nanp), exponent(nanp) print 100, ninf, ninf, fraction(ninf), fraction(ninf), exponent(ninf) print 100, ninfp, ninfp, fraction(ninfp), fraction(ninfp), exponent(ninfp) print 100, pinf, pinf, fraction(pinf), fraction(pinf), exponent(pinf) print 100, pinfp, pinfp, fraction(pinfp), fraction(pinfp), exponent(pinfp) 100 format (f10.5,1x,z8,1x,f10.5,1x,z8,1x,i11) end program test_fractnan Result: 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 0 NaN 7FD00.00 0 -Infinity FF80 -Infinity FF80 0 -Infinity FF80NaN 7FC0 -2147483645 Infinity 7F80 Infinity 7F80 0 Infinity 7F80NaN 7FC0 -2147483645 Expected result (-std=f2003): 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 2147483647 NaN 7FD0NaN 7FD0 2147483647 -Infinity FF80 -Infinity FF80 2147483647 -Infinity FF80 -Infinity FF80 2147483647 Infinity 7F80 Infinity 7F80 2147483647 Infinity 7F80 Infinity 7F80 2147483647 Expected result (-std=f2008): 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 2147483647 NaN 7FD0NaN 7FD0 2147483647 -Infinity FF80NaN 7FC0 2147483647 -Infinity FF80NaN 7FC0 2147483647 Infinity 7F80NaN 7FC0 2147483647 Infinity 7F80NaN 7FC0 2147483647 EXPONENT(X) Fortran 2003/2008: If X is an IEEE infinity or NaN, the result has the value HUGE (0). FRACTION(X) Fortran 2003: If X is an IEEE infinity, the result is that infinity. If X is an IEEE NaN, the result is that NaN. Fortran 2008: If X is an IEEE NaN, the result is that NaN. If X is an IEEE infinity, the result is an IEEE NaN. Bug 1: The program does not compile without -fno-range-check. Bug 2: Different results are returned for a variables with values of NaN/Infinity and compile-time constants NaN/Infinity. Bug 3: EXPONENT should be HUGE(0)=2147483647 for NaN/Infinity.
[Bug tree-optimization/48822] [4.5/4.6 Regression] G++ gets stucks and never finishes compilation when enabling -O2/3 optimization options.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48822 --- Comment #8 from Richard Guenther 2011-05-12 14:08:05 UTC --- Author: rguenth Date: Thu May 12 14:08:00 2011 New Revision: 173705 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173705 Log: 2011-05-12 Richard Guenther Backport from mainline 2011-05-02 Richard Guenther PR tree-optimization/48822 * tree-ssa-sccvn.c (set_ssa_val_to): Never go up the lattice. (process_scc): Indicate which iteration we start. * gcc.dg/torture/pr48822.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48822.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-sccvn.c
Re: [Bug lto/48978] New: excessive hash table allocation for large lto build
> I tried a large LTO build with gcc version 4.7.0 20110511 (experimental) > (GCC) > on a 18GB machine. It ended with > > lto1: out of memory allocating 8589934312 bytes after a total of 6827421696 > bytes > > Since a 7+GB single malloc seems somewhat excessive I put a break point > on xmalloc_failed. It looks like the hash tables are growing > too aggressively? I think the problem was introduced by Richi's last commit: 2011-05-12 Richard Guenther * gimple.c (gtc_visit): Compare TREE_ADDRESSABLE, handle NULLPTR_TYPE similar to VOID_TYPE. Defer type-leader lookup until after simple checks. (gimple_types_compatible_p): Likewise. (iterative_hash_gimple_type): Always hash pointer targets and function return and argument types. (iterative_hash_canonical_type): Do not hash TYPE_QUALS, hash TYPE_ALIGN. Do not hash TYPE_MIN/MAX_VALUE. (gimple_canonical_types_compatible_p): Compare TREE_ADDRESSABLE, handle NULLPTR_TYPE similar to VOID_TYPE. Handle non-aggregates completely in the simple compare section. (gimple_register_canonical_type): Query the cache again after registering. So reverting this patch might get you past the problem. Ysterday I was able to build your testcase with 3GB of ram, today it got out of memory, too. The hashtable is not expanding too irrationally, but it saves O(n^2) information. I would like to see it die for sure ;) Honza
[Bug c++/48980] New: Misleading error message when a conversion is invalid while calling a protected base constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48980
Summary: Misleading error message when a conversion is invalid
while calling a protected base constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dib...@ieee.org
Provided with this code:
class base {
protected:
base( int * ) {}
};
struct derived : base {
derived( const int * p ) : base( p ) {}
};
The compiler correctly detects that there is an error as using p as argument to
the constructor of base will break const-correctness. The error report
identifies that condition, but it also adds a misleading first error:
error.cpp: In constructor ‘derived::derived(const int*)’:
error.cpp:5: error: ‘base::base(int*)’ is protected
error.cpp:10: error: within this context
error.cpp:10: error: invalid conversion from ‘const int*’ to ‘int*’
error.cpp:10: error: initializing argument 1 of ‘base::base(int*)’
Clearly base::base(int*) is protected, but it is accessible from the context of
the constructor derived::derived(const int*), and the first 3 lines should not
be part of the error message.
This can be reproduced with the default g++ in ubuntu/linaro, and also with g++
4.0.3 (I don't know the exact compiler flags used, but I believe the error to
be independent of compiler flags, if it is not, I can find out the exact flags
used).
g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
[Bug lto/48978] excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 --- Comment #1 from Jan Hubicka 2011-05-12 15:29:42 UTC --- > I tried a large LTO build with gcc version 4.7.0 20110511 (experimental) > (GCC) > on a 18GB machine. It ended with > > lto1: out of memory allocating 8589934312 bytes after a total of 6827421696 > bytes > > Since a 7+GB single malloc seems somewhat excessive I put a break point > on xmalloc_failed. It looks like the hash tables are growing > too aggressively? I think the problem was introduced by Richi's last commit: 2011-05-12 Richard Guenther * gimple.c (gtc_visit): Compare TREE_ADDRESSABLE, handle NULLPTR_TYPE similar to VOID_TYPE. Defer type-leader lookup until after simple checks. (gimple_types_compatible_p): Likewise. (iterative_hash_gimple_type): Always hash pointer targets and function return and argument types. (iterative_hash_canonical_type): Do not hash TYPE_QUALS, hash TYPE_ALIGN. Do not hash TYPE_MIN/MAX_VALUE. (gimple_canonical_types_compatible_p): Compare TREE_ADDRESSABLE, handle NULLPTR_TYPE similar to VOID_TYPE. Handle non-aggregates completely in the simple compare section. (gimple_register_canonical_type): Query the cache again after registering. So reverting this patch might get you past the problem. Ysterday I was able to build your testcase with 3GB of ram, today it got out of memory, too. The hashtable is not expanding too irrationally, but it saves O(n^2) information. I would like to see it die for sure ;) Honza
[Bug libfortran/48982] New: libgfortran on sysv never uses fpsetmask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48982
Summary: libgfortran on sysv never uses fpsetmask
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicolai.sta...@zmaw.de
I'm working on Solaris10/SPARC.
nic@nic-desktop:~/gcc-4.5.3$ grep -r have_fpsetmask . | grep -v libgfor_
./libgfortran/configure.host:if test "x${have_fpsetmask}" = "xyes"; then
nic@nic-desktop:~/gcc-4.5.3$
have_fpsetmask won't ever be set anywhere.
libgfor_cv_have_fpsetmask ist set and should be tested instead.
This results in set_fpu coming from fpu-generic.h.
Compiling code w. -ffpe-trap=invalid,zero,overflow results in the following
warnings when executing the code:
Fortran runtime warning: IEEE 'invalid operation' exception not supported.
Fortran runtime warning: IEEE 'division by zero' exception not supported.
Fortran runtime warning: IEEE 'overflow' exception not supported.
Best regards
Nicolai
[Bug other/48981] New: bootstrap-lto -O3 produces miscompiled, broken gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48981
Summary: bootstrap-lto -O3 produces miscompiled, broken gcc
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
CC: rgue...@gcc.gnu.org
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
GCC crashes because of violation of strict aliasing rules. The same memory
location is accessed in vec_gc_o_reserve_1 through (struct vec_prefix *)
pointer, then in VEC_tree_base_quick_push through (struct VEC_tree_base *).
Optimization moves the code around in a wrong way.
This patch fixes it:
--- gcc/vec.c
+++ gcc/vec.c
@@ -37,11 +37,11 @@
struct vec_prefix
{
unsigned num;
unsigned alloc;
void *vec[1];
-};
+} __attribute__ ((may_alias));
#ifdef GATHER_STATISTICS
/* Store information about each particular vector. */
[Bug middle-end/45579] Re-enable IPA-CP for "fn spec"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45579 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka 2011-05-12 15:35:08 UTC --- Hmm, it should be fairly trivial to update cgraph virtual cloning code to actually handle those attributes...
[Bug rtl-optimization/48971] [4.7 regression] ICE with -msoft-float -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com, ||vmakarov at redhat dot com --- Comment #2 from Jeffrey A. Law 2011-05-12 15:14:54 UTC --- Vlad, this is an abort in setup_pressure_classes which apparently is totally broken for sparc -msoft-float.
[Bug c++/48980] Misleading error message when a conversion is invalid while calling a protected base constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48980 --- Comment #1 from Jonathan Wakely 2011-05-12 15:58:06 UTC --- With 4.6 you just get: d.cc: In constructor 'derived::derived(const int*)': d.cc:6:39: error: invalid conversion from 'const int*' to 'int*' [-fpermissive] d.cc:3:4: error: initializing argument 1 of 'base::base(int*)' [-fpermissive]
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-05-12 16:09:39 UTC --- (In reply to comment #0) > > Bug 1: > The program does not compile without -fno-range-check. > Can you explain why you think that this is a bug?
[Bug lto/48978] excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 --- Comment #2 from Andi Kleen 2011-05-12 16:16:19 UTC --- I will try. BTW this was a much larger test case (allyesconfig), the tarball I sent you is a much more limited config. Normally noone uses allyesconfig kernels (they barely boot), but they are a good stress tester for the compiler. Still I suspect the hash table expansion algorithms are not optimal. If you're already in the GB range you shouldn't be doubling anymore...
[Bug debug/48967] [4.6/4.7 Regression] ICE during use_narrower_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48967 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2011-05-12 13:53:33 UTC --- Fixed.
[Bug other/48983] New: No diagnostic message about no space left on device with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48983
Summary: No diagnostic message about no space left on device
with LTO
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
To reproduce it in GNU/Linux:
# mount -t tmpfs tmpfs /mnt -o size=4k
$ cat > 1.c
int main(void)
{
return 0;
}
^D
$ TMPDIR=/mnt gcc -flto 1.c
collect2: ld returned 1 exit status
[Bug lto/48978] excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 --- Comment #3 from Andi Kleen 2011-05-12 16:22:30 UTC --- looks like the revert is really needed, i just ran out of memory even on the small config on the large memory system.
[Bug other/48983] No diagnostic message about no space left on device with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48983 --- Comment #1 from Dmitry Gorbachev 2011-05-12 16:30:22 UTC --- Other not very informative messages (depending on the space and program size): /usr/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status lto-wrapper: gcc returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #5 from Tobias Burnus 2011-05-12 17:40:32 UTC --- Author: burnus Date: Thu May 12 17:40:29 2011 New Revision: 173708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173708 Log: 2011-05-12 Tobias Burnus PR fortran/48972 * resolve.c (resolve_intrinsic): Don't resolve module intrinsics multiple times. 2011-05-12 Tobias Burnus PR fortran/48972 * gfortran.dg/iso_c_binding_compiler_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/iso_c_binding_compiler_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #2 from Thomas Henlich 2011-05-12 17:34:27 UTC --- (In reply to comment #1) > (In reply to comment #0) > > > > Bug 1: > > The program does not compile without -fno-range-check. > > > > Can you explain why you think that this is a bug? I consider it a bug because the result of the expressions FRACTION(Infinity) and FRACTION(NaN) is defined by the Fortran standard, so the compiler should not throw an error on simplifying them. Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do).
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus 2011-05-12 17:49:25 UTC --- (In reply to comment #2) > Whether this really is a bug or not depends on whether one thinks that a > standard-compliant Fortran program should compile without requiring special > options (I do). So do I - but the question is whether it is standard conforming. NAN and INF are not Fortran numbers, cf. "13.4 Numeric models". Admittedly, IEEE and Fortran model numbers are widely mixed in the standard. However, strictly speaking, the IEEE functionality is only available if the relevant IEEE module is loaded and the feature is marked as supported. However, I have to admit that the error message should mention -fno-range-check; currently, it does not.
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 --- Comment #4 from Jakub Jelinek 2011-05-12 17:44:26 UTC --- Author: jakub Date: Thu May 12 17:44:23 2011 New Revision: 173709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173709 Log: PR tree-optimization/48975 * tree-if-conv.c (combine_blocks): Call free_bb_predicate on all bbs here and free and clear ifc_bbs at the end. * gcc.dg/pr48975.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr48975.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek 2011-05-12 17:49:48 UTC --- Fixed.
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 --- Comment #5 from Jakub Jelinek 2011-05-12 17:46:21 UTC --- Author: jakub Date: Thu May 12 17:46:15 2011 New Revision: 173710 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173710 Log: PR tree-optimization/48975 * tree-if-conv.c (combine_blocks): Call free_bb_predicate on all bbs here and free and clear ifc_bbs at the end. * gcc.dg/pr48975.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48975.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-if-conv.c
[Bug rtl-optimization/48971] [4.7 regression] ICE with -msoft-float -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971 --- Comment #3 from Vladimir Makarov 2011-05-12 17:57:58 UTC --- (In reply to comment #2) > Vlad, this is an abort in setup_pressure_classes which apparently is totally > broken for sparc -msoft-float. I found the wrong code. It is pretty simple but I need to check a few platforms because the fix might affect other platform builds. I hope I'll send the patch at the end of the day.
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #6 from Tobias Burnus 2011-05-12 17:44:21 UTC --- (In reply to comment #5) > New Revision: 173708 Wrong PR number - supposed to go to PR 45823
[Bug fortran/45823] Bogus warning for intrinsic module procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus 2011-05-12 17:45:15 UTC --- FIXED. Commit had the wrong PR number: URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173708 Log: 2011-05-12 Tobias Burnus PR fortran/48972 * resolve.c (resolve_intrinsic): Don't resolve module intrinsics multiple times. 2011-05-12 Tobias Burnus PR fortran/48972 * gfortran.dg/iso_c_binding_compiler_3.f90: New.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #4 from Steve Kargl 2011-05-12 18:21:46 UTC --- On Thu, May 12, 2011 at 05:53:10PM +, thenlich at users dot sourceforge.net wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 > > --- Comment #2 from Thomas Henlich > 2011-05-12 17:34:27 UTC --- > (In reply to comment #1) > > (In reply to comment #0) > > > > > > Bug 1: > > > The program does not compile without -fno-range-check. > > > > > > > Can you explain why you think that this is a bug? > > I consider it a bug because the result of the expressions FRACTION(Infinity) > and FRACTION(NaN) is defined by the Fortran standard, so the compiler should > not throw an error on simplifying them. > > Whether this really is a bug or not depends on whether one thinks that a > standard-compliant Fortran program should compile without requiring special > options (I do). > You're looking at the wrong standard. Gfortran is a Fortran 95 compiler (yes, it has many F03 and F08 extensions). The Fortran 95 standard states: 13.14.38 FRACTION(X) Result Value. The result has the value X*b**(-e), where b and e are as defined in 13.7.1 for the model representation of X. If X has the value zero, the result has the value zero. Neither NaN nor +-Inf can be represented as a model number.
[Bug libfortran/48960] OPEN statement modifies NEWUNIT variable on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48960 Jerry DeLisle changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #1 from Jerry DeLisle 2011-05-12 18:31:56 UTC --- Ok, on my list
[Bug other/48981] bootstrap-lto -O3 produces miscompiled, broken gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48981 --- Comment #1 from Andrew Pinski 2011-05-12 17:59:56 UTC --- Created attachment 24239 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24239 Patch which changes how vec base is done Can you try this patch? I have not tested it and have not even tried compiling it.
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.12 18:45:19 AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jerry DeLisle 2011-05-12 18:45:19 UTC --- I seem to recall this use to work. We need to check to see if this is a regression.
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #7 from Jerry DeLisle 2011-05-12 18:39:19 UTC --- Reply to comment#2, There are tags that are constants and some that are variable expressions, so you have to resolve the correct one. I have not looked for a while , but I think there is a resolve_tag_e or such.
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2011-05-12 18:55:39 UTC --- read_char calls setjmp.
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 --- Comment #2 from Jerry DeLisle 2011-05-12 19:04:46 UTC --- OK, I checked. We simply have not implemented this yet. I will do so.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #5 from Steve Kargl 2011-05-12 18:47:54 UTC --- On Thu, May 12, 2011 at 05:59:44PM +, burnus at gcc dot gnu.org wrote: > > Whether this really is a bug or not depends on whether one thinks that a > > standard-compliant Fortran program should compile without requiring special > > options (I do). > > So do I - but the question is whether it is standard conforming. NAN and INF > are not Fortran numbers, cf. "13.4 Numeric models". Admittedly, IEEE and > Fortran model numbers are widely mixed in the standard. However, strictly > speaking, the IEEE functionality is only available if the relevant IEEE module > is loaded and the feature is marked as supported. > >From F2003: Page 300: A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters, unless the intrinsic module IEEE_ARITHMETIC (section 14) is accessible and there is support for an infinite or a NaN result, as appropriate. Page 364: The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and IEEE_FEATURES provide support for exceptions and IEEE arithmetic. Whether the modules are provided is processor dependent. 1) Thomas's program does not USE IEEE_ARITHMETIC. 2) gfortran does not supply the ieee modules. So, calling fraction() with +-Inf and NaN is, I believe, technically non-conforming. I agree that having consistency between constant-folding and runtime results is desirable, I disagree on calling the need for -fno-range-check a bug.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #6 from Steve Kargl
2011-05-12 19:18:16 UTC ---
On Thu, May 12, 2011 at 07:03:34PM +, sgk at troutmask dot
apl.washington.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
>
> --- Comment #5 from Steve Kargl
> 2011-05-12 18:47:54 UTC ---
> On Thu, May 12, 2011 at 05:59:44PM +, burnus at gcc dot gnu.org wrote:
> > > Whether this really is a bug or not depends on whether one thinks that a
> > > standard-compliant Fortran program should compile without requiring
> > > special
> > > options (I do).
> >
> > So do I - but the question is whether it is standard conforming. NAN and INF
> > are not Fortran numbers, cf. "13.4 Numeric models". Admittedly, IEEE and
> > Fortran model numbers are widely mixed in the standard. However, strictly
> > speaking, the IEEE functionality is only available if the relevant IEEE
> > module
> > is loaded and the feature is marked as supported.
> >
>
> >From F2003:
>
> Page 300:
>
>A program is prohibited from invoking an intrinsic procedure
>under circumstances where a value to be returned in a subroutine
>argument or function result is outside the range of values
>representable by objects of the specified type and type parameters,
>unless the intrinsic module IEEE_ARITHMETIC (section 14) is accessible
>and there is support for an infinite or a NaN result, as appropriate.
>
> Page 364:
>
>The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and
>IEEE_FEATURES provide support for exceptions and IEEE arithmetic.
>Whether the modules are provided is processor dependent.
>
> 1) Thomas's program does not USE IEEE_ARITHMETIC.
> 2) gfortran does not supply the ieee modules.
>
> So, calling fraction() with +-Inf and NaN is, I believe,
> technically non-conforming.
>
> I agree that having consistency between constant-folding
> and runtime results is desirable, I disagree on calling the
> need for -fno-range-check a bug.
>
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,12 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);
+ if (mpfr_nan_p (x->value.real) != 0 || mpfr_inf_p (x->value.real) != 0)
+{
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
+ return result;
+}
+
if (mpfr_sgn (x->value.real) == 0)
{
mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
gives
0.000.00 0
0.000.00 0
NaN 7FD0NaN 7FD0 0
NaN 7FD0NaN 7FC0 0
-Infinity FF80 -Infinity FF80 0
-Infinity FF80 -Infinity FF80 3
Infinity 7F80 Infinity 7F80 0
Infinity 7F80 Infinity 7F80 3
fixing exponent is much more involved.
[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #6 from Ian Lance Taylor 2011-05-12 19:36:23 UTC --- I believe that gold will issue these warnings in some cases that GNU ld will not, but as far as I know gold will never issue them for code which was in fact compiled with -fPIC. Can you get a copy of a failing ltransNN.ltrans.o and attach it here, or at least attach the output of readelf -r on the file?
[Bug fortran/48977] -fpe-trap=denormal on x86 GLIBC systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48977
--- Comment #1 from Uros Bizjak 2011-05-12 19:43:56
UTC ---
Why not just:
Index: configure.host
===
--- configure.host(revision 173705)
+++ configure.host(working copy)
@@ -20,12 +20,6 @@
# DEFAULTS
fpu_host='fpu-generic'
-# HOST-SPECIFIC OVERRIDES
-case "${host_cpu}" in
- i?86 | x86_64)
-fpu_host='fpu-387' ;;
-esac
-
# CONFIGURATION-SPECIFIC OVERRIDES
if test "x${have_feenableexcept}" = "xyes"; then
fpu_host='fpu-glibc'
@@ -39,6 +33,12 @@
fpu_host='fpu-aix'
fi
+# HOST-SPECIFIC OVERRIDES
+case "${host_cpu}" in
+ i?86 | x86_64)
+fpu_host='fpu-387' ;;
+esac
+
# Some targets require additional compiler options for NaN/Inf.
ieee_flags=
case "${host_cpu}" in
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 --- Comment #5 from eggert at gnu dot org 2011-05-12 19:52:20 UTC --- A register may be live (after inlining), but the local variable XXXevent is not live across the setjmp call, so surely the warning is wrong even if the generated code is correct.
[Bug middle-end/48984] New: [4.7 Regression] Many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48984 Summary: [4.7 Regression] Many testsuite failures Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 173711: http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00490.html caused: FAIL: gcc.dg/pr45055.c (test for excess errors) FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 "x[^ ]* & y" 1 FAIL: gfortran.dg/block_name_1.f90 -O (internal compiler error) FAIL: gfortran.dg/block_name_1.f90 -O (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O0 (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O0 (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O1 (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O1 (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O2 (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O2 (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -Os (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -Os (test for excess errors) FAIL: gfortran.dg/gomp/pr39152.f90 -O (internal compiler error) FAIL: gfortran.dg/gomp/pr39152.f90 -O (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O1 (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O2 (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O2 (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/where_1.f90 -Os (internal compiler error) FAIL: gfortran.dg/where_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/where_nested_1.f90 -O (internal compiler error) FAIL: gfortran.dg/where_nested_1.f90 -O (test for excess errors) FAIL: gfortran.dg/where_operator_assign_1.f90 -O (internal compiler error) FAIL: gfortran.dg/where_operator_assign_1.f90 -O (test for excess errors) FAIL: gfortran.dg/where_operator_assign_2.f90 -O (internal compiler error) FAIL: gfortran.dg/where_operator_assign_2.f90 -O (test for excess errors) FAIL: gfortran.dg/where_operator_assign_3.f90 -O (internal compiler error) FAIL: gfortran.dg/where_operator_assign_3.f90 -O (test for excess errors) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O0 (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O1 (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 -fbounds-check (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 -fomit-frame-pointer -finline-functions (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 -fomit-frame-pointer -finline-functions -funroll-loops (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O3 -g (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -Os (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 -ftree-vectorize -msse2 (internal compiler error) FAIL: gfortran.fortran-torture/execute/intrinsic_associated_2.f90, -O0 (internal compiler error) FAIL: gfortran.fortr
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #7 from Steve Kargl
2011-05-12 20:10:19 UTC ---
Here's a better patch that gets the warning/error
messages correct.
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,12 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);
+ if (mpfr_nan_p (x->value.real) != 0 || mpfr_inf_p (x->value.real) != 0)
+{
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
+ return range_check (result, "FRACTION");
+}
+
if (mpfr_sgn (x->value.real) == 0)
{
mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
[Bug middle-end/48984] [4.7 Regression] Many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48984 --- Comment #1 from Andrew Pinski 2011-05-12 20:12:45 UTC --- bool in fortran can be multiple sizes.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #8 from Tobias Burnus 2011-05-12 20:36:05 UTC --- (In reply to comment #7) > + return range_check (result, "FRACTION"); Can we additionally add to the range_check() error messages a note like "This check can be disabled with the option -fno-range-check"? We already did so at several places. I think without, one does not know that one can easily disable it. An alternative would be to switch to the middle-end way of showing warning messages: warning: unused variable 'x' [-Wunused-variable] Analogously, the error could then be "[-frange-check]".
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972
--- Comment #8 from Janne Blomqvist 2011-05-12 21:02:40
UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > - Specify that the default character set is UTF-8.
>
> What do you mean by that? I know 1 byte and 4 byte character variables, but I
> do not see where UTF-8 fits in there. (One can place UTF-8 into
> character(kind=1) - and it also kind of works OK. But if one wants to use
> len(), string manipulation ("change 3 character to ..."), or tabulated I/O
> that
> will fail. But as quirky workaround, one can use UTF-8 file names with kind=1
> character variables - at least under Unix/Linux.)
Well, for backwards compatibility I strongly think we should keep kind=1 the
default. What I meant was that for bytes whose values are not part of the 7-bit
ASCII character set, we can interpret it as UTF-8, as UTF-8 is backwards
compatible with ASCII. In most cases this won't matter, but it matters e.g. as
discussed in this PR on mingw as we need to convert the default character
filename to utf-16.
The other option, I suppose, would be to regard the default character set as
some locale-dependent charset, and then use some char->wchar_t conversion
routines from the MS libc, assuming such things exist.
FWIW, the issue that the length of a string does not equal the width when
printed is not unique to utf-8. The same issue is seen with kind=4 (utf-32) as
well e.g. if one uses diacritic characters. So regardless of whether one uses
UTF-8, UTF-16 or UTF-32, with unicode one needs to be prepared for the fact
that the number of code points in a string might not be the same as the width.
Fortran is not really prepared for this, so I suppose that making the string
intrinsics etc. consider bytes==characters (for kind=1) is the best we can do
in any case.
> Regarding the ENCODING= specifier: That's already used for the encoding of the
> file content - one shan't use it to also modify the interpretation of the FILE
> string.
Yes, the point was not related to the FILE= issue. Rather, that if we make
utf-8 the default charset then it makes sense to also make the default file
encoding utf-8.
> I still think that the default character encoding should remain 1 byte
> (kind=1), which is simply passed as is to "open()".
Yes, I agree, at least for Unix. What about mingw, then, if the string contains
characters not part of the 7-bit ASCII charset? Will MS libc convert it into
UTF-16 assuming the encoding is according to the current locale, or what?
> And UCS-4 as FILE= argument
> should simply be supported as vendor extension. One just needs to tell the
> library that the string is in UCS-4.
I'm not convinced of the value of such an extension. Fortran already suffers
from too many vendor extensions.
> This wide string could then directly used
> for Windows' _wopen
Not really, since wchar_t on windows is a 16-bit type (utf-16), not a 32-bit
one.
> or converted to UTF-8 for Unix/Linux.
Well, that is also a choice that needs to be made, analogous on how to convert
default char file names to utf-16 on mingw. That is, do we convert the name to
UTF-8 or to whatever the charset of the current locale is (LC_CTYPE)?
So in one way it would be nice to make gfortran respect the current locale
charset, but OTOH Unicode was invented because the locale charset system is a
failure, and just using unicode everywhere would in some respects be simpler.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #10 from Steve Kargl
2011-05-12 20:54:38 UTC ---
Forgot the diff
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,14 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);
+ if (mpfr_nan_p (x->value.real) != 0 || mpfr_inf_p (x->value.real) != 0)
+{
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
+ if (gfc_option.allow_std & (GFC_STD_F2008|GFC_STD_F2003))
+ return result;
+ return range_check (result, "FRACTION");
+}
+
if (mpfr_sgn (x->value.real) == 0)
{
mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #9 from Steve Kargl 2011-05-12 20:53:37 UTC --- On Thu, May 12, 2011 at 08:40:48PM +, burnus at gcc dot gnu.org wrote: > (In reply to comment #7) > > + return range_check (result, "FRACTION"); > > Can we additionally add to the range_check() error messages a note like "This > check can be disabled with the option -fno-range-check"? We already did so at > several places. I think without, one does not know that one can easily disable > it. > > An alternative would be to switch to the middle-end way of showing warning > messages: >warning: unused variable 'x' [-Wunused-variable] > > Analogously, the error could then be "[-frange-check]". > I worked up the following patch. It now silently accepts fraction() for +-inf and nan for -std=gnu,f2003,f2008. If one uses -std=f95, you get a bunch of noise. I'll finish a patch on Saturday. EXPONENT() is going to be a little more work. When simplication does not apply, gfortran uses something like integer(kind=4) D.1559; integer(kind=4) D.1558; __builtin_frexpf (nan, &D.1558); D.1559 = D.1558; _gfortran_transfer_integer_write (&dt_parm.2, &D.1559, 4); to grab the fraction and exponent. For nan and +-inf, D.1558 is 0.
[Bug other/44574] Avoid use of atoi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574 --- Comment #2 from Joseph S. Myers 2011-05-12 21:08:14 UTC --- There are also uses of atol, atoll and atoq to eliminate. Also note some Ada code using atoi (surely there must be a more idiomatic Ada way of doing this?). It would be best to poison all these functions when the uses are eliminated. In some cases the use of atoi may be allowing a wider range of inputs (in terms of leading whitespace and trailing unrecognized characters) than should actually be allowed in the context. libiberty has a use of atoi in cplus-dem.c that is harmless (it's only used on a single-digit string) but pointless (C guarantees that the digit characters have consecutive integer values so you can just subtract '0', and this guarantee is already in C90).
[Bug web/46305] [Regression] Bugzilla: PR comment type of links: Comment links to the wrong bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46305 --- Comment #2 from Tobias Burnus 2011-05-12 21:37:08 UTC --- The current plan according to Frédéric is to defer it until Bugzilla 4.2, which should allow this feature without hacks - rather than introducing further hacks. (See attachments to PR 43011 for the currently required patches.)
[Bug web/46482] [bugzilla] emails not sent to gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46482 --- Comment #7 from Frédéric Buclin 2011-05-12 21:59:43 UTC --- Is it still happening these days? Or can this bug be closed?
[Bug web/46305] [Regression] Bugzilla: PR comment type of links: Comment links to the wrong bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46305 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.12 21:57:34 Ever Confirmed|0 |1 --- Comment #3 from Frédéric Buclin 2011-05-12 21:57:34 UTC --- Yes, should be easier to fix in 4.2.
[Bug web/46482] [bugzilla] emails not sent to gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46482 --- Comment #8 from Jonathan Wakely 2011-05-12 22:21:30 UTC --- I pointed out some delays of up to an hour at http://gcc.gnu.org/ml/gcc/2011-05/msg00138.html I haven't seen any failing to arrive entirely, but I only monitor c++ bugs
[Bug bootstrap/48679] [4.7 regression] bootstrap comparison failures on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48679 --- Comment #6 from Mikael Pettersson 2011-05-12 22:36:17 UTC --- It's expand_call(), initialize_argument_information(), precompute_register_parameters(), or load_register_parameters() that gets miscompiled in stage2. expand_call() is an external entry point, the next three are static functions that get completely inlined in expand_call(). Moving either of these four to a separate file compiled with the bootstrap compiler eliminates the code changes in alloca.o.
[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956 --- Comment #6 from stevenj at alum dot mit.edu 2011-05-12 22:33:59 UTC --- Thanks, I was somewhat aware of the additional requirements for applying patches to the official tree (probably I should also file a copyright assignment), but I wanted to check with you that I was on the right track first. I'm a bit swamped this week, but should be able to do all this next week.
[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956 --- Comment #7 from Manuel López-Ibáñez 2011-05-12 23:06:14 UTC --- (In reply to comment #6) > Thanks, I was somewhat aware of the additional requirements for applying > patches to the official tree (probably I should also file a copyright > assignment), but I wanted to check with you that I was on the right track > first. I'm a bit swamped this week, but should be able to do all this next > week. You should definitely get the copyright assignment, but you do not need to wait for it to submit the patch properly and get more feedback and approval.
[Bug lto/48978] excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 --- Comment #4 from Jan Hubicka 2011-05-12 22:53:39 UTC --- > looks like the revert is really needed, i just ran out of memory > even on the small config on the large memory system. Yep, it is something with the last Richi's patch. Things has worked reosnably well for me prveiously (through not quite sanely - 94% of WPA time went into type merging. Good news is that we could hope for really huge speedup fixing this relatively small part of compiler) I will try to revert it too and look into inliner dumps on kernel just if I can spot something obvious. Honza
[Bug c/48985] New: bogus buffer overflow warning and abort on static flexible array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48985
Summary: bogus buffer overflow warning and abort on static
flexible array member
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mse...@gmail.com
GCC emits a bogus warning on the program below which then aborts at runtime.
Note that when the strncpy (s.c, "012", 4) call in line 24 is removed GCC
doesn't emit a warning but the program still aborts even though there is no
buffer overflow.
For statically allocated flexible array members I would expect
__builtin_object_size() to report the actual size of the array rather than
zero, analogously to the case when the array is allocated dynamically.
$ cat z.c && gcc -D_FORTIFY_SOURCE -O2 z.c && ./a.out
#include
#include
#include
struct s {
int i;
char c[];
} s = { 1, "01234" };
size_t f (void) { return __builtin_object_size(&s.c, 0); }
size_t g (struct s *p) { return __builtin_object_size(p->c, 0); }
int main (void) {
struct s *p;
p = (struct s*)malloc (sizeof *p + 6);
printf ("%zu %zu\n", f (), g (p));
fflush (stdout);
strncpy (p->c, "012", strlen(s.c));
if (puts ("###"))
strncpy (s.c, "012", 4); /* line 24 */
strncpy (s.c, "012", strlen(s.c) + 1);
return 0;
}
In file included from /usr/include/string.h:642:0,
from z.c:3:
In function ‘strncpy’,
inlined from ‘main’ at z.c:24:17:
/usr/include/bits/string3.h:121:3: warning: call to __builtin___strncpy_chk
will always overflow destination buffer [enabled by default]
0 6
###
*** buffer overflow detected ***: ./a.out terminated
...
Aborted (core dumped)
[Bug fortran/48926] gfortran.dg/coarray/image_index_1.f90 -fcoarray=single -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48926 --- Comment #6 from Jack Howarth 2011-05-12 22:20:30 UTC --- (In reply to comment #5) > Dominique, I think you also have an x86_64-apple-darwin10. Do you also see > failures - for instance with -m32? > > (In reply to comment #2) > > - One failure on ia64-debian-linux-gnu (20110507): > > Whatever the reason was, it does not fail anymore. Thus, we have success (no > coarray failures) on i686, powerpc, x86_64, s390x and s390 under Linux, > FreeBSD, Darwin, and with hppa-Linux/hppa-hpux. > > I think there might be a true bug - but as long it does not fail with my > system, I cannot debug it. Thus, it needs to be debugged by someone on whose > system it fails. My mistake. I had the gcc/testsuite/gfortran.dg/coarray_20.f90 and gcc/testsuite/gfortran.dg/coarray/image_index_2.f90 left behind from http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00566.html.
