date:20090108

[Bug tree-optimization/37194] [4.3/4.4 Regression] Autovectorization of small constant iteration loop degrades performance

2009-01-08 Thread irar at gcc dot gnu dot org

--- Comment #9 from irar at gcc dot gnu dot org  2009-01-08 07:59 ---
Subject: Bug 37194

Author: irar
Date: Thu Jan  8 07:59:40 2009
New Revision: 143183

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143183
Log:
PR tree-optimization/37194
* tree-vect-transform.c (vect_estimate_min_profitable_iters):
Don't add the cost of cost model guard in prologue to scalar 
outside cost in case of known number of iterations.

Added:
trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-transform.c

-- 

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

[Bug libstdc++/38732] [4.4 Regression] Openoffice.org segfaults with runtime libs built from GCC trunk

2009-01-08 Thread stephan dot bergmann at sun dot com



--- Comment #20 from stephan dot bergmann at sun dot com  2009-01-08 08:31 
---
re <#c17>:

"prepended member can change the negative offset of the other struct members":
see "the four bytes of referenceCount cancel out a previous four padding bytes
just before the unwindHeader member coming later in the struct" (<#c12>)

"if they ever use std::current_exception(), they *will* have to change the code
to cope with dependent exceptions": can you please elaborate (by direct mail,
if considered more appropriate)


-- 


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

[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32

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



--- Comment #4 from dannysmith at users dot sourceforge dot net  2009-01-08 
08:41 ---
Created an attachment (id=17052)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17052&action=view)
Replace execvp with pex_one in process_command

Patch uses pex_one as per Ian Taylor suggestion , but the error reporting may
need expansion.
Danny


-- 


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

[Bug libstdc++/38741] Unable to write data to wofstream

2009-01-08 Thread radhika dot ganganna at oracle dot com



--- Comment #4 from radhika dot ganganna at oracle dot com  2009-01-08 
08:58 ---
Created an attachment (id=17053)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17053&action=view)
Testcase which demonstrates the error

The code writes the wstring "Forecast" 100 times to wofstream. 
When I executed the program it ouput the wstring 25 times and stopped. 
The wofstream doesn't set any error bit. 
Please let me know if there is some buffor which needs to be refreshed. How to
do it? 

Regards,
Radhika


-- 

radhika dot ganganna at oracle dot com changed:

   What|Removed |Added

  Attachment #17044|0   |1
is obsolete||


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

[Bug libstdc++/38741] Unable to write data to wofstream

2009-01-08 Thread radhika dot ganganna at oracle dot com



--- Comment #5 from radhika dot ganganna at oracle dot com  2009-01-08 
08:59 ---
Created an attachment (id=17054)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17054&action=view)
nullcodecvt.h needed to compile linuxunicode.cpp


-- 


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

[Bug target/38366] gcc doesn't call functions that are struct arguments correctly

2009-01-08 Thread ktietz at gcc dot gnu dot org



--- Comment #5 from ktietz at gcc dot gnu dot org  2009-01-08 09:22 ---
By the last patches Honza and I did, this bug is fixed.

See http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00520.html


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/37194] [4.3/4.4 Regression] Autovectorization of small constant iteration loop degrades performance

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



--- Comment #10 from jakub at gcc dot gnu dot org  2009-01-08 09:22 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/37194] [4.3/4.4 Regression] Autovectorization of small constant iteration loop degrades performance

2009-01-08 Thread cnstar9988 at gmail dot com



--- Comment #11 from cnstar9988 at gmail dot com  2009-01-08 09:24 ---
fixed for 4.3.3?
Thanks.


-- 


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

[Bug tree-optimization/37194] [4.3/4.4 Regression] Autovectorization of small constant iteration loop degrades performance

2009-01-08 Thread irar at il dot ibm dot com



--- Comment #12 from irar at il dot ibm dot com  2009-01-08 09:25 ---
(In reply to comment #11)
> fixed for 4.3.3?
> Thanks.

No, still waiting for approval.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug middle-end/38584] [4.3/4.4 Regression] Inline heuristics run even at -O0

2009-01-08 Thread cnstar9988 at gmail dot com



--- Comment #12 from cnstar9988 at gmail dot com  2009-01-08 09:30 ---
Target Milestone: 4.3.3
But not fixed for 4.3.3
ping ...


-- 


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

[Bug middle-end/38584] [4.3/4.4 Regression] Inline heuristics run even at -O0

2009-01-08 Thread steven at gcc dot gnu dot org



--- Comment #13 from steven at gcc dot gnu dot org  2009-01-08 10:21 ---
Reopening...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug middle-end/38584] [4.3/4.4 Regression] Inline heuristics run even at -O0

2009-01-08 Thread steven at gcc dot gnu dot org



--- Comment #14 from steven at gcc dot gnu dot org  2009-01-08 10:22 ---
...to unassign and avoid spam from cnstar9988 (who is free to test/submit the
patch if it's so important for him/her to have this bug fixed in gcc 4.3).


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org
 Status|REOPENED|NEW


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

[Bug tree-optimization/37031] [4.4 Regression] ICE for h264ref in gather_interchange_stats with -ftree-loop-linear

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



--- Comment #7 from jakub at gcc dot gnu dot org  2009-01-08 11:04 ---
Created an attachment (id=17055)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17055&action=view)
pr37031.i

Slightly less minimized testcase which reproduces (under valgrind only) on both
powerpc64-linux native and x86_64-linux -> powerpc64-linux cross, with
-O3 -ftree-loop-linear -m{32,64}.


-- 


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

[Bug c++/38764] New: bogus 'changes meaning' error?

2009-01-08 Thread pluto at agmk dot net

following code snipet is reducted testcase from external application.
g++ and comeau online accept/reject source differently.

template < class T >
struct A
{
};
template < class U >
struct B
{
#if 1
typedef A< float > A; // <-- accepted by comeau but...
// g++: error: declaration of typedef struct A B::A
// g++: error: changes meaning of A from struct A
#else
typedef ::A< float > A; // <-- accepted by g++ but...
// comeau: class member typedef may not be redeclared
// typedef ::A< float > A;
//  ^
#endif
};


-- 
   Summary: bogus 'changes meaning' error?
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net


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

[Bug fortran/38765] New: [4.4, 4.3 Regression] ICE in check_host_association

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

As reported to the list by Marco Restelli:

ice-test.f90:6: internal compiler error: in check_host_association, at
fortran/resolve.c:4353
Please submit a full bug report,
with preprocessed source if appropriate.

gfortran -c ice-test.f90
ice-test.f90:6: internal compiler error: in check_host_association, at
fortran/resolve.c:4353

gfortran --version
GNU Fortran (GCC) 4.4.0 20090108 (experimental) [trunk revision 143177]
Copyright (C) 2008 Free Software Foundation, Inc.


module mod_a
 implicit none
 public :: fun
 private
contains
 pure function fun(x) result(mu)
 real, intent(in) :: x(:,:)
 real :: mu(2,2,size(x,2))
 mu = 2.0
 end function fun
end module mod_a


module mod_b
! Changing fun to fun2 in this module works.

 use mod_a, only: &
  a_fun => fun

 implicit none
 private
contains

 pure function fun(x) result(mu)
 !pure function fun2(x) result(mu)
 real, intent(in) :: x(:,:)
 real :: mu(2,2,size(x,2))

mu = a_fun(x)

 end function fun
 !end function fun2

end module mod_b

This has an obvious solution that I will fix in the next 48 hours.

Cheers

Paul


-- 
   Summary: [4.4, 4.3 Regression] ICE in check_host_association
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: pault at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org


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

[Bug fortran/38765] [4.4, 4.3 Regression] ICE in check_host_association

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



-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-08 12:45:58
   date||


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

[Bug c++/38764] bogus 'changes meaning' error?

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



--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-08 12:50 ---
I suggest filing a problem report with Comeau.  EDG accepts both in
-strict_ansi mode.


-- 


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

[Bug tree-optimization/38721] [alias-improvements] vectorizer miscompiles gfortran.fortran-torture/execute/elemental.f90 at -O3

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

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-01-08 12:29 ---
Subject: Bug 38721

Author: rguenth
Date: Thu Jan  8 12:29:46 2009
New Revision: 143185

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143185
Log:
2009-01-07  Richard Guenther  

