[Bug bootstrap/44229] [4.6 Regression] 1 new GCC h...@159608 regression

[iains at gcc dot gnu dot org]

--- Comment #3 from iains at gcc dot gnu dot org  2010-05-25 07:33 ---
powerpc64-apple-darwin9 does *not* exhibit this ...


-- 


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

[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm

[iains at gcc dot gnu dot org]

--- Comment #7 from iains at gcc dot gnu dot org  2010-05-25 07:38 ---
(In reply to comment #4)
> (In reply to comment #3)
> > most likely this is a duplicate of:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229

> 1. I see the failure on both BE (sparc64) and LE (armv5tel).
> 2. Both BE (powerpc64-linux) and LE (x86) don't see the failure.

No failure on powerpc64-apple-darwin9 either.


-- 


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

[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-05-25 07:57 ---
If cp-demangle.c fails to compile even with -fcompare-debug switch added,
please
attach preprocessed source for it from sparc64 and/or arm and mention the exact
command line switches used to compile it, so it can be reproduced with a
cross-compiler.  Thanks.


-- 


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

[Bug middle-end/28685] Multiple comparisons are not simplified

[rguenther at suse dot de]

--- Comment #14 from rguenther at suse dot de  2010-05-25 08:11 ---
Subject: Re:  Multiple comparisons are not simplified

On Mon, 24 May 2010, sandra at codesourcery dot com wrote:

> --- Comment #13 from sandra at codesourcery dot com  2010-05-24 13:21 
> ---
> I'm working on a patch that fixes the test case in comment #5 (originally 
> filed
> as PR 39874) and some other test cases by improving the comparison combination
> logic in both tree-ssa-ifcombine and tree-ssa-reassoc.
> 
> The test case in comment #4 is a somewhat different problem -- maybe it is a
> VRP failure?  The problem is figuring out the right place to attempt to 
> combine
> the comparisons

In this case it is probably phiopt that could recognize this (though
it does not do the kind of transformation).  It could transform

:
  eq_5 = a_2(D) == b_3(D);
  if (a_2(D) < b_3(D))
goto ;
  else
goto ;

:

:
  # eq_1 = PHI <1(2), eq_5(3)>
  return eq_1;

to

:
  if (a_2(D) <= b_3(D))
goto ;
  else
goto ;

:

:
  # eq_1 = PHI <1(2), 0(3)>
  return eq_1;

and eventually further if-convert that.

Richard.


-- 


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[reichelt at gcc dot gnu dot org]

--- Comment #16 from reichelt at gcc dot gnu dot org  2010-05-25 08:41 
---
*** Bug 44264 has been marked as a duplicate of this bug. ***


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


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

[Bug lto/44264] [4.5 regression] ICE with virtual functions

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2010-05-25 08:41 
---
> This sounds like the same as PR 44256 which was just fixed today.

I guess, you're right. The bug disappeared.


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


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure

[iains at gcc dot gnu dot org]

--- Comment #6 from iains at gcc dot gnu dot org  2010-05-25 09:11 ---
Subject: Bug 44140

Author: iains
Date: Tue May 25 09:10:52 2010
New Revision: 159812

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

PR ObjC/44140
* objc.dg/torture/tls/thr-init-3.m: XFAIL lto/whopr for all.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/objc.dg/torture/tls/thr-init-3.m


-- 


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

[Bug target/43610] [4.5/4.6 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison

[bonzini at gcc dot gnu dot org]

--- Comment #12 from bonzini at gnu dot org  2010-05-25 09:19 ---
Subject: Bug 43610

Author: bonzini
Date: Tue May 25 09:19:37 2010
New Revision: 159813

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159813
Log:
2010-05-09  Paolo Bonzini  

PR target/43610
* optabs.c (prepare_float_lib_cmp): Allow reversing the comparison
even if !FLOAT_LIB_COMPARE_RETURNS_BOOL.  Always compute true_rtx and
false_rtx.  Use false_rtx to compute the correct *ptest for reversed
comparisons for which !FLOAT_LIB_COMPARE_RETURNS_BOOL.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c


-- 


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

[Bug objc/44140] ObjC lto/whopr fails

[iains at gcc dot gnu dot org]

--- Comment #7 from iains at gcc dot gnu dot org  2010-05-25 09:22 ---
This bug has nothing to do with the TLS check, so renaming
A non-tls testcase exhibiting the same fail is shown as comment #5


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|objc.dg/torture/tls/thr-|ObjC lto/whopr fails
   |init-3.m failure|


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

[Bug c++/18249] C++ parser i18n problems

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug c++/44267] SFINAE does not handle down static_cast over virtual inheritance

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-05-25 09:28 
---
For the record, both Intel and Comeau accept this. Let's CC Jason... 


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
Summary|SFINAE does not handle down |SFINAE does not handle down
   |static_cast over virtual|static_cast over virtual
   |inheritance |inheritance


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #25 from iains at gcc dot gnu dot org  2010-05-25 09:38 ---
#24 works for me also on powerpc-apple-darwin9 and powerpc64-apple-darwin9.


-- 


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

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-05-25 09:50 ---
CONFIRM
(No regression: GCC 4.1/4.2/4.3 reject the code ["names" invalid in expression]
while 4.4/4.5/4.6 show either the link error or ICE. Other compilers simply
work.)

One has the local parameter:
CHARACTER(*), PARAMETER :: names(3) = ...

And the characteristics of the result variable
INTEGER, INTENT(IN) :: i
CHARACTER(LEN_TRIM(names(i))) :: s
which depend on the argument. (While "len(names(i))" is constant,
"len_trim(names(i))"  is not.)

Thus, I see two possibilities: Mark the return length (in .MOD) as unknown
(which g95 and NAG f95 seemingly do) - or to properly handle the PARAMETER.

Looking at gfortran's .mod file, one finds:
 4 'names' '' 'names' 6 ((PARAMETER UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN ...
Thus, the symbol is already saved.

 * * *

Variant: If one adds a
  subroutine test()
print *, get(1)
  end subroutine test
in the module itself, one gets an ICE:

foo.f90:18:0: internal compiler error: in gfc_generate_function_code, at
fortran/trans-decl.c:4378


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, rejects-
   ||valid
   Last reconfirmed|-00-00 00:00:00 |2010-05-25 09:50:41
   date||


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

[Bug libstdc++/44268] New: abi docs say that hppa-linux defaults to libgcc_s.so.2

[caolanm at redhat dot com]

http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

says "gcc-3.4.x, gcc-4.[0-5].x: on m68k-linux and hppa-linux this is either
libgcc_s.so.1 (when configuring --with-sjlj-exceptions) or libgcc_s.so.2. For
all others, this is libgcc_s.so.1."

But I see libgcc_s.so.4 on hppa not libgcc_s.so.2. Patch attached to change
docs


-- 
   Summary: abi docs say that hppa-linux defaults to libgcc_s.so.2
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: caolanm at redhat dot com


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

[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2

[caolanm at redhat dot com]

--- Comment #1 from caolanm at redhat dot com  2010-05-25 10:34 ---
Created an attachment (id=20740)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20740&action=view)
update docs


-- 


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

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

[jakub at gcc dot gnu dot org]

--- Comment #28 from jakub at gcc dot gnu dot org  2010-05-25 10:39 ---
Created an attachment (id=20741)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20741&action=view)
gcc46-pr41371.patch

Another small optimization.  At least on this testcase in 80% the s1node and
s2var->var_part[0].loc_chain chains contain the same locations in the same
order.  So, if we avoid calling find_loc_in_1pdv in that case and only start
calling it when they differ, the testcase can be speeded up slightly.
With --enable-checking=release cc1plus the difference is:
real4m52.484s
user4m51.991s
sys 0m0.446s

to:

real3m38.218s
user3m37.641s
sys 0m0.383s

I'm going to bootstrap/regtest it now with additional statistics gathering on
how many find_loc_in_1pdv calls it can avoid.


-- 


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

[Bug middle-end/44203] [4.6 regression] New prefetch test failures

[krebbel at gcc dot gnu dot org]

--- Comment #4 from krebbel at gcc dot gnu dot org  2010-05-25 11:18 ---
Subject: Bug 44203

Author: krebbel
Date: Tue May 25 11:18:07 2010
New Revision: 159816

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159816
Log:
2010-05-25  Christian Borntraeger  

PR 44203
* tree-ssa-loop-prefetch.c: Fix logic for step calculation to
match the original (and intended) behaviour before r159557.  This
changeset changed a=a+b*c to a=(a+b)*b which was obviously wrong
in two ways.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-loop-prefetch.c


-- 


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

[Bug c++/18249] C++ parser i18n problems

[amylaar at gcc dot gnu dot org]

--- Comment #4 from amylaar at gcc dot gnu dot org  2010-05-25 12:09 ---
(In reply to comment #1)
> Subject: Bug 18249
> 
> Author: pzhao
> Date: Tue May 25 06:26:07 2010
> New Revision: 159808
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159808
> Log:
> 2010-05-25  Shujing Zhao  
> 
> PR c++/18249
> * parser.c: Remove inclusion of dyn-string.h.
> (non_integral_constant): New enum.
> (name_lookup_error): New enum.
> (required_token): New enum.
> (cp_parser_required_error): New function.
> (cp_parser_require): Change the type of variable token_desc to
> required_token and use cp_parser_required_error.
> (cp_parser_require_keyword): Likewise.
> (cp_parser_error): Use gmsgid as parameter.
> (cp_parser_name_lookup_error): Change the type of variable desired to
> name_lookup_error and put the diagnostic in the full sentences. Change
> caller.
> (cp_parser_non_integral_constant_expression): Change the type of the
> variable thing to non_integral_constant and put the diagnostics in
> full sentences. Change caller.
> 
> Modified:
> trunk/gcc/cp/ChangeLog
> trunk/gcc/cp/parser.c
> 

This broke bootstrap on i686-pc-linux-gnu:

/user/inria/fsf/bld-20100525/./prev-gcc/xgcc
-B/user/inria/fsf/bld-20100525/./prev-gcc/ -B/user/inria/i686-pc-linux-gnu/bin/
-B/user/inria/i686-pc-linux-gnu/bin/ -B/user/inria/i686-pc-linux-gnu/lib/
-isystem /user/inria/i686-pc-linux-gnu/include -isystem
/user/inria/i686-pc-linux-gnu/sys-include-c  -g -O2 -fomit-frame-pointer
-gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition
-Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -Icp -I../../gcc/gcc
-I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
 -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber  -DCLOOG_PPL_BACKEND  -I/usr/include/libelf 
../../gcc/gcc/cp/parser.c -o cp/parser.o
../../gcc/gcc/cp/parser.c: In function ‘cp_parser_unary_expression’:
../../gcc/gcc/cp/parser.c:5898:7: error: enum conversion in initialization is
invalid in C++ [-Werror=c++-compat]
../../gcc/gcc/cp/parser.c: In function ‘cp_parser_asm_definition’:
../../gcc/gcc/cp/parser.c:13478:3: error: enum conversion in initialization is
invalid in C++ [-Werror=c++-compat]
cc1: all warnings being treated as errors


-- 


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

[Bug target/37750] a lot of crashes with tree optimizations on mingw

[dbkr at mxtelecom dot com]

--- Comment #13 from dbkr at mxtelecom dot com  2010-05-25 12:09 ---
I've just run into this problem too with MinGW's packaged GCC 4.4.0. It was
working fine for some time but recently started crashing when both libevent and
the C++ program that libevent was calling back into were both compiled at at
least -O1. This causes libevent to use the edi register whose value is
corrupted (set to null, actually) by a callback into our C++ program.

The C++ app seems to use the edi register at any optimisation level and in any
case seems to push it onto the stack and pop it off at the end of the callback,
but some kind of stack corruption goes on within the callback that means the
value popped off the stack at the end is zero when the app is compiled at -O1.

Compiling the app at -O0 or at -O1 with -fno-dce prevents the crash, although
compiling with -O2 -fno-dce causes the same crash.


-- 

dbkr at mxtelecom dot com changed:

   What|Removed |Added

 CC||dbkr at mxtelecom dot com


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

[Bug c++/18249] C++ parser i18n problems

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-05-25 12:22 ---
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01837.html


-- 


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

[Bug web/44269] New: Search for PR number in mailing lists fails

[amylaar at gcc dot gnu dot org]

Searching for 18249 or PR18249 in the web archive of the gcc-patches mailing
list fails, even though there are postings with PR18249 in the subject.


-- 
   Summary: Search for PR number in mailing lists fails
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
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=44269

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[iains at gcc dot gnu dot org]

--- Comment #31 from iains at gcc dot gnu dot org  2010-05-25 12:51 ---
please can we revert the changes of comment #11?

They did not solve the problem and AFAICT they are wrong and break bootstrap on
x86_64-apple-darwin10 if I correct an error in the t-makefile fragments.  

after that, surely this bug can now be closed?


-- 


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

[Bug c/44270] New: Bootstrap comparison failure in snapshot of 05/22/2010

[michael dot a dot richmond at nasa dot gov]

When I attempt to compile the snapshot of 05/22/2010 I get the following
messages:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
libiberty/cp-demangle.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/mrichmon/gcc-4.6-20100522/g95'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/mrichmon/gcc-4.6-20100522/g95'
make: *** [all] Error 2
Error running make


-- 
   Summary: Bootstrap comparison failure in snapshot of 05/22/2010
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov
 GCC build triplet: sparc-unknown-linux-gnu
  GCC host triplet: sparc-unknown-linux-gnu
GCC target triplet: sparc-unknown-linux-gnu


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

[Bug c/44270] Bootstrap comparison failure in snapshot of 05/22/2010

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-05-25 13:27 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-05-25 13:27 ---
*** Bug 44270 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||michael dot a dot richmond
   ||at nasa dot gov


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

[Bug lto/43898] -flto -g: ICE in dwarf2out_finish, at dwarf2out.c:21433

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-05-25 13:40 ---
Re-confirmed.  It's not some decl/type context that is missing, maybe some
C++ debug hook that needs to be emulated.

Not working on this at the moment.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/44266] stack frame lacks parameter save area

[amodra at gmail dot com]

--- Comment #1 from amodra at gmail dot com  2010-05-25 13:42 ---
Created an attachment (id=20742)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20742&action=view)
fairly obvious fix


-- 


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

[Bug target/44266] stack frame lacks parameter save area

[amodra at gmail dot com]

--- Comment #2 from amodra at gmail dot com  2010-05-25 13:45 ---
Created an attachment (id=20743)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20743&action=view)
alternate fix using emit_library_call machinery

this one hasn't finished bootstrapping yet


-- 


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

[Bug debug/43260] Java static class members lack DWARF location info

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-05-25 13:51 ---
Created an attachment (id=20744)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20744&action=view)
gcc46-pr43260.patch

Untested patch that solves it similarly to how C++ FE does this.


-- 


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

--- Comment #20 from rguenth at gcc dot gnu dot org  2010-05-25 13:56 
---
-fsched2-use-superblocks also fixes it.

-fdbg-cnt=sched_region:65 is broken, -fdbg-cnt=sched_region:64 works for
a simplified testcase tail:

int bmi_get(const int* id)
{
  if (*id != 42)
__builtin_abort();

  return 0;
}

int main()
{
  int id = 42;

  typedef boost::function func_t;

  func_t f = boost::bind(&bmi_get, &id);
  func_t g = f;
  g();

  return 0;
}

Assembler difference:

--- /tmp/gtest.s.ok 2010-05-25 15:51:19.0 +0200
+++ /tmp/gtest.s.broken 2010-05-25 15:51:30.0 +0200
@@ -825,21 +825,21 @@
call_ZN5boost6detail8function16has_empty_targetEz
testb   %al, %al
jne .L93
+   movq112(%rsp), %rdx
leaq96(%rsp), %rbx
-   movq$_Z7bmi_getPKi, 104(%rsp)
-   movq%rbp, 16(%rbx)
movl   
$_ZZN5boost9function0IiE9assign_toINS_3_bi6bind_tIiPFiPKiENS3_5l
ist1INS3_5valueIPivT_E13stored_vtable, %eax
orq $1, %rax
-   movq%rax, 96(%rsp)
-   movq%rax, 64(%rsp)
+   movq$_Z7bmi_getPKi, 104(%rsp)
movq$_Z7bmi_getPKi, 72(%rsp)
-   movq112(%rsp), %rdx
+   movq%rbp, 16(%rbx)
+   leaq64(%rsp), %rbp
+   movq%rax, 96(%rsp)
movq%rdx, 80(%rsp)
movq120(%rsp), %rdx
-   movq%rdx, 88(%rsp)
+   movq%rax, 64(%rsp)
andq$-2, %rax
-   leaq64(%rsp), %rbp
leaq8(%rbp), %rdi
+   movq%rdx, 88(%rsp)
 .LEHB15:
call*8(%rax)
 .LEHE15:

Still can't see where that is broken ... :/


-- 


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

[Bug bootstrap/44271] New: [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

Revision 159808:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00862.html

gave:

../../src-trunk/gcc/cp/parser.c: In function 'cp_parser_asm_definition':
../../src-trunk/gcc/cp/parser.c:13478:3: error: enum conversion in
initialization is invalid in C++ [-Werror=c++-compat]
cc1: all warnings being treated as errors

Revision 159807 is OK.


-- 
   Summary: [4.6 regression] Failed to bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c/44272] New: Wrong interpretation of hex constant as floating point value.

[draqsn at mail dot ru]

gcc 4.5.0, built for arm-elf
Problems with compiling following code:

int ret_const(void)
{
return 0x12E+2;
}

GCC claims that:

test.c: In function 'ret_const':
test.c:3:12: error: invalid suffix "+2" on integer constant
test.c:4:1: warning: control reaches end of non-void function

This is because GCC thinks that 0x12E+2 is a floating point number, while this
is just an addition of two integers.
Adding spaces around '+' solves the problem, but this is definitely bug.
It persists with all versions of GCC 4.4.x and 4.5.0


-- 
   Summary: Wrong interpretation of hex constant as floating point
value.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: draqsn at mail dot ru
 GCC build triplet: all
  GCC host triplet: all
GCC target triplet: all


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2010-05-25 14:57 
---
We're exchanging

movq112(%rsp), %rdx

and

leaq96(%rsp), %rbx
movq%rbp, 16(%rbx)

which is broken.

(insn 565 18 20 3 /usr/include/boost/function/function_template.hpp:566 (set
(reg/f:DI 3 bx [242])
(plus:DI (reg/f:DI 7 sp)
(const_int 96 [0x60]))) 248 {*lea_1} (nil))

(insn 23 21 24 3 gtest.cc:21 (set (mem/s/f:DI (plus:DI (reg/f:DI 3 bx [242])
(const_int 16 [0x10])) [20 D.60304_20->l_.D.57654.a1_.t_+0 S8
A64])
(reg/f:DI 6 bp [140])) 89 {*movdi_1_rex64} (expr_list:REG_DEAD
(reg/f:DI 6 bp [140])
(nil)))

(insn 39 38 40 3 /usr/include/boost/function/function_template.hpp:886 (set
(reg:DI 1 dx [orig:146 f.D.56107.D.55977.functor+8 ] [146])
(mem/s/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 112 [0x70])) [9 f.D.56107.D.55977.functor+8 S8
A64])) 89 {*movdi_1_rex64} (expr_list:REG_EQUIV (mem/s/c:DI (plus:DI (reg/f:DI
7 sp)
(const_int 112 [0x70])) [9 f.D.56107.D.55977.functor+8 S8 A64])
(nil)))

