[Bug c++/34749] Incorrect warning when applying dllimport to friend function

[angry-kasyan at narod dot ru]

--- Comment #10 from angry-kasyan at narod dot ru  2009-01-13 08:12 ---
(In reply to comment #9)
> (In reply to comment #8)
> > still unfixed?
> 
> Please provide a compilable self-contained testcase. 
> Danny
> 

Here is compilable testcase:

## begin df.cpp
__attribute__((dllimport)) int bar();

class Foo
{
private:
int foo();
friend __attribute__((dllimport)) int bar();
};

int Foo::foo()
{
return bar();
}
## end df.cpp

> g++ -S df.cpp


I don't see that patch in 4.3.2 or in the 4.3 branch. This is fixed in
mainline, so it'll appear in 4.4, I guess.


-- 


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

[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization

[steven at gcc dot gnu dot org]

--- Comment #19 from steven at gcc dot gnu dot org  2009-01-13 08:19 ---
Joern, nobody is forcing you to follow the crowd if you think the crowd is
going in the wrong direction.


-- 


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

[Bug libstdc++/32666] FAIL: abi_check

[bkoz at gcc dot gnu dot org]

--- Comment #7 from bkoz at gcc dot gnu dot org  2009-01-13 08:41 ---
From:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00197.html

Looking at the __signbitl issue first. HPPA is the only platform that wants to
export this. Let's try to figure out why.

I see this in include/c_global/cmath

  template
inline typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value,
   int>::__type
signbit(_Tp __f)
{
  typedef typename __gnu_cxx::__promote<_Tp>::__type __type;
  return __builtin_signbit(__type(__f));
}

This is from 

130443  paolo signbit(_Tp __f)

or

Author: paolo
Date: Mon Nov 26 18:24:54 2007
New Revision: 130443

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130443
Log:
2007-11-26  Paolo Carlini  

PR libstdc++/25913
* include/c_std/cmath (std::fpclassify, isfinite, isinf, isnan,
isnormal, signbit, isgreater, isgreaterequal, isless, islessequal,
islessgreater, isunordered): Guard with __enable_if and forward
with __promote.
* include/c_global/cmath: Likewise.
* testsuite/26_numerics/headers/cmath/25913.cc: New.

* include/c_std/cmath (__gnu_cxx::__capture_isfinite,
__capture_isinf, __capture_isnan, __capture_isnormal,
__capture_signbit, __capture_isgreater, __capture_isgreaterequal,
__capture_isless, __capture_islessequal, __capture_islessgreater,
__capture_isunordered): Remove.
(std::isfinite, isinf, isnan, isnormal, signbit, isgreater,
isgreaterequal, isless, islessequal, islessgreater, isunordered):
Forward to the corresponding builtin.
* include/c_global/cmath: Likewise.

* include/c_global/cmath (std::atan2, pow): Guard with __enable_if.


OK. 

Well, that removed the last uses for libmath. (signbit, copysign. These were
once needed for the complex implementation but seem to not be necessary or use
builtins now, so can be removed.)

The following patch does so.

Dave, can you try it on hppa-linux? I've adjusted the baseline_symbols.txt file
such that it should pass now. If it does not, do 'make check-abi' and attach
the libstdc++.log file please. 

I'm not quite sure that the src/compatibility.cc bits are correct. They should
be correct for hppa, but I see that:

alpha-linux-gnu/baseline_symbols.txt:FUNC:atanl@@GLIBCXX_3.4.3
alpha-linux-gnu/baseline_symbols.txt:FUNC:tanl@@GLIBCXX_3.4
hppa-linux-gnu/baseline_symbols.txt:FUNC:atanl@@GLIBCXX_3.4.3
hppa-linux-gnu/baseline_symbols.txt:FUNC:tanl@@GLIBCXX_3.4
hppa-linux-gnu/baseline_symbols.txt.orig:FUNC:atanl@@GLIBCXX_3.4.3
hppa-linux-gnu/baseline_symbols.txt.orig:FUNC:tanl@@GLIBCXX_3.4
mips-linux-gnu/baseline_symbols.txt:FUNC:atanl@@GLIBCXX_3.4.3
mips-linux-gnu/baseline_symbols.txt:FUNC:tanl@@GLIBCXX_3.4
powerpc64-linux-gnu/baseline_symbols.txt:FUNC:at...@glibcxx_3.4.3
powerpc64-linux-gnu/baseline_symbols.txt:FUNC:t...@glibcxx_3.4
powerpc-linux-gnu/baseline_symbols.txt:FUNC:at...@glibcxx_3.4.3
powerpc-linux-gnu/baseline_symbols.txt:FUNC:t...@glibcxx_3.4
s390-linux-gnu/baseline_symbols.txt:FUNC:at...@glibcxx_3.4.3
s390-linux-gnu/baseline_symbols.txt:FUNC:t...@glibcxx_3.4
s390x-linux-gnu/baseline_symbols.txt:FUNC:atanl@@GLIBCXX_3.4.3
s390x-linux-gnu/baseline_symbols.txt:FUNC:tanl@@GLIBCXX_3.4
sparc-linux-gnu/baseline_symbols.txt:FUNC:at...@glibcxx_3.4.3
sparc-linux-gnu/baseline_symbols.txt:FUNC:t...@glibcxx_3.4

all these other ones need it too, and am not sure if the
_GLIBCXX_LONG_DOUBLE_COMPAT macro is true on these other platforms.


As an aside, I think that a lot of the GLIBCXX_CHECK_MATH finding of math
functions at configure time can be seriously reduced now that most of these are
builtins. This should be audited and fixed. We should not really have to define
most of these now.

-benjamin


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-13 08:41:37
   date||


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

[Bug libstdc++/33485] parallel v3: do not use __builtin_alloca, use VLA

[bkoz at gcc dot gnu dot org]

--- Comment #14 from bkoz at gcc dot gnu dot org  2009-01-13 08:42 ---
Created an attachment (id=17082)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17082&action=view)
patch for hppa check-abi fail


-- 


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

[Bug libstdc++/32666] FAIL: abi_check

[bkoz at gcc dot gnu dot org]

--- Comment #8 from bkoz at gcc dot gnu dot org  2009-01-13 08:43 ---
Created an attachment (id=17083)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17083&action=view)
check abi fails


-- 


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

[Bug tree-optimization/38748] [4.4 Regression] Missed FRE because of VIEW_CONVERT_EXPR

[rguenther at suse dot de]

--- Comment #5 from rguenther at suse dot de  2009-01-13 08:55 ---
Subject: Re:  [4.4 Regression] Missed FRE because
 of VIEW_CONVERT_EXPR

On Tue, 13 Jan 2009, pinskia at gcc dot gnu dot org wrote:

> --- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-13 01:09 
> ---
> We should be able to fold:
> VIEW_CONVERT_EXPR(D.919509.D.78313.D.78008)
> 
> Into just D.919509 .

True.  I tried a quick shot at it but it turns out to be slightly
complicated ;)

Richard.


-- 


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

[Bug c++/38795] [4.3/4.4 regression] ICE with reinterpret_cast and variadic templates

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-01-13 09:03 ---
Seems cp_walk_subtrees doesn't handle REINTERPRET_CAST_EXPR, so
check_for_bare_parameter_packs doesn't detect them.  Just handling this the
same
as CAST_EXPR seems to fix this testcase.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-13 09:03:19
   date||


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

[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-13 09:29 ---
I think the best solution is to explore the possibility of lowering the call
to what it will look like in the end - pass return values of variable size
by reference.  Hopefully all targets will end up doing this ;)


-- 


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

[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-01-13 09:33 ---
Or, can we make that invalid GNU C please? ;)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org


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

[Bug tree-optimization/38819] [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-13 09:51 ---
It should be ok with -fnon-call-exceptions.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.2.5


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

[Bug libstdc++/32666] FAIL: abi_check

[bkoz at gcc dot gnu dot org]

--- Comment #9 from bkoz at gcc dot gnu dot org  2009-01-13 10:02 ---
Created an attachment (id=17084)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17084&action=view)
shiny


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #17083|0   |1
is obsolete||


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

[Bug libstdc++/33485] parallel v3: do not use __builtin_alloca, use VLA

[bkoz at gcc dot gnu dot org]

--- Comment #15 from bkoz at gcc dot gnu dot org  2009-01-13 10:06 ---
(From update of attachment 17082)
mistaken, part of 32666


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #17082|1   |0
   is patch||
  Attachment #17082|0   |1
is obsolete||


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

[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit

[frikkie at zitera dot co dot za]

--- Comment #12 from frikkie at zitera dot co dot za  2009-01-13 10:12 
---
Created an attachment (id=17085)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17085&action=view)
patch_for_volatile_bitfields_gcc400.tgz

The following patches help to honour the container type of the volatile
bitfield when the GCC internal: TARGET_NARROW_VOLATILE_BITFIELD is false.

The patch is for GCC 4.0.0

Included in the tgz-file is the disassembly for the application: main.c, with
the original GCC 4.0.0 source and the patched source.


-- 


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

