[Bug target/39291] _Unwind_Backtrace fails.

[pluto at agmk dot net]

--- Comment #3 from pluto at agmk dot net  2009-02-25 08:24 ---
(In reply to comment #2)
> I get this with your testcase on mingw32, DW@ build:
> GNU C (GCC) version 4.4.0 20090221 (experimental) (mingw32)

i have a gcc/dw2 configured with:

Using built-in specs.
Target: i486-pc-mingw32
Configured with: ../configure --target=i486-pc-mingw32 --with-arch=i486
--prefix=/local/devel/toolchain44/i486-pc-mingw32.host64
--with-sysroot=/local/devel/toolchain44/i486-pc-mingw32.host64
--libdir=/local/devel/toolchain44/i486-pc-mingw32.host64/lib
--libexecdir=/local/devel/toolchain44/i486-pc-mingw32.host64/lib
--with-slibdir=/local/devel/toolchain44/i486-pc-mingw32.host64/lib
--with-gmp-include=/home/pawels/toolchain/trunk/gcc-math-runtime/include
--with-gmp-lib=/home/pawels/toolchain/trunk/gcc-math-runtime/lib
--with-mpfr-include=/home/pawels/toolchain/trunk/gcc-math-runtime/include
--with-mpfr-lib=/home/pawels/toolchain/trunk/gcc-math-runtime/lib
--disable-multilib --disable-nls --disable-libgomp --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --with-pic --enable-c99
--enable-long-long --disable-win32-registry --enable-threads=win32
--disable-sjlj-exceptions --enable-shared --enable-__cxa_atexit
--enable-languages=c,c++ --disable-symvers --with-pic --with-long-double-128
--disable-cld --disable-bootstrap
Thread model: win32
gcc version 4.4.0 20090220 (experimental) (GCC)

> gcc -fexceptions -g  u.c
> 
> foo:enter
> bar:enter
> zoo:enter
> boom!
> signalHandler:enter
> lookupSymbol: 00401407
> lookupSymbol: 00401232
> signalHandler:longjmp
> zoo:exit
> bar:exit
> foo:exit
> alive!

could you attach a precompiled .exe? i'll check it on my winxp64.


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25 08:52 ---
Sooo - what is the content of the .optimized dump?


-- 


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

[Bug target/37520] [4.4 Regression] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-02-25 08:57 
---
Let's make this P1 until we are sure it is not an ABI problem.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug middle-end/39298] New: Optimize away only set but not used variable

[burnus at gcc dot gnu dot org]

In the following Fortran program, the variable "foo" is never used, it is only
set.

Result: Using "gfortran -O3", "foo" is not optimized away.
Expected: "foo" is optimized away as it happens with "ifort -O2".

  program a
  implicit none
  integer*8 it,two
  parameter(it=1073741824,two=2)
  complex foo(it*two-1)

  foo(10)=1.
  write(*,*) ''
  end program a


-- 
   Summary: Optimize away only set but not used variable
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
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=39298

[Bug middle-end/39298] Optimize away only set but not used variable

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25 09:43 ---
Is there a reason the Fortran frontend gives function local variables static
storage duration?

a ()
{
  struct __st_parameter_dt dt_parm.1;
  static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
  static complex(kind=4) foo[2147483647];

:
  _gfortran_set_options (8, &options.0);
  foo[9] = __complex__ (1.0e+0, 0.0);


-- 

rguenth 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-02-25 09:43:40
   date||


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

[Bug middle-end/39298] Optimize away only set but not used variable

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-02-25 09:51 ---
It works with it == 1024 in which case foo is not static.


-- 


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

[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work

[andreasmeier80 at gmx dot de]

--- Comment #11 from andreasmeier80 at gmx dot de  2009-02-25 10:33 ---
The target milestone 4.0.4 is wrong 


-- 

andreasmeier80 at gmx dot de changed:

   What|Removed |Added

 CC||andreasmeier80 at gmx dot de


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

[Bug middle-end/39298] Optimize away only set but not used variable

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-02-25 10:35 ---
I did some testing with sunf95, icc and ifort.

sunf95 also puts the variable in .bss as gfortran does, while ifort puts it on
the stack (unless explicitly declared as static ["SAVE"]). If the variable is
static, neither of the compilers optimizes it away.

a) Why are static variables not optimized away? (Not even in main()/MAIN_?)
b) Is there something what one could do to get the advantage of not having huge
variables on the stack but still allowing to optimize the variable away?


-- 


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

[Bug middle-end/39298] Optimize away only set but not used variable

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-02-25 10:21 ---
> Is there a reason the Fortran frontend gives function local variables static
> storage duration?

For huge arrays, there is a problem if the memory is allocated on the stack, as
one quickly hits stack-size limits. Thus gfortran puts large local arrays in
static memory, except when a procedure can be called recursively/simultaneously
(RECURSIVE attribute, -frecursive, -fopenmp). The size for which this happens
is controlled by -fmax-stack-var-size=.

Actually, I don't quite see why the "static" matters: As local variable it
cannot be accessed from elsewhere and if it is not accessed in the procedure
...

Additionally, C's main() and Fortran's PRORGRAM (= "MAIN__") are special
because they are only called once.


-- 


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

[Bug tree-optimization/39299] New: wrong PTA for structure copies

[rguenth at gcc dot gnu dot org]

At -O2 -fno-tree-sra we compute y.p as pointing to nothing.  Which causes
the abort to trigger on alias-improvements branch.

struct X
{
  long l1;
  struct Y
  {
long l2;
int *p;
  } y;
};
int i;
int foo (struct X *x)
{
  struct Y y = x->y;
  *y.p = 0;
  i = 1;
  return *y.p;
}
extern void abort (void);
int main()
{
  struct X x;
  x.y.p = &i;
  if (foo(&x) != 1)
abort ();
  return 0;
}


-- 
   Summary: wrong PTA for structure copies
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code, alias
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=39299

[Bug middle-end/39298] Optimize away only set but not used variable

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-02-25 11:21 ---
Optimizing dead local static variables requires special handling which probably
is not thought to be worth the trouble.  If the variable is unused the
programmer can as well remove it.


-- 


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

[Bug tree-optimization/39300] New: vectorizer confused by predictive commoning

[matz at gcc dot gnu dot org]

The loop in this test is not vectorized if either PRE or predictive
commoning is active:
% cat vecttest2.f
  subroutine Bench_StaggeredLeapfrog2( cctk_dim,XADM_curv_stag0,
 &ADM_kzz_stag,lgxx,nx)
  implicit none
  INTEGER cctk_dim
  INTEGER XADM_curv_stag0
  REAL*8 ADM_kzz_stag(XADM_curv_stag0)

  integer :: i
  integer :: nx
  REAL*8,DIMENSION(cctk_dim):: lgxx
  do i=2,nx-1
ADM_kzz_stag(i) = ADM_kzz_stag(i)+lgxx(i)+lgxx(i-1)+lgxx(i+1)
  end do
  end subroutine Bench_StaggeredLeapfrog2
% gfortran -c -O3 -g -ffast-math -ftree-vectorizer-verbose=2 vecttest2.f
vecttest2.f:11: note: not vectorized: unsupported use in stmt.
vecttest2.f:12: note: not vectorized: unsupported use in stmt.
% add -fno-tree-pre -fno-predictive-commoning to above command:
vecttest2.f:11: note: LOOP VECTORIZED.
% add only -fno-tree-pre (so predictive commoning is active):
vecttest2.f:11: note: LOOP VECTORIZED.
vecttest2.f:12: note: not vectorized: unsupported use in stmt.

The one vectorized loop in case it mentions two of them is the tail loop
for the one produced by predictive commoning.  That one doesn't contain
any loop carried values.  Somehow the vectorizer doesn't like the 
PHI nodes in the loop created by predictive commoning.

This testcase comes from 436.cactusADM, where it's very important to
vectorize a certain inner loop, and this (PRE and predcom) is one reason this
doesn't happen already.


-- 
   Summary: vectorizer confused by predictive commoning
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
  GCC host triplet: x86_64-linux


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[bonzini at gnu dot org]

--- Comment #16 from bonzini at gnu dot org  2009-02-25 12:18 ---
The upcoming C++0x memory model forbids this; see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html (Concurrency
memory model compiler consequences).  But it says that this is acceptable
instead:

  tmp = var;
  modified = false;
  for (i = 0; i < 100; i++)
{
  if (i > x)
tmp = i, modified = true;
}
  if (modified)
var = tmp;

I think the bug can be confirmed, can't it?


-- 


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

[Bug fortran/39292] [4.3/4.4 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:3884

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2009-02-25 13:05 ---
Steve,

> 
> At this stage in the 4.4 release process, I think my patch is too risky.
> I've only done some limited testing.  This should probably be considered
> a 4.5 patch.
> 

Should I apply mine, with a check that the expression is constant?

Paul


-- 


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

[Bug tree-optimization/39299] wrong PTA for structure copies

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25 13:08 ---
I have a patch.


-- 

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-02-25 13:08:43
   date||


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2009-02-25 13:25 
---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-02-25 13:25:54
   date||


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

Re: [Bug middle-end/39298] Optimize away only set but not used variable

[Andrew Thomas Pinski]

Sent from my iPhone

On Feb 25, 2009, at 1:43 AM, "rguenth at gcc dot gnu dot org" > wrote:





--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25  
09:43 ---
Is there a reason the Fortran frontend gives function local  
variables static

storage duration?



Yes, it is larger than the threshhold. Remember fortran has no  
recursive functions except for the ones which marked as such.



a ()
{
 struct __st_parameter_dt dt_parm.1;
 static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
 static complex(kind=4) foo[2147483647];

:
 _gfortran_set_options (8, &options.0);
 foo[9] = __complex__ (1.0e+0, 0.0);


--

rguenth 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-02-25 09:43:40
  date||


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

[Bug middle-end/39298] Optimize away only set but not used variable

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2009-02-25 13:37 ---
Subject: Re:  Optimize away only set but not used variable



Sent from my iPhone

On Feb 25, 2009, at 1:43 AM, "rguenth at gcc dot gnu dot org"
 wrote:

>
>
> --- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25  
> 09:43 ---
> Is there a reason the Fortran frontend gives function local  
> variables static
> storage duration?
>

Yes, it is larger than the threshhold. Remember fortran has no  
recursive functions except for the ones which marked as such.

> a ()
> {
>  struct __st_parameter_dt dt_parm.1;
>  static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
>  static complex(kind=4) foo[2147483647];
>
> :
>  _gfortran_set_options (8, &options.0);
>  foo[9] = __complex__ (1.0e+0, 0.0);
>
>
> -- 
>
> rguenth 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-02-25 09:43:40
>   date||
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
>


-- 


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

[Bug tree-optimization/39300] vectorizer confused by predictive commoning

[matz at gcc dot gnu dot org]

--- Comment #1 from matz at gcc dot gnu dot org  2009-02-25 13:53 ---
For reference intel fortran (11.0) produces three loops, one where it uses
predictive commoning (that is used when there are only few iterations):

..B1.7: # Preds ..B1.6
movsd 8(%r8), %xmm1 #13.52
movsd (%r8), %xmm0  #13.52
# LOE rax rdx rcx rbx rbp rsi rdi r8 r9 r12 r13
r14 r15 xmm0 xmm1
..B1.8: # Preds ..B1.8 ..B1.7
movaps%xmm1, %xmm2  #13.33
movsd 16(%r8,%rdi,8), %xmm3 #13.52
addsd %xmm3, %xmm2  #13.33
addsd %xmm0, %xmm2  #13.41
movaps%xmm1, %xmm0  #14.7
movaps%xmm3, %xmm1  #14.7
addsd 8(%rdx,%rdi,8), %xmm2 #13.9
movsd %xmm2, 8(%rcx,%rdi,8) #13.9
incq  %rdi  #14.7
cmpq  %rax, %rdi#14.7
jl..B1.8# Prob 82%  #14.7

And two others which are vectorized (plus four/eight times unrolled), but
do _not_ use something like predictive commoning (i.e. no cross iteration
values).  Both loops are just versions of each other, one for aligned
destinations and the other for unaligned.  The aligned variant is this:

..B1.15:# Preds ..B1.10 ..B1.15
movsd 8(%rdx,%rax,8), %xmm1 #13.18
movhpd16(%rdx,%rax,8), %xmm1#13.18
movsd 8(%r8,%rax,8), %xmm0  #13.34
movhpd16(%r8,%rax,8), %xmm0 #13.34
movsd 24(%rdx,%rax,8), %xmm4#13.18
movhpd32(%rdx,%rax,8), %xmm4#13.18
movsd 24(%r8,%rax,8), %xmm2 #13.34
movhpd32(%r8,%rax,8), %xmm2 #13.34
movsd 40(%rdx,%rax,8), %xmm7#13.18
movhpd48(%rdx,%rax,8), %xmm7#13.18
movsd 40(%r8,%rax,8), %xmm5 #13.34
movhpd48(%r8,%rax,8), %xmm5 #13.34
movsd 56(%rdx,%rax,8), %xmm10   #13.18
movhpd64(%rdx,%rax,8), %xmm10   #13.18
movsd 56(%r8,%rax,8), %xmm8 #13.34
movhpd64(%r8,%rax,8), %xmm8 #13.34
addpd %xmm0, %xmm1  #13.33
addpd (%r8,%rax,8), %xmm1   #13.41
addpd %xmm2, %xmm4  #13.33
addpd %xmm5, %xmm7  #13.33
addpd %xmm8, %xmm10 #13.33
movaps16(%r8,%rax,8), %xmm3 #13.52
addpd %xmm3, %xmm1  #13.9
movaps32(%r8,%rax,8), %xmm6 #13.52
movaps48(%r8,%rax,8), %xmm9 #13.52
movaps%xmm1, 8(%rcx,%rax,8) #13.9
addpd %xmm3, %xmm4  #13.41
addpd %xmm6, %xmm4  #13.9
movaps%xmm4, 24(%rcx,%rax,8)#13.9
addpd %xmm6, %xmm7  #13.41
addpd %xmm9, %xmm7  #13.9
movaps%xmm7, 40(%rcx,%rax,8)#13.9
addpd %xmm9, %xmm10 #13.41
addpd 64(%r8,%rax,8), %xmm10#13.9
movaps%xmm10, 56(%rcx,%rax,8)   #13.9
addq  $8, %rax  #14.7
cmpq  %r9, %rax #14.7
jl..B1.15   # Prob 82%  #14.7

Not most optimal, due to not using the cross-iteration values to save 
two loads per iteration.  But still much better than what GCC uses.


-- 


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

[Bug tree-optimization/39300] vectorizer confused by predictive commoning

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-02-25 13:56 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2009-02-25 13:56:08
   date||


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

[Bug c/39301] New: ICE in register_overhead, at bitmap.c:115

[lucier at math dot purdue dot edu]

With this compiler:

[luc...@descartes gambc-v4_4_1-devel]$ /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline
--enable-languages=c --enable-gather-detailed-mem-stats --with-cpu=default64
Thread model: posix
gcc version 4.4.0 20090224 (experimental) [trunk revision 144414] (GCC) 

with compiler.i found at

http://www.math.purdue.edu/~lucier/bugzilla/8

and this command line:

[luc...@descartes gambc-v4_4_1-devel]$ gdb
/pkgs/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.4.0/cc1
(gdb) run  -I../include -Wall -W -Wno-unused -O1 -fno-math-errno
-fschedule-insns2 -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math
-fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common  compiler.i

one gets an ICE 

Starting program:
/pkgs/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.4.0/cc1
-I../include -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -O1
-fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common  compiler.i
 btowc wctob mbrlen {GC 5504k -> 3345k} {GC 5325k -> 4387k} code_size
___H__20_compiler_2e_o1 {GC 202396k -> 113348k} ___init_proc
20_compiler_2e_o1
Analyzing compilation unit
 {GC 182571k -> 135708k}Performing interprocedural optimizations
   {GC 237987k -> 236439k} 
  Assembling functions:
 code_size ___init_proc 20_compiler_2e_o1 ___H__20_compiler_2e_o1 {GC
349654k -> 288661k} {GC 406235k -> 272087k}
compiler.c: In function ‘___H__20_compiler_2e_o1’:
compiler.c:322876: internal compiler error: in register_overhead, at
bitmap.c:115

I'm sorry the test case is enormous, but it runs in about a GB of RAM. I also
haven't been able to figure out how to use gdb properly in this mixed
ppc32/ppc64 environment.


-- 
   Summary: ICE in register_overhead, at bitmap.c:115
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug other/39302] New: [meta-bug] bugs waiting for Copyright Assignment acknowledgemt for ARC International (UK) Ltd

[amylaar at gcc dot gnu dot org]

Before patches from ARC International (UK) Ltd can be reviewed, it
must be verified that a valid copyright assignment is on file at the FSF.
This blocks a number of bugs where patches are available, but cannot be
reviewed.


-- 
   Summary: [meta-bug] bugs waiting for Copyright Assignment
acknowledgemt for ARC International (UK) Ltd
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: meta-bug
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org


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

[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-02-25 14:07 ---
Simpler C testcase:

float res[1024], data[1024];

void foo(void)
{
  int i;
  float tmp = data[0];
  for (i = 1; i < 1024; ++i)
{
  float tmp2 = data[i];
  res[i] = tmp + tmp2;
  tmp = tmp2;
}
}


-- 


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

[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE

[irar at il dot ibm dot com]

--- Comment #4 from irar at il dot ibm dot com  2009-02-25 14:08 ---
Looks similar to PR 35229.

We get here:
# pre.1 = PHI 
..
load D.2 
D.3 = D.2 + pre.1 + ...
store D.3


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 CC||irar at il dot ibm dot com


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25 14:10 ---
/* Store information about each particular bitmap.  */
struct bitmap_descriptor
{
  const char *function;
  const char *file;
  int line;
  int allocated;
  int created;
  int peak;
  int current;
  int nsearches;
};

I guess we simply overflow current.  Using HOST_WIDEST_INT for the counters
would be appropriate.


-- 


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

[Bug tree-optimization/35229] Vectorizer doesn't support dependence created by predictive commoning

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25 14:12 ---
Indeed.  Proper testcase:

float res[1024], data[1024];

void foo(void)
{
  int i;
  float tmp = data[0];
  for (i = 1; i < 1024; ++i)
{
  float tmp2 = data[i];
  res[i] = tmp + tmp2;
  tmp = tmp2;
}
}

manually "optimized" from

  res[i] = data[i] + data[i-1];


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
OtherBugsDependingO||39300
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-25 14:12:51
   date||


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

[Bug tree-optimization/35229] Vectorizer doesn't support dependence created by predictive commoning

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-02-25 14:33 ---
Or like the following, which is just a bunch of reductions of two elements

float data[1024];

void foo(void)
{
  int i;
  for (i = 1; i < 1024; ++i)
data[i] = data[i] + data[i-1];
}


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-02-25 14:37 ---
(In reply to comment #1)
> Sooo - what is the content of the .optimized dump?
> 

;; Function foo (foo)

Analyzing Edge Insertions.
foo (int len, int v)
{
  long unsigned int D.1255;
  long unsigned int ivtmp.14;

:
  if (len > 0)
goto ;
  else
goto ;

:
  ivtmp.14 = (long unsigned int) &a[0];
  D.1255 = ((long unsigned int) &a + 2) + (long unsigned int) ((unsigned int)
le
n + 4294967295) * 2;

:
  MEM[index: ivtmp.14] = (short int) (short int) v;
  ivtmp.14 = ivtmp.14 + 2;
  if (ivtmp.14 != D.1255)
goto ;
  else
goto ;

:
  return a[0];

}


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-02-25 14:41 ---
Note index: again, bo. I thought I got rid of all those.


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[rguenther at suse dot de]

--- Comment #4 from rguenther at suse dot de  2009-02-25 14:48 ---
Subject: Re:  [4.4 Regression]
 gcc.dg/tree-ssa/loop-31.c

On Wed, 25 Feb 2009, hjl dot tools at gmail dot com wrote:

> --- Comment #2 from hjl dot tools at gmail dot com  2009-02-25 14:37 
> ---
> (In reply to comment #1)
> > Sooo - what is the content of the .optimized dump?
> > 
> 
> ;; Function foo (foo)
> 
> Analyzing Edge Insertions.
> foo (int len, int v)
> {
>   long unsigned int D.1255;
>   long unsigned int ivtmp.14;
> 
> :
>   if (len > 0)
> goto ;
>   else
> goto ;
> 
> :
>   ivtmp.14 = (long unsigned int) &a[0];
>   D.1255 = ((long unsigned int) &a + 2) + (long unsigned int) ((unsigned int)
> le
> n + 4294967295) * 2;

This likely used to be folded to &a[len], but the addressing-mode
is still what it is supposed to be.  Can you attach the dump with
the patch reverted as well?

> :
>   MEM[index: ivtmp.14] = (short int) (short int) v;
>   ivtmp.14 = ivtmp.14 + 2;
>   if (ivtmp.14 != D.1255)
> goto ;
>   else
> goto ;
> 
> :
>   return a[0];
> 
> }
> 
> 
> 


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-25 14:53 ---
Revision 144404 gave:

;; Function foo (foo)

Analyzing Edge Insertions.
foo (int len, int v)
{
  short int * D.1254;
  short int * ivtmp.14;

:
  if (len > 0)
goto ;
  else
goto ;

:
  D.1254 = &a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 1)
* 2;
  ivtmp.14 = &a[0];

:
  MEM[base: ivtmp.14] = (short int) (short int) v;
  ivtmp.14 = ivtmp.14 + 2;
  if (ivtmp.14 != D.1254)
goto ;
  else
goto ;

:
  return a[0];

}


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2009-02-25 15:01 ---
Subject: Re:  [4.4 Regression]
 gcc.dg/tree-ssa/loop-31.c

On Wed, 25 Feb 2009, hjl dot tools at gmail dot com wrote:

> --- Comment #5 from hjl dot tools at gmail dot com  2009-02-25 14:53 
> ---
> Revision 144404 gave:

Is the assembly different?


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-02-25 15:09 ---
Revision 144405 gave:

.text
.align 16
.global foo#
.type   foo#, @function
.proc foo#
foo:
.prologue
.body
cmp4.ge p6, p7 = 0, r32
(p6) br.cond.spnt .L2
addl r14 = @ltoffx(a#), r1
;;
ld8.mov r14 = [r14], a#
adds r16 = -1, r32
;;
addp4 r16 = r16, r0
addl r15 = @gprel(.LC0), gp
;;
ld8 r15 = [r15]
;;
shladd r15 = r16, 1, r15
.L3:
st2 [r14] = r33, 2
;;
cmp.ne p6, p7 = r15, r14
(p6) br.cond.sptk .L3
.L2:
addl r14 = @ltoffx(a#), r1
;;
ld8.mov r14 = [r14], a#
;;
ld2 r8 = [r14]
br.ret.sptk.many b0
;;
.endp foo#

Revision 144404 gave:

.proc foo#
foo:
.prologue
.save ar.lc, r2
mov r2 = ar.lc
.body
cmp4.ge p6, p7 = 0, r32
(p6) br.cond.spnt .L2
adds r15 = -1, r32
;;
addp4 r15 = r15, r0
;;
adds r15 = 1, r15
addl r14 = @ltoffx(a#), r1
;;
ld8.mov r14 = [r14], a#
;;
shladd r15 = r15, 1, r14
;;
sub r15 = r15, r14
;;
adds r15 = -2, r15
;;
shr.u r15 = r15, 1
;;
mov ar.lc = r15
.L3:
st2 [r14] = r33, 2
;;
br.cloop.sptk.few .L3
.L2:
addl r14 = @ltoffx(a#), r1
;;
ld8.mov r14 = [r14], a#
;;
ld2 r8 = [r14]
mov ar.lc = r2
br.ret.sptk.many b0
;;
.endp foo#


-- 


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

[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-02-25 15:52 ---
An updated patch is at

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01171.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2009-   |patches/2009-
   |02/msg00961.html|02/msg01171.html


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

[Bug target/39303] New: ARC port does not support ARCompact architecture

[amylaar at gcc dot gnu dot org]

The ARC port that is currently in the FSF GCC does not support the ARCompact
architecture, which is used by the current and ARC chips ARC600 and ARC700,
and by the already superceded ARCtangent-A5.


-- 
   Summary: ARC port does not support ARCompact architecture
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org


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

[Bug fortran/39304] New: ICE on module compilation

[Huub dot van-Dam at stfc dot ac dot uk]

I am trying to compile a module for automatic differentiation. The file is
called auto_deriv.f90 and is distributed by the journal Computer Physics
Communications at http://www.cpc.cs.qub.ac.uk/summaries/ADLS_v1_0.html .
However, when trying to compile this with gfortran -c auto_deriv.f90 I get:

 In file auto_deriv.f90:2757

END MODULE deriv_class
 1
 Internal Error at (1):
 spec_dimen_size(): Bad dimension

I have absolutely no idea why this happens. Just in case it is helpful there is
an HTML version of the associated paper available online at
http://tccc.iesl.forth.gr/~farantos/po_cpc/auto_deriv.html


-- 
   Summary: ICE on module compilation
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Huub dot van-Dam at stfc dot ac dot uk
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/39304] ICE on module compilation

[Huub dot van-Dam at stfc dot ac dot uk]

--- Comment #1 from Huub dot van-Dam at stfc dot ac dot uk  2009-02-25 
16:02 ---
Created an attachment (id=17358)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17358&action=view)
The file that fails to compile


-- 


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

[Bug fortran/39304] ICE on module compilation

[Huub dot van-Dam at stfc dot ac dot uk]

--- Comment #2 from Huub dot van-Dam at stfc dot ac dot uk  2009-02-25 
16:03 ---
Created an attachment (id=17359)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17359&action=view)
A tiny sample program that uses auto_deriv.f90


-- 


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[davids at webmaster dot com]

--- Comment #18 from davids at webmaster dot com  2009-02-25 16:06 ---
This is a real bug. There is simply no way to write correct threaded code if
the compiler is free to read a variable and write it back when the code didn't
specifically tell it to.

Optimizations on threaded code cannot add a write to a variable unless they can
prove no other thread could know the location of the variable. (It's local,
it's address has never been passed to a function, and so on.)

In any event, the last time I looked into this, it seemed that such
'optimizations' were typically pessimizations on multi-threaded code anyway, as
they added expensive cache misses.


-- 


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[dnovillo at google dot com]

--- Comment #19 from dnovillo at google dot com  2009-02-25 16:12 ---
Subject: Re:  Loop IM and other optimizations harmful 
for -fopenmp

On Wed, Feb 25, 2009 at 11:06, davids at webmaster dot com
 wrote:
>
>
> --- Comment #18 from davids at webmaster dot com  2009-02-25 16:06 
> ---
> This is a real bug. There is simply no way to write correct threaded code if
> the compiler is free to read a variable and write it back when the code didn't
> specifically tell it to.

Yes.  Unless we build an actual concurrent data flow and adapt the
optimizers for these programs, we will never get it right.  The best
approach in these cases is to tell the optimizers to back off
completely.  After all the code has completely different semantics
from what they are ready to handle.


Diego.


-- 


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

[Bug fortran/39304] ICE on module compilation

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-02-25 16:23 ---
Confirmed on powerpc-apple-darwin9 (trunk rev. 144372, 4.2.3 and 4.3.3).

g95 gives the following warning (lines 477, 488, 499, 510, 521, 532, and 543)

Warning (158): INTENT(OUT) variable 'res' at (1) is never set


-- 


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

[Bug ada/39172] libada parsing of multilib options

[schwab at suse dot de]

--- Comment #2 from schwab at suse dot de  2009-02-25 16:43 ---
The problem seems to be that the AWK makefile variable is not properly passed
down to submakes.


-- 


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

[Bug tree-optimization/39305] New: tree-ssa-loop-ch.c:copy_loop_headers performs loop unrolling

[amylaar at gcc dot gnu dot org]

For some simple loops with early exits, like libgcc2.c:__gcc_bcmp,
copy_loop_headers copies not only the header, but also the loop body,
and thus disables doloop optimizations.


-- 
   Summary: tree-ssa-loop-ch.c:copy_loop_headers performs loop
unrolling
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
 BugsThisDependsOn: 39302


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

[Bug ada/39172] libada parsing of multilib options

[schwab at suse dot de]

--- Comment #3 from schwab at suse dot de  2009-02-25 16:57 ---
Created an attachment (id=17360)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17360&action=view)
Candidate patch


-- 


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

[Bug ada/39172] libada parsing of multilib options

[schwab at suse dot de]

--- Comment #4 from schwab at suse dot de  2009-02-25 16:58 ---
Can you please try out the attached patch?


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|m68k-rtems4.10  |m68k-*.*


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

[Bug middle-end/39274] internal compiler error: in check_cfg, at haifa-sched.c, var-tracking

[sergei_lus at yahoo dot com]

--- Comment #2 from sergei_lus at yahoo dot com  2009-02-25 17:00 ---

Thank you for the suggestion, but... 

I use schedule_ebbs in machine dependent reorg, and I do call
compute_bb_for_insn before it. CFG is messed up before I get there... 


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-02-25 17:00 ---
gcc.dg/tree-ssa/loop-31.c comes from PR 32283. This testcase only
runs on arms and ia64.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

OtherBugsDependingO||32283
  nThis||


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

[Bug ada/39172] libada parsing of multilib options

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-02-25 17:03 ---
Subject: Re:  libada parsing of multilib options

schwab at suse dot de wrote:
> --- Comment #3 from schwab at suse dot de  2009-02-25 16:57 ---
> Created an attachment (id=17360)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17360&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17360&action=view)
> Candidate patch

That's fine, or you can probably add a...@awk@ in
gcc/ada/gcc-interface/Makefile.in.  That was the patch I was meaning to
test.

If you don't want to test this other thing, your patch is okay if it is
tested.


-- 


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

[Bug ada/39172] libada parsing of multilib options

[joel at gcc dot gnu dot org]

--- Comment #6 from joel at gcc dot gnu dot org  2009-02-25 17:04 ---
Can you include the generated files please?  I do not have autoconf 2.59
installed.   I can test the Ada build quickly though.

Thanks.


-- 


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

[Bug c/39306] New: -fstack-check + large frame == SIGSEGV

[ppluzhnikov at google dot com]

Discovered as a failure of GDB test:
FAIL: gdb.base/stack-checking.exp: continue to breakpoint: breakpoint for big
frame

With current SVN head @144426:

/* t.c */
void foo() { char buf[524188]; }
int main() { foo(); return 0; }

i686-unknown-linux-gnu-gcc t.c -fstack-check && ./a.out
Segmentation fault

AFAICT, this is a regression from 4.3.1
Problem also happens in x86_64-unknown-linux-gnu.
Minimal size to crash appears to be about 57058.


-- 
   Summary: -fstack-check + large frame == SIGSEGV
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at google dot com
 GCC build triplet: i686-unknown-linux-gnu
  GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[davids at webmaster dot com]

--- Comment #20 from davids at webmaster dot com  2009-02-25 17:53 ---
I don't like this either:

  tmp = var;
  modified = false;
  for (i = 0; i < 100; i++)
{
  if (i > x)
tmp = i, modified = true;
}
  if (modified)
var = tmp;

This can be a pessimization as well. If 'modified' is almost always false, the
'tmp = var;' can force a cache unshare for no reason. If this code is not
performance critical, the optimization is pointless. If it is, the
pessimization can be significant.

IMO, these kinds of optimizations are not worth doing. Almost any optimization
that can introduce an additional memory access risks a net performance loss in
some use cases. The compiler cannot determine the use case by static code
inspection.

Now, in this case, the 'tmp = var;' is obviously superfluous, you can just
eliminate it, so this isn't a good example of what I'm talking about. But in
general, an optimization should not *add* a memory operation the code did not
request unless you can show that it will always remove at least one operation
of comparable cost. Otherwise it can be a net performance loss all the time in
some use cases.


-- 


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

[Bug middle-end/39306] -fstack-check + large frame == SIGSEGV

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-25 17:56 ---
fstack-check  is known to be broken on x86 GNU/Linux, see PR 13757.

So I don't think this is a regression even.


-- 


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[matz at gcc dot gnu dot org]

--- Comment #21 from matz at gcc dot gnu dot org  2009-02-25 18:04 ---
The question if such transformation is or isn't worthwhile is independent from
the issue at hand (which is about the validity in the light of the new
memory model).  If you find a clearly pessimizing but valid transformation
create a bug report.


-- 


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[pinskia at gcc dot gnu dot org]

--- Comment #22 from pinskia at gcc dot gnu dot org  2009-02-25 18:07 
---
Really to me this is still a valid transformation even in the inside threads. 
If you want to be able to access via different threads, use locks, heavy or
light weight ones.


-- 


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

[Bug fortran/39304] ICE on module compilation

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-02-25 18:08 ---
Created an attachment (id=17361)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17361&action=view)
Reduced testcase


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #17358|0   |1
is obsolete||
  Attachment #17359|0   |1
is obsolete||


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

[Bug fortran/39304] ICE on module compilation

[kargl at gcc dot gnu dot org]

-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.2.5 4.3.3 4.4.0
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-02-25 18:10:46
   date||


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

[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749

[jamborm at gcc dot gnu dot org]

--- Comment #8 from jamborm at gcc dot gnu dot org  2009-02-25 18:19 ---
Fixed with:

Author: jamborm
Date: Wed Feb 25 17:34:40 2009
New Revision: 144428

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144428
Log:
2009-02-25  Martin Jambor  

* tree-inline.c (initialize_cfun): Remove asserts for calls_setjmp and
alls_alloca function flags.
(copy_bb): Set calls_setjmp and alls_alloca function flags if such
calls are detected.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr39259.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2009-02-25 18:24 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01185.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||02/msg01185.html


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-02-25 18:30 ---
Confirm. Also works with NAG f95. It fails with 4.1 to 4.4 and thus it does not
seem to be a regression.

It fails in spec_dimen_size for "dimen=1, as->rank=1". Some more debugging
information from gfc_array_dimen_size:

- array->symtree->n.sym->name == "fd"  (this is the function "FD")
- array->symtree->n.sym->as == { rank = 1, type = AS_DEFERRED, ... }
- array->rank == 2

Thus the interesting thing is that the EXPR_FUNCTION is RANK 2 while the symbol
is only RANK 1.

A backtrace shows that it occurs for a MATMUL. The problem seems to be
constructs like:
  ptr = MATMUL(FD(a, i), value(b))

where not
  FUNCTION FD(x) 
should be called but
  FUNCTION FD_array_one(x, i)
as there is
  INTERFACE FD
 MODULE PROCEDURE FD, FD_one, FD_array_one, FD_matrix_one
  END INTERFACE

#0  gfc_array_dimen_size (array=0x1329450, dimen=1, result=0x7fffd370) at
array.c:2036
#1  0x00412da8 in identical_dimen_shape (a=0x1329450, ai=1,
b=0x1329690, bi=2) at check.c:386
#2  0x004149f2 in gfc_check_matmul (matrix_a=0x1329450,
matrix_b=0x1329690) at check.c:1869
#3  0x0043371c in check_specific (specific=0x11857a0, expr=0x1329000,
error_flag=0) at intrinsic.c:3461
#4  0x00433a43 in gfc_intrinsic_func_interface (expr=0x1329000,
error_flag=0) at intrinsic.c:3667
#5  0x0046fb9d in resolve_function (expr=0x1329000) at resolve.c:1689
#6  0x0046bd2a in gfc_resolve_expr (e=0x1329000) at resolve.c:4754


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|
   Keywords||ice-on-valid-code
   Priority|P4  |P3
Summary|ICE on module compilation   |ICE with MATMUL,
   ||specific/generic functions
   ||and rank checking


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[rakdver at gcc dot gnu dot org]

-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-25 18:34:04
   date||


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[davids at webmaster dot com]

--- Comment #23 from davids at webmaster dot com  2009-02-25 18:35 ---
"Really to me this is still a valid transformation even in the inside threads. 
If you want to be able to access via different threads, use locks, heavy or
light weight ones."

Absolutely, you do use locks everywhere you write to a variable that might be
read from by another thread. The problem is that the compiler introduces locks
where you *don't* write to a variable.

It is simply impossible to use locks if the compiler can add a write where you
didn't expect one.

The classic example:

if(can_write) acquire_lock();
for(int i=0; i<100; i++)
{
 some_stuff(i);
 if(can_write) shared_variable+=i;
}
if(can_write) release_lock();

Here this code does acquire a lock if it plans to modify the shared variable.
But the optimizations discussed will break this code.

Also, you can have the same problem with this kind of code without threads.
Imagine, for example, if the 'shared_variable' may be in read-only memory and
'can_write' indicates this case.


-- 


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[bonzini at gnu dot org]

--- Comment #24 from bonzini at gnu dot org  2009-02-25 18:43 ---
Andrew, your comments #6 #8 #9 clearly show that you haven't understood the
issue and are just talking past others.

The other hand the transformation has been shown to be an optimization on
single-thread cases; if it is bad for multiprocessors, it means it probably
should be guarded by a flag (but what if the load is not necessary?  should it
use the same flag, a separate flag, or be always enabled?).  But the IM code
should be modified to use the flag as suggested by the C++ standard (and to
avoid the load if it is not necessary, as it is in this case but not in the
case explained by N2238).


-- 


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

[Bug c/39307] New: avr-gcc ICE in start_function, at c-decl.c:6248

[regehr at cs dot utah dot edu]

Seen in avr-gcc 4.3.3 built using the script that comes with FemtoOS 0.88.

[reg...@babel tmp40]$ avr-gcc -mmcu=atmega128 small.c
small.c:3: internal compiler error: in start_function, at c-decl.c:6248
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[reg...@babel tmp40]$ cat small.c

__attribute ((signal))
void __vector_15 (void)
{
}

[reg...@babel tmp40]$ avr-gcc -v

Using built-in specs.
Target: avr
Configured with: ../gcc-4.3.3/configure --prefix=/home/regehr/z/avr-gcc-test
--target=avr --with-gnu-ld --with-gnu-as --enable-languages=c,c++ --disable-nls
--disable-libssp --with-dwarf2
Thread model: single
gcc version 4.3.3 (GCC)


-- 
   Summary: avr-gcc ICE in start_function, at c-decl.c:6248
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr


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

[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2009-02-25 18:49 ---
Subject: Bug 39241

Author: hjl
Date: Wed Feb 25 18:49:28 2009
New Revision: 144430

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144430
Log:
gcc/

2008-02-25  H.J. Lu  

PR rtl-optimization/39241
* jump.c (rtx_renumbered_equal_p): Remove 2 superfluous calls
to subreg_offset_representable_p.

gcc/testsuite/

2008-02-25  H.J. Lu  

PR rtl-optimization/39241
* gcc.dg/torture/pr39241.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr39241.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/jump.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/39307] avr-gcc ICE in start_function, at c-decl.c:6248

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-25 18:50 ---


*** This bug has been marked as a duplicate of 34299 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/34299] [avr] ICE on function attribute syntax for main()

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-02-25 18:50 ---
*** Bug 39307 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||regehr at cs dot utah dot
   ||edu


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

[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2009-02-25 18:55 ---
Subject: Bug 39241

Author: hjl
Date: Wed Feb 25 18:55:14 2009
New Revision: 144431

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144431
Log:
2009-02-25  H.J. Lu  

Backport from mainline:
2008-02-25  H.J. Lu  

PR rtl-optimization/39241
* gcc.dg/torture/pr39241.c: New.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr39241.c
  - copied unchanged from r144430,
trunk/gcc/testsuite/gcc.dg/torture/pr39241.c
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2009-02-25 18:55 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[rakdver at gcc dot gnu dot org]

--- Comment #10 from rakdver at gcc dot gnu dot org  2009-02-25 19:09 
---
The difference between

>   D.1254 = &a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 1)
> * 2;

(original) and

>   D.1255 = ((long unsigned int) &a + 2) + (long unsigned int) ((unsigned int)
>len + 4294967295) * 2;

(current) is mostly cosmetical; the test in the testcase should be made more
robust, but other than that, there is no regression here.


-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |
   |patches/2009-   |
   |02/msg01185.html|


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-02-25 19:18 
---
(In reply to comment #10)
> The difference between
> 
> >   D.1254 = &a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 
> > 1)
> > * 2;
> 
> (original) and
> 
> >   D.1255 = ((long unsigned int) &a + 2) + (long unsigned int) ((unsigned 
> > int)
> >len + 4294967295) * 2;
> 
> (current) is mostly cosmetical; the test in the testcase should be made more
> robust, but other than that, there is no regression here.
> 

The new loop is

.L3:
st2 [r14] = r33, 2
;;
cmp.ne p6, p7 = r15, r14
(p6) br.cond.sptk .L3

The old loop is

   mov ar.lc = r15
.L3:
st2 [r14] = r33, 2
;;
br.cloop.sptk.few .L3

They are quite different.


-- 


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

[Bug target/34299] [avr] ICE on function attribute syntax for main()

[regehr at cs dot utah dot edu]

--- Comment #8 from regehr at cs dot utah dot edu  2009-02-25 20:01 ---
Sorry for the dup.

This bug prevents compilation of almost all TinyOS apps using 4.3.3!  Is there
a workaround?


-- 


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

[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work

[reichelt at gcc dot gnu dot org]

--- Comment #12 from reichelt at gcc dot gnu dot org  2009-02-25 21:00 
---
The culprit is in the function pushdecl_maybe_friend:
Functions declared extern "C" bypass the usual mechanism, because
duplicate_decls isn't called for them (see lines 727ff):

  else if ((DECL_EXTERN_C_FUNCTION_P (x)
|| DECL_FUNCTION_TEMPLATE_P (x))
   && is_overloaded_fn (t))
/* Don't do anything just yet.  */;
  else if (t == wchar_decl_node)
[...snip...]
  else
{
  tree olddecl = duplicate_decls (x, t, is_friend);

Later only the binding for such functions is compared, which doesn't
take default parameters into account (see line 778ff):

  if ((TREE_CODE (x) == FUNCTION_DECL)
  && DECL_EXTERN_C_P (x)
  /* We should ignore declarations happening in system headers.  */
  && !DECL_IN_SYSTEM_HEADER (x))
{
  cxx_binding *function_binding =
  lookup_extern_c_fun_binding_in_all_ns (x);
  if (function_binding
  && !DECL_IN_SYSTEM_HEADER (function_binding->value))
{
  tree previous = function_binding->value;

  /* In case either x or previous is declared to throw an
exception,
 make sure both exception specifications are equal.  */
  if (decls_match (x, previous))
   [...snip...]

}
}

  if (TREE_CODE (x) == FUNCTION_DECL || DECL_FUNCTION_TEMPLATE_P (x))
check_default_args (x);

I'm not sure how to proceed from here, so unassigning.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 AssignedTo|reichelt at gcc dot gnu dot |unassigned at gcc dot gnu
   |org |dot org
 Status|REOPENED|NEW
  Known to fail|3.4.6 4.0.3 4.1.0 4.1.1 |3.4.6 4.0.3 4.1.0 4.2.0
   ||4.3.0
  Known to work|3.3.6 3.4.0 3.4.5 4.0.2 |3.3.6 3.4.0 3.4.5 4.0.0
   |4.0.4 4.1.2 |4.0.1 4.0.2
   Target Milestone|4.0.4   |4.2.5


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

[Bug c/39308] New: ICE when compiling with -O[s123] -floop-interchange

[il dot basso dot buffo at gmail dot com]

In almost any nontrivial C project, using GCC 4.4 SVN (rev 144432) results in
an ICE when building with any nonzero value of -O and -floop-interchange.


-- 
   Summary: ICE when compiling with -O[s123] -floop-interchange
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: il dot basso dot buffo at gmail dot com
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c/39308] ICE when compiling with -O[s123] -floop-interchange

[il dot basso dot buffo at gmail dot com]

--- Comment #1 from il dot basso dot buffo at gmail dot com  2009-02-25 
21:49 ---
Created an attachment (id=17362)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17362&action=view)
Preprocessed C source (from bzip2 sources)


-- 


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

[Bug middle-end/36578] cast to long double not taken into account when result stored to a double

[janis at gcc dot gnu dot org]

--- Comment #6 from janis at gcc dot gnu dot org  2009-02-25 22:09 ---
Subject: Bug 36578

Author: janis
Date: Wed Feb 25 22:08:55 2009
New Revision: 144436

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144436
Log:
2009-02-25  Janis Johnson  

gcc/
Backport from mainline:
2008-10-29  Joseph Myers  

PR middle-end/36578
* convert.c (convert_to_real): Do not optimize conversions of
binary arithmetic operations between binary and decimal
floating-point types.  Consider mode of target type in determining
decimal type for arithmetic.  Unless
flag_unsafe_math_optimizations, do not optimize binary conversions
where this may change rounding behavior.
* real.c (real_can_shorten_arithmetic): New.
* real.h (real_can_shorten_arithmetic): Declare.

gcc/testsuite/
Backport from mainline:
2008-10-29  Joseph Myers  

PR middle-end/36578
* gcc.dg/dfp/convert-bfp-13.c, gcc.dg/dfp/convert-bfp-14.c,
gcc.dg/dfp/convert-dfp-fold-2.c, gcc.target/i386/pr36578-1.c,
gcc.target/i386/pr36578-2.c: New tests.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/convert-bfp-13.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/convert-bfp-14.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/convert-dfp-fold-2.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/pr39034.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr36578-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr36578-2.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/convert.c
branches/gcc-4_3-branch/gcc/real.c
branches/gcc-4_3-branch/gcc/real.h
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/39248] FAIL: gcc.dg/vect/vect-complex-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2009-02-25 
22:35 ---
Subject: Re:  FAIL:
gcc.dg/vect/vect-complex-1.c

On Wed, 25 Feb 2009, irar at il dot ibm dot com wrote:

> Does adding attribute aligned, as below, help?

Yes, it fixes the failure.

> Could you please attach slp-7.c's dump as well? I think it is a different
> problem there.

Attached.

Dave


--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2009-02-25 
22:35 ---
Created an attachment (id=17363)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17363&action=view)


