[Bug rtl-optimization/40153] Long long comparison optimized away incorrectly in Thumb code.

[dougkwan at google dot com]

--- Comment #1 from dougkwan at google dot com  2009-05-15 07:08 ---
This is caused by a typo in arm.md.

(define_insn "cstoresi_nltu_thumb1"
  [(set (match_operand:SI 0 "s_register_operand" "=l,l")
(neg:SI (gtu:SI (match_operand:SI 1 "s_register_operand" "l,*h")
(match_operand:SI 2 "thumb1_cmp_operand" "lI*h,*r"]
  "TARGET_THUMB1"
  "cmp\\t%1, %2\;sbc\\t%0, %0, %0"
  [(set_attr "length" "4")]
)

The instruction cstoresi_nltu_thumb1 is used to compute the expression -(x < y)
where x and y are unsigned SI-type values.  The operand of the NEG RTX should
be a LTU RTX instead of a GTU RTX.  The incorrected RTX code caused a later CSE
pass to substitute this pattern:

(set x
(neg (gtu a b)))   <=== cstoresi_nltu_thumb1
(set y (neg x))

with

(set y (gtu a b))

I tried fixing the RTX code and the test case passed.


-- 


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[jakub at gcc dot gnu dot org]

--- Comment #37 from jakub at gcc dot gnu dot org  2009-05-15 07:56 ---
This patch looks very wrong.  It assumes that min_insn_size gives exact insn
sizes (current min_insn_size is very far from that, but even get_attr_length
isn't exact), doesn't take into account label alignments nor branch shortening
which can change the insn sizes afterwards and assumes that a p2align always
aligns to 16 bytes (it does not).
While the previous algorithm works with estimated 16 consecutive bytes rather
than 16 byte pages 0x0 ... 0xXXXF, that's because during machine reorg
you simply can't know in most cases where exactly the 16 byte page will start,
so you assume it can start (almost) anywhere (and use .p2align behavior to
align when needed).


-- 


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

[Bug libstdc++/40156] New: [4.4 Regression] Possible bogus warning in libstdc++ headers

[tbm at cyrius dot com]

I'm getting the following warning when compiling wesnoth.  I'm not sure if
this is a bug in the code or in GCC but Andrew Pinski said I should file a
bug so someone can take a look at it.

This happens with gcc 4.4, but not with 4.3.

(sid)700:t...@em64t: ~/src/wesnoth-1.6.2/src] g++-4.4 -c -O1 -Wall -Werror
game_preferences.ii
cc1plus: warnings being treated as errors
game_preferences.cpp: In constructor 'preferences::manager::manager()':
game_preferences.cpp:66: error: 'v.std::vector, std::allocator >,
std::allocator,
std::allocator > >
>::.std::_Vector_base, std::allocator >,
std::allocator,
std::allocator > > >::_M_impl.std::_Vector_base, std::allocator >,
std::allocator,
std::allocator > > >::_Vector_impl::_M_start' may be used uninitialized
in this function
game_preferences.cpp:70: error: 'terrain.std::vector
>::.std::_Vector_base
>::_M_impl.std::_Vector_base >::_Vector_impl::_M_start' may be used
uninitialized in this function
zsh: exit 1 g++-4.4 -c -O1 -Wall -Werror game_preferences.ii


-- 
   Summary: [4.4 Regression] Possible bogus warning in libstdc++
headers
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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

[Bug libstdc++/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2009-05-15 08:10 ---
Created an attachment (id=17872)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17872&action=view)
Preprocessed code


-- 


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

[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-05-15 08:26 ---
(In reply to comment #1)
> This is caused by a typo in arm.md.
> 
> (define_insn "cstoresi_nltu_thumb1"
>   [(set (match_operand:SI 0 "s_register_operand" "=l,l")
> (neg:SI (gtu:SI (match_operand:SI 1 "s_register_operand" "l,*h")
> (match_operand:SI 2 "thumb1_cmp_operand" 
> "lI*h,*r"]
>   "TARGET_THUMB1"
>   "cmp\\t%1, %2\;sbc\\t%0, %0, %0"
>   [(set_attr "length" "4")]
> )
> 
> The instruction cstoresi_nltu_thumb1 is used to compute the expression -(x < 
> y)
> where x and y are unsigned SI-type values.  The operand of the NEG RTX should
> be a LTU RTX instead of a GTU RTX.  The incorrected RTX code caused a later 
> CSE
> pass to substitute this pattern:
> 
> (set x
> (neg (gtu a b)))   <=== cstoresi_nltu_thumb1
> (set y (neg x))
> 
> with
> 
> (set y (gtu a b))
> 
> I tried fixing the RTX code and the test case passed.
> 

This looks correct. Please submit a patch to gcc-patc...@.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-15 08:26:09
   date||


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

[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.

[dougkwan at google dot com]

--- Comment #3 from dougkwan at google dot com  2009-05-15 08:28 ---
Subject: Re:  Long long comparison optimized away 
incorrectly in Thumb code.

I am running regression tests and will submit a patch tomorrow morning
after that.

-Doug

2009/5/15 ramana at gcc dot gnu dot org :
>
>
> --- Comment #2 from ramana at gcc dot gnu dot org  2009-05-15 08:26 
> ---
> (In reply to comment #1)
>> This is caused by a typo in arm.md.
>>
>> (define_insn "cstoresi_nltu_thumb1"
>>   [(set (match_operand:SI 0 "s_register_operand" "=l,l")
>>         (neg:SI (gtu:SI (match_operand:SI 1 "s_register_operand" "l,*h")
>>                         (match_operand:SI 2 "thumb1_cmp_operand" 
>> "lI*h,*r"]
>>   "TARGET_THUMB1"
>>   "cmp\\t%1, %2\;sbc\\t%0, %0, %0"
>>   [(set_attr "length" "4")]
>> )
>>
>> The instruction cstoresi_nltu_thumb1 is used to compute the expression -(x < 
>> y)
>> where x and y are unsigned SI-type values.  The operand of the NEG RTX should
>> be a LTU RTX instead of a GTU RTX.  The incorrected RTX code caused a later 
>> CSE
>> pass to substitute this pattern:
>>
>> (set x
>>     (neg (gtu a b)))   <=== cstoresi_nltu_thumb1
>> (set y (neg x))
>>
>> with
>>
>> (set y (gtu a b))
>>
>> I tried fixing the RTX code and the test case passed.
>>
>
> This looks correct. Please submit a patch to gcc-patc...@.
>
>
> --
>
> ramana at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> 
>             Status|UNCONFIRMED                 |NEW
>     Ever Confirmed|0                           |1
>   Last reconfirmed|-00-00 00:00:00         |2009-05-15 08:26:09
>               date|                            |
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug tree-optimization/40071] ICE assert aliasing in vectorizable_store, at tree-vect-stmts.c:3108 on mipsel abi=n32 and 64, works at 32

[rguenther at suse dot de]

--- Comment #4 from rguenther at suse dot de  2009-05-15 08:39 ---
Subject: Re:  ICE assert aliasing in
 vectorizable_store, at tree-vect-stmts.c:3108 on mipsel abi=n32 and 64,
 works at 32

On Thu, 14 May 2009, ebotcazou at gcc dot gnu dot org wrote:

> --- Comment #3 from ebotcazou at gcc dot gnu dot org  2009-05-14 14:54 
> ---
> Richard, the subtype bounds removal patch will expose this on x86-64 as well.
> 
> Vectorization is not a priority in Ada for the time being so I'll go ahead, 
> but
> do you have an idea about the nature of the problem?

The assertion ensures that when the vectorizer replaces a store the
replacement store conflicts with at least the statements the original
store conflicted.

I will have a look once I can reproduce this on x86_64.

Richard.


-- 


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

[Bug middle-end/40157] New: [4.4 Regression] ICE with -floop-block

[arthur dot loiret at gmail dot com]

Hi,

With this simple testcase:

int buffer[256*256];
int main(void)
{
int *dest = buffer;
int x, y;
for(x = 0; x < 256; x++)
for(y = 0; y < 256; y++)
*dest++ = 0;
return 0;
}

We get an ICE:

% gcc-4.4 -O1 -floop-block foo.c -o foo
foo.c: In function ‘main’:
foo.c:2: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:4295
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Thanks.


-- 
   Summary: [4.4 Regression]  ICE with -floop-block
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arthur dot loiret at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong

[rguenther at suse dot de]

--- Comment #7 from rguenther at suse dot de  2009-05-15 08:44 ---
Subject: Re:  [4.3/4.4/4.5 Regression] Number
 of iterations analysis wrong

On Fri, 15 May 2009, rakdver at gcc dot gnu dot org wrote:

> --- Comment #6 from rakdver at gcc dot gnu dot org  2009-05-15 00:34 
> ---
> (In reply to comment #5)
> > It is number of iteration analysis that gets it wrong (I suppose it might 
> > get
> > confused by the two exits of the loop?).
> 
> Sort of; # of iterations analysis assumes that pointers never wrap, and uses
> this assumption to derive a wrong number of iterations for the first exit
> (which is not taken).  We had a similar problem before (PR 25985), but I
> somehow persuaded myself that this cannot happen with pointers.

Ah - it indeed cannot happen, but you need to assume that the offsets
in POINTER_PLUS_EXPRs are signed (even though they are unsigned as
they are of type sizetype).  At least that should be the only
"overflow" present in this testcase, no?

Richard.


-- 


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

[Bug middle-end/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-05-15 09:02 
---
Definitely bogus, maybe we already have something open about this issue, CC-ing
Richard, to be sure...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
  Component|libstdc++   |middle-end


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

[Bug middle-end/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2009-05-15 09:11 ---
Does it happen on trunk?

The testcase is too big.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug tree-optimization/40071] ICE (aliasing assert) in vectorizable_store at tree-vect-stmts.c:3117

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-05-15 09:14 
---
Confirmed on x86-64.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|mipsel-linux-gnu|
   GCC host triplet|mipsel-linux-gnu|
 GCC target triplet|mipsel-linux-gnu|
   Last reconfirmed|-00-00 00:00:00 |2009-05-15 09:14:03
   date||
Summary|ICE assert aliasing in  |ICE (aliasing assert) in
   |vectorizable_store, at tree-|vectorizable_store at tree-
   |vect-stmts.c:3108 on mipsel |vect-stmts.c:3117
   |abi=n32 and 64, works at 32 |


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

[Bug middle-end/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-15 09:17 ---
It is an uninitialized use in an exception handler.

;; basic block 132, loop depth 0, count 0
;; prev block 131, next block 133
;; pred:   131 (ab,eh,exec)
;; succ:   135 [100.0%]  (fallthru,exec)
:
save_filt.2381_159 = [filter_expr] <<>>;
save_eptr.2380_160 = [exc_ptr_expr] <<>>;
ivtmp.6668_667 = (long unsigned int) v$D45569$_M_impl$_M_start_645(D);
goto ;

possibly reached from

;; basic block 116, loop depth 0, count 0
;; prev block 115, next block 117
;; pred:   115 [100.0%]  (fallthru,exec)
;; succ:   131 (ab,eh,exec) 117 [100.0%]  (fallthru,exec)
:
D.141736 = get (&D.141735); [return slot optimization]


we could avoid warning for these at all but I am not sure if that would
be appreciated.


-- 


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[billingd at gcc dot gnu dot org]

--- Comment #11 from billingd at gcc dot gnu dot org  2009-05-15 09:24 
---
Subject: Bug 36211

Author: billingd
Date: Fri May 15 09:23:58 2009
New Revision: 147565

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147565
Log:
2009-05-15  David Billinghurst 

PR libstdc++/36211
* testsuite/lib/libstdc++.exp(v3_target_compile):  Add
cxxldflags to additional_flags rather than cxx_final.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/lib/libstdc++.exp


-- 


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

[Bug c++/40139] [4.4/4.5 Regression] ICE on invalid use of destructor

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-05-15 10:06 ---
Particularly the dependent_type_p -> dependent_scope_p change in
finish_id_expression makes the difference here.  BIT_NOT_EXPR of a RECORD_TYPE
makes it through till tsubsting and isn't errored as invalid use of destructor
in that case.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)

[bonzini at gnu dot org]

--- Comment #12 from bonzini at gnu dot org  2009-05-15 10:08 ---
Andrew, any news?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #84 from bonzini at gnu dot org  2009-05-15 10:35 ---
Ok, I am working on a patch to add a multiple-definitions DF problem and use
that together with a domwalk to find the single definitions (instead of
reaching-definitions, which is the remaining slow part).  The new problem has a
bitvector sized by the number of registers rather than the number of defs (that
is sized like the bitvectors for liveness), which means it will be fast.  It is
defined as follows:

MDkill (B) = regs that have a def in B
MDinit (B) = (union of MDkill (P) for every P : B \in DomFrontier(P) \cap
LRin(B)
MDin (B) = MDinit (B) \cup (union of MDout (P) for every predecessor P of B)
MDout (B) = MDin (B) - MDkill (B)


-- 


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

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-05-15 10:32 ---
Proc-pointer fun as written by Malcolm Cohen,
  http://j3-fortran.org/pipermail/j3/2009-May/002755.html

If I understood his arguments correctly, even the following Fortran 90 program
might be affected:

module m
  IMPLICIT logical(1)(A-Z)
  external proc
end module m

program test
use m
implicit none ! << optionally remove this line
logical(1) :: x
x = proc()
end program test

It currently fails with ifort, NAG f95, sunf95, openf95, pathf95, pgf95, and
gfortran. (g95 seeming properly accepts it - and rejects it if one changes the
IMPLICIT logical to something incompatible.)

 * * *

Otherwise, the example proposed by Richard is invalid. (I think that is line
with current gfortran.)

 * * *

Regarding

  implicit none
  PROCEDURE(REAL) :: func
  PROCEDURE(), POINTER :: ptr
  ptr => func

that seems to be invalid and thus is needs to be rejected, but I think it is
currently accepted.

(Please follow the thread and check also the final outcome of the
interpretation request.)


-- 


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

[Bug c/40150] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188 with -combine

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-15 11:03 ---
Confirmed with

gcc -c -std=gnu99 -O -combine lv2log.i sim-common.i
sim-common.c: In function ‘main_chute’:
sim-common.c:88: internal compiler error: in
cgraph_estimate_size_after_inlining, at ipa-inline.c:188
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

;; Function main_chute (main_chute)

Considering inline candidate trace_printf.

void trace_printf(const char *fmt, ...) __attribute__((format(printf,1,2)));

void trace_printf(const char *fmt, ...)
{
# 41 "sim-common.c"
}

---

void trace_printf(const char *fmt, ...) __attribute__((format(printf,1,2)));

void main_chute(_Bool go)
{
 if(go)
  trace_printf("FC deployed main chute\n");
 else
  trace_printf("FC stopped deploying main chute\n");
}

but this small example does not reproduce it.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|internal compiler error: in |ICE in
   |cgraph_estimate_size_after_i|cgraph_estimate_size_after_i
   |nlining, at ipa-inline.c:188|nlining, at ipa-inline.c:188
   ||with -combine


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

[Bug inline-asm/40152] Illegal instruction in bits/mathinline.h:613

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-15 11:04 ---
This is not part of GCC but glibc.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/40157] ICE with -floop-block

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-15 11:05 ---
Not a regression, -floop-block is new.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org
  Component|middle-end  |tree-optimization
   Keywords||ice-on-valid-code
Summary|[4.4 Regression]  ICE with -|ICE with -floop-block
   |floop-block |
Version|unknown |4.4.0


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

[Bug middle-end/40141] [4.3 Regression] accessing aliased __m128 miscompiles

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-05-15 11:09 ---
Created an attachment (id=17873)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17873&action=view)
patch

This is a patch backporting the fix and followups necessary to fix the fallout
(and the new testcases).


-- 


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[jakub at gcc dot gnu dot org]

--- Comment #38 from jakub at gcc dot gnu dot org  2009-05-15 12:11 ---
To extend #c31, I've also built the same tree with another patch which made
sure ix86_avoid_jump_mispredicts is never called (change "&& optimize" into "&&
optimize > 4" in ix86_reorg).  cc1plus sizes were then
0x88d6d8 bytes for 64-bit cc1plus and 0x8c980c bytes for 32-bit cc1plus.
That is 2.42% smaller than vanilla resp. 2.06%.

I've also changed my testing script, so that it (hopefully, point me to errors)
follows the AMD rules more closely (namely that the last byte in the branch
insn counts, not the first one), will attach.
With that script, I got following number of violations for 64-bit cc1plus
(vanilla, +1patch, +2patches, +3patches, +4patches):
6, 7, 6, 51, 138
and for 32-bit cc1plus:
1, 2, 3, 34, 159.


-- 


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

[Bug tree-optimization/40071] ICE (aliasing assert) in vectorizable_store at tree-vect-stmts.c:3117

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-05-15 12:11 ---
We are vectorizing

:

:
  # J1_43 = PHI 
  J1_36 = J1_43 + 1;
  D.2354_35 = (long int) J1_36;
  VIEW_CONVERT_EXPR(*_init$P_ARRAY_1)[D.2354_35]{lb: D.2335_26 sz: 8} = 0B;
  if (D.2336_6 != J1_36)
goto ;
  else
goto ;

:
  goto ;

using a vector pointer of type vector struct loop_optimization1__r **.

The issue here is that for

VIEW_CONVERT_EXPR(*_init$P_ARRAY_1)[D.2354_35]

we use the alias set of *_init$P_ARRAY_1 because the array elements are
non-aliased.  As the vectorizer now creates an alias the resulting
stores through the pointer to the vector type do not conflict with the
original stores and we have created wrong code.

How I love Ada ;)

Well, the fix is to teach the vectorizer to never vectorize arrays with
non-aliased components (or any aggregate with such elements).  Or, as
they were introduced to allow more optimization, finally drop this
non-sensical non-aliased component stuff from the middle-end as well.

:P


-- 


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[jakub at gcc dot gnu dot org]

--- Comment #39 from jakub at gcc dot gnu dot org  2009-05-15 12:12 ---
Created an attachment (id=17874)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17874&action=view)
test4jmp.sh


-- 


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

[Bug fortran/40158] New: Misleading error message for passing a scalar to an array

[burnus at gcc dot gnu dot org]

The following program is rightly rejected. But the problem is not really that
the ranks are different (as the example shows for "i", which is valid). The
issue is that "j" is a scalar.  -- A user might also not be that familiar the
concept that a rank-0 array is equivalent to a scalar.


gfortran shows:
  Error: Rank mismatch in argument 'i' at (1) (1 and 0)
other compiles have, e.g.
  Error: Cannot pass scalar to array argument 'i' at (1)

  Error: Scalar supplied for array argument I (no. 1) of SUB

  Illegal association of a scalar actual argument with array dummy argument
"I".

  error #7836: If the actual argument is scalar, the corresponding dummy
argument shall be scalar unless the actual argument is an element of an array
that is not an assumed-shape or pointer array, or a substring of such an
element.   [I]

Though I'm not sure whether one needs to be as long as ifort.

Cool stuff: If one changes the "contains" into "end" and removes the last line,
gfortran -fwhole-file still detects the violated constraint, while ifort, g95,
openf95 miss it. NAG f95 also detects it.

implicit none
 integer :: i(4,5),j
 i = 0
 call sub(i)
 call sub(j)  ! Wrong scalar passed to array
 print '(5i0)', i
contains
 subroutine sub(i)
   integer :: i(*)
   i(1) = 2
 end subroutine sub
end


-- 
   Summary: Misleading error message for passing a scalar to an
array
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug other/40159] New: [4.5 regression] "make all" ignores build failures

[schwab at linux-m68k dot org]

Since r147415 all failures from recursive make calls are ignored and "make all"
always exits successfully.


-- 
   Summary: [4.5 regression] "make all" ignores build failures
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at linux-m68k dot org


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

[Bug tree-optimization/39999] [4.4/4.5 Regression] gcc 4.4.0 compiles in infinite loop

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-05-15 13:10 ---
Subject: Bug 3

Author: rguenth
Date: Fri May 15 13:09:53 2009
New Revision: 147573

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147573
Log:
2009-05-15  Richard Guenther  

PR tree-optimization/3
* gimple.h (gimple_expr_type): Use the expression type looking
through useless conversions.
* tree-ssa-sccvn.c (vn_nary_op_lookup_stmt): Use gimple_expr_type.
(vn_nary_op_insert_stmt): Likewise.
(simplify_binary_expression): Likewise.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c


-- 


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

[Bug tree-optimization/39999] [4.4 Regression] gcc 4.4.0 compiles in infinite loop

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-05-15 13:10 ---
Fixed on the trunk.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.3.3   |4.3.3 4.5.0
Summary|[4.4/4.5 Regression] gcc|[4.4 Regression] gcc 4.4.0
   |4.4.0 compiles in infinite  |compiles in infinite loop
   |loop|


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

[Bug rtl-optimization/40101] [4.5 Regression] 200.sixtrack ICEs in get_seqno_by_preds, at sel-sched-ir.c:3752

[abel at gcc dot gnu dot org]

--- Comment #2 from abel at gcc dot gnu dot org  2009-05-15 13:20 ---
The bug happens when we compute a seqno for the newly created bookkeping insn. 
Seqnos exist in the algorithm (roughly) to guide the movement of fences so
that, first, all unscheduled insns will be found and scheduled, and second,
"dynamic" back-edges during pipelining will be properly marked.  

The assert we hit just means that the existing code was unable to compute the
proper seqno, because it looks only on direct succs/preds of the place we want
to insert bookkeeping, yet in the test case the fences are processed in such an
order that all of those succs/preds are already scheduled (we're pipelining). 
The fix would be to extend this code to walk further to find yet unscheduled
insns and to derive the seqno from them.  

However, thinking about it further, I believe that we can get rid of seqnos
altogether.  We already have topological sorting for basic blocks in the
scheduler, and it should be enough just to check that we don't hit other fence
or already visited insn (or already scheduled insn if no pipelining) when
computing our availability sets, and it should be enough just to move fences to
unscheduled code.  The original approach also used seqnos to mark parallel
groups, but this is not needed for gcc.  So, as we are in Stage 1, and there is
no rush with this bug, I will try to get rid of seqnos first.  In case it turns
out I've overlooked anything, I will resort to the former, more conservative
fix.


-- 


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

[Bug tree-optimization/39999] [4.4 Regression] gcc 4.4.0 compiles in infinite loop

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2009-05-15 
13:37 ---
Will this fix be backported for gcc 4.4.1?


-- 


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

[Bug tree-optimization/39999] [4.4 Regression] gcc 4.4.0 compiles in infinite loop

[rguenther at suse dot de]

--- Comment #9 from rguenther at suse dot de  2009-05-15 13:47 ---
Subject: Re:  [4.4 Regression] gcc 4.4.0 compiles
 in infinite loop

On Fri, 15 May 2009, howarth at nitro dot med dot uc dot edu wrote:

> --- Comment #8 from howarth at nitro dot med dot uc dot edu  2009-05-15 
> 13:37 ---
> Will this fix be backported for gcc 4.4.1?

Yes, I will wait a few days to spot problems though.

Richard.


-- 


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

[Bug libstdc++/40160] New: -fno-rtti vs _GLIBCXX_DEBUG

[jay dot foad at gmail dot com]

I get:

$ cat s.cpp
#include 
$ g++ -c -fno-rtti -D_GLIBCXX_DEBUG s.cpp
In file included from /usr/include/c++/4.3/debug/debug.h:155,
 from /usr/include/c++/4.3/bits/stl_algobase.h:76,
 from /usr/include/c++/4.3/bits/char_traits.h:46,
 from /usr/include/c++/4.3/string:47,
 from s.cpp:1:
/usr/include/c++/4.3/debug/formatter.h: In constructor
‘__gnu_debug::_Error_formatter::_Parameter::_Parameter(const
__gnu_debug::_Safe_iterator<_Iterator, _Sequence>&, const char*,
__gnu_debug::_Error_formatter::_Is_iterator)’:
/usr/include/c++/4.3/debug/formatter.h:218: error: cannot use typeid with
-fno-rtti
/usr/include/c++/4.3/debug/formatter.h:224: error: cannot use typeid with
-fno-rtti
/usr/include/c++/4.3/debug/formatter.h: In constructor
‘__gnu_debug::_Error_formatter::_Parameter::_Parameter(const _Type*&, const
char*, __gnu_debug::_Error_formatter::_Is_iterator)’:
/usr/include/c++/4.3/debug/formatter.h:247: error: cannot use typeid with
-fno-rtti
/usr/include/c++/4.3/debug/formatter.h: In constructor
‘__gnu_debug::_Error_formatter::_Parameter::_Parameter(_Type*&, const char*,
__gnu_debug::_Error_formatter::_Is_iterator)’:
/usr/include/c++/4.3/debug/formatter.h:260: error: cannot use typeid with
-fno-rtti
/usr/include/c++/4.3/debug/formatter.h: In constructor
‘__gnu_debug::_Error_formatter::_Parameter::_Parameter(const _Iterator&, const
char*, __gnu_debug::_Error_formatter::_Is_iterator)’:
/usr/include/c++/4.3/debug/formatter.h:273: error: cannot use typeid with
-fno-rtti
/usr/include/c++/4.3/debug/formatter.h: In constructor
‘__gnu_debug::_Error_formatter::_Parameter::_Parameter(const
__gnu_debug::_Safe_sequence<_Sequence>&, const char*,
__gnu_debug::_Error_formatter::_Is_sequence)’:
/usr/include/c++/4.3/debug/formatter.h:289: error: cannot use typeid with
-fno-rtti
/usr/include/c++/4.3/debug/formatter.h: In constructor
‘__gnu_debug::_Error_formatter::_Parameter::_Parameter(const _Sequence&, const
char*, __gnu_debug::_Error_formatter::_Is_sequence)’:
/usr/include/c++/4.3/debug/formatter.h:298: error: cannot use typeid with
-fno-rtti

Shouldn't uses of typeid in the library be guarded with #ifdef _GXX_RTTI, or
something?

I'm using g++ 4.3.2 on Debian lenny.


-- 
   Summary: -fno-rtti vs _GLIBCXX_DEBUG
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot foad at gmail dot com


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

[Bug libstdc++/40160] -fno-rtti vs _GLIBCXX_DEBUG

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-05-15 14:27 
---
I get your point, indeed I implemented __GXX_RTTI and put it to good use in
has_facet / use_facet. However, here, what happens to debug mode if typeid is
not available? Is it still largely usable? If not, and I'm afraid is not, then
probably the error is rather appropriate, we can maybe make it more clear, but
it's essentially. Or you believe debug mode can be made to work also together
with -fno-rtti?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[hjl dot tools at gmail dot com]

--- Comment #40 from hjl dot tools at gmail dot com  2009-05-15 14:35 
---
(In reply to comment #37)
> This patch looks very wrong.  It assumes that min_insn_size gives exact insn
> sizes (current min_insn_size is very far from that, but even get_attr_length
> isn't exact), doesn't take into account label alignments nor branch shortening
> which can change the insn sizes afterwards and assumes that a p2align always
> aligns to 16 bytes (it does not).
> While the previous algorithm works with estimated 16 consecutive bytes rather
> than 16 byte pages 0x0 ... 0xXXXF, that's because during machine reorg
> you simply can't know in most cases where exactly the 16 byte page will start,
> so you assume it can start (almost) anywhere (and use .p2align behavior to
> align when needed).
> 

There is no perfect solution here. Let's list pros/cons:

The current algorithm:

pros:

1. Very conservative. Catch most of 4 branches in 16byte windows.

Cons:

1. It works on 16byte window, not 16byte page.
2. When it gets wrong, it increases code sizes by adding unnecessary
nops.

My proposal:

Pros:

1. Work on 16byte page.
2. Even if it gets wrong, it doesn't increase code size.

Cons:

1. Rely on inaccurate instruction length data.


-- 


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

[Bug libstdc++/40160] -fno-rtti vs _GLIBCXX_DEBUG

[jay dot foad at gmail dot com]

--- Comment #2 from jay dot foad at gmail dot com  2009-05-15 14:37 ---
I'm using debug mode to catch problems like v[i] where i >= v.size(). I think
it would be very nice if this worked with -fno-rtti. I don't see why RTTI
should be required to make this work. But then, I have no idea why typeid is
being used in debug/formatter.h in the first place.

As a workaround, I am removing -fno-rtti from the command line when I build my
project with libstdc++ debug mode enabled, but it is annoying to have to do
this for a project that doesn't use RTTI.


-- 


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

[Bug libstdc++/40160] -fno-rtti vs _GLIBCXX_DEBUG

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-05-15 14:48 
---
Ok. In fact, being typeid used in formatter.h only (please confirm, if you
can), I suspect not using it (replacing &typeid with 0) would only lead to
worse error message, not more than that. Are you willing to experiment a bit
with that? It would imply wrapping those place where _M_type is assigned with
__GXX_RTTI, and also, careful, tweaking a bit src/debug.cc to not assert
_M_type != 0, instead conditionalize consistently on that, have something like
"" in its place. Please let me know...


-- 


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

[Bug middle-end/40161] New: [4.5 Regression] Revision 147566 may cause many regressions

[hjl dot tools at gmail dot com]

Revision 147566 gave:

FAIL: g++.dg/eh/filter2.C execution test
FAIL: gcc.c-torture/compile/pr22379.c  -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr22379.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr22379.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr22379.c  -O3 -fomit-frame-pointer -funroll-loops 
(test for excess errors)
FAIL: gcc.c-torture/compile/pr22379.c  -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr22379.c  -Os  (test for excess errors)
FAIL: gcc.dg/ipa/ipa-4.c scan-ipa-dump-times cp "replacing param a with const
7" 1
FAIL: gcc.dg/ipa/ipa-4.c scan-ipa-dump-times cp "versioned function" 1
FAIL: gcc.dg/sibcall-1.c execution test
FAIL: gcc.dg/sibcall-2.c execution test
FAIL: gcc.dg/sibcall-3.c execution test
FAIL: gcc.dg/sibcall-4.c execution test
FAIL: gcc.dg/sibcall-6.c execution test
FAIL: gcc.dg/tree-prof/inliner-1.c scan-tree-dump optimized "cold_function ..;"
FAIL: gcc.dg/vect/costmodel/i386/costmodel-vect-33.c scan-tree-dump-times vect
"vectorization not profitable" 1
FAIL: gcc.dg/vect/pr18400.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr31699.c scan-tree-dump-times vect "vectorized 1 loops" 2
FAIL: gcc.dg/vect/vect-iv-10.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/winline-5.c  (test for warnings, line 28)
FAIL: gcc.dg/winline-5.c  (test for warnings, line 5)
FAIL: gcc.target/i386/align-main-1.c scan-assembler and[lq]?[\\t ]*\\$-128,[\\t
]*%[re]?sp
FAIL: gcc.target/i386/align-main-2.c scan-assembler and[lq]?[\\t ]*\\$-64,[\\t
]*%[re]?sp
FAIL: tr1/3_function_objects/function/5.cc (test for excess errors)
FAIL: tr1/3_function_objects/function/8.cc (test for excess errors)

Revision 147564 is OK. Revision 147566:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00542.html

may be the cause.


-- 
   Summary: [4.5 Regression]  Revision 147566 may cause many
regressions
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
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=40161

[Bug middle-end/40162] New: autoparallelization should update ESCAPED

[rguenth at gcc dot gnu dot org]

Just a reminder PR for me.

The reason why auto-parallelization has TODO_rebuild_alias is that it generates
a .paral_data_store structure where it stores pointers to new address-taken
variables and passes the address of that structure to the new parallel worker
clone.  This makes ESCAPED incomplete and causes followup DCE to delete stores
to .paral_data_store if points-to information (and ESCAPED) is not rebuilt.

A way to amend the ESCAPED solution should be added and autopar should use it.


-- 
   Summary: autoparallelization should update ESCAPED
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: alias
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug middle-end/40162] autoparallelization should update ESCAPED

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-15 15:23:50
   date||


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

[Bug middle-end/40161] [4.5 Regression] Revision 147566 may cause many regressions

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-15 15:27 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug c++/40163] New: null pointer in remove_unreachable_regions

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package blocxx-2.1.0.342-124.2
with the GNU g++ version 4.5 snapshot 20090514.

The compiler said

LogAppender.cpp: In constructor 'blocxx6::LogAppender::LogAppender(const
blocxx6::StringArray&, const blocxx6::StringArray&, const blocxx6::String&)':
LogAppender.cpp:401: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flags -fPIC -O2 required.

Here is some valgrind output

==18958== Invalid read of size 8
==18958==at 0x6EEB91: remove_unreachable_regions (bitmap.h:225)
==18958==by 0x8FCA9C: cleanup_eh (tree-eh.c:2764)
==18958==by 0x820CD0: execute_one_pass (passes.c:1283)
==18958==by 0x820F34: execute_pass_list (passes.c:1332)
==18958==by 0x914DFB: tree_rest_of_compilation (tree-optimize.c:394)
==18958==by 0xA77400: cgraph_expand_function (cgraphunit.c:1095)
==18958==by 0xA79154: cgraph_optimize (cgraphunit.c:1154)
==18958==by 0x52E1DC: cp_write_global_declarations (decl2.c:3635)
==18958==by 0x8C6543: toplev_main (toplev.c:1044)
==18958==by 0x54D7585: (below main) (in /lib64/libc-2.9.so)
==18958==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


-- 
   Summary: null pointer in remove_unreachable_regions
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/40163] null pointer in remove_unreachable_regions

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-05-15 15:37 ---
Created an attachment (id=17875)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17875&action=view)
C++ source code


-- 


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

[Bug libstdc++/40160] -fno-rtti vs _GLIBCXX_DEBUG

[jay dot foad at gmail dot com]

--- Comment #4 from jay dot foad at gmail dot com  2009-05-15 15:39 ---
> typeid used in formatter.h only (please confirm, if you can)

If I replace typeid(...) with 0 in formatter.h then I can at least compile the
following with -fno-rtti -D_GLIBCXX_DEBUG:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

I'm not really in a position to test changes to libstdc++.so, sorry.


-- 


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

[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #8 from rakdver at kam dot mff dot cuni dot cz  2009-05-15 
15:44 ---
Subject: Re:  [4.3/4.4/4.5 Regression] Number of iterations analysis wrong

> > > It is number of iteration analysis that gets it wrong (I suppose it might 
> > > get
> > > confused by the two exits of the loop?).
> > 
> > Sort of; # of iterations analysis assumes that pointers never wrap, and uses
> > this assumption to derive a wrong number of iterations for the first exit
> > (which is not taken).  We had a similar problem before (PR 25985), but I
> > somehow persuaded myself that this cannot happen with pointers.
> 
> Ah - it indeed cannot happen, but you need to assume that the offsets
> in POINTER_PLUS_EXPRs are signed (even though they are unsigned as
> they are of type sizetype).

that is not the problem.  The problem is that # of iterations analysis
has a look at the first test, of form [x,+,4] == [x + 28, +, -4],
observes that the variables do not wrap, and concludes that the loop
is not infinite.  So far OK, but next we infer that this means that
the exit is taken, i.e., that 28 % 8 = 0, and the things go down for
there.  I fixed this error before, but special-cased the pointer ivs
in a strike of wishful thinking.


-- 


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

[Bug tree-optimization/40071] ICE (aliasing assert) in vectorizable_store at tree-vect-stmts.c:3117

[laurent at guerby dot net]

--- Comment #7 from laurent at guerby dot net  2009-05-15 16:23 ---
Indeed, at revision 147567 on x86_64-linux:

http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg01235.html

Running target unix/-m64
FAIL: gnat.dg/loop_optimization1.adb (test for excess errors)


-- 


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

[Bug c++/40163] [4.5 Regression] null pointer in remove_unreachable_regions

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
Summary|null pointer in |[4.5 Regression] null
   |remove_unreachable_regions  |pointer in
   ||remove_unreachable_regions
   Target Milestone|--- |4.5.0


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[jakub at gcc dot gnu dot org]

--- Comment #41 from jakub at gcc dot gnu dot org  2009-05-15 16:24 ---
The 34 resp. 51 4 branches in 16 byte page with the 3 patches together made me
look at one of the cases which was wrong and the problem is that cmp $0x1d, %al
has too large get_attr_lenght (insn) returned, 3 instead of 2, because GCC
thinks it has modrm byte when it has not.
Testing:
--- gcc/config/i386/i386.md.jj2009-05-13 08:42:51.0 +0200
+++ gcc/config/i386/i386.md2009-05-15 18:06:40.0 +0200
@@ -504,6 +504,9 @@
  (and (eq_attr "type" "callv")
   (match_operand 1 "constant_call_address_operand" ""))
  (const_int 0)
+ (and (eq_attr "type" "alu,alu1,icmp,test")
+  (match_operand 0 "ax_reg_operand" ""))
+ (symbol_ref "(get_attr_length_immediate (insn) > (get_attr_mode (insn) !=
MODE_QI))")
  ]
  (const_int 1)))

now on top of the 3 patches (without the 4th) to see what it does to code size
and number of 4+ branches in 16 byte page.


-- 


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

[Bug tree-optimization/40157] ICE with -floop-block

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2009-05-15 17:49 ---
This problem is fixed in the Graphite branch.  I guess that the
problem comes from the fact that in GCC4.4 we did not handled
INDIRECT_REF in expand_scalar_variables_expr.  

Should I back-port that code?

Thanks,
Sebastian


-- 


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[jakub at gcc dot gnu dot org]

--- Comment #42 from jakub at gcc dot gnu dot org  2009-05-15 18:18 ---
Sizes with the #c41 patch together with the 3 patches mentioned in #c31 are:
0x890038 (64-bit) and 0x8ce08c (32-bit), 44 bad 16-byte pages in 64-bit, 35 in
32-bit.


-- 


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

[Bug fortran/40164] New: Fortran 2003: "Arrays of procedure pointers"

[janus at gcc dot gnu dot org]

PROGRAM test_prog

 TYPE ProcPointerArray
   PROCEDURE(add), POINTER, NOPASS :: f
 END TYPE ProcPointerArray

 TYPE (ProcPointerArray) :: f_array(1)
 PROCEDURE(add), POINTER :: f

 f_array(1)%f => add
 f => f_array(1)%f
 PRINT*, f(2.,4.)

CONTAINS

 FUNCTION add(a,b) RESULT(sum)
   REAL, INTENT(in) :: a, b
   REAL :: sum
   sum = a + b
 END FUNCTION add

END PROGRAM test_prog


This produces the error

 f => f_array(1)%f
1
Error: VARIABLE attribute of 'f_array' conflicts with PROCEDURE attribute at
(1)

Reported by Barron Bichon.


-- 
   Summary: Fortran 2003: "Arrays of procedure pointers"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[jakub at gcc dot gnu dot org]

--- Comment #43 from jakub at gcc dot gnu dot org  2009-05-15 18:23 ---
Some code size growth is from enlarged get_attr_modrm though, 292 bytes for
64-bit, 1338 bytes for 32-bit.


-- 


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

[Bug fortran/40165] New: Excessive warnings for REAL DO loops

[burnus at gcc dot gnu dot org]

do real_var = 0.0, 10.0, 0.1
  print *, real_var
end do

is valid Fortran 77 (not in 66) but it was deleted from newer Fortran
standards. gfortran barks if it finds one, but instead of printing one error
message it prints four (loop variable, start, end and increment), which is a
bit too much. 

Expected: There is only one warning message printed.

a.f90:4.6:

  do x =0., 10., dx
 1
Warning: Deleted feature: Loop variable at (1) must be integer
a.f90:4.8:

  do x =0., 10., dx
   1
Warning: Deleted feature: Start expression in DO loop at (1) must be
integer
a.f90:4.11:

  do x =0., 10., dx
  1
Warning: Deleted feature: End expression in DO loop at (1) must be
integer
a.f90:4.16:

  do x =0., 10., dx
   1
Warning: Deleted feature: Step expression in DO loop at (1) must be
integer


-- 
   Summary: Excessive warnings for REAL DO loops
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/40165] Excessive warnings for REAL DO loops

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-05-15 18:51 ---
I disagree with you as does the F95 standard (if I'm
not misreading the standard).

1.5 Conformance

 (3) It contains the capability to detect and report the use within
 a submitted program unit of an additional form or relationship
 that is not permitted by the numbered syntax rules or their
 associated constraints, including the deleted features described
 in Annex B;

The F95 standard explicitly lists a constraint that the do-variable
is an INTEGER.  It also explicitly lists that start, end, and step
are scalar-int-expr.  By 1.5(3), gfortran must provide a means to
detect and report the (mis)uses of 'do x = 0., 10. 0.1'.  That's
4 warnings.


-- 


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

[Bug libstdc++/40160] -fno-rtti vs _GLIBCXX_DEBUG

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-05-15 19:34 
---
Ok, thanks. I'll fix it as I said earlier today.


-- 

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|WAITING |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-15 19:34:10
   date||


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

[Bug c/16302] gcc fails to warn about some common logic errors

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2009-05-15 20:08 ---
Subject: Bug 16302

Author: manu
Date: Fri May 15 20:08:21 2009
New Revision: 147596

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147596
Log:
2009-05-15  Manuel López-Ibáñez  

PR 16302
* fold-const.c (make_range,build_range_check,merge_ranges): Move
declaration to...
(merge_ranges): Returns bool. 
* tree.h (make_range): .. to here.
(build_range_check): Likewise.
(merge_ranges): Likewise. Renamed from merge_ranges.
* c-typeck.c (parser_build_binary_op): Update calls to
warn_logical_operator.
* c-common.c (warn_logical_operator): Add new warning.
* c-common.h (warn_logical_operator): Update declaration.
cp/
* call.c (build_new_op): Update calls to warn_logical_operator.

testsuite/
* gcc.dg/pr16302.c: New.
* g++.dg/warn/pr16302.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr16302.C
trunk/gcc/testsuite/gcc.dg/pr16302.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-common.h
trunk/gcc/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.h


-- 


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

[Bug c/16302] gcc fails to warn about some common logic errors

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2009-05-15 20:10 ---
FIXED for GCC 4.5


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/36513] -Wlogical-op warns about strchr

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2009-05-15 20:13 ---
Benjamin, note that -Wlogical-op will be enabled by -Wextra in GCC 4.5. 

I am willing to give it a try to fix this before 4.5 is released. However, I
cannot reproduce this problem, so please, provide a preprocessed testcase.


-- 


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

[Bug fortran/40165] Excessive warnings for REAL DO loops

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-05-15 20:23 ---
(In reply to comment #1)
> I disagree with you as does the F95 standard

Sorry, I cannot find anywhere in the standard that one has to emit four
warnings. First, I think that one warning for a real loop variable is enough
(if the loop variable is integer, but e.g. step is real, I of cause expect a
warning there). Second, one can also emit a warning stating:

Warning: Deleted feature: Loop variable and start, stop, and step expression at
(1) must [all] be integer [but are all real]

where [...] is optional text to really stress that all four constrains are
violated.


-- 


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

[Bug fortran/40165] Excessive warnings for REAL DO loops

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2009-05-15 20:40 ---
(In reply to comment #2)
> (In reply to comment #1)
> > I disagree with you as does the F95 standard
> 
> Sorry, I cannot find anywhere in the standard that one has to emit four
> warnings.

I quoted the relevant text from F95.  See comment #1.

The standards requires that a conforming processor "detect and report
the use ... including the deleted features"

I don't care if it's one warning or 4, but all 4 deleted features
in 'do x = 0., 10., 0.1' must be detected and reported.  Gfortran's
current behavior is conforming.  To be clear, there are 16 possible
combinations (and I'm not distinguishing between the various REAL
kind type parameters).   Are you going to construct correct (or at
least sensible English) sentences for the various combinations?

Why fix something that isn't broken and not very likely to occur
when there are some many other things to do?


-- 


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

[Bug tree-optimization/40071] ICE (aliasing assert) in vectorizable_store at tree-vect-stmts.c:3117

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2009-05-15 21:48 
---
> The issue here is that for
> 
> VIEW_CONVERT_EXPR *[D.2335:D.2339]>(*_init$P_ARRAY_1)[D.2354_35]
> 
> we use the alias set of *_init$P_ARRAY_1 because the array elements are
> non-aliased.  As the vectorizer now creates an alias the resulting
> stores through the pointer to the vector type do not conflict with the
> original stores and we have created wrong code.

Thanks for the analysis.  Looks like we lack non-aliased vectors here. ;-)


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-15 09:14:03 |2009-05-15 21:48:29
   date||


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

[Bug fortran/40164] Fortran 2003: "Arrays of procedure pointers"

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2009-05-15 21:51 ---
Here is a small patch which fixes the test case:

Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 147527)
+++ gcc/fortran/primary.c   (working copy)
@@ -2558,7 +2558,7 @@
   if (gfc_matching_procptr_assignment)
{
  gfc_gobble_whitespace ();
- if (gfc_peek_ascii_char () == '(')
+ if (!sym->attr.dimension && gfc_peek_ascii_char () == '(')
/* Parse functions returning a procptr.  */
goto function0;



-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-15 21:51:18
   date||


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

[Bug middle-end/39301] ICE in register_overhead, at bitmap.c:115

[lucier at math dot purdue dot edu]

--- Comment #8 from lucier at math dot purdue dot edu  2009-05-15 21:55 
---
Created an attachment (id=17876)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17876&action=view)
patch to use HOST_WIDEST_INT for bitmap statistics

Here's a hack to use HOST_WIDEST_INT for bitmap statistics.  I'll attach the
report from the compiler.i test case.  If you think the report is useful,
perhaps you can use this as a starting point for a real patch and I'll
bootstrap and test it.

Brad


-- 


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

[Bug middle-end/39301] ICE in register_overhead, at bitmap.c:115

[lucier at math dot purdue dot edu]

--- Comment #9 from lucier at math dot purdue dot edu  2009-05-15 21:57 
---
Created an attachment (id=17877)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17877&action=view)
memory and time report for compiler.i test case

Here's the output for the test case.  See if you like it.

I used the following configure command and compiler version:

pythagoras-147% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /tmp/lucier/gcc/mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline --enable-languages=c
--enable-gather-detailed-mem-stats --disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090515 (experimental) [trunk revision 147594] (GCC) 


-- 


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

[Bug libstdc++/40160] -fno-rtti vs _GLIBCXX_DEBUG

[paolo at gcc dot gnu dot org]

--- Comment #6 from paolo at gcc dot gnu dot org  2009-05-15 22:25 ---
Subject: Bug 40160

Author: paolo
Date: Fri May 15 22:25:24 2009
New Revision: 147599

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147599
Log:
2009-05-15  Paolo Carlini  

PR libstdc++/40160
* include/debug/formatter.h (_Parameter::_Parameter): Don't use
typeid when __GXX_RTTI is undefined.
* src/debug.cc (_Error_formatter::_Parameter::_M_print_field): Adjust
for null _M_variant._M_iterator._M_type,
_M_variant._M_iterator._M_seq_type, _M_variant._M_sequence._M_type.
* testsuite/21_strings/basic_string/40160.cc: New.

Added:
trunk/libstdc++-v3/testsuite/21_strings/basic_string/40160.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/formatter.h
trunk/libstdc++-v3/src/debug.cc


-- 


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

[Bug libstdc++/40160] -fno-rtti vs _GLIBCXX_DEBUG

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2009-05-15 22:27 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug middle-end/39301] ICE in register_overhead, at bitmap.c:115

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-05-15 22:29 
---
The patch is good enough.


-- 


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

[Bug c++/40163] [4.5 Regression] null pointer in remove_unreachable_regions

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2009-05-15 22:53 
---
Confirmed. Reduced testcase (crahses already with "-O"):

===
struct A
{
  void foo(int*, int);
};

struct B
{
  B();
  ~B() { A().foo(p, q - p); }

  int *p, *q;
};

struct C : B
{
  C() { bar(); }
  ~C() { baz(bar(), bar()); }
  int bar();
  void baz(int, int);
};

struct D
{
  D(C*);
  ~D() { try { delete p; } catch (...) {} }
  C* operator->() { delete p; return 0; }

  C* p;
};

struct E
{
  E() : d(new C) { d->baz(d->bar(), d->bar()); }

  D d;
};

struct F
{
  F();
  virtual ~F();

  E e1, e2, e3;
};

F::F() {}
F::~F() {}
===


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-15 22:53:07
   date||


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[hjl dot tools at gmail dot com]

--- Comment #44 from hjl dot tools at gmail dot com  2009-05-15 23:05 
---
(In reply to comment #41)
> The 34 resp. 51 4 branches in 16 byte page with the 3 patches together made me
> look at one of the cases which was wrong and the problem is that cmp $0x1d, 
> %al
> has too large get_attr_lenght (insn) returned, 3 instead of 2, because GCC
> thinks it has modrm byte when it has not.
> Testing:
> --- gcc/config/i386/i386.md.jj2009-05-13 08:42:51.0 +0200
> +++ gcc/config/i386/i386.md2009-05-15 18:06:40.0 +0200
> @@ -504,6 +504,9 @@
>   (and (eq_attr "type" "callv")
>(match_operand 1 "constant_call_address_operand" ""))
>   (const_int 0)
> + (and (eq_attr "type" "alu,alu1,icmp,test")
> +  (match_operand 0 "ax_reg_operand" ""))
> + (symbol_ref "(get_attr_length_immediate (insn) > (get_attr_mode (insn) 
> !=
> MODE_QI))")
>   ]
>   (const_int 1)))
> 

"cmp imm,%al/%ax/%eax/%rax" doesn't have the modrm byte. I think
this patch works better:

--- i386.md.branch  2009-05-15 11:30:42.0 -0700
+++ i386.md 2009-05-15 14:44:11.0 -0700
@@ -504,6 +504,10 @@
 (and (eq_attr "type" "callv")
  (match_operand 1 "constant_call_address_operand" ""))
 (const_int 0)
+(and (eq_attr "type" "alu,alu1,icmp,test")
+ (match_operand 0 "ax_reg_operand" "")
+ (match_operand 1 "immediate_operand" ""))
+(const_int 0)
 ]
 (const_int 1)))



