[Bug fortran/40955] STDCALL attributes are not saved in the .MOD files
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-09 08:36 --- Subject: Bug 40955 Author: burnus Date: Sun Aug 9 08:35:36 2009 New Revision: 150589 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150589 Log: 2009-08-05 Tobias Burnus PR fortran/40955 * gfortran.h (ext_attr_id_t): Add typedef for this enum. (gfc_add_ext_attribute): Use it. * decl.c (gfc_match_gcc_attributes): Ditto. * expr.c (gfc_check_pointer_assign): Ditto. * symbol.c (gfc_add_ext_attribute): Ditto. (gfc_copy_attr): Copy also ext_attr. * resolve.c (resolve_fl_derived,resolve_symbol): Ditto. * module.c (mio_symbol_attribute): Save ext_attr in the mod * file. 2009-08-05 Tobias Burnus PR fortran/40955 * gfortran.dg/module_md5_1.f90: Update MD5 check sum. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/module_md5_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40955
[Bug fortran/40955] STDCALL attributes are not saved in the .MOD files
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-09 08:40 --- FIXED on the trunk (4.5). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40955
[Bug libfortran/40549] Building libgfortran as a DLL
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-08-09 11:02 --- Subject: Bug 40549 Author: fxcoudert Date: Sun Aug 9 11:02:08 2009 New Revision: 150590 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150590 Log: PR libfortran/40549 * Makefile.in (LTLDFLAGS): Add -no-undefined. * Makefile.am: Regenerate. * libgfortran.h: Remove unused block of code. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/libgfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40549
[Bug web/36739] Proposal for clarifications in GCC Bugzilla
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-09 12:08 --- IMHO all fields on http://gcc.gnu.org/bugzilla/enter_bug.cgi need a link to documentation just like some already have. We can't expect people to guess what to put there. The alternative is to remove some of the fields (but then they are undocumented and meaningless on the main bug page as well). As Andrew said most of the detail information can be guessed from the description. But sometimes it is really hard because people do not read bugs.html (which is in a sorry state) and even do not paste simple things like the output of running 'gcc -v' into the description. The http://gcc.gnu.org/bugzilla/enter_bug.cgi page should in its preamble mention that - you should create attachments for large testcases after submitting the initial report - bugzilla is not the proper way to submit patches (link to contribute.html) IMHO the http://gcc.gnu.org/bugzilla/enter_bug.cgi page misses the Known-to-work and Known-to-fail fields. IMHO the assign to, CC and bug dependency fields are not required for http://gcc.gnu.org/bugzilla/enter_bug.cgi. The build-triplet is the most confusing one and I would remove it retaining the host and target fields (with proper descriptions). The gcc.gnu.org/bugs.html needs serious TLC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36739
[Bug tree-optimization/41008] [4.5 Regression] ICE in vect_is_simple_reduction, at tree-vect-loop.c:1708
--- Comment #2 from irar at gcc dot gnu dot org 2009-08-09 12:13 --- Subject: Bug 41008 Author: irar Date: Sun Aug 9 12:13:19 2009 New Revision: 150591 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150591 Log: PR tree-optimization/41008 * tree-vect-loop.c (vect_is_simple_reduction): Get operands from condition only in case it's a comparison. Adjust checks. Added: trunk/gcc/testsuite/gcc.dg/vect/O1-pr41008.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41008
[Bug tree-optimization/41008] [4.5 Regression] ICE in vect_is_simple_reduction, at tree-vect-loop.c:1708
--- Comment #3 from irar at il dot ibm dot com 2009-08-09 12:15 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41008
[Bug libfortran/40549] Building libgfortran as a DLL
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-08-09 13:25 --- Fixed on trunk. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40549
[Bug target/41013] New: Fastcall calling convention is incompatible with Windows
In Windows, fastcall calling convention is implemented in the following way:
* an argument that has integer type with size less-or-equal than 4 bytes is
eligible for fastcall
* the first argument that is eligible for fastcall is passed in ECX
* the second argument that is eligible for fastcall is passed in EDX
GCC implementes it badly, structures and 64-bit integer arguments are not
correctly passed in registers but they incorrectly increase the register number
in "function_arg_advance_32" and further arguments eligible for fastcall are
not passed in registers.
Example:
struct s {
int a;
};
int __attribute__((fastcall,noinline)) f(struct s s, int a1, int a2)
{
printf("args: %d, %d, %d\n", a1, a2, s.a);
return 0;
}
int main()
{
struct s s = { 3 };
f(s, 1, 2);
return 0;
}
--- on Windows, s goes on the stack, a1 goes in ECX and a2 goes in EDX.
--- in gcc, s goes on the stack (but it incorrectly increased a register
number), a1 goes in EDX and a2 goes on the stack too because gcc runs out of
fastcall registers.
--
Summary: Fastcall calling convention is incompatible with Windows
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
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=41013
[Bug target/41013] Fastcall calling convention is incompatible with Windows
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-08-09 13:39 --- "an argument that has integer type" should really be "an argument that has integer or pointer type" ... pointers are passed in registers too. Anything else isn't, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41013
[Bug libffi/41014] New: Fix for libffi err_bad_abi test failure
This patch fixes the libffi.call/err_bad_abi.c expected test failures, The bug
seems to be that various that bad ABI numbers, as used by err_bad_abi.c,
generate assertion failures instead of returning FFI_BAD_ABI. If the test is
correct then this if the wrong thing. The only unaffected architecture would
appear to be m32r.
This patch replaces the assertion failures with if statements that return
FFI_BAD_ABI. I think all architecture are covered but do not have access to
anything except x86_64 hardware.
--- libffi/src/mips/ffi.c.dist 2009-08-09 16:16:19.016509533 +0100
+++ libffi/src/mips/ffi.c 2009-08-09 16:17:03.912006032 +0100
@@ -573,6 +573,12 @@
void * fn;
char *clear_location = (char *) codeloc;
+ /* Reject if bad ABI */
+ if (cif == NULL)
+return FFI_BAD_ABI;
+ if (cif->abi < FFI_FIRST_ABI || cif->abi >= FFI_LAST_ABI)
+return FFI_BAD_ABI;
+
#if defined(FFI_MIPS_O32)
FFI_ASSERT(cif->abi == FFI_O32 || cif->abi == FFI_O32_SOFT_FLOAT);
fn = ffi_closure_O32;
--- libffi/src/sparc/ffi.c.dist 2009-08-09 16:16:19.476512080 +0100
+++ libffi/src/sparc/ffi.c 2009-08-09 16:27:44.904006388 +0100
@@ -447,7 +447,8 @@
#ifdef SPARC64
/* Trampoline address is equal to the closure address. We take advantage
of that to reduce the trampoline size by 8 bytes. */
- FFI_ASSERT (cif->abi == FFI_V9);
+ if (cif == NULL || c->abi != FFI_V9)
+return FFI_BAD_ABI;
fn = (unsigned long) ffi_closure_v9;
tramp[0] = 0x83414000; /* rd %pc, %g1*/
tramp[1] = 0xca586010; /* ldx [%g1+16], %g5 */
@@ -456,7 +457,8 @@
*((unsigned long *) &tramp[4]) = fn;
#else
unsigned long ctx = (unsigned long) codeloc;
- FFI_ASSERT (cif->abi == FFI_V8);
+ if (cif == NULL || c->abi != FFI_V9)
+return FFI_BAD_ABI;
fn = (unsigned long) ffi_closure_v8;
tramp[0] = 0x0300 | fn >> 10;/* sethi %hi(fn), %g1 */
tramp[1] = 0x0500 | ctx >> 10; /* sethi %hi(ctx), %g2 */
--- libffi/src/sh/ffi.c.dist2009-08-09 16:16:19.664507713 +0100
+++ libffi/src/sh/ffi.c 2009-08-09 16:23:07.992004879 +0100
@@ -463,7 +463,9 @@
unsigned int *tramp;
unsigned int insn;
- FFI_ASSERT (cif->abi == FFI_GCC_SYSV);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif->abi != FFI_GCC_SYSV)
+return FFI_BAD_ABI;
tramp = (unsigned int *) &closure->tramp[0];
/* Set T bit if the function returns a struct pointed with R2. */
--- libffi/src/pa/ffi.c.dist2009-08-09 16:16:18.848526920 +0100
+++ libffi/src/pa/ffi.c 2009-08-09 16:17:03.912006032 +0100
@@ -626,7 +626,9 @@
UINT32 *tmp;
#endif
- FFI_ASSERT (cif->abi == FFI_PA32);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif->abi != FPI_PA32)
+return FFI_BAD_ABI;
/* Make a small trampoline that will branch to our
handler function. Use PC-relative addressing. */
--- libffi/src/s390/ffi.c.dist 2009-08-09 16:16:18.784508669 +0100
+++ libffi/src/s390/ffi.c 2009-08-09 16:21:26.772005463 +0100
@@ -750,7 +750,9 @@
void *user_data,
void *codeloc)
{
- FFI_ASSERT (cif->abi == FFI_SYSV);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif->abi != FFI_SYSV)
+return FFI_BAD_ABI;
#ifndef __s390x__
*(short *)&closure->tramp [0] = 0x0d10; /* basr %r1,0 */
--- libffi/src/alpha/ffi.c.dist 2009-08-09 16:16:18.724509984 +0100
+++ libffi/src/alpha/ffi.c 2009-08-09 16:17:03.908010391 +0100
@@ -178,6 +178,12 @@
{
unsigned int *tramp;
+ /* Reject if bad ABI */
+ if (cif == NULL)
+return FFI_BAD_ABI;
+ if (cif->abi < FFI_FIRST_ABI || cif->abi >= FFI_LAST_ABI)
+return FFI_BAD_ABI;
+
tramp = (unsigned int *) &closure->tramp[0];
tramp[0] = 0x47fb0401; /* mov $27,$1 */
tramp[1] = 0xa77b0010; /* ldq $27,16($27) */
--- libffi/src/frv/ffi.c.dist 2009-08-09 16:16:18.752505382 +0100
+++ libffi/src/frv/ffi.c2009-08-09 16:17:03.912006032 +0100
@@ -260,6 +260,12 @@
#endif
int i;
+ /* Reject if bad ABI */
+ if (cif == NULL)
+return FFI_BAD_ABI;
+ if (cif->abi < FFI_FIRST_ABI || cif->abi >= FFI_LAST_ABI)
+return FFI_BAD_ABI;
+
fn = (unsigned long) ffi_closure_eabi;
#ifdef __FRV_FDPIC__
--- libffi/src/prep_cif.c.dist 2009-08-09 16:16:19.668507512 +0100
+++ libffi/src/prep_cif.c 2009-08-09 16:17:03.908010391 +0100
@@ -93,7 +93,8 @@
ffi_type **ptr;
FFI_ASSERT(cif != NULL);
- FFI_ASSERT((abi > FFI_FIRST_ABI) && (abi <= FFI_DEFAULT_ABI));
+ if (abi=FFI_LAST_ABI)
+ return FFI_BAD_ABI;
cif->abi = abi;
cif->arg_types = atypes;
--- libffi/src/powerpc/ffi.c.dist 2009-08-09 16:16:18.268505941 +0100
+++ libffi/src/powerpc/ffi.c2009-08-09 16:17:03.916005633 +0100
@@ -948,7 +948,10 @@
#ifdef POWERPC64
void **tramp = (void **) &closure->tramp[0];
- FFI_ASSERT (cif->abi == FFI_LINUX64);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif->abi != FFI_LINUX64)
+return FFI_BAD_ABI;
+
/* Copy function address and TOC from ffi_closure_L
[Bug target/41015] New: [4.4 Regression] SH: miscompilation for sh4-linux
glibc-2.10.1 is not correctly compiled with gcc-4.4.1 for sh4-linux. I attached preproccessed code. Reproduce: sh4-linux-gcc -O2 -fPIC -S strtod_l.i Wrong part is as follows. .L453: mov #64,r13 tst r9,r9 !! add r14,r13 mov.l @(4,r13),r0 #APP ! 1306 "strtod_l.c" 1 mov r11,r5 !! udiv_qrnnd macro swap.w r7,r4 swap.w r5,r6 jsr @r10! call __udiv_qrnnd_16 shll16 r6 swap.w r4,r4 jsr @r10! call __udiv_qrnnd_16 swap.w r1,r8 or r1,r8 ! 0 "" 2 #NO_APP bf/s.L323 mov.l r0,@(4,r13) In this code, "tst r9,r9" is moved to wrong place as if "t" bit is not clobbered in __udiv_qrnnd_16. I guessed that missing "t" bit constraint in udiv_qrnnd macro caused this problem. So I tried following patch, but there was no effect. Index: gcc/longlong.h === --- gcc/longlong.h (revision 150591) +++ gcc/longlong.h (working copy) @@ -982,7 +982,7 @@ " or r1,%0" \ : "=r" (q), "=&z" (r) \ : "1" (n1), "r" (n0), "rm" (d), "r" (&__udiv_qrnnd_16) \ - : "r1", "r2", "r4", "r5", "r6", "pr"); \ + : "r1", "r2", "r4", "r5", "r6", "pr", "t"); \ } while (0) #define UDIV_TIME 80 -- Summary: [4.4 Regression] SH: miscompilation for sh4-linux Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sugioka at itonet dot co dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41015
[Bug target/41015] [4.4 Regression] SH: miscompilation for sh4-linux
--- Comment #1 from sugioka at itonet dot co dot jp 2009-08-09 16:28 --- Created an attachment (id=18330) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18330&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41015
[Bug web/36739] Proposal for clarifications in GCC Bugzilla
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-08-09 16:35 --- >The build-triplet is the most confusing one and I would remove it retaining the host and target fields (with proper descriptions). Except sometimes that information is needed if doing a canadian cross so I would retain it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36739
[Bug libffi/41014] Fix for libffi err_bad_abi test failure
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-09 16:38 --- Patches to gcc should be sent to gcc-patches with a ChangeLog entry following existing practice and a note on how you tested the patch. Note there is a different upstream for libffi somewhere at sourceforge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41014
[Bug tree-optimization/41016] New: ICE in build_int_cst_wide with -O1
The following code ICEs with -O1 on gcc-4.4:
typedef struct _IO_FILE FILE;
void
CompareRNAStructures (FILE * ofp, int start, int L, char *ss_true, char *ss)
{
int i;
float agree = 0.;
float pairs = 0.;
float pairs_true = 0.;
for (i = 0; i < L; i++)
{
pairs_true += 1.;
agree += 1.;
}
if (((int) pairs % 2 != 0) || ((int) pairs_true % 2 != 0)
|| ((int) agree % 2 != 0))
Die
("Error in CompareRNAStrutures(); odd number of paired nucleotides\n");
}
Let me know what other information would be helpful.
--
Summary: ICE in build_int_cst_wide with -O1
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at halcy0n dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41016
[Bug tree-optimization/41016] [4.4/4.5 Regression] ICE in build_int_cst_wide with -O1
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-09 17:37 --- Confirmed. We build a integer constant of floating-point type. From tree-ifcombine, thus, mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail|4.4.0 4.4.1 |4.4.0 4.4.1 4.5.0 Known to work||4.3.4 Last reconfirmed|-00-00 00:00:00 |2009-08-09 17:37:41 date|| Summary|ICE in build_int_cst_wide |[4.4/4.5 Regression] ICE in |with -O1|build_int_cst_wide with -O1 Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41016
[Bug tree-optimization/41016] [4.4/4.5 Regression] ICE in build_int_cst_wide with -O1
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-09 17:47 --- A tuplification bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41016
[Bug target/41017] New: regparm=3 passes structures inconsistently
regparm=3 passes structures in registers if they fit there. There is
inconsistency in this rule, if structure contains only float or only double
type, it is passed on the stack.
Example:
__attribute__((regparm(3))) void function(struct s s);
now, the argument passing varies wildly depending on the definition of "struct
s".
struct s { float a; float b; } --- passed in registers
struct s { float a; } --- passed on stack
struct s { float a[1]; } --- passed on stack
struct s { float a[2]; } --- passed in registers
struct s { float a; int b; } --- passed in registers
struct s { float a[1]; float b[0]; } --- passed on stack
struct s { double a; } --- passed on stack
struct s { struct { float a; }; } --- passed on stack
union s { float a; } --- passed in registers
struct s { union { float a; }; } --- passed in registers
struct s { struct { float a; } q[1]; } --- passed on stack
struct s { long double a; } --- passed on stack
struct s { union { long double a; } } --- passed in registers
--- actually it seems that if the structure contains only one floating point
entry inside other structures or arrays (not unions), it is passed on stack,
not in registers ... otherwise it is passed in registers.
Hardly anyone deliberately designed it this way. Gcc internals are exposed to
the ABI! If the structure contains just one entry, its mode is different from
BLKmode and it takes different path in function_arg_advance_32 and
function_arg_32.
I'd propose to change it so that structures are always passed in registers, the
current state makes it hard or impossible to do any automatic marshalling of
arguments for regparm functions. I found this bug when trying to extend libffi
to handle regparm=3 calling convention.
(another way to fix this is to pass structures always on the stack, maybe it
would generate faster code, but it would create more ABI-incompatibility pain)
--
Summary: regparm=3 passes structures inconsistently
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
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=41017
[Bug target/41017] regparm=3 passes structures inconsistently
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-08-09 18:40 --- Created an attachment (id=18331) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18331&action=view) a proposed patch. Fixed bug 41013 as well. Change it so that all the aggregate types take common code path, so passing of the structure no longer depends on its content. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41017
[Bug bootstrap/41018] New: bootstrap broken on FreeBSD powerpc
This patch: http://gcc.gnu.org/ml/gcc-cvs/2008-10/msg00471.html broke bootstrap on powerpc targets which do not include svr4.h. SVR4_ASM_SPEC is never defined. This patch restores bootstrap, tested on 4.4 branch and head. http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00421.html Approval for this patch is here: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00203.html I will commit the patch nn both trees, 4.4 and main, with an adjusted ChangeLog within 24 hours if there are no objections. -- Summary: bootstrap broken on FreeBSD powerpc Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: andreast at gcc dot gnu dot org ReportedBy: andreast at gcc dot gnu dot org GCC build triplet: powerpc-*-freebsd8.0 GCC host triplet: powerpc-*-freebsd8.0 GCC target triplet: powerpc-*-freebsd8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41018
[Bug bootstrap/41018] bootstrap broken on FreeBSD powerpc
-- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-09 19:05:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41018
[Bug target/41017] regparm=3 passes structures inconsistently
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-09 19:10 --- Can you check if regparm(3) behavior ever changed during the gcc releases? > Hardly anyone deliberately designed it this way. Gcc internals are exposed to > the ABI! well, regparm(n) is certainly out of the psABI and I am not sure the regparm ABI has a proper specification anywhere. But indeed it is exposed as ABI so we shouldn't change it if we didn't do so repeatedly in the past. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41017
[Bug target/41017] regparm=3 passes structures inconsistently
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-09 19:13 --- Btw, the documentation claims regparm only affects integral parameters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41017
[Bug tree-optimization/41016] [4.4/4.5 Regression] ICE in build_int_cst_wide with -O1
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-09 20:10 --- Subject: Bug 41016 Author: rguenth Date: Sun Aug 9 20:10:41 2009 New Revision: 150595 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150595 Log: 2009-08-09 Richard Guenther PR tree-optimization/41016 * tree-ssa-ifcombine.c (get_name_for_bit_test): Fix tuplification bug. (operand_precision): Remove. (integral_operand_p): Likewise. (recognize_single_bit_test): Adjust. * gcc.c-torture/compile/pr41016.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr41016.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ifcombine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41016
[Bug c++/41019] New: Variate_generator with mt19937 and normal_distribution produces wrong sequence for "-O3".
The attached code, we compiled with "-O3", gives an incorrect sequence (and different from the sequence without optimization or -O1 or -O2). This problem was discovered due to incorrect statistical behavior of a Monte Carlo calculation (not attached). -- Summary: Variate_generator with mt19937 and normal_distribution produces wrong sequence for "-O3". Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m_albert137 at yahoo dot com GCC host triplet: x86_64-unknown-linux-gnu Core2 Q9550 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
[Bug c++/41019] Variate_generator with mt19937 and normal_distribution produces wrong sequence for "-O3".
--- Comment #1 from m_albert137 at yahoo dot com 2009-08-09 21:02 --- Created an attachment (id=18332) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18332&action=view) Example code When compiled below -O3 (e.g., -O2), this code gives: 0 -0.29321891723895837645 1 0.25316081895796688217 2 -0.057085487765685671846 with -O3: 0 0.31678484080597951733 1 0.27675012391718101235 2 0.14034606328371523887 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
[Bug c++/41019] Variate_generator with mt19937 and normal_distribution produces wrong sequence for "-O3".
--- Comment #2 from m_albert137 at yahoo dot com 2009-08-09 21:05 --- Created an attachment (id=18333) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18333&action=view) Configuration information from "g++ -O3 -v --save-temps t.cpp" Config information from "-v" compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
[Bug c++/41019] Variate_generator with mt19937 and normal_distribution produces wrong sequence for "-O3".
--- Comment #3 from m_albert137 at yahoo dot com 2009-08-09 21:09 --- Created an attachment (id=18334) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18334&action=view) "savetemps" file from "g++ -O3 -v --save-temps t.cpp" The savetemps file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
[Bug target/41017] regparm=3 passes structures inconsistently
--- Comment #4 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-08-09 21:16 --- Regparm changed between gcc 3.x -> 4.x (I remember it too painfully, I had to rewrite some assembler files). In 3.x, all arguments were incrementing register count, even if they were on stack, if you had (float f1, int i2, int i3), f1 was on stack, i2 was in EDX and i3 was in ECX. In 4.x it changed so that f1 is on stack, i2 is in EAX and i3 is in EDX. Similarly, (double f1, int i2, int i3) was (stack, ECX, stack) in 3.x and (stack, EAX, EDX) in 4.x. If we change it so that structures are always in registers, it will be the least painful thing, because they already are in registers almost always (except few pathological cases, like struct containing only float or double). So it won't likely hurt too much, because few programmers rely on regparm(3) for external ABI, few programmers pass structures directly and few programmers declare structure with only one member. And the programmer will be hurt only if he does all these three things. If you want to change it to be consistent with the documentation (not with existing implementation) and pass structures always on stack, I wouldn't object against it. Just don't change it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41017
[Bug c++/41020] New: Can't declare an extern "C" friend.
Attempting to declare a previously-declared extern "C" function as a friend
within a class definition fails with an error that the friend declaration
ambiguates the original extern "C" declaration. It appears that the friend
declaration is taken as an overload with "C++" linkage, since G++ then
complains that the class members are private within the context of the extern
"C" function definition.
$ cat friend.cxx
extern "C"
{
int fork (void);
};
class frok
{
int this_errno;
friend int fork (void);
};
extern "C" int
fork (void)
{
frok grouped;
return grouped.this_errno;
}
$ g++-4 -c friend.cxx -o friend.o
friend.cxx:10:24: error: new declaration 'int fork()'
friend.cxx:4:7: error: ambiguates old declaration 'int fork()'
friend.cxx: In function 'int fork()':
friend.cxx:9:7: error: 'int frok::this_errno' is private
friend.cxx:17:18: error: within this context
$
According to, for example, "C++ in a nutshell"
(http://books.google.co.uk/books?id=91JTA9B_m44C&pg=PA170&lpg=PA170&dq=friend+%22storage+class%22&source=bl&ots=HrN4X1Y5wu&sig=N9rnB8r_YnxbH2hiWGqtbAWbWyk&hl=en&ei=oDt_SqmvGJKNjAe9k93wAQ&sa=X&oi=book_result&ct=result&resnum=5#v=onepage&q=friend%20%22storage%20class%22&f=false),
a function in a friend declaration should "retain its original linkage" when it
has already been declared. That is referring to the case of applying a storage
class specifier (static) to the prior declaration that isn't syntactically
valid within a friend declaration, but it seems like it should apply here too;
the linkage should still be retained, even though I'm not changing the
storage-class specifier.
There may be some reason why this isn't valid C++, but I think it's probably
a weakness in the parsing of friend declarations.
$ g++-4 -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /gnu/gcc/gcc-patched/configure --prefix=/opt/gcc-tools -v
--wit
h-gmp=/usr --with-mpfr=/usr --enable-bootstrap
--enable-version-specific-runtime
-libs --enable-static --enable-shared --enable-shared-libgcc
--disable-__cxa_ate
xit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions
--disabl
e-symvers --disable-libjava --disable-interpreter --program-suffix=-4
--disable-
libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686
--with-tune=generic CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4
--with-ecj-jar=/usr/share/java/ecj.jar LD=/opt/gcc-tools/bin/ld.exe
LD_FOR_TARGE
T=/opt/gcc-tools/bin/ld.exe AS=/opt/gcc-tools/bin/as.exe
AS_FOR_TARGET=/opt/gcc-
tools/bin/as.exe --disable-win32-registry --disable-libgcj-debug
--enable-langua
ges=c,c++,ada
Thread model: posix
gcc version 4.5.0 20090730 (experimental) (GCC)
--
Summary: Can't declare an extern "C" friend.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug c++/41020] Can't declare an extern "C" friend.
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-09 21:31 --- (In reply to comment #0) > $ g++-4 -v Yuck, that got horribly wrapped. Here it is again, hopefully formatted a little better this time: Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/gcc-patched/configure --prefix=/opt/gcc-tools -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --disable-symvers --disable-libjava --disable-interpreter --program-suffix=-4 --disable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 --with-ecj-jar=/usr/share/java/ecj.jar LD=/opt/gcc-tools/bin/ld.exe LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe AS=/opt/gcc-tools/bin/as.exe AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe --disable-win32-registry --disable-libgcj-debug --enable-languages=c,c++,ada Thread model: posix gcc version 4.5.0 20090730 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug tree-optimization/41016] [4.4/4.5 Regression] ICE in build_int_cst_wide with -O1
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-09 21:39 --- Subject: Bug 41016 Author: rguenth Date: Sun Aug 9 21:39:19 2009 New Revision: 150598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150598 Log: 2009-08-09 Richard Guenther PR tree-optimization/41016 * tree-ssa-ifcombine.c (get_name_for_bit_test): Fix tuplification bug. (operand_precision): Remove. (integral_operand_p): Likewise. (recognize_single_bit_test): Adjust. * gcc.c-torture/compile/pr41016.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr41016.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-ifcombine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41016
[Bug tree-optimization/41016] [4.4/4.5 Regression] ICE in build_int_cst_wide with -O1
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-09 21:39 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.4.0 4.4.1 4.5.0 |4.4.0 4.4.1 Known to work|4.3.4 |4.3.4 4.4.2 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41016
[Bug middle-end/31844] Incorrect source locations and number of warnings for unsupported visibility attribute
--- Comment #2 from davek at gcc dot gnu dot org 2009-08-09 22:03 --- Still present, although the location has slipped slightly for the warnings on the function declarations with no body. $ g++ -S vis.cpp -o vis.asm vis.cpp: In function 'int foo(int)': vis.cpp:11: warning: visibility attribute not supported in this configuration; i gnored vis.cpp: At global scope: vis.cpp:30: warning: visibility attribute not supported in this configuration; i gnored vis.cpp:30: warning: visibility attribute not supported in this configuration; i gnored Confirming, but lowering the severity and priority. -- davek at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2009-08-09 22:03:51 date|| Version|4.2.0 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31844
[Bug target/41015] [4.4/4.5 Regression] SH: miscompilation for sh4-linux
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-08-09 22:44 --- I've confirmed that 4.5 has the same problem and 4.3 doesn't. > In this code, "tst r9,r9" is moved to wrong place as if > "t" bit is not clobbered in __udiv_qrnnd_16. > > I guessed that missing "t" bit constraint in udiv_qrnnd macro > caused this problem. So I tried following patch, but there was > no effect. I think you are right. Also your patch solves the problem in my tests. Did you make strtod_l.i change as your patch does for longlong.h? -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.4.1 4.5.0 Known to work||4.3.4 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2009-08-09 22:44:43 date|| Summary|[4.4 Regression] SH:|[4.4/4.5 Regression] SH: |miscompilation for sh4-linux|miscompilation for sh4-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41015
[Bug target/41021] New: [ARM] Suboptimal code generated to store a struct
A simple function to store a small struct ends up writing the struct to
memory twice unnecessarily (plus writing it for real the third time).
The function's args are passed in r0-r3 (with r1-r3 being the struct).
It compiles to a sequence containing the following loads and stores,
among others:
[1] stmfd sp!, {r0, r1, r2, r4, r5}
[2] stmia r0, {r1, r2, r3}
[3] ldmia r0, {r0, r1, r2}
[4] stmia r3, {r0, r1, r2}
[5] ldmfd sp!, {r1, r2, r3, r4, r5}
[2] and [3] seem the most egregious. (r0 points to stack space.)
However, [1] and [5] are odd too; I don't know why it's taking the time
to preserve r1-r3. Line [4] is the line that's actually necessary.
Adjusting the optimization level can eliminate the extra saves in [1],[5],
but all optimization levels seem to perform the extra save in [2],[3].
Environment:
System: OpenBSD underhill..org 4.4 UNDERHILL#1 i386
host: i386-unknown-openbsd4.4
build: i386-unknown-openbsd4.4
target: arm-none-elf
configured with: ../gcc-4.4.1/configure --with-system-zlib --disable-nls
--target=arm-none-elf --prefix=/usr/local/cross/arm-elf --enable-languages=c
--with-cpu=arm7tdmi --with-newlib --with-gmp=/usr/local --with-mpfr=/usr/local
--with-gnu-as --with-gnu-ld --disable-libssp
--enable-version-specific-runtime-libs
How-To-Repeat:
$ arm-none-elf-gcc -mcpu=arm7tdmi -mthumb-interwork -Os -Wa,-alhd -c
rstore.c
struct queue {
unsigned short used;
struct queue_entry {
unsigned short aux;
void (*func)(int);
int arg;
} entries[16];
};
void enqueue(struct queue *q, struct queue_entry ent)
{
q->entries[q->used++] = ent;
}
--
Summary: [ARM] Suboptimal code generated to store a struct
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wiml at dot org
GCC build triplet: i386-unknown-openbsd4.4
GCC host triplet: i386-unknown-openbsd4.4
GCC target triplet: arm-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41021
[Bug target/41015] [4.4/4.5 Regression] SH: miscompilation for sh4-linux
--- Comment #3 from sugioka at itonet dot co dot jp 2009-08-10 04:47 --- I found that there is a copy of longlong.h in glibc/stdlib. After fixing it, it worked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41015
[Bug target/41015] [4.4/4.5 Regression] SH: miscompilation for sh4-linux
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-08-10 05:08 --- Ah, I see. Could you please send that patch to libc list? I'll fix gcc/longlong.h on gcc trunk and 4.4 branch after the usual tests. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||sh*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41015
[Bug target/41021] [ARM] Suboptimal code generated to store a struct
--- Comment #1 from wiml at dot org 2009-08-10 05:18 --- Workaround notes: Changing the structure assignment to multiple assignments, one for each field, produces noticeably better code; and changing the argument list to pass the structure fields individually produces code that looks good to me (even though the same values are passed in the same registers). So I guess this is a missed opportunity for SRA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41021