Relevant MEM_ATTRs are

  [20 D.60304_20->l_.D.57654.a1_.t_+0 S8 A64]
  [9 f.D.56107.D.55977.functor+8 S8 A64]

  struct bind_t * D.60304;
  struct bind_t f;
  struct func_t f;

  D.60304_20 = (struct bind_t *) &f.D.56107.D.55977.functor.data;
  D.60304_20->l_.D.57654.a1_.t_ = &id;
...
  g.D.56107.D.55977.functor = f.D.56107.D.55977.functor;

which we disambiguate via the TBAA tree oracle as the pointed-to type
by D.60304_20 is bind_t and has alias-set 21 which is not a subset of
alias-set 5, the alias-set of f.  This particular disambiguation would
be fixed by backporting the alias_set_subset_of change.  Then we
disambiguate via access-path based disambiguation.


-- 


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

[Bug driver/44273] New: Using -save-temps and @file should also save the intermediate @file used by the driver.

[carlos at codesourcery dot com]

When you compile anything using @file support, the driver assumes @file
(at_file_supplied is true) is allowed and may pass options to the linker via
@file using a *temporary* file.

When -save-temps is also used, the temporary @file passed to the linker should
also be saved.

Saving the temporary @file passed to the linker allows a developer to re-run
just the collect2/ld command.

