[Bug bootstrap/29382] Bootstrap comparison failure!

2007-05-30 Thread jakub at gcc dot gnu dot org


--- Comment #8 from jakub at gcc dot gnu dot org  2007-05-30 13:32 ---
Subject: Bug 29382

Author: jakub
Date: Wed May 30 13:32:34 2007
New Revision: 125182

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125182
Log:
PR bootstrap/29382
* configure.in: Don't use -fkeep-inline-functions for GCC  3.3.1.
* configure: Rebuilt.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382



[Bug bootstrap/29382] Bootstrap comparison failure!

2007-05-30 Thread jakub at gcc dot gnu dot org


--- Comment #9 from jakub at gcc dot gnu dot org  2007-05-30 13:48 ---
Subject: Bug 29382

Author: jakub
Date: Wed May 30 13:48:07 2007
New Revision: 125184

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125184
Log:
PR bootstrap/29382
* configure.in: Don't use -fkeep-inline-functions for GCC  3.3.1.
* configure: Rebuilt.

Modified:
branches/gcc-4_2-branch/ChangeLog
branches/gcc-4_2-branch/configure
branches/gcc-4_2-branch/configure.in


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382



[Bug bootstrap/29382] Bootstrap comparison failure!

2007-05-30 Thread jakub at gcc dot gnu dot org


--- Comment #10 from jakub at gcc dot gnu dot org  2007-05-30 14:03 ---
Worked around in 4.2.1+ and on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382



[Bug bootstrap/29382] Bootstrap comparison failure!

2007-05-29 Thread jakub at gcc dot gnu dot org


--- Comment #4 from jakub at gcc dot gnu dot org  2007-05-29 10:40 ---
When using gcc-3.2.3 as bootstrap compiler, i386.c is miscompiled
with -O0 -fkeep-inline-functions (the latter option is what is new
in gcc 4.2 and why 4.1.x bootstrap didn't suffer from this, see
2006-07-04  Eric Botcazou  [EMAIL PROTECTED]

PR bootstrap/18058
* configure.in: Add -fkeep-inline-functions to CFLAGS for stage 1
if the bootstrap compiler is a GCC version that supports it.
* configure: Regenerate.
).

typedef struct rtx_def *rtx;
enum machine_mode
{
  VOIDmode = 0,
  DImode = 13
};
extern rtx gen_rtx_CONST_INT (enum machine_mode, long);
extern rtx gen_x86_shld_1 (rtx, rtx, rtx);
static __inline__ rtx
gen_x86_64_shld(rtx a, rtx b, rtx c)
{
  return 0;
}
extern rtx emit_insn (rtx);

void
foo (rtx *high, rtx *low, enum machine_mode mode, int count)
{
  emit_insn ((mode == DImode ? gen_x86_shld_1 : gen_x86_64_shld)
 (high[0], low[0], gen_rtx_CONST_INT (VOIDmode, count)));
}

(extracted from i386.i) is miscompiled (tested latest RHEL3 gcc-3.2.3 as well
as current branches/gcc-3_2-branch), it calls gen_x86_64_shld unconditionally.
Removing -fkeep-inline-functions (or adding asm volatile () into the inline
function or making gen_x86_64_shld extern instead of static inline cures this).

Now, gcc-3_2-branch is long time closed, so IMNSHO gcc-4.2+ should work around
this bug.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382



[Bug bootstrap/29382] Bootstrap comparison failure!

2007-05-29 Thread ebotcazou at gcc dot gnu dot org


--- Comment #5 from ebotcazou at gcc dot gnu dot org  2007-05-29 10:47 
---
 Now, gcc-3_2-branch is long time closed, so IMNSHO gcc-4.2+ should work around
 this bug.

Agreed, we can simply say that GCC 3.2.x is not is a GCC version that supports
it.  Would you mind writing the patch?  I don't have GCC 3.2.x handy.  TIA.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382



[Bug bootstrap/29382] Bootstrap comparison failure!

2007-05-29 Thread jakub at gcc dot gnu dot org


--- Comment #6 from jakub at gcc dot gnu dot org  2007-05-29 11:42 ---
Seems there were 2 separate bugs that are causing this miscompilation.
1) common_type (in contemporary gcc's common_pointer_type) will for the type
of the whole conditional expression use pointer to attribute const function
rather than non-const:
int fn1 (void);
int fn2 (void) __attribute__((const));
...
(cond ? fn1 : fn2)
I'd say that's an unfortunate effect from representing __attribute__((const))
as TREE_READONLY on the FUNCTION_TYPE rather than as an attribute.  Say for
cond expr where one ptr target is volatile and the other is not the result
needs to be ptr to volatile and similarly for say
int *ptr1;
const int *ptr2;
cond ? ptr1 : ptr2
where the result should be pointer to const, a conservative choice.  But for
__attribute__((const)) functions the conservative choise is the exact opposite,
if I have (cond ? fn1 : fn2) one of the functions isn't const and therefore
nothing should assume the whole thing is pointer to __attribute__((const))
function.  gcc trunk handles this the same way.

2) because of 1), but also e.g. on
typedef struct rtx_def *rtx;
enum machine_mode
{
  VOIDmode = 0,
  DImode = 13
};
extern rtx gen_rtx_CONST_INT (enum machine_mode, long);
extern rtx gen_x86_shld_1 (rtx, rtx, rtx) __attribute__((const));
extern rtx gen_x86_64_shld (rtx, rtx, rtx) __attribute__((const));
extern rtx emit_insn (rtx);