PR tree-optimization/38721
* tree-into-ssa.c (pass_build_ssa): Add TODO_update_address_taken.
* tree-pass.h (TODO_update_address_taken): New flag.
* tree-ssa-loop.c (tree_ssa_loop_ivopts): Update address-taken.
* tree-ssa.c (execute_update_addresses_taken): Optimize only when
optimizing.
(pass_update_address_taken): Just use TODO_update_address_taken.
* tree-flow.h (execute_update_addresses_taken): Update prototype.
* tree-cfg.c (verify_expr): Verify that stmt addresses-taken and
function addressable-vars are conservatively correct.
(verify_stmt): Initialize gsi of walk data.
* tree-inline.c (optimize_inline_calls): Execute
TODO_update_address_taken.
(tree_function_versioning): Call execute_update_addresses_taken.
* passes.c (execute_function_todo): Handle TODO_update_address_taken.
(init_optimization_passes): Remove redundant update-address-taken pass
after final inlining.
* tree-parloops.c (parallelize_loops): Call
execute_update_addresses_taken.
* tree-vectorizer.c (vectorize_loops): Likewise.

Modified:
branches/alias-improvements/gcc/ChangeLog.alias
branches/alias-improvements/gcc/passes.c
branches/alias-improvements/gcc/tree-cfg.c
branches/alias-improvements/gcc/tree-flow.h
branches/alias-improvements/gcc/tree-inline.c
branches/alias-improvements/gcc/tree-into-ssa.c
branches/alias-improvements/gcc/tree-parloops.c
branches/alias-improvements/gcc/tree-pass.h
branches/alias-improvements/gcc/tree-ssa-loop.c
branches/alias-improvements/gcc/tree-ssa.c
branches/alias-improvements/gcc/tree-vectorizer.c

-- 

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

[Bug c++/38764] bogus 'changes meaning' error?

2009-01-08 Thread pluto at agmk dot net



--- Comment #2 from pluto at agmk dot net  2009-01-08 12:56 ---
(In reply to comment #1)
> I suggest filing a problem report with Comeau.  EDG accepts both in
> -strict_ansi mode.
> 

i've tested it on comeau online to verify g++ behaviour :)


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault

2009-01-08 Thread ubizjak at gmail dot com



--- Comment #11 from ubizjak at gmail dot com  2009-01-08 13:10 ---
Program received signal SIGSEGV, Segmentation fault.
record_one_conflict (allocnos_live=0x16103ee8, hard_regs_live=, 
regno=390007032) at
../../gcc-svn/branches/gcc-4_3-branch/gcc/ra-conflict.c:176
176 word = conflicts[index];
(gdb) bt
#0  record_one_conflict (allocnos_live=0x16103ee8, hard_regs_live=, 
regno=390007032) at
../../gcc-svn/branches/gcc-4_3-branch/gcc/ra-conflict.c:176
#1  0x08535fef in global_conflicts ()
at ../../gcc-svn/branches/gcc-4_3-branch/gcc/ra-conflict.c:290
#2  0x0850b80d in rest_of_handle_global_alloc ()
at ../../gcc-svn/branches/gcc-4_3-branch/gcc/global.c:534
#3  0x081d1d43 in execute_one_pass (pass=0x86e38c0)
at ../../gcc-svn/branches/gcc-4_3-branch/gcc/passes.c:1122


-- 


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

[Bug tree-optimization/37031] [4.4 Regression] ICE for h264ref in gather_interchange_stats with -ftree-loop-linear

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



--- Comment #8 from jakub at gcc dot gnu dot org  2009-01-08 13:39 ---
Testing a patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/37031] [4.4 Regression] ICE for h264ref in gather_interchange_stats with -ftree-loop-linear

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



--- Comment #9 from jakub at gcc dot gnu dot org  2009-01-08 13:51 ---
Created an attachment (id=17056)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17056&action=view)
gcc44-pr37031.patch

Fix I'm going to bootstrap/regtest.


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault

2009-01-08 Thread ubizjak at gmail dot com



--- Comment #12 from ubizjak at gmail dot com  2009-01-08 13:55 ---
At the point of failure, we have:

bitnum = 1024405, index = 32012