On trunk this means that gcc/gcc.c (create_at_file) should honour the
save_temps_flag, saving the temporary @file for later analysis or use.


-- 
   Summary: Using -save-temps and @file should also save the
intermediate @file used by the driver.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlos at codesourcery dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu arm-none-linux-gnu


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2010-05-25 15:28 
---
I have some patches.


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2010-05-19 22:15:45 |2010-05-25 15:28:49
   date||


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

[Bug c/44272] Wrong interpretation of hex constant as floating point value.

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-05-25 15:33 ---
It is not a bug.
See ISO C99, 6.4.8.
0x12E+2
as whole is a pp-number and thus one token (which is not a valid number though,
but that is determined in a later phase, not during lexing).
If you want 0x12E + 2, you really need to put some whitespace in between E and
+
to make sure it is lexed as separate tokens.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/44069] [4.5/4.6 Regression] optimization bug initializing from cast array

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-05-25 15:50 ---
Subject: Bug 44069

Author: rguenth
Date: Tue May 25 15:49:34 2010
New Revision: 159824

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159824
Log:
2010-05-25  Richard Guenther  

PR middle-end/44069
* gimple-fold.c (maybe_fold_stmt_addition): Avoid generating
out-of-bounds array accesses.

* g++.dg/torture/pr44069.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr44069.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/44069] [4.5 Regression] optimization bug initializing from cast array

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-05-25 15:53 ---
Fixed for 4.6 sofar.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.6.0
Summary|[4.5/4.6 Regression]|[4.5 Regression]
   |optimization bug|optimization bug
   |initializing from cast array|initializing from cast array


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

