[Bug libfortran/32611] Print sign of negative zero
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-08 07:01 --- F77 Standard: 13.5.9 (3) On output, the representation of a positive or zero internal value in the field may be prefixed with a plus, as controlled by the S, SP, and SS edit descriptors (13.5.6) or the processor. The representation of a negative internal value in the field must be prefixed with a minus. However, the processor must not produce a negative signed zero in a formatted output record. I do not find that last statement about negative signed zero in the F95 or F2003. However, I am still reviewing these more recent standards. A patch is developing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32611
[Bug fortran/32669] [4.3 Regression] Actual argument contains too few elements for dummy argument is triggered for valid code
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-08 08:04 --- Accept. I missed to properly get the lower bound. Thanks for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-08 08:04:09 date|| Summary|Actual argument contains |[4.3 Regression] Actual |too few elements for dummy |argument contains too few |argument is triggered for |elements for dummy argument |valid code |is triggered for valid code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32669
[Bug fortran/32669] [4.3 Regression] Actual argument contains too few elements for dummy argument is triggered for valid code
--- Comment #2 from patchapp at dberlin dot org 2007-07-08 08:30 --- Subject: Bug number PR32669 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00669.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32669
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #13 from irar at il dot ibm dot com 2007-07-08 10:00 --- Hi Sebastian, I was going to submit the attached patch, but now the analysis fails with affine-affine test failed: missing iteration counts and distance vector is not built (so the loop in this PR cannot be vectorized even with the addition of DDR_REVERSED_P). This was caused by your patch to PR 32457 http://gcc.gnu.org/viewcvs?view=revrevision=126305. Is there any way to restore the previous behaviour for this case? Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #14 from irar at il dot ibm dot com 2007-07-08 10:01 --- Created an attachment (id=13869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13869action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
Re: [Bug tree-optimization/32032] [4.3 Regression] Inliner not setting has_volatile_ops
--- Comment #4 from jakub at gcc dot gnu dot org 2007-07-04 12:31 --- This doesn't ICE any longer on the trunk. But that does not mean the bug is still there. PRE/VN was changed (which exposed the ICE) but the inliner was not. Really we should verify this in the verify_tree_cfg so we catch this early on and not depend on PRE ICEing. -- Pinski
[Bug tree-optimization/32032] [4.3 Regression] Inliner not setting has_volatile_ops
--- Comment #5 from pinskia at gmail dot com 2007-07-08 10:11 --- Subject: Re: [4.3 Regression] Inliner not setting has_volatile_ops --- Comment #4 from jakub at gcc dot gnu dot org 2007-07-04 12:31 --- This doesn't ICE any longer on the trunk. But that does not mean the bug is still there. PRE/VN was changed (which exposed the ICE) but the inliner was not. Really we should verify this in the verify_tree_cfg so we catch this early on and not depend on PRE ICEing. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
[Bug c/32643] [4.3 Regression] Wrong error message with unsigned char a = uchar512
--- Comment #3 from manu at gcc dot gnu dot org 2007-07-08 10:12 --- (In reply to comment #0) testcase, compile with -pedantic-errors (we don't reject it overwise in 4.3): unsigned char p; unsigned char p1 = p 512; Now there is an overflow but only because we optimize the IR (unsigned char)(((int)p) 512) into: p (unsigned char)512 and (unsigned char)512 is converted into 0 (with overflow) so we have p 0 which is then optimized into 0(with overflow). So we are only rejecting this because of the overflow due to the conversion (which was due to fold). There should not be any overflow? So the result is wrong independently whether this is an initialization or not? The operation should be done with int, isn't it? BTW, you should get two warnings when using -pedantic. We don't reject as invalid code either: unsigned char p; unsigned char p1 = p 0; Why should we? There is no overflow here, you mean that p is not constant? I think we have two issues in the first testcase, one is folding (X op 0), the other is converting 512 to uchar before performing the operation. Am I wrong? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
[Bug c/32643] [4.3 Regression] Wrong error message with unsigned char a = uchar512
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-08 10:19 --- (In reply to comment #3) We don't reject as invalid code either: unsigned char p; unsigned char p1 = p 0; Why should we? There is no overflow here, you mean that p is not constant? I think we have two issues in the first testcase, one is folding (X op 0), the other is converting 512 to uchar before performing the operation. Am I wrong? Yes, the converting 512 to uchar is a valid optimization. That is: (char)(((int) a) b) is the same as: a ((char)b) if a is of type char. as there are no overflow concerns with AND. The folding gets us to the case where we have a 0 which is not a valid constant initializer at all. Note I found this while working on fixing PR 32628, where the patch which fixes that caues us to no longer emit a warning/error for the first testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32628 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
[Bug rtl-optimization/32605] Missing byte swap optimizations
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-08 10:27 --- This is unrealated to PR 29749, here we have load/stores there we have a rotate. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|29749 | Severity|normal |enhancement Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32605
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #28 from ubizjak at gmail dot com 2007-07-08 10:29 --- This patch breaks gcc.dg/torture/pr20314-1.c and gcc.dg/torture/pr20314-2.c tests for i386 [1] and x86_64 [2] targets on 4.1 branch: /home/uros/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr20314- 1.c: In function 'f3': /home/uros/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr20314- 1.c:29: internal compiler error: in update_equiv_regs, at local-alloc.c:1117 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [1]: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00314.html [2]: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00315.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #29 from ubizjak at gmail dot com 2007-07-08 10:32 --- (In reply to comment #28) This patch breaks gcc.dg/torture/pr20314-1.c and gcc.dg/torture/pr20314-2.c tests for i386 [1] and x86_64 [2] targets on 4.1 branch: Also on 4.2 branch [1]. [1]: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00316.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug c++/32596] ICE with template in anonymous namespace
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Keywords||ice-on-valid-code Summary|ice for legal code |ICE with template in ||anonymous namespace http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32596
[Bug c++/32596] [4.3 Regression] ICE with template in anonymous namespace
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|x86_64-suse-linux | Summary|ICE with template in|[4.3 Regression] ICE with |anonymous namespace |template in anonymous ||namespace Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32596
[Bug c++/32596] [4.3 Regression] ICE with inline template specialization in anonymous namespace
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-08 10:46 ---
Reduced testcase:
namespace
{
templateclass T inline void char_less(void) { }
template inline void char_lesschar(void) { }
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-07-08 10:46:52
date||
Summary|[4.3 Regression] ICE with |[4.3 Regression] ICE with
|template in anonymous |inline template
|namespace |specialization in anonymous
||namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32596
[Bug c/32574] [4.3 Regression] running out of memory during compiling
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code, memory- ||hog Summary|running out of memory during|[4.3 Regression] running out |compiling |of memory during compiling Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32574
[Bug tree-optimization/32573] [4.3 Regression] ice for legal code with -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |tree-optimization Keywords||ice-on-valid-code Summary|ice for legal code with -O3 |[4.3 Regression] ice for ||legal code with -O3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug fortran/32673] New: Wrongly allowed: Statement function with subobject of constant
Even with -std=f95 -pedantic no error is given for the following program. NAG f95 gives: Error: st_function.f90, line 4: Subobject of constant not allowed in statement function Example (from gfortran.fortran-torture/execute/st_function.f90): subroutine with_character_dummy character (len=4) s1, s2, st4 character (len=10) st5, s0 st4 (i, j) = 0123456789(i:j) if (st4 (1, 4) .ne. 0123 ) call abort end subroutine I could not find this restriction, when I quickly browsed the standards (F95,F2003), however, I found the following (F2003, I'm not sure whether it applies here): C421 (R424) The length specified for a character statement function or for a statement function dummy argument of type character shall be an initialization expression. -- Summary: Wrongly allowed: Statement function with subobject of constant Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32673
[Bug target/32479] [4.3 Regression] [sh] ICE in cse_extended_basic_block, at cse.c:6117
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[sh] ICE in |[4.3 Regression] [sh] ICE in |cse_extended_basic_block, at|cse_extended_basic_block, at |cse.c:6117 |cse.c:6117 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32479
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-08 11:29 --- Related to PR 32596. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||32596 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug c++/32674] New: [4.1/4.2/4.3 regression] ICE in lvalue_p_1 initialising static variable inside template class
The following code snippet (similiar to PR31992) triggers an ICE since 4.1.x
onwards:
--- snip ---
class C
{
static const int j = 3;
};
templateint class A
{
static const int i;
};
templateint N const int AN::i(C::j);
--- snip ---
Error message:
bug.cc:11: internal compiler error: in lvalue_p_1, at cp/tree.c:148
--
Summary: [4.1/4.2/4.3 regression] ICE in lvalue_p_1 initialising
static variable inside template class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lmillward at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32674
[Bug bootstrap/32675] New: verify_stmts failed during Ada bootstrap
Ada fails bootstrap on i386-unknown-netbsdelf3.1: /gcctmp/agcc070708/build/./prev-gcc/xgcc -B/gcctmp/agcc070708/build/./prev-gcc/ -B/usr/local/i386-unknown-netbsdelf3.1/bin/ -c -g -O2 -fomit-frame-pointer -gnatpg -gnata -nostdinc -I- -I. -Iada -I../../gcc/gcc/ada ../../gcc/gcc/ada/exp_dbug.adb -o ada/exp_dbug.o ../../gcc/gcc/ada/exp_dbug.adb: In function 'Exp_Dbug.Prepend_String_To_Buffer':../../gcc/gcc/ada/exp_dbug.adb:981: error: invalid array index (unnamed-signed:32) MAX_EXPR D.2761_31, 0 + 1; +===GNAT BUG DETECTED==+ | 4.3.0 20070708 (experimental) (i386-unknown-netbsdelf3.1) GCC error: | | verify_stmts failed | | Error detected around ../../gcc/gcc/ada/exp_dbug.adb:981 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| [...] This error was introduced by revision 126149: 2007-06-30 Daniel Berlin [EMAIL PROTECTED] Fix PR tree-optimization/32540 Fix PR tree-optimization/31651 * tree-ssa-sccvn.c: New file. * tree-ssa-sccvn.h: Ditto. [...] The build is configured using --enable-languages=c,ada. The source tree has the following patch applied to fix an unrelated bootstrap problem on NetBSD: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02159.html -- Summary: verify_stmts failed during Ada bootstrap Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cato at df dot lth dot se GCC build triplet: i386-unknown-netbsdelf3.1 GCC host triplet: i386-unknown-netbsdelf3.1 GCC target triplet: i386-unknown-netbsdelf3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32675
[Bug c++/32676] New: [cxx0x branch] incorrect member address when using delegate constructors and virtual inheritance
version: g++0x (GCC) 4.3.0 20070628 (experimental)
(more exactly: branch svn://gcc.gnu.org/svn/gcc/branches/cxx0x-branch, svn
revision 126129)
system type: x86_64-unknown-linux-gnu
configured with: ../gcc0x/configure --program-suffix=0x --disable-multilib
--enable-languages=c,c++
The following code prints two different adresses for m_Count, whereas it should
print the same address twice.
It works properly when not calling the delegate constructor from A's default
constructor.
It also works properly if the blah array in B is removed or reduced to a size
of one.
#include iostream
class base
{
public:
virtual ~base() {}
int m_Count;
};
class A : public virtual base
{
public:
A( int blah ) {}
A() : A( 13245 )
{
std::cout m_Count std::endl;
}
};
class B : public virtual base, public A
{
public:
B()
{
std::cout m_Count std::endl;
}
private:
int blah[100];
};
int main()
{
B* pB = new B;
return 0;
}
=
--
Summary: [cxx0x branch] incorrect member address when using
delegate constructors and virtual inheritance
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot chavasse at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32676
[Bug ada/32640] [Ada] [4.2 Regression] Binding for pthread_sigmask not same as other ports
--- Comment #3 from laurent at guerby dot net 2007-07-08 14:22 --- Tested by Joel, privately approved by Geert, commited on 4.2 (okayed by Mark) and trunk. Laurent -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32640
[Bug bootstrap/32675] verify_stmts failed during Ada bootstrap
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-07-08 14:25 --- *** This bug has been marked as a duplicate of 32589 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32675
[Bug tree-optimization/32589] [4.3 Regression] exp_dbug.adb:981: error: invalid array index
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-07-08 14:25 --- *** Bug 32675 has been marked as a duplicate of this bug. *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||cato at df dot lth dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589
[Bug c++/28266] [4.0/4.1 regression] ICE on invalid default variable
--- Comment #8 from pcarlini at suse dot de 2007-07-08 14:34 --- Not a 4.2 regression anymore. -- pcarlini at suse dot de changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE on |on invalid default variable |invalid default variable http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28266
[Bug target/31331] [avr] ICE on function attribute syntax for main()
-- eweddington at cso dot atmel dot com changed: What|Removed |Added Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #56 from manu at gcc dot gnu dot org 2007-07-08 14:50 --- Subject: Bug 25241 Author: manu Date: Sun Jul 8 14:50:37 2007 New Revision: 126461 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126461 Log: 2007-07-08 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR testsuite/25241 testsuite/ * gcc.dg/20041213-1.c: Don't use default -pedantic-errors to allow discern pedantic diagnostics and errors. * gcc.dg/empty2.c: Add -pedantic, so it actually produces a warning and not an error. * gcc.dg/20050121-1.c: This is an error and not a warning. * gcc.target/i386/sseregparm-2.c: Likewise. * gcc.target/i386/20060512-4.c: This is a warning and not an error. * gcc.dg/charset/attribute2.c: Likewise. * gcc.dg/bitfld-1.c: Likewise. * gcc.dg/pack-test-2.c: Likewise. * gcc.dg/940510-1.c: Match separately error and warning. * gcc.dg/array-2.c: Match separately multiple messages. The second diagnostic is a pedantic warning and not an error. * gcc.dg/pr14475.c: Match separately multiple messages. * gcc.dg/pr18809-1.c: Likewise. * gcc.dg/pr27953.c: Likewise. * gcc.dg/vla-init-1.c: Likewise. * gcc.dg/redecl-1.c: Fix wrong use of dg-error and dg-warning. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/20041213-1.c trunk/gcc/testsuite/gcc.dg/20050121-1.c trunk/gcc/testsuite/gcc.dg/940510-1.c trunk/gcc/testsuite/gcc.dg/array-2.c trunk/gcc/testsuite/gcc.dg/bitfld-1.c trunk/gcc/testsuite/gcc.dg/charset/attribute2.c trunk/gcc/testsuite/gcc.dg/empty2.c trunk/gcc/testsuite/gcc.dg/pack-test-2.c trunk/gcc/testsuite/gcc.dg/pr14475.c trunk/gcc/testsuite/gcc.dg/pr18809-1.c trunk/gcc/testsuite/gcc.dg/pr27953.c trunk/gcc/testsuite/gcc.dg/redecl-1.c trunk/gcc/testsuite/gcc.dg/vla-init-1.c trunk/gcc/testsuite/gcc.target/i386/20060512-4.c trunk/gcc/testsuite/gcc.target/i386/sseregparm-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/32673] Wrongly allowed: Statement function with subobject of constant
--- Comment #1 from pault at gcc dot gnu dot org 2007-07-08 14:51 --- (In reply to comment #0) Even with -std=f95 -pedantic no error is given for the following program. NAG f95 gives: Both Lahey and g95 are happy with it. C421 (R424) The length specified for a character statement function or for a statement function dummy argument of type character shall be an initialization expression. That is the case here (LEN = 4). I do not think that this is a bug. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32673
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #10 from hjl at lucon dot org 2007-07-08 15:12 --- When a statement has no vuses, but its LHS value handle has vuses, we wind up with tree val = vn_lookup_or_add_with_stmt (newt, stmt); vn_add (lhs, val); Now the LHS value handle changes from vuses to no vuses since the statement has no vuses. Are you sure you handle this case correctly? Can we reuse LHS value handle in this case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug c++/30535] [4.2/4.3 regression] ICE with invalid template operator
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30535
[Bug fortran/32157] intrinsic function name conflicts with subroutine if present in the same file
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-08 15:18 --- Paul, your patch in comment #2 also seems to fix PR31609. Any plans to get it into trunk? :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32157
[Bug fortran/31609] module that calls a contained function with an ENTRY point
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-08 15:20 --- Jerry, the patch in PR32157, comment #2 seems to fix this one as well. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
[Bug fortran/32217] segfaults (at runtime) on UNPACK with zero-sized arrays
--- Comment #3 from dominiq at lps dot ens dot fr 2007-07-08 15:42 --- This fixes the test case. Confirmed on PPC Darwin7 and it passes the regression-test on this platform. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32217
[Bug fortran/32554] [4.2 Only] Bug in P formatting
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-07-08 17:09 --- Closing, fixed for 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-08 17:26 --- Further reduced testcase: $ cat pr31639.f90 function f() integer :: i = irand() f = i end function $ gfortran-svn -g -Wall -c pr31639.f90 pr31639.f90: In function 'f': pr31639.f90:1: internal compiler error: in gfc_conv_constant, at fortran/trans-const.c:297 With this code: function f() integer :: i = irand() end function one gets: $ gfortran-svn -g -Wall -c pr31639.f90 pr31639.f90: In function 'f': pr31639.f90:1: warning: Function return value not set pr31639.f90:1: warning: control reaches end of non-void function which is noteworthy in itself ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-08 17:28 --- function f() integer :: i = irand() end function Make that: function f() integer :: f = irand() end function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-08 17:49 --- function f() integer :: i = irand() f = i end function We should give a message such as ifort: The initialization shall not appear for this object name. [F] This array or function or substring is invalid in constant expressions. [IRAND] The place to change is check_init_expr; maybe gfc_intrinsic_func_interface. Giving an error should fix both problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
[Bug c++/32677] New: optimizer fails properly accessing argument
The problem occurs when using flags -O3 (or -O2) in gcc 4.0, 4.1 and 4.2.0.
The following program exhibits the bug:
#include iostream
inline void store4(char* dst, char* src) {
*(unsigned*)dst = *(unsigned*)src;
}
voidset(char* dst, long value) {
store4(dst, (char*)value);
}
int main(int argc, char* argv[])
{
int value = 0;
char* data = (char*)value;
set(data, 1);
std::cerr value std::endl;
}
Command line for showing the bug:
c++ -o gccBug -O3 gccBug.cpp ; gccBug
0
c++ -o gccBug -O gccBug.cpp ; gccBug
1
The bug also disappears when compiling with option -m32.
From the assembly code for set(), the -O3 optimized version is:
_Z3setPcl:
.LFB1462:
movl-8(%rsp), %eax
movl%eax, (%rdi)
ret
instead the -O version is:
_Z3setPcl:
.LFB1462:
movq%rsi, -8(%rsp)
movl-8(%rsp), %eax
movl%eax, (%rdi)
ret
-- Giuseppe Attardi
University of Pisa
Italy
--
Summary: optimizer fails properly accessing argument
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: attardi at di dot unipi dot it
GCC build triplet: 4.2.0
GCC host triplet: x86_64 GNU/Linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32677
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #11 from mark at codesourcery dot com 2007-07-08 18:12 --- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion pcarlini at suse dot de wrote: --- Comment #10 from pcarlini at suse dot de 2007-07-07 22:57 --- (In reply to comment #9) Ah, thanks for finding the old PR. In looking at the mail threads, I fail to find my magic solution. :-( Do you have a pointer to it? Well, that PR is *closed as fixed*. Maybe at the time I didn't follow all the details and your eventual fix was only partial, in some sense? Certainly 21210 is closed as fixed and we didn't add any constructor, contrary to some ideas temporarily envisaged in the discussion linked in Comment #3 therein. I was confused by your crediting me with magic because it was Roger Sayle who fixed the bug. In any case, his fix was a specific hack for converting zero to a complex type, not for the more general problem, which has always remained unfixed. I still think adding a few constructors is the best fix. The only situation where we have a problem is a class with constructors taking both a type like double and a GNU __complex__ type. GNU __complex__types are very rare in C++ programs; people use std::complex in C++, and there is no problem in that situation. :-) So, libstdc++ is the rare case. Changing the library will give us very natural semantics in the front end; we just declare GNU __complex__ to be an arithmetic type, and everything else follows. Absent direction from the ISO C++ committee regarding integration of C99 complex into C++, that seems like the best we can do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/32677] optimizer fails properly accessing argument
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-08 18:23 --- You are violating C/C++ aliasing rules. You are accessing a long as an unsigned int which is not allowed by C/C++ and is undefined. It is allowed to access an int as a unsigned int and a long as an unsigned long but not long as an int or an int as a long. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32677
[Bug c/21920] aliasing violations
--- Comment #116 from pinskia at gcc dot gnu dot org 2007-07-08 18:23 --- *** Bug 32677 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||attardi at di dot unipi dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug fortran/32678] New: GFortan works incorrectly when writing with FORMAT Tx
GFortran writes unpredictable char when it is used modificaters Tx in FORMAT and the first position 'x' is less then current position and the second position 'x' is greater then the maximum previously position. write (*,10) '12','a','b' 10 format (a2,t1,a1,t2,a1,t20,' ') This bug is reproduced in GFortan 4.1.2 Fail case has invisible char with code 0 after 'ab'. You can see this char with hexdump or VIM for example. fail case ./a.out | hexdump 000 6261 2000 2020 2020 2020 2020 2020 2020 010 2020 2020 000a 015 pass case ./a1.out | hexdump 000 6261 2020 2020 2020 2020 2020 2020 2020 010 2020 2020 000a 015 Satya -- Summary: GFortan works incorrectly when writing with FORMAT Tx Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: satyaakam at yahoo dot co dot in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32678
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #12 from pcarlini at suse dot de 2007-07-08 18:42 --- (In reply to comment #11) I was confused by your crediting me with magic because it was Roger Sayle who fixed the bug. Ah! Curious, he doesn't work on the C++ front-end very often... So, libstdc++ is the rare case. Changing the library will give us very natural semantics in the front end; we just declare GNU __complex__ to be an arithmetic type, and everything else follows. Absent direction from the ISO C++ committee regarding integration of C99 complex into C++, that seems like the best we can do. What can I say... Gaby designed the complex class that way, those special constructors included. If we cannot avoid adding more constructors, so be it, but of course please make sure Gaby agrees. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2007-07-07 19:26:39 |2007-07-08 18:42:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #13 from mmitchel at gcc dot gnu dot org 2007-07-08 18:58 --- Gaby -- Paolo and I would like your input on this issue, please. Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at integrable-solutions ||dot net Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug fortran/32678] GFortan works incorrectly when writing with FORMAT Tx
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-07-08 19:12 --- I believe this has been fixed in gfortran version 4.2 and 4.3. You can get better results with these. In the meantime, I think your test case has uncovered another issue. $ ./a.out | hexdump 000 6261 2000 2020 2020 2020 2020 2020 2020 010 2020 2020 0a20 There is a oo in byte position 4. I will have to investigate further. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-08 19:12:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32678
[Bug bootstrap/32679] New: cpp bug in libffi (looks like brother of http://gcc.gnu.org/ml/gcc/2003-05/msg01774.html)
/bin/sh ./libtool --tag=GCJ --mode=link /usr/src/rpm/BUILD/gcc-build/gcc/gcj -B/usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libjava/ -B/usr/src/rpm/BUILD/gcc-build/gcc/ -L/usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libjava -march=pentium4 -mtune=pentium4 -fno-asynchronous-unwind-tables -fregmove -funit-at-a-time -o jv-convert --main=gnu.gcj.convert.Convert -rpath /usr/lib/gcc/pentium4-east-linux/4.3.0 -shared-libgcc -L/usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libjava/.libs libgcj.la libtool: link: /usr/src/rpm/BUILD/gcc-build/gcc/gcj -B/usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libjava/ -B/usr/src/rpm/BUILD/gcc-build/gcc/ -march=pentium4 -mtune=pentium4 -fno-asynchronous-unwind-tables -fregmove -funit-at-a-time -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libjava/.libs -L/usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libjava ./.libs/libgcj.so -lpthread -lrt -ldl -lz /usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libffi/.libs/libffi.so -Wl,-rpath -Wl,/usr/lib/gcc/pentium4-east-linux/4.3.0 /usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libffi/.libs/libffi.so: undefined reference to `FFI_TYPE_DOUBLE' /usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libffi/.libs/libffi.so: undefined reference to `FFI_TYPE_FLOAT' /usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libffi/.libs/libffi.so: undefined reference to `FFI_TYPE_LONGDOUBLE' /usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libffi/.libs/libffi.so: undefined reference to `FFI_TYPE_SINT64' /usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libffi/.libs/libffi.so: undefined reference to `FFI_TYPE_INT' collect2: ld returned 1 exit status The preprocessd source of libffi/src/types.c is attached -- Summary: cpp bug in libffi (looks like brother of http://gcc.gnu.org/ml/gcc/2003-05/msg01774.html) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Vladislav dot Mikhailikov at paradox-neo dot uz GCC build triplet: pentium4-east-linux GCC host triplet: pentium4-east-linux GCC target triplet: pentium4-east-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32679
[Bug bootstrap/32679] cpp bug in libffi (looks like brother of http://gcc.gnu.org/ml/gcc/2003-05/msg01774.html)
--- Comment #1 from Vladislav dot Mikhailikov at paradox-neo dot uz
2007-07-08 19:20 ---
# 1 ../../../gcc-4.3.0-20070707/libffi/src/types.c
# 1 /usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libffi//
# 1 built-in
# 1 command-line
# 1 ../../../gcc-4.3.0-20070707/libffi/src/types.c
# 30 ../../../gcc-4.3.0-20070707/libffi/src/types.c
# 1 include/ffi.h 1
# 63 include/ffi.h
# 1 include/ffitarget.h 1
# 39 include/ffitarget.h
typedef unsigned long ffi_arg;
typedef signed long ffi_sarg;
typedef enum ffi_abi {
FFI_FIRST_ABI = 0,
# 55 include/ffitarget.h
FFI_SYSV,
FFI_UNIX64,
FFI_DEFAULT_ABI = FFI_SYSV,
FFI_LAST_ABI = FFI_DEFAULT_ABI + 1
} ffi_abi;
# 64 include/ffi.h 2
# 1 /usr/src/rpm/BUILD/gcc-build/./gcc/include/stddef.h 1 3 4
# 152 /usr/src/rpm/BUILD/gcc-build/./gcc/include/stddef.h 3 4
typedef int ptrdiff_t;
# 214 /usr/src/rpm/BUILD/gcc-build/./gcc/include/stddef.h 3 4
typedef unsigned int size_t;
# 326 /usr/src/rpm/BUILD/gcc-build/./gcc/include/stddef.h 3 4
typedef long int wchar_t;
# 68 include/ffi.h 2
# 1 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/limits.h 1 3 4
# 11 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/limits.h 3 4
# 1 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/syslimits.h 1 3 4
# 1 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/limits.h 1 3 4
# 122 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/limits.h 3 4
# 1 /usr/include/limits.h 1 3 4
# 27 /usr/include/limits.h 3 4
# 1 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/features.h 1 3 4
# 337 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 324 /usr/include/sys/cdefs.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 325 /usr/include/sys/cdefs.h 2 3 4
# 338 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/features.h 2 3 4
# 360 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 5 /usr/include/gnu/stubs.h 2 3 4
# 1 /usr/include/gnu/stubs-32.h 1 3 4
# 8 /usr/include/gnu/stubs.h 2 3 4
# 361 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/features.h 2 3 4
# 28 /usr/include/limits.h 2 3 4
# 145 /usr/include/limits.h 3 4
# 1 /usr/include/bits/posix1_lim.h 1 3 4
# 153 /usr/include/bits/posix1_lim.h 3 4
# 1 /usr/include/bits/local_lim.h 1 3 4
# 36 /usr/include/bits/local_lim.h 3 4
# 1 /usr/include/linux/limits.h 1 3 4
# 37 /usr/include/bits/local_lim.h 2 3 4
# 154 /usr/include/bits/posix1_lim.h 2 3 4
# 146 /usr/include/limits.h 2 3 4
# 1 /usr/include/bits/posix2_lim.h 1 3 4
# 150 /usr/include/limits.h 2 3 4
# 123 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/limits.h 2 3 4
# 8 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/syslimits.h 2 3 4
# 12 /usr/src/rpm/BUILD/gcc-build/./gcc/include-fixed/limits.h 2 3 4
# 69 include/ffi.h 2
# 88 include/ffi.h
typedef struct _ffi_type
{
size_t size;
unsigned short alignment;
unsigned short type;
struct _ffi_type **elements;
} ffi_type;
# 166 include/ffi.h
typedef enum {
FFI_OK = 0,
FFI_BAD_TYPEDEF,
FFI_BAD_ABI
} ffi_status;
typedef unsigned FFI_TYPE;
typedef struct {
ffi_abi abi;
unsigned nargs;
ffi_type **arg_types;
ffi_type *rtype;
unsigned bytes;
unsigned flags;
} ffi_cif;
# 196 include/ffi.h
typedef union {
ffi_sarg sint;
ffi_arg uint;
float flt;
char data[4];
void* ptr;
} ffi_raw;
void ffi_raw_call (ffi_cif *cif,
void (*fn)(),
void *rvalue,
ffi_raw *avalue);
void ffi_ptrarray_to_raw (ffi_cif *cif, void **args, ffi_raw *raw);
void ffi_raw_to_ptrarray (ffi_cif *cif, ffi_raw *raw, void **args);
size_t ffi_raw_size (ffi_cif *cif);
void ffi_java_raw_call (ffi_cif *cif,
void (*fn)(),
void *rvalue,
ffi_raw *avalue);
void ffi_java_ptrarray_to_raw (ffi_cif *cif, void **args, ffi_raw *raw);
void ffi_java_raw_to_ptrarray (ffi_cif *cif, ffi_raw *raw, void **args);
size_t ffi_java_raw_size (ffi_cif *cif);
typedef struct {
char tramp[10];
ffi_cif *cif;
void (*fun)(ffi_cif*,void*,void**,void*);
void *user_data;
} ffi_closure __attribute__((aligned (8)));
void *ffi_closure_alloc (size_t size, void **code);
void ffi_closure_free (void *);
ffi_status
ffi_prep_closure (ffi_closure*,
ffi_cif *,
void (*fun)(ffi_cif*,void*,void**,void*),
void *user_data);
ffi_status
ffi_prep_closure_loc (ffi_closure*,
ffi_cif *,
void (*fun)(ffi_cif*,void*,void**,void*),
void *user_data,
void*codeloc);
typedef struct {
char tramp[10];
ffi_cif *cif;
# 269 include/ffi.h
void (*fun)(ffi_cif*,void*,ffi_raw*,void*);
void *user_data;
} ffi_raw_closure;
ffi_status
ffi_prep_raw_closure (ffi_raw_closure*,
ffi_cif *cif,
void (*fun)(ffi_cif*,void*,ffi_raw*,void*),
void *user_data);
ffi_status
ffi_prep_raw_closure_loc (ffi_raw_closure*,
ffi_cif *cif,
void (*fun)(ffi_cif*,void*,ffi_raw*,void*),
void *user_data,
void *codeloc);
ffi_status
ffi_prep_java_raw_closure
[Bug bootstrap/32679] cpp bug in libffi (looks like brother of http://gcc.gnu.org/ml/gcc/2003-05/msg01774.html)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-08 19:20 --- *** This bug has been marked as a duplicate of 32670 *** *** This bug has been marked as a duplicate of 32670 *** *** This bug has been marked as a duplicate of 32670 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32679
[Bug preprocessor/32670] '$' is handled as a part of identifiers in asm
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-08 19:20 --- *** Bug 32679 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Vladislav dot Mikhailikov at ||paradox-neo dot uz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32670
[Bug preprocessor/32670] [4.3 Regression] '$' is handled as a part of identifiers in asm
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-08 19:21 --- Fixed by: 2007-07-08 Sandra Loosemore [EMAIL PROTECTED] Revert this patch: 2007-07-06 Sandra Loosemore [EMAIL PROTECTED] * c-opts.c (c_common_handle_option): Make DOLLARS_IN_IDENTIFIERS apply to assembly language, too. * doc/tm.texi (DOLLARS_IN_IDENTIFIERS): Update. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|'$' is handled as a part of |[4.3 Regression] '$' is |identifiers in asm |handled as a part of ||identifiers in asm Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32670
[Bug bootstrap/32679] cpp bug in libffi (looks like brother of http://gcc.gnu.org/ml/gcc/2003-05/msg01774.html)
--- Comment #3 from Vladislav dot Mikhailikov at paradox-neo dot uz 2007-07-08 19:22 --- Created an attachment (id=13871) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13871action=view) Preprocessed source of libffi's types.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32679
[Bug debug/32610] [4.2/4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-08 19:30 ---
Confirmed.
Reduced testcase:
void matmat(int nbc1 ) { double (*m1)[nbc1]; }
void rtop(void) { matmat(1); }
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-07-08 19:30:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug tree-optimization/32573] [4.3 Regression] ice for legal code with -O3
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-08 19:37 ---
The whole ddr.subscripts vec is messed up:
(gdb) p *ddr.subscripts
$5 = {
base = {
num = 1125262459,
alloc = 0,
vec = {0x43121100}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug fortran/31609] module that calls a contained function with an ENTRY point
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-08 19:40 --- (In reply to comment #4) Not sure if this is same bug or new one. Al, How do I load a .zip file through Bugzilla, please? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
[Bug fortran/31609] module that calls a contained function with an ENTRY point
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-08 19:44 --- Not sure if this is same bug or new one. Paul, this probably became PR32594. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
[Bug middle-end/32667] builtin operator= generates memcpy with overlapping memory regions
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-08 19:46 --- No, this doesn't have anything to do with aliasing. 4.3 simply inlines the memcpys. This is probably a middle-end issue with expanding structure assignments. 2.95 and 3.3 also expanded the calls inline. 3.4 does not, likewise 4.0, 4.1 and 4.2. Note that this is likely not a problem in practice as memcpy (p, p, sizeof (*p)) is difficult to implement in a way that would make it not work. So, downgrading severity. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|major |normal Status|UNCONFIRMED |NEW Component|c++ |middle-end Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-07-08 19:46:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
[Bug fortran/31609] module that calls a contained function with an ENTRY point
--- Comment #7 from jvdelisle at verizon dot net 2007-07-08 19:54 --- Subject: Re: module that calls a contained function with an ENTRY point pault at gcc dot gnu dot org wrote: --- Comment #5 from pault at gcc dot gnu dot org 2007-07-08 19:40 --- (In reply to comment #4) Not sure if this is same bug or new one. Al, How do I load a .zip file through Bugzilla, please? Paul goto irc and we talk. Jerry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
[Bug c/32680] New: unneeded movsbl
Code compiled with -O2 -fomit-frame-pointer
char function1(){ return 10; }
char (*pfunc)() = function1;
char function2(){ return pfunc(); }
produce unneeded movsbl instruction:
_function2:
subl$12, %esp unneeded
call*_pfunc
addl$12, %esp unneeded
movsbl %al,%eax unneeded
ret
eax register allready contains char and don't need to be converted.
Code for
long function1(){ return 10; }
long (*pfunc)() = function1;
lonf function2(){ return pfunc(); }
looks fine.
--
Summary: unneeded movsbl
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: romikb at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32680
[Bug middle-end/32680] unneeded movsbl
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-08 20:29 --- eax register allready contains char not true but oh well, it is called promting for abi reasons. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32680
[Bug fortran/25094] Procedure with public generic identifier allowed to have argument of private type
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-08 20:39 --- Subject: Bug 25094 Author: dfranke Date: Sun Jul 8 20:38:58 2007 New Revision: 126466 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126466 Log: gcc/fortran: 2007-07-08 Daniel Franke [EMAIL PROTECTED] PR fortran/25094 * resolve.c (resolve_fl_procedure): Added check for PRIVATE types in PUBLIC interfaces. gcc/testsuite: 2007-07-08 Daniel Franke [EMAIL PROTECTED] PR fortran/25094 * gfortran.dg/interface_15.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/interface_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25094
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-07-08 20:40 --- Subject: Re: [4.3 regression]: revision 126369 went into an infinite loop On 8 Jul 2007 15:12:51 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: --- Comment #10 from hjl at lucon dot org 2007-07-08 15:12 --- When a statement has no vuses, but its LHS value handle has vuses, we wind up with tree val = vn_lookup_or_add_with_stmt (newt, stmt); vn_add (lhs, val); Now the LHS value handle changes from vuses to no vuses since the statement has no vuses. Are you sure you handle this case correctly? Can we reuse LHS value handle in this case? I'm going to fix the whole dman thing the righ tway, which is to remove vuses from value handles and attach them to expressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug middle-end/32667] builtin operator= generates memcpy with overlapping memory regions
--- Comment #4 from pcarlini at suse dot de 2007-07-08 20:53 --- Thanks for the clarification, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
[Bug fortran/32669] [4.3 Regression] Actual argument contains too few elements for dummy argument is triggered for valid code
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-08 20:57 --- Subject: Bug 32669 Author: burnus Date: Sun Jul 8 20:57:07 2007 New Revision: 126467 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126467 Log: 2007-07-08 Tobias Burnus [EMAIL PROTECTED] PR fortran/32669 * interface.c (get_expr_storage_size): Properly obtain lower bound. (compare_actual_formal): Add space before parenthesis. 2007-07-08 Tobias Burnus [EMAIL PROTECTED] PR fortran/32669 * gfortran.dg/argument_checking_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/argument_checking_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32669
[Bug fortran/32669] [4.3 Regression] Actual argument contains too few elements for dummy argument is triggered for valid code
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-08 20:57 --- FIXED. Note: This is PR was not rejects-valid but only diagnostic as a (bogus) warning was printed and not an error. The problem occurred for array sections where the lower bound was not specified (a(:), a(:4) etc.); in this case the lower bound was always 1. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords|rejects-valid |diagnostic Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32669
[Bug fortran/32535] namelist with private items contained in sub-sub-procedure of a module rejected
--- Comment #1 from patchapp at dberlin dot org 2007-07-08 21:06 --- Subject: Bug number PR 32535 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00650.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32535
[Bug fortran/17711] Wrong operator name in error message
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-07-08 21:09 --- Subject: Bug 17711 Author: dfranke Date: Sun Jul 8 21:08:52 2007 New Revision: 126468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126468 Log: gcc/fortran: 2007-07-08 Daniel Franke [EMAIL PROTECTED] Tobias Schlüter [EMAIL PROTECTED] PR fortran/17711 * gfortran.h (gfc_intrinsic_op): Added INTRINSIC_EQ_OS, INTRINSIC_NE_OS, INTRINSIC_GT_OS, INTRINSIC_GE_OS, INTRINSIC_LT_OS and INTRINSIC_LE_OS. * arith.c (eval_intrinsic, eval_type_intrinsic0): Likewise. * arith.h (gfc_eq, gfc_ne, gfc_gt, gfc_ge, gfc_lt, gfc_le): Added gfc_intrinsic_op as third argument type. * dump-parse-tree.c (gfc_show_expr): Account for new enum values. * expr.c (simplify_intrinsic_op, check_intrinsic_op): Likewise. * interface.c (check_operator_interface): Likewise. (gfc_check_interfaces): Added cross-checks for FORTRAN 77 and Fortran 90 style operators using new enum values. (gfc_extend_expr): Likewise. (gfc_add_interface): Likewise. * match.c (intrinsic_operators): Distinguish FORTRAN 77 style operators from Fortran 90 style operators using new enum values. * matchexp.c (match_level_4): Account for new enum values. * module.c (mio_expr): Likewise. * resolve.c (resolve_operator): Deal with new enum values, fix inconsistent error messages. * trans-expr.c (gfc_conv_expr_op): Account for new enum values. gcc/testsuite: 2007-07-08 Daniel Franke [EMAIL PROTECTED] PR fortran/17711 * gfortran.dg/operator_4.f90: New test. * gfortran.dg/operator_5.f90: New test. * gfortran.dg/logical_comp.f90: Adjusted error messages. * gfortran.dg/module_md5_1.f90: Adjusted MD5 sum. Added: trunk/gcc/testsuite/gfortran.dg/operator_4.f90 trunk/gcc/testsuite/gfortran.dg/operator_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/arith.h trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/matchexp.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/logical_comp.f90 trunk/gcc/testsuite/gfortran.dg/module_md5_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17711
[Bug fortran/17711] Wrong operator name in error message
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-08 21:13 --- Fixed in trunk. No regression, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17711
[Bug fortran/25094] Procedure with public generic identifier allowed to have argument of private type
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-08 21:13 --- Fixed in trunk. No regression, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25094
[Bug c/32681] New: ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
I just tried to compile Suse Linux package aalib-1.4.0-364 with the GNU C compiler version 4.3 snapshot 20070706 The compiler said aarender.c: In function 'aa_renderpalette': aarender.c:33: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Here is some help from valgrind ==21796== Invalid read of size 2 ==21796==at 0x7CE295: extract_range_from_binary_expr (tree-vrp.c:1738) ==21796==by 0x7CF7DA: extract_range_from_expr (tree-vrp.c:2594) ==21796==by 0x7D1572: vrp_visit_assignment (tree-vrp.c:4679) ==21796==by 0x7D2606: vrp_visit_stmt (tree-vrp.c:5215) ==21796==by 0x7807F1: simulate_stmt (tree-ssa-propagate.c:322) ==21796==by 0x78113F: ssa_propagate (tree-ssa-propagate.c:445) ==21796==by 0x7C7BFD: execute_vrp (tree-vrp.c:6100) ==21796==by 0x61A7C8: execute_one_pass (passes.c:1126) ==21796==by 0x61A99F: execute_pass_list (passes.c:1179) ==21796==by 0x61A9B4: execute_pass_list (passes.c:1180) ==21796==by 0x6EA3E7: tree_rest_of_compilation (tree-optimize.c:406) ==21796==by 0x83F95F: cgraph_expand_function (cgraphunit.c:1073) ==21796== Address 0x0 is not stack'd, malloc'd or (recently) free'd Preprocessed source code attached. Flags -ffast-math -O3 -ftree-vectorize required. -- Summary: ice for legal C code with flags -ffast-math -O3 -ftree- vectorize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_ 64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug c/32681] ice for legal C code with flags -ffast-math -O3 -ftree-vectorize
--- Comment #1 from dcb314 at hotmail dot com 2007-07-08 21:15 --- Created an attachment (id=13872) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13872action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32681
[Bug fortran/32217] segfaults (at runtime) on UNPACK with zero-sized arrays
--- Comment #4 from patchapp at dberlin dot org 2007-07-08 21:30 --- Subject: Bug number PR 32217 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00717.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32217
[Bug libfortran/32336] matmul: flag runtime- instead of assertation error
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-07-08 22:08 --- Here's an example: $ cat mm.f90 program main real, dimension(:,:), allocatable :: a real, dimension(:), allocatable :: b allocate (a(2,2), b(3)) call random_number(a) call random_number(b) print *,matmul(a,b) end program main $ gfortran mm.f90 $ ./a.out a.out: ../../../../gcc/trunk/libgfortran/generated/matmul_r4.c:173: matmul_r4: Assertion `count == b-dim[0].ubound + 1 - b-dim[0].lbound' failed. Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32336
[Bug fortran/32217] segfaults (at runtime) on UNPACK with zero-sized arrays
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-07-08 22:20 --- Subject: Bug 32217 Author: tkoenig Date: Sun Jul 8 22:20:04 2007 New Revision: 126469 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126469 Log: 2007-07-08 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32217 * intrinsics/unpack_generic.c: If the destination array is empty, return early. 2007-07-08 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32217 * gfortran.dg/unpack_zerosize_1.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/unpack_zerosize_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/unpack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32217
[Bug fortran/32217] segfaults (at runtime) on UNPACK with zero-sized arrays
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-07-08 22:23 --- Fixed on mainline. No plans to backport this to 4.2. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32217
[Bug fortran/32678] GFortan works incorrectly when writing with FORMAT Tx
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-07-08 22:37 --- This appears to fix it: Still testing Index: transfer.c === --- transfer.c (revision 126449) +++ transfer.c (working copy) @@ -1213,6 +1213,8 @@ formatted_transfer_scalar (st_parameter_ dtp-u.p.skips = dtp-u.p.skips + pos - bytes_used; dtp-u.p.pending_spaces = dtp-u.p.pending_spaces + pos - dtp-u.p.max_pos; + dtp-u.p.pending_spaces = dtp-u.p.pending_spaces 0 + ? 0 : dtp-u.p.pending_spaces; if (dtp-u.p.skips == 0) break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32678
[Bug fortran/32682] New: [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
consider the following program: program matrix implicit none real,dimension(2,2),parameter::c=0 real,dimension(2,2)::m m=f()+c m=c+f() call sub(m+f()) call sub(c+m) call sub(f()+c) call sub(c+f()) contains function f() implicit none real, dimension(2,2)::f f=0 end function f subroutine sub(a) implicit none real, dimension(2,2)::a end subroutine sub end program matrix this gives the error message: matrix.f90: In function MAIN__: matrix.f90:11: internal compiler error: in gfc_trans_array_constructor, at fortran/trans-array.c:1664 though the message claims an error in line 11, the program only fails in the presence of line 12: call sub(c+f()) all the lines before (7-11) are ok. the ICE only appears in exactly this configuration, i.e. c is a parameter, f is a function, and c+f() is fed as an argument to a subroutine it happens in trans-array.c(gfc_trans_array_constructor), line 1664: /* We should have a 1-dimensional, zero-based loop. */ gcc_assert (loop-dimen == 1); this fails with loop-dimen==2 in our case happens only with 4.3 (trunk), but not with 4.1 or 4.2 -- Summary: [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug c++/30917] [4.1/4.2/4.3 Regression] ICE with friend in local class (to a function)
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-07-08 22:40
---
Simon --
It took me a while to decide that this patch was OK -- but it is. :-) I will
suggest a few changes to make it more obviously correct.
First, minor coding style nit: drop the else after the return that you've
introduced.
Second, we need some chapter-and-verse in here. Please avoid references like
11.4.8 as the numbers tend to move around as the standard changes. (For
example, I don't think 11.4.8 is the right reference in either the published
standard or the current WP.)
For the comment on the gcc_asert, I would say:
/* A non namespace-scope binding can only be hidden if we
are in a local class, due to friend declarations. In particular,
consider:
void f() {
struct A {
friend struct B;
void g() { B* b; } // error: B is hidden
}
struct B {};
}
The standard says that B is a local class in f (but not nested within
A) -- but that name lookup for B does not find this declaration until
it is declared directly with f.
In particular:
[class.friend]
If a friend declaration appears in a local class and the name specified
is an unqualified name, a prior declaration is looked up without considering
scopes that are outside the innermost enclosing non-class scope
For a friend class declaration, if there is no prior declaration, the class
that is specified belongs to the innermost enclosing non-class scope, but
if it is subsequently referenced, its name is not found by name lookup until
a matching declaration is provided in the innermost enclosing nonclass
scope.
*/
OK with that change.
Thanks,
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
CC||simartin at users dot
||sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30917
[Bug c++/30535] [4.2/4.3 regression] ICE with invalid template operator
--- Comment #3 from paolo at gcc dot gnu dot org 2007-07-08 22:41 --- Subject: Bug 30535 Author: paolo Date: Sun Jul 8 22:41:12 2007 New Revision: 126470 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126470 Log: /cp 2007-07-08 Paolo Carlini [EMAIL PROTECTED] PR c++/30535 * pt.c (unify): Never pass error_mark_node to template_decl_level. /testsuite 2007-07-08 Paolo Carlini [EMAIL PROTECTED] PR c++/30535 * g++.dg/template/operator10.C: New. Added: trunk/gcc/testsuite/g++.dg/template/operator10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30535
[Bug fortran/24784] Warning about unused routine argument should not read unused variable
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-08 22:41 --- Subject: Bug 24784 Author: dfranke Date: Sun Jul 8 22:41:35 2007 New Revision: 126471 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126471 Log: gcc: 2007-07-08 Daniel Franke [EMAIL PROTECTED] * function.c (do_warn_unused_parameter): Do not warn if TREE_NO_WARNING is set. gcc/fortran: 2007-07-08 Daniel Franke [EMAIL PROTECTED] PR fortran/24784 PR fortran/28004 * trans-decl.c (generate_local_decl): Adjusted warning on unused dummy arguments, tell middle-end not to emit additional warnings. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24784
[Bug fortran/28004] Warn if intent(out) dummy variable is not set
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-07-08 22:41 --- Subject: Bug 28004 Author: dfranke Date: Sun Jul 8 22:41:35 2007 New Revision: 126471 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126471 Log: gcc: 2007-07-08 Daniel Franke [EMAIL PROTECTED] * function.c (do_warn_unused_parameter): Do not warn if TREE_NO_WARNING is set. gcc/fortran: 2007-07-08 Daniel Franke [EMAIL PROTECTED] PR fortran/24784 PR fortran/28004 * trans-decl.c (generate_local_decl): Adjusted warning on unused dummy arguments, tell middle-end not to emit additional warnings. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
[Bug fortran/24784] Warning about unused routine argument should not read unused variable
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-07-08 22:45 --- Fixed in trunk. Not a regression, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24784
[Bug fortran/28004] Warn if intent(out) dummy variable is used before being defined
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-07-08 22:54 --- Partially fixed (warn if unused and thus not set). Changed summary to reflect the remaining task. Unassigning myself. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dfranke at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|Warn if intent(out) dummy |Warn if intent(out) dummy |variable is not set |variable is used before ||being defined http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
[Bug fortran/29876] ICE on bad operator in ONLY clause of USE statement
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-08 22:58 --- Subject: Bug 29876 Author: dfranke Date: Sun Jul 8 22:58:45 2007 New Revision: 126472 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126472 Log: gcc/fortran: 2007-07-08 Daniel Franke [EMAIL PROTECTED] PR fortran/29876 * module.c (gfc_match_use): Do not set an non-existant intrinsic operator if a user-defined operator is found. gcc/testsuite: 2007-07-08 Daniel Franke [EMAIL PROTECTED] PR fortran/29876 * gfortran.dg/operator_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/operator_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29876
[Bug fortran/29876] ICE on bad operator in ONLY clause of USE statement
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-08 23:03 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29876
[Bug fortran/32678] GFortan works incorrectly when writing with FORMAT Tx
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-09 00:15 --- Subject: Bug 32678 Author: jvdelisle Date: Mon Jul 9 00:15:15 2007 New Revision: 126473 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126473 Log: 2007-07-08 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/32678 * io/transfer.c (formatted_transfer_scalar): Don't allow pending_spaces to go negative. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32678
[Bug fortran/32678] GFortan works incorrectly when writing with FORMAT Tx
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-09 00:17 --- Subject: Bug 32678 Author: jvdelisle Date: Mon Jul 9 00:17:42 2007 New Revision: 126478 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126478 Log: 2007-07-08 Jerry DeLisle [EMAIL PROTECTED] PR fortran/32678 * gfortran.dg/fmt_t_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_t_5.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32678
[Bug fortran/32678] [4.2, 4.1]GFortan works incorrectly when writing with FORMAT Tx
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-09 00:22 --- Fixed on 4.3. Will back port to 4.2 and 4.1 since this is a regression with respect to g77. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|GFortan works incorrectly |[4.2, 4.1]GFortan works |when writing with FORMAT Tx |incorrectly when writing ||with FORMAT Tx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32678
[Bug c++/32683] New: Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)
I'm not an expert in C++. This bug report's subject is HPCToolkit compiles
with GCC 4.2 (and earlier) but won't compile with GCC 4.3 . I don't know if it
is because GCC was less fussy previously or there is a fault in GCC 4.3.
There are so many warnings and errors, and the program _might_ be of interest
to persons working with GCC source, so I will provide a little info about it:
HPCToolkit is an open-source suite of multi-platform tools for profile-based
performance analysis of applications. http://www.hipersoft.rice.edu/hpctoolkit/
It produces a navigable HTML document that combines the performance metrics
with the source code.
The toolkit components include:
hpcrun: a tool for profiling executions of unmodified application binaries
using statistical sampling of hardware performance counters.
hpcprof xprof: tools for interpeting sample-based execution profiles and
relating them back to program source lines.
bloop: a tool for analyzing application binaries to recover program structure;
namely, to identify where loops are present and what program source lines they
contain.
hpcview: a tool for correlating program structure information, multiple
sample-based performance profiles, and program source code to produce a
performance database.
hpcviewer: a java-based GUI for exploring databases consisting of performance
information correlated with program source.
HPCToolkit-OneStopShopping-TRUNK-4.9.0=810.tar.gz
http://www.hipersoft.rice.edu/hpctoolkit/downloads/HPCToolkit-OneStopShopping-TRUNK-4.9.0=810.tar.gz
The authors complain of slight differences in the operation of binutils
between various platforms and have attempted to resolve those problems - that
might be interesting reading for some.
I configured and installed GCC 4.3, here is the -v:
# /usr/test/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr/test
--enable-objc-gc --disable-multilib
--with-gxx-include-dir=/usr/test/include/c++/4.3 --enable-libstdcxx-debug
--enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit
--enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp
--enable-libmudflap --enable-libgomp --disable-werror --enable-nls
--with-included-gettext --enable-decimal-float --enable-debug
--enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo
--enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers
--enable-portable-native-sync --enable-examples --with-dwarf2 --with-stabs
--enable-hash-synchronization --enable-gc-debug --enable-interpreter
--with-system-zlib --enable-libada --with-tls --with-tune=athlon-xp
--with-cpu=athlon-xp --with-arch=athlon-xp
--enable-stage1-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.3.0 20070630 (experimental)
I am not using a more recent version because there is a problem (it won't
build) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589 .
I set my environment like this (since 4.3 is not in my path):
export CC=/usr/test/bin/gcc
export CXX=/usr/test/bin/g++
export F77=/usr/test/bin/gfortran
export JAVAC='javac -1.5'
If you wish to build the viewer you'll need to use javac -1.5 to avoid
complaints about using annotations.
I configured HPCToolkit like this:
./configure --prefix=/usr --enable-hpcviewer --enable-develop --enable-devtools
--enable-hpc-binutils --with-monitor --with-objcopy
It turns out that my OS's bash doesn't like = in file names they use the name
HPCToolkit-OneStopShopping-TRUNK-4.9.0-810 . You might want to rename it
before you configure and make this project.
When building HPCToolkit some files produced _many_ warnings and errors. I am
not an expert on C++ but I did try adding -ansi, -std=c++98, and
-std=gnu++98 to the 4.3 command line - still the same errors.
I tried to compile a _few_ of these files with gcc 3.4 and 4.2 - it worked fine
on the _small_ number of files I tested. All the failing files were compiled
using GCC 4.1 and compiled without warning or error. My checking of 3.4 and 4.2
is limited.
The files attached all failed to compile with GCC 4.3 (20070630) and compiled
_perfectly_ (no warning or errors) with gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21).
Here is a couple of reduced testcases, The people who wrote this C++ and some
other people at GCC's bugzilla know more about C++ than I do, so I'll leave the
rest ...
Here is a reduced testcase for bloop_LocationMgr.cpp (no claim the testcase is
a useful program!):
#include string
using std::string;
static const string RELOCATED = [reloc-from];
inline bool
RELOCATEDcmp(const char* x)
{
return (strncmp(x, RELOCATED.c_str(), RELOCATED.length()) == 0);
}
# gcc-3.4 -c -o test_1.o test_1.cpp
(Prints nothing)
# gcc-4.1 -c -o test_1.o test_1.cpp
(Prints
[Bug c++/32683] Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)
--- Comment #1 from rob1weld at aol dot com 2007-07-09 02:49 --- Created an attachment (id=13873) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13873action=view) A few example .ii files (from a list of many) that have errors when compiled using GCC == 4.3 --- but do not have any errors or warnings with GCC 4.3 . GCC does not seem to compile .ii files out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32683
[Bug libstdc++/32683] Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-09 02:53 --- # gcc-4.3 -c -o test_1.o test_1.cpp test_1.cpp: In function 'bool RELOCATEDcmp(const char*)': test_1.cpp:9: error: 'strncmp' was not declared in this scope No include for string.h or cstring. # gcc-4.3 -c -o test_2.o test_2.cpp test_2.cpp: In function 'void Ctor(const char*)': test_2.cpp:10: error: 'strlen' was not declared in this scope Likewise. All of these look like missing includes in the source and nothing wrong with GCC 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32683
[Bug tree-optimization/32684] New: Missed tail call with sin/cos and sincos pass
Testcase:
double _Complex quantum_cexp(double phi)
{
return __builtin_cos(phi) + 1i * __builtin_sin(phi);
}
- Cut
This shows up in libquantum (but after fixing a different issue which I will
file seperately).
--
Summary: Missed tail call with sin/cos and sincos pass
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32684
[Bug tree-optimization/32685] New: Missed changing of sin into sinf (likewise for cos to cosf)
Testcase:
float _Complex quantum_cexp(float phi)
{
return __builtin_cos(phi) + 1i * __builtin_sin(phi);
}
--- CUT
We should able to change cos/sin here into cosf/sinf (and then into cexpfi).
This shows up in libquantum (which is part of SPEC 2k6 but the sources I am
using to test are the open soruce ones and not the SPEC 2k6 ones).
--
Summary: Missed changing of sin into sinf (likewise for cos to
cosf)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32685
[Bug middle-end/32686] New: Code to convert double to _Complex double for arguments passing is not good (extra load)
Testcase:
_Complex double f(_Complex double);
_Complex double g(double a)
{
return f(a);
}
- Cut
We currently get:
mflr r0
bcl 20,31,L001$pb
L001$pb:
stw r31,-4(r1)
mflr r31
stfd f1,-24(r1)
mtlr r0
lwz r3,-24(r1)
lwz r4,-20(r1)
addis r2,r31,ha16(LC0-L001$pb)
lwz r31,-4(r1)
la r5,lo16(LC0-L001$pb)(r2)
lwz r6,4(r5)
lwz r5,0(r5)
b L_f$stub
We should be able to get:
stfd f1,-8(r1)
li r6,0
li r5,0
lwz r3,-8(r1)
lwz r4,-4(r1)
b L_f$stub
Without the need for the PIC register.
--
Summary: Code to convert double to _Complex double for arguments
passing is not good (extra load)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32686
[Bug middle-end/32686] Code to convert double to _Complex double for arguments passing is not good (extra load)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 03:33 --- powerpc64-darwin is just as bad, we get: mflr r0 std r31,-8(r1) stfd f1,-32(r1) bcl 20,31,L001$pb L001$pb: mflr r31 addis r2,r31,ha16(LC0-L001$pb) mtlr r0 ld r4,lo16(LC0-L001$pb)(r2) ld r3,-32(r1) ld r31,-8(r1) b L_f$stub When we should get: stfd f1,-8(r1) li r4,0 ld r3,-8(r1) b L_f$stub With a few nops through in there so we don't reject the distpatch group. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32686
[Bug fortran/31609] module that calls a contained function with an ENTRY point
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-09 04:45 --- This ICEs as well: MODULE ksbin1_aux_mod interface foo module procedure k end interface CONTAINS FUNCTION j () j = 1 ENTRY k () k = 2 END FUNCTION j END MODULE ksbin1_aux_mod I thought that such things had been fixed a while since *sigh* Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
[Bug fortran/32157] intrinsic function name conflicts with subroutine if present in the same file
--- Comment #4 from patchapp at dberlin dot org 2007-07-09 05:05 --- Subject: Bug number PR32157 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00744.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32157
[Bug tree-optimization/23834] Not removing a SSA_NAME which is not used
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-09 05:27 --- Fixed by: 2007-05-28 Daniel Berlin [EMAIL PROTECTED] * tree-ssa-dce.c (eliminate_unnecessary_stmts): Release LHS SSA name when we remove it from a call. 2007-01-24 Jan Hubicka [EMAIL PROTECTED] * tree-ssa-dce.c (eliminate_unnecesary_stmts): Remove dead LHS of calls. -- 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=23834
[Bug testsuite/25037] gcc.target/i386/asm-1.c fails with -m64 passed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-09 05:29 --- Fixed by: 2006-09-08 Eric Christopher [EMAIL PROTECTED] * gcc.target/i386/20060512-3.c: Run test on ilp32 only. * gcc.target/i386/memcpy-1.c: Ditto. * gcc.target/i386/asm-1.c: Ditto. -- 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=25037