-- 


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

[Bug target/39296] ICE in cselib_hash_rtx with -O -fPIC -mcmodel=large

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #2 from sgk at troutmask dot apl dot washington dot edu  
2009-02-25 22:38 ---
Subject: Re:  ICE in cselib_hash_rtx with -O -fPIC -mcmodel=large

On Wed, Feb 25, 2009 at 01:47:45AM -, hjl dot tools at gmail dot com wrote:
> 
> --- Comment #1 from hjl dot tools at gmail dot com  2009-02-25 01:47 
> ---
> I can't reproduce it on Linux with revision 144417. I believe it is a dup
> of PR 38988. Reopen it if it isn't fixed in trunk.
> 
> *** This bug has been marked as a duplicate of 38988 ***
> 
> 

Testing shows that the bug was fixed by revision 144417.


-- 


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

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #12 from rakdver at kam dot mff dot cuni dot cz  2009-02-25 
22:41 ---
Subject: Re:  [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

> --- Comment #11 from hjl dot tools at gmail dot com  2009-02-25 19:18 
> ---
> (In reply to comment #10)
> > The difference between
> > 
> > >   D.1254 = &a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) 
> > > + 1)
> > > * 2;
> > 
> > (original) and
> > 
> > >   D.1255 = ((long unsigned int) &a + 2) + (long unsigned int) ((unsigned 
> > > int)
> > >len + 4294967295) * 2;
> > 
> > (current) is mostly cosmetical; the test in the testcase should be made more
> > robust, but other than that, there is no regression here.
> > 
> 
> The new loop is
> 
> .L3:
> st2 [r14] = r33, 2
> ;;
> cmp.ne p6, p7 = r15, r14
> (p6) br.cond.sptk .L3
> 
> The old loop is
> 
>mov ar.lc = r15
> .L3:
> st2 [r14] = r33, 2
> ;;
> br.cloop.sptk.few .L3
> 
> They are quite different.