-- 


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

[Bug fortran/39872] Bounds check off by one

[jb at gcc dot gnu dot org]

--- Comment #5 from jb at gcc dot gnu dot org  2009-05-15 23:45 ---
Subject: Bug 39872

Author: jb
Date: Fri May 15 23:45:08 2009
New Revision: 147601

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147601
Log:
Backport fix for PR libfortran/39872 from trunk.

Modified:
branches/gcc-4_4-branch/libgfortran/ChangeLog
branches/gcc-4_4-branch/libgfortran/io/transfer.c


-- 


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

[Bug fortran/39782] [4.3/4.4 Regression] IO depends on uninitialised value

[jb at gcc dot gnu dot org]

--- Comment #11 from jb at gcc dot gnu dot org  2009-05-15 23:50 ---
Backported to 4.4 branch as r147601.

Backporting to 4.3 caused regressions, so I'm tempted to just skip that.


-- 


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

[Bug middle-end/40154] [4.4/4.5 Regression] internal compiler error: in do_SUBST, at combine.c:681

[kkojima at gcc dot gnu dot org]

--- Comment #1 from kkojima at gcc dot gnu dot org  2009-05-16 00:08 ---
I've tried to see what is going on with -da.
.expand rtl dump shows that t *= 10 is compiled to
a sequence of insns and the last two insns are:

(insn 87 86 88 ice.i:6 (parallel [
(set (subreg:SI (reg:DI 220) 0)
(ashift:SI (subreg:SI (reg:DI 218) 0)
(const_int 9 [0x9])))
(clobber (scratch:SI))
]) -1 (expr_list:REG_EQUAL (mult:DI (reg:DI 169)
(const_int 10 [0x3b9aca00]))
(nil)))

(insn 88 87 0 ice.i:6 (set (mem/c/i:DI (plus:SI (reg/f:SI 167)
(const_int 56 [0x38])) [0 t+0 S8 A32])
(reg:DI 220)) -1 (nil))

Then CSE pass folds the constant multiplication and replaces
the above insn 87 with

(insn 87 86 108 2 ice.i:6 (set (reg:SI 229)
(const_int -1539607552 [0xa43b7400])) 175 {movsi_ie}
(expr_list:REG_EQUAL (const_int 500 [0xba43b7400])
(nil)))

and do_SUBST complains that SImode reg can't hold 500
at the combine pass.
I guess that the REG_EQUAL note of the original insn 87 is
suspicious.  It seems that the patch below avoids the problem,
though it may be completely wrong.  I'll ask the middle-end
experts on the gcc list about this issue.

--- ORIG/trunk/gcc/expmed.c 2009-05-12 19:17:54.0 +0900
+++ trunk/gcc/expmed.c  2009-05-16 08:34:14.0 +0900
@@ -2958,7 +2958,7 @@ expand_mult_const (enum machine_mode mod
   enum mult_variant variant)
 {
   HOST_WIDE_INT val_so_far;
-  rtx insn, accum, tem;
+  rtx insn, accum, tem, set;
   int opno;
   enum machine_mode nmode;

@@ -3074,9 +3074,12 @@ expand_mult_const (enum machine_mode mod
}

   insn = get_last_insn ();
-  set_unique_reg_note (insn, REG_EQUAL,
-  gen_rtx_MULT (nmode, tem,
-GEN_INT (val_so_far)));
+  set = single_set (insn);
+  if (set != 0
+ && GET_MODE (SET_DEST (set)) == nmode)
+   set_unique_reg_note (insn, REG_EQUAL,
+gen_rtx_MULT (nmode, tem,
+  GEN_INT (val_so_far)));
 }

   if (variant == negate_variant)


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.4.0 4.5.0
  Known to work||4.3.3
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-05-16 00:08:06
   date||