void
foo (rtx *high, rtx *low, enum machine_mode mode, int count)
{
  emit_insn ((mode == DImode ? gen_x86_shld_1 : gen_x86_64_shld)
 (high[0], low[0], gen_rtx_CONST_INT (VOIDmode, count)));
}
where 1) doesn't apply a properly emitted expanded COND_EXPR into rtl is
passed through emit_libcall_block which changes:
(insn 31 0 32 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -20 [0xffec])) [0 mode+0 S4 A32])
(const_int 13 [0xd]))) -1 (nil)
(nil))

(jump_insn 32 31 34 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 37)
(pc))) -1 (nil)
(nil))

(insn 34 32 35 (set (reg:DI 63)
(symbol_ref:DI (gen_x86_shld_1))) -1 (nil)
(nil))

(jump_insn 35 34 36 (set (pc)
(label_ref 40)) -1 (nil)
(nil))

(barrier 36 35 37)

(code_label 37 36 39 2   [0 uses])

(insn 39 37 40 (set (reg:DI 63)
(symbol_ref:DI (gen_x86_64_shld))) -1 (nil)
(nil))

(code_label 40 39 42 3   [0 uses])

(insn 42 40 44 (set (reg:DI 1 rdx)
(reg:DI 60)) -1 (nil)
(nil))

(insn 44 42 46 (set (reg:DI 4 rsi)
(mem:DI (reg/f:DI 61) [0 S8 A64])) -1 (nil)
(nil))

(insn 46 44 47 (set (reg:DI 5 rdi)
(mem:DI (reg/f:DI 62) [0 S8 A64])) -1 (nil)
(nil))

(call_insn/u 47 46 0 (set (reg:DI 0 rax)
(call (mem:QI (reg:DI 63) [0 S1 A8])
(const_int 0 [0x0]))) -1 (nil)
(nil)
(expr_list (use (reg:DI 5 rdi))
(expr_list (use (reg:DI 4 rsi))
(expr_list (use (reg:DI 1 rdx))
(nil)

into
(insn 34 30 39 (set (reg:DI 63)
(symbol_ref:DI (gen_x86_shld_1))) -1 (nil)
(nil))

(insn 39 34 31 (set (reg:DI 63)
(symbol_ref:DI (gen_x86_64_shld))) -1 (nil)
(nil))

(insn 31 39 32 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -20 [0xffec])) [0 mode+0 S4 A32])
(const_int 13 [0xd]))) -1 (nil)
(nil))

(jump_insn 32 31 35 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 37)
(pc))) -1 (nil)
(nil))

(jump_insn 35 32 36 (set (pc)
(label_ref 40)) -1 (nil)
(nil))

(insn 34 30 39 (set (reg:DI 63)
(symbol_ref:DI (gen_x86_shld_1))) -1 (nil)
(nil))

(insn 39 34 31 (set (reg:DI 63)
(symbol_ref:DI (gen_x86_64_shld))) -1 (nil)
(nil))

(insn 31 39 32 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -20 [0xffec])) [0 mode+0 S4 A32])
(const_int 13 [0xd]))) -1 (nil)
(nil))

(jump_insn 32 31 35 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 37)
(pc))) -1 (nil)
(nil))

(jump_insn 35 32 36 (set (pc)
(label_ref 40)) -1 (nil)
(nil))

(barrier 36 35 37)

(code_label 37 36 40 2   [0 uses])

(code_label 40 37 42 3   [0 uses])

(insn 42 40 44 (set (reg:DI 1 rdx)
(reg:DI 60)) -1 (nil)
(nil))

(insn 44 42 46 (set (reg:DI 4 rsi)
(mem:DI (reg/f:DI 61) [0 S8 A64])) -1 (nil)
(nil))

(insn 46 44 47 (set (reg:DI 5 rdi)
(mem:DI (reg/f:DI 62) [0 S8 A64])) -1 (nil)
(nil))

(call_insn/u 47 46 49 (set (reg:DI 0 rax)
(call (mem:QI (reg:DI 63) [0 S1 A8])
(const_int 0 [0x0]))) -1 (nil)

[Bug bootstrap/29382] Bootstrap comparison failure!

2007-05-29 Thread jakub at gcc dot gnu dot org


--- Comment #7 from jakub at gcc dot gnu dot org  2007-05-29 12:48 ---
2) is apparently PR11557, fixed in GCC 3.3.1+.

So, I'd say as workaround we should not use -fkeep-inline-functions for
GCC  3.3.1.  Testing a patch for that.


-- 

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
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-29 12:48:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382



[Bug bootstrap/29382] Bootstrap comparison failure!

2007-05-21 Thread tru at pasteur dot fr


--- Comment #3 from tru at pasteur dot fr  2007-05-21 15:43 ---
[EMAIL PROTECTED] ~]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-58)
[EMAIL PROTECTED] ~]$ rpm -q gcc
gcc-3.2.3-58.i386

is failing too, but a plain gcc-3.4.6 can bootstrap gcc-4.2.0


-- 

tru at pasteur dot fr changed:

   What|Removed |Added

 CC||tru at pasteur dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382



[Bug bootstrap/29382] Bootstrap comparison failure!

2007-03-05 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2007-03-05 19:43 ---
No feedback in 3 months so closing.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382



[Bug bootstrap/29382] Bootstrap comparison failure!

2006-10-07 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-07 20:07 ---
This works for me on i686-linux-gnu.  Can you first try compiling 3.4.x and
then trying compiling the mainline with that?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382