(BTW: The function doesn't crash when index = 26677).


-- 


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

[Bug c/38755] [graphite] wrong code with -O3 -fgraphite-identity -floop-block on polyhedron benchmarks

2009-01-08 Thread spop at gcc dot gnu dot org



--- Comment #1 from spop at gcc dot gnu dot org  2009-01-08 13:57 ---
Fixed.

See below the graphite.chk for the run of polyhedron on amd64-linux for a
graphite.par containing: "gfortran -O2 -floop-block %n.f90 -o %n"
I don't know why aermod does fail the execution of one of the tests.

Sebastian

> Value=14159 Target=14159 Tolerance=0
> Value=   16 Target=   16 Tolerance=0
> Value=  100 Target=  100 Tolerance=0
> Value=0.44068679351 Target=0.44068679400 Tolerance=0.100E-06
> Value=1 Target=1 Tolerance=0
> Value= 1.4530259062 Target= 1.4530259100 Tolerance=0.100E-02
> Value=0.60312607314E-07 Target=0.60312607300E-07 Tolerance=0.100E-06
> Value=0.54549700079 Target=0.54549700100 Tolerance=0.300E-03
> Value=0.25209045155E-04 Target=0.25209045200E-04 Tolerance=0.100E-06
> Value= 139.68826600 Target= 139.68826600 Tolerance=0.100
> Value=0.15138495928E-01 Target=0.15138495900E-01 Tolerance=0.200E-04

ac PASSED   11 tests - no failures

> Value= 2191.1142600 Target= 2191.1145000 Tolerance=0.100E-02
> Value= 34310.417970 Target= 34310.421880 Tolerance=0.300E-01
> Value= 4260.9589800 Target= 4260.9716800 Tolerance=0.500E-01
> Value= 37094.347660 Target= 37094.375000 Tolerance=0.200E-01
FAIL 
> Value= 7924.8842800 Target= 7924.8842800 Tolerance=0.300E-01
> Value= 37094.347660 Target= 37094.375000 Tolerance= 1.00

aermod FAILED1 fails and5 passes

= Value=1737 Target=1737
> Value=0.99606856460E-02 Target=0.99606856460E-02 Tolerance=0.100E-06
> Value=0.100E-01 Target=0.100E-01 Tolerance=0.100E-06
> Value=0.4152860 Target=0.4152860 Tolerance=0.100E-06
> Value=0.57795248195E-05 Target=0.57795248200E-05 Tolerance=0.100E-06
> Value=0.10001137147E-01 Target=0.10001137100E-01 Tolerance=0.100E-06
= Value=1744 Target=1744

air PASSED7 tests - no failures

> Value=0.32603740700E-04 Target= 0.00 Tolerance=0.600E-04
> Value= 35.406277000 Target= 35.40800 Tolerance=0.200E-02
> Value=0.13642944400E-04 Target= 0.00 Tolerance=0.600E-04
> Value= 5.8969231000 Target= 5.898000 Tolerance=0.200E-02

capacita PASSED4 tests - no failures

> Value=0.42933170391E-01 Target=0.42933170400E-01 Tolerance=0.100E-08
> Value= 667696.66592 Target= 667696.66000 Tolerance=0.100E-01
> Value= 9.780570 Target= 9.780570 Tolerance=0.100E-04
> Value= 6.40 Target= 6.40 Tolerance=0.100
> Value= 6.90 Target= 6.90 Tolerance=0.100
> Value= 7.40 Target= 7.40 Tolerance=0.100
> Value= 7.80 Target= 7.80 Tolerance=0.100
> Value= 8.20 Target= 8.20 Tolerance=0.100
> Value= 8.50 Target= 8.50 Tolerance=0.100
> Value= 8.70 Target= 8.70 Tolerance=0.100
> Value= 8.60 Target= 8.60 Tolerance=0.100
> Value= 8.50 Target= 8.50 Tolerance=0.100
> Value= 7.90 Target= 7.90 Tolerance=0.100
> Value= 7.40 Target= 7.40 Tolerance=0.100
> Value= 6.10 Target= 6.10 Tolerance=0.100
> Value= 5.00 Target= 5.00 Tolerance=0.100
> Value= 2.90 Target= 2.90 Tolerance=0.100
> Value=0.600 Target=0.600 Tolerance=0.100

channel PASSED   18 tests - no failures

> Value= 2000.0002673 Target= 2000.0024122 Tolerance=0.100E-01
> Value=   529859 Target=   533050 Tolerance= 5000

doduc PASSED2 tests - no failures

= Value=10 Target=10
> Value=0.6032500E-04 Target=0.6032500E-04 Tolerance=0.100E-08
= Value=9 Target=9
> Value=0.5397500E-04 Target=0.5397500E-04 Tolerance=0.100E-08
= Value=8 Target=8
> Value=0.4762500E-04 Target=0.4762500E-04 Tolerance=0.100E-08
> Value= 17.55810 Target= 17.55810 Tolerance=0.100E-03
> Value=0.5346300 Target=0.5346300 Tolerance=0.100E-05

fatigue PASSED8 tests - no failures

> Value=0.8677490E-06 Target=0.8677490E-06 Tolerance=0.100E-10

gas_dyn PASSED1 tests - no failures

= Value=10 Target=10
> Value=0.133E-04 Target=0.133E-04

[Bug middle-end/38559] [graphite] ICE :in build2_stat, at tree.c:3293

2009-01-08 Thread spop at gcc dot gnu dot org

--- Comment #5 from spop at gcc dot gnu dot org  2009-01-08 14:14 ---
Subject: Bug 38559

Author: spop
Date: Thu Jan  8 14:14:41 2009
New Revision: 143187

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143187
Log:
2009-01-07  Sebastian Pop  
Jan Sjodin  

PR tree-optimization/38559
* testsuite/gcc.dg/graphite/pr38559.c: New.

* graphite.c (debug_value, copy_constraint,
swap_constraint_variables, scale_constraint_variable, ): New.
(get_lower_bound, get_upper_bound): Removed.
(graphite_trans_bb_strip_mine): Clean up this code that works
only for constant number of iterations.  Fully copy upper and
lower bound constraints, not only the constant part of them.
* graphite.h (debug_value): Declared.

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

-- 

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

[Bug tree-optimization/37031] [4.4 Regression] ICE for h264ref in gather_interchange_stats with -ftree-loop-linear

2009-01-08 Thread spop at gcc dot gnu dot org



--- Comment #10 from spop at gcc dot gnu dot org  2009-01-08 14:18 ---
Subject: Re:  [4.4 Regression] ICE for h264ref in gather_interchange_stats with
-ftree-loop-linear

Patch looks good.  Thanks for this fix.

Sebastian


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault

2009-01-08 Thread ubizjak at gmail dot com



--- Comment #10 from ubizjak at gmail dot com  2009-01-08 13:03 ---
Confirmed, attached testcase fails with -O1 on 4.3 branch, works OK for 4.4
branch.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|x86_64-linux-gnu|i686-linux-gnu
  Known to fail||4.3.3
  Known to work||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2009-01-08 13:03:12
   date||
Summary|internal compiler error:|[4.3 Regression] internal
   |Segmentation fault  |compiler error: Segmentation
   ||fault
   Target Milestone|--- |4.3.3


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

[Bug libstdc++/38741] Unable to write data to wofstream

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



--- Comment #6 from paolo dot carlini at oracle dot com  2009-01-08 14:36 
---
I can't reproduce, neither with stock FSF gcc3.4.6 neither with current
gcc4.3.2 and mainline (I'm assuming you expect a 1002 bytes output). I suggest
testing a current FSF GCC release, and file a new PR in case you are still
having problems.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.

2009-01-08 Thread markus dot schoepflin at comsoft dot de



--- Comment #11 from markus dot schoepflin at comsoft dot de  2009-01-08 
14:40 ---
I don't have 4.3 or 4.4 available, but I now checked with gcc 4.1.2 and 4.2.1.
It works with both versions.

Looking at the resulting listing file, the #.def entries which were triggering
the error in mips-tfile are no longer present.

For example, gcc 3.4.6 creates the following:

#.def   11_Is_integerIbE;   .scl10; .type   0x8;.size  
1;  .endef

whereas gcc 4.2.1 creates:

#.def   St12__is_integerIbE;.scl10; .type   0x8;.size  
1;  .endef

So GCC 4.1 and 4.2 no longer create the problematic definitions, but
nevertheless the problem in mips-tfile is still present.


-- 


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

[Bug tree-optimization/38721] [alias-improvements] vectorizer miscompiles gfortran.fortran-torture/execute/elemental.f90 at -O3

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



--- Comment #6 from rguenth at gcc dot gnu dot org  2009-01-08 14:59 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.

2009-01-08 Thread ubizjak at gmail dot com



--- Comment #12 from ubizjak at gmail dot com  2009-01-08 15:01 ---
(In reply to comment #11)

> So GCC 4.1 and 4.2 no longer create the problematic definitions, but
> nevertheless the problem in mips-tfile is still present.

Can you please post your patch to gcc-patches@ mailing list for a review?


-- 


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

[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.

2009-01-08 Thread markus dot schoepflin at comsoft dot de



--- Comment #13 from markus dot schoepflin at comsoft dot de  2009-01-08 
15:13 ---
Note that my original patch is for the 4.1.1 source tree. Should I post it
anyway?


-- 


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

[Bug libmudflap/38766] New: mudflap cannot detect errors on stack of nptl thread

2009-01-08 Thread anemo at mba dot ocn dot ne dot jp

The mudflap do not report an error in this func() when called from
NPTL thread.  Same error on main thread is reported as expected.

#include 

void *func(void *arg)
{
void *a[1];
return a[2];
}

int main(int argc, char **argv)
{
pthread_t tid;

pthread_create(&tid, NULL, func, NULL);
pthread_join(tid, NULL);
return (int)func(NULL);
}

$ gcc -fmudflapth foo.c -lmudflapth -lpthread
$ ./a.out
***
mudflap violation 1 (check/read): time=1231413729.194138 ptr=0xbfcc9030 size=12
pc=0x1f92a0 location=`foo.c:6:2 (func)'
  /usr/lib/libmudflapth.so.0(__mf_check+0x50) [0x1f92a0]
  ./a.out(func+0x97) [0x804884b]
  ./a.out(main+0x77) [0x80488e8]
Nearby object 1: checked region begins 0B into and ends 8B after
mudflap object 0x9a5ae88: name=`foo.c:5:8 (func) a'
bounds=[0xbfcc9030,0xbfcc9033] size=4 area=stack check=3r/0w liveness=3
alloc time=1231413729.194135 pc=0x1f89c0 thread=3087742672
number of nearby objects: 1
$ rpm -q gcc
gcc-4.3.0-8.i386


With -trace-calls:

$ MUDFLAP_OPTIONS=-trace-calls ./a.out
mf(3086894800): set options from `-trace-calls'
...
mf(3086894800): pthread_create
mf(3086894800): mmap
mf(3086894800): register ptr=0xb75e3000 size=4096 type=2 name='mmap page'
...
mf(3086894800): register ptr=0xb7fe3000 size=4096 type=2 name='mmap page'
mf(3086894800): calloc
mf(3086894800): register ptr=0x9830cb8 size=144 type=2 name='calloc region'
mf(3086891920): register ptr=0xb7fe3b54 size=4 type=5 name='errno area
(thread)'
mf(3086891920): register ptr=0xb7fe3370 size=4 type=3 name='foo.c:5:8 (func) a'
mf(3086891920): check ptr=0xb7fe3370 b=220 size=12 read location=`foo.c:6:2
(func)'
mf(3086891920): unregister ptr=0xb7fe3370 size=4 type=3
mf(3086891920): unregister ptr=0xb7fe3b54 size=4 type=5
mf(3086891920): free
mf(3086894800): register ptr=0xbf9f9540 size=4 type=3 name='foo.c:5:8 (func) a'
mf(3086894800): check ptr=0xbf9f9540 b=336 size=12 read location=`foo.c:6:2
(func)'
mf(3086894800): violation pc=0x1f92a0 location=foo.c:6:2 (func) type=1
ptr=0xbf9f9540 size=12
***
mudflap violation 1 (check/read): time=1231413750.233228 ptr=0xbf9f9540 size=12
pc=0x1f92a0 location=`foo.c:6:2 (func)'
...

As this log shows, "ptr=0xb7fe3370 size=12" does not cause violation
because stack of NPTL thread is in mmapped area.

In the past, it seems mudflap wrapper for pthread_create allocate its
own thread stack, but the code was removed a while ago.

http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01100.html

I'm not sure this problem could happen at that time.


-- 
   Summary: mudflap cannot detect errors on stack of nptl thread
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anemo at mba dot ocn dot ne dot jp
GCC target triplet: *-linux


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

[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.

2009-01-08 Thread ubizjak at gmail dot com



--- Comment #14 from ubizjak at gmail dot com  2009-01-08 15:55 ---
(In reply to comment #13)
> Note that my original patch is for the 4.1.1 source tree. Should I post it
> anyway?

Yes, I think that there were no recent changes in this area.


-- 


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

[Bug tree-optimization/37031] [4.4 Regression] ICE for h264ref in gather_interchange_stats with -ftree-loop-linear

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

--- Comment #11 from jakub at gcc dot gnu dot org  2009-01-08 16:01 ---
Subject: Bug 37031

Author: jakub
Date: Thu Jan  8 16:01:42 2009
New Revision: 143188

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143188
Log:
PR tree-optimization/37031
* lambda-code.c (lambda_collect_parameters): Call pointer_set_destroy
on parameter_set.
(build_access_matrix): Reserve correct size for AM_MATRIX vector,
allocate it using gc instead of heap, use VEC_quick_push instead of
VEC_safe_push.
* graphite.c (build_access_matrix): Allocate AM_MATRIX vector using gc
instead of heap, use VEC_quick_push instead of VEC_safe_push.
* tree-data-ref.h (struct access_matrix): Change matrix to gc
allocated vector from heap allocated.
* lambda.h: Add DEF_VEC_ALLOC_P for gc allocated lambda_vector.
* tree-loop-linear.c (linear_transform_loops): Allocate nest
vector only after perfect_loop_nest_depth call.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c
trunk/gcc/lambda-code.c
trunk/gcc/lambda.h
trunk/gcc/tree-data-ref.h
trunk/gcc/tree-loop-linear.c

-- 

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

[Bug c/38755] [graphite] wrong code with -O3 -fgraphite-identity -floop-block on polyhedron benchmarks

2009-01-08 Thread howarth at nitro dot med dot uc dot edu



--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-01-08 
16:20 ---
What checkin fixed this? Or can't you reproduce the failure? If the latter,
what happens if you use -m32 on amd64-linux?


-- 


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

[Bug tree-optimization/37031] [4.4 Regression] ICE for h264ref in gather_interchange_stats with -ftree-loop-linear

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



--- Comment #12 from jakub at gcc dot gnu dot org  2009-01-08 16:03 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

Re: [Bug c/38755] [graphite] wrong code with -O3 -fgraphite-identity -floop-block on polyhedron benchmarks

2009-01-08 Thread Sebastian Pop

> --- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-01-08 
> 16:20 ---
> What checkin fixed this? Or can't you reproduce the failure? If the latter,
> what happens if you use -m32 on amd64-linux?

I'm running the polyhedron bmk with -m32 and will report the result.
But this should be fixed now by the patch for PR38559.

Sebastian

[Bug c/38755] [graphite] wrong code with -O3 -fgraphite-identity -floop-block on polyhedron benchmarks

2009-01-08 Thread sebpop at gmail dot com



--- Comment #3 from sebpop at gmail dot com  2009-01-08 16:33 ---
Subject: Re:  [graphite] wrong code with -O3 -fgraphite-identity -floop-block
on polyhedron benchmarks

> --- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-01-08 
> 16:20 ---
> What checkin fixed this? Or can't you reproduce the failure? If the latter,
> what happens if you use -m32 on amd64-linux?

I'm running the polyhedron bmk with -m32 and will report the result.
But this should be fixed now by the patch for PR38559.

Sebastian


-- 


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

[Bug fortran/38763] [4.3/4.4 Regression] Yet another TRANSFER ICE

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



--- Comment #2 from pault at gcc dot gnu dot org  2009-01-08 16:42 ---
Steve,

gfc_target_encode_expr has no means to deal with EXPR_NULL.  It's quite easy to
change that, so I have assigned myself.

Thanks for the report.  "Yet another" don't be so hard!  Making TRANSFER
work has been a balls-breaker of a job.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-08 16:42:52
   date||


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

[Bug c/38767] [avr] Complex equations evaluate wrong

2009-01-08 Thread daniel at rozsnyo dot com



--- Comment #1 from daniel at rozsnyo dot com  2009-01-08 16:51 ---
The 01 should be 0x1, my bad. Lost a day working out this :/


-- 

daniel at rozsnyo dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/38767] New: [avr] Complex equations evaluate wrong

2009-01-08 Thread daniel at rozsnyo dot com

Tried with:
 avr-gcc (GCC) 3.4.6 (Gentoo 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10)
 avr-gcc (GCC) 4.2.4 (Gentoo 4.2.4 p1.0)
 avr-gcc (Gentoo 4.3.2-r2 p1.5, pie-10.1.5) 4.3.2

Both -Os and -O0 behave the same, the -mmcu=atmega1281 and -mmcu=atmega128 too
(however the later was not tested on all 6 combinations)

When the complex statement is replaced with the commented out equivalent, the
result is right. It fails on stated magic numbers - the code is basically a
test if a write to external memory crosses the 64KB chip boundary or not.

Complete source code:

#define F_CPU 1600UL
#include 

uint8_t _eeprom_cross16bit( uint32_t a, uint16_t c ) {

/*
uint32_t s = a & 0x1;
uint32_t e = (a + c -1) & 0x1;
return s != e;
*/

return (a & 01) != ( (a + c -1) & 01 );

}

// main code
int main(void) {

// init LEDS
PORTC = 0;
DDRC  = 0xFF;

// comparison result:
if (_eeprom_cross16bit( 4075 , 43 )) {
// wrong
PORTC = 0x55;
} else {
// good
PORTC = 0x0F;
}

while(1);

return 0;
}


-- 
   Summary: [avr] Complex equations evaluate wrong
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daniel at rozsnyo dot com


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

[Bug c/38755] [graphite] wrong code with -O3 -fgraphite-identity -floop-block on polyhedron benchmarks

2009-01-08 Thread sebpop at gmail dot com



--- Comment #4 from sebpop at gmail dot com  2009-01-08 17:05 ---
Subject: Re:  [graphite] wrong code with -O3 -fgraphite-identity -floop-block
on polyhedron benchmarks

> I'm running the polyhedron bmk with -m32 and will report the result.

Actually I cannot run the test with -m32 on my machine.
Could you please test on i686-apple-darwin9 and report the result.

Thanks,
Sebastian


-- 


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

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

2009-01-08 Thread spop at gcc dot gnu dot org



--- Comment #19 from spop at gcc dot gnu dot org  2009-01-08 17:10 ---
Hi,

With the latest trunk CP2K compiles with -O2 -floop-block.  I tried to
run CP2K with -floop-block but I got an error due to the libblas
installation on my system (missing symbols in libblas that uses the
libgfortran of gcc 4.2 of my system).  I would have to install libblas
manually with current gcc trunk.  Could you try to run again the make
test and report the status of CP2K?

Thanks,
Sebastian


-- 


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

[Bug fortran/38763] [4.3/4.4 Regression] Yet another TRANSFER ICE

2009-01-08 Thread sgk at troutmask dot apl dot washington dot edu



--- Comment #3 from sgk at troutmask dot apl dot washington dot edu  
2009-01-08 17:23 ---
Subject: Re:  [4.3/4.4 Regression] Yet another TRANSFER ICE

On Thu, Jan 08, 2009 at 04:42:52PM -, pault at gcc dot gnu dot org wrote:
> gfc_target_encode_expr has no means to deal with EXPR_NULL.  It's
> quite easy to change that, so I have assigned myself.

I haven't had time to look at the code.

> Thanks for the report.  "Yet another" don't be so hard!
> Making TRANSFER work has been a balls-breaker of a job.

It was meant in jest.  I'll change the summary to something
more pleasing.

BTW, James claims that some other failures occur, but I
can't reproduce those.  See

http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/01722ebb249bdb26#


-- 


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

[Bug fortran/38763] [4.3/4.4 Regression] TRANSFER ICE due to missing EXPR_NULL case

2009-01-08 Thread kargl at gcc dot gnu dot org



--- Comment #4 from kargl at gcc dot gnu dot org  2009-01-08 17:25 ---
Update summary to something a little less annoying.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4 Regression] Yet|[4.3/4.4 Regression]
   |another TRANSFER ICE|TRANSFER ICE due to missing
   ||EXPR_NULL case


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

[Bug libgomp/38086] [4.2/4.3 Regression] libgomp fails to build if assembler doesn't support .symver

2009-01-08 Thread ro at techfak dot uni-bielefeld dot de



--- Comment #13 from ro at techfak dot uni-bielefeld dot de  2009-01-08 
17:31 ---
Subject: Re:  [4.2/4.3/4.4 Regression] libgomp fails to build if assembler
doesn't support .symver

bkoz at gcc dot gnu dot org writes:

> Any luck getting past the libgomp build failure? All that is needed is trying
> Jakub's patch and getting confirmation that it works. If it does then the
> libgomp/libstdc++ bits can go in at the same time without further delay.

Sure: as I had already written in Comment #7 of PR libstdc++/38092, I
wanted to let the make check run to completion.  This has happened now and
the results are more or less identical to what I got as of 20081110 with
--disable-symvers.  So from my perspective, all is fine (and the patches
have already been checked in).

Thanks.
Rainer


-- 


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

[Bug other/38768] New: man page: -fschedule-insns documentation

2009-01-08 Thread tim at klingt dot org

according to the manpage, -fschedule-insns is enabled at the optimization
levels -O2, -O3 and -Os. according to g++ -c -Q --help=optimizers, this is not
the case, though.


-- 
   Summary: man page: -fschedule-insns documentation
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug other/38768] man page: -fschedule-insns documentation

2009-01-08 Thread tim at klingt dot org



--- Comment #1 from tim at klingt dot org  2009-01-08 17:44 ---
Created an attachment (id=17057)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17057&action=view)
proposed patch


-- 


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

[Bug middle-end/38753] gcc 4.4.0 20090106 - make profiledbootstrap - No ".gcda" files created in the libiberty/pic directory

2009-01-08 Thread rob1weld at aol dot com



--- Comment #7 from rob1weld at aol dot com  2009-01-08 17:53 ---
I skirted the i386 file by adding this to the line 189 of the Makefile:

# Added - "make profiledbootstrap" is slow and we don't want to break the build
# i386.c - causes "ISO C90 forbids variable length array 'vec'"
i386.o-warn = -Wno-error


That saves a lot of work on that 'generated file' but is not the correct fix.


Building the gcc directory generates few messages compared to the number of
faults thus far versus it's large size. The few that are being show are
related to the "gcc/gcov.gcda", "gcc/errors.gcda" and "gcc/gcov-dump.gcda"
which makes sense that we do not have those ".gcda" files.

I don't know that we need to worry about making profiled versions of
"gcc/genchecksum.c" and other locally used generator executables.


The ada directory works very well. I could not see a single ".gcda" file miss.

Once we've finished gnatbind and get on to the 'cp' directory we loose:

../../gcc_trunk/gcc/cp/cp-lang.c:132: note: file
/usr/share/src/gcc_build/gcc/cp/cp-lang.gcda not found, execution counts
estimated
../../gcc_trunk/gcc/cp/call.c:7312: note: file
/usr/share/src/gcc_build/gcc/cp/call.gcda not found, execution counts estimated
...

(so far) Every(?) file in 'cp' is unprofiled.


-- 


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

[Bug tree-optimization/36922] [4.4 Regression] ICE in tree-data-ref.c with -ftree-loop-linear

2009-01-08 Thread janis at gcc dot gnu dot org



--- Comment #9 from janis at gcc dot gnu dot org  2009-01-08 18:08 ---
I tried the submitter's testcase on i686-pc-linux-gnu using trunk revision
143188 (today) and got the same ICE:

laptop% /home/janis/tools/gcc-trunk-bid/bin/gfortran -c -O2 -ftree-loop-linear
36922.f
36922.f: In function getcof2:
36922.f:1: internal compiler error: in initialize_matrix_A, at
tree-data-ref.c:1903
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This isn't specific to powerpc.


-- 


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

Re: [Bug other/38768] man page: -fschedule-insns documentation

2009-01-08 Thread Andrew Thomas Pinski




On Jan 8, 2009, at 9:44 AM, "tim at klingt dot org" > wrote:





--- Comment #1 from tim at klingt dot org  2009-01-08 17:44  
---

Created an attachment (id=17057)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17057&action=view)
proposed patch



This patch is incorrect as -fschedule-insns is enabled at -O2 and  
above for most targets except for x86.






--


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

[Bug other/38768] man page: -fschedule-insns documentation

2009-01-08 Thread pinskia at gmail dot com



--- Comment #2 from pinskia at gmail dot com  2009-01-08 18:27 ---
Subject: Re:  man page: -fschedule-insns documentation



On Jan 8, 2009, at 9:44 AM, "tim at klingt dot org"  wrote:

>
>
> --- Comment #1 from tim at klingt dot org  2009-01-08 17:44  
> ---
> Created an attachment (id=17057)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17057&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17057&action=view)
> proposed patch