Summary|internal compiler error: in |[4.4/4.5 Regression]
   |do_SUBST, at combine.c:681  |internal compiler error: in
   ||do_SUBST, at combine.c:681


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue dot edu]

--- Comment #85 from lucier at math dot purdue dot edu  2009-05-16 00:20 
---
Created an attachment (id=17878)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17878&action=view)
Large test file for testing time and memory usage

This is the file compiler.i used in the previous tests.


-- 


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue dot edu]

--- Comment #86 from lucier at math dot purdue dot edu  2009-05-16 00:29 
---
Created an attachment (id=17879)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17879&action=view)
Time and memory report for compiler.i

This is the time and memory report after the hack from

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301#c8

to make the statistic fields HOST_WIDEST_INTs.

Some interesting lines:

fwprop.c:178 (build_single_def_use_links)8  8438189160  
82240   01027496
df-problems.c:311 (df_rd_alloc) 155420  8433928200 
8433870880  8433870880  0
df-problems.c:593 (df_rd_transfer_functio   909666 40718919320 
6755812320  67557368402025096
Total 13171390 61130398320


-- 


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue dot edu]

--- Comment #87 from lucier at math dot purdue dot edu  2009-05-16 00:33 
---
The compiler options for the previous report:

/pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I.  -Wall -W -Wno-unused
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -frename-registers
-fno-move-loop-invariants -fforward-propagate -DHAVE_CONFIG_H -D___PRIMAL
-D___LIBRARY -c compiler.i -ftime-report -fmem-report > &
rename-no-move-loop-invariants-forward-propagate-report-new