[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit

[frikkie at zitera dot co dot za]

--- Comment #13 from frikkie at zitera dot co dot za  2009-01-13 10:42 
---
Please note: The patch was for GCC 4.4.0, not GCC 4.0.0 as mentioned in the
previous post.


-- 


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

[Bug fortran/38822] New: ICE in in gfc_target_encode_expr

[burnus at gcc dot gnu dot org]

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2

(There is another issue with constant folding, which Steve wants to fix.)

The following program compiles with NAG f95/g95/ifort and prints "T F". With
gfortran 4.3 and 4.4 it crashes (with 4.1/4.2 it does not compile):

f951: internal compiler error: in gfc_target_encode_expr, at
fortran/target-memory.c:249

  gcc_assert (source->expr_type == EXPR_CONSTANT
  || source->expr_type == EXPR_STRUCTURE
  || source->expr_type == EXPR_SUBSTRING);

Here, source->expr_type == EXPR_OP.

Reduced testcase:
   integer z(0*transfer(2.D0**2.,1)+2)
   end

Long testcase, see
http://groups.google.com/group/comp.lang.fortran/msg/c71f697c3e21e3f2


-- 
   Summary: ICE in in gfc_target_encode_expr
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  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=38822

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2009-01-13 11:03 
---
Smaller testcase for the possible libstdc++ / C++ FE issue, build with
-O2 -finline-functions -Wstrict-aliasing -Wsystem-headers

#include 

class test
{
  test();
  void bar(int ci);

  std::set foo;
};

void test::bar(int ci )
{
  test ctx;
  ctx.foo.insert( ci );
}

/usr/include/c++/4.4/bits/stl_function.h: In member function ‘void
test::bar(int)’:
/usr/include/c++/4.4/bits/stl_function.h:230: warning: dereferencing pointer
‘__x.13’ does break strict-aliasing rules
/usr/include/c++/4.4/bits/stl_tree.h:530: note: initialized from here
/usr/include/c++/4.4/bits/stl_function.h:230: warning: dereferencing pointer
‘__x.13’ does break strict-aliasing rules
/usr/include/c++/4.4/bits/stl_tree.h:530: note: initialized from here

I am now trying to investigate who is at fault.


-- 


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

[Bug fortran/38823] New: Diagnose and treat (-2.0)**2.0 properly

[burnus at gcc dot gnu dot org]

Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2

  print *, (-2.0)**2.0
  end
is invalid. gfortran should print a diagnostic for -std=f95/f2003/f2008 as NAG
f95 does:
  Error: Negative floating-point value raised to a real power

Fortran 2003 in the second sentence of the second paragraph of "7.1.8
Evaluation of Operations":

  "Raising a negative-valued primary of type real to a real power is
   prohibitted."

The question is whether one needs to reject it completely or only with
-std=f95. Steve (see thread) thinks the constant folding gets it wrong
(-> gives "4.0").

Current results:
- Runtime and compile time evaluation (ifort, gfortran, g95):
  -2.0**2.0 = 4.0
  -2.0**1.9 = NaN
- Mathematica:
  -2^2 = 4, -2.0^2.0 = -4.0
  2.0^1.9 = -3.73213


-- 
   Summary: Diagnose and treat (-2.0)**2.0 properly
   Product: gcc
   Version: 4.4.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=38823

[Bug target/38824] New: [4.4 regression] performance regression of sse code from 4.2/4.3

[tim at klingt dot org]

the following code shows a performance regression from gcc-4.2 to gcc-4.3 and
4.4 (20090111) on an intel core2 using the x86_64 architecture:

void bench_1(float * out, float * in, float f, unsigned int n)
{
n /= 4;
__m128 scalar = _mm_set_ps1(f);
do
{
__m128 arg = _mm_load_ps(in);
__m128 result = _mm_add_ps(arg, scalar);
_mm_store_ps(out, result);
in += 4;
out += 4;
}
while (--n);
}

results, running the function 1 times, measured with performance
counters (requires a patched kernel), compiled with -O3 -mfpmath=sse -msse
gcc-4.2: 1946256122 cycles, 8394301290 instructions, 5005 branch misses
gcc-4.3: 2191990305 cycles, 7658465214 instructions, 3442 branch misses
gcc-4.4: 2532778908 cycles, 7462359830 instructions, 8593402 branch misses

although the instruction count decreases, the cycles spent in the function
increases. also gcc-4.4 shows a huge number of branch misses.

the generated code is

gcc-4.2:
.globl _Z7bench_1PfS_fj
.type   _Z7bench_1PfS_fj, @function
_Z7bench_1PfS_fj:
.LFB2695:
movaps  %xmm0, %xmm2
shrl$2, %edx
shufps  $0, %xmm2, %xmm2
movaps  %xmm2, %xmm1
.p2align 4,,7
.L15:
movaps  (%rsi), %xmm0
addq$16, %rsi
addps   %xmm1, %xmm0
movaps  %xmm0, (%rdi)
addq$16, %rdi
subl$1, %edx
jne .L15
rep ; ret
.LFE2695:
.size   _Z7bench_1PfS_fj, .-_Z7bench_1PfS_fj
.align 2
.p2align 4,,15

gcc-4.3
.globl _Z7bench_1PfS_fj
.type   _Z7bench_1PfS_fj, @function
_Z7bench_1PfS_fj:
.LFB2563:
movaps  %xmm0, %xmm2
shrl$2, %edx
subl$1, %edx
xorl%eax, %eax
shufps  $0, %xmm2, %xmm2
mov %edx, %edx
addq$1, %rdx
salq$4, %rdx
movaps  %xmm2, %xmm1
.p2align 4,,10
.p2align 3
.L17:
movaps  (%rsi,%rax), %xmm0
addps   %xmm1, %xmm0
movaps  %xmm0, (%rdi,%rax)
addq$16, %rax
cmpq%rdx, %rax
jne .L17
rep
ret
.LFE2563:
.size   _Z7bench_1PfS_fj, .-_Z7bench_1PfS_fj
.p2align 4,,15

gcc-4.4
.globl _Z7bench_1PfS_fj
.type   _Z7bench_1PfS_fj, @function
_Z7bench_1PfS_fj:
.LFB2489:
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
shrl$2, %edx
shufps  $0, %xmm0, %xmm0
subl$1, %edx
xorl%eax, %eax
addq$1, %rdx
salq$4, %rdx
.p2align 4,,10
.p2align 3
.L17:
movaps  %xmm0, %xmm1
addps   (%rsi,%rax), %xmm1
movaps  %xmm1, (%rdi,%rax)
addq$16, %rax
cmpq%rdx, %rax
jne .L17
rep
ret
.cfi_endproc
.LFE2489:
.size   _Z7bench_1PfS_fj, .-_Z7bench_1PfS_fj
.p2align 4,,15


-- 
   Summary: [4.4 regression] performance regression of sse code from
4.2/4.3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug libgcj/38812] gcj-built executables don't run after strip (libgcj erroneously references _environ)

[pkeller at globalphasing dot com]

--- Comment #4 from pkeller at globalphasing dot com  2009-01-13 11:26 
---
Thanks for confirming the problem. I know that what I did isn't particularly
portable (although it would be fine on the systems that I work with). I vaguely
remember something about setenv not being available on Solaris, but I haven't
worked with Solaris for several years now.

I'm hoping that someone with more experience than me of libgcj development and
the range of supported OS's can use my information to submit a more robust fix.
I'll keep an eye on this bug and help out if I can.


-- 


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

Re: [Bug fortran/38823] New: Diagnose and treat (-2.0)**2.0 properly

[Andrew Thomas Pinski]

On Jan 13, 2009, at 3:08 AM, "burnus at gcc dot gnu dot org" > wrote:



Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2

 print *, (-2.0)**2.0
 end
is invalid. gfortran should print a diagnostic for -std=f95/f2003/ 
f2008 as NAG

f95 does:
 Error: Negative floating-point value raised to a real power

Fortran 2003 in the second sentence of the second paragraph of "7.1.8
Evaluation of Operations":

 "Raising a negative-valued primary of type real to a real power is
  prohibitted."

The question is whether one needs to reject it completely or only with
-std=f95. Steve (see thread) thinks the constant folding gets it wrong
(-> gives "4.0").

Current results:
- Runtime and compile time evaluation (ifort, gfortran, g95):
 -2.0**2.0 = 4.0
 -2.0**1.9 = NaN
- Mathematica:
 -2^2 = 4, -2.0^2.0 = -4.0
 2.0^1.9 = -3.73213


-2.0^1.9 will be a complex number.  Maybe we can define it as taking  
the real part. I don't know if that is better than generating a nan  
here.


Thanks,
Andrew Pinski






--
  Summary: Diagnose and treat (-2.0)**2.0 properly
  Product: gcc
  Version: 4.4.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=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-13 11:28 ---
Subject: Re:   New: Diagnose and treat (-2.0)**2.0 properly

On Jan 13, 2009, at 3:08 AM, "burnus at gcc dot gnu dot org"
 wrote:

> Found at:
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2
>
>  print *, (-2.0)**2.0
>  end
> is invalid. gfortran should print a diagnostic for -std=f95/f2003/ 
> f2008 as NAG
> f95 does:
>  Error: Negative floating-point value raised to a real power
>
> Fortran 2003 in the second sentence of the second paragraph of "7.1.8
> Evaluation of Operations":
>
>  "Raising a negative-valued primary of type real to a real power is
>   prohibitted."
>
> The question is whether one needs to reject it completely or only with
> -std=f95. Steve (see thread) thinks the constant folding gets it wrong
> (-> gives "4.0").
>
> Current results:
> - Runtime and compile time evaluation (ifort, gfortran, g95):
>  -2.0**2.0 = 4.0
>  -2.0**1.9 = NaN
> - Mathematica:
>  -2^2 = 4, -2.0^2.0 = -4.0
>  2.0^1.9 = -3.73213