This patch is incorrect as -fschedule-insns is enabled at -O2 and  
above for most targets except for x86.

>
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38768
>


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176

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



--- Comment #13 from hjl dot tools at gmail dot com  2009-01-08 18:30 
---
Gcc 4.1 gave

cc1: out of memory allocating 3644231872 bytes after a total of 50307072 bytes

on Linux/ia32.


-- 


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

[Bug other/38768] man page: -fschedule-insns documentation

2009-01-08 Thread tim at klingt dot org



--- Comment #3 from tim at klingt dot org  2009-01-08 18:30 ---
> This patch is incorrect as -fschedule-insns is enabled at -O2 and  
> above for most targets except for x86.

and x86_64 ... the only platforms i can use for testing ...


-- 


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

Re: [Bug c++/38764] New: bogus 'changes meaning' error?

2009-01-08 Thread Andrew Thomas Pinski



On Jan 8, 2009, at 4:22 AM, "pluto at agmk dot net" > wrote:



following code snipet is reducted testcase from external application.
g++ and comeau online accept/reject source differently.

template < class T >
struct A
{
};
template < class U >
struct B
{
#if 1
   typedef A< float > A; // <-- accepted by comeau but...
   // g++: error: declaration of typedef struct A B::A
   // g++: error: changes meaning of A from struct A
#else
   typedef ::A< float > A; // <-- accepted by g++ but...
   // comeau: class member typedef may not be redeclared
   // typedef ::A< float > A;
   //  ^
#endif
};


