[Bug fortran/35719] pointer to zero sized array not associated

[jb at gcc dot gnu dot org]

--- Comment #6 from jb at gcc dot gnu dot org  2008-05-09 06:15 ---
Another solution is to have status flags for allocated and associated in the
descriptor, IIRC at least Pathscale does this.

Aren't there actually free bits left in the dtype flag that gfortran could use,
without requiring to change the descriptor?


-- 


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

[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation

[cnstar9988 at gmail dot com]

--- Comment #30 from cnstar9988 at gmail dot com  2008-05-09 05:36 ---
fixed?


-- 

cnstar9988 at gmail dot com changed:

   What|Removed |Added

 CC||cnstar9988 at gmail dot com


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

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2008-05-09 05:05 ---
ahem, tentative


-- 


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

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

--- Comment #3 from bonzini at gnu dot org  2008-05-09 05:05 ---
i'll post a temptative patch for the cris issue if i get to it during the
commute.


-- 


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

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2008-05-09 05:04 ---
unfortunately my current gcc time is ~0, which is why dje actually tested and
committed the patch for me, but sorry for causing these regressions anyway.

for cris, i believe the correct fix is to strengthen the check and only wrap
symbol_refs if they are from the same section.  (this is a problem in my patch,
which is why i'm confirming the bug).

for spu, this is a target bug where legitimate_address is not rejecting an
invalid address.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-09 05:04:25
   date||


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

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[hp at bitrange dot com]

--- Comment #6 from hp at bitrange dot com  2008-05-09 03:49 ---
Subject: Re:  [4.4 Regression] g++.dg/opt/pr23714.C
 ICEs with 135041 -> 135057

On Thu, 8 May 2008, zadeck at naturalbridge dot com wrote:
> I am testing this patch on x86.  But hp needs to test it on the cris
> before i will ask for approval.

For the record, anyone can test this target using
 and
.
Anyway, I'm doing it; I just made a baseline run.

The patch was malformed; applying it gave:
patching file doc/rtl.texi
patching file dce.c
Hunk #1 succeeded at 99 with fuzz 2.
Hunk #3 FAILED at 388.
1 out of 3 hunks FAILED -- saving rejects to file dce.c.rej

Apparently TABs had been expanded or something.  I applied the
rejected part manually and I'm testing the patch in the
attachment, which I hope is the same as what you have.

(I suggest attaching patches to the PR's by uploading them or
sending them as attachments; not cutnpasting into the web form
or whatever happened.  I sure hope the same doesn't happen to
this one!)

Thanks for your quick action!

brgds, H-PIndex: doc/rtl.texi
===
--- doc/rtl.texi(revision 135097)
+++ doc/rtl.texi(working copy)
@@ -559,14 +559,37 @@
 perhaps with the help of base registers.
 Stored in the @code{unchanging} field and printed as @samp{/u}.

[EMAIL PROTECTED] CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] RTL_CONST_CALL_P
 @cindex @code{call_insn} and @samp{/u}
 @cindex @code{unchanging}, in @code{call_insn}
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P (@var{x})
-In a @code{call_insn}, @code{note}, or an @code{expr_list} for notes,
-indicates that the insn represents a call to a const or pure function.
-Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+const function.  Stored in the @code{unchanging} field and printed as
[EMAIL PROTECTED]/u}.

[EMAIL PROTECTED] RTL_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/i}
[EMAIL PROTECTED] @code{return_val}, in @code{call_insn}
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+pure function.  Stored in the @code{return_val} field and printed as
[EMAIL PROTECTED]/i}.
+
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/u} or @samp{/i}
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn}, true if @code{RTL_CONST_CALL_P} or
[EMAIL PROTECTED] is true.
+
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/c}
[EMAIL PROTECTED] @code{call}, in @code{call_insn}
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a possibly
+infinite looping call to a const or pure function.  Stored in the
[EMAIL PROTECTED] field and printed as @samp{/c}.  Only true if one of
[EMAIL PROTECTED] or @code{RTL_PURE_CALL_P} is true.
+
 @findex INSN_ANNULLED_BRANCH_P
 @cindex @code{jump_insn} and @samp{/u}
 @cindex @code{call_insn} and @samp{/u}