-2.0^1.9 will be a complex number.  Maybe we can define it as taking  
the real part. I don't know if that is better than generating a nan  
here.

Thanks,
Andrew Pinski


>
>
>
> -- 
>   Summary: Diagnose and treat (-2.0)**2.0 properly
>   Product: gcc
>   Version: 4.4.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=38823
>


-- 


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

[Bug target/38825] New: missed optimization: register renaming in unrolled loop

[tim at klingt dot org]

the following two functions are equivalent, adding a scalar to a vector, using
a manual loop unrolling of 8 (2 sse vectors).

the first function serializes the operation, while the second function
interleaves the instructions for two operations:

void bench_3(float * out, float * in, float f, unsigned int n)
{
n /= 8;
__m128 scalar = _mm_set_ps1(f);
do
{
__m128 arg = _mm_load_ps(in);
__m128 result = _mm_add_ps(arg, scalar);
_mm_store_ps(out, result);

arg = _mm_load_ps(in+4);
result = _mm_add_ps(arg, scalar);
_mm_store_ps(out+4, result);
in += 8;
out += 8;
}
while (--n);
}

with the generated code:
.L13:
movaps  (%rsi,%rax), %xmm0
addps   %xmm1, %xmm0
movaps  %xmm0, (%rdi,%rax)
movaps  16(%rsi,%rax), %xmm0
addps   %xmm1, %xmm0
movaps  %xmm0, 16(%rdi,%rax)
addq$32, %rax
cmpq%rdx, %rax
jne .L13


void bench_4(float * out, float * in, float f, unsigned int n)
{
n /= 8;
__m128 scalar = _mm_set_ps1(f);
do
{
__m128 arg  = _mm_load_ps(in);
__m128 arg2 = _mm_load_ps(in+4);
__m128 result  = _mm_add_ps(arg, scalar);
__m128 result2 = _mm_add_ps(arg2, scalar);
_mm_store_ps(out, result);
_mm_store_ps(out+4, result2);
in += 8;
out += 8;
}
while (--n);
}

generated code:
.L9:
movaps  (%rsi,%rax), %xmm0
movaps  16(%rsi,%rax), %xmm1
addps   %xmm2, %xmm0
addps   %xmm2, %xmm1
movaps  %xmm0, (%rdi,%rax)
movaps  %xmm1, 16(%rdi,%rax)
addq$32, %rax
cmpq%rdx, %rax
jne .L9

the interleaved code outperforms the sequential code by about 12% on
x86_64/core2, possibly, because the instruction pairs (load/add/store) don't
have any data dependencies.
it would be nice, if gcc could do a register renaming and instruction
reordering on the first function to generate the same instructions than the
second function.


-- 
   Summary: missed optimization: register renaming in unrolled loop
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-01-13 11:37 ---
> - Mathematica:
>   -2^2 = 4, -2.0^2.0 = -4.0
>   2.0^1.9 = -3.73213  <--- probably -2.0^1.9!

Apparently Mathematica parse "-2.0^a" as "-(2.0^a)". (-2.0)^1.9 gives "3.54947-
1.15329 I". I don't know if the fortran standard says how "-a**b" should be
parsed (nor have the time right now to decipher the legalese).


-- 


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2009-01-13 11:30 ---
> The question is whether one needs to reject it completely or only with 
> -std=f95.

I vote for "only with -std=f95" with may be a warning otherwise. I think it is
a legitimate optimization to replace A**B by A**I (with I=B) when B is known to
be an integer, hence to accept negative values for A in this case. I find
upsetting to have to cheat with variables when constant folding does not give
the same result as a similar code with variables.


-- 


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

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

--- Comment #15 from laurent at guerby dot net  2009-01-13 12:05 ---
Add URL of gcc-patches discussion

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00409.html


-- 

laurent at guerby dot net changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||01/msg00409.html


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2009-01-13 12:14 
---
There is only a conditional path through the program that violates aliasing
rules,
likely never executed.  We do not detect this fact because of a points-to
solver
issue, PR38826.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||38826


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

[Bug tree-optimization/38826] New: points-to result wrong for reads from call-clobbered vars

[rguenth at gcc dot gnu dot org]

The following testcase emits a strict-aliasing warning because the points-to
result for p is wrong.  It should be pt_anything, but instead the read from
s.q is considered a non-pointer variable (we do not have constraints for all
implicitly taken addresses by passing &s to the function call).

struct S { int *p; int *q; };

void foo (struct S *);

int bar (int b)
{
  struct S s;
  int *p;
  float f;
  foo (&s);
  if (b)
p = s.q;
  else
p = (int *)&f;
  return *p;
}

Inspecting the points-to results on

struct S { int *p; int *q; };

void foo (struct S *);

int *bar (int b)
{
  struct S s;
  foo (&s);
  return s.q;
}

exposes the failure as

ESCAPED = { ESCAPED NONLOCAL s s.64+64 }
...
s = { ESCAPED NONLOCAL }
s.64+64 = { ESCAPED NONLOCAL }
D.1598_1 = { }


D.1598_1 should have the same solution as s.64+64.


-- 
   Summary: points-to result wrong for reads from call-clobbered
vars
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  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=38826

[Bug tree-optimization/38826] points-to result wrong for reads from call-clobbered vars

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-13 12:34 ---
It is interesting to see how taking the address of &s.q makes it a pointer
variable.  The fundamental issue seems to be that eliminating non-pointers
and their edges conflicts with field-sensitive analysis.

Consider

struct S { int *p; int *q; };

void foo (struct S **);

int *bar (int b)
{
  struct S s;
  struct S *p = &s;
  foo (&p);
  return s.q;
}

to see that just generating extra ADDRESSOF constraints for call arguments
will not fix the issue.

Not only we will need to avoid eliminating non-pointers / edges if any of a
variables sub-field has got a proper pointer label, unifying them (they
still have pointer label 0) is also wrong.

Danny, any idea where/how to fix this?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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

