[Bug fortran/35740] a = conjg(transpose(a)) still gives wrong results, see bug 31994
--- Comment #2 from pault at gcc dot gnu dot org 2008-03-29 06:38 --- (In reply to comment #1) Confirm. There seems to be a temporary missing. Paul, you have fixed PR 31994, do you have an idea here? Tobias, I'll put my thinking cap on. Our conjg(tranpose()) trick is efficoent, of course, but it keeps on tripping us up. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-28 19:58:54 |2008-03-29 06:38:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35740
[Bug fortran/35740] a = conjg(transpose(a)) still gives wrong results, see bug 31994
--- Comment #3 from pault at gcc dot gnu dot org 2008-03-29 07:27 --- (In reply to comment #2) Hah! It's still worse than I thought. Not only is a temporary not made but the scalarizer is being blown out of the water by the likes of: program main implicit none complex, dimension(2,2) :: a,b,c,d a(1,1) = (1.,1.) a(2,1) = (2.,2.) a(1,2) = (3.,3.) a(2,2) = (4.,4.) b = a c = (0.0,0.0) b = conjg(transpose(b + c)) print *, H(a) -wrong: ,b b = a b = transpose(conjg(b + c)) print *, H(a) - OK: ,b b = a d = conjg(transpose(b + c)) b = d print *, H(a) - really wrong: ,b END program main Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35740
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-29 08:11 --- Subject: Bug 35698 Author: pault Date: Sat Mar 29 08:11:02 2008 New Revision: 133710 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133710 Log: 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * trans-array.c (gfc_array_init_size): Set 'size' zero if negative in one dimension. PR fortran/35702 * trans-expr.c (gfc_trans_string_copy): Only assign a char directly if the lhs and rhs types are the same. 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * gfortran.dg/allocate_zerosize_3.f: New test. PR fortran/35702 * gfortran.dg/character_assign_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_zerosize_3.f trunk/gcc/testsuite/gfortran.dg/character_assign_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35702] [4.3/4.4 Regression]: structure character element with subscripts
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-29 08:11 --- Subject: Bug 35702 Author: pault Date: Sat Mar 29 08:11:02 2008 New Revision: 133710 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133710 Log: 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * trans-array.c (gfc_array_init_size): Set 'size' zero if negative in one dimension. PR fortran/35702 * trans-expr.c (gfc_trans_string_copy): Only assign a char directly if the lhs and rhs types are the same. 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * gfortran.dg/allocate_zerosize_3.f: New test. PR fortran/35702 * gfortran.dg/character_assign_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_zerosize_3.f trunk/gcc/testsuite/gfortran.dg/character_assign_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35702
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-29 08:18 --- Subject: Bug 35698 Author: pault Date: Sat Mar 29 08:17:36 2008 New Revision: 133711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133711 Log: 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * trans-array.c (gfc_array_init_size): Set 'size' zero if negative in one dimension. PR fortran/35702 * trans-expr.c (gfc_trans_string_copy): Only assign a char directly if the lhs and rhs types are the same. 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * gfortran.dg/allocate_zerosize_3.f: New test. PR fortran/35702 * gfortran.dg/character_assign_1.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/allocate_zerosize_3.f branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/character_assign_1.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-array.c branches/gcc-4_3-branch/gcc/fortran/trans-expr.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35702] [4.3/4.4 Regression]: structure character element with subscripts
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-29 08:18 --- Subject: Bug 35702 Author: pault Date: Sat Mar 29 08:17:36 2008 New Revision: 133711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133711 Log: 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * trans-array.c (gfc_array_init_size): Set 'size' zero if negative in one dimension. PR fortran/35702 * trans-expr.c (gfc_trans_string_copy): Only assign a char directly if the lhs and rhs types are the same. 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * gfortran.dg/allocate_zerosize_3.f: New test. PR fortran/35702 * gfortran.dg/character_assign_1.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/allocate_zerosize_3.f branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/character_assign_1.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-array.c branches/gcc-4_3-branch/gcc/fortran/trans-expr.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35702
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-29 08:19 --- Fixed on trunk and 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35702] [4.3/4.4 Regression]: structure character element with subscripts
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-29 08:20 --- Fixed on trunk and 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35702
[Bug fortran/34820] internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
--- Comment #8 from pault at gcc dot gnu dot org 2008-03-29 08:23 --- (In reply to comment #7) I have a regtested patch for this but cannot post it until Saturday, when I am back from vacation. Paul This has been delayed by the discovery of memory leaks in a number of the gfortran.dg/alloc_comp* Watch this space. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
[Bug rtl-optimization/33790] postreload can handle the case where the memory locations use different modes
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 08:55 --- Hmm, I wonder how important this is now after the DSE patch for PR 33927 which basically does the same thing and it also runs after reload. I really don't want to make cselib any slower than it is already and post reload cse is really to me a hack for reload (or really RA) not doing its job so I don't want to slow down post reload cse. I am going to close this as won't fix as the reasons mentioned about. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33790
Re: [Bug rtl-optimization/33790] postreload can handle the case where the memory locations use different modes
I forgot to mention that the dse patch fixes the problem earlier on so we now do the optimization pre-reload. We still have an extra store but that is recorded as another bug I filed. Sent from my iPhone On Mar 29, 2008, at 1:55, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 08:55 --- Hmm, I wonder how important this is now after the DSE patch for PR 33927 which basically does the same thing and it also runs after reload. I really don't want to make cselib any slower than it is already and post reload cse is really to me a hack for reload (or really RA) not doing its job so I don't want to slow down post reload cse. I am going to close this as won't fix as the reasons mentioned about. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33790
[Bug rtl-optimization/33790] postreload can handle the case where the memory locations use different modes
--- Comment #4 from pinskia at gmail dot com 2008-03-29 09:02 --- Subject: Re: postreload can handle the case where the memory locations use different modes I forgot to mention that the dse patch fixes the problem earlier on so we now do the optimization pre-reload. We still have an extra store but that is recorded as another bug I filed. Sent from my iPhone On Mar 29, 2008, at 1:55, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 08:55 --- Hmm, I wonder how important this is now after the DSE patch for PR 33927 which basically does the same thing and it also runs after reload. I really don't want to make cselib any slower than it is already and post reload cse is really to me a hack for reload (or really RA) not doing its job so I don't want to slow down post reload cse. I am going to close this as won't fix as the reasons mentioned about. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33790 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33790
[Bug c/35753] apparent integer math bug
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-29 10:27 --- use unsigned arithmetic. -- 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=35753
[Bug c++/35708] jump to label enters catch block
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-29 10:52 ---
Here's a shorter testcase:
struct object { int one_o; int allocstamp; };
int pgci_pointable (object obj);
void foo(void);
int main (int argc, char *argv[])
{
if (pgci_pointable((object){7,100}))
{
bad_rehash_size:
foo();
}
goto bad_rehash_size;
}
If you look at the original IL as coming from the FE you see
{
cleanup_point struct object D.1681 = {.one_o=7, .allocstamp=100};;
Unknown tree: if_stmt
cleanup_point pgci_pointable (D.1681) != 0
bad_rehash_size:;
cleanup_point Unknown tree: expr_stmt foo () ;
;
}
goto bad_rehash_size;
which is gimplified to
{
{
struct objectD.1670 D.1681;
D.1681.one_oD.1672 = 7;
D.1681.allocstampD.1673 = 100;
D.1699 = pgci_pointable (D.1681);
retval.0D.1698 = D.1699 != 0;
if (retval.0D.1698)
{
bad_rehash_sizeD.1697:;
foo ();
}
else
{
}
}
goto bad_rehash_sizeD.1697;
}
at which point the goto enters a scope with local objects constructed
before the jump target. Thus the FE generates a new scope around the
if statement where the temporary object is bound to and somehow this
is a of type sk_catch (that there is no checking whether something can
throw inside the block may be a problem).
With gcc 4.1 where the testcase is accepted we gimplify to
int main(int, char**) (argc, argv)
{
boolD.1451 retval.0D.1759;
struct objectD.1732 D.1760;
intD.2 D.1761;
intD.2 D.1762;
D.1760.one_oD.1734 = 7;
D.1760.allocstampD.1735 = 100;
D.1761 = pgci_pointable (D.1760);
retval.0D.1759 = D.1761 != 0;
if (retval.0D.1759)
{
bad_rehash_sizeD.1758:;
foo ();
}
else
{
}
goto bad_rehash_sizeD.1758;
not creating this extra scope.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Known to fail||4.2.3 4.3.0
Known to work||4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c++/35708] jump to label enters catch block
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-29 10:56 --- Jason, can you have a look here? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug target/34879] __builtin_setjmp / __builtin_longjmp fails stack frame address with O2, O3 and Os
--- Comment #1 from hutchinsonandy at aim dot com 2008-03-29 11:37 --- Created an attachment (id=15395) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15395action=view) Setjmp patch for AVR The attached patch is a fix for AVR target. MIPS does something similar to get around same issue. The real problem is with gcc builin setjmp receiver being removed by optimizers. Optimizers think that frame_pointer load in receiver is unneeded and remove it! The patch loads the frame pointer in the nonlocal_goto, making the receiver (where it jumps to) empty, so bad optimization cannot remove it. Additionally, it avoids the unnecessary arithmetic around frame pointer offsets. This patch was tested and the testcase passes. Further changes may be required in the future if AVR 24bit jumps are to be supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34879
[Bug target/21080] Excecution test failure for avr for pr17377 test case.
--- Comment #3 from hutchinsonandy at aim dot com 2008-03-29 12:55 --- Created an attachment (id=15396) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15396action=view) Patch to correct return_address The attached patch fixes this problem and PR21078 The AVR target support for builtin_return_address only returned value of frame_pointer+1 - so it would only be correct if stack and frame were empty. The attached patch calculates the stack usage in the function prolog. This is placed in symbol stack_usage using UNSPEC instruction pattern. Builtin Return address uses RETURN_ADDR_RTX(count, tem) to add this to frame pointer to get to correct address. This only supports level 0 (same function). Other levels (ie upper functions) return 0 - which is correct response if not supported. The address is that read from the stack - ie word address. Testsuite torture/execute/20010122-1.c and PR17377.c both pass with this patch applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080
[Bug fortran/35754] New: -std=f95: Reject 1P2E12.4 w/o a comma after the P
The comma after the P is optional in Fortran 2003 if followed by a repeat specifier but required in Fortran 95. (According to MRC) -- Summary: -std=f95: Reject 1P2E12.4 w/o a comma after the P Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement 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=35754
[Bug c++/35708] jump to label enters catch block
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-29 15:13:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c++/35708] jump to label enters catch block
--- Comment #7 from jason at gcc dot gnu dot org 2008-03-29 15:19 --- The bug is that the temporary object created by the C99 compound literal syntax doesn't have proper C++ temporary lifetime; the compiler treats it as living until the end of the block, so the goto seems to be skipping its initialization. The compiler talks about a catch block because it assumes that the only artificial decl a goto could jump into is the one for the catch parameter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug libmudflap/35755] New: [4.4 Regression]: libmudflap.cth/pass39-frag.c
On Fedora 8/Intel64, gcc 4.4 revision 133638 gave FAIL: libmudflap.cth/pass39-frag.c (-O2) (rerun 16) execution test FAIL: libmudflap.cth/pass39-frag.c (-O2) (rerun 16) output pattern test Revision 133612 is OK. It could be related to stack limit. -- Summary: [4.4 Regression]: libmudflap.cth/pass39-frag.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35755
[Bug fortran/35756] New: incorrect WHERE for functions in ELSEWHERE and overlaps
The following program computes the wrong values for the even (elsewhere branch) of the left hand array. It looks like the function R_MY_MIN_I is evaluated before the store in the WHERE branch happens. The same thing happens if the R_M* functions are external rather than contained. Dick Hendrickson program RA1028 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] INTEGER ILA(10) LOGICAL LDA(10) ILA = (/ (I, i=1,10) /) LDA = (/ (i/2*2 .ne. I, i=1,10) /) WHERE(LDA) ILA = R_MY_MAX_I(ILA) ELSEWHERE ILA = R_MY_MIN_I(ILA) ENDWHERE print *, 10,2,10,2, ' etc'!expected print *, ila CONTAINS INTEGER FUNCTION R_MY_MAX_I(A) INTEGER :: A(:) R_MY_MAX_I = MAXVAL(A) END FUNCTION R_MY_MAX_I !internal procedure INTEGER FUNCTION R_MY_MIN_I(A) INTEGER :: A(:) R_MY_MIN_I = MINVAL(A) END FUNCTION R_MY_MIN_I !internal procedure END C:\g_experiments\gfortrangfortran ra1028.f C:\g_experiments\gfortrana 10 2 10 2 etc 10 1 10 1 10 1 10 1 10 1 -- Summary: incorrect WHERE for functions in ELSEWHERE and overlaps Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35756
[Bug fortran/35745] Divide incorrectly extracted from WHERE block?; run time abort
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-29 15:52 --- See also PR 35756. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35745
[Bug fortran/35756] incorrect WHERE for functions in ELSEWHERE and overlaps
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-29 15:52 --- Confirm. See also PR 35745. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-03-29 15:52:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35756
[Bug target/35757] New: [4.4 Regression] Incorrect contraint on sse4_1_blendpssemodesuffixf2c
sse.md has
(define_insn sse4_1_blendpssemodesuffixf2c
[(set (match_operand:SSEMODEF2P 0 register_operand =x)
(vec_merge:SSEMODEF2P
(match_operand:SSEMODEF2P 2 nonimmediate_operand xm)
(match_operand:SSEMODEF2P 1 register_operand 0)
(match_operand:SI 3 const_0_to_3_operand n)))]
TARGET_SSE4_1
blendpssemodesuffixf2c\t{%3, %2, %0|%0, %2, %3}
[(set_attr type ssemov)
(set_attr prefix_extra 1)
(set_attr mode MODE)])
The problem is blendpd takes 0 to 15 as immediate operand. The problem
is hidden in testsuite due to MAEK defined in sse4_1-check.h.
--
Summary: [4.4 Regression] Incorrect contraint on
sse4_1_blendpssemodesuffixf2c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35757
[Bug target/35757] [4.4 Regression] Incorrect contraint on sse4_1_blendpssemodesuffixf2c
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-29 16:09 --- It is introduced by revision 132518. -- hjl dot tools at gmail dot com changed: What|Removed |Added Known to fail||4.4.0 Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35757
[Bug libmudflap/35755] [4.4 Regression]: libmudflap.cth/pass39-frag.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-29 16:57 --- ... (rerun 16) ... this means the 16th invocation failed. This is just regular mudflap noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35755
[Bug c++/35641] [4.1 regression] ICE on overload of friend function definition inside a class
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-29 17:11
---
Here's a reduced testcase:
=
templateint struct A
{
friend void foo(const A)
{
__FUNCTION__;
}
};
inline void foo(const A0)
{
__FUNCTION__;
}
void bar()
{
foo(A0());
}
=
The bug is fixed since GCC 4.2.0, as the code is correctly rejected:
bug.cc: In instantiation of 'A0':
bug.cc:17: instantiated from here
bug.cc:4: error: redefinition of 'void foo(const A0)'
bug.cc:10: error: 'void foo(const A0)' previously defined here
On the 4.1 branch I still get an ICE, but after the above error message:
bug.cc: In instantiation of 'A0':
bug.cc:17: instantiated from here
bug.cc:4: error: redefinition of 'void foo(const A0)'
bug.cc:10: error: 'void foo(const A0)' previously defined here
bug.cc:4: internal compiler error: tree check: expected var_decl or
function_decl or type_decl or template_decl, have error_mark in
tsubst_friend_function, at cp/pt.c:5352
Please submit a full bug report, [etc.]
Since we already rejected the code with GCC 3.1 - 3.3.6 this is a regression.
I don't think anybody will fix this minor problem on the 4.1 branch, though.
Btw, the code was wrongly accepted by GCC 4.0.0 - 4.1.1.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||error-recovery, ice-on-
||invalid-code
Known to fail||3.4.0 3.4.6 4.0.0 4.1.2
Known to work||3.1 3.3.6
Last reconfirmed|-00-00 00:00:00 |2008-03-29 17:11:11
date||
Summary|ICE on overload of friend |[4.1 regression] ICE on
|function definition inside a|overload of friend function
|class |definition inside a class
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35641
[Bug c++/24602] g++: Internal error: Illegal instruction (program cc1plus)
--- Comment #11 from reichelt at gcc dot gnu dot org 2008-03-29 17:32 --- *** Bug 35596 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||kevin at kelphead dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24602
[Bug c++/35596] Runs out of virtual memory, with for_each
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-03-29 17:32 --- It's a duplicate of PR24602. *** This bug has been marked as a duplicate of 24602 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35596
[Bug c++/35578] [4.2/4.3/4.4 regression] Error about misplaced 'friend' word is issued on a wrong line
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-29 17:43 --- Confiremd. This happens since GCC 4.2.0. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||4.2.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2008-03-29 17:43:57 date|| Summary|Error about misplaced |[4.2/4.3/4.4 regression] |'friend' word is issued on a|Error about misplaced |wrong line |'friend' word is issued on a ||wrong line Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35578
[Bug c++/35578] [4.2/4.3/4.4 regression] Error about misplaced 'friend' word is issued on a wrong line
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-29 17:57 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-03-29 17:43:57 |2008-03-29 17:57:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35578
[Bug c++/35758] New: [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
The following testcase used to work in 4.1.1 but no longer does:
#define vector __attribute__((vector_size(16) ))
templateint INDEX
vector signed int MyFunction(vector float value) {}
templateint
void MyFunction(float ){}
int main()
{
vector float myVector;
float myFloat;
MyFunction1(myVector);
MyFunction1(myFloat);
}
CUT
We get:
vector14.C: In function int main():
vector14.C:12: error: no matching function for call to MyFunction(float
__vector__)
vector14.C:13: error: call of overloaded MyFunction(float) is ambiguous
vector14.C:3: note: candidates are: int MyFunction(float) [with int INDEX = 1]
vector14.C:6: note: void MyFunction(float) [with int
anonymous = 1]
--
Summary: [4.3/4.4 Regression] vector_size attribute lost in
function arguments for templates
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: blocker
Priority: P3
Component: c++
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=35758
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-29 18:45 --- This is caused by the delaying of vector_size attribute inside templates. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-29 18:46 --- This blocks me from even thinking about updating the PS3 toolchain to 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 18:47 --- This is related to PR 27433 and I bet fixing this one will also fix that one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-29 18:49 --- It worked with 4.3.0 20070623 and 4.2.0 20061019. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-29 18:55 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 Known to work||4.2.3 Last reconfirmed|-00-00 00:00:00 |2008-03-29 18:55:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug tree-optimization/30186] accessing an element via a pointer on a vector does not cause vec_extract to be used (non-zero index)
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 19:14 --- Created an attachment (id=15397) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15397action=view) Patch which should fix it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30186
[Bug c/35753] apparent integer math bug
--- Comment #3 from regehr at cs dot utah dot edu 2008-03-29 19:16 --- Subject: Re: apparent integer math bug This multiplication overflows so the resulting behavior is undefined. Right-- but always in the past it has been (or seemed) fine to assume two's complement overflow behavior for signed arithmetic under gcc on two's complement platforms. I have seen the strict overflow options and those seem quite reasonable. However, changing overflow behavior for multiply seems risky! Is it still reasonable at least to rely on two's complement behavior for signed addition and subtraction? Thanks, John Regehr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35753
Re: [Bug c/35753] apparent integer math bug
Sent from my iPhone On Mar 29, 2008, at 12:16, regehr at cs dot utah dot edu [EMAIL PROTECTED] wrote: --- Comment #3 from regehr at cs dot utah dot edu 2008-03-29 19:16 --- Subject: Re: apparent integer math bug This multiplication overflows so the resulting behavior is undefined. Right-- but always in the past it has been (or seemed) fine to assume two's complement overflow behavior for signed arithmetic under gcc on two's complement platforms. I have seen the strict overflow options and those seem quite reasonable. However, changing overflow behavior for multiply seems risky! Is it still reasonable at least to rely on two's complement behavior for signed addition and subtraction? It never was reasonable to depend on this behaviour, just GCC got better at optimizing these cases. We have had the option -fwrapv since at least 3.3 so that people can use that option if the want full wrapping behavior with signed types. Note the C standard is over 18 years old now so I had hoped people would still not making the mistake of thinking signed interger being wrapping types. Thanks, John Regehr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35753
[Bug c/35753] apparent integer math bug
--- Comment #4 from pinskia at gmail dot com 2008-03-29 19:27 --- Subject: Re: apparent integer math bug Sent from my iPhone On Mar 29, 2008, at 12:16, regehr at cs dot utah dot edu [EMAIL PROTECTED] wrote: --- Comment #3 from regehr at cs dot utah dot edu 2008-03-29 19:16 --- Subject: Re: apparent integer math bug This multiplication overflows so the resulting behavior is undefined. Right-- but always in the past it has been (or seemed) fine to assume two's complement overflow behavior for signed arithmetic under gcc on two's complement platforms. I have seen the strict overflow options and those seem quite reasonable. However, changing overflow behavior for multiply seems risky! Is it still reasonable at least to rely on two's complement behavior for signed addition and subtraction? It never was reasonable to depend on this behaviour, just GCC got better at optimizing these cases. We have had the option -fwrapv since at least 3.3 so that people can use that option if the want full wrapping behavior with signed types. Note the C standard is over 18 years old now so I had hoped people would still not making the mistake of thinking signed interger being wrapping types. Thanks, John Regehr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35753 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35753
[Bug c/35753] apparent integer math bug
--- Comment #5 from regehr at cs dot utah dot edu 2008-03-29 19:32 --- Subject: Re: apparent integer math bug wrapping behavior with signed types. Note the C standard is over 18 years old now so I had hoped people would still not making the mistake of thinking signed interger being wrapping types. 18 years old and still useless for writing real programs! John Regehr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35753
[Bug c/35430] [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 19:44 ---
This is the patch which I am testing:
Index: cp/typeck.c
===
--- cp/typeck.c (revision 133711)
+++ cp/typeck.c (working copy)
@@ -3917,6 +3917,10 @@ cp_build_binary_op (enum tree_code code,
int unsignedp0, unsignedp1;
tree primop0 = get_narrower (op0, unsignedp0);
tree primop1 = get_narrower (op1, unsignedp1);
+ tree undertype = result_type;
+
+ if (TREE_CODE (undertype) == COMPLEX_TYPE)
+ undertype = TREE_TYPE (undertype);
/* Check for comparison of different enum types. */
if (TREE_CODE (TREE_TYPE (orig_op0)) == ENUMERAL_TYPE
@@ -3937,7 +3941,7 @@ cp_build_binary_op (enum tree_code code,
/* Do not warn if the comparison is being done in a signed type,
since the signed type will only be chosen if it can represent
all the values of the unsigned type. */
- if (!TYPE_UNSIGNED (result_type))
+ if (!TYPE_UNSIGNED (undertype))
/* OK */;
/* Do not warn if both operands are unsigned. */
else if (op0_signed == op1_signed)
@@ -3955,10 +3959,10 @@ cp_build_binary_op (enum tree_code code,
else if ((resultcode == EQ_EXPR || resultcode == NE_EXPR)
((op0_signed TREE_CODE (orig_op1) == INTEGER_CST
int_fits_type_p (orig_op1, c_common_signed_type
- (result_type)))
+ (undertype)))
|| (op1_signed TREE_CODE (orig_op0) == INTEGER_CST
int_fits_type_p (orig_op0, c_common_signed_type
- (result_type)
+ (undertype)
/* OK */;
else if (complain tf_warning)
warning (OPT_Wsign_compare,
Index: c-typeck.c
===
--- c-typeck.c (revision 133711)
+++ c-typeck.c (working copy)
@@ -8483,6 +8483,9 @@ build_binary_op (enum tree_code code, tr
{
tree sop, uop;
bool ovf;
+ tree undertype = result_type;
+ if (TREE_CODE (undertype) == COMPLEX_TYPE)
+ undertype = TREE_TYPE (undertype);
if (op0_signed)
sop = xop0, uop = xop1;
@@ -8502,7 +8505,7 @@ build_binary_op (enum tree_code code, tr
else if (TREE_CODE (uop) == INTEGER_CST
(resultcode == EQ_EXPR || resultcode == NE_EXPR)
int_fits_type_p
- (uop, c_common_signed_type (result_type)))
+ (uop, c_common_signed_type (undertype)))
/* OK */;
/* Do not warn if the unsigned quantity is an enumeration
constant and its maximum value would fit in the result
@@ -8511,7 +8514,7 @@ build_binary_op (enum tree_code code, tr
TREE_CODE (TREE_TYPE (uop)) == ENUMERAL_TYPE
int_fits_type_p
(TYPE_MAX_VALUE (TREE_TYPE (uop)),
- c_common_signed_type (result_type)))
+ c_common_signed_type (undertype)))
/* OK */;
else
warning (OPT_Wsign_compare, comparison between signed and
unsigned);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35430
[Bug target/35713] [4.4 Regression] invalid type for va_arg with _Decimal128
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-29 20:17 --- This is caused by the extra type checking which Richard Guenther added. It is not just _Decimal128, but almost all types which are broken. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||ice-checking Last reconfirmed|-00-00 00:00:00 |2008-03-29 20:17:18 date|| Summary|invalid type for va_arg with|[4.4 Regression] invalid |_Decimal128 |type for va_arg with ||_Decimal128 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35713
[Bug c/35748] ICE with cast to invalid union
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-29 20:18 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-29 20:18:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35748
[Bug tree-optimization/35431] [4.1/4.2/4.3/4.4 regression] ICE with complex data in PRE
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-29 21:01 --- We have invalid gimple before PRE: k_7 = COMPLEX_EXPR (int) D.1197_2, 0; Which we don't catch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|[4.1/4.2/4.3/4.4 regression]|[4.1/4.2/4.3/4.4 regression] |ICE with complex data |ICE with complex data in PRE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35431
[Bug fortran/35759] New: WHERE with overlap with ELSEWHERE error
The following program computes the wrong result for a WHERE where different sections of the same array are in both the WHERE and ELSEWHERE section. It's as if the ELSEWHERE block were ignored. Dick Hendrickson program RG0023 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] integer UDA1L(6) integer :: UDA1R(6), expected(6) = (/2,0,5,0,3,0/) LOGICAL LDA(5) UDA1L(1:6) = 0 uda1r = (/1,2,3,4,5,6/) lda = (/ (i/2*2 .ne. I, i=1,5) /) WHERE (LDA)! expected UDA1L(1:5) = UDA1R(2:6) ! uda1l = 2,0,4,0,6,0 ELSEWHERE UDA1L(2:6) = UDA1R(6:2:-1) !uda1l = 2,0,5,0,3,0 ENDWHERE print *, 'expected = ',expected print *, 'computed = ', uda1l END gfortran:gfortran rg0023.f gfortran:a expected =2 0 5 0 3 0 computed =2 0 4 0 6 0 -- Summary: WHERE with overlap with ELSEWHERE error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35759
[Bug tree-optimization/35431] [4.1/4.2/4.3/4.4 regression] ICE with complex integer, invalid gimple
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-29 21:04 --- This is caused by PHI-opt, fixing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Summary|[4.1/4.2/4.3/4.4 regression]|[4.1/4.2/4.3/4.4 regression] |ICE with complex data in PRE|ICE with complex integer, ||invalid gimple http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35431
[Bug target/35757] [4.4 Regression] Incorrect contraint on sse4_1_blendpssemodesuffixf2c
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-29 21:12 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01848.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||03/msg01848.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35757
[Bug fortran/34128] slow gfortran 4.x (library?) compared to g77 3.4
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-03-29 21:19 --- I have submitted glibc PR http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997 With a C test case that clearly shows the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34128
[Bug target/35760] New: [4.4 Regression] ICE with complex types and -static on PPC darwin
While going to look into fixing PR 35314, I found this bug for PowerPC darwin.
A simple testcase:
int foo()
{
__complex__ float i = 0;
}
Will ICE in memory_address when we don't compile with PIC turned on.
t.c: In function 'foo':
t.c:3: internal compiler error: in memory_address, at explow.c:492
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: [4.4 Regression] ICE with complex types and -static on
PPC darwin
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
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=35760
[Bug target/35760] [4.4 Regression] ICE with complex types and -static on PPC darwin
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35760
[Bug libstdc++/35725] [4.3/4.4 Regression] ambiguous std::fill with character array
--- Comment #4 from paolo at gcc dot gnu dot org 2008-03-29 22:38 --- Subject: Bug 35725 Author: paolo Date: Sat Mar 29 22:38:19 2008 New Revision: 133721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133721 Log: 2008-03-29 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/35725 * include/bits/stl_algobase.h (__fill_a(_ForwardIterator, _ForwardIterator, _Tp), __fill_a(_Tp*, _Tp*, _Tp), __fill_n_a(_OutputIterator, _Size, _Tp), __fill_n_a(_Tp*, _Size, _Tp)): Fix signatures. * testsuite/25_algorithms/fill/35725.cc: New. * testsuite/25_algorithms/fill_n/35725.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/25_algorithms/fill/35725.cc trunk/libstdc++-v3/testsuite/25_algorithms/fill_n/35725.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algobase.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35725
[Bug libstdc++/35725] [4.3/4.4 Regression] ambiguous std::fill with character array
--- Comment #5 from paolo at gcc dot gnu dot org 2008-03-29 22:39 --- Subject: Bug 35725 Author: paolo Date: Sat Mar 29 22:38:36 2008 New Revision: 133722 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133722 Log: 2008-03-29 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/35725 * include/bits/stl_algobase.h (__fill_a(_ForwardIterator, _ForwardIterator, _Tp), __fill_a(_Tp*, _Tp*, _Tp), __fill_n_a(_OutputIterator, _Size, _Tp), __fill_n_a(_Tp*, _Size, _Tp)): Fix signatures. * testsuite/25_algorithms/fill/35725.cc: New. * testsuite/25_algorithms/fill_n/35725.cc: Likewise. Added: branches/gcc-4_3-branch/libstdc++-v3/testsuite/25_algorithms/fill/35725.cc branches/gcc-4_3-branch/libstdc++-v3/testsuite/25_algorithms/fill_n/35725.cc Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/include/bits/stl_algobase.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35725
[Bug libstdc++/35725] [4.3/4.4 Regression] ambiguous std::fill with character array
--- Comment #6 from pcarlini at suse dot de 2008-03-29 22:43 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35725
[Bug c/35761] New: GCC 4.3.0 tar 1.19 and glibc 2.7 bug with __cplusplus and -O2
I'm currently compiling my linux based of the Linux From Scratch SVN. I decided to try my hand at compiling with the gcc 4.3.0. The current bug im noticing has to do with the -O2 flag and __cplusplus. I have done a search through the bug database all most errors that I have seen have had __cplusplus in the part of the program that failed. One of the programs that I tried to compile was tar 1.18 and 1.19. It would not compile because of the -O2 flag, when I removed it from the config script and reconfigured it compiled fine. The same thing happened with the glibc and the problem was in the conftest which had a __cplusplus and a exception throw. With LFS the first part of the compiling process is to only comprile the C compiler part of gnu compiler yet im not sure why __cplusplus would be returning true if there is not a C++ compiler. -- Summary: GCC 4.3.0 tar 1.19 and glibc 2.7 bug with __cplusplus and -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: devilsclaw at devilsclaws dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35761
[Bug c/35761] GCC 4.3.0 tar 1.19 and glibc 2.7 bug with __cplusplus and -O2
--- Comment #1 from devilsclaw at devilsclaws dot net 2008-03-29 23:01 --- I also tried -O0 , -O1 , -O3 and -O4. The only one that worked as you would guess was -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35761
[Bug c/35761] GCC 4.3.0 tar 1.19 and glibc 2.7 bug with __cplusplus and -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-29 23:17 --- It certainly is not setting __cplusplus if you are not using C++. Other than that this is not a useful bugreport. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35761
[Bug fortran/35759] WHERE with overlap with ELSEWHERE error
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-29 23:23 ---
Confirm.
The algorithm below does essentially:
while (1,0,1,0,1)
uda1l( 1 _ 3 _ 5) = 2 3 4 5 6
else
udal1 ( _ 3 _ 5 _) = 6 5 4 3 2
done
That is
1. uda1l(1) = 2
2. uda1l(3) = 5 ---\__
3. uda1l(3) = 4 ---/
4. uda1l(5) = 3 ---\__
5. uda1l(6) = 4 ---/
The order is wrong. The procedure has to be:
1. Establish control mask (i.e. 1,0,1,0,1) and run WHERE
while (1,0,1,0,1)
uda1l( 1 _ 3 _ 5) = 2 3 4 5 6
end
2. Establish pending controlmask for ELSEWHERE (i.e. 0,1,0,1,0)
elsewhile (0,1,0,1)
uda1l( 1 _ 3 _ 5) = 2 3 4 5 6
end
{
static logical(kind=4) A.2[5] = {1, 0, 1, 0, 1};
static integer(kind=4) A.1[6] = {1, 2, 3, 4, 5, 6};
(void) __builtin_memset ((void *) uda1l, 0, 24);
(void) __builtin_memcpy ((void *) uda1r, (void *) A.1, 24);
(void) __builtin_memcpy ((void *) lda, (void *) A.2, 20);
{
integer(kind=8) S.3;
S.3 = 1;
while (1)
{
if (S.3 5) goto L.1;
if (lda[S.3 + -1])
{
uda1l[S.3 + -1] = uda1r[S.3];
}
else
{
uda1l[S.3] = uda1r[6 - S.3];
}
S.3 = S.3 + 1;
}
L.1:;
}
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2008-03-29 23:23:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35759
[Bug c++/35319] [4.3/4.4 regression] ICE throwing fixed-point types
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 00:20 --- This is most likely because there is no way to mangle fixed point types at all. So really I don't think this should be a P2 or marked as a regression until the ABI has been finialized -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 00:24 --- Confirmed. -- 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 |2008-03-30 00:24:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 00:30 --- Complex lowering is creating phi's with constant arguments on abnormal edges. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug c/35746] [4.3/4.4 regression] ICE with undefined variables
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 00:32 --- Confirmed. -- 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 |2008-03-30 00:32:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug c++/11859] Substitution failure incorrectly reported as error in SFINAE situation.
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-30 00:42 --- Fixed on mainline by Douglas' patch: 2008-03-25 Douglas Gregor [EMAIL PROTECTED] * typeck.c (composite_pointer_type_r): Add SFINAE support. ... -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11859
[Bug c/35746] [4.3/4.4 regression] ICE with undefined variables
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 00:50 --- So this was introduced by the gimplify_modify_expr changes. The C++ front-end actually produces error_mark_node for the call, maybe the C front-end should do the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug c++/35747] [4.3/4.4 regression] ICE with undefined variable in statement expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 00:52 --- Confirmed, only happens with the C++ front-end. -- 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 |2008-03-30 00:52:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35747
[Bug c/35736] [4.4 regression] ICE with continue and -Wall
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 00:57 --- This is a predict_expr tree. Shouldn't TREE_SIDE_EFFECTS be set on that expression? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-30 00:57:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35736
[Bug bootstrap/35216] Out of memory building java
--- Comment #1 from bugzilla-gcc at thewrittenword dot com 2008-03-30 02:24 --- Created an attachment (id=15398) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15398action=view) Patch for a generated file This patch allowed the build to complete for us, unfortunately Makefile.in is a generated file, as is sources.am, which is generated by makemake.tcl. We have not come up with a usable patch for makemake.tcl yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35216
[Bug c/35762] New: wrong code emitted for loop with volatile induction variable
This is for gcc version 4.3.0 (GCC)
This is similar to bug 35729. I'm filing a new report since the behavior seems
to be a different one.
This code:
volatile short g_10 = 0;
volatile int g_13 = 0;
int func_1 (void)
{
for (g_10 = 0; g_10 10; g_10++)
return g_13;
return 0;
}
When compiled with:
gcc -O1 -S foo.c
gives:
func_1:
pushl %ebp
movl%esp, %ebp
movw$0, g_10
movzwl g_10, %eax
cmpw$10, %ax
setle %al
movzbl %al, %eax
subl$1, %eax
andlg_13, %eax
popl%ebp
ret
The output is not correct, it unconditionally returns the value from g_13.
--
Summary: wrong code emitted for loop with volatile induction
variable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35762
[Bug libstdc++/35763] New: std::cout loses whole blocks of output if interrupted by signal without SA_RESTART
I noticed this when running a program that uses a periodic timer signal. The sigaction did not set SA_RESTART. During program runs, huge chunks of console output would disappear. I sort of tracked this down to the code in libstdc++ that uses fwrite to do the output of cout and cerr. That is a bit weird, I expected it to be using the basic_file operations on fd 0 instead. In summary, it appears to call fwrite and never check the error return, then it increments the streambuf pointers and loses that whole output block. -- Summary: std::cout loses whole blocks of output if interrupted by signal without SA_RESTART Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zlynx at acm dot org GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
[Bug libstdc++/35763] std::cout loses whole blocks of output if interrupted by signal without SA_RESTART
--- Comment #1 from zlynx at acm dot org 2008-03-30 03:43 --- Forgot to mention, I filed a bug for fwrite too: http://sources.redhat.com/bugzilla/show_bug.cgi?id=5998 Until they fix that (if they do) it will be useless to check fwrite's return value since you can't know how many bytes were written. I think the fix would be to use write directly or to use the file operations (which do seem to use write directly and check for EINTR returns) on fd 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
[Bug libstdc++/35763] std::cout loses whole blocks of output if interrupted by signal without SA_RESTART
--- Comment #2 from zlynx at acm dot org 2008-03-30 03:46 --- Created an attachment (id=15399) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15399action=view) test program, build: g++ timer-test.cc -lrt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
[Bug c/35764] New: improper load from volatile
This is for gcc version 4.3.0 (GCC)
This is very likely related to 35729 and 35762.
This code:
extern int bar (void);
volatile int g_156;
int foo (void)
{
if (bar ())
return 0;
else
return g_156;
}
Compiled with:
gcc -O1 -S foo.c
Gives:
foo:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
callbar
cmpl$1, %eax
sbbl%eax, %eax
andlg_156, %eax
leave
ret
The unconditional load from volatile g_156 is incorrect.
--
Summary: improper load from volatile
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35764