@@ -869,6 +892,9 @@
 @item call
 In a @code{mem}, 1 means that the memory reference will not trap.

+In a @code{call}, 1 means that this pure or const call may possibly
+infinite loop.
+
 In an RTL dump, this flag is represented as @samp{/c}.

 @findex frame_related
@@ -938,6 +964,8 @@

 In @code{symbol_ref} expressions, 1 means the referenced symbol is weak.

+In @code{call} expressions, 1 means the call is pure.
+
 In an RTL dump, this flag is represented as @samp{/i}.

 @findex jump
@@ -967,8 +995,8 @@
 In a @code{symbol_ref} expression, 1 means that this symbol addresses
 something in the per-function constant pool.

-In a @code{call_insn}, @code{note}, or an @code{expr_list} of notes,
-1 means that this instruction is a call to a const or pure function.
+In a @code{call_insn} 1 means that this instruction is a call to a const
+function.

 In an RTL dump, this flag is represented as @samp{/u}.

Index: dce.c
===
--- dce.c   (revision 135097)
+++ dce.c   (working copy)
@@ -99,11 +99,16 @@
   rtx body, x;
   int i;

-  /* We can delete dead const or pure calls as long as they do not
- infinite loop and are not sibling calls.  The problem with
- sibling calls is that it is hard to see the result.  */
-  if (CALL_P (insn) 
+  if (CALL_P (insn)
+  /* We cannot delete calls inside of the recursive dce because
+this may cause basic blocks to be deleted and this messes up
+the rest of the stack of optimization passes.  */
+  && (!df_in_progress)
+  /* We cannot delete pure or const sibling calls because it is
+hard to see the result.  */
   && (!SIBLING_CALL_P (insn))
+  /* We can delete dead const or pure calls as lon

[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)

[froydnj at gcc dot gnu dot org]

--- Comment #4 from froydnj at gcc dot gnu dot org  2008-05-09 03:14 ---
If I understand correctly, one would just need to add vector modes with
appropriate alignment restrictions to SLOW_UNALIGNED_ACCESS.  If I add an extra

|| (((MODE) == V4SFmode || (MODE) == V2DFmode) && (ALIGN) < 128)

to SLOW_UNALIGNED_ACCESS, and compile without -mstrict-align, I get
semi-reasonable looking code at -O2:

f:
   stwu 1,-48(1)
   addi 9,1,16
   stw 28,32(1)
   stw 29,36(1)
   stvx 2,0,9
   lwz 8,12(9)
   lwz 5,0(9)
   lwz 6,4(9)
   mr 0,8
   lwz 7,8(9)
   stw 8,13(3)
   addi 8,1,16
   stw 5,1(3)
   stw 7,9(3)
   stw 6,5(3)
   stw 5,0(8)
   stw 6,4(8)
   stw 7,8(8)
   stw 0,12(8)
   lvx 2,0,8
   lwz 28,32(1)
   lwz 29,36(1)
   addi 1,1,48
   blr

It could be improved, but it's a lot better than -mstrict-align code.


-- 

froydnj at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||froydnj at gcc dot gnu dot
   ||org


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

[Bug bootstrap/36184] New: gimple-tuples-branch fails bootstrap on Darwin

[stanshebs at earthlink dot net]

Per mailing list instructions and using a branch checkout from today,

../gimple-tuples-branch/configure --disable-libgomp --disable-libmudflap
make

on Darwin fails with an illegal instruction:

/Users/shebs/s/gcc/tuples/macosx/./prev-gcc/xgcc
-B/Users/shebs/s/gcc/tuples/macosx/./prev-gcc/
-B/usr/local/i386-apple-darwin9.2.2/bin/ -c  -g -O2 -fomit-frame-pointer
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros-Wno-overlength-strings
-Werror -Werror -Wno-return-type -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gimple-tuples-branch/gcc -I../../gimple-tuples-branch/gcc/.
-I../../gimple-tuples-branch/gcc/../include -I./../intl
-I../../gimple-tuples-branch/gcc/../libcpp/include 
-I../../gimple-tuples-branch/gcc/../libdecnumber
-I../../gimple-tuples-branch/gcc/../libdecnumber/dpd -I../libdecnumber 
insn-attrtab.c -o insn-attrtab.o
xgcc: Internal error: Illegal instruction (program cc1)
Please submit a full bug report.
See  for instructions.
make[3]: *** [insn-attrtab.o] Error 1
make[2]: *** [all-stage3-gcc] Error 2
make[1]: *** [stage3-bubble] Error 2
make: *** [all] Error 2


-- 
   Summary: gimple-tuples-branch fails bootstrap on Darwin
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stanshebs at earthlink dot net
 GCC build triplet: i386-apple-darwin9.2.2
  GCC host triplet: i386-apple-darwin9.2.2
GCC target triplet: i386-apple-darwin9.2.2


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

[Bug c++/36183] New: missleading error message with explicit copy constructor call

[4ertus2 at mail dot ru]

class B
{
  public:
B() {}
explicit B(const B& ref) {}
};

void f(B obj) {}

int main()
{
  const B b;
  const B& r(b);
  f(b); // error: no matching function for call to 'B::B(const B&)'
// error:   initializing argument 1 of 'void f(B)'
  f(r); // error: no matching function for call to 'B::B(const B&)'
// error:   initializing argument 1 of 'void f(B)'
  return 0;
}

The problem is in casting from const B& to B, not in coustructor existence.


-- 
   Summary: missleading error message with explicit copy constructor
call
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 4ertus2 at mail dot ru


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

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[zadeck at naturalbridge dot com]

--- Comment #5 from zadeck at naturalbridge dot com  2008-05-08 23:04 
---
Subject: Re:  [4.4 Regression] g++.dg/opt/pr23714.C
 ICEs with 135041 -> 135057

steven at gcc dot gnu dot org wrote:
> --- Comment #4 from steven at gcc dot gnu dot org  2008-05-08 22:27 
> ---
> So I was looking at an older revision of dce.c.  There is this new check 
> before
> the !NONJUMP_INSN_P check now:
>
>   /* We can delete dead const or pure calls as long as they do not
>  infinite loop and are not sibling calls.  The problem with
>  sibling calls is that it is hard to see the result.  */
>   if (CALL_P (insn) 
>   && (!SIBLING_CALL_P (insn))
>   && (RTL_CONST_OR_PURE_CALL_P (insn)
>   && !RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)))
> return true;
>
> CALL_P is obviously true for this insn, and so is !SIBLING_CALL_P (there is no
> call_insn/j).  The "/u" flag means that RTL_CONST_OR_PURE_CALL_P is true for
> the insn.  The "/c" flag is clear, so RTL_LOOPING_CONST_OR_PURE_CALL_P is
> false.
>
> I don't know where RTL_CONST_OR_PURE_CALL_P is set.  But that's where I would
> look.
>
> [ I see that RTL_LOOPING_CONST_OR_PURE_CALL_P is not documented.  Kenny, can
> you please take care of that (and probably other necessary document updates
> following your patch)? ]
>
>
>   
The real problem is that this call was being deleted (and I believe that 
it should have been because it is const.) and this caused some blocks to 
become orphaned. 

In particular, the bug was that when this call was deleted, it also 
caused the exception edge out of that block to be deleted.   That caused 
some other blocks to be orphaned and that caused an assertion check.   
What this patch does is only allow pure and const calls to be deleted 
when dce is run as a stand alone pass because it is not possible to 
properly update the blocks from the call  to fast dce that happens as a 
side effect of running the lr problem. 

However, such calls (and there will be a lot more of them once more 
libcall code gets removed) are deleted by the use-def based dce that is 
run right before combine. 

I am testing this patch on x86.  But hp needs to test it on the cris 
before i will ask for approval.

kenny

2008-05-08  Kenneth Zadeck  <[EMAIL PROTECTED]>

* dce.c (deletable_insn_p): Do not delete calls if
df_in_progress.
(delete_unmarked_insns): When deleting a call, call
delete_unreachable_blocks.
* rtl.texi (RTL_CONST_CALL_P, RTL_PURE_CALL_P,
RTL_CONST_OR_PURE_CALL_P, RTL_LOOPING_CONST_OR_PURE_CALL_P): Fixed
doc.



Index: doc/rtl.texi
===
--- doc/rtl.texi(revision 135089)
+++ doc/rtl.texi(working copy)
@@ -559,13 +559,36 @@ In either case GCC assumes these address
 perhaps with the help of base registers.
 Stored in the @code{unchanging} field and printed as @samp{/u}.

[EMAIL PROTECTED] CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] RTL_CONST_CALL_P
 @cindex @code{call_insn} and @samp{/u}
 @cindex @code{unchanging}, in @code{call_insn}
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P (@var{x})
-In a @code{call_insn}, @code{note}, or an @code{expr_list} for notes,
-indicates that the insn represents a call to a const or pure function.
-Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+const function.  Stored in the @code{unchanging} field and printed as
[EMAIL PROTECTED]/u}.
+
[EMAIL PROTECTED] RTL_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/i}
[EMAIL PROTECTED] @code{return_val}, in @code{call_insn}
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+pure function.  Stored in the @code{return_val} field and printed as
[EMAIL PROTECTED]/i}.
+
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/u} or @samp{/i}
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn}, true if @code{RTL_CONST_CALL_P} or
[EMAIL PROTECTED] is true.
+
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/c}
[EMAIL PROTECTED] @code{call}, in @code{call_insn}
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a possibly
+infinite looping call to a const or pure function.  Stored in the
[EMAIL PROTECTED] field and printed as @samp{/c}.  Only true if one of
[EMAIL PROTECTED] or @code{RTL_PURE_CALL_P} is true.

 @findex INSN_ANNULLED_BRANCH_P
 @cindex @code{jump_insn} and @samp{/u}