[Bug c/44274] New: alpha-dec-vms internal error compiling unwind-dw2.c

[jay dot krell at cornell dot edu]

/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c: In function 'uw_update_context_1':
/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:1378:1: error: unrecognizable insn:
(insn 372 371 373 42 /src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:241 (set (reg:DI
457)
(plus:SI (subreg/s:SI (reg:DI 183 [ ivtmp___789 ]) 0)
(const_int 312 [0x138]))) -1 (nil))
/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:1378:1: internal compiler error: in
extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


reduced case:


struct {
unsigned a;
unsigned short b[6];
} *c;

void F1(void)
{
unsigned i;
for (i = 0; i < 6; ++i)
c->b[i] = c->b[0];
}

jbook2:libgcc jay$ alpha-dec-vms-gcc -O2 -v -c 1.c
Using built-in specs.
COLLECT_GCC=alpha-dec-vms-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/alpha-dec-vms/4_5_0/lto-wrapper
Target: alpha-dec-vms
Configured with: /src/gcc-4.5.0/configure -target=alpha-dec-vms -disable-shared
-disable-multilib -disable-werror -enable-target-optspace -disable-nls -verbose
Thread model: single
gcc version 4.5.0 (GCC) 
COLLECT_GCC_OPTIONS='-O2' '-v' '-c'
 /usr/local/libexec/gcc/alpha-dec-vms/4_5_0/cc1 -quiet -v 1.c -quiet -dumpbase
1.c -auxbase 1 -O2 -version -o
/var/folders/QG/QGSTvYqCGfSGxXo0rUMOXTI/-Tmp-//cceivbQS.s
GNU C (GCC) version 4.5.0 (OpenVMS/Alpha)
compiled by GNU C version 4.0.1 (Apple Inc. build 5493), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/alpha-dec-vms/4_5_0/include
 /usr/local/lib/gcc/alpha-dec-vms/4_5_0/include-fixed
 /usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include
End of search list.
GNU C (GCC) version 4.5.0 (OpenVMS/Alpha)
compiled by GNU C version 4.0.1 (Apple Inc. build 5493), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4534e0034debe97df9f8a4e8952a585a
1.c: In function 'F1':
1.c:11:1: error: unrecognizable insn:
(insn 58 57 59 4 1.c:10 (set (reg:DI 122)
(plus:SI (subreg/s:SI (reg:DI 115 [ ivtmp___14 ]) 0)
(const_int 4 [0x4]))) -1 (nil))
1.c:11:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: alpha-dec-vms internal error compiling unwind-dw2.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
GCC target triplet: alpha-dec-vms


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

[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[ro at gcc dot gnu dot org]

--- Comment #5 from ro at gcc dot gnu dot org  2010-05-25 16:14 ---
Created an attachment (id=20745)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20745&action=view)
proposed patch

This patch worked for me.  It's a hack in that it does the save and restore
using lowlevel autoconf implementation details, but it gets the job done.


-- 


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

[Bug debug/42801] C VLAs should use DW_AT_allocated

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-05-25 16:16 ---
Subject: Bug 42801

Author: jakub
Date: Tue May 25 16:15:38 2010
New Revision: 159826

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159826
Log:
PR debug/42801
* tree-inline.c (remap_decls): Remap DECL_VALUE_EXPR here...
(copy_bind_expr): ... instead of here.
(copy_tree_body_r): If id->remapping_type_depth clear TREE_BLOCK
if the block hasn't been remapped.
* dwarf2out.c (gen_formal_parameter_die, gen_variable_die): When
emitting concrete instance of abstract VLA, add DW_AT_type attribute.

* gcc.dg/guality/sra-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/guality/sra-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c


-- 


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

[Bug c++/18249] C++ parser i18n problems

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-05-25 16:18 ---
Subject: Bug 18249

Author: jakub
Date: Tue May 25 16:17:32 2010
New Revision: 159827

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159827
Log:
PR c++/18249
* parser.c (non_integral_constant): Add NIC_NONE.
(required_token): Add RT_NONE.
(cp_parser_unary_expression): Initialize non_constant_p
to NIC_NONE.
(cp_parser_asm_definition): Initialize missing to RT_NONE.
(cp_parser_primary_expression, cp_parser_postfix_expression,
cp_parser_cast_expression, cp_parser_binary_expression,
cp_parser_functional_cast): Fix formatting.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c


-- 


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

[Bug debug/43260] Java static class members lack DWARF location info

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-25 16:19 ---
Subject: Bug 43260