GCC is correct.  This code is invalid but the standard says for this  
case no diagnostic is required so both compilers are correct according  
to the standard. Just that edg could be enchened to error about this  
case.







--
  Summary: bogus 'changes meaning' error?
  Product: gcc
  Version: 4.3.3
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: pluto at agmk dot net


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

[Bug c++/38764] bogus 'changes meaning' error?

2009-01-08 Thread pinskia at gmail dot com



--- Comment #3 from pinskia at gmail dot com  2009-01-08 19:16 ---
Subject: Re:   New: bogus 'changes meaning' error?


On Jan 8, 2009, at 4:22 AM, "pluto at agmk dot net"  wrote:

> following code snipet is reducted testcase from external application.
> g++ and comeau online accept/reject source differently.
>
> template < class T >
> struct A
> {
> };
> template < class U >
> struct B
> {
> #if 1
>typedef A< float > A; // <-- accepted by comeau but...
>// g++: error: declaration of typedef struct A B::A
>// g++: error: changes meaning of A from struct A
> #else
>typedef ::A< float > A; // <-- accepted by g++ but...
>// comeau: class member typedef may not be redeclared
>// typedef ::A< float > A;
>//  ^
> #endif
> };

GCC is correct.  This code is invalid but the standard says for this  
case no diagnostic is required so both compilers are correct according  
to the standard. Just that edg could be enchened to error about this  
case.


>
>
>
> -- 
>   Summary: bogus 'changes meaning' error?
>   Product: gcc
>   Version: 4.3.3
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: pluto at agmk dot net
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38764
>


-- 


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

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

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



