[Bug c++/35884] defining __need_size_t before including cstddef causes error
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-11 06:45 --- No, that is a way how the implementation does that internally. That's certainly not something you are allowed to do in random applications or libraries. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35884
[Bug c/35744] [4.1/4.2/4.3/4.4 regression] ICE attributes for invalid types
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-04-11 06:56 --- Subject: Bug 35744 Author: reichelt Date: Fri Apr 11 06:55:38 2008 New Revision: 134193 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134193 Log: PR c/35744 * attribs.c (decl_attributes): Return early on errorneous node. * gcc.dg/attr-error-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/attr-error-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35744
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #5 from burnus at gcc dot gnu dot org 2008-04-11 07:45 --- If on the other hand Tobias is right in the assumption he made in comment #3, then one could something along the lines of if (f1-sym-as-type != f2-sym-as-type) I would not be surprised if foo(*) and foo(4) are allowed and then your test rejects too much. My feeling is that at least the array size should match for explicit-shape arrays, I'm not sure about that part; one can create valid (i.e. working) programs which violate this (e.g.: array(5), array(10), but only accessing 1 to 5). We should check what the standard says about this. I think it is formally invalid to do so; if we decide to allow it, at least a warning should be printed. (At the end one needs to carefully read the standard, unfortunately, I do not have much time the next two, three weeks. One could also ask at comp.lang.fortran.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug ada/35906] New: build fails when building with -m32 -mcpu=ultrasparc (sparcv9 or -mv8plus also)
Bug is present in 4.2.3 also. building 32bit code with architecture greater than sparcv8 fails like this: /home/users/builder/rpm/BUILD/gcc-4.3.0/builddir/./gcc/xgcc -B/home/users/builder/rpm/BUILD/gcc-4.3.0/builddir/./gcc/ -B/usr/sparc-pld-linux/bin/ -B/usr/sparc-pld-linux/lib/ -isystem /usr/sparc-pld-linux/ include -isystem /usr/sparc-pld-linux/sys-include -c -O2 -m32 -mcpu=ultrasparc -gdwarf-2 -g2 -fPIC -W -Wall -gnatpg s-finroo.adb -o s-finroo.o /home/users/builder/rpm/BUILD/gcc-4.3.0/builddir/./gcc/xgcc -B/home/users/builder/rpm/BUILD/gcc-4.3.0/builddir/./gcc/ -B/usr/sparc-pld-linux/bin/ -B/usr/sparc-pld-linux/lib/ -isystem /usr/sparc-pld-linux/include -isystem /usr/sparc-pld-linux/sys-include -c -O2 -m32 -mcpu=ultrasparc -gdwarf-2 -g2 -fPIC -W -Wall -gnatpg s-fore.adb -o s-fore.o s-fore.adb: In function 'System.Fore.Fore': s-fore.adb:57: error: unrecognizable insn: (insn 11 10 12 2 s-fore.adb:41 (set (reg:CCFPE 96 %fcc0) (compare:CCFPE (reg/v:TF 108 [ t ]) (reg:TF 115))) -1 (nil)) +===GNAT BUG DETECTED==+ | 4.3.0 20080408 (release) (sparc-pld-linux-gnu) GCC error:| | in extract_insn, at recog.c:1990 | | Error detected around s-fore.adb:57 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398 make[7]: *** [s-fore.o] Error 1 make[7]: Leaving directory `/home/users/builder/rpm/BUILD/gcc-4.3.0/builddir/gcc/ada/rts' make[6]: *** [gnatlib] Error 2 -- Summary: build fails when building with -m32 -mcpu=ultrasparc (sparcv9 or -mv8plus also) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tommat at pimpek dot one dot pl GCC build triplet: sparc-pld-linux GCC host triplet: sparc-pld-linux GCC target triplet: sparc-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35906
[Bug target/35906] build fails when building with -m32 -mcpu=ultrasparc (sparcv9 or -mv8plus also)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Component|ada |target Keywords||build, ice-on-valid-code Known to fail||4.2.3 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35906
[Bug testsuite/35843] [4.4 Regression]: -fdump-rtl-expand does not exist anymore
--- Comment #4 from ubizjak at gmail dot com 2008-04-11 10:16 --- Patch in testing. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Component|middle-end |testsuite Last reconfirmed|2008-04-07 01:13:56 |2008-04-11 10:16:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35843
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack on ia32
--- Comment #18 from jakub at gcc dot gnu dot org 2008-04-11 10:25 ---
Seems I forgot to provide the testcase I was talking about. Here it is:
__attribute__((preserve_stack)) void f1 (int a, int b, int c, int d, int e)
{
int i;
for (i = 0; i 50; i++)
{
// Simulate high register pressure, I'm lazy
asm volatile ( : : r (e) : %eax, %ebx, %ecx, %edx, %esi);
e++;
asm volatile ( : : r (d) : %eax, %ebx, %ecx, %edx, %esi);
}
}
__attribute__((preserve_stack)) void f2 (int a, int b, int c, int d, int e)
{
int i;
for (i = 0; i 50; i++)
{
asm volatile ( : : m (e) : %eax, %ebx, %ecx, %edx, %esi,
%edi);
e++;
}
}
extern int fn (int, int);
__attribute__((preserve_stack)) int f3 (int a, int b)
{
return fn (b, a);
}
__attribute__((preserve_stack)) int f4 (int a, int b)
{
return fn (a, b);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90
--- Comment #9 from pault at gcc dot gnu dot org 2008-04-11 09:54 --- It's mine, it's mine! I even posted a fix for it last night but have not had a chance to commit it. I'll try to do so over the weekend. As Jerry remarks, it sometimes goes away; such as on my x86_ia64/FC8, on which I developed the patch that caused the regression. Sorry about the problem. 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-04-08 00:12:28 |2008-04-11 09:54:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
[Bug testsuite/35843] [4.4 Regression]: -fdump-rtl-expand does not exist anymore
--- Comment #5 from ubizjak at gmail dot com 2008-04-11 11:44 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00930.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg00930.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35843
[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90
--- Comment #10 from burnus at gcc dot gnu dot org 2008-04-11 12:23 --- It's mine, it's mine! I even posted a fix for it last night but have not had a chance to commit it. I'll try to do so over the weekend. The mentioned patch was posted here: http://gcc.gnu.org/ml/fortran/2008-04/msg00107.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
[Bug target/35907] New: [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
build_trtable function from posix/regex.c is miscompiled on ppc64-linux with -mcpu=power6. The $v31 register is used within the function and is therefore saved in prologue and restored in epilogue, but as the function uses alloca, it is restored from different memory slot than it was saved into. Options used: -fpreprocessed -quiet -m64 -mcpu=power6 -mno-minimal-toc -mnew-mnemonics -mlong-double-128 -g -O3 -std=gnu99 -fgnu89-inline -fasynchronous-unwind-tables -fmerge-all-constants -fpic The interesting lines in the assembly are: .build_trtable: ... li 0,320 ... stdu 1,-496(1) stvx 31,1,0 mfvrsave 0 mr 31,1 ... ld 0,0(1) ... stdu 0,-12304(1) ... li 0,320 lvx 31,1,0 ld 1,0(1) ... blr The above is with the trunk gcc, but 4.3 is similar. Unlike this, gcc 4.1 saved the vector register early: li 0,-176 stvx 31,1,0 as first two insns in the routine, before first stdu, and restored after incrementing stack pointer back: ld 1,0(1) mr 3,0 li 0,-176 lwz 12,-148(1) lvx 31,1,0 So, with 4.1.x this works, but with 4.3/trunk $v31 will get the value of a memory slot 12304 bytes (i.e. the size of alloca) below where it was actually saved. -- Summary: [4.3/4.4 Regression] 64-bit power6 glibc miscompilation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-11 14:01 --- Created an attachment (id=15466) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15466action=view) regex.i.bz2 bzip2ed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug tree-optimization/35869] ICE in calc_dfs_tree at -O2 -gnatp after VRP optimization
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-11 14:14 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35869
[Bug tree-optimization/35869] ICE in calc_dfs_tree at -O2 -gnatp after VRP optimization
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-11 14:14 --- Subject: Bug 35869 Author: rguenth Date: Fri Apr 11 14:14:04 2008 New Revision: 134197 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134197 Log: 2008-04-11 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/35869 * tree-vrp.c (execute_vrp): Move switch statement update after jump threading. Schedule another cfg cleanup run. * gcc.c-torture/compile/pr35869.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr35869.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35869
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-11 14:25 ---
Smaller testcase:
/* { dg-do run } */
/* { dg-options -O2 -mcpu=power6 } */
#define vector __attribute__((vector_size (16)))
union
{
vector int k;
int c[16];
} u, v, w;
vector int m;
void __attribute__((noinline))
bar (void *i, vector int j)
{
asm volatile ( : : r (i), r (j) : memory);
}
int __attribute__((noinline))
foo (int i, vector int j)
{
char *p = __builtin_alloca (64 + i);
m += u.k;
v.k = m;
w.k = j;
if (__builtin_memcmp (v.c, w.c, 16) != 0)
__builtin_abort ();
j += u.k;
bar (p, j);
j += u.k;
bar (p, j);
return 0;
}
int
main (void)
{
vector int l;
int i;
for (i = 0; i 4; i++)
u.c[i] = i;
l = u.k;
if (foo (64, l))
__builtin_abort ();
l += u.k;
if (foo (64, l))
__builtin_abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-11 14:31 --- On this smaller testcase and supposedly on the large testcase too: @@ -90,7 +90,7 @@ foo: li 3,0 lvx 30,1,0 li 0,128 - lvx 31,1,0 + lvx 31,31,0 ld 1,0(1) lwz 12,-28(1) mtvrsave 12 fixes this (r31 is frame pointer, set to r1 around the stvx that saved v31, but at the lvx 31,1,0 instruction r1 is r31 decreased by alloca calls). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c/35908] New: Dubious charset conversions
GCC accepts the following with -ansi -pedantic -Wall without diagnostics #include stdlib.h wchar_t z[] = La \xff; GCC claims a default execution charset of UTF-8; presumably the default execution wide character set is UTF-32. But \xff is a two-character narrow execution character set string literal, with characters \xff \0, which is invalid UTF-8 and so cannot be converted in a meaningful way to the execution character set (whatever it is). I would expect the above code to be rejected, or at least diagnosed. -- Summary: Dubious charset conversions Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35908
[Bug middle-end/35897] DSE doesn't support targets with wide registers
--- Comment #5 from hjl at gcc dot gnu dot org 2008-04-11 15:53 --- Subject: Bug 35897 Author: hjl Date: Fri Apr 11 15:52:19 2008 New Revision: 134199 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134199 Log: 2008-04-11 H.J. Lu [EMAIL PROTECTED] PR middle-end/35897 * dse.c (store_info): Change positions_needed to unsigned HOST_WIDE_INT. (lowpart_bitmask): New. (record_store): Cast to unsigned HOST_WIDE_INT for positions_needed. Assert width = size of positions_needed * CHAR_BIT. Call lowpart_bitmask to initialize positions_needed. (check_mem_read_rtx): Use unsigned HOST_WIDE_INT on mask. Call lowpart_bitmask to set mask. Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35897
[Bug middle-end/35897] DSE doesn't support targets with wide registers
--- Comment #6 from hjl at gcc dot gnu dot org 2008-04-11 15:56 --- Subject: Bug 35897 Author: hjl Date: Fri Apr 11 15:55:57 2008 New Revision: 134200 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134200 Log: 2008-04-11 H.J. Lu [EMAIL PROTECTED] PR middle-end/35897 * dse.c (store_info): Change positions_needed to unsigned HOST_WIDE_INT. (lowpart_bitmask): New. (record_store): Cast to unsigned HOST_WIDE_INT for positions_needed. Assert width = size of positions_needed * CHAR_BIT. Call lowpart_bitmask to initialize positions_needed. (check_mem_read_rtx): Use unsigned HOST_WIDE_INT on mask. Call lowpart_bitmask to set mask. Modified: branches/ix86/avx/gcc/ChangeLog.avx branches/ix86/avx/gcc/dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35897
[Bug testsuite/35843] [4.4 Regression]: -fdump-rtl-expand does not exist anymore
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-11 16:09 --- I would rather have -fdump-rtl-expand back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35843
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-11 16:26 --- I wonder if this was caused by: 2007-05-16 Eric Christopher [EMAIL PROTECTED] * config/rs6000/rs6000.c (rs6000_emit_prologue): Move altivec register saving after stack push. Set sp_offset whenever we push. (rs6000_emit_epilogue): Move altivec register restore before stack push. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c/35908] Dubious charset conversions
--- Comment #1 from joseph at codesourcery dot com 2008-04-11 16:58 --- Subject: Re: New: Dubious charset conversions On Fri, 11 Apr 2008, neil at gcc dot gnu dot org wrote: GCC accepts the following with -ansi -pedantic -Wall without diagnostics #include stdlib.h wchar_t z[] = La \xff; GCC claims a default execution charset of UTF-8; presumably the default execution wide character set is UTF-32. But \xff is a two-character narrow execution character set string literal, with characters \xff \0, which is invalid UTF-8 and so cannot be converted in a meaningful way to the execution character set (whatever it is). I would expect the above code to be rejected, or at least diagnosed. Accepting it as equivalent to La\xff (generating a wide character L'a' followed by one with value 0xff) seems in accordance with the principles of N951, the relevant ones of which are implemented in GCC. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n951.htm http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00532.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35908
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #5 from bergner at gcc dot gnu dot org 2008-04-11 17:20 --- Created an attachment (id=15467) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15467action=view) Restore altivec regs after frame pointer setup I agree with Andrew, it looks like Eric's patch moved the restoring of the altivec registers to before the frame pointer code. The attached (non bootstrapped or regtested) fixes the problem for me. Does this look ok to everyone? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c++/33486] namespace association doesn't handle parallel namespaces
--- Comment #9 from bkoz at gcc dot gnu dot org 2008-04-11 17:32 --- OK'd by Richard in private email, so I'm adjusting the Target Milestone to 4.3.1. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #6 from bergner at gcc dot gnu dot org 2008-04-11 17:33 --- FYI, it results in the updated asm: --- glibc02-bad.s 2008-04-11 12:21:48.0 -0500 +++ glibc02-good.s 2008-04-11 12:21:33.0 -0500 @@ -66,12 +66,12 @@ mr 3,30 vadduwm 2,31,2 bl bar - li 0,16 + li 0,-64 li 3,0 lwz 11,0(1) - lvx 30,1,0 - li 0,32 - lvx 31,1,0 + lvx 30,11,0 + li 0,-48 + lvx 31,11,0 lwz 12,-16(11) mtvrsave 12 lwz 0,4(11) -- bergner 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-04-11 17:33:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c++/35909] New: ice for legal code
I just tried to compile the Suse Linux package tse3-0.3.1 with the GNU C compiler version 4.4 snapshot 20080404 The compiler said g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -W -Wall -ansi -pedantic -MT Alsa-0.9.lo -MD -MP -MF .deps/Alsa-0.9.Tpo -c Alsa-0.9.cpp -fPIC -DPIC -o .libs/Alsa-0.9.o In file included from Alsa-0.9.cpp:35: /usr/include/sys/asoundlib.h:1:2: warning: #warning This header is deprecated, use alsa/asoundlib.h instead. Alsa-0.9.cpp: In member function 'void TSE3::Plt::AlsaMidiScheduler::getSystemInfo()': Alsa-0.9.cpp:208: warning: the address of 'ci' will always evaluate as 'true' Alsa-0.9.cpp:219: warning: the address of 'pi' will always evaluate as 'true' Alsa-0.9.cpp:238: warning: the address of 'subs' will always evaluate as 'true' Alsa-0.9.cpp: In member function 'void TSE3::Plt::AlsaImpl::tx(TSE3::MidiCommand, int, long int, long int)': Alsa-0.9.cpp:343: internal compiler error: in build_target_expr, at cp/tree.c:267 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed C++ source code attached. No flags required -- Summary: ice for legal code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35909
[Bug c++/35909] ice for legal code
--- Comment #1 from dcb314 at hotmail dot com 2008-04-11 18:08 --- Created an attachment (id=15468) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15468action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35909
[Bug ada/15915] Illegal program not detected, RM 13.11(15)
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-13 14:15:45 |2008-04-11 18:23:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15915
[Bug target/35910] New: error: �struct function� has no member named �args_info�
Hi, building the target arm-elf fails with: gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/mstein/svn/trunk/gcc -I/home/mstein/svn/trunk/gcc/. -I/home/mstein/svn/trunk/gcc/../include -I/home/mstein/svn/trunk/gcc/../libcpp/include -I/opt/cfarm/mpfr-2.3.1/include -I/home/mstein/svn/trunk/gcc/../libdecnumber -I/home/mstein/svn/trunk/gcc/../libdecnumber/dpd -I../libdecnumber \ /home/mstein/svn/trunk/gcc/config/arm/arm.c -o arm.o /home/mstein/svn/trunk/gcc/config/arm/arm.c: In function thumb_find_work_register: /home/mstein/svn/trunk/gcc/config/arm/arm.c:3567: error: struct function has no member named args_info make[2]: *** [arm.o] Error 1 rev: 134177 last working rev: 133987 -- Summary: error: struct function has no member named args_info Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein dot lists at googlemail dot com GCC host triplet: x86_64-linux-gnu GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35910
[Bug rtl-optimization/35875] [ira] Error in process_bb_node_lives, at ira-lives.c:680
--- Comment #3 from mstein dot lists at googlemail dot com 2008-04-11 18:28 --- Fixed. -- mstein dot lists at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35875
[Bug rtl-optimization/35817] [ira] Error in init_move_cost, at regclass.c:321
--- Comment #2 from mstein dot lists at googlemail dot com 2008-04-11 18:31 --- Fixed. -- mstein dot lists at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35817
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-11 18:37 --- Is it safe to have live data in memory below stack pointer on ppc/ppc64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-11 19:07 --- (In reply to comment #7) Is it safe to have live data in memory below stack pointer on ppc/ppc64? powerpc64-*-* yes , powerpc-linux-gnu no. the SysV abi does not define a red zone. --Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #9 from bergner at gcc dot gnu dot org 2008-04-11 19:08 --- This isn't accessing data below the stack pointer, it's accessing below the previous stack pointer value which is in the current stack frame. From a technical standpoint, the ppc64 ABI allows us to access some number of bytes (144?) below the stack pointer, but the ppc32 ABI does not. -- bergner at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bergner at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-04-11 17:33:25 |2008-04-11 19:08:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #10 from jakub at gcc dot gnu dot org 2008-04-11 19:19 --- Well, for -m64 the code in between the old and new Altivec reg restoring spot when use_backchain_to_restore_sp will ld 1,0(1). Is altivec_save_offset guaranteed to be not lower than 288 bytes below this? For -m32, I see that it doesn't restore sp right away when alloca is used and the info-push_p increment doesn't apply to ABI_V4 either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35911] New: Building m32c-elf cross compiler fails
Hi, building m32c-elf fails here: gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/mstein/svn/trunk/gcc -I/home/mstein/svn/trunk/gcc/. -I/home/mstein/svn/trunk/gcc/../include -I/home/mstein/svn/trunk/gcc/../libcpp/include -I/opt/cfarm/mpfr-2.3.1/include -I/home/mstein/svn/trunk/gcc/../libdecnumber -I/home/mstein/svn/trunk/gcc/../libdecnumber/dpd -I../libdecnumber \ /home/mstein/svn/trunk/gcc/config/m32c/m32c.c -o m32c.o /home/mstein/svn/trunk/gcc/config/m32c/m32c.c: In function m32c_pushm_popm: /home/mstein/svn/trunk/gcc/config/m32c/m32c.c:1284: error: struct function has no member named return_rtx /home/mstein/svn/trunk/gcc/config/m32c/m32c.c:1285: error: struct function has no member named return_rtx /home/mstein/svn/trunk/gcc/config/m32c/m32c.c:1288: error: struct function has no member named return_rtx make[2]: *** [m32c.o] Error 1 -- Summary: Building m32c-elf cross compiler fails Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein dot lists at googlemail dot com GCC host triplet: x86_64-linux-gnu GCC target triplet: m32c-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35911
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #24 from d at domob dot eu 2008-04-11 20:26 --- (In reply to comment #23) (In reply to comment #22) I think your patch is in a good enough shape to post it to [EMAIL PROTECTED] and ask there for comments; this ensures that all gfortraners read it (and not only three Fortraners) and it makes discussing easier than a in a bugreport. Ok, sent it in. Any news from the patch? Or is it usual to take some time to get responses? Hope it didn't get lost (or the responses in the gcc-patches volume on my machine...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug c++/35909] [4.4 Regression] ice for legal code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ice for legal code |[4.4 Regression] ice for ||legal code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35909
[Bug target/35910] error: �struct function� has no member named �args_info�
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-11 21:24 --- Honza? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35910
[Bug target/35911] Building m32c-elf cross compiler fails
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-11 21:24 --- Honza? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35911
[Bug c++/35708] jump to label enters catch block
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c++/35708] [4.2 Regression] jump to label enters catch block
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|jump to label enters catch |[4.2 Regression] jump to |block |label enters catch block Target Milestone|4.3.1 |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c++/35909] [4.3/4.4 Regression] ice for legal code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-11 21:29 --- This is most likely caused by PR 35708. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Known to fail||4.4.0 Known to work||4.3.0 Summary|[4.4 Regression] ice for|[4.3/4.4 Regression] ice for |legal code |legal code Target Milestone|4.4.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35909
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #11 from bergner at gcc dot gnu dot org 2008-04-11 22:04 --- Hacking the test case to use up more stack space, I did get it to access more than 288 bytes below the stack frame for -m64, so we obviously need something more here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c/35885] unsigned long long and while loop evaluation regression?
--- Comment #3 from wilson at tuliptree dot org 2008-04-12 00:45 --- Subject: Re: New: unsinged long long and while loop evaluation regression? I can reproduce this on a 32-bit x86-linux machine (i.e. a 32-bit HWI). The unsigned long long 0x becomes a (const_double -1 0), and then in expand_mult in expmed.c we have /* If we are multiplying in DImode, it may still be a win to try to work with shifts and adds. */ if (CONST_DOUBLE_HIGH (op1) == 0) coeff = CONST_DOUBLE_LOW (op1); After this line, expand_mult thinks we are multiplying by -1 and we get the wrong result. I think there is a false assumption here that we can get CONST_DOUBLEs which can be simplified to a single word. Maybe in the olden days we always created a CONST_DOUBLE for DImode constants? This stuff has changed so many times it is hard to remember. I don't think we do it that way anymore. Anyways, if this assumption is not false, then the code needs to look more like the code in immed_double_const in emit-rtl.c, which does /* If this integer fits in one word, return a CONST_INT. */ if ((i1 == 0 i0 = 0) || (i1 == ~0 i0 0)) return GEN_INT (i0); where i1 is CONST_DOUBLE_HIGH and i0 is CONST_DOUBLE_LOW, and only in the case that this tests succeeds can we set coeff to CONST_DOUBLE_LOW. The same bug is in mainline, and probably goes a long ways back. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35885
[Bug ada/16086] Legal program rejected, procedure of protected object should be visible
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|2005-06-14 20:31:43 |2008-04-12 01:32:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16086
[Bug ada/16098] Illegal program not detected, RM 13.1(6)
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-06-14 20:23:24 |2008-04-12 03:08:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16098
[Bug middle-end/35885] unsigned long long and while loop evaluation regression?
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-12 03:10 --- I think this is one of the reasons why x86 should change to HWI is 64bits, it will get the same code generation between using -m32 on x86_64 and i?86. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end GCC build triplet|several | GCC host triplet|several | GCC target triplet|several |HWI == 32bits http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35885
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-12 03:21 --- On the trunk we get a better ICE: fs/sfs_xplatform.h:250: internal compiler error: tree check: expected class 'expression', have 'gimple_stmt' (gimple_modify_stmt) in expand_call_inline, at tree-inline.c:2872 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Keywords||ice-on-valid-code Summary|ICE on filesystem code |[4.3/4.4 Regression] ICE on ||filesystem code Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug ada/18204] Legal program rejected, completion of private type declaration
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-12 03:23 --- This appears to be fixed in 4.3.0. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18204
[Bug ada/18205] Legal program rejected, RM 13.13.2(14)
--- Comment #2 from sam at gcc dot gnu dot org 2008-04-12 03:24 --- Confirmed on gcc (GCC) 4.4.0 20080411 -- sam at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-06-14 20:21:48 |2008-04-12 03:24:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18205
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-12 03:35 ---
Reduced testcase:
void sfs_freeblocks(void)
{
int a = sfs_native_read_block ();
}
void sfs_native_read_block (void) {}
--- CUT ---
With -pedantic-errors, we error out.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords|ice-on-valid-code |
Last reconfirmed|-00-00 00:00:00 |2008-04-12 03:35:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug libgomp/35912] New: omp parallel for wrong result
I just write the following code:
int main() {
int i = 0;
int s = 0;
#pragma omp parallel for
for(i = 0; i 10001; i++) {
/* uncommenting the follow line, it works */
printf(thread %d : %d\n, omp_get_thread_num(), s = s + i);
/* uncommenting the follow line, it gets wrong */
/* s += i; */
/* but when uncommenting the follow line, the above line works
*/
/* printf(%d\n, s); */
}
printf(%d\n, s);
}
The above runs just as I described in the comment.
when I said it gets worng, I mean that, when I run it many time, it returns
different result, but every one is wrong.
such as:
$ ./another
31653559
lfs_625:wizard | Sat 12 Apr 2008 11:46:05 AM GMT | ~/programe/c/openMP
$ ./another
50005000
lfs_625:wizard | Sat 12 Apr 2008 11:46:06 AM GMT | ~/programe/c/openMP
$ ./another
24946634
lfs_625:wizard | Sat 12 Apr 2008 11:46:07 AM GMT | ~/programe/c/openMP
$ ./another
19633725
lfs_625:wizard | Sat 12 Apr 2008 11:46:07 AM GMT | ~/programe/c/openMP
$ ./another
49257506
lfs_625:wizard | Sat 12 Apr 2008 11:46:08 AM GMT | ~/programe/c/openMP
--
Summary: omp parallel for wrong result
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: whitelilis at gmail dot com
GCC host triplet: omp parallel for gets the wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35912
[Bug libgomp/35912] omp parallel for wrong result
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-12 04:27 --- I don't think this is a bug as you did not mark the operations on s as atomic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35912
[Bug c/35908] Dubious charset conversions
--- Comment #2 from neil at daikokuya dot co dot uk 2008-04-12 04:40 --- Subject: Re: Dubious charset conversions joseph at codesourcery dot com wrote:- GCC accepts the following with -ansi -pedantic -Wall without diagnostics #include stdlib.h wchar_t z[] = La \xff; GCC claims a default execution charset of UTF-8; presumably the default execution wide character set is UTF-32. But \xff is a two-character narrow execution character set string literal, with characters \xff \0, which is invalid UTF-8 and so cannot be converted in a meaningful way to the execution character set (whatever it is). I would expect the above code to be rejected, or at least diagnosed. Accepting it as equivalent to La\xff (generating a wide character L'a' followed by one with value 0xff) seems in accordance with the principles of N951, the relevant ones of which are implemented in GCC. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n951.htm http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00532.html Ah, I'd forgotten about that. That document does make much more sense, thanks. However I think there are at least two things wrong in Principle 7; I've mailed Clive about those. [The single byte requirement cannot be fulfilled for Latin source charset to UTF-8 target, for example, and UCNs are escape sequences that typically cannot be encoded as a single byte]. GCC should perhaps consider not creating invalid UTF-8 (i.e. no 5 or 6 bytes forms, or encodings of \ufffe \u etc.) Please feel free to close this report. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35908