Author: jakub
Date: Tue May 25 16:19:11 2010
New Revision: 159828

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159828
Log:
PR debug/43260
* java-tree.h (pending_static_fields): New extern declaration.
(java_write_globals): New prototype.
* lang.c (LANG_HOOKS_WRITE_GLOBALS): Define.
* decl.c (java_mark_class_local): When clearing DECL_EXTERNAL
of a static field push it into pending_static_fields vector.
* class.c (pending_static_fields): New variable.
(add_field): If static field is not DECL_EXTERNAL, push it into
pending_static_fields vector.
(java_write_globals): New function.

Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/class.c
trunk/gcc/java/decl.c
trunk/gcc/java/java-tree.h
trunk/gcc/java/lang.c


-- 


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

[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2010-05-25 16:21 ---
The patch needs a fat comment saying what's going on, then it should be okay.


-- 


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

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

[jakub at gcc dot gnu dot org]

--- Comment #29 from jakub at gcc dot gnu dot org  2010-05-25 16:27 ---
Subject: Bug 41371

Author: jakub
Date: Tue May 25 16:27:03 2010
New Revision: 159829

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159829
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Guard asserts with
ENABLE_CHECKING.
(intersect_loc_chains): Walk the s2var's loc_chain together
with s1node chain as long as the locations are equal, don't
call find_loc_in_1pdv in that case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c


-- 


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

[Bug debug/43260] Java static class members lack DWARF location info

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-25 16:28 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/43973] alpha libiberty/regex.c fails to compile with -O2 without -mbwx (internal compiler error)

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2010-05-25 16:42 ---
*** Bug 44274 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/44274] alpha-dec-vms internal error compiling unwind-dw2.c

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2010-05-25 16:42 ---
This is duplicate of 43973.

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


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |target
 Resolution||DUPLICATE


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

[Bug bootstrap/44271] [4.6 regression] Failed to bootstrap

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2010-05-25 16:47 ---
Fixed by [1].

[1] http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00882.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[ro at gcc dot gnu dot org]

--- Comment #7 from ro at gcc dot gnu dot org  2010-05-25 16:55 ---
Mine.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-25 16:55:37
   date||


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