--- Comment #20 from jv244 at cam dot ac dot uk  2009-01-08 19:30 ---
(In reply to comment #19)
> Could you try to run again the make
> test and report the status of CP2K?

Hi Sebastian,

the testcase provide runs fine (AFAICT) with current trunk. I'll run the full
CP2K testsuite to test somewhat better.

Thanks,

Joost


-- 


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

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

2009-01-08 Thread sebpop at gmail dot com



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

> the testcase provide runs fine (AFAICT) with current trunk. I'll run the full
> CP2K testsuite to test somewhat better.

Thanks for testing.  Can you close the bug after the CP2K testsuite passes?

Thanks,
Sebastian


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176

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



--- Comment #14 from hjl dot tools at gmail dot com  2009-01-08 20:04 
---
This is fixed in 4.4 by IRA:

gnu-3:pts/0[29]> ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i
-fno-ira
gcc_bug.c: In function main:
gcc_bug.c:23030: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
gnu-3:pts/0[30]>

When I enable checking in gcc 4.3, I got

[...@gnu-17 gcc]$ ./xgcc -B./ /tmp/gcc_bug.i -S -O -v
Reading specs from ./specs
Target: i686-pc-linux-gnu
Configured with: /net/gnu-13/export/gnu/src/gcc-4.3/gcc/configure
--enable-languages=c --disable-bootstrap --enable-checking
Thread model: posix
gcc version 4.3.3 20090108 (prerelease) [gcc-4_3-branch revision 143188] (GCC) 
COLLECT_GCC_OPTIONS='-B./' '-S' '-O' '-v' '-mtune=generic'
 ./cc1 -fpreprocessed /tmp/gcc_bug.i -quiet -dumpbase gcc_bug.i -mtune=generic
-auxbase gcc_bug -O -version -o gcc_bug.s
GNU C (GCC) version 4.3.3 20090108 (prerelease) [gcc-4_3-branch revision
143188] (i686-pc-linux-gnu)
compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 98cd2bcb358a704593004b875ff80d57
gcc_bug.c: In function main:
gcc_bug.c:23030: internal compiler error: in global_alloc, at global.c:438
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[...@gnu-17 gcc]$ 

We had an overflow in max_bitnum and things went downhill after that.


-- 


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

[Bug c/38769] New: Sometimes a percent sign is just a percent sign

2009-01-08 Thread jesnow at uh dot edu

Consider the following code: 

#include 

main()

{
printf("hello, world%\n");
printf("hello, world\%\n");
} 

The first generates a warning with -Wall: 
percent.c:6: warning: unknown conversion type character 0xa in format

But the second is escaped, and should not. But does anyway. 

This reduces the usefulness of having warnings turned on at all, as a lot of
spurious warnings are generated if you do much statistics in your code. Any
character after any non-format string percent sign will trigger this warning,
escaped or not.


-- 
   Summary: Sometimes a percent sign is just a percent sign
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jesnow at uh dot edu


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

[Bug c/38770] New: internal compiler error: asm clobber conflict with output operand

2009-01-08 Thread rakeshk at netapp dot com

cd Osolaris-sparcv9; gmake install
gmake[1]: Entering directory `/u/rakeshk/tt/pari-2.1.7/Osolaris-sparcv9'
/usr/ccs/bin/as -P -I. -D__GNUC__ -T -o kernel.o
../src/kernel/sparcv8/level0_sparcv8_micro.S
cat ../src/kernel/sparcv8/level0.h ../src/kernel/none/level1.h > pariinl.h
/usr/software/bin/gcc -c -O3 -DGCC_INLINE -Wall -Wno-implicit
-fomit-frame-pointer   -I. -I../src/headers -o mp.o ../src/kernel/none/mp.c
../src/kernel/none/mp.c: In function 'smulss':
../src/kernel/none/mp.c:1559: internal compiler error: asm clobber conflict
with output operand
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
gmake[1]: *** [mp.o] Error 1
gmake[1]: Leaving directory `/u/rakeshk/tt/pari-2.1.7/Osolaris-sparcv9'
gmake: *** [install] Error 2


-- 
   Summary: internal compiler error: asm clobber conflict with
output operand
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rakeshk at netapp dot com
 GCC build triplet: --program-suffix=-4.1.1 Thread model: posix gcc version
4.1.1
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug c/38770] internal compiler error: asm clobber conflict with output operand

2009-01-08 Thread rakeshk at netapp dot com



--- Comment #1 from rakeshk at netapp dot com  2009-01-08 20:47 ---
Created an attachment (id=17058)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17058&action=view)
save-temps file


-- 


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

[Bug c/38769] Sometimes a percent sign is just a percent sign

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



--- Comment #1 from jakub at gcc dot gnu dot org  2009-01-08 20:54 ---
What kind of escaping are you talking about?
"\%" is the same as "%" in gcc.  If you want to print character %%, you should
write printf ("something %%\n");


-- 

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=38769

[Bug c/38769] Sometimes a percent sign is just a percent sign

2009-01-08 Thread jesnow at uh dot edu



--- Comment #2 from jesnow at uh dot edu  2009-01-08 20:58 ---
Subject: Re:  Sometimes a percent sign is just a percent sign

Sorry my mistake.

jakub at gcc dot gnu dot org wrote:
> --- Comment #1 from jakub at gcc dot gnu dot org  2009-01-08 20:54 ---
> What kind of escaping are you talking about?
> "\%" is the same as "%" in gcc.  If you want to print character %%, you should
> write printf ("something %%\n");
> 
> 


-- 


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

[Bug middle-end/38587] psim miscompiled #2 [regression]

2009-01-08 Thread joel at gcc dot gnu dot org



--- Comment #5 from joel at gcc dot gnu dot org  2009-01-08 22:07 ---
Problem still present:

gcc (GCC) 4.4.0 20090108 (experimental) [trunk revision 143192]


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176

2009-01-08 Thread sergstesh at yahoo dot com