nevertheless, loop-31.c test is not supposed to test this; it just
checks whether strength reduction is performed correctly.  I think we
already have another PR regarding the problem that strength reduction
and iv elimination on tree level may cause rtl level # of iterations
analysis to fail (which leads to the code difference).


-- 


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

[Bug c/39044] -Wformat warns on printf() with stringpointer as sole argument

[vapier at gentoo dot org]

--- Comment #3 from vapier at gentoo dot org  2009-02-25 23:58 ---
i'd reconstruct this report as gcc not properly handling constant strings with
printf() when the string is readily available to it and clearly does not change

as for the kernel and this warning flag, that's a different issue


-- 

vapier at gentoo dot org changed:

   What|Removed |Added

 CC||toolchain at gentoo dot org


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

[Bug target/34299] [avr] ICE on function attribute syntax for main()

[eric dot weddington at atmel dot com]

--- Comment #9 from eric dot weddington at atmel dot com  2009-02-26 01:00 
---
(In reply to comment #8)
> Sorry for the dup.
> 
> This bug prevents compilation of almost all TinyOS apps using 4.3.3!  Is there
> a workaround?
> 

See comment #4 of this bug.


-- 


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

[Bug c++/29027] template conversion specialization found by using declaration

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2009-02-26 01:02 ---
Subject: Bug 29027

Author: janis
Date: Thu Feb 26 01:02:22 2009
New Revision: 13

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=13
Log:
libcpp/
PR c/29027
* include/cpplib.h (CPP_N_DEFAULT): Define.
* expr.c (interpret_float_suffix): Recognize d or D for double,
return new value for default.
(cpp_classify_number): Issue pedwarn for use of d or D in suffix.

gcc/
PR c/29027
* c-lex.c (interpret_float): Default (no suffix) is double.

gcc/testsuite/
PR c/29027
* gcc.dg/fltconst-1.c: Don't error for use of d or D in suffix.
* gcc.dg/fltconst-2.c: New test.
* gcc.dg/fltconst-double-pedantic-1.c: New test.
* gcc.dg/fltconst-double-pedantic-2.c: New test.

Added:
branches/c-4_5-branch/gcc/testsuite/gcc.dg/fltconst-2.c
branches/c-4_5-branch/gcc/testsuite/gcc.dg/fltconst-double-pedantic-1.c
branches/c-4_5-branch/gcc/testsuite/gcc.dg/fltconst-double-pedantic-2.c
Modified:
branches/c-4_5-branch/gcc/ChangeLog.c45
branches/c-4_5-branch/gcc/c-lex.c
branches/c-4_5-branch/gcc/testsuite/ChangeLog.c45
branches/c-4_5-branch/gcc/testsuite/gcc.dg/fltconst-1.c
branches/c-4_5-branch/libcpp/ChangeLog.c45
branches/c-4_5-branch/libcpp/expr.c
branches/c-4_5-branch/libcpp/include/cpplib.h


-- 


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

[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected

[ayers at fsfe dot org]

--- Comment #6 from ayers at fsfe dot org  2009-02-26 05:16 ---
Created an attachment (id=17364)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17364&action=view)
Updated patch (using and accessor function) inlcuding a test case

For the record:

This is an update of the existing patch which includes a test case.  This was
posted as an RFA: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01085.html with
the following ChangeLog entries:

2009-02-23  Richard Frith-Macdonald  

   PR libobjc/27466
   * objc/objc-api.h: declare objc_set_unexpected function.
   * exception.c: implement objc_set_unexpected function.
   * libobjc.def: export objc_set_unexpected

2009-02-23  David Ayers  

   PR libobjc/27466
   * objc/execute/exceptions/handler-1.m. New.


-- 


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

[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected

[ayers at fsfe dot org]

--- Comment #7 from ayers at fsfe dot org  2009-02-26 05:24 ---
Created an attachment (id=17365)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17365&action=view)
Alternative patch using a callback hook

This patch was posted as an RFA:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01086.html

With the following ChangeLog entry:

2009-02-23  Richard Frith-Macdonald  
David Ayers  

PR libobjc/27466
* objc/objc-api.h (_objc_unexpected_exception): Declare new
  hook.
* exception.c (objc_exception_throw): Use hook.
* libobjc.def (_objc_unexpected_exception): Export hook.

2009-02-23  David Ayers  

PR libobjc/27466
* objc/execute/exceptions/handler-1.m. New.


-- 


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

[Bug fortran/39292] [4.3/4.4 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:3884

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2009-02-26 06:24 ---
Subject: Bug 39292

Author: pault
Date: Thu Feb 26 06:23:42 2009
New Revision: 14

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=14
Log:
2009-02-26  Paul Thomas  

PR fortran/39292
* trans-array.c (gfc_conv_array_initializer): Convert all
expressions rather than ICEing.

2009-02-26  Paul Thomas  

PR fortran/39292
* gfortran.dg/initialization_22.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/initialization_22.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug inline-asm/39058] [4.3 regression] ICE with double in inline-asm

[uros at gcc dot gnu dot org]

--- Comment #6 from uros at gcc dot gnu dot org  2009-02-26 07:07 ---
Subject: Bug 39058

Author: uros
Date: Thu Feb 26 07:06:48 2009
New Revision: 15

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=15
Log:
Backport from mainline:
2009-02-02  Jakub Jelinek  

PR inline-asm/39058
* recog.h (asm_operand_ok): Add constraints argument.
* recog.c (asm_operand_ok): Likewise.  If it is set, for digits
recurse on matching constraint.
(check_asm_operands): Pass constraints as 3rd argument to
asm_operand_ok.  Don't look up matching constraint here.
* stmt.c (expand_asm_operands): Pass NULL as 3rd argument
to asm_operand_ok.

testsuite/ChangeLog:

Backport from mainline:
2009-02-02  Jakub Jelinek  

PR inline-asm/39058
* gcc.target/i386/pr39058.c: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr39058.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/recog.c
branches/gcc-4_3-branch/gcc/recog.h
branches/gcc-4_3-branch/gcc/stmt.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug inline-asm/39058] [4.3 regression] ICE with double in inline-asm

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2009-02-26 07:23 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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