@@ -869,6 +892,9 @@ These are the fields to which the above 
 @item call
 In a @code{mem}, 1 means that the memory reference will not trap.

+In a @code{call}, 1 means that this pure or const call may possibly
+infinite loop.
+
 In an RTL dump, this flag is represented as @samp{/c}.

 @findex fra

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-08 22:47 ---
I have a similar issue on spu-elf where we get [EMAIL PROTECTED] which is too 
complex for
the linker to handle.

/tmp/ccbhdI9l.s:19: Error: reloc 132 not supported by object file format^M
/tmp/ccbhdI9l.s:22: Error: reloc 131 not supported by object file format^M

ilhu$3,[EMAIL PROTECTED]
iohl$3,[EMAIL PROTECTED]

This is with compiling pr34029-2.c


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.3.1


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

[Bug rtl-optimization/36182] New: [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

With 135074 no regressions.
With 135087, I see the following regressions:
FAIL: ext/malloc_allocator/deallocate_local.cc (test for excess errors)
WARNING: ext/malloc_allocator/deallocate_local.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-2.cc (test for excess errors)
WARNING: ext/mt_allocator/deallocate_local-2.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-4.cc (test for excess errors)
WARNING: ext/mt_allocator/deallocate_local-4.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-6.cc (test for excess errors)
WARNING: ext/mt_allocator/deallocate_local-6.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-8.cc (test for excess errors)
WARNING: ext/mt_allocator/deallocate_local-8.cc compilation failed to produce
executable
FAIL: ext/new_allocator/deallocate_local.cc (test for excess errors)
WARNING: ext/new_allocator/deallocate_local.cc compilation failed to produce
executable
FAIL: ext/throw_allocator/deallocate_local.cc (test for excess errors)
WARNING: ext/throw_allocator/deallocate_local.cc compilation failed to produce
executable

with the .log file saying similar for all errors:
/tmp/ccDpHWIJ.s: Assembler messages:^M
/tmp/ccDpHWIJ.s:788: Error: can't resolve `.LC2' {.rodata.str1.2 section} -
`__ZNSbIcSt11char_traitsIcEN9__gnu_cxx16malloc_allocatorIcEEE4_Rep20_S_empty_rep_storageE'
{.bss._ZNSbIcSt11char_traitsIcEN9__gnu_cxx16malloc_allocatorIcEEE4_Rep20_S_empty_rep_storageE
section}^M
/tmp/ccDpHWIJ.s:788: Error: expression too complex^M
compiler exited with status 1
output is:
/tmp/ccDpHWIJ.s: Assembler messages:^M
/tmp/ccDpHWIJ.s:788: Error: can't resolve `.LC2' {.rodata.str1.2 section} -
`__ZNSbIcSt11char_traitsIcEN9__gnu_cxx16malloc_allocatorIcEEE4_Rep20_S_empty_rep_storageE'
{.bss._ZNSbIcSt11char_traitsIcEN9__gnu_cxx16malloc_allocatorIcEEE4_Rep20_S_empty_rep_storageE
section}^M
/tmp/ccDpHWIJ.s:788: Error: expression too complex^M

FAIL: ext/malloc_allocator/deallocate_local.cc (test for excess errors)

There's only the PR36090 simplify_plus_minus change between these two revisions
on the 4.3 branch.  So, the CONST change now causes a wrap of a MINUS between
two symbols to _different_ sections, which must not happen.  Curiously, the
same change on HEAD doesn't exhibit these regressions.  Author of patch CC:ed.


-- 
   Summary: [4.3 Regression] Fix for PR 36090 causes libstdc++
regressions
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2008-05-08 22:27 ---
So I was looking at an older revision of dce.c.  There is this new check before
the !NONJUMP_INSN_P check now:

  /* We can delete dead const or pure calls as long as they do not
 infinite loop and are not sibling calls.  The problem with
 sibling calls is that it is hard to see the result.  */
  if (CALL_P (insn) 
  && (!SIBLING_CALL_P (insn))
  && (RTL_CONST_OR_PURE_CALL_P (insn)
  && !RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)))
return true;

CALL_P is obviously true for this insn, and so is !SIBLING_CALL_P (there is no
call_insn/j).  The "/u" flag means that RTL_CONST_OR_PURE_CALL_P is true for
the insn.  The "/c" flag is clear, so RTL_LOOPING_CONST_OR_PURE_CALL_P is
false.

I don't know where RTL_CONST_OR_PURE_CALL_P is set.  But that's where I would
look.

[ I see that RTL_LOOPING_CONST_OR_PURE_CALL_P is not documented.  Kenny, can
you please take care of that (and probably other necessary document updates
following your patch)? ]


-- 


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

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2008-05-08 22:16 ---
> I would have thought that since this can generate an exception and it is 
> a call insn that it would have been declared as a non deleteable insn by 
> dce.c:deleteable_insn_p.

deletable_insn_p() *will* declare this insn as non-deletable.  The insn is not
a NONJUMP_INSN_P so the very first check in deletable_insn_p() will already
make it return false.

So the problem is somewhere else.


-- 


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

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-05-08 22:07 ---
(In reply to comment #1)
> In particular, i assume that the dce code is getting confused because it 
> does not see the call inside the parallel.
> 
> i do not know if this is a bug in the cris port or if there are other 
> cases that need to be added to dce.   This is for the rtl trained 
> professionals to determine.

This is a valid insn and the parallel-construct is certainly valid and not some
"burying". If some part of gcc doesn't look inside a parallel, then there¨s the
bug.


-- 


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

[Bug target/35657] Alignments of DFP types aren't consistent

[hjl dot tools at gmail dot com]

--- Comment #14 from hjl dot tools at gmail dot com  2008-05-08 19:12 
---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35657] Alignments of DFP types aren't consistent

[hjl at gcc dot gnu dot org]

--- Comment #13 from hjl at gcc dot gnu dot org  2008-05-08 19:12 ---
Subject: Bug 35657

Author: hjl
Date: Thu May  8 19:11:23 2008
New Revision: 135089

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135089
Log:
2008-05-08  H.J. Lu  <[EMAIL PROTECTED]>

Backport from mainline:
2008-05-06  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35657
* config/i386/i386.c (contains_128bit_aligned_vector_p): Renamed
to ...
(contains_aligned_value_p): This.  Handle _Decimal128.
(ix86_function_arg_boundary): Only align _Decimal128 to its
natural boundary and handle it properly.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/i386.c


-- 


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

[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files

[jkrahn at nc dot rr dot com]

--- Comment #3 from jkrahn at nc dot rr dot com  2008-05-08 18:19 ---
Fortran files should not be put into /usr/local/include or /usr/include. Those
directories are defined for C headers. It is particularly bad to put binary
files there. We should instead develop a standard location for Fortran-specific
files, as is done with all non-C languages. For example:
/usr/lib/gfortran/modules /usr/local/lib/gfortran/modules.


-- 


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

[Bug tree-optimization/36181] New: Simple for loop generates ICE with -ftree-parallelize-loops=2

[runeerle at stud dot ntnu dot no]

This simple test case fails:
--

#include 
int main(int argc, const char* argv[])
{
int data[1024];
int sum = 0;
int i = 0;
for(; i<1024; i++)
sum += data[i];
printf("%d", sum);
return 0;
}

--

Options and output:

$ gcc-4.3 -O3 -ftree-parallelize-loops=2 main2.c -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure linux gnu
Thread model: posix
gcc version 4.3.0 (Ubuntu 4.3.0-1ubuntu1) 
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v' '-mtune=generic'
'-pthread'
 /usr/lib/gcc/x86_64-linux-gnu/4.3.0/cc1 -quiet -v -D_REENTRANT main2.c -quiet
-dumpbase main2.c -mtune=generic -auxbase main2 -O3 -version
-ftree-parallelize-loops=2 -fstack-protector -fstack-protector -o
/tmp/cclHEQpb.s
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.3.0/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.3.0/include
 /usr/lib/gcc/x86_64-linux-gnu/4.3.0/include-fixed
 /usr/include
End of search list.
GNU C (Ubuntu 4.3.0-1ubuntu1) version 4.3.0 (x86_64-linux-gnu)
compiled by GNU C version 4.3.0, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1cbb7f16ebc5c81a75d8a2ed8f02da6b
main2.c: In function ‘main’:
main2.c:4: internal compiler error: in canonicalize_loop_ivs, at
tree-parloops.c:1329
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: Simple for loop generates ICE with -ftree-parallelize-
loops=2
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: runeerle at stud dot ntnu dot no
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 -> 135057

[zadeck at naturalbridge dot com]

--- Comment #1 from zadeck at naturalbridge dot com  2008-05-08 16:46 
---
Subject: Re:  [4.4 Regression] g++.dg/tree-ssa/pr19637.C
 ICEs with 135041 -> 135057

Here is the bug.   I do not know if this is just an illegal insn 
generated by a bad port or if we are missing something in the dce code.

the dce code is deleting insn 12:

(call_insn/u 12 11 47 2 
/home/zadeck/gcc36177/gcc/testsuite/g++.dg/opt/pr23714.C:11 (parallel [
(set (reg:SF 10 r10)
(call (mem:QI (reg/f:SI 31) [0 S1 A8])
(const_int 0 [0x0])))
(clobber (reg:SI 16 srp))
]) 224 {*expanded_call_value_non_v32} (expr_list:REG_EH_REGION 
(const_int 1 [0x1])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:SF 11 r11))
(expr_list:REG_DEP_TRUE (use (reg:SF 10 r10))
(nil

I would have thought that since this can generate an exception and it is 
a call insn that it would have been declared as a non deleteable insn by 
dce.c:deleteable_insn_p.  It is also clearly a jump insn even though we 
do not see it as such since it is buried in a parallel.

In particular, i assume that the dce code is getting confused because it 
does not see the call inside the parallel.

i do not know if this is a bug in the cris port or if there are other 
cases that need to be added to dce.   This is for the rtl trained 
professionals to determine.

kenny 


-- 


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

[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation

[dje at gcc dot gnu dot org]

--- Comment #29 from dje at gcc dot gnu dot org  2008-05-08 16:41 ---
Subject: Bug 36090

Author: dje
Date: Thu May  8 16:40:17 2008
New Revision: 135087

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135087
Log:
2008-05-08  Paolo Bonzini  <[EMAIL PROTECTED]>

PR target/36090
* simplify-rtx.c (simplify_plus_minus): Create CONST of
similar RTX_CONST_OBJ before CONST_INT.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/simplify-rtx.c


-- 


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

[Bug preprocessor/22231] -MG ignores missing headers even with -c

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2008-05-08 16:40 ---
I finally submitted this patch.
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00520.html


-- 


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

[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation

[dje at gcc dot gnu dot org]

--- Comment #28 from dje at gcc dot gnu dot org  2008-05-08 16:36 ---
Subject: Bug 36090

Author: dje
Date: Thu May  8 16:35:56 2008
New Revision: 135086

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135086
Log:
2008-05-08  Paolo Bonzini  <[EMAIL PROTECTED]>

PR target/36090
* simplify-rtx.c (simplify_plus_minus): Create CONST of
similar RTX_CONST_OBJ before CONST_INT.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c


-- 


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

[Bug tree-optimization/34976] verify_ssa ICE with -ftree-loop-linear

[spop at gcc dot gnu dot org]

--- Comment #5 from spop at gcc dot gnu dot org  2008-05-08 15:54 ---
Subject: Re:  verify_ssa ICE with -ftree-loop-linear

The patch is already in trunk:

2008-02-29  Sebastian Pop  <[EMAIL PROTECTED]>

* tree-loop-linear.c (try_interchange_loops): Compare memory access
strides against cache sizes.

I don't know if I can commit the patch to 4.3 to close the PR.
As I said before this is a workaround not a proper fix of the bug.

Sebastian


-- 


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

[Bug tree-optimization/35501] Wrong value returned from const int

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2008-05-08 15:13 ---
Hmm, actually I sort of agree with HJ.  It's a global (and unhidden)
definition, which very well can be replaced by a different definition at
runtime.  In particular that will happen for instance if the global data
is defined in a shared lib, but referenced from the executable.  A COPY reloc
will be created and the content of the variable will be taken from the 
executable.  That of course will have the same value as in the shared lib,
so that difference doesn't matter.

The only way by which we could declare the current behaviour valid, is if
we declare several definitions of global const variables with different
value as invalid.  The C standard isn't concerned with different shared
object, so we can't extract such declaration out of it.  The ELF standard
doesn't say anything about this, so the default rules apply, which would
require _not_ hardcoding the constant.


-- 


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

[Bug bootstrap/36180] [4.4 Regression] Multiple bootstrap failures due to revision 135069

[ktietz at gcc dot gnu dot org]

--- Comment #2 from ktietz at gcc dot gnu dot org  2008-05-08 11:38 ---
Committed at revision135079 to gcc trunk.


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/36180] [4.4 Regression] Multiple bootstrap failures due to revision 135069

[ktietz at gcc dot gnu dot org]

--- Comment #1 from ktietz at gcc dot gnu dot org  2008-05-08 11:37 ---
Created an attachment (id=15618)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15618&action=view)
Committed patch at revision 135079.


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ktietz at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED


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

[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2008-05-08 10:44 ---
(In reply to comment #8)
> 
> Sorry, you got it totally wrong! When someone suggests a feature that he 
> thinks
> would be useful, he does definitely not imply that the current developers are
> bored and have nothing to do.

If after being repetitively told that the developers don't see a feature
request as appropriate or useful or even practical such someone keeps insisting
and arguing giving the impression that such person is offended because his/her
feature doesn't get any attention, then, at least in my case, my conclusion is
that such person thinks that the developers should go out of their way to
precisely define and implement the feature in his/her behalf. Sorry, if that is
not the case here.

> The critical misunderstanding here is that some GCC developers think that a
> feature request is something that they are obliged to implement within a
> certain time and the only way to get rid of that obligation is to dismiss any
> idea, that they do not have time to implement right now, as invalid.

That is obviously not the case. There are many interesting feature requests
open in bugzilla that most GCC developers would like to see implemented but
nobody has had time to implement right now.

On the other hand, as far as I understand it, features marked as invalid won't
be implemented ever. Not even if the developers had time to implement them. The
reasons maybe several: not useful, not appropriate for the scope of the
project, not possible. We just want to keep our bugzilla as clean and useful as
possible while not giving false hopes to users.

Some of us have argued above that this PR doesn't meet some of the above
criteria. Anyway, this discussion is pointless. This PR won't be closed as
INVALID. If you are happier if we keep open this feature request, so be it.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|manu at gcc dot gnu dot org |
   Priority|P3  |P5


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

[Bug bootstrap/36180] New: [4.4 Regression] Multiple bootstrap failures due to revision 135069

[dominiq at lps dot ens dot fr]

Building gcc on powerpc-apple-darwin9, I got the following error:

...
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/ -c  -g -O2 -mdynam
ic-no-pic -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pe
dantic -Wno-long-long -Wno-variadic-macros  
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I
. -I. -I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/.
-I../../gcc-4.4-work/gcc/../include -I../../gcc-4.4-work/gcc/../libcpp/include
-I/
sw/include  -I../../gcc-4.4-work/gcc/../libdecnumber
-I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber 
../../gcc-4.4-work/gcc/
calls.c -o calls.o
cc1: warnings being treated as errors
../../gcc-4.4-work/gcc/calls.c: In function 'compute_argument_block_size':
../../gcc-4.4-work/gcc/calls.c:1192: error: unused parameter 'fndecl'
../../gcc-4.4-work/gcc/calls.c: In function 'emit_library_call_value_1':
../../gcc-4.4-work/gcc/calls.c:3284: error: unused variable 'fndecl'
make[3]: *** [calls.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

And bootstraping on i686-apple-darwin9 fails with:

...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -c  -g -O2 -fomit-frame-pointer
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/.
-I../../gcc-4.4-work/gcc/../include -I./../intl
-I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include 
-I../../gcc-4.4-work/gcc/../libdecnumber
-I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber 
../../gcc-4.4-work/gcc/c-common.c -o c-common.o
In file included from ../../gcc-4.4-work/gcc/c-common.c:50:
../../gcc-4.4-work/gcc/target-def.h:548:1: error: "TARGET_RETURN_IN_MEMORY"
redefined
In file included from ./tm.h:5,
 from ../../gcc-4.4-work/gcc/c-common.c:24:
../../gcc-4.4-work/gcc/config/i386/i386.h:1281:1: error: this is the location
of the previous definition
...


-- 
   Summary: [4.4 Regression] Multiple bootstrap failures due to
revision 135069
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: *-apple-darwin9
  GCC host triplet: *-apple-darwin9
GCC target triplet: *-apple-darwin9


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2008-05-08 08:30 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36154] [4.3 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-05-08 08:29 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-05-08 08:24 
---
Subject: Bug 36172

Author: rguenth
Date: Thu May  8 08:23:59 2008
New Revision: 135072

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135072
Log:
2008-05-08  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36154
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Make
sure to create a representative for trailing arrays for PTA.

* gcc.c-torture/compile/pr36154.c: New testcase.

2008-05-08  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36172
* fold-const.c (operand_equal_p): Two objects which types
differ in pointerness are not equal.

* gcc.c-torture/compile/pr36172.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr36154.c
  - copied unchanged from r135071,
trunk/gcc/testsuite/gcc.c-torture/compile/pr36154.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr36172.c
  - copied unchanged from r135071,
trunk/gcc/testsuite/gcc.c-torture/compile/pr36172.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c


-- 


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

[Bug middle-end/36154] [4.3 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-05-08 08:24 ---
Subject: Bug 36154

Author: rguenth
Date: Thu May  8 08:23:59 2008
New Revision: 135072

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135072
Log:
2008-05-08  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36154
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Make
sure to create a representative for trailing arrays for PTA.

* gcc.c-torture/compile/pr36154.c: New testcase.

2008-05-08  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36172
* fold-const.c (operand_equal_p): Two objects which types
differ in pointerness are not equal.

* gcc.c-torture/compile/pr36172.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr36154.c
  - copied unchanged from r135071,
trunk/gcc/testsuite/gcc.c-torture/compile/pr36154.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr36172.c
  - copied unchanged from r135071,
trunk/gcc/testsuite/gcc.c-torture/compile/pr36172.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c


-- 


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

[Bug middle-end/36154] [4.3 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-05-08 08:21 ---
Subject: Bug 36154

Author: rguenth
Date: Thu May  8 08:20:45 2008
New Revision: 135071

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135071
Log:
2008-05-08  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36154
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Make
sure to create a representative for trailing arrays for PTA.

* gcc.c-torture/compile/pr36154.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr36154.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-05-08 08:20 
---
Subject: Bug 36172

Author: rguenth
Date: Thu May  8 08:19:16 2008
New Revision: 135070

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135070
Log:
2008-05-08  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36172
* fold-const.c (operand_equal_p): Two objects which types
differ in pointerness are not equal.

* gcc.c-torture/compile/pr36172.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr36172.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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