--- Comment #15 from sergstesh at yahoo dot com  2009-01-08 22:18 ---
(In reply to comment #14)
> This is fixed in 4.4 by IRA:
> 
> gnu-3:pts/0[29]> ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i
> -fno-ira
> gcc_bug.c: In function main:
> gcc_bug.c:23030: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> gnu-3:pts/0[30]>
> 
> When I enable checking in gcc 4.3, I got
> 
> [...@gnu-17 gcc]$ ./xgcc -B./ /tmp/gcc_bug.i -S -O -v
> Reading specs from ./specs
> Target: i686-pc-linux-gnu
> Configured with: /net/gnu-13/export/gnu/src/gcc-4.3/gcc/configure
> --enable-languages=c --disable-bootstrap --enable-checking
> Thread model: posix
> gcc version 4.3.3 20090108 (prerelease) [gcc-4_3-branch revision 143188] 
> (GCC) 
> COLLECT_GCC_OPTIONS='-B./' '-S' '-O' '-v' '-mtune=generic'
>  ./cc1 -fpreprocessed /tmp/gcc_bug.i -quiet -dumpbase gcc_bug.i -mtune=generic
> -auxbase gcc_bug -O -version -o gcc_bug.s
> GNU C (GCC) version 4.3.3 20090108 (prerelease) [gcc-4_3-branch revision
> 143188] (i686-pc-linux-gnu)
> compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP 
> version
> 4.2.2, MPFR version 2.3.2.
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> Compiler executable checksum: 98cd2bcb358a704593004b875ff80d57
> gcc_bug.c: In function main:
> gcc_bug.c:23030: internal compiler error: in global_alloc, at global.c:438
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> [...@gnu-17 gcc]$ 
> 
> We had an overflow in max_bitnum and things went downhill after that.
> 

I do not quite understand the

"
This is fixed in 4.4 by IRA:

gnu-3:pts/0[29]> ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i
-fno-ira
gcc_bug.c: In function main:
gcc_bug.c:23030: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
gnu-3:pts/0[30]>
"

part, i.e. on the one hand there is a statement that the problem is fixed in
4.4, on the other hand the example still shows "internal compiler error:
Segmentation fault" - is this example from 4.4 ?

If yes, how does "Segmentation fault" indicate that the problem is fixed ?


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176

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



--- Comment #16 from hjl dot tools at gmail dot com  2009-01-08 22:23 
---
(In reply to comment #15)
> This is fixed in 4.4 by IRA:
> 
> gnu-3:pts/0[29]> ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i
> -fno-ira
> gcc_bug.c: In function main:
> gcc_bug.c:23030: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> gnu-3:pts/0[30]>
> "
> 
> part, i.e. on the one hand there is a statement that the problem is fixed in
> 4.4, on the other hand the example still shows "internal compiler error:
> Segmentation fault" - is this example from 4.4 ?
> 
> If yes, how does "Segmentation fault" indicate that the problem is fixed ?
> 

You only see "Segmentation fault" with -fno-ira.


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176

2009-01-08 Thread sergstesh at yahoo dot com



--- Comment #17 from sergstesh at yahoo dot com  2009-01-08 22:26 ---
(In reply to comment #16)
> (In reply to comment #15)
> > This is fixed in 4.4 by IRA:
> > 
> > gnu-3:pts/0[29]> ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i
> > -fno-ira
> > gcc_bug.c: In function main:
> > gcc_bug.c:23030: internal compiler error: Segmentation fault
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> > gnu-3:pts/0[30]>
> > "
> > 
> > part, i.e. on the one hand there is a statement that the problem is fixed in
> > 4.4, on the other hand the example still shows "internal compiler error:
> > Segmentation fault" - is this example from 4.4 ?
> > 
> > If yes, how does "Segmentation fault" indicate that the problem is fixed ?
> > 
> 
> You only see "Segmentation fault" with -fno-ira.
> 

Am I supposed to encounter "Segmentation fault" at all ?


-- 


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

[Bug libstdc++/38000] [4.3 Regression] System header files not found once -isystem /usr/include is used

2009-01-08 Thread bkoz at gcc dot gnu dot org



--- Comment #8 from bkoz at gcc dot gnu dot org  2009-01-08 22:41 ---

Hey Paolo, what do you think about applying this patch to the gcc-4_3-branch
and change the target milestone to 4.3.3, marking it FIXED?

-benjamin


-- 


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

[Bug libstdc++/36505] C++ includes do not work

2009-01-08 Thread bkoz at gcc dot gnu dot org



--- Comment #6 from bkoz at gcc dot gnu dot org  2009-01-08 22:42 ---


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


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/38000] [4.3 Regression] System header files not found once -isystem /usr/include is used

2009-01-08 Thread bkoz at gcc dot gnu dot org



--- Comment #9 from bkoz at gcc dot gnu dot org  2009-01-08 22:42 ---
*** Bug 36505 has been marked as a duplicate of this bug. ***


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pontus dot astrom at csr dot
   ||com


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

[Bug libstdc++/33612] make check -jN should fully use N cores

2009-01-08 Thread bkoz at gcc dot gnu dot org



--- Comment #4 from bkoz at gcc dot gnu dot org  2009-01-08 22:47 ---

Jakub fixed this with 

http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00772.html


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/38763] [4.3/4.4 Regression] TRANSFER ICE due to missing EXPR_NULL case

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



--- Comment #5 from pault at gcc dot gnu dot org  2009-01-08 22:48 ---
(In reply to comment #3)

> It was meant in jest.  I'll change the summary to something
> more pleasing.

I know:-)

> BTW, James claims that some other failures occur, but I
> can't reproduce those.  See
> 
> http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/01722ebb249bdb26#

OK - I'll take a look a bit later.

Cheers

Paul


-- 


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

[Bug libstdc++/38000] [4.3 Regression] System header files not found once -isystem /usr/include is used

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



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.4.0   |4.3.3


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

[Bug c/32041] [4.3/4.4 Regression] offsetof buglet

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



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.4.0   |4.3.3


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

[Bug tree-optimization/33562] [4.3/4.4/4.5 Regression] aggregate DSE disabled

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



--- Comment #12 from rguenth at gcc dot gnu dot org  2009-01-08 22:56 
---
Neither for GCC 4.4.  Re-targeting for GCC 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4 Regression]|[4.3/4.4/4.5 Regression]
   |aggregate DSE disabled  |aggregate DSE disabled
   Target Milestone|4.4.0   |4.5.0


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

[Bug c++/37561] [4.2/4.3 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C

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



--- Comment #10 from rguenth at gcc dot gnu dot org  2009-01-08 22:58 
---
Thus fixed.  No need to fix accepts-invalid bugs on release branches (IMHO
we should never do that).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.2.4 4.3.2
 Resolution||FIXED


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

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



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|4.4.0   |4.3.3


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

[Bug fortran/38669] [4.3/4.4 Regression] Array bounds violation for arguments of elemental subroutine

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



--- Comment #11 from rguenth at gcc dot gnu dot org  2009-01-08 23:01 
---
Huh, the regression state of this bug looks weird.  So we have a patch applied
on trunk, but known-to-fail is both 4.3.3 and 4.4.0 - but 4.3.2 works?  And
the target milestone is 4.4.0?  If it is really a regression on the branch
(4.3.3 vs. 4.3.2) it definitely should be 4.3.3.  Changed as such, to get on
the radar for 4.3.3 again.

Please adjust known-to-work and known-to-fail accordingly.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.4.0   |4.3.3


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

[Bug libstdc++/38000] [4.3 Regression] System header files not found once -isystem /usr/include is used

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



--- Comment #10 from paolo dot carlini at oracle dot com  2009-01-08 23:02 
---
Ok, I'll do the backport.


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176

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



--- Comment #18 from rguenth at gcc dot gnu dot org  2009-01-08 23:02 
---
So, only the ICE is a regression, not the memory-hog, correct?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code


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

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

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



--- Comment #3 from dodji at gcc dot gnu dot org  2009-01-08 23:03 ---
Created an attachment (id=17059)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17059&action=view)
candidate patch

I think what is happening is that lookup_name_real (in name-lookup.c) makes
sure types defined in the class hierarchy hide template type parameters. That
scheme is implemented in the outer_binding accessor function.

That scheme is fine for class templates, as stated in the spec in [temp.res]
and [temp.local]. 

Template parameters of member templates though, should hide types defined in
the class scope.

This patch tries to implement that. But I am not sure if it's the right
approach. I'll keep working on it until it's suitable for submission to
gcc-patches.


-- 


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

[Bug libstdc++/33328] sys_nerr declaration assumed to be in errno.h

2009-01-08 Thread bkoz at gcc dot gnu dot org



--- Comment #1 from bkoz at gcc dot gnu dot org  2009-01-08 23:05 ---
Fixed on trunk since:

2008-05-16  Benjamin Kosnik  

* include/std/system_error: Align to current draft specifications.
* src/system_error.cc: Same.
* src/functexcept.cc: Adjust for corrected system_error construction.
* include/std/ostream: Adjust error_code inserter.
* acinclude.m4 (GLIBCXX_CHECK_SYSTEM_ERROR): Remove sys_nerr test.
* config/abi/pre/gnu.ver: Add new exports.
...

And as system_error support was pulled from 4.3.x, this bug can't have been in
4.3.0.

This seems to have been reported against 4.4.x after 4.3.0 was released, or
early 4_3-branch pre-release. 

In any case, fixed.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID
   Target Milestone|--- |4.4.0
Version|4.3.0   |4.4.0


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

[Bug libstdc++/32092] Can't create directory link when build libstdc++ (gcc-4.2.0)

2009-01-08 Thread bkoz at gcc dot gnu dot org



--- Comment #5 from bkoz at gcc dot gnu dot org  2009-01-08 23:08 ---

I'm going to close this as "WONTFIX" due to inactivity. If you can still
reproduce this with gcc-4.3.x or gcc-4.4.x, please reopen and state the gcc and
mingw versions being used.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/32890] Compile-time detect of LHS/RHS missmatch for PACK

2009-01-08 Thread dfranke at gcc dot gnu dot org



-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-07-26 05:53:39 |2009-01-08 23:19:34
   date||


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

[Bug libstdc++/33603] configuration failure during native build

2009-01-08 Thread bkoz at gcc dot gnu dot org



--- Comment #9 from bkoz at gcc dot gnu dot org  2009-01-08 23:39 ---

I am closing this due to inactivity. The following remain unclear to me: 

1) Does this issue exist with mingw32 and configure such as:

Combined binutils/gcc in-tree build with this configuration
../src/configure --host=mingw32 --build=mingw32 --target=mingw32
--with-arch=i486 --with-cpu=generic --disable-werror --prefix=/mingw 
--enable-threads --disable-nls --enable-languages=c,c++,objc,obj-c++,fortran
--disable-win32-registry --enable-libstdcxx-debug
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--enable-version-specific-runtime-lib   --enable-libgomp
--disable-sjlj-exceptions --enable-shared --disable-symvers

(Danny Smith says yes, Gaby says no. Nightstrike says yes on mingw32, but not
for mingw64)? No real consensus.

If this is a known issue, it needs to be documented here:
http://gcc.gnu.org/install/specific.html#x-x-mingw


2) If so, does --with-ld=/mingw/bin/ld.exe fix it? (Gaby says Yes.)


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug libstdc++/38000] [4.3 Regression] System header files not found once -isystem /usr/include is used

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



--- Comment #11 from paolo at gcc dot gnu dot org  2009-01-09 00:00 ---
Subject: Bug 38000

Author: paolo
Date: Fri Jan  9 00:00:17 2009
New Revision: 143194

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

Backport from mainline:
2008-11-13  Paolo Carlini  

PR libstdc++/38000
* include/c_global/csignal: Do not use include_next.
* include/c_global/cstdlib: Likewise.
* include/c_global/cstdio: Likewise.
* include/c_global/cstdarg: Likewise.
* include/c_global/cctype: Likewise.
* include/c_global/cerrno: Likewise.
* include/c_global/cmath: Likewise.
* include/c_global/clocale: Likewise.
* include/c_global/climits: Likewise.
* include/c_global/cassert: Likewise.
* include/c_global/csetjmp: Likewise.
* include/c_global/cwchar: Likewise.
* include/c_global/cfloat: Likewise.
* include/c_global/cstdbool: Likewise.
* include/c_global/cstring: Likewise.
* include/c_global/cstddef: Likewise.
* include/c_global/cwctype: Likewise.
* include/tr1/cstdbool: Likewise.
* include/tr1_impl/cinttypes: Do not include .
* include/c_global/cinttypes: Do it here.
* include/tr1/cinttypes: Likewise.
* include/tr1_impl/cfenv: Do not include .
* include/c_global/cfenv: Do it here.
* include/tr1/cfenv: Likewise.
* include/tr1_impl/cstdint: Do not include .
* include/c_global/cstdint: Do it here.
* include/tr1/cstdint: Likewise.
* include/c_compatibility/fenv.h: Include .
* include/c_compatibility/stdint.h: Include .
* include/c_compatibility/inttypes.h: Include .

* include/c_compatibility/math.h: Minor tweak, add comment.