[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function

[joseph at codesourcery dot com]

--- Comment #5 from joseph at codesourcery dot com  2009-01-13 12:52 ---
Subject: Re:  [4.2/4.3/4.4 regression] ICE with nested
 function

Does standard Ada allow something like this?  If so, there's not much 
point making it invalid GNU C.


-- 


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

[Bug other/38805] sed Unterminated `s' command

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2009-01-13 13:05 ---
(In reply to comment #3)
> for ac_var in `(set) 2>&1 |
>sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do
> 

That happens much earlier than the posted errors.

Thomas, please print the full name of the directory you are configuring in,
and the exact command line you are using to configure and build the GCC tree.

Thanks,
Ralf


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org


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

[Bug bootstrap/38728] gcc 4.4.0 20090104 - "make install" is relinking `libgij.la'

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2009-01-13 13:10 ---
Relinking in itself is not a bug.  You can avoid it on some systems
(but likely not on yours) with --enable-fast-install.
On some systems it is simply necessary.

If there is a specific problem you have with the relinking process, then
please describe that and reopen the bug.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization

[amylaar at gcc dot gnu dot org]

--- Comment #20 from amylaar at gcc dot gnu dot org  2009-01-13 14:00 
---
(In reply to comment #19)
> Joern, nobody is forcing you to follow the crowd if you think the crowd is
> going in the wrong direction.

I have evidence that the direction is wrong.  I added a new option to disable
partial-partial pre while keeping the rest of -O3 and -ftree-pre enabled.
This got EEMBC bitmnp back to the level of 4.2.1 (unmodified 4.4.0 needs 2.55
times the amout of cycles).  fbital00 also improved, although it regained only
a little of the performance that it lost since 4.2.1 - cycle count is now down
6% against unmodified gcc 4.4.0 .  Overall the disabling of partial-partial
is also beneficial for EEMBC; there are a few other benchmarks that improved
5 or 6 percent, and the worst regressions are one and two percent.

These are the changes in the geometric means of cycle counts by disabling
partial-partial redundancy elimination per EEMBC benchmark suite:

automotive: 5.73% improvement
consumer:   0.04% improvement
networking: 0.37% improvement
office: 1.39% worse
telecom:0.00% worse


-- 


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

[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization

[amylaar at gcc dot gnu dot org]

--- Comment #21 from amylaar at gcc dot gnu dot org  2009-01-13 14:11 
---
(In reply to comment #20)
> office: 1.39% worse

Actually, this is the EEMBC version with bezier01, where the entire benchmark
gets optized away and thus tiny changes in the cost of the set-up code make
noticeable differences.  Comparing the geometric means with bezier01 left out
gives:

automotive: 5.73% improvement
consumer:   0.04% improvement
networking: 0.37% improvement
office: 0.90% worse
telecom:0.00% worse


-- 


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

[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization

[rguenther at suse dot de]

--- Comment #22 from rguenther at suse dot de  2009-01-13 14:29 ---
Subject: Re:  TreeSSA-PRE load after store missed
 optimization

On Tue, 13 Jan 2009, amylaar at gcc dot gnu dot org wrote:

> --- Comment #21 from amylaar at gcc dot gnu dot org  2009-01-13 14:11 
> ---
> (In reply to comment #20)
> > office: 1.39% worse
> 
> Actually, this is the EEMBC version with bezier01, where the entire benchmark
> gets optized away and thus tiny changes in the cost of the set-up code make
> noticeable differences.  Comparing the geometric means with bezier01 left out
> gives:
> 
> automotive: 5.73% improvement
> consumer:   0.04% improvement
> networking: 0.37% improvement
> office: 0.90% worse
> telecom:0.00% worse

If you post a patch to add the option to enable/disable partial-PRE I will
happily review and approve it for 4.4.

Richard.


-- 


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

[Bug tree-optimization/38826] points-to result wrong for reads from call-clobbered vars

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-01-13 14:37 ---
In fact, field-sensitive points-to analysis is probably not improving things
anyway - a testcase where it does is certainly welcome! - simply due to the
fact that the points-to analysis would need to be more clever than
load (partial-)redundancy elimination.  Where it could help is for IPA mode
though.  And likely it will rot very quickly if we disable it, but ...
disabling
it would be my prefered choice here.


-- 


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

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[rob1weld at aol dot com]

--- Comment #7 from rob1weld at aol dot com  2009-01-13 14:38 ---
Let me clarify the accuracy of my meaning:

When I said: "Down in family is not cross compiling." I meant for the purposes
of being able to execute 'target' code on the 'host', 'build' or 'target'
platform (as when executables that create source code are ran during the
build).

Technically speaking, _ANY_ difference in 'host', 'build' or 'target'
processor,
even a _small_ revision, makes it a "cross compile"; we care most (during the
build) if we can execute our utilities.

---

That reminds me. It would be great if there were a ./configure option to
specify a script that would "enable" the other hardware. 

It could 'wake-up' real hardware and ask it to download / execute / upload
results of some code. It could run WINE or QEmu and execute the utility on
the target to allow easier cross-porting.

A set of 'gnokii-like' scripts could create a simple framework to allow gdb
to remotely execute code (port gcc to your cellphone's Operating System).


I run gcc to cross compile for my router (Linux 2.6) and cellphone (Symbian).

Rob

Rob


-- 


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

[Bug bootstrap/38800] gcc 4.4.0 20090109 - "make -i -k distclean" does not remove amd64/*/* fixincludes/* and /gnattools/*

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2009-01-13 14:44 ---
(In reply to comment #1)
> fixincludes is already registered as PR 25470. 
> 
> And really PR 3415 is the original bug for it.
> 
> *** This bug has been marked as a duplicate of 3415 ***
> 

Hehe ...

Only a few years old.


-- 


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

[Bug bootstrap/38792] RFE - Need Makefile to build using different strategy for "coverage" vs. "profiling"

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2009-01-13 14:53 ---
(In reply to comment #3)
> Coverage builds should not be bootstrapped.
> 
> Profiled bootstrap means build stage1 with no opts and then stage2 with
> generating the profiling data and then build some target libraries (not all
> though) and the build stage3 using that generated profile data.
> 

For "Coverage" I used the additional ./configure option of
"--enable-coverage=noopt" and initiated the 'make' by typing "gmake".

For "Profiling" I used no additional ./configure options and initiated
the 'make' by typing "gmake profiledbootstrap".

Rob

PS: I did succeed in compiling gcc and it's libraries with the "coverage"
options: "-fprofile-arcs -ftest-coverage" and now when I run the Testsuite
I get coverage stats in my executable's directory. 


-- 


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

[Bug bootstrap/38788] gcc 4.4.0 20090109 - Configure with "--enable-intermodule" breaks build

[rob1weld at aol dot com]

--- Comment #8 from rob1weld at aol dot com  2009-01-13 14:58 ---
(In reply to comment #7)
> Nobody builds using --enable-intermodule, it uses too much memory in general
> anyways so closing as won't fix.
> 

We can "fix" it by reopening this bug and removing --enable-intermodule .

It is simply not possible for it to work, it makes no sense to have it (unless
you want to backport it to gcc 2.x (were it might actually work)).


-- 

rob1weld at aol dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization

[amylaar at gcc dot gnu dot org]

--- Comment #23 from amylaar at gcc dot gnu dot org  2009-01-13 14:58 
---
(In reply to comment #22)
> If you post a patch to add the option to enable/disable partial-PRE I will
> happily review and approve it for 4.4.

I'd be happy to post the patch, but we (ARC) are still waiting for the
FSF acknowledgement that our copyright assignment has been filed.


-- 


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

[Bug target/38824] [4.4 regression] performance regression of sse code from 4.2/4.3

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-13 15:07 ---
I don't see how this changes could cause more branch misses.  If you do the
same .palign for the 4.4 code does the regression vanish?  I would suspect
that the loop-stream detector catches one but not the other form for some
reason.  Maybe the Intel folks can properly analyze this - HJ?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu dot org


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

[Bug target/38825] missed optimization: register renaming in unrolled loop

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-13 15:08 ---
Try -frename-registers.


-- 


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

[Bug bootstrap/38788] gcc 4.4.0 20090109 - Configure with "--enable-intermodule" breaks build

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2009-01-13 15:09 ---
Reopening a bug doesn't "fix" anything.  Patches do.


-- 


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

[Bug target/38825] missed optimization: register renaming in unrolled loop

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-01-13 15:15 ---
Note that your testcase has moved the load _mm_load_ps(in+4); before the
store _mm_store_ps(out, result); which the compiler cannot do itself because
they may alias.


-- 


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

[Bug bootstrap/38776] gcc 4.4.0 20090109 - Configure with "--enable-coverage=noopt" breaks build

[rob1weld at aol dot com]

--- Comment #7 from rob1weld at aol dot com  2009-01-13 15:17 ---
(In reply to comment #6)
> You should not be bootstrapping a --enable-coverage=noopt build, you should
> only need to build stage1 gcc.
> 

I only typed make.

If I set "--enable-coverage=noopt" it should build correctly when I type
make and discontinue the build at the correct stage. Not my fault.

Rob


-- 


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

[Bug bootstrap/38775] gcc 4.4.0 20090109 - The Makefile displays "profile" when using "--enable-coverage" (and not profiling)

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2009-01-13 15:19 ---
(In reply to comment #1)
> Well you don't understand any of these options it seems.
> First --enable-coverage=nopt does nothing except changes the CFLAGS really.
> There is nothing in the toplevel makefile or configure which uses 
> --enable-coverage=, only the gcc subdirectory.  Also you should not be
> bootstrapping a compiler built with --enable-coverage= really.
> 
I only typed make, what should I have done to start the build after configuring
?

Rob


-- 


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

[Bug target/38825] missed optimization: register renaming in unrolled loop

[tim at klingt dot org]

--- Comment #3 from tim at klingt dot org  2009-01-13 15:26 ---
(In reply to comment #1)
> Try -frename-registers.

i forgot to mention: the binaries are compiled with -O3 -mfpmath=sse -msse
(4.2, 4.3 and 4.4).

-frename-registers is enabled by -O3

(In reply to comment #2)
> Note that your testcase has moved the load _mm_load_ps(in+4); before the
> store _mm_store_ps(out, result); which the compiler cannot do itself because
> they may alias.

i see ... however the generated code is the same, when using restricted
pointers to inform the compiler, that there is no aliasing problem


-- 


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

[Bug middle-end/33443] Compiler warnings in gcc sources

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2009-01-13 15:26 ---
(In reply to comment #2)
> *** Bug 38746 has been marked as a duplicate of this bug. ***

I think the Bugs in 38746 are more serious (and against the Trunk) than these
"discards qualifiers" warnings and the ever annoying "operand 1 missing mode?"
warning that are shown here.

A small cleanup and a "New code does not have warnings" rule could fix this.

Rob


-- 


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

[Bug middle-end/38786] [graphite] ICE with -floop-block in verify_ssa

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2009-01-13 15:33 ---
Subject: Bug 38786

Author: spop
Date: Tue Jan 13 15:33:13 2009
New Revision: 143341

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143341
Log:
2009-01-13  Sebastian Pop  

PR tree-optimization/38786
* gcc.dg/graphite/pr38786.c: New.
* graphite.c (expand_scalar_variables_ssa_name): New, outlined from
the SSA_NAME case of expand_scalar_variables_expr.
Set the type of an expression to the type of its assign statement.
(expand_scalar_variables_expr): Also gather the scalar computation
used to index the memory access.  Do not pass loop_p.
Fix comment.  Stop recursion on tcc_constant or tcc_declaration.
(expand_scalar_variables_stmt): Pass to expand_scalar_variables_expr
the gimple_stmt_iterator where it inserts new code.  Do not pass
loop_p.
(copy_bb_and_scalar_dependences): Do not pass loop_p.
(translate_clast): Update call to copy_bb_and_scalar_dependences.


Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr38786.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes

[jakub at gcc dot gnu dot org]

--- Comment #22 from jakub at gcc dot gnu dot org  2009-01-13 15:37 ---
Created an attachment (id=17086)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17086&action=view)
gcc44-pr38245.patch

Updated patch (tested with the new testcase on i386/x86_64 and eyeballed
for ppc{,64}, sparc{32,64}, ia64.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug target/38825] missed optimization: register renaming in unrolled loop

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-01-13 15:44 ---
-frename-registers does make a difference for me,

.L2:
movaps  %xmm0, %xmm2
movaps  %xmm0, %xmm1
addps   (%rsi,%rax), %xmm2
movaps  %xmm2, (%rdi,%rax)
addps   16(%rsi,%rax), %xmm1
movaps  %xmm1, 16(%rdi,%rax)
addq$32, %rax
cmpq%rdx, %rax
jne .L2

vs.

.L2:
movaps  %xmm0, %xmm1
addps   (%rsi,%rax), %xmm1
movaps  %xmm1, (%rdi,%rax)
movaps  %xmm0, %xmm1
addps   16(%rsi,%rax), %xmm1
movaps  %xmm1, 16(%rdi,%rax)
addq$32, %rax
cmpq%rdx, %rax
jne .L2

x86_64, -O3 -fschedule-insns [-frename-registers], with restrict added


-- 


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

[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit

[frikkie at zitera dot co dot za]

--- Comment #14 from frikkie at zitera dot co dot za  2009-01-13 15:51 
---
Created an attachment (id=17087)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17087&action=view)
GCC 4.3.2 patch for volatile bitfields

The following patches help to honour the container type of the volatile
bitfield when the GCC internal: TARGET_NARROW_VOLATILE_BITFIELD is false.

The patch is for GCC 4.3.2

Included in the tgz-file is the whole project, GCC patches and disassembly for
the application when using the original GCC 4.3.2 source and the patched
source.


-- 


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

[Bug c/27628] Incorrect memory access type used used in accessing bitfields

[frikkie at zitera dot co dot za]

--- Comment #6 from frikkie at zitera dot co dot za  2009-01-13 15:56 
---
Good day,

I've submitted patches to bug report 23623
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623) 
that corrects the behavior described in this bug report.

There are patches for GCC 4.3.2 and GCC 4.4.0.

In the archive for gcc432, the whole project is included, for easier testing by
other parties.

The project was created for and tested on the ST STR912FW44 ARM9
microprocessor.


-- 


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

[Bug java/38827] New: gcj emitting incorrect code

[tschwinge at gcc dot gnu dot org]

I originally found this problem when trying to compile a Java package written
by the Universität Stuttgart's institute IKR.  I was using Debian's gcj
package, version 4.3.2-2, but can likewise reproduce this using SVN trunk, as
well as Debian's 4.2.4-4 package.

I completely reduced the test case to the following:

public class Bug_Class
{
}

public interface Bug_Interface
{
}

public class Bug
{
public  Bug(X x)
{
set(x);
}

public void set(Bug_Interface x)
{
}
}

Directly compiling this will fail as follows:

$ ~/GCC/trunk.build.64.install/bin/gcj -c Bug.java
Bug.java: In class 'Bug':
Bug.java: In constructor '(Bug_Class)':
In file included from :3:
Bug.java:3: error: verification failed at PC=9: incompatible type on stack

gcj is able to emit a class file, but that one is considered non-verifying by
the BCEL verifier:

[...]
Pass 3b, method number 0 ['public void (Bug_Class arg1)
[Signature((TE;)V)]']:
VERIFIED_REJECTED
Constraint violated in method 'public void (Bug_Class arg1)
[Signature((TE;)V)]':
Instruction INVOKEVIRTUAL constraint violated: Expecting a 'Bug_Interface'
but found a 'Bug_Class' on the stack (which is not assignment compatible).
InstructionHandle:6: invokevirtual[182](3) 13
[...]

What Sun's javac does differently (as per class-file disassembly inspection) is
emitting a checkcast against class Bug_Interface before calling invokevirtual.


-- 
   Summary: gcj emitting incorrect code
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org


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

[Bug target/38825] missed optimization: register renaming in unrolled loop

[tim at klingt dot org]

--- Comment #5 from tim at klingt dot org  2009-01-13 16:08 ---
(In reply to comment #4)
> -frename-registers does make a difference for me,

i can reproduce it, however, -frename-registers is supposed to be enabled by
-O3:
t...@thinkpad:~/workspace/nova-server.git$ /usr/local/lib/gcc-snapshot/bin/g++
-Q -O3 --help=optimizer  |grep frename
  -frename-registers[enabled]


the resolved aliasing issue, is not taken into account, though:

.L23:
movaps  %xmm0, %xmm2
movaps  %xmm0, %xmm1
addps   (%rsi,%rax), %xmm2
movaps  %xmm2, (%rdi,%rax)
addps   16(%rsi,%rax), %xmm1
movaps  %xmm1, 16(%rdi,%rax)
addq$32, %rax
cmpq%rdx, %rax
jne .L23

vs.

.L19:
movaps  %xmm0, %xmm2
movaps  %xmm0, %xmm1
addps   (%rsi,%rax), %xmm2
addps   16(%rsi,%rax), %xmm1
movaps  %xmm2, (%rdi,%rax)
movaps  %xmm1, 16(%rdi,%rax)
addq$32, %rax
cmpq%rdx, %rax
jne .L19


-- 


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

[Bug target/38824] [4.4 regression] performance regression of sse code from 4.2/4.3

[tim at klingt dot org]

--- Comment #2 from tim at klingt dot org  2009-01-13 16:22 ---
(In reply to comment #1)
> I don't see how this changes could cause more branch misses.  If you do the
> same .palign for the 4.4 code does the regression vanish?  I would suspect
> that the loop-stream detector catches one but not the other form for some
> reason.  Maybe the Intel folks can properly analyze this - HJ?

after doing some more tests, i wouldn't think too much about the branch misses.
they seem to be quite dependent on the binary, even on linked libraries. i am
more concerned about the inner loop ...


-- 


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

[Bug c++/38828] New: g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear

[ronan dot lehy at probayes dot com]

I'm compiling the attached source and inspecting symbols in it:
  g++-4.3 -v -save-temps -Wall -Wextra -O2 -fno-inline-small-functions
mylib.cpp -c -o mylib.o
  nm mylib.o | c++filt | grep 'serialize<'

With -O2 -fno-inline-small-functions (as above), nm gives (as expected):
  W void
boost::serialization::serialize(boost::archive::xml_iarchive&,
A&, unsigned int)
  W void
boost::serialization::serialize(boost::archive::xml_iarchive&,
B&, unsigned int)
  W void
boost::serialization::serialize(boost::archive::xml_oarchive&,
A&, unsigned int)
  W void
boost::serialization::serialize(boost::archive::xml_oarchive&,
B&, unsigned int)

With just -O2, some symbols are missing:
  W void
boost::serialization::serialize(boost::archive::xml_iarchive&,
B&, unsigned int)
  W void
boost::serialization::serialize(boost::archive::xml_oarchive&,
B&, unsigned int)

The disappearing functions are explicit template instantiations, that are not
marked static, or inline. With g++-4.1 and g++-4.2, no symbols are missing.

The g++ output follows.

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O2' '-c' '-o'
'mylib.o' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1plus -E -quiet -v -D_GNU_SOURCE mylib.cpp
-D_FORTIFY_SOURCE=2 -mtune=generic -Wall -Wextra -O2 -fpch-preprocess -o
mylib.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.3
 /usr/include/c++/4.3/i486-linux-gnu
 /usr/include/c++/4.3/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.3.2/include
 /usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed
 /usr/include/i486-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O2' '-c' '-o'
'mylib.o' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1plus -fpreprocessed mylib.ii -quiet
-dumpbase mylib.cpp -mtune=generic -auxbase-strip mylib.o -O2 -Wall -Wextra
-version -fstack-protector -o mylib.s
GNU C++ (Ubuntu 4.3.2-1ubuntu11) version 4.3.2 (i486-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: dc8f858cacda993dd8f70837f0d9565d
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O2' '-c' '-o'
'mylib.o' '-shared-libgcc' '-mtune=generic'
 as -V -Qy -o mylib.o mylib.s
GNU assembler version 2.18.93 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.93.20081009
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O2' '-c' '-o'
'mylib.o' '-shared-libgcc' '-mtune=generic'


-- 
   Summary: g++ 4.3.2: -O2 without -fno-inline-small-functions makes
some template instantiations disappear
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ronan dot lehy at probayes dot com


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-01-13 16:33 ---
The problem is the following in arith.c:
  if (op == INTRINSIC_POWER && op2->ts.type != BT_INTEGER)
goto runtime;

Thus it is only run-time evaluated. gfc_arith_power deals so far only with
(numeric_type)**(integer). We need to handle (complex)**(complex)
and (real)**(real).

I think Fortran 2003 allows ** in initialization expressions (at least I could
not find anything else) and thus one needs this. See also PR 38823.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE in in   |Compile-time simplification
   |gfc_target_encode_expr  |of x**(real)  /  ICE in in
   ||gfc_target_encode_expr


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-01-13 16:35 ---
I wonder whether this should be fixed together with PR 38823.
Currently, (x)**(non-integer) is never be simplified at compile time - and the
simplification would be an obvious place to do the checking.


-- 


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

[Bug c++/38828] g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear

[ronan dot lehy at probayes dot com]

--- Comment #1 from ronan dot lehy at probayes dot com  2009-01-13 16:35 
---
Created an attachment (id=17088)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17088&action=view)
Preprocessed source


-- 


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

[Bug target/38825] missed optimization: register renaming in unrolled loop

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-01-13 16:37 ---
Yes, the alias sets are not properly transfered to RTL:

;; MEM[base: out, index: ivtmp.58] = result;

(insn 22 21 0 /usr/lib64/gcc/x86_64-suse-linux/4.4/include/xmmintrin.h:951 (set
(mem:V4SF (plus:DI (reg/v/f:DI 66 [ out ])
(reg:DI 63 [ ivtmp.58 ])) [2 S16 A128])
(reg/v:V4SF 64 [ result ])) -1 (nil))

;; result.70 = __builtin_ia32_addps (MEM[base: in, index: ivtmp.58, offset:
16], scalar);

(insn 23 22 24 /usr/lib64/gcc/x86_64-suse-linux/4.4/include/xmmintrin.h:161
(set (reg:V4SF 75)
(plus:V4SF (reg/v:V4SF 65 [ scalar ])
(mem:V4SF (plus:DI (plus:DI (reg/v/f:DI 67 [ in ])
(reg:DI 63 [ ivtmp.58 ]))
(const_int 16 [0x10])) [2 S16 A128]))) -1 (nil))

as you can see both use alias set 2.  But it should be noted that with
TARGET_MEM_REF (the MEM[...] expr) type-based aliasing is hosed (which is
unfortunately what restrict relies on).

Thus, with -fno-ivopts we can see different alias sets:

;; *(__v4sf *) out = result;

(insn 14 13 0 /usr/lib64/gcc/x86_64-suse-linux/4.4/include/xmmintrin.h:951 (set
(mem:V4SF (reg/v/f:DI 62 [ out ]) [6 S16 A128])
(reg/v:V4SF 60 [ result ])) -1 (nil))

;; result.58 = __builtin_ia32_addps (*(__v4sf *) (in + 16), scalar);

(insn 15 14 16 /usr/lib64/gcc/x86_64-suse-linux/4.4/include/xmmintrin.h:161
(set (reg:V4SF 67)
(plus:V4SF (reg/v:V4SF 61 [ scalar ])
(mem:V4SF (plus:DI (reg/v/f:DI 63 [ in ])
(const_int 16 [0x10])) [5 S16 A128]))) -1 (nil))

and re-ordering of mems!

.L2:
movaps  %xmm0, %xmm2
movaps  %xmm0, %xmm1
addps   (%rsi), %xmm2
addps   16(%rsi), %xmm1
addq$32, %rsi
movaps  %xmm2, (%rdi)
movaps  %xmm1, 16(%rdi)
addq$32, %rdi
subl$1, %edx
jne .L2


-- 


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

[Bug c++/38828] g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear

[ronan dot lehy at probayes dot com]

--- Comment #2 from ronan dot lehy at probayes dot com  2009-01-13 16:39 
---
(In reply to comment #1)
> Created an attachment (id=17088)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17088&action=view)

I had to trim a bit the source to be make the preprocessed source fit into 1000
ko. With it, the expected nm output (-O2 -fno-inline-small-functions) is:

 W void
boost::serialization::serialize(boost::archive::xml_iarchive&,
A&, unsigned int)
  W void
boost::serialization::serialize(boost::archive::xml_iarchive&,
B&, unsigned int)

And the one with missing symbols (-O2) is:
  W void
boost::serialization::serialize(boost::archive::xml_iarchive&,
B&, unsigned int)


-- 


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

[Bug c/27628] Incorrect memory access type used used in accessing bitfields

[joseph at codesourcery dot com]

--- Comment #7 from joseph at codesourcery dot com  2009-01-13 16:39 ---
Subject: Re:  Incorrect memory access type used used in accessing
 bitfields

On Tue, 13 Jan 2009, frikkie at zitera dot co dot za wrote:

> I've submitted patches to bug report 23623
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623) 
> that corrects the behavior described in this bug report.

If you wish patches submitted to receive any attention, you need to follow 
the patch submission procedures described at 
.  Closed bugs, such as the one you've 
attached the patches to, receive no attention.  If you can demonstrate 
there are problems not fixed by the patch that fixed the closed bug, you 
should open a new bug with a testcase that shows how it differs from the 
closed bug, but the patches should still go to gcc-patches as described.


-- 


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

[Bug c++/38828] g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear

[ronan dot lehy at probayes dot com]

--- Comment #3 from ronan dot lehy at probayes dot com  2009-01-13 16:42 
---
Created an attachment (id=17089)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17089&action=view)
Original source (#includes Boost headers).


-- 


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

[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name

[dodji at redhat dot com]

--- Comment #10 from dodji at gcc dot gnu dot org  2009-01-13 16:50 ---
Subject: Re:  [4.2/4.3/4.4 Regression] template parameter does
 not hide class name

jakub at gcc dot gnu dot org a écrit :
> --- Comment #9 from jakub at gcc dot gnu dot org  2009-01-12 23:00 ---
> The 4.3 version seems to be the old one, with is_* prefixes and macro, while
> trunk/4.2 are the new ones.

Oops, right. Fixing that now. Thanks.

Dodji.


-- 


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

[Bug c++/38636] [4.2/4.3/4.4 regression] ICE with broken ctor declaration

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-12-26 22:22:17 |2009-01-13 16:56:35
   date||


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

[Bug debug/37022] internal compiler error: in compute_barrier_args_size

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2009-01-13 17:18 ---
As the asserts aren't on the trunk, this isn't really a regression, we've been
emitting bogus unwind info in these cases (and many more than now) before as
well.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 regression] internal   |internal compiler error: in
   |compiler error: in  |compute_barrier_args_size
   |compute_barrier_args_size   |


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

[Bug c++/38797] [c++0x] Missing warning about type qualifiers on late function return types

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2009-01-13 17:49 ---
Closing.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/38829] New: Bogus BIND(C) error message

[burnus at gcc dot gnu dot org]

Compiling the following program gives the error:

Error: Type 'y_c' at (1) is a parameter to the BIND(C)  procedure 'wrapper' but
is not C interoperable because derived type 'ty_c' is not C interoperable

It works if one moves the TYPE declaration up. It also works with the
SUBROUTINE is not BIND(C).

TODO:
- Move check from decl.c to resolve.c
- Change "parameter" to (dummy/formal) "argument" as otherwise it can be
confused with the PARAMETER attribute.

Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5392e4c270d4f3c7
Where it was reported by Steven Correll.


MODULE mExample
CONTAINS
  SUBROUTINE wrapper(y_c) bind(c)
  USE iso_c_binding
  type, bind(c) :: ty_c
type(c_ptr) :: y_cptr
Integer(c_int) ny
  end type
  type(ty_c) :: y_c
  END SUBROUTINE
END MODULE


-- 
   Summary: Bogus BIND(C) error message
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  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=38829

[Bug rtl-optimization/38774] [4.4 Regression] ice in df_refs_verify, at df-scan.c:4307

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-01-13 18:07 ---
Simplified testcase:
extern int bar (void);
volatile int g;

int
foo (void)
{
  int a = 1 >= bar ();
  if ((1 > 9223372036854775807LL - a && 1 - a ? : 1 + a) & 1)
return g;
  return 0;
}


-- 


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

[Bug c++/38795] [4.3/4.4 regression] ICE with reinterpret_cast and variadic templates

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-01-13 18:12 ---
Subject: Bug 38795

Author: jakub
Date: Tue Jan 13 18:11:50 2009
New Revision: 143351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143351
Log:
PR c++/38795
* tree.c (cp_walk_subtrees): Handle REINTERPRET_CAST_EXPR,
STATIC_CAST_EXPR, CONST_CAST_EXPR and DYNAMIC_CAST_EXPR the same
as CAST_EXPR.

* g++.dg/cpp0x/pr38795.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr38795.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/38795] [4.3 regression] ICE with reinterpret_cast and variadic templates

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-01-13 18:12 ---
Fixed on the trunk so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with
   |with reinterpret_cast and   |reinterpret_cast and
   |variadic templates  |variadic templates


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

[Bug fortran/38830] New: Add "Variable Format Expression" I/O Capability

[tom dot browder at gmail dot com]

I would like to see a new gfortran extension added so that the "Variable Format
Expression" I/O capability will be available with gfortran as it is on many
commercial compilers.  Such a capability was once proposed as an addition to
the Fortran 95 standard but was not accepted for some reason.


-- 
   Summary: Add "Variable Format Expression" I/O Capability
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot browder at gmail dot com


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

[Bug tree-optimization/38826] points-to result wrong for reads from call-clobbered vars

[dberlin at dberlin dot org]

--- Comment #3 from dberlin at gcc dot gnu dot org  2009-01-13 18:42 ---
Subject: Re:  points-to result wrong for reads 
from call-clobbered vars

Interesting.
I have emailed some others for their thoughts.

One way to eliminate this bug would be to mark the entire structure as
indirect nodes due to &s when we initialize the offline problem.
You would also have to do the same if you see &s.p.

The problem of course, is that i think our C++ implementation still
plays games with subtracting offsets, so for C++, you'd have to mark
the entire structure full of variables indirect when you see address
taking of any member :(

Anyway, give me a short time to wait for responses and see if there is
a good way out of this.

On Tue, Jan 13, 2009 at 7:34 AM, rguenth at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-13 12:34 
> ---
> It is interesting to see how taking the address of &s.q makes it a pointer
> variable.  The fundamental issue seems to be that eliminating non-pointers
> and their edges conflicts with field-sensitive analysis.
>
> Consider
>
> struct S { int *p; int *q; };
>
> void foo (struct S **);
>
> int *bar (int b)
> {
>  struct S s;
>  struct S *p = &s;
>  foo (&p);
>  return s.q;
> }
>
> to see that just generating extra ADDRESSOF constraints for call arguments
> will not fix the issue.
>
> Not only we will need to avoid eliminating non-pointers / edges if any of a
> variables sub-field has got a proper pointer label, unifying them (they
> still have pointer label 0) is also wrong.
>
> Danny, any idea where/how to fix this?
>
>
> --
>
> rguenth at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> 
> CC||dberlin at gcc dot gnu dot
>   ||org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38826
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

Re: [Bug java/38827] New: gcj emitting incorrect code

[Andrew Thomas Pinski]

On Jan 13, 2009, at 8:03 AM, "tschwinge at gcc dot gnu dot org" > wrote:


I originally found this problem when trying to compile a Java  
package written
by the Universität Stuttgart's institute IKR.  I was using Debian's  
gcj
package, version 4.3.2-2, but can likewise reproduce this using SVN  
trunk, as

well as Debian's 4.2.4-4 package.

I completely reduced the test case to the following:

   public class Bug_Class
   {
   }

   public interface Bug_Interface
   {
   }

   public class Bug
   {
   public  Bug(X x)
   {
   set(x);
   }

   public void set(Bug_Interface x)
   {
   }
   }

Directly compiling this will fail as follows:

   $ ~/GCC/trunk.build.64.install/bin/gcj -c Bug.java
   Bug.java: In class 'Bug':
   Bug.java: In constructor '(Bug_Class)':
   In file included from :3:
   Bug.java:3: error: verification failed at PC=9: incompatible type  
on stack


gcj is able to emit a class file, but that one is considered non- 
verifying by

the BCEL verifier:


This sounds like a bug in the eclispe source to bytecode compiler  
which gcj uses now.








   [...]
   Pass 3b, method number 0 ['public void (Bug_Class arg1)
[Signature((TE;)V)]']:
   VERIFIED_REJECTED
   Constraint violated in method 'public void (Bug_Class arg1)
[Signature((TE;)V)]':
   Instruction INVOKEVIRTUAL constraint violated: Expecting a  
'Bug_Interface'
but found a 'Bug_Class' on the stack (which is not assignment  
compatible).

   InstructionHandle:6: invokevirtual[182](3) 13
   [...]

What Sun's javac does differently (as per class-file disassembly  
inspection) is
emitting a checkcast against class Bug_Interface before calling  
invokevirtual.



--
  Summary: gcj emitting incorrect code
  Product: gcc
  Version: 4.3.2
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: java
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: tschwinge at gcc dot gnu dot org


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

[Bug java/38827] gcj emitting incorrect code

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-13 19:22 ---
Subject: Re:   New: gcj emitting incorrect code



On Jan 13, 2009, at 8:03 AM, "tschwinge at gcc dot gnu dot org"
 wrote:

> I originally found this problem when trying to compile a Java  
> package written
> by the Universität Stuttgart's institute IKR.  I was using Debian's  
> gcj
> package, version 4.3.2-2, but can likewise reproduce this using SVN  
> trunk, as
> well as Debian's 4.2.4-4 package.
>
> I completely reduced the test case to the following:
>
>public class Bug_Class
>{
>}
>
>public interface Bug_Interface
>{
>}
>
>public class Bug
>{
>public  Bug(X x)
>{
>set(x);
>}
>
>public void set(Bug_Interface x)
>{
>}
>}
>
> Directly compiling this will fail as follows:
>
>$ ~/GCC/trunk.build.64.install/bin/gcj -c Bug.java
>Bug.java: In class 'Bug':
>Bug.java: In constructor '(Bug_Class)':
>In file included from :3:
>Bug.java:3: error: verification failed at PC=9: incompatible type  
> on stack
>
> gcj is able to emit a class file, but that one is considered non- 
> verifying by
> the BCEL verifier:

This sounds like a bug in the eclispe source to bytecode compiler  
which gcj uses now.




>
>
>[...]
>Pass 3b, method number 0 ['public void (Bug_Class arg1)
> [Signature((TE;)V)]']:
>VERIFIED_REJECTED
>Constraint violated in method 'public void (Bug_Class arg1)
> [Signature((TE;)V)]':
>Instruction INVOKEVIRTUAL constraint violated: Expecting a  
> 'Bug_Interface'
> but found a 'Bug_Class' on the stack (which is not assignment  
> compatible).
>InstructionHandle:6: invokevirtual[182](3) 13
>[...]
>
> What Sun's javac does differently (as per class-file disassembly  
> inspection) is
> emitting a checkcast against class Bug_Interface before calling  
> invokevirtual.
>
>
> -- 
>   Summary: gcj emitting incorrect code
>   Product: gcc
>   Version: 4.3.2
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: java
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: tschwinge at gcc dot gnu dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38827
>


-- 


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

[Bug fortran/29600] MINLOC, MAXLOC and SHAPE take an optional KIND argument

[dfranke at gcc dot gnu dot org]

-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-20 09:50:52 |2009-01-13 19:24:06
   date||


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #5 from sgk at troutmask dot apl dot washington dot edu  
2009-01-13 19:43 ---
Subject: Re:   New: Diagnose and treat (-2.0)**2.0 properly

On Tue, Jan 13, 2009 at 11:08:40AM -, burnus at gcc dot gnu dot org wrote:
> 
> Fortran 2003 in the second sentence of the second paragraph of "7.1.8
> Evaluation of Operations":
> 
>   "Raising a negative-valued primary of type real to a real power is
>prohibitted."
> 
> The question is whether one needs to reject it completely or only with
> -std=f95. Steve (see thread) thinks the constant folding gets it wrong
> (-> gives "4.0").

For constant folding, it will be rejected because it can be detected
at compile time.

> Current results:
> - Runtime and compile time evaluation (ifort, gfortran, g95):
>   -2.0**2.0 = 4.0
>   -2.0**1.9 = NaN

I believe you're missing ( ) around -2.0 because ** has higher
precedence than unary minus.

> - Mathematica:
>   -2^2 = 4, -2.0^2.0 = -4.0
>   2.0^1.9 = -3.73213

Try putting ( ) around -2 in the above.


-- 


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #6 from sgk at troutmask dot apl dot washington dot edu  
2009-01-13 19:44 ---
Subject: Re:  Diagnose and treat (-2.0)**2.0 properly

On Tue, Jan 13, 2009 at 11:28:05AM -, pinskia at gmail dot com wrote:
> 
> -2.0^1.9 will be a complex number.  Maybe we can define it as taking  
> the real part. I don't know if that is better than generating a nan  
> here.
> 

The ** operator has higher precedence than unary minus.


-- 


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

[Bug fortran/38152] ICE for procedure pointer assignment

[domob at gcc dot gnu dot org]

--- Comment #7 from domob at gcc dot gnu dot org  2009-01-13 19:47 ---
Created an attachment (id=17090)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17090&action=view)
Another test case

This seems to be yet another test triggering this ICE.


-- 


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

Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[Sebastian Pop]

Hi,

I compiled BLAS and LAPACK with the gfortran compiler of the graphite
branch such that I could test the CP2K benchmark.  On my laptop, that
is an amd64-linux, "make test" passes with the gfortran compiler from
the graphite branch.  However I'm not able to run the test that you
reported failing:

./cp2k.sopt canonical.inp
 CP2K: The specified file canonical.inp can not be opened, it does not exist.
STOP 1

Could you tell me where I can find the canonical.inp file, or how to
reproduce the fail?

Thanks,
Sebastian

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[sebpop at gmail dot com]

--- Comment #28 from sebpop at gmail dot com  2009-01-13 19:52 ---
Subject: Re:  [graphite] several ICEs with CP2K (summary)

Hi,

I compiled BLAS and LAPACK with the gfortran compiler of the graphite
branch such that I could test the CP2K benchmark.  On my laptop, that
is an amd64-linux, "make test" passes with the gfortran compiler from
the graphite branch.  However I'm not able to run the test that you
reported failing:

./cp2k.sopt canonical.inp
 CP2K: The specified file canonical.inp can not be opened, it does not exist.
STOP 1

Could you tell me where I can find the canonical.inp file, or how to
reproduce the fail?

Thanks,
Sebastian


-- 


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #7 from sgk at troutmask dot apl dot washington dot edu  
2009-01-13 19:55 ---
Subject: Re:  Diagnose and treat (-2.0)**2.0 properly

On Tue, Jan 13, 2009 at 11:30:40AM -, dominiq at lps dot ens dot fr wrote:
> 
> 
> --- Comment #2 from dominiq at lps dot ens dot fr  2009-01-13 11:30 
> ---
> > The question is whether one needs to reject it completely or only with 
> > -std=f95.
> 
> I vote for "only with -std=f95" with may be a warning otherwise.

It will be a compile time error during constant folding.  The compiler
can detect (-2.)**some_real_entity.

> I think it is a legitimate optimization to replace A**B by A**I (with I=B)
> when B is known to be an integer, hence to accept negative values for A
> in this case.

I have no plans to change this optimization.

> I find upsetting to have to cheat with variables when constant folding
> does not give the same result as a similar code with variables.

In the general case,

function my_pow(x,y)
  real my_pow
  real x, y
  my_pow = x**y
end function my_pow

we have

my_pow (real(kind=4) & x, real(kind=4) & y)
{
  real(kind=4) __result_my_pow;

  {
real(kind=4) D.1525;

D.1525 = *x;
__result_my_pow = __builtin_powf (D.1525, *y);
  }
  return __result_my_pow;
}

I intend to change this, conditional on perhaps -ffast-math and/or -pedantic,
to

D.1525 = *x;
if (D.1525 < 0)
   runtime_error( )
else
   __result_my_pow = __builtin_powf (D.1525, *y);

gfortran's default behavior in this instance should be conformance to
the Standards. 


-- 


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

[Bug fortran/38831] New: ICE in bitmap_first_set_bit for procptr and C binding

[domob at gcc dot gnu dot org]

The attached program gives an ICE:

bash-3.2# gfortran-dev reduced.f03 
reduced.f03: In function 'mysql_library_shutdown':
reduced.f03:24: internal compiler error: in bitmap_first_set_bit, at
bitmap.c:770
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

when compiled with gfortran 4.4 trunk.  Adding a "=> NULL()" to the procptr
declaration makes it compile, and commenting out any of the three lines of code
in the function bodies gives the ICE of PR 38152 instead.


-- 
   Summary: ICE in bitmap_first_set_bit for procptr and C binding
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #8 from sgk at troutmask dot apl dot washington dot edu  
2009-01-13 19:58 ---
Subject: Re:  Diagnose and treat (-2.0)**2.0 properly

On Tue, Jan 13, 2009 at 11:37:25AM -, dominiq at lps dot ens dot fr wrote:
> 
> 
> --- Comment #3 from dominiq at lps dot ens dot fr  2009-01-13 11:37 
> ---
> > - Mathematica:
> >   -2^2 = 4, -2.0^2.0 = -4.0
> >   2.0^1.9 = -3.73213  <--- probably -2.0^1.9!
> 
> Apparently Mathematica parse "-2.0^a" as "-(2.0^a)". (-2.0)^1.9 gives 
> "3.54947-
> 1.15329 I". I don't know if the fortran standard says how "-a**b" should be
> parsed (nor have the time right now to decipher the legalese).
> 

See Note 7.30 in the Fortran 2003 Standard.

-a**b is parsed as if it were written as -(a**b).


-- 


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[mikael at gcc dot gnu dot org]

--- Comment #9 from mikael at gcc dot gnu dot org  2009-01-13 20:08 ---
(In reply to comment #2)
> I think it is
> a legitimate optimization to replace A**B by A**I (with I=B) when B is known 
> to
> be an integer, hence to accept negative values for A in this case. 
You can use A**I directly if you want to accept negative values.


-- 


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

[Bug fortran/38831] ICE in bitmap_first_set_bit for procptr and C binding

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2009-01-13 19:56 ---
Created an attachment (id=17091)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17091&action=view)
Test case

This is the program ICE'ing


-- 


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

[Bug fortran/38830] Add "Variable Format Expression" I/O Capability

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-01-13 20:31 ---
Needed for legacy code; internal I/O allows the same (and more powerful) albeit
a bit lengthier.

Cf. http://gcc.gnu.org/ml/fortran/2009-01/msg00167.html
and
http://coding.derkeiler.com/Archive/Fortran/comp.lang.fortran/2008-02/msg00404.html

Proposal:http://www.j3-fortran.org/doc/year/97/97-109.txt (Dedo)
Old version: http://www.j3-fortran.org/doc/year/96/96-071.asc (Dedo)
Simplified proposal: http://www.j3-fortran.org/doc/year/96/96-083.txt (HP)


Other compilers:

http://h21007.www2.hp.com/portal/download/files/unprot/Fortran/docs/lrm/lrm0441.htm

http://www.intel.com/software/products/compilers/docs/flin/main_for/lref_for/source_files/pghvarfm.htm

http://publib.boulder.ibm.com/infocenter/lnxpcomp/v101v121/topic/com.ibm.xlf121.linux.doc/language_ref/format.html

http://docs.sun.com/app/docs/doc/819-5263/aevnt


-- 


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

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[jv244 at cam dot ac dot uk]

--- Comment #29 from jv244 at cam dot ac dot uk  2009-01-13 20:33 ---
(In reply to comment #28)
> the graphite branch.  However I'm not able to run the test that you
> reported failing:
> 
> ./cp2k.sopt canonical.inp
>  CP2K: The specified file canonical.inp can not be opened, it does not exist.
> STOP 1
> 
> Could you tell me where I can find the canonical.inp file, or how to
> reproduce the fail?

you'll have to untar the additional_test.tgz which is attached here to the PR:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=17062


-- 


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

[Bug ada/38832] New: Main program runs fine but hangs on exit when linked with Ada shared lib

[oliver dot kellogg at eads dot com]

Running the test program from the attached tarfile
produces the expected output:

shared_lib/testuser> export LD_LIBRARY_PATH=../installed_lib
shared_lib/testuser> ./appl_main
Here is appl_main, now calling Pkg.Proc ...
Pkg.Proc: X is 2
Here is appl_main, back from calling Pkg.Proc: end of program.

However, the program hangs after the last output, i.e. does not relinquish
control back to the command line.

I tried this with FSF GCC versions 4.2.1 and svn 4.4 trunk
as well as with GNATGPL-2007 and 2008. Same behavior with all.


-- 
   Summary: Main program runs fine but hangs on exit when linked
with Ada shared lib
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliver dot kellogg at eads dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug java/38827] gcj emitting incorrect code

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-13 20:37 ---
Can you see if the normal eclipse compiler that comes with the eclipse IDE has
the same issue, and maybe report it to them if so?

GCJ no longer includes a source compiler, we use the eclipse compiler (this was
done in 4.3 and above and also in Debian's 4.2).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug ada/38832] Main program runs fine but hangs on exit when linked with Ada shared lib

[oliver dot kellogg at eads dot com]

--- Comment #1 from oliver dot kellogg at eads dot com  2009-01-13 20:39 
---
Created an attachment (id=17092)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17092&action=view)
source code and makefiles for the test application

Usage:
$ tar xvzf gnat-shared_lib.tgz
$ cd shared_lib
$ make   # will produce ./installed_lib/libadasharedlib.so et al.
$ export LD_LIBRARY_PATH=$PWD/installed_lib
$ cd testuser && make   # will produce test program, appl_main
$ ./appl_main


-- 


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

[Bug rtl-optimization/38774] [4.4 Regression] ice in df_refs_verify, at df-scan.c:4307

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-01-13 20:39 ---
The single CC user is modified, then those changes are reverted, but
unfortunately they aren't reverted by putting back the old content, but instead
tweaking the new comparison with PUT_CODE.
  SUBST (*cc_use, gen_rtx_fmt_ee (new_code, GET_MODE (*cc_use),
  dest, const0_rtx));   
  other_changed = 1;
...
  if ((recog_for_combine (&pat, other_insn, ¬e) < 0
   && ! check_asm_operands (pat)))
{
  PUT_CODE (*cc_use, old_code);
  other_changed = 0;

We should insert put there the old *cc_use rtx.  I'll test a patch.


-- 


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

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-01-13 20:39 ---
>Other circumstances include "co-processing". You want to compile for your
favorite hardware, Xbox or PSP

HEHE, funny you mentioned the PSP, you know that I work for Sony on their GCC
for PS3 compilers.  So I cross compile all the time really.  Anyways most of
this bug report is not really the issue here.


-- 


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

[Bug c++/38828] g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-13 20:43 ---
serialize with an empty body is a pure function so it will be can be optimized
away without any effects.  I don't see the issue here really.


-- 


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

[Bug c++/38828] g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-01-13 20:46 ---
Also since it is not explicitly instatinated, the template does not need to be
in the object file really.

Can you give a better example of why do you think this is wrong besides a nm
testcase?  It might be due to that you are defining the template specialization
in the other TUs in which case, the code is invalid.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/38830] Add "Variable Format Expression" I/O Capability

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2009-01-13 20:46 ---
This is a dup of PR 20618, which was closed as WONTFIX at the time.

The semantics of variable formats are very tricky (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20618#c1 ),
so this is hard to get right.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org


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

[Bug other/38805] sed Unterminated `s' command

[thomas dot jourdan at gmail dot com]

--- Comment #5 from thomas dot jourdan at gmail dot com  2009-01-13 20:50 
---
Created an attachment (id=17093)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17093&action=view)
Configure and build log

This patch contains the full build log of the cross tool chain.


-- 


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

[Bug rtl-optimization/38774] [4.4 Regression] ice in df_refs_verify, at df-scan.c:4307

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-01-13 20:57 ---
Created an attachment (id=17094)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17094&action=view)
gcc44-pr38774.patch

Patch I'm going to bootstrap/regtest.  Fixes the testcase on both i686-linux
and x86_64-linux.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|zadeck at naturalbridge dot |jakub at gcc dot gnu dot org
   |com |


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

[Bug rtl-optimization/38774] [4.4 Regression] ice in df_refs_verify, at df-scan.c:4307

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-01-13 20:59 ---
(In reply to comment #6)
> Created an attachment (id=17094)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17094&action=view) [edit]
> gcc44-pr38774.patch
> 
> Patch I'm going to bootstrap/regtest.  Fixes the testcase on both i686-linux
> and x86_64-linux.

Do you think the testcase could go into gcc.dg/torture/ instead of just gcc.dg
and remove the -O2 part of dg-options ?


-- 


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