[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[ro at gcc dot gnu dot org]

--- Comment #8 from ro at gcc dot gnu dot org  2010-05-25 17:00 ---
Subject: Bug 44216

Author: ro
Date: Tue May 25 16:59:45 2010
New Revision: 159833

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159833
Log:
PR libgcj/44216
* configure.ac (libgcj_cv_exidx): Enable AC_LANG_WERROR.
Save and restore werror flag.
* configure: Regenerate.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/configure
trunk/libjava/configure.ac


-- 


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

[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[ro at gcc dot gnu dot org]

--- Comment #9 from ro at gcc dot gnu dot org  2010-05-25 17:01 ---
Fixed for 4.6.0.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||05/msg01889.html
 Status|ASSIGNED|RESOLVED
   Keywords||patch
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug c++/44267] SFINAE does not handle down static_cast over virtual inheritance

[cjoldfield at gmail dot com]

--- Comment #2 from cjoldfield at gmail dot com  2010-05-25 17:09 ---
Intel 11.1 accepts it, but it doesn't even try to instantiate "one &f(...)". 
To see what I mean, try replacing main with:

#include 
int main()
{
   std::cout << sizeof(f(0)) << std::endl;
   std::cout << sizeof(f(0)) << std::endl;
   std::cout << sizeof(f(0)) <(0) for all three calls (it should match the second).  In this situation,
gcc only complains about the first and the last, which is the expected
behavior.


-- 


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

[Bug c/44275] New: Union cast leads to wrong code generation. (Strict aliasing not warned about?)

[svfuerst at gmail dot com]

struct s1
{
int a;
int b;

double c;
};

struct s2
{
long long a;
long long b;
};

union us
{
struct s1 us1;
struct s2 us2;
};

void foo1(struct s1 s)
{
printf("Got %d %d %f\n", s.a, s.b, s.c);
}

void __attribute__((noinline, used, noclone)) foo(void)
{
struct s1 s = {1, 2, 3.0};

asm("");

foo1(s);

foo1(((union us *)&s)->us1);
}

Neither gcc 4.4 or 4.5 warn about the union cast, however 4.4 will mention a
strict-aliasing problem if foo1() is forced not to be inlined.  gcc 4.5 outputs
incorrect results.  4.4 outputs the correct 1,2,3 unless foo1() is forced to be
not inlined, in which case it also has incorrect output.

My understanding is that casting to the union type is okay because union us
contains struct s1 as a member.  We then access the union member that
corresponds to the original type. (No undefined behaviour.)  So it looks like
the lack of strict aliasing warning in 4.5 is correct.  However, the wrong code
generation that results is obviously then problematic.


-- 
   Summary: Union cast leads to wrong code generation. (Strict
aliasing not warned about?)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2010-05-25 18:10 ---
Subject: Bug 34260

Author: dfranke
Date: Tue May 25 18:10:01 2010
New Revision: 159838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159838
Log:
gcc/fortran/:
2010-05-25  Daniel Franke  

PR fortran/30668
PR fortran/31346
PR fortran/34260
* resolve.c (resolve_global_procedure): Add check for global
procedures with implicit interfaces and assumed-shape or optional
dummy arguments. Verify that function return type, kind and string
lengths match.

gcc/testsuite/:
2010-05-25  Daniel Franke  

PR fortran/30668
PR fortran/31346
PR fortran/34260
* gfortran.dg/pr40999.f: Fix function type.
* gfortran.dg/whole_file_5.f90: Likewise.
* gfortran.dg/whole_file_6.f90: Likewise.
* gfortran.dg/whole_file_16.f90: New.
* gfortran.dg/whole_file_17.f90: New.
* gfortran.dg/whole_file_18.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/whole_file_16.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_17.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr40999.f
trunk/gcc/testsuite/gfortran.dg/whole_file_5.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_6.f90


-- 


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

[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays without explicit interface

[dfranke at gcc dot gnu dot org]

--- Comment #11 from dfranke at gcc dot gnu dot org  2010-05-25 18:10 
---
Subject: Bug 31346

Author: dfranke
Date: Tue May 25 18:10:01 2010
New Revision: 159838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159838
Log:
gcc/fortran/:
2010-05-25  Daniel Franke  

PR fortran/30668
PR fortran/31346
PR fortran/34260
* resolve.c (resolve_global_procedure): Add check for global
procedures with implicit interfaces and assumed-shape or optional
dummy arguments. Verify that function return type, kind and string
lengths match.

gcc/testsuite/:
2010-05-25  Daniel Franke  

PR fortran/30668
PR fortran/31346
PR fortran/34260
* gfortran.dg/pr40999.f: Fix function type.
* gfortran.dg/whole_file_5.f90: Likewise.
* gfortran.dg/whole_file_6.f90: Likewise.
* gfortran.dg/whole_file_16.f90: New.
* gfortran.dg/whole_file_17.f90: New.
* gfortran.dg/whole_file_18.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/whole_file_16.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_17.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr40999.f
trunk/gcc/testsuite/gfortran.dg/whole_file_5.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_6.f90


-- 


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

[Bug fortran/30668] -fwhole-file should catch function of wrong type

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2010-05-25 18:10 ---
Subject: Bug 30668

Author: dfranke
Date: Tue May 25 18:10:01 2010
New Revision: 159838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159838
Log:
gcc/fortran/:
2010-05-25  Daniel Franke  

PR fortran/30668
PR fortran/31346
PR fortran/34260
* resolve.c (resolve_global_procedure): Add check for global
procedures with implicit interfaces and assumed-shape or optional
dummy arguments. Verify that function return type, kind and string
lengths match.

gcc/testsuite/:
2010-05-25  Daniel Franke  

PR fortran/30668
PR fortran/31346
PR fortran/34260
* gfortran.dg/pr40999.f: Fix function type.
* gfortran.dg/whole_file_5.f90: Likewise.
* gfortran.dg/whole_file_6.f90: Likewise.
* gfortran.dg/whole_file_16.f90: New.
* gfortran.dg/whole_file_17.f90: New.
* gfortran.dg/whole_file_18.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/whole_file_16.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_17.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr40999.f
trunk/gcc/testsuite/gfortran.dg/whole_file_5.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_6.f90


-- 


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

[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2010-05-25 18:11 ---
Commit in #5 catches the OPTIONAL argument if the testcase is compiled with
-fwhole-file. However, the warning regarding the inconsistent use of SUB is
still missing.


-- 


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

[Bug middle-end/44276] New: [4.6 Regression]: gcc.dg/tls/alias-1.c

[hp at gcc dot gnu dot org]

With revision 159779 this test passed.
>From revision 159784 and on, this test has failed as follows:

Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/tls/tls.exp ...
FAIL: gcc.dg/tls/alias-1.c (test for excess errors)

With the message in the logfile being (copy-pasted):

Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ /tmp/hpaut\
otest-gcc1/gcc/gcc/testsuite/gcc.dg/tls/alias-1.c-ansi -pedantic-errors  
-isystem /tmp/hpautotest-gcc1/cris-elf/gc\
cobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-e\
lf/gccobj/cris-elf/./libgloss/cris/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris
-L/tmp/hpautotest-g\
cc1/gcc/libgloss/cris 
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj\
/cris-elf/./newlib -sim3  -lm   -o alias-1.exe(timeout = 300)
/tmp/ccZoLZBR.s: Assembler messages:^M
/tmp/ccZoLZBR.s:43: Error: symbol `___emutls_v.bar' is already defined^M
compiler exited with status 1
output is:
/tmp/ccZoLZBR.s: Assembler messages:^M
/tmp/ccZoLZBR.s:43: Error: symbol `___emutls_v.bar' is already defined^M

FAIL: gcc.dg/tls/alias-1.c (test for excess errors)
Excess errors:
/tmp/ccZoLZBR.s:43: Error: symbol `___emutls_v.bar' is already defined


Author of suspect patches in revision range CC:ed.


-- 
   Summary: [4.6 Regression]: gcc.dg/tls/alias-1.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2010-05-25 18:41 ---
See also PR44137.


-- 


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

[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c

[iains at gcc dot gnu dot org]

--- Comment #2 from iains at gcc dot gnu dot org  2010-05-25 19:15 ---

Yes, sorry, the list of emutls users grows...

most likely it is my commit from r159781 to address PR44132 that caused this,

1/ Did the same commit improve PR44137 on your target?
 (PR44173 looks pretty much the same bug as 44132)

2/ Are you able to try the proposed "proper" solution to that bug (see comment
#24 of PR44132) ?

In the end we will have to address this if lto/whopr are to work with emulated
tls.


-- 


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

[Bug tree-optimization/44137] [4.6 Regression]: objc.dg/torture/tls/thr-init-2.m and thr-init.m

[iains at gcc dot gnu dot org]

--- Comment #1 from iains at gcc dot gnu dot org  2010-05-25 19:19 ---
I've xfailed thr-init-3.m (which were failing across the board for non-tls
reasons).

are the remainder fixed by r159781?

Please see also comments in PR44276


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||iains at gcc dot gnu dot org


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

[Bug fortran/39427] F2003: Procedures with same name as types/type constructors

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2010-05-25 19:55 ---
(In reply to comment #14)
> Created an attachment (id=20714)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20714&action=view) [edit]

In module.c's import_iso_c_binding_module, one needs to replace:
  local_name = gfc_get_string ("%s@", u->local_name);
by
  local_name = (u->local_name[0] != '\0')
   ? gfc_get_string ("%s@", u->local_name) : NULL;

I now will try the other approach of using ns->derived_types to see whether the
code will be cleaner.


-- 


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

[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c

[iains at gcc dot gnu dot org]

--- Comment #3 from iains at gcc dot gnu dot org  2010-05-25 20:38 ---
I will need some help in tracking down how to solve this (since I don't have an
emutls/visibility/alias target available).

Also I can't find any reference in the gcc manual to alias applied to variables
- only to functions.
(although that might just be documentation lag).

I guess we need to check for the alias attribute in emutls_decl and find our
way back to the original aliased decl.  Alternatively it might be enough to
copy the alias attribute onto the emutls control var.


-- 


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

[Bug fortran/38112] unneeded temporary

[mikael at gcc dot gnu dot org]

--- Comment #8 from mikael at gcc dot gnu dot org  2010-05-25 20:52 ---
(In reply to comment #7)
> This could be fixed but, right now, I am not sure how :-(

It seems to be fixed now.
probably http://gcc.gnu.org/viewcvs?view=revision&revision=158632


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-05-25 20:55 
---
Jon, can you have a look and apply the patch to the relevant branches? Thanks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


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

[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-05-25 20:57 
---
See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01912.html we are going to
have __int128 and unsigned __int128.


-- 


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

[Bug fortran/38112] unneeded temporary

[paul dot richard dot thomas at gmail dot com]

--- Comment #9 from paul dot richard dot thomas at gmail dot com  
2010-05-25 20:57 ---
Subject: Re:  unneeded temporary

Mikael,

Yes, I am sure that you are right about the <>.

Let's close it :-)

Paul

On Tue, May 25, 2010 at 10:52 PM, mikael at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #8 from mikael at gcc dot gnu dot org  2010-05-25 20:52 
> ---
> (In reply to comment #7)
>> This could be fixed but, right now, I am not sure how :-(
>
> It seems to be fixed now.
> probably http://gcc.gnu.org/viewcvs?view=revision&revision=158632
>
>
> --
>
> mikael at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> 
>             Status|REOPENED                    |RESOLVED
>         Resolution|                            |FIXED
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
>
> --- 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=38112

[Bug fortran/43841] Missing temporary for ELEMENTAL function call

[mikael at gcc dot gnu dot org]

--- Comment #10 from mikael at gcc dot gnu dot org  2010-05-25 21:02 ---
Any backport ?


-- 


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

[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|paolo dot carlini at oracle |
   |dot com |
 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-25 21:03:55
   date||


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

[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2

[redi at gcc dot gnu dot org]

-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |redi at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-25 21:35:43
   date||


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

[Bug target/43892] PowerPC suboptimal "add with carry" optimization

[joakim dot tjernlund at transmode dot se]

--- Comment #13 from joakim dot tjernlund at transmode dot se  2010-05-25 
21:42 ---
(In reply to comment #12)
> (In reply to comment #11)
> > If this is the case for something as simple as add with carry, one really
> > needs a simple way to tell gcc what ppc class CPU one wants to use.
> 
> Please see -mcpu= .
> 

Almost forgot, but how do I specify that at gcc build/configure ?

Also, I haven't seen any progress on this issue even though it sounded that the
initial fix was easy(addcc expander)


-- 


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

[Bug c++/44277] New: [C++0x] Add warning to facilitate nullptr conversion.

[sacolcor at provide dot net]

C++0x introduces the 'nullptr' constant, intended to replace a literal '0' for
null pointers.  Support for nullptr is being (has been?) added to gcc 4.6. 
However, for backward compatibility reasons, '0' will remain convertible to
pointer type for the foreseeable future.  As grepping for '0' is likely to be
unfeasibly noisy, it would be helpful if a warning could be enabled to detect
the use of '0' as a pointer type.


-- 
   Summary: [C++0x] Add warning to facilitate nullptr conversion.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sacolcor at provide dot net


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

[Bug tree-optimization/43423] gcc should vectorize this loop through if-conversion

[spop at gcc dot gnu dot org]

--- Comment #11 from spop at gcc dot gnu dot org  2010-05-25 23:33 ---
This is not a IV type problem: the number of iterations may be zero when mid ==
0 or mid == n, so the number of iterations analysis has a condition under which
niter may_be_zero.

I sent out a patch that makes niter return a COND_EXPR
instead of a chrec_dont_know:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01927.html

With that patch I now get 
  note: not vectorized: data ref analysis failed D.2726_51 = a[var.9_55];


-- 


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

[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE

[jon at beniston dot com]

--- Comment #5 from jon at beniston dot com  2010-05-25 23:51 ---
This is the same as 43805. Looks like it can be fixed by removing
GO_IF_MODE_DEPENDENT_ADDRESS from lm32.h. I'll submit a patch shotly.


-- 


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

[Bug target/43527] ICE in cselib_record_set, at cselib.c:1864 during build of compiler

[jon at beniston dot com]

--- Comment #2 from jon at beniston dot com  2010-05-25 23:55 ---
Hi Joel, do you have a .i test case for this? Thanks.


-- 


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

[Bug target/43527] ICE in cselib_record_set, at cselib.c:1864 during build of compiler

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2010-05-26 00:26 ---
(In reply to comment #2)
> Hi Joel, do you have a .i test case for this? Thanks.
> 

It works today. with 

$ lm32-rtems4.10-gcc --version
lm32-rtems4.10-gcc (GCC) 4.6.0 20100525 (experimental) [trunk revision 159847]

Do I need to pull the 4.5 branch and try that?


-- 


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

[Bug target/44278] New: Use ubfx to extract unsigned bit fields at the low end

[carrot at google dot com]

Compile the following code with options -march=armv7-a -mthumb -O2

unsigned int foo6(unsigned u)
{
  return (u >> 0) & 0x1ff;
}

GCC generates:

lslsr0, r0, #23
lsrsr0, r0, #23
bx  lr

The two shifts can be merged into 
UBFX r1,r0,#0,#9

If I change the source code into
  return (u >> 1) & 0x1ff;
Then gcc can generate ubfx instruction. So this case only occurs at the low end
of a register.

The same problem exists with option -Os and arm instructions.


-- 
   Summary: Use ubfx to extract unsigned bit fields at the low end
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
 GCC build triplet: i686-linux
  GCC host triplet: i686-linux
GCC target triplet: arm-eabi


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

[Bug target/44266] stack frame lacks parameter save area

[amodra at gmail dot com]

--- Comment #3 from amodra at gmail dot com  2010-05-26 02:49 ---
and it contained a typo too.  superceded by the patch in the patch url


-- 


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

[Bug c/44279] New: system.h calloc/malloc/realloc VMS size_t vs. __size_t

[jay dot krell at cornell dot edu]

VMS has:
typedef long unsigned int size_t;
typedef unsigned int __size_t;
void * calloc (__size_t __nmemb, __size_t __size);
void * malloc (__size_t __size);
void * realloc (__void_ptr64 __ptr, __size_t __size);

possibly this is something for fixincludes to deal with.

As a result, gcc/system.h gets warnings/errors here, due to varying
declarations of malloc/calloc/realloc (size_t vs. __size_t, unsigned vs.
unsigned long):

#if defined (HAVE_DECL_MALLOC) && !HAVE_DECL_MALLOC
extern void *malloc (size_t);
#endif

#if defined (HAVE_DECL_CALLOC) && !HAVE_DECL_CALLOC
extern void *calloc (size_t, size_t);
#endif

#if defined (HAVE_DECL_REALLOC) && !HAVE_DECL_REALLOC
extern void *realloc (void *, size_t);
#endif


I changed mine to:

#if defined (HAVE_DECL_MALLOC) && !HAVE_DECL_MALLOC && !defined(__vms)
extern void *malloc (size_t);
#endif

#if defined (HAVE_DECL_CALLOC) && !HAVE_DECL_CALLOC && !defined(__vms)
extern void *calloc (size_t, size_t);
#endif

#if defined (HAVE_DECL_REALLOC) && !HAVE_DECL_REALLOC && !defined(__vms)
extern void *realloc (void *, size_t);
#endif


perhaps not the best fix.


-- 
   Summary: system.h calloc/malloc/realloc VMS size_t vs. __size_t
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
GCC target triplet: alpha-dec-vms


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

[Bug c/44280] New: vms-unwind.h needs #define __NEW_STARTLET and #include "vms/lib$routines.h"?

[jay dot krell at cornell dot edu]

I didn't preserve the errors/rationale but I have this reasonable trivial diff:


diff -ur /src/orig/gcc-4.5.0/gcc/config/alpha/vms-unwind.h
/src/gcc-4.5.0/gcc/config/alpha/vms-unwind.h
--- /src/orig/gcc-4.5.0/gcc/config/alpha/vms-unwind.h   2009-08-09
21:38:02.0 -0700
+++ /src/gcc-4.5.0/gcc/config/alpha/vms-unwind.h2010-05-21
23:46:31.0 -0700
@@ -23,12 +23,16 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */

+#ifndef __NEW_STARLET
+#define __NEW_STARLET
+#endif
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 

 #define MD_FALLBACK_FRAME_STATE_FOR alpha_vms_fallback_frame_state

@@ -286,6 +290,3 @@

   return _URC_NO_REASON;
 }
-
-
-


-- 
   Summary: vms-unwind.h needs #define __NEW_STARTLET and #include
"vms/lib$routines.h"?
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
GCC target triplet: alpha-dec-vms


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

[Bug target/44037] builtin ffs vs. renamed ffs (vms-crtl.h)‏

[jay dot krell at cornell dot edu]

--- Comment #3 from jay dot krell at cornell dot edu  2010-05-26 04:56 
---
Also this needed at top after #includes:
+#ifndef TARGET_ABI_OPEN_VMS
+#define TARGET_ABI_OPEN_VMS 0
+#endif


-- 


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

[Bug c++/43382] [C++0x] ICE with auto return type and variadic templates

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-16 10:27:59 |2010-05-26 04:59:29
   date||


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

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

--- Comment #55 from pault at gcc dot gnu dot org  2010-05-26 05:11 ---
Subject: Bug 40011

Author: pault
Date: Wed May 26 05:11:04 2010
New Revision: 159852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159852
Log:
2010-05-26  Paul Thomas  

PR fortran/40011
* resolve.c (resolve_global_procedure): Resolve the gsymbol's
namespace before trying to reorder the gsymbols.

2010-05-26  Paul Thomas  

PR fortran/40011
* gfortran.dg/whole_file_19.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/whole_file_19.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug regression/44281] New: Global Register variable pessimisation and regression

[adam at consulting dot net dot nz]

I am aware developers WONTFIX GCC being a pessimising compiler with respect to
some global register variable issues:


GCC is copying registers for no good reason whatsoever. Below is a very simple
example where gcc 3.3.6 does a better job of optimising the code. Unnecessary
copying of registers may also occur with local register variables.

#include 

register uint64_t global_flag_stack __asm__("rbx");

void push_flag_into_global_reg_var(uint64_t a, uint64_t b) {
  uint64_t flag = (a==b);
  global_flag_stack <<= 8;
  global_flag_stack  |= flag;
}

uint64_t push_flag_into_local_var(uint64_t a, uint64_t b,
  uint64_t local_flag_stack) {
  uint64_t flag = (a==b);
  local_flag_stack <<= 8;
  return local_flag_stack | flag;
}

int main() {
}


gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-15):
$ gcc-3.3 -Os flags.c && objdump -d -m i386:x86-64:intel a.out|less
...
00400478 :
  400478:   31 c0   xoreax,eax
  40047a:   48 39 f7cmprdi,rsi
  40047d:   0f 94 c0sete   al
  400480:   48 c1 e3 08 shlrbx,0x8
  400484:   48 09 c3or rbx,rax
  400487:   c3  ret

00400488 :
  400488:   31 c0   xoreax,eax
  40048a:   48 39 f7cmprdi,rsi
  40048d:   0f 94 c0sete   al
  400490:   48 c1 e2 08 shlrdx,0x8
  400494:   48 09 d0or rax,rdx
  400497:   c3  ret  
...

gcc-4.1 (GCC) 4.1.3 20080704 (prerelease) (Debian 4.1.2-29):
$ gcc-4.1 -Os flags.c && objdump -d -m i386:x86-64:intel a.out|less
...
00400448 :
  400448:   48 89 damovrdx,rbx
  40044b:   31 c0   xoreax,eax
  40044d:   48 c1 e2 08 shlrdx,0x8
  400451:   48 39 f7cmprdi,rsi
  400454:   0f 94 c0sete   al
  400457:   48 89 d3movrbx,rdx
  40045a:   48 09 c3or rbx,rax
  40045d:   c3  ret

0040045e :
  40045e:   48 c1 e2 08 shlrdx,0x8
  400462:   31 c0   xoreax,eax
  400464:   48 39 f7cmprdi,rsi
  400467:   0f 94 c0sete   al
  40046a:   48 09 d0or rax,rdx
  40046d:   c3  ret 
...

gcc-4.5 (Debian 4.5.0-1) 4.5.0:
$ gcc-4.5 -Os flags.c && objdump -d -m i386:x86-64:intel a.out|less
...
00400494 :
  400494:   31 d2   xoredx,edx
  400496:   48 39 f7cmprdi,rsi
  400499:   48 89 d8movrax,rbx
  40049c:   0f 94 c2sete   dl
  40049f:   48 c1 e0 08 shlrax,0x8
  4004a3:   48 89 d3movrbx,rdx
  4004a6:   48 09 c3or rbx,rax
  4004a9:   c3  ret

004004aa :
  4004aa:   48 89 d0movrax,rdx
  4004ad:   31 d2   xoredx,edx
  4004af:   48 c1 e0 08 shlrax,0x8
  4004b3:   48 39 f7cmprdi,rsi
  4004b6:   0f 94 c2sete   dl
  4004b9:   48 09 d0or rax,rdx
  4004bc:   c3  ret   
...

The object code that current GCC is generating is embarrassing compared with
GCC 3.3.6. Is it also necessary to increase the code footprint of
push_flag_into_local_var when optimising for size (-Os) when compared to gcc
3.3.6 and 4.1.3?


-- 
   Summary: Global Register variable pessimisation and regression
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #18 from jakub at gcc dot gnu dot org  2010-05-26 06:01 ---
Subject: Bug 44199

Author: jakub
Date: Wed May 26 06:00:44 2010
New Revision: 159853

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159853
Log:
PR target/44199
* config/rs6000/rs6000.c (rs6000_emit_epilogue): If cfun->calls_alloca
or total_size is larger than red zone size for non-V4 ABI, emit a
stack_tie resp. frame_tie insn before stack pointer restore.
* config/rs6000/rs6000.md (frame_tie): New insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #19 from jakub at gcc dot gnu dot org  2010-05-26 06:02 ---
Subject: Bug 44199

Author: jakub
Date: Wed May 26 06:02:30 2010
New Revision: 159854

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159854
Log:
PR target/44199
* config/rs6000/rs6000.c (rs6000_emit_epilogue): If cfun->calls_alloca
or total_size is larger than red zone size for non-V4 ABI, emit a
stack_tie resp. frame_tie insn before stack pointer restore.
* config/rs6000/rs6000.md (frame_tie): New insn.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_5-branch/gcc/config/rs6000/rs6000.md


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #20 from jakub at gcc dot gnu dot org  2010-05-26 06:05 ---
Subject: Bug 44199

Author: jakub
Date: Wed May 26 06:05:29 2010
New Revision: 159855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159855
Log:
PR target/44199
* config/rs6000/rs6000.c (rs6000_emit_epilogue): If cfun->calls_alloca
or total_size is larger than red zone size for non-V4 ABI, emit a
stack_tie resp. frame_tie insn before stack pointer restore.
* config/rs6000/rs6000.md (frame_tie): New insn.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.md


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #21 from jakub at gcc dot gnu dot org  2010-05-26 06:07 ---
Should be fixed now.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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