Modified:
branches/gcc-4_3-branch/libstdc++-v3/ChangeLog
branches/gcc-4_3-branch/libstdc++-v3/include/c_compatibility/fenv.h
branches/gcc-4_3-branch/libstdc++-v3/include/c_compatibility/inttypes.h
branches/gcc-4_3-branch/libstdc++-v3/include/c_compatibility/math.h
branches/gcc-4_3-branch/libstdc++-v3/include/c_compatibility/stdint.h
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cassert
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cctype
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cerrno
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cfenv
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cfloat
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cinttypes
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/climits
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/clocale
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cmath
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/csetjmp
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/csignal
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cstdarg
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cstdbool
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cstddef
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cstdint
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cstdio
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cstdlib
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cstring
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/ctime
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cwchar
branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cwctype
branches/gcc-4_3-branch/libstdc++-v3/include/tr1/cfenv
branches/gcc-4_3-branch/libstdc++-v3/include/tr1/cinttypes
branches/gcc-4_3-branch/libstdc++-v3/include/tr1/cstdbool
branches/gcc-4_3-branch/libstdc++-v3/include/tr1/cstdint
branches/gcc-4_3-branch/libstdc++-v3/include/tr1_impl/cfenv
branches/gcc-4_3-branch/libstdc++-v3/include/tr1_impl/cinttypes
branches/gcc-4_3-branch/libstdc++-v3/include/tr1_impl/cstdint


-- 


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

[Bug libstdc++/38000] [4.3 Regression] System header files not found once -isystem /usr/include is used

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



--- Comment #12 from paolo dot carlini at oracle dot com  2009-01-09 00:01 
---
Fixed 4.3.3 too.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/38771] New: error: non-trivial conversion in unary operation

2009-01-08 Thread regehr at cs dot utah dot edu

Seen using r143187 on Ubuntu Hardy on x86.

reg...@john-home:~/volatile/tmp116$ current-gcc -O0 -c small.c
small.c: In function foo:
small.c:1: error: non-trivial conversion in unary operation
long long unsigned int
long long int
iftmp.0 = -p_37.1;

small.c:1: error: non-trivial conversion in unary operation
long long unsigned int
long long int
iftmp.0 = -p_37;

small.c:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

reg...@john-home:~/volatile/tmp116$ cat small.c

unsigned long long foo (long long p_37)
{
  return -(unsigned long long) (p_37 ? : p_37);
}

reg...@john-home:~/volatile/tmp116$ current-gcc -v

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr : (reconfigured) ../configure
--program-prefix=current- --enable-languages=c,c++ --prefix=/home/regehr :
(reconfigured) ../configure --program-prefix=current- --enable-languages=c,c++
--prefix=/home/regehr : (reconfigured) ../configure --program-prefix=current-
--prefix=/home/regehr --enable-languages=c,c++ --no-create --no-recursion :
(reconfigured) ../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion : (reconfigured)
../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion : (reconfigured)
../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion : (reconfigured)
../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20090108 (experimental) (GCC)


-- 
   Summary: error: non-trivial conversion in unary operation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug libfortran/38772] New: r143102 breaks xplor-nih

2009-01-08 Thread howarth at nitro dot med dot uc dot edu

The change in revision 143102...

uthor: jvdelisle
Date: Mon Jan  5 22:55:15 2009
New Revision: 143102

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143102
Log:
2009-01-05  Jerry DeLisle  

PR libfortran/38735
* io/unit.c (get_internal_unit): Set default BLANK= status to NULL for
internal units.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/unit.c

...causes 22 testsuite regressions in xplor-nih. The change breaks the routines
in xplor-nih that parse xplor script files. Regressing r143102 from current gcc
trunk eliminates the xplor-nih failures.


-- 
   Summary: r143102 breaks xplor-nih
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug c++/36159] C++ compiler should issue a warning with missing new operator

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



--- Comment #7 from hjl dot tools at gmail dot com  2009-01-09 01:09 ---
We can solve it with

1. A target should define MALLOC_ABI_ALIGNMENT properly.
2. g++ should issue an error when the default new operator
is used on a type whose alignment is greater than
MALLOC_ABI_ALIGNMENT.
3. It is user's responsibility to provide a new operator to return
a properly aligned memory.
4. g++ can assume memory return by the user-provided new
operator is properly aligned.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||xuepeng dot guo at intel dot
   ||com


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

[Bug fortran/38773] New: Arithmetic Overflow with Integer Parameter Assignment

2009-01-08 Thread tom dot browder at gmail dot com

The attached program causes an arithmetic overflow error with the following
gfortran versions: 4.3.1, 4.3.2, and the trunk at revision 143193.  It does NOT
cause an error with version 4.2.1.

Also attached is the output from running gfortran -v --save-temps.


-- 
   Summary: Arithmetic Overflow with Integer Parameter Assignment
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot browder at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/38773] Arithmetic Overflow with Integer Parameter Assignment

2009-01-08 Thread tom dot browder at gmail dot com



--- Comment #1 from tom dot browder at gmail dot com  2009-01-09 01:13 
---
Created an attachment (id=17060)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17060&action=view)
Program demonstrating the overflow error.


-- 


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

[Bug fortran/38773] Arithmetic Overflow with Integer Parameter Assignment

2009-01-08 Thread tom dot browder at gmail dot com



--- Comment #2 from tom dot browder at gmail dot com  2009-01-09 01:14 
---
Created an attachment (id=17061)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17061&action=view)
Output from gfortran with -v --save-temps


-- 


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

[Bug fortran/38773] Arithmetic Overflow with Integer Parameter Assignment

2009-01-08 Thread kargl at gcc dot gnu dot org



--- Comment #3 from kargl at gcc dot gnu dot org  2009-01-09 01:22 ---
See the -fno-range-check option.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/38772] r143102 breaks xplor-nih

2009-01-08 Thread kargl at gcc dot gnu dot org



--- Comment #1 from kargl at gcc dot gnu dot org  2009-01-09 01:47 ---
Without a testcase, it is difficult to determine if the problem is
with gfortran or a bug in your application.

>From Section 9.2.2.1, Internal File Properties, 

 (8) On input, blanks are treated in the same way as for an external file
 opened with a BLANK= specifier having the value NULL and records are
 padded with blanks if necessary (9.4.4.4.2).

>From Section 9.3.4.6, BLANK= Specifier in the OPEN statement,

   The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK=
   specifier is permitted only for a file being connected for formatted
   input/output.  If NULL is specified, all blank characters in numeric
   formatted input fields on the specified unit are ignored, except that
   a field of all blanks has a value of zero.  If ZERO is specified, all
   blanks other than leading blanks are treated as zeros. If this specifier
   is omitted, the default value is NULL.


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

2009-01-08 Thread howarth at nitro dot med dot uc dot edu



--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-01-09 
02:14 ---
I've contacted the author of xplor-nih as the parsing code is pretty complex
legacy fortran. However I would note that they build this code with the a
variety of commercial fortran compilers.

PowerPC darwin xlf 8.1
i386 Linux ifc version: 9.1.051
ia64 Linux  Intel fortran version 10.1.012
x86_64 Linux Intel Fortran version 10.1.012


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

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



--- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-01-09 03:00 
---
I am looking into it. Thanks for the report.


-- 


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

[Bug c/38774] New: ice in df_refs_verify, at df-scan.c:4307

2009-01-08 Thread regehr at cs dot utah dot edu

This is seen using r143187 on Ubuntu Hardy on x86.

PR 32431 reports a similar failure but at a different line number, and for the
68HC11 target.

reg...@john-home:~/volatile/tmp117$ current-gcc -c -O2 -march=i686 small.c
small.c: In function foo:
small.c:17: internal compiler error: in df_refs_verify, at df-scan.c:4307
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

reg...@john-home:~/volatile/tmp117$ cat small.c

int safe_add_func_int64_t_s_s (int _si1, int _si2)
{
  return 1 > 9223372036854775807LL - _si2 && 1 - _si2 ? : 1 + _si2;
}

volatile int g_55;

void func_42 (int p_43, int p_44, int p_46, int p_47)
{
  p_44 & 1 && g_55, !1;
}

void foo (int p_38)
{
  int l_84 = 0;
  func_42 (1, safe_add_func_int64_t_s_s (p_38, 1 >= safe (1)), l_84, 1);
}

reg...@john-home:~/volatile/tmp117$ current-gcc -v

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr : (reconfigured) ../configure
--program-prefix=current- --enable-languages=c,c++ --prefix=/home/regehr :
(reconfigured) ../configure --program-prefix=current- --enable-languages=c,c++
--prefix=/home/regehr : (reconfigured) ../configure --program-prefix=current-
--prefix=/home/regehr --enable-languages=c,c++ --no-create --no-recursion :
(reconfigured) ../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion : (reconfigured)
../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion : (reconfigured)
../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion : (reconfigured)
../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20090108 (experimental) (GCC)


-- 
   Summary: ice in df_refs_verify, at df-scan.c:4307
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

1 2 >

1 - 100 of 108 matches

Mail list logo