[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #2 from thomas at reactsoft dot com 2006-09-01 07:10 ---
We also have severe problems with GCC4.1.1 which generates wrong machine code
on i386 when there's a (volatile) structure with __attribute__((aligned (16)))
on the stack. If the code is not very complex, the alignment works flawlessly.
But as soon as the code becomes complex, GCC screwes the alignment (and even
accesses variables that don't exist (I'll go into detail later).
Basically code like this is affected (this is *NOT* a test case, I'm going to
post a test case as soon as I get it to work):
typedef struct _somestruct {
int a;
};
static void checkstruct (volatile struct _somestruct *palignedvar)
{
if ((size_t)palignedvar & 0xF)
printf("structure misaligned!\n");
}
void somefunc(int a, int b, int c) {
__attribute__((aligned (16))) volatile struct _somestruct alignedvar;
while (1)
/* [other code] */
if (a) {
if (c) {
/* [other code] */
alignedvar.a = c;
checkstruct(&alignedvar);
} else {
/* [other code] */
break;
}
} else {
if (b) {
/* [other code] */
alignedvar.a = a;
checkstruct(&alignedvar);
} else {
if (c) {
break;
} else {
/* [other code] */
alignedvar.a = a;
checkstruct(&alignedvar);
}
}
/* [other code] */
}
}
I analyzed the generated assembly code. GCC reserves an area big enough to hold
the structure plus padding, so it can align the structure dynamically at
runtime. It stores a pointer to the reserved area and a pointer to the
structure within the area. As long as the code is simple, GCC uses the pointer
to the structure to access the data. However, if the code is complex enough,
GCC mistakenly uses the pointer to the reserved area - which of course is
sometimes not properly aligned. As a result, also the data of the structure
members are read/write incorrectly.
the stack is organized like this (the order may not match as showed in this
abstracted example):
struct {
void *reserved_area; /* this is the pointer GCC sometimes accidently
grabs */
void *aligned_structure; /* this is the pointer GCC should always grab */
char reserved[sizeof(structure) + sizeof(padding)];
};
I encountered this bug with -O3, I don't know if GCC also generates broken code
without optimizations. I tried to create a simple test case that triggers the
problem, but I failed last night. I'm going to do that this weekend. In the
meanwhile, you can find some real-world code that fails due to this bug:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/srw.c?revision=23806&view=markup
(see the ASSERT_SRW_WAITBLOCK macro).
--
thomas at reactsoft dot com changed:
What|Removed |Added
CC||thomas at reactsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug middle-end/28683] [4.0/4.1 regression] ICE (segfault in add_reg_br_prob_note) when comparing pointers with -O (and higher)
--- Comment #5 from jakub at gcc dot gnu dot org 2006-09-01 07:48 --- Subject: Bug 28683 Author: jakub Date: Fri Sep 1 07:48:22 2006 New Revision: 116620 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116620 Log: PR middle-end/28683 * cfgexpand.c (add_reg_br_prob_note): Check if last has exactly 3 following insns. * gcc.c-torture/compile/20060823-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/20060823-1.c - copied unchanged from r116467, trunk/gcc/testsuite/gcc.c-torture/compile/20060823-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cfgexpand.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28683
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #22 from paul dot richard dot thomas at cea dot fr 2006-09-01 08:11 --- Created an attachment (id=12166) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12166&action=view) A partial reversion to the previous method of type association. This regests OK on trunk and fixes the problems(regressions!) below. Sufficient of the original patch remains that the PRs that it was intended to fix remain fixed. My apologies to one and all for this struggle but the result has been an improved gfortran. HJ, you will see that in submitting to the list , I have required your green light before committing. If you have time today, I would be very grateful if you would test the patch, relative to trunk. Best regards Paul 2006-09-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28908 REGRESSION FIX * gfortran.h : Restore the gfc_dt_list structure and reference to it in gfc_namespace. * resolve.c (resolve_fl_derived): Restore the building of the list of derived types for the current namespace. * symbol.c (gfc_free_dt_list): Restore. (gfc_free_namespace): Restore call to previous. * trans-types.c (copy_dt_decls_ifequal): Restore. (gfc_get_derived_type): Restore all the paraphenalia for association of derived types, including calls to previous. 2006-09-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28908 * gfortran.dg/used_types_7.f90: New test. * gfortran.dg/used_types_8.f90: New test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #3 from thomas at reactsoft dot com 2006-09-01 08:05 --- (In reply to comment #2) > while (1) Please ignore that line... I forgot to delete it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug fortran/28916] Build of the head fails on Mac Intel
--- Comment #3 from federico dot carminati at cern dot ch 2006-09-01 08:18 --- Subject: Re: Build of the head fails on Mac Intel Hello, I am building the head version with the following script #!/bin/sh export CVS_RSH=ssh cvs -qz9 -d :pserver:[EMAIL PROTECTED]:/sources/gcc up -Pd rm -rf /opt/gcc-4_0/* [ -d build ] && (rm -rf build ; mkdir build) cd build ../configure --prefix=/opt/gcc-4_0 --with-gmp=/sw --enable- languages=fortran,c++ make 2>&1 | tee ../make.log make install 2>&1 | tee -a ../make.log with xcode 2.4 Best regards, Federico Carminati CERN-PH 1211 Geneva 23 Switzerland Tel: +41 22 76 74959 Fax: +41 22 76 79480 Mobile: +41 76 487 4843 On 1 Sep 2006, at 06:20, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-01 > 04:20 --- > Also what version of Xcode do you have installed? > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916
[Bug fortran/28916] Build of the head fails on Mac Intel
--- Comment #4 from federico dot carminati at cern dot ch 2006-09-01 08:23 --- Subject: Fwd: Build of the head fails on Mac Intel Federico Carminati CERN-PH 1211 Geneva 23 Switzerland Tel: +41 22 76 74959 Fax: +41 22 76 79480 Mobile: +41 76 487 4843 Begin forwarded message: > From: "federico dot carminati at cern dot ch" [EMAIL PROTECTED]> > Date: 1 September 2006 10:18:21 GMT+02:00 > To: [EMAIL PROTECTED] > Subject: [Bug fortran/28916] Build of the head fails on Mac Intel > Reply-To: [EMAIL PROTECTED] > > > > --- Comment #3 from federico dot carminati at cern dot ch > 2006-09-01 08:18 --- > Subject: Re: Build of the head fails on Mac Intel > > Hello, >I am building the head version with the following script > > #!/bin/sh > export CVS_RSH=ssh > cvs -qz9 -d :pserver:[EMAIL PROTECTED]:/sources/gcc up -Pd > rm -rf /opt/gcc-4_0/* > [ -d build ] && (rm -rf build ; mkdir build) > cd build > ../configure --prefix=/opt/gcc-4_0 --with-gmp=/sw --enable- > languages=fortran,c++ > make 2>&1 | tee ../make.log > make install 2>&1 | tee -a ../make.log > > > with xcode 2.4 > > > > > Best regards, > > Federico Carminati > CERN-PH > 1211 Geneva 23 > Switzerland > Tel: +41 22 76 74959 > Fax: +41 22 76 79480 > Mobile: +41 76 487 4843 > > On 1 Sep 2006, at 06:20, pinskia at gcc dot gnu dot org wrote: > >> >> >> --- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-01 >> 04:20 --- >> Also what version of Xcode do you have installed? >> >> >> -- >> >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916 >> >> --- You are receiving this mail because: --- >> You reported the bug, or are watching the reporter. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916
[Bug fortran/28923] New: Bad triplet interpretation in initialization
The following program: real, dimension(3,3), parameter :: a=reshape ((/(i, i = 1,9)/),(/3,3/)) real, dimension(2,3) :: b=a(:2:-1,:) real, dimension(2,3) :: c=a(3:2:-1,:) print *, b print *, c end compiles with gfortran and gives: 3.00 2.00 6.00 5.00 9.00 8.00 3.00 2.00 6.00 5.00 9.00 8.00 i.e., b=a(:2:-1,:) is interpreted as c=a(3:2:-1,:) instead of giving: real, dimension(2,3) :: b=a(:2:-1,:) 1 Error: Array assignment at (1) has different sizes (6/0) as required by the following first and last paragraphs (draft f2003): > 6.2.2.3.1 Subscript triplet > > A subscript triplet designates a regular sequence of subscripts > consisting of zero or more subscript values. The third expression in the > subscript triplet is the increment between the subscript values and is > called the stride. The subscripts and stride of a subscript triplet are > optional. An omitted first subscript in a subscript triplet is > equivalent to a subscript whose value is the lower bound for the array > and an omitted second subscript is equivalent to the upper bound. An > omitted stride is equivalent to a stride of 1. > > The stride shall not be zero. > > When the stride is positive, the subscripts specified by a triplet form a > regularly spaced sequence of integers beginning with the first subscript > and proceeding in increments of the stride to the largest such integer > not greater than the second subscript; the sequence is empty if the first > subscript is greater than the second. > > ... > > When the stride is negative, the sequence begins with the first subscript > and proceeds in increments of the stride down to the smallest such > integer equal to or greater than the second subscript; the sequence is > empty if the second subscript is greater than the first. Note that: real, dimension(3,3) :: a real, dimension(2,3) :: b a=1 b=a(:2:-1,:) print *, b end gives correctly: b=a(:2:-1,:) 1 Error: different shape for Array assignment at (1) on dimension 1 (2/0) Dominique -- Summary: Bad triplet interpretation in initialization Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: gcc version 4.2.0 20060826 (experimental) GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28923
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #23 from patchapp at dberlin dot org 2006-09-01 09:10 --- Subject: Bug number PR28908 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/2006-09/msg8.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug target/28909] Missed optimization with x86 sync builtins
--- Comment #2 from uros at kss-loka dot si 2006-09-01 10:18 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00010.html -- uros at kss-loka dot si changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00010.html Status|NEW |ASSIGNED Last reconfirmed|2006-08-31 03:13:03 |2006-09-01 10:18:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28909
[Bug target/28924] New: x86 sync builtins fail for char and short memory operands
Following testcases ICEs with current mainline:
--cut here--
char c;
void testc(void)
{
(void) __sync_fetch_and_add(&c, -1);
}
short s;
void tests(void)
{
(void) __sync_fetch_and_add(&s, -1);
}
--cut here--
inc.c: In function âtestsâ:
inc.c:13: error: unrecognizable insn:
(insn 10 8 11 3 (set (reg:HI 58)
(const_int 65535 [0x])) -1 (nil)
(nil))
inc.c:13: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
and:
inc.c: In function âtestcâ:
inc.c:6: error: unrecognizable insn:
(insn 7 5 8 3 (set (reg:QI 58)
(const_int 255 [0xff])) -1 (nil)
(nil))
inc.c:6: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
ICE happens for all optimization levels, also for unsigned c and s variables. I
have checked _sync_fetch_and_add() and _sync_fetch_and_sub() builtins, but due
to the nature of error all other sync_* builtins may be affected.
--
Summary: x86 sync builtins fail for char and short memory
operands
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
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=28924
[Bug c++/28878] [4.0/4.1/4.2 regression] ICE using "[" instead of "{"
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-08-28 23:46:22 |2006-09-01 10:59:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28878
[Bug rtl-optimization/28925] New: problem with zero_extract during gcse
I have a problem with 4.1 on m68k-linux, which miscompiles the following
test case during the gcse pass:
struct b {
unsigned a : 1;
unsigned b : 1;
unsigned c : 1;
unsigned d : 1;
};
unsigned int x = 1;
void f(int y, struct b *p)
{
switch (y) {
case 1:
p->a = 0;
p->b = 0;
break;
case 3:
p->a = 0;
p->b = 1;
break;
default:
return;
}
p->c = x;
p->d = 1;
}
The assignment to p->c is done via zero_extract:
(insn 46 45 48 5 (set (zero_extract:SI (mem/s/j:QI (reg/v/f:SI 31 [ p ]) [0 S1
A8])
(const_int 1 [0x1])
(const_int 2 [0x2]))
(reg:SI 40 [ x ])) 278 {*m68k.md:4815} (nil)
(nil))
The other assignments are done with (and) and (ior). When propagating the
mem expression, gcse misses this assignment and the assignment to p->d
overwrites it, because the earlier mem expression was propagated past it
in a register.
Currently I'm using the attached patch, which simply invalidates the
load/store. Now I need some help from someone, who is more familiar with
this code, whether this is the correct approach.
It would be nice if above could be changed into (zero_extract:SI (reg)),
but I guess that would be a little too complex.
--
Summary: problem with zero_extract during gcse
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zippel at linux-m68k dot org
GCC target triplet: m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28925
[Bug rtl-optimization/28925] problem with zero_extract during gcse
--- Comment #1 from zippel at linux-m68k dot org 2006-09-01 11:39 --- Created an attachment (id=12167) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12167&action=view) possible fix for gcse problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28925
[Bug libgomp/28926] New: FAIL: libgomp.c/ordered-1.c execution test
libgomp.c/ordered-1.c and libgomp.c/ordered-3.c currently timeouts on my system (RedHat 8.0 with 2.4.18-14, i686) due to unimplemented FUTEX syscall. strace of produced binary shows endless lines of "Function not implemented" lines. This is the beginning: rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 write(4, "[EMAIL PROTECTED]@[EMAIL PROTECTED]@\340\370\377\277\0\0\0"..., 148) = 148 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 rt_sigsuspend([] --- SIGRTMIN (Real-time signal 0) --- <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) sigreturn() = ? (mask now [RTMIN]) futex(0x40019458, FUTEX_WAIT, 0, NULL) = -1 ENOSYS (Function not implemented) futex(0x40019458, FUTEX_WAIT, 0, NULL) = -1 ENOSYS (Function not implemented) futex(0x40019458, FUTEX_WAIT, 0, NULL) = -1 ENOSYS (Function not implemented) futex(0x40019458, FUTEX_WAIT, 0, NULL) = -1 ENOSYS (Function not implemented) futex(0x40019458, FUTEX_WAIT, 0, NULL) = -1 ENOSYS (Function not implemented) futex(0x40019458, FUTEX_WAIT, 0, NULL) = -1 ENOSYS (Function not implemented) ... Breaking execution in the middle produces following backtrace: Program received signal SIGINT, Interrupt. [Switching to Thread 8192 (LWP 5941)] 0x40017c83 in gomp_sem_wait_slow (sem=0x804b09c) at ../../../gcc-svn/trunk/libgomp/config/linux/x86/futex.h:73 in ../../../gcc-svn/trunk/libgomp/config/linux/x86/futex.h (gdb) bt #0 0x40017c83 in gomp_sem_wait_slow (sem=0x804b09c) at ../../../gcc-svn/trunk/libgomp/config/linux/x86/futex.h:73 #1 0x400167ce in gomp_ordered_sync () at ../../../gcc-svn/trunk/libgomp/config/linux/sem.h:46 #2 0x40016412 in gomp_loop_ordered_static_next (istart=0xb8e8, iend=0xb8e4) at ../../../gcc-svn/trunk/libgomp/loop.c:307 #3 0x08048b45 in f_static_1 (dummy=0x0) at ordered-1.c:72 -- Summary: FAIL: libgomp.c/ordered-1.c execution test Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uros at kss-loka dot si 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=28926
[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-09-01 13:45 --- (In reply to comment #3) > Setting the parameter n=65535, the program appears to execute correctly. > However, the pr28914.f90.003t.original file is 706800 bytes long and embedded > with a very large static declaration of the array. As if it has been inlined. > With n=66536, the dump file is 4436 bytes long and has code to initialize the > array with a loop. That looping code appears broken. The looping code, of itself, is not broken. If one of the 'i's, say in the implied do-loop, is changed to 'j', the code runs to completion. The problem is that the implied do-loop counter uses a variable declaration and so a symbol. This clashes with the variable i. Since do-loops can run with +ve or -ve steps, the end condition is enforced through: L.1:; D.931 = i == 1; i = i + 1; if (D.931) goto L.2; else (void) 0; ie. with an equality. The implied do-loop sets this larger than 1 so the loop never stops. For n < 65536, the loop is simplified out of existence and the large static array makes its appearance. This seems to be an undesirable consequence of treating array initializers and array constructors with the same limit. I would: (i) Change the size limit for simplification of array constructors; and (ii) Store the current value of the loop counter in a temporary and restore it after the array constructor has done its thing (patch follows). Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
[Bug c++/23287] [4.0/4.1/4.2 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #11 from nathan at gcc dot gnu dot org 2006-09-01 13:46 --- Subject: Bug 23287 Author: nathan Date: Fri Sep 1 13:46:19 2006 New Revision: 116623 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116623 Log: cp/ PR c++/23287 * parser.c (cp_parser_id_expression): Add member_p argument. Update all callers. (cp_parser_unqualified_id): Likewise. Lookup a destructor name in the object's scope, if valid. (cp_parser_global_scope_opt): Add object_scope_valid_p. Update callers. (cp_parser_postfix_dot_deref_expression): Set object_scope. * pt.c (tsubst_copy_and_build): Lookup dependent dtor name here. testsuite/ PR c++/23287 * g++.dg/parse/dtor12.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/dtor12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-09-01 13:48 --- Created an attachment (id=12168) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12168&action=view) A provisional fix for the problem This is not regtested. Also, I know that there is a better way to detect a declared variable; however, I am up to my eyeballs getting TR15541 out of the door... wait a few days, I will sort this one. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
[Bug c++/23287] [4.0/4.1/4.2 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #12 from nathan at gcc dot gnu dot org 2006-09-01 13:49 --- 2006-09-01 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/23287 * parser.c (cp_parser_id_expression): Add member_p argument. Update all callers. (cp_parser_unqualified_id): Likewise. Lookup a destructor name in the object's scope, if valid. (cp_parser_global_scope_opt): Add object_scope_valid_p. Update callers. (cp_parser_postfix_dot_deref_expression): Set object_scope. * pt.c (tsubst_copy_and_build): Lookup dependent dtor name here. -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug target/28924] x86 sync builtins fail for char and short memory operands
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-01 14:39 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code Known to fail||4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-01 14:39:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug c++/28899] [/4.2 regression] gimplification failed
-- 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|NEW |ASSIGNED Last reconfirmed|2006-08-30 13:00:58 |2006-09-01 14:51:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #24 from pault at gcc dot gnu dot org 2006-09-01 15:32 --- Fix posted - I await your goahead, HJ. 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-01 15:32:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug c++/28878] [4.0/4.1/4.2 regression] ICE using "[" instead of "{"
--- Comment #2 from patchapp at dberlin dot org 2006-09-01 15:44 --- Subject: Bug number PR c++/28878 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/2006-09/msg00014.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28878
[Bug target/28909] Missed optimization with x86 sync builtins
--- Comment #3 from patchapp at dberlin dot org 2006-09-01 15:45 --- Subject: Bug number PR target/28909 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/2006-09/msg00010.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28909
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #43 from sayle at gcc dot gnu dot org 2006-09-01 15:47 --- Subject: Bug 22313 Author: sayle Date: Fri Sep 1 15:47:29 2006 New Revision: 116628 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116628 Log: PR other/22313 * dwarf2out.c (add_fde_cfi): Use a set_loc if the current label is NULL, otherwise use an advance_loc4 to adjust relative to the current label. (output_cfi) : Update the current label. (dwarf2out_switch_text_section): Reset the current label to avoid using advance_loc4 over section boundaries. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #25 from hjl at lucon dot org 2006-09-01 15:47 --- I am not sure if the patch is correct. I got [EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.2/bin/gfortran -c -o module_integrate.fppized.o -I. -I./netcdf/include -O2 -ffast-math -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG -DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4module_integrate.fppized.f90 gfortran: Internal error: Segmentation fault (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #26 from hjl at lucon dot org 2006-09-01 16:10 --- Here is a testcase: [EMAIL PROTECTED] wrf-1]$ cat bad.f90 module bar implicit none public type domain_ptr type(domain), POINTER :: ptr end type domain_ptr type domain TYPE(domain_ptr) , DIMENSION( : ) , POINTER :: parents TYPE(domain_ptr) , DIMENSION( : ) , POINTER :: nests end type domain end module bar module foo contains recursive subroutine integrate (grid) use bar implicit none type(domain), POINTER :: grid interface subroutine solve_interface (grid) use bar TYPE (domain) grid end subroutine solve_interface end interface end subroutine integrate end module foo [EMAIL PROTECTED] wrf-1]$ make bad.s /usr/gcc-4.2/bin/gfortran -S -o bad.s bad.f90 gfortran: Internal error: Segmentation fault (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [bad.s] Error 1 [EMAIL PROTECTED] wrf-1]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug libgcj/28698] [gcj] libgcj-bc only used when building shared libs, not executables
--- Comment #10 from tromey at gcc dot gnu dot org 2006-09-01 16:16 --- Subject: Bug 28698 Author: tromey Date: Fri Sep 1 16:16:15 2006 New Revision: 116631 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116631 Log: PR libgcj/28698: * libgcj_bc.c (DECLARE_PRIM_TYPE): New macro. Declare primitive classes. boehm-gc PR libgcj/13212: * configure.ac: Check for pthread_getattr_np(). Remove GC_PTHREAD_SYM_VERSION detection. * include/gc.h (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New declarations. * pthread_support.c (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New functions. (GC_delete_thread): Don't try to free the first_thread. * misc.c (GC_init_inner): Use GC_get_thread_stack_base() if possible. (pthread_create_, constr): Removed. (pthread_create): Don't rename. * include/gc_ext_config.h.in: Rebuilt. * include/gc_pthread_redirects.h (pthread_create): Define unconditionally. * include/gc_config.h.in: Rebuilt. * configure: Rebuilt. libjava * java/lang/natThread.cc (_Jv_AttachCurrentThread): Attach thread to GC. (_Jv_DetachCurrentThread): Detach thread from GC. * include/boehm-gc.h (_Jv_GCAttachThread, _Jv_GCDetachThread): Declare. * boehm.cc (_Jv_GCAttachThread): New function. (_Jv_GCDetachThread): Likewise. gcc/java/ChangeLog * jvspec.c (lang_specific_driver): Add -s-bc-abi when needed. libjava/ChangeLog * configure, Makefile.in: Rebuilt. * Makefile.am (toolexeclib_LTLIBRARIES): Add libgcj_bc.la. (libgcj_bc_la_SOURCES): New variable. (libgcj_bc_la_LDFLAGS): Likewise. (libgcj_bc_la_LIBADD): Likewise. (libgcj_bc_la_DEPENDENCIES): Likewise. (libgcj_bc_la_LINK): Likewise. (libgcj_bc_dummy_LINK): Likewise. (libgcj_bc.la): New target. (install-exec-hook): Likewise. * libgcj.spec.in (*lib): Use LIBGCJ_SPEC. * libgcj_bc.c: New file. * configure.ac (LIBGCJ_SPEC): New subst. * configure.host (use_libgcj_bc): New variable. Added: branches/gcj-eclipse/libjava/libgcj_bc.c - copied, changed from r116204, trunk/libjava/libgcj_bc.c Modified: branches/gcj-eclipse/boehm-gc/ChangeLog branches/gcj-eclipse/boehm-gc/configure branches/gcj-eclipse/boehm-gc/configure.ac branches/gcj-eclipse/boehm-gc/dyn_load.c branches/gcj-eclipse/boehm-gc/include/gc.h branches/gcj-eclipse/boehm-gc/include/gc_config.h.in branches/gcj-eclipse/boehm-gc/include/gc_ext_config.h.in branches/gcj-eclipse/boehm-gc/include/gc_pthread_redirects.h branches/gcj-eclipse/boehm-gc/include/private/pthread_support.h branches/gcj-eclipse/boehm-gc/misc.c branches/gcj-eclipse/boehm-gc/os_dep.c branches/gcj-eclipse/boehm-gc/pthread_stop_world.c branches/gcj-eclipse/boehm-gc/pthread_support.c branches/gcj-eclipse/gcc/java/ChangeLog branches/gcj-eclipse/gcc/java/jvspec.c branches/gcj-eclipse/libjava/ChangeLog branches/gcj-eclipse/libjava/Makefile.am branches/gcj-eclipse/libjava/Makefile.in branches/gcj-eclipse/libjava/boehm.cc branches/gcj-eclipse/libjava/configure branches/gcj-eclipse/libjava/configure.ac branches/gcj-eclipse/libjava/configure.host branches/gcj-eclipse/libjava/gcj/Makefile.in branches/gcj-eclipse/libjava/include/Makefile.in branches/gcj-eclipse/libjava/include/boehm-gc.h branches/gcj-eclipse/libjava/java/lang/natThread.cc branches/gcj-eclipse/libjava/libgcj.spec.in branches/gcj-eclipse/libjava/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28698
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #38 from tromey at gcc dot gnu dot org 2006-09-01 16:16 --- Subject: Bug 13212 Author: tromey Date: Fri Sep 1 16:16:15 2006 New Revision: 116631 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116631 Log: PR libgcj/28698: * libgcj_bc.c (DECLARE_PRIM_TYPE): New macro. Declare primitive classes. boehm-gc PR libgcj/13212: * configure.ac: Check for pthread_getattr_np(). Remove GC_PTHREAD_SYM_VERSION detection. * include/gc.h (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New declarations. * pthread_support.c (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New functions. (GC_delete_thread): Don't try to free the first_thread. * misc.c (GC_init_inner): Use GC_get_thread_stack_base() if possible. (pthread_create_, constr): Removed. (pthread_create): Don't rename. * include/gc_ext_config.h.in: Rebuilt. * include/gc_pthread_redirects.h (pthread_create): Define unconditionally. * include/gc_config.h.in: Rebuilt. * configure: Rebuilt. libjava * java/lang/natThread.cc (_Jv_AttachCurrentThread): Attach thread to GC. (_Jv_DetachCurrentThread): Detach thread from GC. * include/boehm-gc.h (_Jv_GCAttachThread, _Jv_GCDetachThread): Declare. * boehm.cc (_Jv_GCAttachThread): New function. (_Jv_GCDetachThread): Likewise. gcc/java/ChangeLog * jvspec.c (lang_specific_driver): Add -s-bc-abi when needed. libjava/ChangeLog * configure, Makefile.in: Rebuilt. * Makefile.am (toolexeclib_LTLIBRARIES): Add libgcj_bc.la. (libgcj_bc_la_SOURCES): New variable. (libgcj_bc_la_LDFLAGS): Likewise. (libgcj_bc_la_LIBADD): Likewise. (libgcj_bc_la_DEPENDENCIES): Likewise. (libgcj_bc_la_LINK): Likewise. (libgcj_bc_dummy_LINK): Likewise. (libgcj_bc.la): New target. (install-exec-hook): Likewise. * libgcj.spec.in (*lib): Use LIBGCJ_SPEC. * libgcj_bc.c: New file. * configure.ac (LIBGCJ_SPEC): New subst. * configure.host (use_libgcj_bc): New variable. Added: branches/gcj-eclipse/libjava/libgcj_bc.c - copied, changed from r116204, trunk/libjava/libgcj_bc.c Modified: branches/gcj-eclipse/boehm-gc/ChangeLog branches/gcj-eclipse/boehm-gc/configure branches/gcj-eclipse/boehm-gc/configure.ac branches/gcj-eclipse/boehm-gc/dyn_load.c branches/gcj-eclipse/boehm-gc/include/gc.h branches/gcj-eclipse/boehm-gc/include/gc_config.h.in branches/gcj-eclipse/boehm-gc/include/gc_ext_config.h.in branches/gcj-eclipse/boehm-gc/include/gc_pthread_redirects.h branches/gcj-eclipse/boehm-gc/include/private/pthread_support.h branches/gcj-eclipse/boehm-gc/misc.c branches/gcj-eclipse/boehm-gc/os_dep.c branches/gcj-eclipse/boehm-gc/pthread_stop_world.c branches/gcj-eclipse/boehm-gc/pthread_support.c branches/gcj-eclipse/gcc/java/ChangeLog branches/gcj-eclipse/gcc/java/jvspec.c branches/gcj-eclipse/libjava/ChangeLog branches/gcj-eclipse/libjava/Makefile.am branches/gcj-eclipse/libjava/Makefile.in branches/gcj-eclipse/libjava/boehm.cc branches/gcj-eclipse/libjava/configure branches/gcj-eclipse/libjava/configure.ac branches/gcj-eclipse/libjava/configure.host branches/gcj-eclipse/libjava/gcj/Makefile.in branches/gcj-eclipse/libjava/include/Makefile.in branches/gcj-eclipse/libjava/include/boehm-gc.h branches/gcj-eclipse/libjava/java/lang/natThread.cc branches/gcj-eclipse/libjava/libgcj.spec.in branches/gcj-eclipse/libjava/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-20 21:23:19 |2006-09-01 16:55:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug middle-end/27226] [4.1/4.2 Regression] Compiler looses track of alignment for emit_block_move
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Compiler looses track of|[4.1/4.2 Regression] |alignment for |Compiler looses track of |emit_block_move |alignment for ||emit_block_move Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #19 from jconner at gcc dot gnu dot org 2006-09-01 16:56 --- Subject: Bug 25505 Author: jconner Date: Fri Sep 1 16:56:14 2006 New Revision: 116633 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116633 Log: 2006-09-01 Josh Conner <[EMAIL PROTECTED]> PR c++/25505 * tree-nrv.c (dest_safe_for_nrv_p): New function. (execute_return_slot_opt): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-nrv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #20 from jconner at gcc dot gnu dot org 2006-09-01 16:56 --- Subject: Bug 25505 Author: jconner Date: Fri Sep 1 16:56:45 2006 New Revision: 116634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116634 Log: 2006-09-01 Josh Conner <[EMAIL PROTECTED]> PR c++/25505 gcc.dg/nrv3.c: New test. gcc.dg/nrv4.c: New test. gcc.dg/nrv5.c: New test. Added: trunk/gcc/testsuite/gcc.dg/nrv3.c trunk/gcc/testsuite/gcc.dg/nrv4.c trunk/gcc/testsuite/gcc.dg/nrv5.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #27 from paulthomas2 at wanadoo dot fr 2006-09-01 17:24 --- Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator HJ, I might be slow but I get there... what has been plaguing me all week is doing the development under Cygwin. I just realised that NONE of the failing cases that you have presented this week fail on Cygwin. It is only when I return to the ranch that I can reproduce what you are seeing; this goes for the business the other night - the portbale is running Cygwin because the b***y wireless card will not run with Linux/ndiswrapper, no matter what I do. Anyway, I agree that your latest shows that there is still a problem and will revert still further. Thanks and apologies about being so long winded about this - I am blowed if I am going to revert so far that I do not fix the two original bugs. *sigh* Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #28 from hjl at lucon dot org 2006-09-01 17:34 --- If you are using Intel Centrino notebook, there is an open source driver for wireless from Intel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug libfortran/23889] behaviour of random_seed()
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-01 17:37 --- I think this should just be closed and leave gfortran as is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
[Bug c++/28899] [4.2 regression] gimplification failed
--- Comment #8 from jason at gcc dot gnu dot org 2006-09-01 17:59 --- Subject: Bug 28899 Author: jason Date: Fri Sep 1 17:59:41 2006 New Revision: 116637 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116637 Log: PR c++/28899 * gimplify.c (gimplify_modify_expr_rhs) [BIND_EXPR]: Handle want_value. * gimplify.c (voidify_wrapper_expr): Handle null type. Added: trunk/gcc/testsuite/g++.dg/ext/stmtexpr9.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
[Bug c++/28899] [4.2 regression] gimplification failed
--- Comment #9 from jason at gcc dot gnu dot org 2006-09-01 18:00 --- fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
[Bug c++/28705] [4.0/4.1/4.2 Regression] ICE: in type_dependent_expression_p, at cp/pt.c:12837
--- Comment #3 from nathan at gcc dot gnu dot org 2006-09-01 18:10 --- 2006-09-01 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/28705 * semantics.c (finish_call_expr): Add assert. * name-lookup.c (lookup_arg_dependent): Check we found an overload or an object. --- Comment #4 from nathan at gcc dot gnu dot org 2006-09-01 18:10 --- Subject: Bug 28705 Author: nathan Date: Fri Sep 1 18:10:17 2006 New Revision: 116638 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116638 Log: cp/ PR c++/28705 * semantics.c (finish_call_expr): Add assert. * name-lookup.c (lookup_arg_dependent): Check we found an overload or an object. testsuite/ PR c++/28705 * g++.dg/lookup/koenig5.C: New. * g++.dg/template/crash56.C: New. Added: trunk/gcc/testsuite/g++.dg/lookup/koenig5.C trunk/gcc/testsuite/g++.dg/template/crash56.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28705
[Bug c++/28705] [4.0/4.1/4.2 Regression] ICE: in type_dependent_expression_p, at cp/pt.c:12837
--- Comment #3 from nathan at gcc dot gnu dot org 2006-09-01 18:10 --- 2006-09-01 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/28705 * semantics.c (finish_call_expr): Add assert. * name-lookup.c (lookup_arg_dependent): Check we found an overload or an object. --- Comment #4 from nathan at gcc dot gnu dot org 2006-09-01 18:10 --- Subject: Bug 28705 Author: nathan Date: Fri Sep 1 18:10:17 2006 New Revision: 116638 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116638 Log: cp/ PR c++/28705 * semantics.c (finish_call_expr): Add assert. * name-lookup.c (lookup_arg_dependent): Check we found an overload or an object. testsuite/ PR c++/28705 * g++.dg/lookup/koenig5.C: New. * g++.dg/template/crash56.C: New. Added: trunk/gcc/testsuite/g++.dg/lookup/koenig5.C trunk/gcc/testsuite/g++.dg/template/crash56.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28705
[Bug middle-end/28911] Cross compiler build for m68k--elf fails on x86_64-linux-gnu
--- Comment #5 from kazu at gcc dot gnu dot org 2006-09-01 18:38 --- Reproduced. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-01 18:38:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
[Bug middle-end/28911] Cross compiler build for m68k--elf fails on x86_64-linux-gnu
-- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
[Bug fortran/25403] gfortran run-time error with multiple tabs in format continuation
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-09-01 19:14 --- Current gfortran is handling this correctly -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25403
[Bug fortran/25403] gfortran run-time error with multiple tabs in format continuation
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-01 19:16 --- I am looking into this a little. setWunused is called which calls SetWextras. Just a little tweaking we need to do here I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25403
[Bug middle-end/28911] Cross compiler build for m68k--elf fails on x86_64-linux-gnu
--- Comment #6 from kazu at gcc dot gnu dot org 2006-09-01 19:17 ---
Reduced down to:
/* m68k-none-elf-gcc -O2 -m68000 */
_Complex float
foo (float a)
{
return __builtin_copysign (a != a, a);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
[Bug c/28930] New: [4.2.0] regression
During the build of glibc (2.3.6) there is a file (csu/initfini.c) that has several asm statements. After compiling, the resulting asm file will be the source of some sed scripts that generates crti.S and crtn.S. Using gcc-trunk snapshot from 20060828, and gcc-4.0.2, the generated files initfini.s differs to a point that the sed scripts gets totaly lost. Attached is initfini.i, the file generated by 4.0.2 (initfini.s) (which is what sed scripts expects), and the file generated with gcc-trunk (initfini-BAD.s) Both compilers in question were configured with: --target=powerpc-unkown-linux-gnuspe --enable-e500_double The initfini.s file is obtained with: gcc -g -g0 -fpic -finhibit-size-directive -fno-exceptions -O1 -S initfini.i -- Summary: [4.2.0] regression Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edmar at freescale dot com GCC host triplet: powerpc-unknown-linux-gnuspe GCC target triplet: powerpc-unknown-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28930
[Bug fortran/25403] gfortran run-time error with multiple tabs in format continuation
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-01 19:34 --- oops disregard that last comment. Typed in the wrong box. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25403
[Bug c/28930] [4.2.0] regression
--- Comment #1 from edmar at freescale dot com 2006-09-01 19:35 --- Created an attachment (id=12171) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12171&action=view) Input file Input file generated with --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28930
[Bug c/28930] [4.2.0] regression
--- Comment #2 from edmar at freescale dot com 2006-09-01 19:37 --- Created an attachment (id=12172) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12172&action=view) What glibc scripts expect Input file processed with gcc-4.0.2 That is what glibc sed scripts expect -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28930
[Bug c/28930] [4.2.0] regression
--- Comment #3 from edmar at freescale dot com 2006-09-01 19:38 --- Created an attachment (id=12173) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12173&action=view) What gcc-trunk 20060828 generates Input file processed with gcc-trunk, from 20060828. The asm file confuses the glibc scripts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28930
[Bug c/28930] [4.2.0] regression
--- Comment #4 from joseph at codesourcery dot com 2006-09-01 19:47 --- Subject: Re: New: [4.2.0] regression On Fri, 1 Sep 2006, edmar at freescale dot com wrote: > During the build of glibc (2.3.6) there is a file (csu/initfini.c) that has > several asm statements. After compiling, the resulting asm file will be the > source of some sed scripts that generates crti.S and crtn.S. > > Using gcc-trunk snapshot from 20060828, and gcc-4.0.2, the generated files > initfini.s differs to a point that the sed scripts gets totaly lost. The ARM version of initfini.c does /* Prevent this function from being inlined. Otherwise half of its constant pool will end up in crti and the other half in crtn. */ static void call_gmon_start (void) __attribute__((noinline)); #include to avoid problems with the asm processing of this file. Does using noinline like this work for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28930
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #36 from dje at watson dot ibm dot com 2006-09-01 19:56 --- Subject: Re: [4.1/4.2 Regression] returning constant double What is confusing to me is that the r->r case is using evmergehi and evmergelo. This is placing the value in both halves of the SIMD register. It seems like this could have been done with two "mr". It is ambiguous whether the pattern is trying to load the full 64 bit register or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug inline-asm/23399] ICE in create_tmp_var, at gimplify.c:387
--- Comment #4 from dtemirbulatov at gmail dot com 2006-09-01 19:57 --- I have got the same ICE on mainline gcc-20060815 bug.cc:4: internal compiler error: in create_tmp_var, at gimplify.c:487 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23399
[Bug target/28930] [4.2.0] regression
--- Comment #5 from edmar at freescale dot com 2006-09-01 20:03 --- (In reply to comment #4) > Subject: Re: New: [4.2.0] regression > > On Fri, 1 Sep 2006, edmar at freescale dot com wrote: > > > During the build of glibc (2.3.6) there is a file (csu/initfini.c) that has > > several asm statements. After compiling, the resulting asm file will be the > > source of some sed scripts that generates crti.S and crtn.S. > > > > Using gcc-trunk snapshot from 20060828, and gcc-4.0.2, the generated files > > initfini.s differs to a point that the sed scripts gets totaly lost. > > The ARM version of initfini.c does > > /* Prevent this function from being inlined. Otherwise half of its >constant pool will end up in crti and the other half in crtn. */ > > static void call_gmon_start (void) __attribute__((noinline)); > > #include > > to avoid problems with the asm processing of this file. Does using > noinline like this work for you? > It does change the inlining of call_gmon_start, but nothing else. I think the critical point is the positioning of /[EMAIL PROTECTED]/ and other markers like it within the file. Of course someone could argue that gcc is not doing anything wrong, and glibc scripts is making too much assumptions. But if this change was accidental, and could be reversed, it would be nice ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28930
[Bug other/28230] ICE during bootstrap (-O2 -fwrapv issue)
--- Comment #6 from pluto at agmk dot net 2006-09-01 20:11 --- I have a smaller testcase. `-march=x86-64 -O2 -fno-strict-aliasing -fwrapv` generates wrong code for gas/write.c from binutils-2.17.50.0.3 and assembler fails on every file with an error message: /tmp/ccsCHgd4.s: Assembler messages: /tmp/ccsCHgd4.s:3: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section .text -- pluto at agmk dot net changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug middle-end/27226] [4.1/4.2 Regression] Compiler looses track of alignment for emit_block_move
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-09-01 20:25 --- Subject: Bug 27226 Author: rguenth Date: Fri Sep 1 20:25:34 2006 New Revision: 116641 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116641 Log: 2006-09-01 J"orn Rennecke <[EMAIL PROTECTED]> Richard Guenther <[EMAIL PROTECTED]> Adam Nemet <[EMAIL PROTECTED]> PR middle-end/27226 * builtins.c (get_pointer_alignment): Handle more forms of base addresses that can be used to derive more precise information about alignment. * gcc.target/mips/memcpy-1.c: New testcase. * gcc.dg/pr27226.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr27226.c trunk/gcc/testsuite/gcc.target/mips/memcpy-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug middle-end/27226] [4.1 Regression] Compiler looses track of alignment for emit_block_move
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-09-01 20:26 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.0 4.2.0 |4.1.0 Known to work|3.4.0 3.4.3 |3.4.0 3.4.3 4.2.0 Summary|[4.1/4.2 Regression]|[4.1 Regression] Compiler |Compiler looses track of|looses track of alignment |alignment for |for emit_block_move |emit_block_move | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug target/28930] [4.2.0] regression
--- Comment #6 from joseph at codesourcery dot com 2006-09-01 20:27 --- Subject: Re: [4.2.0] regression On Fri, 1 Sep 2006, edmar at freescale dot com wrote: > It does change the inlining of call_gmon_start, but nothing else. I think the > critical point is the positioning of /[EMAIL PROTECTED]/ and other markers > like it within the file. > > Of course someone could argue that gcc is not doing anything wrong, and glibc > scripts is making too much assumptions. But if this change was accidental, and > could be reversed, it would be nice ... The glibc build is almost certainly buggy and reliable on things GCC does not guarantee. The options you quote don't include -fno-unit-at-a-time. glibc should be using this option (or, better, -fno-toplevel-reorder with newer GCC) to compile this file; I don't know how you configured it not to use this option. glibc's configure tests for and should have detected -fno-toplevel-reorder support. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28930
[Bug target/28930] [4.2.0] regression
--- Comment #7 from edmar at freescale dot com 2006-09-01 20:45 --- (In reply to comment #6) > The options you quote don't include -fno-unit-at-a-time. glibc should be > using this option (or, better, -fno-toplevel-reorder with newer GCC) to > compile this file; I don't know how you configured it not to use this > option. glibc's configure tests for and should have detected > -fno-toplevel-reorder support. Great. the option -fno-toplevel-reorder works for me. Gcc-4.0.2 does not have this option, and I guess glibc-2.3.6 was released arround that time. I will close this bug now Thanks -- edmar at freescale dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28930
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #37 from mmitchel at gcc dot gnu dot org 2006-09-01 21:25 --- I'm marking this P2 since it's E500-specific (as far as I can tell). However, it's clearly a significant issue. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27386] AVR: wrong code generated when passing three uint64_t arguments to function
--- Comment #8 from eweddington at cso dot atmel dot com 2006-09-01 21:44 --- Bugmasters: Please mark this bug as NEW. It is a valid bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27386
[Bug middle-end/28814] [4.1 regression] in compare_values, at tree-vrp.c:415
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-09-01 21:49 --- Subject: Bug 28814 Author: rguenth Date: Fri Sep 1 21:49:05 2006 New Revision: 116642 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116642 Log: 2006-09-01 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: PR middle-end/28814 * fold-const.c (fold_binary): Fold temporary to correct type before constructing new comparison. * gcc.dg/torture/pr28814.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr28814.c - copied unchanged from r116439, trunk/gcc/testsuite/gcc.dg/torture/pr28814.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28814
[Bug middle-end/28814] [4.1 regression] in compare_values, at tree-vrp.c:415
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-09-01 21:49 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28814
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-09-01 21:51 --- This is a P1 because we need to understand if there is actually ABI breakage. If there isn't, or if we can't confirm that there is, we'll downgrade this. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
[Bug middle-end/28831] [4.0/4.1/4.2 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-09-01 21:53 --- Yet another problem showing problems with attributes on typedefs for structure types... -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug c++/28858] [4.0/4.1/4.2 regression] Algorithm to find the end of a template parameter list is flawed
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28858
[Bug c++/28861] [4.0/4.1/4.2 regression] ICE on invalid in-class specialization
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28861
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug tree-optimization/28868] [4.0/4.1/4.2 Regression] Not elimintating the PHIs which have the same agruments
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug c++/28878] [4.0/4.1/4.2 regression] ICE using "[" instead of "{"
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28878
[Bug c++/28879] [4.0/4.1/4.2 regression] ICE with variable-sized array in template function
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28879
[Bug middle-end/28884] [4.2 Regression] TARGET_FUNCTION_VALUE not documented
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28884
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-09-01 22:19 --- There shouldn't be a NON_LVALUE_EXPR here at all; non-type template parameters are lvalues only if they have reference type. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug tree-optimization/28887] [4.2 Regression] rejects valid code (bitfields and loops) with -O1 -fprefetch-loop-arrays
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28887
[Bug tree-optimization/28888] [4.1/4.2 regression] ICE in tree check: expected cond_expr, have label_expr in simplify_using_initial_conditions, at tree-ssa-loop-niter.c
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug tree-optimization/28900] [4.1/4.2 regression] ICE verify_stmts failed (invalid operand to unary operator)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-01 22:24 --- (In reply to comment #3) > There shouldn't be a NON_LVALUE_EXPR here at all; non-type template parameters > are lvalues only if they have reference type. fold produces it because maybe_lvalue_p returns true for Language specific trees and fold is folding (template_parameter+1)-1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug c++/28903] [4.2 Regression] Rejects VLA in template class's member with using
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28903
[Bug tree-optimization/28905] [4.2 regression] ICE in compare_name_with_value, at tree-vrp.c:3557
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28905
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #5 from mark at codesourcery dot com 2006-09-01 22:30 --- Subject: Re: [4.1/4.2 regression] Template specialization with array rejected pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-01 22:24 > --- > (In reply to comment #3) >> There shouldn't be a NON_LVALUE_EXPR here at all; non-type template >> parameters >> are lvalues only if they have reference type. > > fold produces it because maybe_lvalue_p returns true for Language specific > trees > and fold is folding (template_parameter+1)-1. So, that's what should be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug c++/28906] [4.2 regression] rejects valid arrays
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug tree-optimization/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-02 00:02 --- (In reply to comment #11) > Yet another problem showing problems with attributes on typedefs for structure > types... Except this is with C and not C++ unlike the other ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-02 01:36 --- (In reply to comment #5) > So, that's what should be fixed. Except that means introducing a language hook which is only to be useful in one place. The other way of fixing this is not to call fold if we have a MINUS_EXPR with the 2nd operand as 1, we just use the first. Really I don't see any reason why we should introduce a language hook when we can just strip the NON_LVALUE_EXPR right after fold and introducing a language hook which will only help in one specific case. The real real way of fixing this is to move the C++ front-end's templates from using trees and use something which is just specific to the C++ front-end and we would not have to call fold here at all since we will just store the length of the array instead of the "length-1". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
Re: [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
On Fri, 2006-09-01 at 22:30 +, mark at codesourcery dot com wrote: > So, that's what should be fixed. Except that means introducing a language hook which is only to be useful in one place. The other way of fixing this is not to call fold if we have a MINUS_EXPR with the 2nd operand as 1, we just use the first. Really I don't see any reason why we should introduce a language hook when we can just strip the NON_LVALUE_EXPR right after fold and introducing a language hook which will only help in one specific case. The real real way of fixing this is to move the C++ front-end's templates from using trees and use something which is just specific to the C++ front-end and we would not have to call fold here at all since we will just store the length of the array instead of the "length-1". -- Pinski
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #7 from pinskia at physics dot uc dot edu 2006-09-02 01:39 --- Subject: Re: [4.1/4.2 regression] Template specialization with array rejected On Fri, 2006-09-01 at 22:30 +, mark at codesourcery dot com wrote: > So, that's what should be fixed. Except that means introducing a language hook which is only to be useful in one place. The other way of fixing this is not to call fold if we have a MINUS_EXPR with the 2nd operand as 1, we just use the first. Really I don't see any reason why we should introduce a language hook when we can just strip the NON_LVALUE_EXPR right after fold and introducing a language hook which will only help in one specific case. The real real way of fixing this is to move the C++ front-end's templates from using trees and use something which is just specific to the C++ front-end and we would not have to call fold here at all since we will just store the length of the array instead of the "length-1". -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug c/28931] New: Negative numbers in varargs incorrect on AMD64
Example source:
void f1(long foo, long bar) {/*empty*/}
void f2(long foo, ...) {/*empty*/}
void _start()
{
f1(-1, -2); //both correct
f2(-1, -2); //-1 correct, -2 becomes 0xFFFE
f2(0x, 0xfffe); //both correct
}
$ amd64-elf-gcc -ffreestanding -nodefaultlibs -nostdlib -nostartfiles -o
standalone.bin standalone.c
$ amd64-elf-gcc -v
Using built-in specs.
Target: amd64-elf
Configured with: /elf/src/gcc-4.1.1/configure --target=amd64-elf --prefix=/elf
-
-exec-prefix=/elf/amd64-pc-cygwin --with-gnu-as --with-gnu-ld --without-headers
Thread model: single
gcc version 4.1.1
$ amd64-elf-objdump -d standalone.bin
0040014a <_start>:
40014a: 55 push %rbp
40014b: 48 89 e5mov%rsp,%rbp
40014e: 48 c7 c6 fe ff ff ffmov$0xfffe,%rsi
400155: 48 c7 c7 ff ff ff ffmov$0x,%rdi
40015c: e8 4f ff ff ff callq 4000b0
400161: be fe ff ff ff mov$0xfffe,%esi<-- should
be qword move
400166: 48 c7 c7 ff ff ff ffmov$0x,%rdi
40016d: b8 00 00 00 00 mov$0x0,%eax
400172: e8 47 ff ff ff callq 4000be
400177: 48 c7 c6 fe ff ff ffmov$0xfffe,%rsi
40017e: 48 c7 c7 ff ff ff ffmov$0x,%rdi
400185: b8 00 00 00 00 mov$0x0,%eax
40018a: e8 2f ff ff ff callq 4000be
40018f: c9 leaveq
400190: c3 retq
It should emit the 0x48 prefixed version as in the 3rd call. My guess is that
"movl" instead of "movq" or "mov ..., esi" instead of "mov ..., rsi" is being
passed to as.
--
Summary: Negative numbers in varargs incorrect on AMD64
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wulf at ignmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: amd64-pc-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28931
[Bug target/28931] Negative numbers in varargs incorrect on AMD64
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-02 01:51 ---
void f2(long foo, ...) {/*empty*/}
f2(-1, -2); //-1 correct, -2 becomes 0xFFFE
You are passing -2 as an (32bit) int and not as a (64bit) long to a var-args
function so this is not a bug unless you can prove that this is incorrect by
the ABI. If you are trying to port to x86_64-cygwin and this is demanded by
the ABI, you should change the internals of GCC for that ABI but the elf one as
far as I know says it is past as an int and not as a long.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c |target
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28931
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #8 from mark at codesourcery dot com 2006-09-02 03:50 --- Subject: Re: [4.1/4.2 regression] Template specialization with array rejected pinskia at physics dot uc dot edu wrote: > --- Comment #7 from pinskia at physics dot uc dot edu 2006-09-02 01:39 > --- > Subject: Re: [4.1/4.2 regression] Template specialization > with array rejected > > On Fri, 2006-09-01 at 22:30 +, mark at codesourcery dot com wrote: >> So, that's what should be fixed. > Except that means introducing a language hook which > is only to be useful in one place. That's not necessarily a bad thing. But, introducing NON_LVALUE_EXPRs that we are just going to throw away is a bad thing. And, yes, if we can avoid generating MINUS_EXPRs, that would be even better. In general, it might be better if range types were expressed as half-open intervals, rather than closed intervals, since then the number of elements in the array would be immediately available, and that's something often wants. > The real real way of fixing this is to move the C++ > front-end's templates from using trees You bring this up every so often, but I am totally unpersuaded. Using trees is just fine for C++. The advantages to not using trees would be interfacing to things other than GCC itself; there are no advantages within the compiler. For example, if we didn't have trees for C++, we'd be totally unable to use fold. In any case, this is entirely orthogonal to the issue at hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-02 04:00 --- Actually the other way to fix this is not to require NON_LVALUE_EXPR in the first place by fixing the front-ends so they can figure out lvalueness without depending on the tree structures. Since Mark caused this and does not want the simple fix of removing NON_LVALUE_EXPR after the fact, I am unassigning myself. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #13 from geoffk at geoffk dot org 2006-09-02 05:31 --- Subject: Re: [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs On 01/09/2006, at 2:53 PM, mmitchel at gcc dot gnu dot org wrote: > --- Comment #11 from mmitchel at gcc dot gnu dot org > 2006-09-01 21:53 --- > Yet another problem showing problems with attributes on typedefs > for structure > types... The question I asked is "why doesn't this happen for 'const'"? That turned out to be a good question, because it leads to the better question of "what debugging output did you expect for this code, anyway"? It seems to me that __noalias__ is an interesting attribute that should be somehow reflected in the DWARF. That would require a GNU extension, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug c++/26917] [4.0/4.1/4.2 regression] ICE with -frepo on invalid code
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-02 06:52 --- Subject: Bug 26917 Author: jakub Date: Sat Sep 2 06:52:24 2006 New Revision: 116654 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116654 Log: PR c++/26917 * repo.c (repo_file): Remove. (open_repo_file, reopen_repo_file_for_write): Return fopened FILE * instead of setting global repo_file variable. (init_repo): Adjust caller. (finish_repo): Likewise. Return instead of goto out before reopen_repo_file_for_write has been called. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/repo.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26917
[Bug c++/28878] [4.0/4.1/4.2 regression] ICE using "[" instead of "{"
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-02 06:54 --- Subject: Bug 28878 Author: jakub Date: Sat Sep 2 06:54:04 2006 New Revision: 116655 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116655 Log: PR c++/28878 * except.c (build_throw): Only set current_function_returns_abnormally if cfun is not NULL. * g++.dg/parse/crash33.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/crash33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28878
[Bug middle-end/27567] [4.0/4.1/4.2 Regression] __builtin_memcpy generates redundant stores/moves.
--- Comment #6 from jakub at gcc dot gnu dot org 2006-09-02 06:55 ---
Subject: Bug 27567
Author: jakub
Date: Sat Sep 2 06:55:09 2006
New Revision: 116656
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116656
Log:
PR middle-end/27567
* builtins.c (fold_builtin_memcpy, fold_builtin_memmove): Remove.
(fold_builtin_mempcpy): Rename to...
(fold_builtin_memory_op): ... this. Optimize one element copy
into an assignment.
(fold_builtin_memset, fold_builtin_bzero, fold_builtin_bcopy): New
functions.
(expand_builtin_strcpy, expand_builtin_strncpy): Handle COMPOUND_EXPR.
(expand_builtin_memcpy, expand_builtin_mempcpy,
expand_builtin_memmove): Likewise. Use fold_builtin_memory_op.
(fold_builtin_1): Handle BUILT_IN_MEMSET, BUILT_IN_BZERO and
BUILT_IN_BCOPY. Use fold_builtin_memory_op for
BUILT_IN_MEM{CPY,PCPY,MOVE}.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27567
[Bug c++/26917] [4.0/4.1/4.2 regression] ICE with -frepo on invalid code
--- Comment #4 from jakub at gcc dot gnu dot org 2006-09-02 06:57 --- Subject: Bug 26917 Author: jakub Date: Sat Sep 2 06:56:59 2006 New Revision: 116657 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116657 Log: PR c++/26917 * repo.c (repo_file): Remove. (open_repo_file, reopen_repo_file_for_write): Return fopened FILE * instead of setting global repo_file variable. (init_repo): Adjust caller. (finish_repo): Likewise. Return instead of goto out before reopen_repo_file_for_write has been called. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/repo.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26917
[Bug c++/28878] [4.0/4.1/4.2 regression] ICE using "[" instead of "{"
--- Comment #4 from jakub at gcc dot gnu dot org 2006-09-02 06:58 --- Subject: Bug 28878 Author: jakub Date: Sat Sep 2 06:58:19 2006 New Revision: 116658 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116658 Log: PR c++/28878 * except.c (build_throw): Only set current_function_returns_abnormally if cfun is not NULL. * g++.dg/parse/crash33.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/crash33.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/except.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28878
