[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-10-22 06:45 --- The test case that has been attached shows a FORTRAN and Ada program that are equivalent (within their matrix multiply loop). The Ada one runs about 2x slower with about 3x the number of machine instructions in the inner loop. Why do you go through an indirection in Ada? Just write: type Real_Matrix is array(Integer range ,Integer range ) of Float; N : Positive := Positive'Value (Argument (1)); G : Ada.Numerics.Float_Random.Generator; A,B,C : Real_Matrix (1..N, 1..N); Start, Finish : Ada.Calendar.Time; Sum : Float := 0.0; and you'll probably significantly narrow the gap. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-22 06:45:13 date|| Summary|Ada produces substantially |Poor code generated for |slower code than FORTRAN for|arrays with variable bounds |identical inputs - looping | |over double subscripted | |arrays | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug fortran/29452] Keyword check for specifiers in WRITE, READ and OPEN/CLOSE
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:15 --- (In reply to comment #1) - A compile-time-error is shown (probably fixed by FX patch, not checked) Yes, it's fixed by my patch. Confirming this bug. Tobias, if you want to submit a global patch to resolve these issues (both compile-time and run-time), I'll be happy to review it. 4.3 is in stage 1, it's time for change! :) PS: for the compile-time checks, you can probably use the compare_to_allowed helper routine I added in my OPEN/CLOSE checks patch; most of the work is probably reading both F95 and F2003 to spot the differences. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-22 07:15:24 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29452
[Bug fortran/29453] [g77 support] chmod intrinsic function not implemented in gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:18 --- No, it's implemented, it's only that the subroutine and function with the same name cannot be called in the same scoping unit. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29453
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:19 --- Confirmed. This one will probably be implemented after ISO_C_BINDING. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-22 07:19:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
[Bug fortran/26025] Optionally use BLAS for matmul
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:42 --- Subject: Bug 26025 Author: fxcoudert Date: Sun Oct 22 07:41:48 2006 New Revision: 117948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117948 Log: PR fortran/26025 * lang.opt: Add -fexternal-blas and -fblas-matmul-limit options. * options.c (gfc_init_options): Initialize new flags. (gfc_handle_option): Handle new flags. * gfortran.h (gfc_option): Add flag_external_blas and blas_matmul_limit flags. * trans-expr.c (gfc_conv_function_call): Use new argument append_args, appending it at the end of the argument list built for a function call. * trans-stmt.c (gfc_trans_call): Use NULL_TREE for the new append_args argument to gfc_trans_call. * trans.h (gfc_conv_function_call): Update prototype. * trans-decl.c (gfc_build_intrinsic_function_decls): Add prototypes for BLAS ?gemm routines. * trans-intrinsic.c (gfc_conv_intrinsic_funcall): Generate the extra arguments given to the library matmul function, and give them to gfc_conv_function_call. * invoke.texi: Add documentation for -fexternal-blas and -fblas-matmul-limit. * m4/matmul.m4: Add possible call to gemm routine. * generated/matmul_r8.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r4.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i16.c: Regenerate. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26025
[Bug fortran/26025] Optionally use BLAS for matmul
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:43 --- Fixed on mainline. -- fxcoudert 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=26025
[Bug fortran/22547] Fortran 2003: ISO_FORTRAN_ENV intrinsic module missing
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:45 --- I don't think we want to have a real .mod file somewhere, but I know how I'll implement it internally. I'll do it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-30 19:42:36 |2006-10-22 07:45:25 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22547
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #7 from richard at codesourcery dot com 2006-10-22 08:51 --- Subject: Re: [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions daney at gcc dot gnu dot org [EMAIL PROTECTED] writes: Richard, does this look right? Looks good to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit
--- Comment #5 from aldot at gcc dot gnu dot org 2006-10-22 11:36 --- I think the code in comment #1 is valid. f95, 5.5.2.4 Differences between named common and blank common reads: A blank common block has the same properties as a named common block except (iii) [...] objects in blank common shall not be initially defined. 11.8 defines BLOCK DATA as block-data-stmt [specification-part] end-block-data-stmt where [specification-part] lists no further constrained (wrt blank common). blank-common imposed constraints seem to include - 5.1 Type decl stmts: [initialization] shall not appear if obj-name is [...] an object in blank common So i don't really see why the testcase in Comment #1 is invalid. I do, however, consider the snippet below to be invalid (initialization seems forbidden by the above): Block data __BLKDT__ (line-no.)(nest) 1block data 2 common c 3 data c /1/ 4end !block data Diagnostic messages: program name(__BLKDT__) 8657-W: SOURCE.F90, line 3: Element 'c' of blank common block cannot be initialized. Procedure information Lines : 4 Statements : 4 Scoping unit of blockdata : __BLKDT__ Attribute and Cross reference of name c |(Class and Type) : variable name, REAL(4)-implicit |(Attributes) : common-block-object, initialized |(Declaration): 2 3 |(Definition) : |(Reference) : -- aldot at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE in gfc_match_common |ICE in gfc_match_common for ||blank common in BLOCK DATA ||unit http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit
--- Comment #6 from aldot at gcc dot gnu dot org 2006-10-22 11:50 ---
I think the code in comment #1 is valid.
Rejecting blank common in block data stmts would add a regression in
testsuite's blockdata_1.f90 like so:
[EMAIL PROTECTED]:~/src/gcc-4.2/gcc/testsuite/gfortran.dg$ gfortran-4.2-HEAD -S
-o foo.s
-W -Wall blockdata_1.f90
In file blockdata_1.f90:17
common j
1
Error: BLOCK DATA unit cannot contain blank COMMON at (1)
In file blockdata_1.f90:18
data j /1/
1
Error: BLOCK DATA element 'j' at (1) must be in COMMON
So rejecting the blank common must be wrong, fwiw :)
--- match.c (revision 117934)
+++ match.c (working copy)
@@ -2327,16 +2328,20 @@ gfc_match_common (void)
if (name[0] == '\0')
{
+ if (gfc_current_ns-is_block_data)
+ {
+ gfc_error (BLOCK DATA unit cannot contain blank COMMON at %C);
+ goto cleanup;
+ }
t = gfc_current_ns-blank_common;
if (t-head == NULL)
t-where = gfc_current_locus;
- head = t-head;
}
else
{
t = gfc_get_common (name, 0);
- head = t-head;
}
+ head = t-head;
if (*head == NULL)
tail = NULL;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #5 from laurent at guerby dot net 2006-10-22 12:04 --- Eric, if the type is Long_Float your solution will be much worse since the alignement on the stack of the matrices will be 4-bytes so you have 50% chance the code will be N times slower (when not 8-bytes aligned). So in practice you have to go malloc in order to get proper alignment for Long_Float, and there is no reason the proposed code should perform badly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug fortran/28585] Fortran 2003: Support NEW_LINE intrinsic
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-22 12:26 --- Fixed in 4.2 and later, thanks to Tobias. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28585
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-10-22 12:42 --- Eric, if the type is Long_Float your solution will be much worse since the alignement on the stack of the matrices will be 4-bytes so you have 50% chance the code will be N times slower (when not 8-bytes aligned). You're over-generalizing. Choose a saner architecture or use -malign-double. So in practice you have to go malloc in order to get proper alignment for Long_Float, and there is no reason the proposed code should perform badly. No, but there is an obvious one why the Fortran version trounces the Ada version. Let's not compare apples with oranges. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #3 from falk at debian dot org 2006-10-22 12:50 --- This bug is still there in 4.1, but not in mainline. Janis, can you perhaps do a regression hunt to see what fixed this and whether it is feasible to backport? -- falk at debian dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug preprocessor/29546] New: Wrong preprocessing when value of a define is powerpc
When you want to set the powerpc string as a value of a define (-D or #define), you get the integer value 1 instead of the string. Here's an example : test.c : - Arch = ARCH - With the powerpc string (bug) : gcc -E -DARCH=powerpc test.c Result is : # 1 test.c # 1 built-in # 1 command line # 1 test.c Arch = 1 With another string (no bug) : gcc -E -DARCH=ia32 test.c Result is : # 1 test.c # 1 built-in # 1 command line # 1 test.c Arch = ia32 == GCC Config == Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.1.2 20061007 (prerelease) (Debian 4.1.1-16) -- Summary: Wrong preprocessing when value of a define is powerpc Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: glibersat at linux62 dot org GCC build triplet: powerpc-linux-gnu GCC host triplet: powerpc-linux-gnu GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29546
[Bug target/29541] Enable IBM long double format in PowerPC Linux soft float
--- Comment #2 from joseph at codesourcery dot com 2006-10-22 13:20 --- Subject: Re: Enable IBM long double format in PowerPC Linux soft float On Sat, 21 Oct 2006, pinskia at gcc dot gnu dot org wrote: There was talking about this on the mailing list but I cannot find it right now. This is glibc bug 2749: http://sources.redhat.com/bugzilla/show_bug.cgi?id=2749 which has all the necessary patches to both GCC and glibc. To all intents and purposes we have a regression for PowerPC GNU/Linux soft-float: current GCC+glibc are broken, pre-4.1 GCC and glibc 2.3 worked. In order to fix this regression, a fix to a soft-fp bug is needed. As per the FSF copyright policy, this must go in glibc first. http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html says: RMS says: The GLIBC developers should accept some conditionals into their source, so that we do not have two diverging versions. We should all talk together to make this happen. He doesn't say that they should also accept bug fixes, but I think that can be taken for granted. Steven Munroe has submitted the relevant glibc fixes several times, both to libc-alpha (for core glibc) and libc-ports (for ports) and to that glibc bug report, but they have not been reviewed. I have stated on libc-alpha that I believe the patches are correct, but I only maintain soft-fp for GCC and cannot approve GCC-local changes that are not in glibc, and my own soft-fp patches for glibc are not reviewed either. At this point, I do not believe that the FSF copyright policy is workable in the soft-fp case and so ask that the SC revisit it with RMS and the glibc SC with a view to obtaining one of the following conclusions: * Local changes for soft-fp are permitted in GCC (subject to review by GCC soft-fp maintainers) until effective and prompt review and commit to glibc CVS of such changes is available when they are submitted to glibc. * In conjunction with the glibc maintainers, agreement is obtained that glibc maintainers will review and commit more promptly changes to soft-fp since it is imported into GCC and so they have responsibility in this regard to more than just its users within glibc. * glibc maintainers move soft-fp to the glibc ports repository, along with the Alpha, Sparc and PowerPC code that uses it, and allow other maintainers to maintain the code in the ports repository. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29541
[Bug preprocessor/29546] Wrong preprocessing when value of a define is powerpc
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-22 13:21 --- powerpc is one of the standard defines gcc defines if running on ppc-linux. It is changed to __powerpc if you define powerpc yourself. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29546
[Bug preprocessor/29546] Wrong preprocessing when value of a define is powerpc
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-22 14:15 --- Note if you add -pedantic or -ansi or -std=c99 or -std=c89, powerpc will not be defined as it is not in the reserved space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29546
[Bug middle-end/23295] fold does not simplify -a - (5) to (-5) - a
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-22 14:45 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-18 17:40:06 |2006-10-22 14:45:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2006-10-22 15:00 --- Subject: Re: ICE in gfc_match_common for blank common in BLOCK DATA unit On Sun, Oct 22, 2006 at 11:36:15AM -, aldot at gcc dot gnu dot org wrote: --- Comment #5 from aldot at gcc dot gnu dot org 2006-10-22 11:36 --- I think the code in comment #1 is valid. f95, 5.5.2.4 Differences between named common and blank common reads: A blank common block has the same properties as a named common block except (iii) [...] objects in blank common shall not be initially defined. 11.8 defines BLOCK DATA as block-data-stmt [specification-part] end-block-data-stmt where [specification-part] lists no further constrained (wrt blank common). blank-common imposed constraints seem to include - 5.1 Type decl stmts: [initialization] shall not appear if obj-name is [...] an object in blank common You're reading the wrong standard. The final committe draft of Fortran 95 states: 11.4Block data program units A block data program unit is used to provide initial values for data objects in named common blocks. I'll note that NAG's compiler only issues a warning. laptop:kargl[212] cat l.f90 block data a common c end block data a laptop:kargl[213] f95 -c l.f90 Warning: l.f90, line 2: Blank common appears in BLOCK DATA A If F2003 removes the named modifier from common blocks in its discussion on block data, then gfortran should probably implement the F2003 behavior with the caveat that -std=f95 should issue a warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-10-22 15:03 --- No, but there is an obvious one why the Fortran version trounces the Ada version. Let's not compare apples with oranges. The adverse effect of the indirection can be alleviated though: N : Positive := Positive'Value (Argument (1)); G : Ada.Numerics.Float_Random.Generator; type Real_Matrix is array (1..N, 1..N) of Float; type Matrix_Access is access Real_Matrix; A,B,C : Matrix_Access; Start, Finish : Ada.Calendar.Time; Sum : Float := 0.0; begin A := new Real_Matrix; B := new Real_Matrix; C := new Real_Matrix; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug middle-end/23666] Fold does not reduce C - ~a into a + (C+1)
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-22 15:12 --- With the patch for 23295 we get the behavior as noted in comment #7. This is due to negate_expr_p (correctly) containing case BIT_NOT_EXPR: return INTEGRAL_TYPE_P (type) (TYPE_UNSIGNED (type) || (flag_wrapv !flag_trapv)); as negating ~7ff will result in signed overflow which is undefined without flag_wrapv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23666
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #8 from jeff at thecreems dot com 2006-10-22 15:50 --- (In reply to comment #7) No, but there is an obvious one why the Fortran version trounces the Ada version. Let's not compare apples with oranges. The adverse effect of the indirection can be alleviated though: N : Positive := Positive'Value (Argument (1)); G : Ada.Numerics.Float_Random.Generator; type Real_Matrix is array (1..N, 1..N) of Float; type Matrix_Access is access Real_Matrix; A,B,C : Matrix_Access; Start, Finish : Ada.Calendar.Time; Sum : Float := 0.0; begin A := new Real_Matrix; B := new Real_Matrix; C := new Real_Matrix; That is a good approach and it significantly narrows the gap though I would argue that a general user would not see the original version as different than the FORTRAN version. Both of them are dynamically allocating the size at run time based on an input parameter. The FORTRAN arrays could indeed be passed to other procedures (such as matmul) that take variable sized arrays while this modified version (in its current form) could not. So, from an understanding of the internals of the compiler, I think you have a reasonable argument that the original Ada and FORTRAN were somewhat different but I think this modified version is actually further from the FORTRAN. (Though I must admit I know very little about FORTRAN 95). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug middle-end/29548] New: Does not fold b * -2 + a * 6
fold_plusminus_mult_expr does not fold
int f6 (int a, int b)
{
return b * -2 + a * 6;
}
this blocks the fix for PR23295 because a fix for it makes the test for
PR23294 fail.
--
Summary: Does not fold b * -2 + a * 6
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 23295
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29548
[Bug middle-end/29548] Does not fold b * -2 + a * 6
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-22 15:56 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-22 15:56:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29548
[Bug fortran/29549] New: matmul slow for complex matrices
Comparison by Francois-Xavier: http://www.eleves.ens.fr/home/coudert/timing.png (bottom row: complex numbers; black gfortran matmul, others: optimized libraries). See also http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00343.html -- Summary: matmul slow for complex matrices Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #14 from nathan at gcc dot gnu dot org 2006-10-22 16:07 --- Subject: Bug 20647 Author: nathan Date: Sun Oct 22 16:07:41 2006 New Revision: 117957 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117957 Log: cp/ PR c++/20647 * rtti.c (tinfo_base_init): The type info string is always global. testsuite/ PR c++/20647 * g++.dg/abi/rtti3.C: New. Added: trunk/gcc/testsuite/g++.dg/abi/rtti3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #15 from nathan at gcc dot gnu dot org 2006-10-22 16:09 --- 2006-10-22 Nathan Sidwell [EMAIL PROTECTED] PR c++/20647 * rtti.c (tinfo_base_init): The type info string is always global. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #9 from laurent at guerby dot net 2006-10-22 16:13 --- Eric, build is i686-pc-linux-gnu I don't understand why you speak of generalization :). Anyway, I changed the code to match more likely use, that is by using a subprogram: procedure Compute (A, B : in Real_Matrix; C : out Real_Matrix) is Sum : Float := 0.0; begin for I in A'range(1) loop for J in A'range(2) loop Sum := 0.0; for R in A'range(2) loop Sum := Sum + A(I,R)*B(R,J); end loop; C(I,J) := Sum; end loop; end loop; end Compute; ... Start := Ada.Calendar.Clock; Compute (A.all, B.all, C.all); Finish := Ada.Calendar.Clock; On my x86_64 box at -O2 (-gnatp) Ada is still three times slower cd ada ; ./tst_array 600 1.65129E+02 1.47839E+02 1.57425E+02 1.40635E+02 Time: 1.541291000 cd fortran ; ./tst_array 600 146.0253 145.0025 149.3322 150.8924 Time: 0.5400340 I don't know how to write the equivalent fortran code, but it's likely better to concentrate on the subprogram version for optimization purpose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug middle-end/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-22
16:18 ---
Subject: Re: FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #8 from sje at cup dot hp dot com 2006-10-19 18:09 ---
Well, I found that the TImode is getting introduced in layout_type. For an
ARRAY_TYPE tree there is this line:
TYPE_SIZE (type) = size_binop (MULT_EXPR, element_size,
fold_convert (bitsizetype,
length));
If you look at bitsizetype, you will find that it is TImode and thus the
resulting expression is TImode. bitsizetype is set in set_sizetype based on 2
* BITS_PER_UNIT_LOG which is 64 for hppa64. Thus our problem.
It appears bitsizetype gets set to a precision that requires TImode here:
void
set_sizetype (tree type)
{
int oprecision = TYPE_PRECISION (type);
/* The *bitsizetype types use a precision that avoids overflows when
calculating signed sizes / offsets in bits. However, when
cross-compiling from a 32 bit to a 64 bit host, we are limited to 64 bit
precision. */
int precision = MIN (oprecision + BITS_PER_UNIT_LOG + 1,
2 * HOST_BITS_PER_WIDE_INT);
In the above, I don't think a precision larger than MAX_FIXED_MODE_SIZE
should be used. This is currently 64 on hppa64. However, oprecision
is 64 and BITS_PER_UNIT_LOG is 3, so the first argument of MIN is 68.
The second argument is 128. Thus, precision ends up as 68 and the
following re layout uses TImode.
I'm trying the patch below. I think other limits come into play
long before a calculation overflow would bit.
The other alternative is to add TImode support. This is much more
complicated and probably not suitable for stage3.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Index: stor-layout.c
===
--- stor-layout.c (revision 117956)
+++ stor-layout.c (working copy)
@@ -1934,7 +1934,8 @@
calculating signed sizes / offsets in bits. However, when
cross-compiling from a 32 bit to a 64 bit host, we are limited to 64 bit
precision. */
- int precision = MIN (oprecision + BITS_PER_UNIT_LOG + 1,
+ int precision = MIN (MIN (oprecision + BITS_PER_UNIT_LOG + 1,
+ MAX_FIXED_MODE_SIZE),
2 * HOST_BITS_PER_WIDE_INT);
tree t;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug fortran/29550] New: Optimize -fexternal-blas calls for transpose()/conj()
Often, matrix multiplications contain transpose() or conj(), e.g. matmul(transpose(A),B) or matmul(A,conj(transpose(B)) matmul(A,transpose(conj(B)) The *gemm subroutines of BLAS anticipate this via the TRANSA and TRANSB options: - 'N' (unchanged) - 'T' (transpose) - 'C' (hermitian conjugate / transpose+complex conjugate) Thus for -fexternal-blas these extra options should be used, if possible. -- Summary: Optimize -fexternal-blas calls for transpose()/conj() Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
[Bug target/28232] Wrong aligned load is generated with -m4a on sh-*
--- Comment #4 from kkojima at gcc dot gnu dot org 2006-10-23 00:14 --- Subject: Bug 28232 Author: kkojima Date: Mon Oct 23 00:14:39 2006 New Revision: 117961 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117961 Log: PR target/28232 * config/sh/sh.c (expand_block_move): Use a BLKmode rather than SImode memory reference for the source of a movua. * config/sh/sh.md (UNSPEC_MOVUA): New macro. (movua): Use an unspec instead of sign_extract. Expect the source to have mode BLKmode. (extv, insv): Use a BLKmode rather than SImode memory reference for the source of a movua. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28232
[Bug tree-optimization/29551] New: FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1
This test has regressed. Executing on host: /home/dave/gnu/gcc-4.3/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .3/objdir/gcc/ /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr26421. c -O2 -fdump-tree-alias1-vops -fno-show-column -S -o pr26421.s(timeout = 300) PASS: gcc.dg/tree-ssa/pr26421.c (test for excess errors) FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1 -- Summary: FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29551
[Bug rtl-optimization/20586] bootstrap comparision fails with -funroll-loops.
--- Comment #10 from pluto at agmk dot net 2006-10-22 17:17 --- i will no longer test the 4.1 branch. for me it's closed with /dontcare. -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20586
[Bug tree-optimization/29551] FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-22 17:12 ---
I think it's ok again, but it shows one weakness of the current NONLOCAL
scheme:
foo ()
{
struct Foo a;
int D.1534;
bb 2:
# SFT.0_2 = V_MUST_DEF SFT.0_1;
a.i = 1;
# SFT.0_6 = V_MAY_DEF SFT.0_2;
# NONLOCAL.6_7 = V_MAY_DEF NONLOCAL.6_5;
bar (a);
# VUSE SFT.0_6;
D.1534_3 = a.i;
return D.1534_3;
}
we should see that a points to a and so no NONLOCAL var is necessary
here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29551
[Bug tree-optimization/29551] FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-22 17:16 ---
Adding
p = a
and using that produces
foo ()
{
struct Foo * p;
struct Foo a;
int D.1535;
bb 2:
# SFT.2_2 = V_MUST_DEF SFT.2_1;
a.i = 1;
p_3 = a;
# SFT.0_9 = V_MAY_DEF SFT.0_6;
# SFT.1_10 = V_MAY_DEF SFT.1_7;
# SFT.2_11 = V_MAY_DEF SFT.2_2;
# NONLOCAL.8_12 = V_MAY_DEF NONLOCAL.8_8;
bar (p_3);
# VUSE SFT.2_11;
D.1535_4 = a.i;
return D.1535_4;
}
!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29551
[Bug libstdc++/29552] std::power() is not in the std namespace when including ext/numeric
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-22 17:35 --- Right because this power is an extension to the C++ standard. This is not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29552
[Bug tree-optimization/29551] FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-22 17:30 --- http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00625.html That just needs to merged back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29551
[Bug libstdc++/29552] New: std::power() is not in the std namespace when including ext/numeric
Sees:
In ext/numeric power() is not declared in the std namespace, and the program
doesn't compile.
Expects:
power to be included in the ext/numeric namespace.
Source:
using namespace std;
#include iostream
#include ext/numeric
int main() {
cout power (2,30) endl;
}
Command line Flag and Compiler error:
[EMAIL PROTECTED] testpower]$ make
make all-am
make[1]: Entering directory `/home/brandon/testpower'
if g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT testpower.o -MD -MP -MF
.deps/testpower.Tpo -c -o testpower.o testpower.cpp; \
then mv -f .deps/testpower.Tpo .deps/testpower.Po; else rm -f
.deps/testpower.Tpo; exit 1; fi
testpower.cpp: In function int main():
testpower.cpp:6: error: power was not declared in this scope
make[1]: *** [testpower.o] Error 1
make[1]: Leaving directory `/home/brandon/testpower'
make: *** [all] Error 2
[EMAIL PROTECTED] testpower]$
The numeric power function that isn't included is described in this document.
http://www.sgi.com/tech/stl/power.html
Workaround, is to add a using __gnu_cxx::power;
using namespace std;
#include iostream
#include ext/numeric
using __gnu_cxx::power;
int main() {
cout power (2,30) endl;
}
Version Info:
g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
2.6.18-1.2200.fc5 #1 Sat Oct 14 16:59:26 EDT 2006 i686 athlon i386 GNU/Linux
-- Also happens in 3.2 compilers.
Works in included header:
#include backward/algo.h
-- Note: if this is a unfixed bug, can I write a patch? It is one of my life
long dreams to commit something to gcc.
--
Summary: std::power() is not in the std namespace when including
ext/numeric
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brandon at rioja dot us
GCC build triplet: i686-redhat-linux-gnu
GCC host triplet: i686-redhat-linux-gnu
GCC target triplet: i686-redhat-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29552
[Bug target/26674] missed optimization / 128-bit arithmetic.
--- Comment #3 from pluto at agmk dot net 2006-10-22 17:44 --- recent 4.2 produces worse %rcx setup code. previously: xorl%edx, %edx movq%rdx, %rcx now: movq%rdi, %rax sarq$63, %rax movq%rax, %rcx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26674
[Bug tree-optimization/29551] FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-10-22 17:37 ---
Subject: Re: FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1
On 22 Oct 2006 17:16:00 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-22 17:16
---
Adding
p = a
and using that produces
foo ()
{
struct Foo * p;
struct Foo a;
int D.1535;
bb 2:
# SFT.2_2 = V_MUST_DEF SFT.2_1;
a.i = 1;
p_3 = a;
# SFT.0_9 = V_MAY_DEF SFT.0_6;
# SFT.1_10 = V_MAY_DEF SFT.1_7;
# SFT.2_11 = V_MAY_DEF SFT.2_2;
# NONLOCAL.8_12 = V_MAY_DEF NONLOCAL.8_8;
bar (p_3);
# VUSE SFT.2_11;
D.1535_4 = a.i;
return D.1535_4;
}
!?
Escaping computation is a bit funky, but this is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29551
[Bug tree-optimization/29551] FAIL: gcc.dg/tree-ssa/pr26421.c scan-tree-dump-times V_MAY_DEF 1
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-10-22 17:39 ---
(In reply to comment #1)
I think it's ok again, but it shows one weakness of the current NONLOCAL
scheme:
foo ()
{
struct Foo a;
int D.1534;
bb 2:
# SFT.0_2 = V_MUST_DEF SFT.0_1;
a.i = 1;
# SFT.0_6 = V_MAY_DEF SFT.0_2;
# NONLOCAL.6_7 = V_MAY_DEF NONLOCAL.6_5;
bar (a);
# VUSE SFT.0_6;
D.1534_3 = a.i;
return D.1534_3;
}
we should see that a points to a and so no NONLOCAL var is necessary
here.
The nonlocal variable is not necessary because it is unused elsewhere, *not*
because you only pass something pointing to a. If we had globals here, they
could still be modified by the call to bar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29551
[Bug libstdc++/29552] std::power() is not in the std namespace when including ext/numeric
--- Comment #2 from brandon at rioja dot us 2006-10-22 18:09 --- Ahh, I see. This document says that the __gnu_cxx namespace is for the C++ extentions for public use: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/doxygroups_8cc-source.html This namespace serves two purposes. This namespace is used for two things: *sequestering internal (implementation-only) names away from the global namespace; these are details of the implementation and should not be touched by users *GNU extensions for public use Verified to be implemented as designed. -- brandon at rioja dot us changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29552
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-10-22 18:33 --- I don't know how to write the equivalent fortran code, but it's likely better to concentrate on the subprogram version for optimization purpose. Sorry, I don't see your point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #31 from rguenth at gcc dot gnu dot org 2006-10-22 20:11 --- Subject: Bug 15911 Author: rguenth Date: Sun Oct 22 20:11:09 2006 New Revision: 117960 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117960 Log: 2006-10-22 Jeff Law [EMAIL PROTECTED] Richard Guenther [EMAIL PROTECTED] PR tree-optimization/15911 * tree-vrp.c (extract_code_and_val_from_cond): New function. (register_edge_assert_for_1): Likewise. (register_edge_assert_for): Handle //||/| in conditionals. (find_conditional_asserts): Adjust for new function signature. (find_assert_locations): Likewise. * gcc.dg/tree-ssa/vrp30.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp30.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-10-22 21:27 --- My point is that the subprogram I wrote is probably the way most Ada programmers will write when they want to multiply matrices (if not using BLAS/Lapack). OK, but you have not simplified the problem in doing so. :-) -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug target/28232] Wrong aligned load is generated with -m4a on sh-*
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-10-23 00:28 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28232
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #32 from rguenth at gcc dot gnu dot org 2006-10-22 20:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug target/21508] non-optimal code with __builtin_signbit
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-22 21:01 --- On the mainline we get: subl$12, %esp fld1 faddl 16(%esp) fstpl (%esp) movl4(%esp), %eax addl$12, %esp andl$-2147483648, %eax ret Which is optimial as there is no extra movl and there is fld1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21508
[Bug inline-asm/29554] GNU as crashes on bad register syntax
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-22 21:02 --- (In reply to comment #0) (BTW, none of the product categories seem right, but I was directed here by the manual of gnu as.) The correct place is http://sourceware.org/bugzilla/ under binutils. This bugzilla is not for binutils so closing as invalid. Please file with them instead. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29554
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #6 from burnus at net-b dot de 2006-10-22 21:03 --- See http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01086.html for a preliminary patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug inline-asm/29554] New: GNU as crashes on bad register syntax
The following bit of (malformed) assembly causes GNU as to crash. .globl foo .type foo, @function foo: sete$%al Here is the error message: $ as test.s test.s: Assembler messages: test.s:4: Internal error, aborting at ../../gas/config/tc-i386.c line 2123 in optimize_imm Please report this bug. $ as --version GNU assembler 2.17 Debian GNU/Linux Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. (BTW, none of the product categories seem right, but I was directed here by the manual of gnu as.) -- Summary: GNU as crashes on bad register syntax Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dagit at codersbase dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29554
[Bug fortran/29550] Optimize -fexternal-blas calls for conj()
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-22 18:45 --- The current code already recognizes matrix transposition and gives BLAS gemm functions the right TRANSA and TRANSB argument in this case. Confirmed for CONJG, which we don't currently handle. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-10-22 18:45:29 date|| Summary|Optimize -fexternal-blas|Optimize -fexternal-blas |calls for transpose()/conj()|calls for conj() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
[Bug libgcj/29424] FAIL: events output
--- Comment #1 from andreast at gcc dot gnu dot org 2006-10-22 20:27 --- Fixed with this commit: http://gcc.gnu.org/ml/java-patches/2006-q4/msg00084.html Confirmed here: http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01120.html This also fixes events run test on linux-ppc 32-bit. Thanks to Tom! -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29424
[Bug tree-optimization/29553] New: wrong-code / trivial logic misscompiled.
long foo( bool flag, int __x )
{
return ( flag ? (unsigned)__x : __x ); // broken
}
long bar( bool flag, int __x )
{
if ( flag )
return (unsigned)__x;
else
return __x;
}
foo(bool, int):
0: 89 f0 mov%esi,%eax
2: c3 retq
0010 bar(bool, int):
10: 89 f0 mov%esi,%eax
12: 40 84 fftest %dil,%dil
15: 48 63 f6movslq %esi,%rsi
18: 48 0f 44 c6 cmove %rsi,%rax
1c: c3 retq
--
Summary: wrong-code / trivial logic misscompiled.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29553
[Bug target/9383] [SYSV] stack frame always made for nested functions
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-22 23:01 --- Fixed in 4.0 by the tree-ssa merge. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9383
[Bug tree-optimization/29553] wrong-code / trivial logic misscompiled.
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-22 20:47 --- In flag ? (unsigned)__x : __x , __x is promoted to unsigned and then promoted to long, so the code is different than bar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29553
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #11 from laurent at guerby dot net 2006-10-22 20:55 --- My point is that the subprogram I wrote is probably the way most Ada programmers will write when they want to multiply matrices (if not using BLAS/Lapack). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit
--- Comment #8 from aldot at gcc dot gnu dot org 2006-10-22 21:08 --- Created an attachment (id=12476) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12476action=view) untested proposed fix I hope to test this patch soon. Note that it adds a warning about blank common in block data but -- unlike the patch in the previous comment -- does accept the common instead of abandoning it via goto cleanup. Please advise if not cleaning this up is acceptable or if blank commons should be ignored there. fortran/ChangeLog: 2006-10-22 Bernhard Fischer [EMAIL PROTECTED] PR fortran/29537 * trans-common.c (gfc_trans_common): For unnamed block data the proc_name is null, so use the locus of the common. (gfc_sym_mangled_common_id): Fix whitespace. * match.c (gfc_match_common): Emit warning about blank common in block data. testsuite/ChangeLog: 2006-10-22 Bernhard Fischer [EMAIL PROTECTED] PR fortran/29537 * blockdata_1.f90: Add warning about blank common in block data. * blockdata_2.f90: New testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug fortran/29539] ICE in variable_decl
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-10-22 19:04:57 date|| Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29539
[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-22 21:01
---
Having thought about it some more, MODULO should be implemented using
fmod{f,,l} and MOD should use remainder{f,,l}. See how BUILT_IN_POWL is used,
for example, to emit the same kind of code in gfc_conv_intrinsic_mod.
Beginner project for someone? :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-06-20 12:22:57 |2006-10-22 21:01:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug target/29555] New: failure building cross compiler for fr30
I want to build a cross compiler for fr30 architecture (including c++) and
configure in a separate build dir as follows:
../gcc-4.1.1/configure --prefix=/usr/cross --target=fr30-unknown-elf
--with-gnu-as --with-gnu-ld --enable-languages=c --disable-libssp
Then is make and make install, which runs fine without any error.
Then I build newlib with my fresh fr30-unknown-elf-gcc and install it which
also runs fine.
Then I configure gcc to build a c++ compiler:
../gcc-4.1.1/configure --prefix=/usr/cross --target=fr30-unknown-elf
--with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-libssp
--with-newlib
The following make aborts with this error:
/home/larsi/gcc/gcc-build/./gcc/xgcc -shared-libgcc
-B/home/larsi/gcc/gcc-build/./gcc -nostdinc++
-L/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/src
-L/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/src/.libs
-B/usr/cross/fr30-unknown-elf/bin/ -B/usr/cross/fr30-unknown-elf/lib/ -isystem
/usr/cross/fr30-unknown-elf/include -isystem
/usr/cross/fr30-unknown-elf/sys-include
-I/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/include/fr30-unknown-elf
-I/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/include
-I/home/larsi/gcc/gcc-4.1.1/libstdc++-v3/libsupc++ -g -Os
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -c
../../../../gcc-4.1.1/libstdc++-v3/src/fstream-inst.cc -o
fstream-inst.o
/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/include/bits/fstream.tcc:
In member function 'typename std::basic_filebuf_CharT, _Traits::pos_type
std::basic_filebuf_CharT, _Traits::_M_seek(typename _Traits::off_type,
std::_Ios_Seekdir, typename _Traits::state_type) [with _CharT = char, _Traits
= std::char_traitschar]':
/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/include/bits/fstream.tcc:753:
error: insn does not satisfy its constraints:
(insn 191 190 23
0
/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/include/bits/postypes.h:117
(set (mem/s/c:SI (plus:SI (reg/f:SI 14 fp [42])
(const_int 4 [0x4])) [27 result._M_state+4 S4 A32])
(reg:SI 2 r2 [orig:1+4 ] [1])) 6 {movsi_internal} (nil)
(expr_list:REG_DEAD (reg:SI 2 r2 [orig:1+4 ] [1])
(nil)))
/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/include/bits/fstream.tcc:753:
internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1592
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[4]: *** [fstream-inst.lo] Fehler 1
make[4]: Leaving directory
`/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3/src'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory
`/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory
`/home/larsi/gcc/gcc-build/fr30-unknown-elf/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Fehler 2
make[1]: Leaving directory `/home/larsi/gcc/gcc-build'
make: *** [all] Fehler 2
--
Summary: failure building cross compiler for fr30
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: larsi at wh2 dot tu-dresden dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: fr30-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29555
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #13 from laurent at guerby dot net 2006-10-22 21:55 --- Indeed :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug c++/29556] New: Expect error when 'using namespace std' is declared when std namespace is not defined
using namespace std does not issue an error or warning when the namespace std
is not declared. Using other namespaces that are not declared issue a warning.
Expects:
using namespace std; to issue the error
error: std is not a namespace-name.
when namespace std is not defined.
System:
2.6.18-1.2200.fc5 #1 Sat Oct 14 16:59:26 EDT 2006 i686 athlon i386 GNU/Linux
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
Test Case that passes but should fail:
using namespace std;
int main () {
return 0;
}
Test case that passes and should pass:
#include iostream
using namespace std;
int main () {
return 0;
}
This code fails to compile as expected.
using namespace __gnu_cxx;
#include ext/numeric
int main () {
return 0;
}
An issues the error
__gnu_cxx is not a namespace-name
This code compiles as expected;
#include ext/numeric
using namespace __gnu_cxx;
int main () {
return 0;
}
Also seen in
- gcc32 (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5)
Command line to compile:
[EMAIL PROTECTED] testnamespace]$ make
make all-am
make[1]: Entering directory `/home/brandon/bugs/testnamespace'
if g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT testnamespace.o -MD -MP -MF
.deps/testnamespace.Tpo -c -o testnamespace.o testnamespace.cpp; \
then mv -f .deps/testnamespace.Tpo .deps/testnamespace.Po; else rm -f
.deps/testnamespace.Tpo; exit 1; fi
g++ -g -O2 -o testnamespace testnamespace.o
make[1]: Leaving directory `/home/brandon/bugs/testnamespace'
[EMAIL PROTECTED] testnamespace]$
--
Summary: Expect error when 'using namespace std' is declared when
std namespace is not defined
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brandon at rioja dot us
GCC build triplet: i686-redhat-linux-gnu
GCC host triplet: i686-redhat-linux-gnu
GCC target triplet: i686-redhat-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29556
[Bug rtl-optimization/16456] PowerPC - redundant subtract involving pointer types
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-22 23:13 --- (In reply to comment #2) This is another example of premature tree optimization, and it should be addressed in the reworking of fold itself. I don't think this should be attempted at stage 3 First off, fold is not doing this but instead convert.c :). Second I don't think this is premature tree optim but instead just something RTL level should catch. People can write code like what the tree level gives us so it is not a question of premature tree opt but rather how to catch it on the RTL level. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-03-11 06:24:57 |2006-10-22 23:13:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16456
[Bug fortran/29550] Optimize -fexternal-blas calls for conjg()
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-22 23:14 --- I've been thinking a bit about this. It's a common case, and it would probably be worth optimizing it. We could detect in iresolve.c (gfc_resolve_matmul) that one (or both) of the arguments to MATMUL is a call to CONJ, and then rewrite the code to be MATMUL(A,B,2) instead of MATMUL(A,CONJG(B)), where the 2 is an extra hidden integer argument that means here that the second MATMUL arg is to be conjugated during the matrix multiplication. After that, we could also detect in iresolve.c (gfc_resolve_conjg) when the result of a matmul call is conjugated (C = CONJG(MATMUL(A,B))) and optimize this as well. Notes for a wannabe coder: that argument a (or b) is the conjg function can be identified by (a-expr_type == EXPR_FUNCTION a-value.function-isym-generic_id == GFC_ISYM_CONJG). Rewriting the expressions might be a bit subtle, but not so hard; for the extra argument, see how the rrspacing and spacing intrinsics are implemented. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2006-10-22 18:45:29 |2006-10-22 23:14:54 date|| Summary|Optimize -fexternal-blas|Optimize -fexternal-blas |calls for conj()|calls for conjg() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
[Bug rtl-optimization/29083] useless clrlwi instruction produced for 16-bit bitfield
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-22 23:55 ---
Confirmed, what happens is that combine combines:
(insn 18 16 19 3 (set (reg/v/f:SI 123 [ node ])
(plus:SI (reg/v/f:SI 123 [ node ])
(const_int -4 [0xfffc]))) 79 {*addsi3_internal1} (nil)
(nil))
(insn 19 18 20 3 (set (reg:HI 125 [ variable.x ])
(mem/s/j:HI (reg/v/f:SI 123 [ node ]) [2 variable.x+0 S2 A32])) 313
{*movhi_internal} (insn_list:REG_DEP_TRUE 18 (nil))
(nil))
Into:
(note 18 16 19 3 NOTE_INSN_DELETED)
(insn 19 18 20 3 (parallel [
(set (reg:HI 125 [ variable.x ])
(mem/s/j:HI (plus:SI (reg/v/f:SI 123 [ node ])
(const_int -4 [0xfffc])) [2 variable.x+0
S2 A32]))
(set (reg/v/f:SI 123 [ node ])
(plus:SI (reg/v/f:SI 123 [ node ])
(const_int -4 [0xfffc])))
]) 361 {*movhi_update1} (nil)
(nil))
But it forgets about:
(insn 20 19 21 3 (set (reg:SI 124 [ variable.x ])
(zero_extend:SI (reg:HI 125 [ variable.x ]))) 42 {*rs6000.md:772}
(insn_list:REG_DEP_TRUE 19 (nil))
(expr_list:REG_DEAD (reg:HI 125 [ variable.x ])
(nil)))
Which is where the extra clrlwi comes from.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-22 23:55:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29083
[Bug c++/29556] Expect error when 'using namespace std' is declared when std namespace is not defined
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 00:48 --- Confirmed. Related to: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00945.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-redhat-linux-gnu | GCC host triplet|i686-redhat-linux-gnu | GCC target triplet|i686-redhat-linux-gnu | Keywords||accepts-invalid Known to fail||2.95 3.2.3 3.4.0 4.0.0 4.2.0 ||4.0.4 4.1.2 3.0.4 4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-10-23 00:48:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29556
[Bug c++/24604] namespace std aliasing
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-23 00:56 --- Related to PR 29556. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29556 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24604
[Bug middle-end/23869] Missed optimization with integer booleans when compiling for pentium and higher
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-22 20:20 --- In both cases we now get a call to g(1) due to the fix for 15911. So, fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23869
[Bug rtl-optimization/29083] useless clrlwi instruction produced for 16-bit bitfield
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 02:16 --- Yes this is fixed on the dataflow branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29083
[Bug rtl-optimization/29083] useless clrlwi instruction produced for 16-bit bitfield
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 02:28 --- This is also fixed at -O2 -fsee so SEE also fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29083
[Bug c++/28088] [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
--- Comment #11 from bangerth at math dot tamu dot edu 2006-10-23 03:18 --- Subject: Re: [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp Technically, I think it would be feasible to backport the patch. However, because that patch eliminates a GNU extension we would change the set of programs accepted on the 4.1 branch. I'm not sure that's a good idea, even to fix a failure to accept conforming code. I can see arguments both ways, so I'd like to see if there's a consensus in the community and among Nathan and Jason. There were PRs that showed that this extension (for those who don't remember: we allowed to match templates with trailing default arguments to match template template parameters with fewer template arguments) leads to wrong code in some circumstances. It's also one of the more obscure and less well thought out extensions, in my opinion. So my view of things is that the patch should be backported. But then I'm not in charge of this, of course :-) W. - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
[Bug c++/28088] [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
--- Comment #12 from fang at csl dot cornell dot edu 2006-10-23 03:34 --- Subject: Re: [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp There were PRs that showed that this extension (for those who don't remember: we allowed to match templates with trailing default arguments to match template template parameters with fewer template arguments) leads to wrong code in some circumstances. It's also one of the more obscure and less well thought out extensions, in my opinion. So my view of things is that the patch should be backported. But then I'm not in charge of this, of course :-) My $.02, as a user: * This said extension was never given a period of deprecation before it was axed. * This extension is used in much existing code in practice, especially when using the STL container templates as template template arguments. (Since the Alloc param is always defaulted to std::allocator...) While I'm favor of removing extensions for the sake of standard conformance (and fixing wrong code), I think that a sudden change on the 4.1 release branch might cause some agony to those who aren't prepared to migrate to the 4.2-like behavior, in disabling the extension. The warning might even state the consequence of this extension: unexpected behavior or wrong code. Caveat emptor. I suggest adding such a diagnostic on existing release branches, to give fair warning when people are (often unknowingly) using the extension. Fortunately, it is easy to write an autoconf-macro to detect this feature, using the test case in http://gcc.gnu.org/gcc-4.2/changes.html. (and I have done so, if anyone would like it) End $.02. Fang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
[Bug c++/28088] [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
--- Comment #13 from bangerth at math dot tamu dot edu 2006-10-23 04:01 --- Subject: Re: [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp So maybe the question should be a different one: if it is difficult and/or potentially risky to backport the patch mentioned, may there be another way to fix this ice-on-valid bug on a release branch? - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
[Bug debug/29443] [4.1 regression] ICE: output_operand: invalid expression as operand with -gstabs
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 04:02 --- This is TLS that is being ICEd on so I doubt this is a regression, except for libstdc++ using TLS now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
[Bug target/29443] [4.1 regression] ICE: output_operand: invalid expression as operand with -gstabs
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 04:15 --- Sorry, not TLS but instead some PIC code. This is a target specific issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|debug |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
possible with gcc 4.1.1 found
Background: This problem was found by running gnu mp's make check script after an successfull make. GNU MP home page: http://www.swox.com/gmp/ Problem discovered while make checking ... of programs from gmp-4.2.1.tar.bz2 $ /usr/local/bin/gcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../configure --disable-nls --enable-languages=c,c++,objc,java Thread model: single Platform: CYGWIN_NT-5.1 1.5.21(0.156/4/2) 2006-07-30 14:21 Configure line: $ ./configure --disable-static --enable-shared CC=/usr/local/bin/gcc -Wall CPPFLAGS=-DDLL_EXPORT Command line that triggers the bug: (in directory `/usr/src/gmp/gmp-4.2.1/tests/mpn' paste code that triggered error: /usr/local/bin/gcc -Wall -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../tests -DDLL_EXPORT -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 -c t-mp_bases.c t-mp_bases.c: In function 'main': t-mp_bases.c:107: error: unrecognizable insn: (insn 105 103 106 10 (set (reg:SI 88) (const:SI (plus:SI (mem:SI (symbol_ref:SI (#i.__gmpn_bases) var_decl 0x194a4990 __gmpn_bases) [0 S4 A8]) (const_int 48 [0x30] -1 (nil) (nil)) t-mp_bases.c:107: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [t-mp_bases.o] Error 1 end of paste. Attched is the t-mp_bases.i file. [1. *.i* file --- text/x-c; t-mp_bases.i]... Please let me know if you have any ideas on how to fix this. Thank you. Darel Henman
