[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

2009-08-04 Thread bonzini at gnu dot org


--- Comment #10 from bonzini at gnu dot org  2009-08-05 06:09 ---
preprocessed testcase?


-- 


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



[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before

2009-08-04 Thread dannysmith at users dot sourceforge dot net


--- Comment #8 from dannysmith at users dot sourceforge dot net  2009-08-05 
04:55 ---
(In reply to comment #6)
> (In reply to comment #5)
> 
> > Applying Dave Korn's patch mentioned in Comment #2, and linking against
> > libstdc++.dll, I get this with your original testcaase:
> > 
> > Expecting 'true', got 'true'
> > Expecting 'false', got 'false'
> > 
> Where this patch is supposed to be applied to? trunk?

Yes, it against trunk.

> I have looked through the patches you are referring to and through the source
> in repository. As far as I can see, libsupc++ is still static only, and
> eh_globals.cc is a part of libsupc++, not libstdc++.

libsupc++ is a convenience lib that is included in libstdc++


 The fact that test-case
> works correctly for you could be just a coincidence. The more reliable way to
> check for the problem would be to compare the value returned by the
> __cxa_get_globals() when being from the main executable and from the dll
> respectively. I'll prepare the new test case.

The new test case succeeds when I link against a shared libstdc++.

Danny


-- 


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



[Bug middle-end/40965] [graphite] slow compilation

2009-08-04 Thread sebpop at gmail dot com


--- Comment #3 from sebpop at gmail dot com  2009-08-05 04:42 ---
Subject: Re:  [graphite] slow compilation

On Tue, Aug 4, 2009 at 17:44, rguenth at gcc dot gnu dot
org wrote:
> Eh - where's that exponential time complexity? ...

The code generation of Graphite can be exponential, didn't I mentioned
it yet?

We should find some cutting factor, function of the number of loops in
a SCoP to avoid these long compile times.  One other solution is to
use the PPL watchdog utility to cut off the exponential operations in
a deterministic way.

Sebastian


-- 


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



[Bug fortran/40853] I/O: Namelist read error

2009-08-04 Thread jvdelisle at gcc dot gnu dot org


--- Comment #11 from jvdelisle at gcc dot gnu dot org  2009-08-05 03:19 
---
Fixed on 4.4 and 4.5, closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug fortran/40853] I/O: Namelist read error

2009-08-04 Thread jvdelisle at gcc dot gnu dot org


--- Comment #10 from jvdelisle at gcc dot gnu dot org  2009-08-05 03:18 
---
Subject: Bug 40853

Author: jvdelisle
Date: Wed Aug  5 03:17:52 2009
New Revision: 150477

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150477
Log:
2009-08-04  Jerry DeLisle  

PR libfortran/40853
* gfortran.dg/namelist_40.f90: Update error output.
* gfortran.dg/namelist_47.f90: Update error output.
* gfortran.dg/namelist_58.f90: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_58.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_40.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_47.f90


-- 


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



[Bug fortran/40853] I/O: Namelist read error

2009-08-04 Thread jvdelisle at gcc dot gnu dot org


--- Comment #9 from jvdelisle at gcc dot gnu dot org  2009-08-05 03:15 
---
Subject: Bug 40853

Author: jvdelisle
Date: Wed Aug  5 03:15:18 2009
New Revision: 150476

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150476
Log:
2009-08-04  Jerry DeLisle  

PR libfortran/40853
* io/list_read.c (nml_get_obj_data): Do not set nl
pointer to first_nl if nl->next is NULL.

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


-- 


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



[Bug fortran/40969] New: [4.5 regression] gfortran.dg/c_by_val_1.f failed

2009-08-04 Thread hjl dot tools at gmail dot com
On Linux/ia64, revision 150465 gave:

FAIL: gfortran.dg/c_by_val_1.f  -O0  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O1  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O2  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -g  execution test
FAIL: gfortran.dg/c_by_val_1.f  -Os  execution test

Revision 150406 is OK.


-- 
   Summary: [4.5 regression] gfortran.dg/c_by_val_1.f failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
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=40969



[Bug bootstrap/40968] ICE when compiling O2g.gch; problem with --enable-gather-detailed-mem-stats

2009-08-04 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-08-05 01:06 
---
A Segmentation fault certainly isn't a library issue.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

  Component|libstdc++   |bootstrap


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



[Bug c++/36069] Strange "warning: suggest parentheses around assignment used as truth value" with volatile/non volatile bools

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #4 from manu at gcc dot gnu dot org  2009-08-04 23:52 ---
FIXED in GCC 4.5. Thanks for the report.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug c++/36069] Strange "warning: suggest parentheses around assignment used as truth value" with volatile/non volatile bools

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #3 from manu at gcc dot gnu dot org  2009-08-04 23:51 ---
Subject: Bug 36069

Author: manu
Date: Tue Aug  4 23:51:07 2009
New Revision: 150471

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

PR c++/36069
cp/
* typeck.c (convert_for_assignment): Do not warn for any boolean
variant. Use explicit location.
testsuite/
* g++.dg/warn/pr36069.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr36069.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

2009-08-04 Thread sje at cup dot hp dot com


--- Comment #9 from sje at cup dot hp dot com  2009-08-04 23:48 ---
Well, it got a lot further using the patch but it didn't completely bootstrap. 
The compiler built but while building libstdc++-v3 I got:

/proj/opensrc/nightly/src/trunk/libstdc++-v3/libsupc++/eh_ptr.cc: In function
'std::__exception_ptr::exception_ptr std::current_exception()':
/proj/opensrc/nightly/src/trunk/libstdc++-v3/libsupc++/eh_ptr.cc:176:31:
internal compiler error: in expand_expr_real_1, at expr.c:7427

/proj/opensrc/nightly/src/trunk/libstdc++-v3/src/ios_locale.cc: In member
function 'std::locale std::ios_base::imbue(const std::locale&)':
/proj/opensrc/nightly/src/trunk/libstdc++-v3/src/ios_locale.cc:50:20: internal
compiler error: in expand_expr_real_1, at expr.c:7427

/proj/opensrc/nightly/src/trunk/libstdc++-v3/src/locale.cc: In member function
'std::string std::locale::name() const':
/proj/opensrc/nightly/src/trunk/libstdc++-v3/src/locale.cc:124:12: internal
compiler error: in expand_expr_real_1, at expr.c:7427

and a few more, all dieing at line 7427 of expr.c


-- 


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



[Bug c++/35652] [4.3/4.4/4.5 Regression] offset warning should be given in the front-end

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #32 from manu at gcc dot gnu dot org  2009-08-04 23:42 ---
Since the patch was reverted, this is still a regression in all open branches.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |
   |patches/2009-   |
   |02/msg00285.html|
  Known to fail|4.3.0   |4.3.0 4.4.0 4.5.0
  Known to work|3.4.6 4.4.0 |3.4.6
   Last reconfirmed|2009-02-08 15:46:08 |2009-08-04 23:42:34
   date||
Summary|[4.3 Regression] offset |[4.3/4.4/4.5 Regression]
   |warning should be given in  |offset warning should be
   |the front-end   |given in the front-end


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



[Bug c++/36888] Error message when forgetting a semicolon after a class definition should be better

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #3 from manu at gcc dot gnu dot org  2009-08-04 23:32 ---
The C parser points to the start of the second declaration, which is not very
good either.

pr36888.c:5:1: error: two or more data types in declaration specifiers

In the c-parser, we can probably special case the struct/union case. It seems a
waste of time to check for keywords after the closing brace of a struct/union.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-04 23:32:42
   date||


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



[Bug libstdc++/40968] ICE when compiling O2g.gch; problem with --enable-gather-detailed-mem-stats

2009-08-04 Thread lucier at math dot purdue dot edu


--- Comment #1 from lucier at math dot purdue dot edu  2009-08-04 23:15 
---
bootstrap completes without --enable-gather-detailed-mem-stats


-- 

lucier at math dot purdue dot edu changed:

   What|Removed |Added

Summary|ICE including fenv.h when   |ICE when compiling O2g.gch;
   |compiling O2g.gch   |problem with --enable-
   ||gather-detailed-mem-stats


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



[Bug libstdc++/40968] New: ICE including fenv.h when compiling O2g.gch

2009-08-04 Thread lucier at math dot purdue dot edu
with this compiler:

Mon Aug  3 16:57:15 UTC 2009 (revision 150373)

with this configure and build:

/bin/rm -rf *; ../../mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline-mem-stats --enable-languages=c,c++
--enable-gather-detailed-mem-stats -enable-stage1-languages=c,c++; make -j 6
bootstrap >& build.log

bootstrap fails with

/home/lucier/programs/gcc/objdirs/mainline/./gcc/xgcc -shared-libgcc
-B/home/lucier/programs/gcc/objdirs/mainline/./gcc -nostdinc++
-L/home/lucier/programs/gcc/objdirs/mainline/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
-L/home/lucier/programs/gcc/objdirs/mainline/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/pkgs/gcc-mainline-mem-stats/x86_64-unknown-linux-gnu/bin/
-B/pkgs/gcc-mainline-mem-stats/x86_64-unknown-linux-gnu/lib/ -isystem
/pkgs/gcc-mainline-mem-stats/x86_64-unknown-linux-gnu/include -isystem
/pkgs/gcc-mainline-mem-stats/x86_64-unknown-linux-gnu/sys-include  -m32 -x
c++-header -D_GNU_SOURCE  -m32
-I/home/lucier/programs/gcc/objdirs/mainline/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/home/lucier/programs/gcc/objdirs/mainline/x86_64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/lucier/programs/gcc/mainline/libstdc++-v3/libsupc++ -O2 -g
/home/lucier/programs/gcc/mainline/libstdc++-v3/include/precompiled/stdtr1c++.h
-o x86_64-unknown-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch
In file included from
/home/lucier/programs/gcc/objdirs/mainline/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/tr1/cfenv:36:0,
 from
/home/lucier/programs/gcc/mainline/libstdc++-v3/include/precompiled/stdtr1c++.h:33:
/home/lucier/programs/gcc/objdirs/mainline/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/fenv.h:32:9:
internal compiler error: Segmentation fault

I'm sorry, but I don't really know how to go further in diagnosing this.


-- 
   Summary: ICE including fenv.h when compiling O2g.gch
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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



[Bug web/36739] Proposal for clarifications in GCC Bugzilla

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #3 from manu at gcc dot gnu dot org  2009-08-04 22:47 ---
We should really upgrade bugzilla to version 3.0


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-04 22:47:55
   date||


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



[Bug middle-end/40965] [graphite] slow compilation

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-08-04 22:44 ---
Eh - where's that exponential time complexity? ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org


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



[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #8 from manu at gcc dot gnu dot org  2009-08-04 22:42 ---
(In reply to comment #7)
> 
> It might be an improvement if GCC gave different diagnostics for the case 
> where
> a suitable conversion sequence exists but cannot be used because it would
> create an rvalue which cannot bind to a non-const reference, and the case 
> where
> there is no suitable conversion (i.e. the types are unrelated)

I don't even know if we have different codepaths for those!


> That seems to be what 2.95 attempted to do by saying "initializing 'blah' with
> 'blah' will use a temporary" but I find that message confusing, as it *won't*
> use a temporary because doing so is not valid.  The message should really have
> been something like "initializing 'blah' with 'blah' would use a temporary, 
> but
> that's not allowed"

Agreed. 


-- 


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



[Bug fortran/40949] FAIL: gfortran.dg/proc_ptr_7.f90

2009-08-04 Thread burnus at gcc dot gnu dot org


--- Comment #4 from burnus at gcc dot gnu dot org  2009-08-04 22:36 ---
FIXED on the trunk.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug c/40967] New: Bad Intel64 codegen for modified 39495 testcase

2009-08-04 Thread brian dot e dot bliss at intel dot com
Take the testcase for 39495, and add the "schedule(dynamic)" clause to the for
loop:

#include 
#include 

void foo(unsigned ub, unsigned *array)
{
unsigned i;

// test passes for N >= 1
#define N   0

#pragma omp for schedule(dynamic)
for (i = ub; i > N; i -=2) {
array[i] = i;
}
}

and compile with gcc -fopenmp -S.  Look at the way the parameters are set up
for the GOMP_loop_dynamic_start call:

movl$1, %ecx
movl$4294967294, %edx
movl$0, %esi
movq%rax, %rdi
callGOMP_loop_dynamic_start

This looks like ia32 codegen to me - 1 is moved into %ecx, not %rcx, and 0 is
moved into %esi, not %rsi.  The harware zero extends the %e?x registers out to
64 bits (not sure if you can rely on that or if the extended bit values are
undefined), so that doesn't cause a failure.  What causes the full testcase to
crash is that moving 4294967294 into %edx causes %rdx = 0xfffe, not
0xfffe = -2, the stride.  Whatever - it's obvious an ia32 code
fragment was selected instead of the intel64 version.


-- 
   Summary: Bad Intel64 codegen for modified 39495 testcase
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brian dot e dot bliss at intel dot com


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



[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

2009-08-04 Thread bonzini at gnu dot org


--- Comment #8 from bonzini at gnu dot org  2009-08-04 22:30 ---
Created an attachment (id=18304)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18304&action=view)
plausible patch


The patch adds back the mode of operation corresponding to
promote_nominal_mode's assignment.  It turns out that it's needed in another
place and that it can be defined relatively easily in the documentation.

I'll try bootstrapping it tomorrow.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

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


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



[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

2009-08-04 Thread sje at cup dot hp dot com


--- Comment #7 from sje at cup dot hp dot com  2009-08-04 21:23 ---
I think I got things backwards in my last comment.  In the old code
promoted_nominal_mode was set by a call to promote_mode which had the ifdef
POINTERS_EXTEND_UNSIGNED in it to set unsignedp for REFERENCE and POINTER
types.

In the new code we call promote_function_mode and this code doesn't have that
ifdef.

So I think, for HP-UX, I need to define TARGET_PROMOTE_FUNCTION_MODE, assuming
we don't want the ifdef POINTERS_EXTEND_UNSIGNED in promote_function_mode.


-- 


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



[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

2009-08-04 Thread sje at cup dot hp dot com


--- Comment #6 from sje at cup dot hp dot com  2009-08-04 21:04 ---
I am currently looking at assign_parm_setup_reg, in the old code with test2.c,
we set promoted_nominal_mode being set to DImode and then we get a conversion
because promoted_nominal_mode != data->promoted_mode.  In the new code
promoted_nominal_mode is set to SImode (the same as data->promoted_node) and so
we don't enter the if statement where the ptr_extend conversion is done in the
old code.  promoted_nominal_mode was set by a call to promote_function_node and
is now being set by a call to promote_mode.


-- 


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



[Bug rtl-optimization/40924] [4.4 Regression] miscompiles with -03 (seemingly related to attribute may_alias)

2009-08-04 Thread jakub at gcc dot gnu dot org


--- Comment #5 from jakub at gcc dot gnu dot org  2009-08-04 20:56 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00226.html


-- 

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 |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||08/msg00226.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-07-31 11:14:45 |2009-08-04 20:56:23
   date||


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



[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure

2009-08-04 Thread dodji at gcc dot gnu dot org


--- Comment #4 from dodji at gcc dot gnu dot org  2009-08-04 20:01 ---
Fixed in 4.5 and 4.4 branches. Won't be fixed in 4.3 as this fix depends on the
fix for PR c++/37971, and that later fix hasn't been applied to the 4.3 branch.

Can this bug be closed still ?


-- 


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



[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure

2009-08-04 Thread dodji at gcc dot gnu dot org


--- Comment #3 from dodji at gcc dot gnu dot org  2009-08-04 19:59 ---
Subject: Bug 39987

Author: dodji
Date: Tue Aug  4 19:59:48 2009
New Revision: 150468

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150468
Log:
2009-08-04  Dodji Seketeli  

gcc/cp/ChangeLog:
PR c++/39987
* pt.c (tsubst_default_argument): Let access checks of the
default argument happen in the context of the current function.

gcc/testsuite/ChangeLog:
PR c++/39987
* g++.dg/overload/defarg4.C: New test.


Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/pt.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/40966] [cxx0x-lambda] ICE

2009-08-04 Thread pedro dot lamarao at gmail dot com


--- Comment #1 from pedro dot lamarao at gmail dot com  2009-08-04 19:55 
---
Created an attachment (id=18303)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18303&action=view)
Preprocessed source that triggered the ICE


-- 


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



[Bug c++/40966] New: [cxx0x-lambda] ICE

2009-08-04 Thread pedro dot lamarao at gmail dot com
I'm seeing the following ICE with current a cxx0x-lambda-branch compiler.


/opt/gcc-lambda/bin/g++ -Iinclude -I../cxx_device/include
-I../cxx_network/include/network -MD -std=c++0x -save-temps -Wall -Werror -O0
-g3 -fPIC -pthread -include src/throw_select_server/config.hpp -c -o
bin/throw_select_server_main.o src/main.cpp
In file included from
/opt/gcc-lambda/lib/gcc/i586-redhat-linux/4.5.0/../../../../include/c++/4.5.0/algorithm:62:0,
 from include/sigyn/server/select_server.hpp:23,
 from ./src/throw_select_server/config.hpp:3,
 from :3:
/opt/gcc-lambda/lib/gcc/i586-redhat-linux/4.5.0/../../../../include/c++/4.5.0/bits/stl_algo.h:
In instantiation of ‘_FIter std::remove_if(_FIter, _FIter, _Predicate) [with
_FIter =
__gnu_cxx::__normal_iterator*,
std::vector > >,
_Predicate = sigyn::server::select_server::run()
[with Handler = sigyn::handler::throw_event_handler, ExceptionPolicy =
sigyn::server::default_exception_policy]::__lambda0]’:
include/sigyn/server/select_server.hpp:158:5:   instantiated from ‘void
sigyn::server::select_server::run() [with Handler =
sigyn::handler::throw_event_handler, ExceptionPolicy =
sigyn::server::default_exception_policy]’
src/main.cpp:59:30:   instantiated from here
/opt/gcc-lambda/lib/gcc/i586-redhat-linux/4.5.0/../../../../include/c++/4.5.0/bits/stl_algo.h:1165:5:
internal compiler error: vector VEC(tree,base) index domain error, in
discriminator_for_local_entity at cp/mangle.c:1484
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: ** [bin/throw_select_server_main.o] Erro 1


[pedro.lama...@larissa cxx_network]$ /opt/gcc-lambda/bin/g++ -v
Using built-in specs.
Target: i586-redhat-linux
Configured with: ../cxx0x-lambda/configure --prefix=/opt/gcc-lambda
--enable-bootstrap --enable-shared --enable-threads=posix --enable-checking
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++ --with-tune=generic --with-arch=i586
--build=i586-redhat-linux
Thread model: posix
gcc version 4.5.0 20090803 (experimental) (GCC)


-- 
   Summary: [cxx0x-lambda] ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pedro dot lamarao at gmail dot com
 GCC build triplet: i586-redhat-linux


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



[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure

2009-08-04 Thread dodji at gcc dot gnu dot org


--- Comment #2 from dodji at gcc dot gnu dot org  2009-08-04 19:50 ---
Subject: Bug 39987

Author: dodji
Date: Tue Aug  4 19:49:48 2009
New Revision: 150467

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150467
Log:
2009-08-04  Dodji Seketeli  

gcc/cp/ChangeLog:
PR c++/39987
* pt.c (tsubst_default_argument): Let access checks of the
default argument happen in the context of the current function.

gcc/testsuite/ChangeLog:
PR c++/39987
* g++.dg/overload/defarg4.C: New test.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug target/40577] ICE on valid code: in extract_insn

2009-08-04 Thread ubizjak at gmail dot com


--- Comment #8 from ubizjak at gmail dot com  2009-08-04 19:27 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||07/msg01637.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.5


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



[Bug target/40577] ICE on valid code: in extract_insn

2009-08-04 Thread uros at gcc dot gnu dot org


--- Comment #7 from uros at gcc dot gnu dot org  2009-08-04 19:25 ---
Subject: Bug 40577

Author: uros
Date: Tue Aug  4 19:25:05 2009
New Revision: 150466

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150466
Log:
Backport from mainline:
2009-08-03  Uros Bizjak  

* config/alpha/alpha.c (alpha_legitimate_constant_p): Reject CONST
constants referencing TLS symbols.

2009-07-29  Uros Bizjak  

PR target/40577
* config/alpha/alpha.c (alpha_expand_unaligned_store): Convert src
to DImode when generating insq_le insn.


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


-- 


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



[Bug middle-end/40965] [graphite] slow compilation

2009-08-04 Thread jv244 at cam dot ac dot uk


--- Comment #1 from jv244 at cam dot ac dot uk  2009-08-04 19:23 ---
Created an attachment (id=18302)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18302&action=view)
testcase


-- 


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



[Bug middle-end/40965] New: [graphite] slow compilation

2009-08-04 Thread jv244 at cam dot ac dot uk
the attached testcase compiles in about 3s with

gfortran -c  -ffree-form -O3 -ffast-math -ftree-vectorize -funroll-loops
-march=native -ftime-report bug.f90

but requires about 130s adding -fgraphite-identity to the options

GRAPHITE loop transforms: 123.82 (97%) usr   0.59 (89%) sys 124.37 (97%) wall  
 2262 kB ( 7%) ggc


-- 
   Summary: [graphite] slow compilation
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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



[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

2009-08-04 Thread jwakely dot gcc at gmail dot com


--- Comment #7 from jwakely dot gcc at gmail dot com  2009-08-04 17:48 
---
(In reply to comment #5)
> Here's a small testcase: 
>  
> struct B {}; 
> struct D : B {}; 
>  
> struct S { 
> int foo(B* & taskData); 
> }; 
>  
> int i = S().foo((D*)0); 
> - 

That tries to initialise a B*& with a D* rvalue, which would fail even if D was
the same type as B.  This might be a slightly better testcase:

struct B {}; 
struct D : B {}; 

struct S { 
int foo(B* & taskData); 
}; 

D* p = 0;
int i = S().foo(p); 


It might be an improvement if GCC gave different diagnostics for the case where
a suitable conversion sequence exists but cannot be used because it would
create an rvalue which cannot bind to a non-const reference, and the case where
there is no suitable conversion (i.e. the types are unrelated)

That seems to be what 2.95 attempted to do by saying "initializing 'blah' with
'blah' will use a temporary" but I find that message confusing, as it *won't*
use a temporary because doing so is not valid.  The message should really have
been something like "initializing 'blah' with 'blah' would use a temporary, but
that's not allowed"


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

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


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



[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

2009-08-04 Thread sje at cup dot hp dot com


--- Comment #5 from sje at cup dot hp dot com  2009-08-04 17:46 ---
Created an attachment (id=18301)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18301&action=view)
Better test case

Here is a better test case that actually shows bad code being generated.  In
r150335, we extend r32 with 'addp4 r32 = 0, r32' and that is fine.  In the new
code we combine the addp4 with a move and generate 'addp4 r8 = r32, r0'  This
is wrong, if we generated 'addp4 - r0, r32' then we would be OK.  addp4 is not
a symetrical operation and the first argument should be an offset (often zero)
and the second argument should be a 32 bit pointer that we want to extend to 64
bits before dereferencing.  addp4 uses the REG_POINTER attribute to distinguish
between offsets and pointers.


-- 


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



[Bug fortran/40949] FAIL: gfortran.dg/proc_ptr_7.f90

2009-08-04 Thread burnus at gcc dot gnu dot org


--- Comment #3 from burnus at gcc dot gnu dot org  2009-08-04 17:36 ---
Subject: Bug 40949

Author: burnus
Date: Tue Aug  4 17:35:59 2009
New Revision: 150465

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150465
Log:
2009-08-04  Tobias Burnus  

PR fortran/40949
* trans-types.c (gfc_get_function_type): Fix typelist of
functions without argument.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c


-- 


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



[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

2009-08-04 Thread sje at cup dot hp dot com


--- Comment #4 from sje at cup dot hp dot com  2009-08-04 17:09 ---
Created an attachment (id=18300)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18300&action=view)
Testcase

This test case shows the difference in generated code between r150335 and
r150336.  It does not actually generate wrong code, just different (technically
better) code.

In this case on IA64 HP-UX we no longer generate some addp4 instructions to
extend pointer arguments from 32 bits to 64 bits.  In this code the addp4's are
not needed but I am guessing somewhere in gengtype they are not getting
generated and are needed.


-- 


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



[Bug debug/39706] namespaces represented incorrectly in debug_pubnames

2009-08-04 Thread dodji at gcc dot gnu dot org


--- Comment #8 from dodji at gcc dot gnu dot org  2009-08-04 17:06 ---
Fixed in 4.3 as well.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug debug/39706] namespaces represented incorrectly in debug_pubnames

2009-08-04 Thread dodji at gcc dot gnu dot org


--- Comment #7 from dodji at gcc dot gnu dot org  2009-08-04 16:59 ---
Subject: Bug 39706

Author: dodji
Date: Tue Aug  4 16:59:11 2009
New Revision: 150462

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150462
Log:
2009-08-04  Dodji Seketeli  

gcc/cp/ChangeLog:
PR debug/39706
* error.c (lang_decl_name): Print qualified names for decls
in  namespace scope.

gcc/testsuite/ChangeLog:
PR debug/39706
* g++.dg/debug/dwarf2/pubnames-1.C: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/debug/dwarf2/pubnames-1.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/error.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above

2009-08-04 Thread jamborm at gcc dot gnu dot org


--- Comment #8 from jamborm at gcc dot gnu dot org  2009-08-04 16:54 ---
Right. The number in identifiers I see are different, of course, but
what happens is this.  Early SRA replaces structure b.3 with
SR.4_25. In BB2, it is assigned into from parameter b:

  SR.4_25 = b._M_value;

This assignment survives until complex lowering which expands it into:

  SR.4$real_7 = REALPART_EXPR ;
  SR.4$imag_1 = IMAGPART_EXPR ;
  SR.4_25 = COMPLEX_EXPR ;

Note that the b.3 is back, although it should have died long time
ago and that leads to the varasm ICE.

What is even more weird however, is how tree-complex.c comes upon that
variable.  In extract_component() it correctly builds rhs
REALPART_EXPR  but then it feeds it into
force_gimple_operand_gsi() which in turns inserts the bogus statements
into the stream.

So that is where to look now, I suppose.  I wonder how come the
behavior is target specific, though.  Well, let me see.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-04 16:54:23
   date||


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



[Bug c++/35075] [4.3/4.4/4.5 regression] ICE with references in templates

2009-08-04 Thread paolo dot carlini at oracle dot com


--- Comment #7 from paolo dot carlini at oracle dot com  2009-08-04 16:51 
---
Nope...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|ASSIGNED|NEW


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



[Bug c++/38646] [4.3/4.4/4.5 regression] ICE with invalid specialization of variadic template

2009-08-04 Thread paolo dot carlini at oracle dot com


--- Comment #6 from paolo dot carlini at oracle dot com  2009-08-04 16:50 
---
Never mind, tried with a non-checking GCC...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

Summary|[4.3/4.4 regression] ICE|[4.3/4.4/4.5 regression] ICE
   |with invalid specialization |with invalid specialization
   |of variadic template|of variadic template


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



[Bug c++/35075] [4.3/4.4/4.5 regression] ICE with references in templates

2009-08-04 Thread paolo dot carlini at oracle dot com


--- Comment #6 from paolo dot carlini at oracle dot com  2009-08-04 16:43 
---
Seems easy to fix now...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|NEW |ASSIGNED


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



[Bug c++/38646] [4.3/4.4 regression] ICE with invalid specialization of variadic template

2009-08-04 Thread paolo dot carlini at oracle dot com


--- Comment #5 from paolo dot carlini at oracle dot com  2009-08-04 16:35 
---
This one doesn't reproduce anymore in mainline.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

Summary|[4.3/4.4/4.5 regression] ICE|[4.3/4.4 regression] ICE
   |with invalid specialization |with invalid specialization
   |of variadic template|of variadic template


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



[Bug c++/36069] Strange "warning: suggest parentheses around assignment used as truth value" with volatile/non volatile bools

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #2 from manu at gcc dot gnu dot org  2009-08-04 16:23 ---
Confirmed in trunk.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-04 16:23:02
   date||


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



[Bug fortran/40963] ICE segfault - c_loc with derived type component as argument

2009-08-04 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2009-08-04 16:14 ---
The issue is that the expression is an array ("expr->rank > 0") but the symbol
itself is not, only it's component.


==16545== Invalid read of size 4
==16545==at 0x55343F: gfc_conv_procedure_call (trans-expr.c:2441)
==16545==by 0x547595F: ???
==16545==by 0x4FBD06: gfc_match_actual_arglist (primary.c:1670)

That's the last line in:

  if (sym->intmod_sym_id == ISOCBINDING_LOC)
[...]
  if (arg->expr->rank == 0)
gfc_conv_expr_reference (se, arg->expr);
  else
{[...]
  /* We should want it to do g77 calling convention.  */
  f = (fsym != NULL)
&& !(fsym->attr.pointer || fsym->attr.allocatable)
&& fsym->as->type != AS_ASSUMED_SHAPE;


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2009-08-04 16:14:31
   date||


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



[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.

2009-08-04 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target
 GCC target triplet||ia64-portbld-freebsd8.0


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



[Bug fortran/40962] Conversion problem for f-allocatable -> cptr -> fptr -> f-allocatable

2009-08-04 Thread burnus at gcc dot gnu dot org


--- Comment #3 from burnus at gcc dot gnu dot org  2009-08-04 16:09 ---
Thomas, as you know a bit about the array descriptor, can you have a look? The
problem seems to be in libgfortran/intrinsics/iso_c_binding.c's c_f_pointer*

Simplified test case:
One:  1  2 -1 -2
Two:  1  2  2 -1  
   ^

The dump is trival:
  D.1581 = (void *) &table;
  D.1582 = D.1581;
  set_table (&D.1582);
and
c_f_pointer_i4 (*cptr, &table_tmp, &parm.1);

Thus the issue must be in
c_f_pointer_i4


program main
   use iso_c_binding, only: c_ptr, c_loc, c_f_pointer
   implicit none
   integer, dimension(2,1,2), target :: table
   table = reshape ( (/ 1,2,-1,-2/), (/2,1,2/))
!   print '(a,12i3)', "One:", table
   call set_table (c_loc (table))
contains
   subroutine set_table (cptr)
 type(c_ptr), intent(in) :: cptr
 integer, dimension(:,:,:), pointer :: table_tmp
 call c_f_pointer (cptr, table_tmp, (/2,1,2/))
! print '(a,12i3)', "Two:", table_tmp
   end subroutine set_table
end program main


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org, tkoenig at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|4.5.0 Ref. svn r150253  |
   GCC host triplet|Linux 32bit, 64bit, MAC OS X|
 GCC target triplet|gcc, gfortran 4.3.2, 4.4.0, |
   |4.5.0   |
   Keywords||wrong-code
  Known to fail||4.5.0 4.4.0 4.3.2
   Last reconfirmed|-00-00 00:00:00 |2009-08-04 16:09:45
   date||
Summary|[4.5.0,4.4.0,4.3.2] |Conversion problem for  f-
   |conversion problem for  f-  |allocatable -> cptr -> fptr
   |allocatable -> cptr -> fptr |-> f-allocatable
   |-> f-allocatable|


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



[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #6 from manu at gcc dot gnu dot org  2009-08-04 16:02 ---
This is still valid and it does not depend on -fpermissive. It would be
interesting to see what is the output from other C++ compilers.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2005-12-18 20:30:27 |2009-08-04 16:02:11
   date||


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



[Bug c++/16696] Strange message when operator++ not found

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #13 from manu at gcc dot gnu dot org  2009-08-04 15:52 ---
FIXED in GCC 4.5.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug c++/16696] Strange message when operator++ not found

2009-08-04 Thread manu at gcc dot gnu dot org


--- Comment #12 from manu at gcc dot gnu dot org  2009-08-04 15:51 ---
Subject: Bug 16696

Author: manu
Date: Tue Aug  4 15:51:12 2009
New Revision: 150461

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

PR c++/16696
cp/
* call.c (build_new_op): Only try prefix operator if -fpermissive,
otherwise just error.
testsuite/
* g++.dg/parse/pr16696.C: New.
* g++.dg/parse/pr16696-permissive.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr16696-permissive.C
trunk/gcc/testsuite/g++.dg/parse/pr16696.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug middle-end/40964] [4.5 Regression] ICE in insert_vi_for_tree

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-08-04 15:50 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2009-08-04 15:50:46
   date||
Summary|ICE in insert_vi_for_tree   |[4.5 Regression] ICE in
   ||insert_vi_for_tree
   Target Milestone|--- |4.5.0


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



[Bug middle-end/40964] New: ICE in insert_vi_for_tree

2009-08-04 Thread matz at gcc dot gnu dot org
% cat bla.c
struct alloc2 {
int bla;
char * __restrict data;
char * __restrict data2;
};
struct alloc2 b;
void * f (void)
{  return b.data;}

% ./cc1 -O2 bla.c
bla.c:12:1: internal compiler error: in insert_vi_for_tree, at
tree-ssa-structalias.c:2586

Problem is that the struct contains two restrict pointers, which confuses
the hash table machinery for varinfos.


-- 
   Summary: ICE in insert_vi_for_tree
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org


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



[Bug fortran/40963] ICE segfault - c_loc with derived type component as argument

2009-08-04 Thread rohou at brandeis dot edu


--- Comment #1 from rohou at brandeis dot edu  2009-08-04 15:22 ---
Created an attachment (id=18299)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18299&action=view)
Source file to cause the segfault

I used option -save-temps, but could not find a *.i file, so I have attached
the *.f90 file instead.


-- 


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



[Bug fortran/40963] New: ICE segfault - c_loc with derived type component as argument

2009-08-04 Thread rohou at brandeis dot edu
(first bug I'm reporting, apologies if duplicate or info missing)


== COMPILE-TIME OUTPUT ==
gfortran -I. -Isrc/  -v  -save-temps -Wall -fbounds-check  -O2 -ffree-form -c
-o main.o /gusr/alr99/cluster/workspace/helloworld/main.f90
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3.3/configure
--prefix=/nexsan3/sware64/gnu/gcc-4.3.3/linux64
--with-mpfr=/nexsan3/sware64/mpfr/linux64 --enable-languages=all
Thread model: posix
gcc version 4.3.3 (GCC)
COLLECT_GCC_OPTIONS='-I.' '-Isrc/' '-v' '-save-temps' '-Wall' '-fbounds-check'
'-O2' '-ffree-form' '-c' '-o' 'main.o' '-mtune=generic'

/nexsan3/sware64/gnu/gcc-4.3.3/linux64/libexec/gcc/x86_64-unknown-linux-gnu/4.3.3/f951
/gusr/alr99/cluster/workspace/helloworld/main.f90 -quiet -dumpbase main.f90
-mtune=generic -auxbase-strip main.o -O2 -Wall -version -fbounds-check
-ffree-form -I. -Isrc/ -fintrinsic-modules-path
/nexsan3/sware64/gnu/gcc-4.3.3/linux64/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/finclude
-o main.s
GNU F95 (GCC) version 4.3.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.1.4, MPFR version
2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/gusr/alr99/cluster/workspace/helloworld/main.f90: In function ‘testcloc’:
/gusr/alr99/cluster/workspace/helloworld/main.f90:1: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [main.o] Error 1


-- 
   Summary: ICE segfault - c_loc with derived type component as
argument
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rohou at brandeis dot edu


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



[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

2009-08-04 Thread sje at cup dot hp dot com


--- Comment #3 from sje at cup dot hp dot com  2009-08-04 14:59 ---
No, the patch in comment #2 did not fix the problem.  I did a non-bootstrap
build followed by a testsuite run hoping I would get a failure there with a
nice small test case but I didn't get any unexpected failures.


-- 


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



[Bug c/40960] POSIX requires that option -D have a lower precedence than -U

2009-08-04 Thread joseph at codesourcery dot com


--- Comment #4 from joseph at codesourcery dot com  2009-08-04 14:54 ---
Subject: Re:  POSIX requires that option -D have a lower precedence
 than -U

On Tue, 4 Aug 2009, vincent at vinc17 dot org wrote:

> There would the possibility to have a POSIX mode implied by c99, but I don't
> think having different behaviors would be a good idea. IMHO, Makefiles should

I think that installing a variant driver program as "c99", that implements 
the different semantics, is exactly the right thing to do here; the 
present semantics are more useful for "gcc".  We should have a configure 
option to install "cc", "c89" and "c99" drivers; they should have 
appropriate defaults regarding e.g. standards mode, and should also adjust 
the precedence of these options and make any other adjustments required by 
POSIX that aren't appropriate for "gcc".


-- 


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



[Bug fortran/40962] [4.5.0,4.4.0,4.3.2] conversion problem for f-allocatable -> cptr -> fptr -> f-allocatable

2009-08-04 Thread reuter at physik dot uni-freiburg dot de


--- Comment #2 from reuter at physik dot uni-freiburg dot de  2009-08-04 
14:25 ---
Created an attachment (id=18298)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18298&action=view)
iso_varying_string.f90 needed for the example 


-- 


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



[Bug fortran/40962] [4.5.0,4.4.0,4.3.2] conversion problem for f-allocatable -> cptr -> fptr -> f-allocatable

2009-08-04 Thread reuter at physik dot uni-freiburg dot de


--- Comment #1 from reuter at physik dot uni-freiburg dot de  2009-08-04 
14:25 ---
Created an attachment (id=18297)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18297&action=view)
test program for the bug report


-- 


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



[Bug fortran/40962] New: [4.5.0,4.4.0,4.3.2] conversion problem for f-allocatable -> cptr -> fptr -> f-allocatable

2009-08-04 Thread reuter at physik dot uni-freiburg dot de
The following test code below (which works with the NAG 5.2 Fortran Compiler) 
seems to choke over the conversion f-allocatable -> cptr -> fptr ->
f-allocatable. With NAG the output should be:
--
nagfor tab3.f90 -o tab3 && ./tab3
NAG Fortran Compiler Release 5.2(686)
[NAG Fortran Compiler normal termination]
In:   1  2  3  4  5  6 -1 -2 -3 -4 -5 -6
Tmp:  1  2  3  4  5  6 -1 -2 -3 -4 -5 -6
Out:  1  2  3  4  5  6 -1 -2 -3 -4 -5 -6
-


For gfortran 4.5.0 the result is:
In:   1  2  3  4  5  6 -1 -2 -3 -4 -5 -6
Tmp:  1  2  3 -1 -2 -3 -1 -2 -3 -4 -5 -6
Out:  1  2  3 -1 -2 -3 -4 -5 -6  0  0  0


while for gfortran 4.3.2 the result is:
-
In:   1  2  3  4  5  6 -1 -2 -3 -4 -5 -6
Tmp:  1  2  3 -1 -2 -3 -1 -2 -3 -4 -5 -6
Out:  1  2  3 -1 -2 -3 -4 -5 -6 ** **  0

It looks as if the order of indices gets confused by gfortran in changing the
corresponding pointers. According to the F2003 Handbook this code should be
allowed. 


TEST PROGRAM:


--
program main

   use iso_c_binding
   implicit none

   character(*), parameter :: fmt = "(A,40(1x,I2))"

   integer, parameter :: n1 = 2
   integer, parameter :: n2 = 3
   integer, parameter :: n3 = 2

   integer, dimension(2), parameter :: shape2 = (/ n1, n2 /)
   integer, dimension(3), parameter :: shape3 = (/ n1, n2, n3 /)

   integer, dimension(n1, n2), parameter :: &
 c0001 = reshape ( (/  1, 2,  3, 4,  5, 6 /), shape2)
   integer, dimension(n1, n2), parameter :: &
 c0002 = reshape ( (/ -1,-2, -3,-4, -5,-6 /), shape2)
   integer, dimension(n1, n2, n3), parameter :: &
 table_in = reshape ( (/ c0001, c0002 /), shape3)

   integer, dimension(:,:,:), allocatable, target :: table_out

   print fmt, "In: ", table_in

   ! Allocate table_out with shape=shape3
   allocate (table_out (n1, n2, n3))

   ! Set table_out via a C pointer
   call set_table (c_loc (table_out))

   print fmt, "Out:", table_out

contains

   subroutine set_table (cptr)

 type(c_ptr), intent(in) :: cptr
 integer, dimension(:,:,:), pointer :: table_tmp

 ! This should make table_tmp an alias to table_out
 call c_f_pointer (cptr, table_tmp, shape3)

 ! Now set the value of table_tmp
 table_tmp = table_in

 print fmt, "Tmp:", table_tmp

   end subroutine set_table

end program main
--


-- 
   Summary: [4.5.0,4.4.0,4.3.2] conversion problem for  f-
allocatable -> cptr -> fptr -> f-allocatable
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reuter at physik dot uni-freiburg dot de
 GCC build triplet: 4.5.0 Ref. svn r
  GCC host triplet: Linux 32bit, 64bit, MAC OS X
GCC target triplet: gcc, gfortran 4.3.2, 4.4.0, 4.5.0


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



[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure

2009-08-04 Thread dodji at gcc dot gnu dot org


--- Comment #1 from dodji at gcc dot gnu dot org  2009-08-04 14:21 ---
Submitted a patch to http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00185.html


-- 


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



[Bug target/40957] [4.5 Regression] standard_sse_constant_opcode crash on x86 64

2009-08-04 Thread hjl dot tools at gmail dot com


--- Comment #2 from hjl dot tools at gmail dot com  2009-08-04 14:15 ---
(In reply to comment #1)
> We enter standard_sse_constant_opcode with:
> 
> (const_vector:V4DI [
> (const_int -1 [0x])
> (const_int -1 [0x])
> (const_int -1 [0x])
> (const_int -1 [0x])
> ])
> 
> And standard_sse_constant_p returns 3 in this case.
> 
> H.J., can this operation be implemented with AVX vcmpeq instruction?
> 

We need to 2 insns to generate all 1s for 256bit.


-- 


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



[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

2009-08-04 Thread mikpe at it dot uu dot se


--- Comment #6 from mikpe at it dot uu dot se  2009-08-04 14:07 ---
Hang on, the test case looks invalid:

> ReadCfgFile (char *cfg_file)
> {
>   void *conf_handler;
>   int i;
>   struct sockaddr_in nsaddr_list[0];
>   char *nserver_str;
>   qp_getconf_array_str (conf_handler, "Nameservers", i, &nserver_str, 0);
>   (*__res_state ()).nsaddr_list[(*__res_state ()).nscount++] = nsaddr_list[0];
> }

This has a zero-element array as a local variable, which it then fetches an
element from. That's clearly invalid. Changing it as follows

-  struct sockaddr_in nsaddr_list[0];
+  struct sockaddr_in nsaddr_list[1];

makes the test case work for me, even without -mtune=xscale.


-- 


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



[Bug fortran/40961] New: Document set_fpe(int)

2009-08-04 Thread burnus at gcc dot gnu dot org
We list a lot of library initialization functions at
  http://gcc.gnu.org/onlinedocs/gfortran/Non_002dFortran-Main-Program.html
however, _gfortran_set_fpe(int) is missing.

Currently, it is set via -ffpe-trap=<*>

Possible values are:
/* Bitmasks for the various FPE that can be enabled.  */
#define GFC_FPE_INVALID(1<<0)
#define GFC_FPE_DENORMAL   (1<<1)
#define GFC_FPE_ZERO   (1<<2)
#define GFC_FPE_OVERFLOW   (1<<3)
#define GFC_FPE_UNDERFLOW  (1<<4)
#define GFC_FPE_PRECISION  (1<<5)


-- 
   Summary: Document set_fpe(int)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: documentation
  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=40961



[Bug c/40960] POSIX requires that option -D have a lower precedence than -U

2009-08-04 Thread jakub at gcc dot gnu dot org


--- Comment #3 from jakub at gcc dot gnu dot org  2009-08-04 14:01 ---
And the GCC behavior makes much more sense than the POSIX required for c99.


-- 


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



[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

2009-08-04 Thread mikpe at it dot uu dot se


--- Comment #5 from mikpe at it dot uu dot se  2009-08-04 13:58 ---
Confirmed with gcc-4.3-20090802, gcc-4.4-20090728, and gcc-4.5-20090730.
Passing -mtune=xscale to gcc prevents the ICE.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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



[Bug target/40957] [4.5 Regression] standard_sse_constant_opcode crash on x86 64

2009-08-04 Thread hjl dot tools at gmail dot com


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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



[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before

2009-08-04 Thread andriys at gmail dot com


--- Comment #7 from andriys at gmail dot com  2009-08-04 13:53 ---
Created an attachment (id=18296)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18296&action=view)
Yet another test case

This test checks whether main executable and dll share common
abi::__cxa_eh_globals structure.


-- 


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



[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395

2009-08-04 Thread mkuvyrkov at gcc dot gnu dot org


--- Comment #17 from mkuvyrkov at gcc dot gnu dot org  2009-08-04 13:43 
---
I'll try the above two patches and will report in a couple of days.


-- 


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



[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before

2009-08-04 Thread andriys at gmail dot com


--- Comment #6 from andriys at gmail dot com  2009-08-04 13:41 ---
(In reply to comment #5)
> I cannot comment on the build of libsdc++.dll in the mingw 4.4.0 release since
> I have not looked at that source. 
There is a patch file that is shipped along with the mingw 4.4.0 build
instructions/script. The patch adds most of the essential things that the Dave
Korn's patch does (i.e. __attribute__((dllimport)) decorations and
-no-undefined linker option.) I believe the official MinGW binaries were built
with that patch applied. Well, there are your E-mail at the top of that patch
file...

> Applying Dave Korn's patch mentioned in Comment #2, and linking against
> libstdc++.dll, I get this with your original testcaase:
> 
> Expecting 'true', got 'true'
> Expecting 'false', got 'false'
> 
Where this patch is supposed to be applied to? trunk?
I have looked through the patches you are referring to and through the source
in repository. As far as I can see, libsupc++ is still static only, and
eh_globals.cc is a part of libsupc++, not libstdc++. The fact that test-case
works correctly for you could be just a coincidence. The more reliable way to
check for the problem would be to compare the value returned by the
__cxa_get_globals() when being from the main executable and from the dll
respectively. I'll prepare the new test case.


-- 


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



[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395

2009-08-04 Thread bergner at gcc dot gnu dot org


--- Comment #16 from bergner at gcc dot gnu dot org  2009-08-04 13:35 
---
There have been many patches posted, but most have caused serious performance
degradations on power.  However, the two latest patches to reload do not.  They
are:

 1) http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00816.html
 2) http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00823.html

Maxim, have you tried either of these patches and do they work for you?

Uli, can you please have a look at Richard's and Paolo's patches and does one
or the other seem like a "better" fix?


-- 

bergner at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu dot
   ||org


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



[Bug c++/38646] [4.3/4.4/4.5 regression] ICE with invalid specialization of variadic template

2009-08-04 Thread paolo dot carlini at oracle dot com


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|ASSIGNED|NEW


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



[Bug c/40960] POSIX requires that option -D have a lower precedence than -U

2009-08-04 Thread vincent at vinc17 dot org


--- Comment #2 from vincent at vinc17 dot org  2009-08-04 13:29 ---
There would the possibility to have a POSIX mode implied by c99, but I don't
think having different behaviors would be a good idea. IMHO, Makefiles should
be fixed to stick to POSIX.

Also, portable Makefiles, i.e. that work with other compilers, should not be
affected.

Note that Sun cc 5.0 is correct. And gcc 2.95.3 was also correct! (That's old,
but this is on an old Solaris machine where I still have an account.)


-- 


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



[Bug target/40957] standard_sse_constant_opcode crash on x86 64

2009-08-04 Thread ubizjak at gmail dot com


--- Comment #1 from ubizjak at gmail dot com  2009-08-04 13:21 ---
We enter standard_sse_constant_opcode with:

(const_vector:V4DI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])

And standard_sse_constant_p returns 3 in this case.

H.J., can this operation be implemented with AVX vcmpeq instruction?


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-04 13:21:16
   date||


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



[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395

2009-08-04 Thread mkuvyrkov at gcc dot gnu dot org


--- Comment #15 from mkuvyrkov at gcc dot gnu dot org  2009-08-04 13:14 
---
There are several (4, I think) patches posted in gcc-patches@ for this bug.  A
reload/recog maintainer is needed to choose the most appropriate one.


-- 


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



[Bug libstdc++/15523] [DR 408] Can't have vectors of vector::const_iterator

2009-08-04 Thread paolo dot carlini at oracle dot com


--- Comment #15 from paolo dot carlini at oracle dot com  2009-08-04 13:04 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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



[Bug libstdc++/15523] [DR 408] Can't have vectors of vector::const_iterator

2009-08-04 Thread paolo at gcc dot gnu dot org


--- Comment #14 from paolo at gcc dot gnu dot org  2009-08-04 13:01 ---
Subject: Bug 15523

Author: paolo
Date: Tue Aug  4 13:01:08 2009
New Revision: 150455

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150455
Log:
2009-08-04  Paolo Carlini  

PR libstdc++/15523
* include/debug/safe_iterator.h (_Safe_iterator<>::
_Safe_iterator(const _Safe_iterator&), _Safe_iterator<>::
operator=(const _Safe_iterator&)): Implement resolution of DR 408,
do not error out when the source is a value-initialized iterator.
* testsuite/23_containers/vector/15523.cc: New.
* doc/xml/manual/intro.xml: Add an entry for DR 408.

Added:
trunk/libstdc++-v3/testsuite/23_containers/vector/15523.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/intro.xml
trunk/libstdc++-v3/include/debug/safe_iterator.h


-- 


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



[Bug fortran/40875] ICE with illegal type conversion

2009-08-04 Thread pault at gcc dot gnu dot org


--- Comment #5 from pault at gcc dot gnu dot org  2009-08-04 12:53 ---
Subject: Bug 40875

Author: pault
Date: Tue Aug  4 12:41:08 2009
New Revision: 150454

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150454
Log:
2009-08-04  Paul Thomas  

PR fortran/40875
* decl.c (add_init_expr_to_sym): Character symbols can only be
initialized with character expressions.

2009-08-04  Paul Thomas  

PR fortran/40875
* gfortran.dg/initialization_23.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/initialization_23.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.

2009-08-04 Thread jwakely dot gcc at gmail dot com


--- Comment #1 from jwakely dot gcc at gmail dot com  2009-08-04 12:48 
---
Testcase can be reduced to:

struct S
{
  template 
  S (T const *)
  { }

  template 
  S (char const (&)[N])
  { }
};

int
main()
{
  S s1 ("test");
}

GCC still accepts this while Comeau rejects it.


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

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


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



[Bug c++/35075] [4.3/4.4/4.5 regression] ICE with references in templates

2009-08-04 Thread paolo dot carlini at oracle dot com


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|ASSIGNED|NEW


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



[Bug debug/39706] namespaces represented incorrectly in debug_pubnames

2009-08-04 Thread dodji at gcc dot gnu dot org


--- Comment #6 from dodji at gcc dot gnu dot org  2009-08-04 12:37 ---
Subject: Bug 39706

Author: dodji
Date: Tue Aug  4 12:28:27 2009
New Revision: 150453

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150453
Log:
2009-08-04  Dodji Seketeli  

gcc/cp/ChangeLog:
PR debug/39706
* error.c (lang_decl_name): Print qualified names for decls
in  namespace scope.

gcc/testsuite/ChangeLog:
PR debug/39706
* g++.dg/debug/dwarf2/pubnames-1.C: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/pubnames-1.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/error.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/40944] [C++0x] rejects well-formed code: SFINAE, decltype, function call

2009-08-04 Thread jwakely dot gcc at gmail dot com


--- Comment #1 from jwakely dot gcc at gmail dot com  2009-08-04 12:35 
---
I think you're right that this is a bug, this is a slightly reduced testcase
showing the same error:

template
struct make { static T&& it(); };

void (*pf)(int&) = 0;

template< typename T >
int bar(T const& x,
decltype( pf(make::it()) )* = 0 // SFINAE!
) {
return 1;
}

int bar(...) {
return 0;
}

int main() {
return bar(42);
}

I think this should compile and return 0


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

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


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



[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump

2009-08-04 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.0   |4.3.5


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



[Bug debug/39706] namespaces represented incorrectly in debug_pubnames

2009-08-04 Thread dodji at gcc dot gnu dot org


--- Comment #5 from dodji at gcc dot gnu dot org  2009-08-04 12:31 ---
Fixed in 4.4 and 4.5. Waiting for 4.3 to unfreeze ...


-- 


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



[Bug fortran/40847] [4.3/4.4/4.5 Regression] segfault & bogus warning

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug c++/40749] [4.3 Regression] g++ doesnt report missing return if return is of type const

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #7 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug target/40735] [4.3/4.4/4.5 Regression] memory hog compiling big functions with -fPIE

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #11 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 
---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug tree-optimization/39839] [4.3/4.4/4.5 regression] loop invariant motion causes stack spill

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug c++/40405] [4.3/4.4/4.5 Regression] ICE with invalid initialization of template member

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug testsuite/39807] [4.3 Regression] Reporting of testsuite failures are messed up when using -j

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #15 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 
---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug middle-end/39838] [4.3/4.4/4.5 regression] unoptimal code for two simple loops

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug tree-optimization/39799] [4.3/4.4/4.5 Regression] missing 'may be used uninitialized' warning

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug c++/39786] [4.3/4.4/4.5 Regression] Qualified name lookup through different numbers of using directives

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug objc/39753] [4.3/4.4/4.5 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug tree-optimization/39657] [4.3 Regression] compiling ruby (yacc) output takes inordinate amount of time with PRE and large SCCs

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #19 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 
---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



[Bug middle-end/39666] [4.3 Regression] spurious warning with ranged-switch statements

2009-08-04 Thread rguenth at gcc dot gnu dot org


--- Comment #9 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.5


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



  1   2   3   4   >