[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #2 from ayers at gcc dot gnu dot org 2009-03-16 07:27 --- So the situation seems to be: - libobjc is a static library. - libfoo is a dll statically linked against libobjc. - test is program which is linked both against libfoo and libobjc. I'm guessing here since I have no experience mingw and with linking libobjc statically, but I could imagine that you may have two copies of libobjc in your executable each with it's own set of runtime structures, which may cause confusion. Is there any reason why libobjc isn't dynamically linked if you going to use DLL's? Note I'll still need to build a mingw compiler and look into the auto-import warning and I'm not sure when I'll get around to it, so I haven't assigned the bug yet in case someone else can easily test it. Cheers, David -- ayers at gcc dot gnu dot org changed: What|Removed |Added CC||ayers at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
--- Comment #25 from jakub at gcc dot gnu dot org 2009-03-16 07:52 --- I'd say first try to add noinline attribute on all callers of num_positive, if it fails even with those, add also __attribute__((__optimize__(0))) to them one by one. If the noinline attribute to those makes the miscompilation go away, search one by one which one it is and retry with all callers of that function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug tree-optimization/39455] [4.3/4.4 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-16 08:15 ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options -O2 -fprefetch-loop-arrays } */
void
foo (char *x, unsigned long y, unsigned char *z)
{
unsigned int c[256], *d;
for (d = c + 1; d c + 256; ++d)
*d += d[-1];
x[--c[z[y]]] = 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
[Bug tree-optimization/39455] [4.3/4.4 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073
--- Comment #8 from pinskia at gmail dot com 2009-03-16 08:28 ---
Subject: Re: [4.3/4.4 Regression] ICE : in compare_values_warnv, at
tree-vrp.c:1073
Sent from my iPhone
On Mar 16, 2009, at 1:15 AM, jakub at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-16
08:15 ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options -O2 -fprefetch-loop-arrays } */
void
foo (char *x, unsigned long y, unsigned char *z)
{
unsigned int c[256], *d;
for (d = c + 1; d c + 256; ++d)
*d += d[-1];
x[--c[z[y]]] = 0;
Hmm. Could this be the char-- bug? Where the front-end/gimplifier does
not promote that to int?
Thanks,
Andrew Pinski
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
[Bug rtl-optimization/30688] Branch registers loaded too late on ia64
--- Comment #5 from steven at gcc dot gnu dot org 2009-03-16 08:46 --- Can someone point me to the IA64 optimiation manuals mentioned in comment #0? I'm looking for some answers, for example: * Which branch registers can I use? bt-load can actually perform register renaming. It has to, of course, because bt-load runs after the register allocator. The register allocator prefers to always use tr0 on sh64, and it probably always tries to use the same branch register on ia64 too. So register renaming is a Good Thing here. But which regs can I use on IA64? * What does as early as possible mean in comment #0? Are there recommendations for what is considered too early (for example due to interactions with calls and such)? * What happens if a value is assigned to a branch register on IA64? Is the prefetcher always triggered? What is the latency of the prefetching after a branch register has been assigned a value? * Is there a possibility to add a prediction hint to say branch register A is more likely to be used than branch register B when multiple branch registers are assigned a value in the same basic block? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30688
[Bug tree-optimization/39455] [4.3/4.4 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073
--- Comment #9 from jakub at gcc dot gnu dot org 2009-03-16 08:49 --- No, this seems to be aprefetch's pass fault, at least in quick skim *.cunroll seems to be ok typewise, while *.aprefetch has: D.1649_44 = c + 1024; D.1650_43 = (long unsigned int) D.1649_44; if (c[2] = D.1650_43) D.1650 is long unsigned int and c is unsigned int c[256], so obviously the comparison above is wrong. Will try to debug it. -- 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|2009-03-13 14:03:54 |2009-03-16 08:49:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
[Bug driver/39356] assembler isn't called
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-03-16 09:15 --- (In reply to comment #8) (In reply to comment #7) The following patch solves this problem and prevents the name collision for 32 and 64 bits win32 systems. ChangeLog * config/i386/i386.md (allocate_stack_worker_32): Use ___gnu_chkstk. (allocate_stack_worker_64): Likewise. * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca. (___chkstk): Renamed to ___gnu_chkstk. No. This breaks backward compatibility. Static libraries and objects built with current and older versions of gcc will not be able to resolve references to __alloca or ___chkstk.Why not add labels with the new names as aliases rather than replace. Danny Ok, for 32-bits this makes sense to keep the old symbol names. Beside there is still a chance that a user uses the manually the chkstk.o file, which can lead to undefined behaviour (at least if the user code references __chkstk). For 64-bit I prefer to avoid those old names and simply rename it. Is this ok for you? I'll file then a patch for it? Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug target/39115] [4.3 Regression] Value of variable is not read again
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 Known to work|4.2.4 |4.2.4 4.4.0 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39115
[Bug tree-optimization/39455] [4.3/4.4 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-16 09:43 ---
Seems tree-ssa-loop-niter.c has a lot of p+ issues. The following untested
patch fixes just the number_of_iterations_lt_to_ne bugs and fixes this
testcase:
--- gcc/tree-ssa-loop-niter.c.jj2009-03-04 20:06:31.0 +0100
+++ gcc/tree-ssa-loop-niter.c 2009-03-16 10:30:39.0 +0100
@@ -699,8 +699,10 @@ number_of_iterations_lt_to_ne (tree type
iv0-base = iv1-base + MOD. */
if (!iv0-no_overflow !integer_zerop (mod))
{
- bound = fold_build2 (MINUS_EXPR, type,
+ bound = fold_build2 (MINUS_EXPR, type1,
TYPE_MAX_VALUE (type1), tmod);
+ if (POINTER_TYPE_P (type))
+ bound = fold_convert (type, bound);
assumption = fold_build2 (LE_EXPR, boolean_type_node,
iv1-base, bound);
if (integer_zerop (assumption))
@@ -708,6 +710,11 @@ number_of_iterations_lt_to_ne (tree type
}
if (mpz_cmp (mmod, bnds-below) 0)
noloop = boolean_false_node;
+ else if (POINTER_TYPE_P (type))
+ noloop = fold_build2 (GT_EXPR, boolean_type_node,
+ iv0-base,
+ fold_build2 (POINTER_PLUS_EXPR, type,
+ iv1-base, tmod));
else
noloop = fold_build2 (GT_EXPR, boolean_type_node,
iv0-base,
@@ -723,6 +730,8 @@ number_of_iterations_lt_to_ne (tree type
{
bound = fold_build2 (PLUS_EXPR, type1,
TYPE_MIN_VALUE (type1), tmod);
+ if (POINTER_TYPE_P (type))
+ bound = fold_convert (type, bound);
assumption = fold_build2 (GE_EXPR, boolean_type_node,
iv0-base, bound);
if (integer_zerop (assumption))
@@ -730,6 +739,13 @@ number_of_iterations_lt_to_ne (tree type
}
if (mpz_cmp (mmod, bnds-below) 0)
noloop = boolean_false_node;
+ else if (POINTER_TYPE_P (type))
+ noloop = fold_build2 (GT_EXPR, boolean_type_node,
+ fold_build2 (POINTER_PLUS_EXPR, type,
+ iv0-base,
+ fold_unary (NEGATE_EXPR,
+ type1, tmod)),
+ iv1-base);
else
noloop = fold_build2 (GT_EXPR, boolean_type_node,
fold_build2 (MINUS_EXPR, type1,
but e.g. number_of_iterations_le doesn't look correct at all as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #19 from falk at debian dot org 2009-03-16 10:24 --- (In reply to comment #18) Well, I've got bad news for you anyway: it seems that the problem affects gcc-4.3.2 too: it seems it's reproducible in another app, however one potentially much harder to debug. Please read http://bugs.winehq.org/show_bug.cgi?id=17406 and give some ideas for a test. The fact that -fno-inline helps gives only very little indication that this is actually the same problem. In any case, I don't think there's really anything we can do without a complete test case (that is, a single file with a main() that exits with 0 when everything's fine and 1 otherwise). This is very difficult to do for someone who doesn't know the freeciv codebase. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #3 from js-gcc at webkeks dot org 2009-03-16 11:24 --- When the target is mingw32, it seems that libobjc is only built as a static library. This isn't a bad idea after all, because I guess no win32 user has a libobjc.so installed somewhere, so you would need to ship that file with every binary produced from ObjC-sources. I heard from the GNUstep guys that they had the same problem until they linked libobjc dynamically. But IMO, this is only a workaround - it should also work if libobjc is linked statically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2009-03-16 11:35 --- Would you please attach a preprocessed testcase so one can reproduce the problem. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #4 from ayers at gcc dot gnu dot org 2009-03-16 11:41 --- Well, consider me a GNUstep guy yet I'm definitely not a GNUstep on MinGW32 guy. (Or anything on MinGW32... which is why this a bit difficult, yet I'm trying to help maintain libobjc so I'll see what I can do.) Could you please add a link to that discussion? It seems that I missed it. I've found a few mingw32 discussions searching the archive but nothing recent wrt static linking. In the meantime I'm learning how to setup a cross tool chain... please be patient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #5 from js-gcc at webkeks dot org 2009-03-16 11:46 --- It would be hard to link to that discussion as that was IRL on FOSDEM in the GNUstep Dev Room :). I reported that bug once on the mingw32 list, but they wouldn't really care about it. After speaking to Nicola Pero on FOSDEM, I decided that it'd be best to file a bug for libobjc - and so I did :). For building mingw32 with gcc 4, you could have a look at these Port files I wrote: https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-api https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-binutils https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-gcc https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-runtime -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug debug/37890] Incorrect nesting for DW_TAG_imported_declaration
--- Comment #1 from jan dot kratochvil at redhat dot com 2009-03-16 14:24 --- Verified as the problem exists on GNU C++ 4.4.0 20090315 (experimental). Tried also non-main function and slightly complicated function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37890
[Bug debug/39471] New: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
Regression from g++-4.3 for GNU C++ 4.4.0 20090315 (experimental)
(+also for 4.4.0 20090313 (Red Hat 4.4.0-0.26))
For full namespace import one should use DW_TAG_imported_module.
1:namespace A
2:{
3: int i = 1;
4:}
5:
6:int
7:main ()
8:{
9: using namespace A;
10: i = 2;
11: return 0;
12:}
Using g++-4.4 DWARF one must use `A::i' at `main' in the debugger.
The whole namespace `A' should be imported there instead.
WRONG g++-4.4 debuginfo:
c DW_AT_producer: (indirect string, offset: 0x0): GNU C++ 4.4.0
20090315 (experimental)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x7d): main
251: Abbrev Number: 3 (DW_TAG_lexical_block)
52 DW_AT_low_pc : 0x4
5a DW_AT_high_pc : 0x13
362: Abbrev Number: 4 (DW_TAG_imported_declaration)
65 DW_AT_name: A
67 DW_AT_import : 0x74 [Abbrev Number: 6 (DW_TAG_namespace)]
174: Abbrev Number: 6 (DW_TAG_namespace)
75 DW_AT_name: A
27d: Abbrev Number: 7 (DW_TAG_variable)
7e DW_AT_name: i
82 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x74): _ZN1A1iE
Correct g++-4.3 debuginfo:
c DW_AT_producer: (indirect string, offset: 0x0): GNU C++ 4.3.2
20081105 (Red Hat 4.3.2-7)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x80): main
251: Abbrev Number: 3 (DW_TAG_imported_module)
54 DW_AT_import : 0x60 [Abbrev Number: 5 (DW_TAG_namespace)]
160: Abbrev Number: 5 (DW_TAG_namespace)
61 DW_AT_name: A
269: Abbrev Number: 6 (DW_TAG_variable)
6a DW_AT_name: i
6e DW_AT_MIPS_linkage_name: (indirect string, offset: 0x77): _ZN1A1iE
72 DW_AT_type: 0x59
It causes regressions on gdb.cp/namespace-using.exp for the GDB project Archer.
--
Summary: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug tree-optimization/39455] [4.3/4.4 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-16 16:07 --- Subject: Bug 39455 Author: jakub Date: Mon Mar 16 16:07:07 2009 New Revision: 144885 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144885 Log: PR tree-optimization/39455 * tree-ssa-loop-niter.c (number_of_iterations_lt_to_ne): Fix types mismatches for POINTER_TYPE_P (type). (number_of_iterations_le): Likewise. * gcc.dg/pr39455.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr39455.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
[Bug tree-optimization/39455] [4.3 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-16 16:27 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.3 4.4.0 |4.3.3 Known to work|4.1.2 4.2.4 |4.1.2 4.2.4 4.4.0 Summary|[4.3/4.4 Regression] ICE : |[4.3 Regression] ICE : in |in compare_values_warnv, at |compare_values_warnv, at |tree-vrp.c:1073 |tree-vrp.c:1073 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
[Bug target/39472] New: Add -mabi=[ms|sysv]
UEFI uses MS x64 calling convention. It will be nice to support -mabi=ms on Linux so that we can use gcc 4.4 to build UEFI applications on Linux. -- Summary: Add -mabi=[ms|sysv] Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
[Bug c/39375] asm with a =X output overwrites the output
--- Comment #4 from balrogg at gmail dot com 2009-03-16 16:53 --- Reopening because int params; __asm__ (xxx : =X (params)); and int params[1]; __asm__ (xxx : =X (params[0])); still produce different output in a way that is undocumented. -- balrogg at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39375
[Bug c/39375] asm with a =X output overwrites the output
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-03-16 17:02 --- (In reply to comment #4) Reopening because int params; __asm__ (xxx : =X (params)); and int params[1]; __asm__ (xxx : =X (params[0])); still produce different output in a way that is undocumented. How so? =X (params[0]) says it can be in memory which means params is addressable. This is documented as =X really means =rfm (plus extra constraints which don't correspond to r, f, or m). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39375
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
--- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-16 17:20 --- Subject: Re: [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c Since revision 144529: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg0.html is the cause and it is inline related, I suggest you use revision 144529 as base and revert the tree-inline.c change to see if it fixes libcpp/expr.c. The regressions don't occur with revision 144874 if I replace tree-inline.c with the version from revision 144528. http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg01655.html 144529 significantly changed the amount of inlining. Thus, it's very difficult to determine the location of the miscompilation in expr.o by comparing the difference in code between 144528 and 144529. It's also my impression that the miscompilation has moved in subsequent revisions. The miscompilation is related to the generation of dwarf2 debug information as it doesn't appear with hpux. While it may be that the changes to tree-inline.c are not directly responsilble for the regressions, they are definitely a contributing factor. I note that Jan does have an account on a hppa linux machine, gsyprf11.external.hp.com. Probably, I should rebuild 144529 and try Jakub's suggestions. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
--- Comment #27 from hjl dot tools at gmail dot com 2009-03-16 17:26 --- (In reply to comment #26) Probably, I should rebuild 144529 and try Jakub's suggestions. You need the fix for PR 39345 on top of revision 144529. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug target/39473] New: Typo in untyped_call in i386.md
untyped_call in i386.md has ix86_expand_call ((TARGET_FLOAT_RETURNS_IN_80387 ? gen_rtx_REG (XCmode, FIRST_FLOAT_REG) : NULL), operands[0], const0_rtx, GEN_INT ((DEFAULT_ABI == SYSV_ABI ? X86_64_SSE_REGPARM_MAX : X64_SSE_REGPARM_MAX) - 1), NULL, 0); It doesn't look right for 32bit. Shouldn't it be GEN_INT (SSE_REGPARM_MAX) instead? -- Summary: Typo in untyped_call in i386.md Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug target/39473] Typo in untyped_call in i386.md
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-16 18:26 ---
Also
void
ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
rtx callarg2,
rtx pop, int sibcall)
{
rtx use = NULL, call;
enum calling_abi function_call_abi;
if (callarg2 INTVAL (callarg2) == -2)
function_call_abi = MS_ABI;
else
function_call_abi = SYSV_ABI;
doesn't look right either. Where does -2 come from? Shouldn't it check
TARGET_64BIT?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||ktietz at onevision dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug target/39473] Typo in untyped_call in i386.md
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-16 18:40 ---
(In reply to comment #1)
Also
void
ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
rtx callarg2,
rtx pop, int sibcall)
{
rtx use = NULL, call;
enum calling_abi function_call_abi;
if (callarg2 INTVAL (callarg2) == -2)
function_call_abi = MS_ABI;
else
function_call_abi = SYSV_ABI;
doesn't look right either. Where does -2 come from? Shouldn't it check
TARGET_64BIT?
This was added by revision 142859:
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00559.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||jh at suse dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug target/39473] Typo in untyped_call in i386.md
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-16 18:47 --- (In reply to comment #0) untyped_call in i386.md has ix86_expand_call ((TARGET_FLOAT_RETURNS_IN_80387 ? gen_rtx_REG (XCmode, FIRST_FLOAT_REG) : NULL), operands[0], const0_rtx, GEN_INT ((DEFAULT_ABI == SYSV_ABI ? X86_64_SSE_REGPARM_MAX : X64_SSE_REGPARM_MAX) - 1), NULL, 0); It doesn't look right for 32bit. Shouldn't it be GEN_INT (SSE_REGPARM_MAX) instead? This was changed by revision 136311: http://gcc.gnu.org/ml/gcc-cvs/2008-06/msg00067.html Those changes: @ -1953,9 +1972,22 @@ is also used as the pic register in ELF. So for now, don't allow more than 3 registers to be passed in registers. */ -#define REGPARM_MAX (TARGET_64BIT ? 6 : 3) - -#define SSE_REGPARM_MAX (TARGET_64BIT ? 8 : (TARGET_SSE ? 3 : 0)) +/* Abi specific values for REGPARM_MAX and SSE_REGPARM_MAX */ +#define X86_64_REGPARM_MAX 6 +#define X64_REGPARM_MAX 4 +#define X86_32_REGPARM_MAX 3 + +#define X86_64_SSE_REGPARM_MAX 8 +#define X64_SSE_REGPARM_MAX 4 +#define X86_32_SSE_REGPARM_MAX (TARGET_SSE ? 3 : 0) + +#define REGPARM_MAX (TARGET_64BIT ? (TARGET_64BIT_MS_ABI ? X64_REGPARM_MAX \ +: X86_64_REGPARM_MAX) \ + : X86_32_REGPARM_MAX) + +#define SSE_REGPARM_MAX (TARGET_64BIT ? (TARGET_64BIT_MS_ABI ? X64_SSE_REGPARM_MAX \ +: X86_64_SSE_REGPARM_MAX) \ + : X86_32_SSE_REGPARM_MAX) weren't properly mentioned in ChangeLog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug debug/39474] New: DW_AT_location missing for unused variables even at -O0
It is a regression since gcc-4.3 but it was found only at artificial (GDB)
testcase. Also at -O2 such behavior is even expected.
The variable is considered as optimized-out which should not happen on -O0.
Testcase:
--
int
main (void)
{
int var;
return 0;
}
--
gcc -Wall -g
WRONG gcc-4.4:
c DW_AT_producer: (indirect string, offset: 0xb): GNU C 4.4.0
20090315 (experimental)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x39): main
252: Abbrev Number: 3 (DW_TAG_variable)
53 DW_AT_name: var
59 DW_AT_type: 0x5e
Correct gcc-4.3:
c DW_AT_producer: (indirect string, offset: 0xf): GNU C 4.3.2
20081105 (Red Hat 4.3.2-7)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x36): main
252: Abbrev Number: 3 (DW_TAG_variable)
53 DW_AT_name: var
59 DW_AT_type: 0x61
5d DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20)
--
Summary: DW_AT_location missing for unused variables even at -O0
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
[Bug c++/39475] New: c++0x type-traits should error out in case of incompleteness
The current implementation returns misleading results if used the wrong way. A
simple example is:
#include iostream
struct X;
int main()
{
std::cout __is_abstract(X) std::endl;
}
compiles and prints 0. Things get worse when templates are involved. PR
libstdc++/39405 shows why this can be a real problem. I attach the example code
from 39405 to this PR again.
--
Summary: c++0x type-traits should error out in case of
incompleteness
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
[Bug c++/39475] c++0x type-traits should error out in case of incompleteness
--- Comment #1 from d dot frey at gmx dot de 2009-03-16 19:05 --- Created an attachment (id=17468) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17468action=view) show inconsistency for is_abstract -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
[Bug rtl-optimization/30688] Branch registers loaded too late on ia64
--- Comment #6 from wilson at codesourcery dot com 2009-03-16 19:07 --- Subject: Re: Branch registers loaded too late on ia64 steven at gcc dot gnu dot org wrote: --- Comment #5 from steven at gcc dot gnu dot org 2009-03-16 08:46 --- Can someone point me to the IA64 optimiation manuals mentioned in comment #0? You can find manuals on the Intel web site. You want the Intel Itanium 2 Processor Reference Manual (For Software Development and Optimization). Chapter 7 talks about branch instructions. * Which branch registers can I use? Any one of the 8 special branch registers, class BR_REGS. * What does as early as possible mean in comment #0? The manual says there should be several cycles between the branch register write and the branch for correct prediction. There is probably no too early to worry about, as long as you don't use more than the available 8 registers. You want to avoid reloads here. Some of the regs are call clobbered, some are preserved, and probably some are reserved for call/return. I don't recall all of the ABI details. You can look them up in the manuals. See the Itanium Software Conventions and Runtime Architecture Guide. * What happens if a value is assigned to a branch register on IA64? Is the prefetcher always triggered? What is the latency of the prefetching after a branch register has been assigned a value? This is complicated. I suggest downloading the docs and reading them. * Is there a possibility to add a prediction hint to say branch register A is more likely to be used than branch register B when multiple branch registers are assigned a value in the same basic block? There is separate predication support for each branch register, but I assume this is about priority for prefetching? Yes, there are branch hints for that. See the Itanium Architecture Software Developer's Manual, Volume 1, section 4.5 is for branch instructions. There is a few completer for prefetching a few lines, and a many completer for prefetching many lines. ia64.md uses many for call and return. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30688
[Bug libstdc++/39405] [4.3 regression] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts
--- Comment #27 from d dot frey at gmx dot de 2009-03-16 19:08 --- Thanks Paolo. I've opened PR c++/39475 for the type traits intrinsics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
[Bug c++/39475] c++0x type-traits should error out in case of incompleteness
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-16 19:20 --- Indeed, ICC errors out. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-16 19:20:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
[Bug target/39473] Typo in untyped_call in i386.md
--- Comment #4 from hjl dot tools at gmail dot com 2009-03-16 19:21 --- A patch is posed at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00749.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00749.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug testsuite/37628] gcc.c-torture/execute/pr35456.c is not generic
--- Comment #1 from janis at gcc dot gnu dot org 2009-03-16 19:58 --- Subject: Bug 37628 Author: janis Date: Mon Mar 16 19:58:32 2009 New Revision: 144890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144890 Log: PR testsuite/37628 * gcc.c-torture/execute/pr35456.x: New, skip for vax. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr35456.x Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37628
[Bug testsuite/37630] gcc.dg/20001012-1.c depends on IEEE FP encoding
--- Comment #2 from janis at gcc dot gnu dot org 2009-03-16 19:59 --- Subject: Bug 37630 Author: janis Date: Mon Mar 16 19:59:37 2009 New Revision: 144891 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144891 Log: PR testsuite/37630 * lib/target-supports.exp (check_effective_target_ieee): New. * gcc.c-torture/execute/ieee/ieee.exp: Use it. * gcc.dg/20001012-1.c: Require ieee. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp trunk/gcc/testsuite/gcc.dg/20001012-1.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37630
[Bug testsuite/37960] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #10 from janis at gcc dot gnu dot org 2009-03-16 20:01 --- Subject: Bug 37960 Author: janis Date: Mon Mar 16 20:01:15 2009 New Revision: 144892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144892 Log: PR testsuite/37960 * gcc.dg/pr11492.c: Replace constant and remove xfail. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr11492.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-16 20:55 ---
Created an attachment (id=17469)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469action=view)
gcc44-pr39471.patch
Untested patch. Dodji, any reason why you started emitting
DW_TAG_imported_declaration for this instead of DW_TAG_imported_module?
Also, looking at the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410#c6
comment, I'm wondering about the C++ doesn't allow that usage part in the
comment. Isn't:
namespace A
{
int i = 1;
int j = 2;
}
namespace B
{
int k = 3;
}
int k = 13;
int
main ()
{
using namespace A;
i++;
j++;
k++;
{
using B::k;
k++;
}
return 0;
}
a testcase which needs IMPORTED_DECL with non-NAMESPACE_DECL
IMPORTED_DECL_ASSOCIATED_DECL?
--
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|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug target/39473] Typo in untyped_call in i386.md
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-16 21:00 --- An updated patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00754.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |03/msg00749.html|03/msg00754.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug testsuite/37630] gcc.dg/20001012-1.c depends on IEEE FP encoding
--- Comment #3 from janis at gcc dot gnu dot org 2009-03-16 21:12 --- Subject: Bug 37630 Author: janis Date: Mon Mar 16 21:11:57 2009 New Revision: 144893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144893 Log: Revert patch for PR testsuite/37630. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp trunk/gcc/testsuite/gcc.dg/20001012-1.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37630
[Bug target/39291] _Unwind_Backtrace fails.
--- Comment #6 from pluto at agmk dot net 2009-03-16 21:24 --- i've tested u-dw2.exe on wine and got more info. $ ./u-dw2.exe err:process:start_wineboot failed to start wineboot, err 2 err:process:__wine_kernel_init boot event wait timed out fixme:msvcrt:__lconv_init stub foo:enter bar:enter zoo:enter boom! signalHandler:enter lookupSymbol: 00401887 lookupSymbol: 0040166A signalHandler:longjmp err:seh:raise_exception Unhandled exception code c096 flags 0 addr 0x409461 $ i486-pc-mingw32-objdump -hw u-dw2.exe u-dw2.exe: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn Flags 0 .text 54c4 00401000 00401000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0030 00407000 00407000 5a00 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .rdata0c28 00408000 00408000 5c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 0538 00409000 00409000 2**5 ALLOC 4 .idata0558 0040a000 0040a000 6a00 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .CRT 0034 0040b000 0040b000 7000 2**2 CONTENTS, ALLOC, LOAD, DATA 6 .tls 0008 0040c000 0040c000 7200 2**2 CONTENTS, ALLOC, LOAD, DATA the 0xc096 code means 'EXCEPTION_PRIV_INSTRUCTION' and the 0x409461 points to the .bss section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39291
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-03-16 21:37 --- Thanks although there is still excessive DW_AT_name: 3422: Abbrev Number: 12 (DW_TAG_imported_module) 425 DW_AT_name: A 427 DW_AT_import : 0x113 [Abbrev Number: 2 (DW_TAG_namespace)] DW_AT_name looks as undefined for me for DW_TAG_imported_module and it certainly breaks the current Archer C++ implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug target/39476] New: Typo in ix86_function_regparm in i386.c
ix86_function_regparm in i386.c has
if (TARGET_64BIT)
{
if (ix86_function_type_abi (type) == ix86_abi)
return regparm;
return ix86_abi != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
}
Shouldn't it be
return ix86_abi == SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
--
Summary: Typo in ix86_function_regparm in i386.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39476
[Bug target/39476] Typo in ix86_function_regparm in i386.c
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-16 21:59 ---
It is
if (TARGET_64BIT)
{
if (ix86_function_type_abi (type) == DEFAULT_ABI)
return regparm;
return DEFAULT_ABI != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
}
Shouldn't it be
return DEFAULT_ABI == SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||ktietz at onevision dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39476
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #2 from rob1weld at aol dot com 2009-03-16 22:08 --- My next difficulty (on OpenSolaris) is the lack of a fopencookie() function (and the related support in FILE). I'm now building melt on i686-pc-linux-gnu and running into a few other errors; thus melt does need some fixing, even on a Linux Operating System. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug target/39476] Typo in ix86_function_regparm in i386.c
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-16 22:09 ---
We never change regparm for 64bit. Does this patch
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 144817)
+++ gcc/config/i386/i386.c (working copy)
@@ -4273,17 +4273,15 @@ static int
ix86_function_regparm (const_tree type, const_tree decl)
{
tree attr;
- int regparm = ix86_regparm;
+ int regparm;
static bool error_issued;
if (TARGET_64BIT)
-{
- if (ix86_function_type_abi (type) == DEFAULT_ABI)
-return regparm;
- return DEFAULT_ABI != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
-}
+return (ix86_function_type_abi (type) == SYSV_ABI
+ ? X86_64_REGPARM_MAX : X64_REGPARM_MAX);
+ regparm = ix86_regparm;
attr = lookup_attribute (regparm, TYPE_ATTRIBUTES (type));
if (attr)
{
look OK?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||jh at suse dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39476
[Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange
--- Comment #3 from il dot basso dot buffo at gmail dot com 2009-03-16
22:21 ---
Here's a further reduction:
struct Point
{
int line, col;
Point( int l = -1, int c = 0 ) throw() : line( l ), col( c ) {}
bool operator==( const Point p ) const throw()
{ return ( line == p.line col == p.col ); }
bool operator( const Point p ) const throw()
{ return ( line p.line || ( line == p.line col p.col ) ); }
};
class Basic_buffer
{
protected:
void add_line( const char * const buf, const int len );
public:
Basic_buffer( const Basic_buffer b, const Point p1, const Point p2 );
int characters( const int line ) const throw();
int pgetc( Point p ) const throw();
Point eof() const throw() { return Point( 0, 0 ); }
bool pisvalid( const Point p ) const throw()
{ return ( ( p.col = 0 p.col characters( p.line ) ) || p == eof() );
}
};
class Buffer : public Basic_buffer
{
public:
bool save( Point p1 = Point(), Point p2 = Point() ) const;
};
bool Buffer::save( Point p1, Point p2 ) const
{
if( !this-pisvalid( p1 ) ) p1 = eof();
if( !this-pisvalid( p2 ) ) p2 = eof();
for( Point p = p1; p p2; ) { pgetc( p ); }
return true;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39447
[Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange
--- Comment #4 from il dot basso dot buffo at gmail dot com 2009-03-16
22:24 ---
Bah, here's an even smaller example:
struct Point
{
int line, col;
Point( int l = -1, int c = 0 ) throw() : line( l ), col( c ) {}
bool operator==( const Point p ) const throw()
{ return ( line == p.line col == p.col ); }
bool operator( const Point p ) const throw()
{ return ( line p.line || ( line == p.line col p.col ) ); }
};
class Buffer
{
public:
int characters( const int line ) const throw();
int pgetc( Point p ) const throw();
Point eof() const throw() { return Point( 0, 0 ); }
bool pisvalid( const Point p ) const throw()
{ return ( ( p.col = 0 p.col characters( p.line ) ) || p == eof() );
}
bool save( Point p1 = Point(), Point p2 = Point() ) const;
};
bool Buffer::save( Point p1, Point p2 ) const
{
if( !this-pisvalid( p1 ) ) p1 = eof();
if( !this-pisvalid( p2 ) ) p2 = eof();
for( Point p = p1; p p2; ) { pgetc( p ); }
return true;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39447
Re: [Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange
Thanks for the reduced testcase, it completely went out of my radar (by now my delta script should have finished reducing it as well on the gcc-farm, but I won't even look at it). Thanks again for the reduced case. I will look at the bug now. Sebastian
[Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange
--- Comment #5 from sebpop at gmail dot com 2009-03-16 22:34 --- Subject: Re: ICE in create_data_ref with -O1 -floop-interchange Thanks for the reduced testcase, it completely went out of my radar (by now my delta script should have finished reducing it as well on the gcc-farm, but I won't even look at it). Thanks again for the reduced case. I will look at the bug now. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39447
[Bug debug/39474] DW_AT_location missing for unused variables even at -O0
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-16 22:59 --- Well, it doesn't even have a value assigned. So I consider this a valid optimization for -O0. Does the variable have a location once you inintialize it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
[Bug c++/39429] compiler create bad asm codes.
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 22:53 --- Confirmed. This is a bug in the arith_adjacent_mem pattern that only triggers when the offset to the memory from the base pointer exceeds the range of a simple add instruction (ie more than 1024 bytes). In that case we fall back to emitting two ldr instructions, but fail to consider the case when the first load overwrites the base address. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-16 22:53:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429
[Bug target/39429] compiler create bad asm codes.
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429
Re: [Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange
Hi,
I don't know who coded the overly complicated exclude_component_ref.
In the graphite branch we already cleaned up all this code, but in
trunk we still have it.
Attached is a patch that fixes the problem by looking at whether the
operand contains COMPONENT_REFs before calling the data reference
analysis.
I'm testing the patch on the gcc farm, and will send it to the gcc-patches
once it finishes regstrap.
Sebastian
* graphite.c (exclude_component_ref): Renamed contains_component_ref_p.
(is_simple_operand): Call contains_component_ref_p before calling data
reference analysis that would fail on COMPONENT_REFs.
Index: graphite.c
===
--- graphite.c (revision 144893)
+++ graphite.c (working copy)
@@ -1062,27 +1062,20 @@ loop_affine_expr (basic_block scop_entry
is component_ref. */
static bool
-exclude_component_ref (tree op)
+contains_component_ref_p (tree op)
{
int i;
- int len;
- if (op)
-{
- if (TREE_CODE (op) == COMPONENT_REF)
- return false;
- else
- {
- len = TREE_OPERAND_LENGTH (op);
- for (i = 0; i len; ++i)
- {
- if (!exclude_component_ref (TREE_OPERAND (op, i)))
- return false;
- }
- }
-}
+ if (!op)
+return false;
- return true;
+ if (TREE_CODE (op) == COMPONENT_REF)
+return true;
+
+ for (i = 0; i TREE_OPERAND_LENGTH (op); i++)
+return contains_component_ref_p (TREE_OPERAND (op, i));
+
+ return false;
}
/* Return true if the operand OP is simple. */
@@ -1094,13 +1087,15 @@ is_simple_operand (loop_p loop, gimple s
if (DECL_P (op)
/* or a structure, */
|| AGGREGATE_TYPE_P (TREE_TYPE (op))
+ /* or a COMPONENT_REF, */
+ || contains_component_ref_p (op)
/* or a memory access that cannot be analyzed by the data
reference analysis. */
|| ((handled_component_p (op) || INDIRECT_REF_P (op))
!stmt_simple_memref_p (loop, stmt, op)))
return false;
- return exclude_component_ref (op);
+ return true;
}
/* Return true only when STMT is simple enough for being handled by
[Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange
--- Comment #6 from sebpop at gmail dot com 2009-03-16 23:18 --- Subject: Re: ICE in create_data_ref with -O1 -floop-interchange Hi, I don't know who coded the overly complicated exclude_component_ref. In the graphite branch we already cleaned up all this code, but in trunk we still have it. Attached is a patch that fixes the problem by looking at whether the operand contains COMPONENT_REFs before calling the data reference analysis. I'm testing the patch on the gcc farm, and will send it to the gcc-patches once it finishes regstrap. Sebastian --- Comment #7 from sebpop at gmail dot com 2009-03-16 23:18 --- Created an attachment (id=17470) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17470action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39447
[Bug inline-asm/38815] Taking the address of a __thread variable prevents the r0 register from being loaded
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 23:27
---
I believe this is a bug in the way we expand local reg vars. The manual says:
Local register variables in specific registers do not reserve the
registers, except at the point where they are used as input or output
operands in an @code{asm} statement and the @code{asm} statement itself is
not deleted. The compiler's data flow analysis is capable of determining
where the specified registers contain live values, and where they are
available for other uses.
There are two key points to note in the above: 1) The only point at which a
register variable *has* to be in the named register is when an inline ASM
appears. 2) Data flow is supposed to know when the value is live. I thus
believe we need to expand local vars as used in this test-case by copying a
pseudo reg that contains the real value into the required register immediately
before its use in an ASM -- and to leave optimizing this code path to the
register allocator -- so that ideally no copy is necessary.
In the test-case cited, the user assigns the variable r0 with a value and then
tries to assign another value to the variable r1. The second step requires a
libcall sequence that clobbers the value previously stored into r0 -- to avoid
this happening the value previously assigned must be copied to a call-saved
register (or the assignment deferred until after the libcall).
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
||org, ramana dot r at gmail
||dot com
Status|UNCONFIRMED |NEW
Component|target |inline-asm
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2009-03-16 23:27:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815
[Bug middle-end/38674] When storing in a register the address of a value contained in the same register, gcc 4.3.2 on ARM clobbers the register before saving its content on the stack.
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 23:38 --- Confirmed. We need a way to represent an early-clobber between a register and a memory-address with side-effects. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-16 23:38:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38674
[Bug middle-end/38674] When storing in a register the address of a value contained in the same register, gcc 4.3.2 on ARM clobbers the register before saving its content on the stack.
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38674
[Bug c++/39475] c++0x type-traits should error out in case of incompleteness
--- Comment #3 from d dot frey at gmx dot de 2009-03-16 23:49 ---
One more thought on the diagnostics: There are two cases: Incomplete types
(like in the initial example in the description of this PR) and recursive
template instantiations (see attachment). I think the latter produces a
diagnostic which suggests it is the former. This problem not only affects
C++0x, it also happens for normal C++:
f...@viasko:~/work/test/recursive_instantiation$ cat t.cc
template typename T
struct foo
{
typename T::type dummy();
};
template typename T
struct bar
{
typedef void type;
foo bar p;
};
foo bar int x;
f...@viasko:~/work/test/recursive_instantiation$ g++ t.cc
t.cc: In instantiation of 'barint':
t.cc:4: instantiated from 'foobarint '
t.cc:14: instantiated from here
t.cc:11: error: 'barT::p' has incomplete type
t.cc:3: error: declaration of 'struct foobarint '
f...@viasko:~/work/test/recursive_instantiation$
g++ is Ubuntu's GCC 4.3.2. The error message says barT::p is incomplete, but
there is no hint why this is the case. Would it be possible to generally
improve this type of diagnostic? Should I open yet another PR or is that not
possible/worth it/...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #6 from ayers at gcc dot gnu dot org 2009-03-16 23:51 --- I've played a bit with creating a trivial static library and linking into an dynamic library and into an executable. After tweaking back and forth it seems that at least on GNU/Linux the static version linked into the executable actually replaces the version that was linked into the dynamic library... not sure what would happen if the version linked in last doesn't satisfy all the requirements needed by the dynamic library. All very intriguing , yet I believe it has nothing to do with your issue. Since I wasn't able to get a cross tool chain running (and www.mingw.org doesn't seem to support that with the current gcc versions) I went ahead and updated an old Windows VM, installed all kinds of updates... and then installed MinGW/MSYS natively. First I reproduced you issue successfully and then went about installing GNUstep. Note that GNUstep's MinGW HOWTO explicitly states: It's a good idea to remove the libobjc.a and libobjc.la and include/objc headers that come with gcc (gcc -v for location) so that they are not accidentally found instead of the libobjc DLL that you will compile below. ... After installing the GNUstep packages, I was able to build and execute applications. Now GNUstep uses it's own build environment (gnustep-make) to hide all the fancy stuff that needs to be done on windows. I was hoping to see something with messages=yes to give me an indication of what you need to do. Yet I had no luck in identifying anything interesting. Well except that GNUstep is using a shared libobjc. I'm going to throw in the towel here, but I don't believe your issue has to do with libobjc. I think your missing some flag or extra processing that gnustep-make might do for you dll or the program. But I also believe that statically linking (potentially different versions) of libobjc into different modules is error prone. I guess it would be OK, if you only have a single executable, but the constellation of the dll linking one version and the executable potentially linking another scares me... even if that itself is most likely not your issue either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug target/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-17 00:03 --- Confirmed, this is a nasty bug that might silently bite users after a long period of apparently correct operation. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2009-03-17 00:03:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved
--- Comment #4 from ramana dot r at gmail dot com 2009-03-17 00:05 --- Still present with 4.4 mainline as on 20090312 revision. It looks like some sort of relic left behind with the calculations of the soft frame pointer. Maybe a peephole will help. -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10242
[Bug rtl-optimization/11222] arm/thumb __Unwind_SjLj_Register prologue optimization causes crash on interrupts
--- Comment #10 from ramana dot r at gmail dot com 2009-03-17 00:11 --- This should be a target bug. Also with mainline the testcase empty described in comment #9 appears fixed. -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11222
[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-17 00:15 --- This is a case where early splitting (before register allocation) of a constant in a plus expression leads to poor code. We should try disabling the split of a plus when combined with the internal frame pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10242
[Bug target/39477] New: Incorrect document for regparm attribute
extend.texi has
---
@item regparm (@var{number})
@cindex @code{regparm} attribute
@cindex functions that are passed arguments in registers on the 386
On the Intel 386, the @code{regparm} attribute causes the compiler to
pass arguments number one to @var{number} if they are of integral type
in registers EAX, EDX, and ECX instead of on the stack. Functions that
take a variable number of arguments will continue to be passed all of their
arguments on the stack.
Beware that on some ELF systems this attribute is unsuitable for
global functions in shared libraries with lazy binding (which is the
default). Lazy binding will send the first call via resolving code in
the loader, which might assume EAX, EDX and ECX can be clobbered, as
per the standard calling conventions. Solaris 8 is affected by this.
GNU systems with GLIBC 2.1 or higher, and FreeBSD, are believed to be
safe since the loaders there save all registers. (Lazy binding can be
disabled with the linker or the loader if desired, to avoid the
problem.)
---
Although glibc is safe since it preserves EAX, EDX and ECX:
_dl_runtime_resolve:
cfi_adjust_cfa_offset (8)
pushl %eax # Preserve registers otherwise clobbered.
cfi_adjust_cfa_offset (4)
pushl %ecx
cfi_adjust_cfa_offset (4)
pushl %edx
cfi_adjust_cfa_offset (4)
movl 16(%esp), %edx # Copy args pushed by PLT in register. Note
movl 12(%esp), %eax # that `fixup' takes its parameters in regs.
call _dl_fixup # Call resolver.
it doesn't save all registers.
--
Summary: Incorrect document for regparm attribute
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
[Bug target/39477] Incorrect document for regparm attribute
-- hjl dot tools at gmail dot com changed: What|Removed |Added GCC target triplet||i686-pc-linux-gnu Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
[Bug c++/39475] c++0x type-traits should error out in case of incompleteness
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-17 00:34 --- Maybe Daniel, but this is a completely separate issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
[Bug target/39477] Incorrect document for regparm attribute
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-17 00:45 --- A patch is posted at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477 -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com URL||http://gcc.gnu.org/bugzilla/ ||show_bug.cgi?id=39477 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
[Bug target/39476] Typo in ix86_function_regparm in i386.c
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-17 01:24 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00761.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00761.html Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39476
[Bug target/39473] Typo in untyped_call in i386.md
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug target/35180] built-in-setjmp.x2
--- Comment #1 from hp at gcc dot gnu dot org 2009-03-17 04:18 --- Does this still happen? See also PR38609. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above
--- Comment #9 from hp at gcc dot gnu dot org 2009-03-17 05:35 --- (In reply to comment #8) Guess it probably won't be TARGET_BUILTIN_SETJMP_FRAME_VALUE then. At any rate, changing it to hard_frame_pointer_rtx doesn't help by itself. (Resulting diffs in RTL dumps are gone after 132r.unshare, for r144898.) Either, GCC should punt and force p to the stack, or calculate p / keep track of the stack-pointer correctly: the value is off by 20 when used after the longjump. (It should be move.d [$sp+28],$r10, not $sp+8.) Right, that's the sp -= 20 due to the __builtin_alloca (20) before the __builtin_setjmp call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38609