-- 


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

[Bug middle-end/39301] ICE in register_overhead, at bitmap.c:115

[lucier at math dot purdue dot edu]

--- Comment #11 from lucier at math dot purdue dot edu  2009-05-16 01:21 
---
Created an attachment (id=17880)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17880&action=view)
The regression test results

So it's passed bootstrap and regression tested.

configure flags: --prefix=/pkgs/gcc-mainline --enable-gather-detailed-mem-stats
Results for 4.5.0 20090515 (experimental) [trunk revision 147594] (GCC)
testsuite on x86_64-unknown-linux-gnu

I don't have check-in privileges.


-- 


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

[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq

[jakub at gcc dot gnu dot org]

--- Comment #45 from jakub at gcc dot gnu dot org  2009-05-16 06:37 ---
cmpl $1, %eax does have the modrm byte:
83 f8 01 cmp$0x1,%eax
compared to cmpl $0xdeadbeef, $eax which doesn't have it:
3d ef be ad de   cmp$0xdeadbeef,%eax
So I think what I wrote is more precise.  modrm byte is there if the insn has
ax_reg_operand destination and immediate source which hasn't been shortened.


-- 


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

[Bug tree-optimization/40071] ICE (aliasing assert) in vectorizable_store at tree-vect-stmts.c:3117

[aoliva at gcc dot gnu dot org]

--- Comment #9 from aoliva at gcc dot gnu dot org  2009-05-16 06:52 ---
FWIW, there are lots of failures like this building gnat in stage2, during a
bootstrap with BUILD_CONFIG=bootstrap-O3


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org


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