[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-10-14 Thread ebotcazou at gcc dot gnu dot org


--- Comment #10 from ebotcazou at gcc dot gnu dot org  2006-10-14 10:59 
---
 PA-RISC GNU/Linux is not a primary platform, so I've marked this P5.  However,
 PA-RISC HP-UX is a primary platform, so if this bug manifests there, please 
 set
 this back to P3 with an explanatory comment.

Present on SPARC/Solaris.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P5  |P3
   Last reconfirmed|-00-00 00:00:00 |2006-10-14 10:59:32
   date||


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



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-10-14 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  GCC build triplet|hppa-unknown-linux-gnu  |
   GCC host triplet|hppa-unknown-linux-gnu  |
 GCC target triplet|hppa-unknown-linux-gnu  |hppa-*-*, sparc-*-*
   Last reconfirmed|2006-10-14 10:59:32 |2006-10-14 11:00:23
   date||


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



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-20 Thread mmitchel at gcc dot gnu dot org


--- Comment #9 from mmitchel at gcc dot gnu dot org  2006-09-21 02:03 
---
PA-RISC GNU/Linux is not a primary platform, so I've marked this P5.  However,
PA-RISC HP-UX is a primary platform, so if this bug manifests there, please set
this back to P3 with an explanatory comment.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-18 Thread ebotcazou at gcc dot gnu dot org


--- Comment #5 from ebotcazou at gcc dot gnu dot org  2006-09-18 11:36 
---
 Hmmm, seems this is a known issue that never got fixed.  See this thread:
 http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01558.html

And this one: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01569.html


-- 

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=29111



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-18 Thread dave at hiauly1 dot hia dot nrc dot ca


--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2006-09-18 
13:39 ---
Subject: Re:  [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c  -O0  execution
test

 And this one: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01569.html

Actually, I was thinking that the library name should be set by
def_builtin_1 if fallback_p is set for the builtin.

Also, based on comments in the thread:

Index: builtins.c
===
--- builtins.c  (revision 117005)
+++ builtins.c  (working copy)
@@ -233,6 +233,11 @@
 {
   unsigned int align, inner;

+  /* TER is not run at -O0, so our representation of alignment
+ information and its propagation is non-existant.  */
+  if (!optimize)
+return 0;
+
   if (! POINTER_TYPE_P (TREE_TYPE (exp)))
 return 0;

Dave


-- 


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



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-18 Thread ebotcazou at gcc dot gnu dot org


--- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-09-18 13:48 
---
 +  /* TER is not run at -O0, so our representation of alignment
 + information and its propagation is non-existant.  */
 +  if (!optimize)
 +return 0;

Perhaps

  if (!flag_tree_ter)
return 0;

would be more accurate?


-- 


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



Re: [Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-18 Thread Andrew Pinski
On Mon, 2006-09-18 at 13:48 +, ebotcazou at gcc dot gnu dot org
wrote:
 
 --- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-09-18 13:48 
 ---
  +  /* TER is not run at -O0, so our representation of alignment
  + information and its propagation is non-existant.  */
  +  if (!optimize)
  +return 0;
 
 Perhaps
 
   if (!flag_tree_ter)
 return 0;
 
 would be more accurate?
Well -f{no-,}tree-ter can be still passed and you will get it wrong,
what about:
if (!optimize || !flag_tree_ter)
  return 0;

Thanks,
Andrew Pinski



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-18 Thread pinskia at physics dot uc dot edu


--- Comment #8 from pinskia at physics dot uc dot edu  2006-09-18 17:19 
---
Subject: Re:  [4.2 Regression] FAIL:
gcc.dg/torture/pr26565.c  -O0  execution test

On Mon, 2006-09-18 at 13:48 +, ebotcazou at gcc dot gnu dot org
wrote:
 
 --- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-09-18 13:48 
 ---
  +  /* TER is not run at -O0, so our representation of alignment
  + information and its propagation is non-existant.  */
  +  if (!optimize)
  +return 0;
 
 Perhaps
 
   if (!flag_tree_ter)
 return 0;
 
 would be more accurate?
Well -f{no-,}tree-ter can be still passed and you will get it wrong,
what about:
if (!optimize || !flag_tree_ter)
  return 0;

Thanks,
Andrew Pinski


-- 


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



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-17 Thread danglin at gcc dot gnu dot org


--- Comment #3 from danglin at gcc dot gnu dot org  2006-09-17 20:05 ---
There's a question in my mind as to whether we should always be
emitting a library call:

  /* When not optimizing, generate calls to library functions for a certain
 set of builtins.  */
  if (!optimize
   !called_as_built_in (fndecl)
   DECL_ASSEMBLER_NAME_SET_P (fndecl)
   fcode != BUILT_IN_ALLOCA)
return expand_call (exp, target, ignore);

The setting of DECL_ASSEMBLER_NAME doesn't seem to be entirely reliable.
We have in builtin_function:

  if (library_name)
SET_DECL_ASSEMBLER_NAME (decl, get_identifier (library_name));

library_name is set for __builtin_memcpy but not for memcpy.

The difference in behavior between the 32-bit hpux targets and the
32-bit linux target arises because the hpux target defines ASM_OUTPUT_EXTERNAL.
So, the assembler name for memcpy gets set indirectly by assemble_external_real
and this causes expand_builtin to use the library routine.  Is this the
intended behavior?

Ok, back to looking at the linux SEGV.


-- 


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



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-17 Thread danglin at gcc dot gnu dot org


--- Comment #4 from danglin at gcc dot gnu dot org  2006-09-17 20:21 ---
Hmmm, seems this is a known issue that never got fixed.  See this thread:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01558.html


-- 


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



[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test

2006-09-16 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |middle-end
  Known to work||3.4.0
Summary|FAIL:   |[4.2 Regression] FAIL:
   |gcc.dg/torture/pr26565.c  - |gcc.dg/torture/pr26565.c  -
   |O0  execution test  |O0  execution test
   Target Milestone|--- |4.2.0


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