[Bug libgomp/38514] use -fopenmp compile gcc 4.4

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-12-13 08:10 ---
User error.  If you compile with -fopenmp, you also need to link with -fopenmp,
otherwise -lgomp isn't linked in.


-- 

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

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

[jv244 at cam dot ac dot uk]

--- Comment #11 from jv244 at cam dot ac dot uk  2008-12-13 08:39 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Unfortunately, '-fgraphite -fgraphite-identity -floop-block 
> > -floop-strip-mine
> > -floop-interchang' goes generate an executable, but it is miscompiled and
> > segfaults.
> 
> reduced testcase in PR38492
> 
After Sebastian Pop's fix for PR38492 the test run goes a bit further but
segfaults again, now with a different trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b0112f77440 (LWP 18589)]
0x00df557b in __fist_neighbor_lists_MOD_give_ijk_subcell ()
(gdb) bt
#0  0x00df557b in __fist_neighbor_lists_MOD_give_ijk_subcell ()
#1  0x00df7742 in __fist_neighbor_lists_MOD_build_neighbor_lists ()
#2  0x00dfd0de in __fist_neighbor_lists_MOD_build_fist_neighbor_lists
()
#3  0x0126f50a in __topology_generate_util_MOD_topology_generate_bond
()
#4  0x01223746 in __topology_MOD_connectivity_control ()
#5  0x012247db in __topology_MOD_topology_control ()
#6  0x0113cf43 in __qs_environment_MOD_qs_init ()
#7  0x007facaa in __qs_main_MOD_quickstep_create_force_env ()
#8  0x00434416 in __f77_interface_MOD_create_force_env ()
#9  0x0040a40e in __cp2k_runs_MOD_cp2k_run ()
#10 0x0040dc47 in __cp2k_runs_MOD_run_input ()
#11 0x00403c01 in MAIN__ ()
#12 0x014483ba in main (argc=2, argv=0x7fff99be3828) at
/scratch/vondele/gcc/graphite/libgfortran/fmain.c:21

There is an earlier error by valgrind:

==18647== Conditional jump or move depends on uninitialised value(s)
==18647==at 0xDF69A3: __fist_neighbor_lists_MOD_build_neighbor_lists (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-6
4-gfortran/cp2k.sopt)
==18647==by 0xDFD0DD: __fist_neighbor_lists_MOD_build_fist_neighbor_lists
(in /scratch/vondele/clean/cp2k/exe/Linux-
x86-64-gfortran/cp2k.sopt)
==18647==by 0x126F509: __topology_generate_util_MOD_topology_generate_bond
(in /scratch/vondele/clean/cp2k/exe/Linux
-x86-64-gfortran/cp2k.sopt)
==18647==by 0x1223745: __topology_MOD_connectivity_control (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran
/cp2k.sopt)
==18647==by 0x12247DA: __topology_MOD_topology_control (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2
k.sopt)
==18647==by 0x113CF42: __qs_environment_MOD_qs_init (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.s
opt)
==18647==by 0x7FACA9: __qs_main_MOD_quickstep_create_force_env (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfor
tran/cp2k.sopt)
==18647==by 0x434415: __f77_interface_MOD_create_force_env (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran
/cp2k.sopt)
==18647==by 0x40A40D: __cp2k_runs_MOD_cp2k_run (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==18647==by 0x40DC46: __cp2k_runs_MOD_run_input (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==18647==by 0x403C00: MAIN__ (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==18647==by 0x14483B9: main (fmain.c:21)

(obviously absent if compiled without graphite).

build_neighbor_lists (fist_neighbor_lists.F) is pretty loopy code, so well.. 
even though the routine is not so long, it wont be easy to reduce it, as it
depends on quite a few types defined elsewhere (it would be nice if the fortran
frontend could generate 'preprocessed' source without module dependencies,
they're similar to C header files.).


-- 


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

[Bug tree-optimization/38515] New: Disabling PPL/CLOOG with configure does not work

[burnus at gcc dot gnu dot org]

--disable-ppl and --without-ppl are accepted, but still ./configure searches
for PPL/CLOOG, finds them and enables them.

Expected: One can build 4.4 also without PPL/CLOOG even if they are installed.


-- 
   Summary: Disabling PPL/CLOOG with configure does not work
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=38515

[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2008-12-13 11:18 ---
(In reply to comment #3)
> Fixed.
> 

This still fails here:

gfortran  -v -O2 -g -ffree-form -fgraphite -fgraphite-identity -cpp -D__FFTSG
PR38492.f90

gcc version 4.4.0 20081110 (experimental) [graphite revision 142738] (GCC)

==28201== Invalid write of size 8
==28201==at 0x41449B: mltfftsg_ (PR38492.f90:234)
==28201==by 0x414808: fftsg3d_ (PR38492.f90:83)
==28201==by 0x414B3B: MAIN__ (PR38492.f90:13)
==28201==by 0x414BC9: main (fmain.c:21)
==28201==  Address 0x4050F68 is 0 bytes after a block of size 1,024 alloc'd
==28201==at 0x4C21D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==28201==by 0x41472C: fftsg3d_ (PR38492.f90:80)
==28201==by 0x414B3B: MAIN__ (PR38492.f90:13)
==28201==by 0x414BC9: main (fmain.c:21)


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org
 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug fortran/38504] double minus sign when printing integer?

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2008-12-13 11:19 ---
For completeness, on my x86-64-linux system I get with 4.4.0, 4.3.0 and with
openSUSE binaries (4.1, 4.2, 4.3, 4.4) always a single "-".

Hmm, OK found something: With -m32 I get "--" but with -m64 (default) I get
"-", maybe it helps.


-- 


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

[Bug fortran/38487] Bogus Warning: INTENT(INOUT) actual argument might interfere with actual argument

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2008-12-13 14:29 ---
Both the warning and the temporary creation depend on the same dependency
checking code. 
While it makes sense in the case of pointers to assume the worst (and create a
temporary, even if it's actually not needed), a warning should probably not be
emitted as it would point real problems in very few cases. 

About activating the warning with a flag (-Waliasing?), I would prefer to keep
the warning by default because it does quite a good job in non-pointer cases. 
But I don't feel very strong about it, as in my opinion, -Waliasing too should
be activated by default (are there too many false positive to do so?). 

Apart for cray pointers (see below), I don't think there are other cases where
the warning would be unwanted. 


Some random thoughts, more or less related:
- As far as I know, cray pointers are not supported by the dependency code.
- -Waliasing doesn't support elemental functions, and seems to catch full
arrays only: on elemental_dependency_1.f90, there is only one (false positive)
warning from -Waliasing. 


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-13 14:29:02
   date||


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

[Bug c++/38516] New: Binary operator ^= doesn't work well for class members

[calliari at gmail dot com]

X-Bugzilla-Reason: CC

*** working on gcc version 3.3.6 

A swap operation between two integers doesn't works for class members.

i ^= j ^= i ^= j;

after the operation above, "i" will value 0 (zero), if i and j are class
members.


-- 
   Summary: Binary operator ^= doesn't work well for class members
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: calliari at gmail dot com


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

[Bug c++/38516] Binary operator ^= doesn't work well for class members

[calliari at gmail dot com]

-- 

calliari at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |major
  Known to work||3.3.6
Summary|Binary operator ^= doesn't  |Binary operator ^= doesn't
   |work well for class members |work well for class members


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

[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2008-12-13 15:29 
---
I am trying not to lose sight of the original problem in comment zero. 
However, the decimal output alignment problem fixed in comment 9 still exists
with -m32 on x86-64 and I can see it with 32 bit windows as well.  There a a
similar shifting in pr38504.


-- 


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

[Bug fortran/38504] double minus sign when printing integer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2008-12-13 15:32 
---
I have also found on pr38472 some odd behaviour at -m32. That we see this with
an integer output has my concern level up.


-- 


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

[Bug fortran/38504] double minus sign when printing integer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-12-13 15:42 
---
Reduced test case. Fails at -m32

program IntAdtest

  integer, parameter :: i8_ = Selected_Int_Kind(18)  ! = integer*8
  integer(i8_) :: value

  value = -9223372036854775807_i8_ -1
  write(*, '(i22)') value

end program IntAdtest

-fdump-tree-original looks clean


-- 


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

[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp

[hjl dot tools at gmail dot com]

--- Comment #32 from hjl dot tools at gmail dot com  2008-12-13 15:55 
---
(In reply to comment #31)
> Created an attachment (id=16902)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16902&action=view) [edit]
> A patch to add -D_GLIBCXX_DEBUG to dg-options
> 
> I am testing this patch to see if it can trigger the bug.
> 

I got many failures:

FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/hash_no_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/list_update_no_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/priority_queue_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_no_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/trie_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/trie_no_data_map_rand.cc execution test

They look like:

/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp:181:
void __gnu_pbds::hash_load_check_resize_trigger::notify_externally_resized(Size_Type) [with bool
External_Load_Access = true, Size_Type = unsigned int]: Assertion
'new_shrink_size > m_next_shrink_size' failed.
FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
extra_tool_flags are:
 -DPB_DS_REGRESSION -D_GLIBCXX_DEBUG
/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/list_update_map_/erase_fn_imps.hpp:125:
void __gnu_pbds::detail::lu_map_no_data_::erase_next(typename
Allocator::rebind<__gnu_pbds::detail::lu_map_no_data_::entry>::other::pointer) [with Key =
__gnu_pbds::test::basic_type, Mapped = __gnu_pbds::null_mapped_type, Eq_Fn =
std::equal_to<__gnu_pbds::test::basic_type>, Allocator =
__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, Update_Policy =
__gnu_pbds::test::move_to_front_lu_policy_t_]: Assertion 'p_l != m_p_l' failed.
FAIL: ext/pb_ds/regression/list_update_no_data_map_rand.cc execution test
extra_tool_flags are:
 -DPB_DS_REGRESSION -D_GLIBCXX_DEBUG
/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_heap.h:357:
error: elements in iterator range [__first, __last) do not form a heap
with respect to the predicate __comp.

Objects involved in the operation:
iterator "__first" @ 0x0xbfc2a270 {
type = PPN10__gnu_pbds4test10basic_typeE;
}
iterator "__last" @ 0x0xbfc2a274 {
type = PPN10__gnu_pbds4test10basic_typeE;
}
FAIL: ext/pb_ds/regression/priority_queue_rand.cc execution test
extra_tool_flags are:
  -include bits/stdc++.h
/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp:213:
typename __gnu_pbds::detail::pat_trie_data_::node_pointer __gnu_pbds::detail::pat_trie_data_::recursive_copy_node(typename
Allocator::rebind::other::const_pointer)
[with Key = __gnu_pbds::test::basic_type, Mapped =
__gnu_pbds::test::basic_type, Node_And_It_Traits =
__gnu_pbds::detail::trie_traits<__gnu_pbds::test::basic_type,
__gnu_pbds::test::basic_type,
__gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, 'a', 'd',
false, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >,
__gnu_pbds::null_trie_node_update, __gnu_pbds::pat_trie_tag,
__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, Allocator =
__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>]: Assertion 'child_i >
1' failed.
FAIL: ext/pb_ds/regression/trie_data_map_rand.cc execution test
extra_tool_flags are:
 -DPB_DS_REGRESSION -D_GLIBCXX_DEBUG

Are they real bugs?


-- 


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

[Bug fortran/38504] double minus sign when printing integer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-12-13 16:28 
---
I have isolated the problem to gfc_itoa.  gfc_itoa returns a string. The number
of digits is determined from the strlen of that string.  At -m32, that string
length (digits, see below) is off by one. I instrumented write_decimal in
write.c to see this.  I now will dig into gfc_itoa.

$ gfc -m64 pr38504.f90
$ ./a.out 
sign=1
w=22, m=-1, digits=19, nsign=1
  -9223372036854775808
$ gfc -m32 pr38504.f90 
$ ./a.out 
sign=1
w=22, m=-1, digits=20, nsign=1
 --9223372036854775808


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-12-12 13:55:55 |2008-12-13 16:28:33
   date||


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

[Bug fortran/38467] gfortran builds programs which don't run on Vista

[marbertone at gmail dot com]

--- Comment #8 from marbertone at gmail dot com  2008-12-13 16:59 ---
Thanks for the 'shot in the dark' suggestion: it worked!

Great, man!

;) 

Thank you

Mario Alberto



(In reply to comment #7)
> $> gcc --version
> shows the same as gfortran? 
> My only data point is, that I have seen programs that I compiled myself on XP
> run on Vista, so I know that *something* works.
> Would it be possible that there is some library interference?! I believe, you
> don't need a mingw installation for the packages from the wiki. Shot in the
> dark: try deinstalling both and install only the wiki-package (while at it,
> check for updates :) - then try again.


-- 


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

[Bug fortran/38467] gfortran builds programs which don't run on Vista

[dfranke at gcc dot gnu dot org]

--- Comment #9 from dfranke at gcc dot gnu dot org  2008-12-13 17:04 ---
Glad it that works now :)
Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/38409] [graphite] ICE : in canonicalize_loop_ivs, at tree-parloops.c:1384

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2008-12-13 
17:08 ---
This is failing gcc.dg/graphite/pr38409.c  on i686-apple-darwin9 at r142739 as
follows...

FAIL: gcc.dg/graphite/pr38409.c (test for excess errors)

which shows up in the the gcc.log as...

Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081213/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081213/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.
dg/graphite/pr38409.c   -O2 -floop-block -S  -m32 -o pr38409.s(timeout =
300)
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:27:
error: redefinition of typedef 'input'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:3:
note: previous declaration of 'input' was here
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:29:
error: redefinition of 'struct test'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:33:
error: redefinition of 'Chv_copyEntriesToVector'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:9:
note: previous definition of 'Chv_copyEntriesToVector' was here
compiler exited with status 1
output is:
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:27:
error: redefinition of typedef 'input'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:3:
note: previous declaration of 'input' was here
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:29:
error: redefinition of 'struct test'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:33:
error: redefinition of 'Chv_copyEntriesToVector'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:9:
note: previous definition of 'Chv_copyEntriesToVector' was here

FAIL: gcc.dg/graphite/pr38409.c (test for excess errors)
Excess errors:
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:27:
error: redefinition of typedef 'input'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:3:
note: previous declaration of 'input' was here
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:29:
error: redefinition of 'struct test'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:33:
error: redefinition of 'Chv_copyEntriesToVector'
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.dg/graphite/pr38409.c:9:
note: previous definition of 'Chv_copyEntriesToVector' was here


-- 


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

[Bug c++/38517] New: At definition of the empty reference the error is not output.

[lisp2d at lisp2d dot net]

int& i; //ok


-- 
   Summary: At definition of the empty reference the error is not
output.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lisp2d at lisp2d dot net


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

[Bug target/38062] FAIL: gfortran.dg/include_2.f90 -O (test for excess errors): error: stray '#' in program

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2008-12-13 
17:47 ---
Subject: Re:  FAIL: gfortran.dg/include_2.f90  -O  (test
for excess errors): error: stray '#' in program

On Tue, 09 Dec 2008, mikael at gcc dot gnu dot org wrote:

> > Is there a way to capture the generated .c file?
> I'm not sure there should be a .c generated file here.

The .c file is generated by collect2.  There's a problem compiling it
using the fortran driver.  Attached log of compiler output with
"-v -Wl,-debug".

I vaguely recall that a fix was applied for this on the trunk.  I'll
see if I can find it.

Dave


--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2008-12-13 
17:47 ---
Created an attachment (id=16903)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16903&action=view)


-- 


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

[Bug target/38062] FAIL: gfortran.dg/include_2.f90 -O (test for excess errors): error: stray '#' in program

[danglin at gcc dot gnu dot org]

--- Comment #6 from danglin at gcc dot gnu dot org  2008-12-13 17:51 ---
Need to backport change from PR 35665.


-- 


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

[Bug c/38518] New: Excessive compile time with -O3

[dcb314 at hotmail dot com]

I just tried to compile the package fceu-0.98.25-1.7
with the GNU C++ compiler version 4.4 snapshot 20081212.

The compiler appears to get into a long or possibly infinite loop.
I tried compiling with flag -O2 and that took 40 seconds or so.
With flag -O3, compilation did not finish in over seven minutes on
an otherwise idle machine.

Preprocessed source code attached. Flag -O3 required.


-- 
   Summary: Excessive compile time with -O3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug c/38518] Excessive compile time with -O3

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-12-13 18:18 ---
Created an attachment (id=16904)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16904&action=view)
C source code


-- 


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

[Bug c++/38516] Binary operator ^= doesn't work well for class members

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-12-13 18:26 ---


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


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/11751] wrong evaluation order of an expression

[schwab at suse dot de]

--- Comment #83 from schwab at suse dot de  2008-12-13 18:26 ---
*** Bug 38516 has been marked as a duplicate of this bug. ***


-- 

schwab at suse dot de changed:

   What|Removed |Added

 CC||calliari at gmail dot com


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

[Bug target/34256] mmx and movd/movq on x86_64

[howarth at nitro dot med dot uc dot edu]

--- Comment #10 from howarth at nitro dot med dot uc dot edu  2008-12-13 
18:38 ---
On i686-apple-darwin9, I have been using...

Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-20081213/configure --prefix=/sw
--prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona
--with-tune=generic --build=i686-apple-darwin9 --host=i686-apple-darwin9
--target=i686-apple-darwin9
Thread model: posix
gcc version 4.4.0 20081213 (experimental) (GCC) 

when the testsuite produces the failure...

FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 4


-- 


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

[Bug libgcj/38414] gcc 4.3-20081204 build broken on OS X 10.4 ppc

[hal at oz dot net]

--- Comment #2 from hal at oz dot net  2008-12-13 19:01 ---
Can you suggest some way of testing that hypothesis?  Or some way of figuring
out why that build broke when the previous one did not break?  What changed?


-- 


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

[Bug target/34256] mmx and movd/movq on x86_64

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2008-12-13 19:29 ---
(In reply to comment #10)

> FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 4

PR 37364


-- 


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

[Bug fortran/38504] double minus sign when printing integer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2008-12-13 19:34 
---
Testing this.

Index: write.c
===
--- write.c (revision 142574)
+++ write.c (working copy)
@@ -600,9 +600,16 @@ write_decimal (st_parameter_dt *dtp, con
   sign = calculate_sign (dtp, n < 0);
   if (n < 0)
 n = -n;
-
   nsign = sign == S_NONE ? 0 : 1;
+  
+  /* conv calls gfc_itoa which sets the negative sign needed
+ by write_integer. The sign '+' or '-' is set below based on sign
+ calculated above, so we just point past the sign in the string
+ before proceeding to avoid double signs in corner cases.
+ (see PR38504)  */
   q = conv (n, itoa_buf, sizeof (itoa_buf));
+  if (*q == '-')
+q++;

   digits = strlen (q);



-- 


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

[Bug c/38518] Excessive compile time with -O3

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-12-13 19:50 ---
On 2.66GHz Cor2 Quad running Fedora 9/x86-64, gcc 4.4 revision 142740 gave:

lake:pts/1[9]> time ./xgcc -B./ -O3 /tmp/bug48.c -S
./xgcc -B./ -O3 /tmp/bug48.c -S  94.39s user 0.98s system 99% cpu 1:35.51 total
lake:pts/1[10]> time ./xgcc -B./ -O2 /tmp/bug48.c -S
./xgcc -B./ -O2 /tmp/bug48.c -S  11.66s user 0.22s system 99% cpu 11.877 total
lake:pts/1[11]> time ./xgcc -B./ -O2 /tmp/bug48.c -S -ftree-vectorize
./xgcc -B./ -O2 /tmp/bug48.c -S -ftree-vectorize  61.16s user 0.73s system 99%
cpu 1:01.92 total


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com
 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug middle-end/38409] [graphite] ICE : in canonicalize_loop_ivs, at tree-parloops.c:1384

[spop at gcc dot gnu dot org]

--- Comment #7 from spop at gcc dot gnu dot org  2008-12-13 19:54 ---
Fixed commit problem.


-- 


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

[Bug bootstrap/37349] [4.4 Regression] bootstrap broken on Alpha: undefined reference to _Jv_RegisterClasses

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2008-12-13 19:55 ---
Has this been fixed in the meantime?

Uros, you wrote in
http://gcc.gnu.org/ml/gcc/2008-12/msg00228.html that bootstrap works
on Alpha...


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com


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

[Bug target/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768

[leonid at volnitsky dot com]

--- Comment #5 from leonid at volnitsky dot com  2008-12-13 20:46 ---
Created an attachment (id=16905)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16905&action=view)
*.ii file


-- 


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

[Bug target/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768

[leonid at volnitsky dot com]

--- Comment #6 from leonid at volnitsky dot com  2008-12-13 20:54 ---
I see same error on Gentoo x86_64, with  gcc-4.4 and 4.3.2
Project page: http://volnitsky/project/lvvlib
Source: http://github.com/lvv/lvvlib
b-array.ii.gz  attached. 
--
g++  b-array.cc -o b-array -save-temps -v -Wall
-DID='"081213_223226-��g++-4.4.0-OPTIMIZE-adf3993d++M"'   -I ~/p/
 -I /usr/local/include -DNDEBUG  -DGSL_RANGE_CHECK_OFF -DNOCHECK   -pipe
-Wno-reorder -Wno-sign-compare  -O3 -march=native  -fwhole-program --combine 
-fopenmp -fomit-frame-pointer -funsafe-loop-optimizations  
g++: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure : (reconfigured) ./configure --disable-bootstrap
--enable-languages=c,c++,fortran --enable-multilib
Thread model: posix
gcc version 4.4.0 20081208 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'b-array' '-save-temps' '-v' '-Wall'
'-DID="081213_223226-��g++-4.4.0-OPTIMIZE-adf3993d++M"' '-I'
'/home/lvv/p/' '-I' '/usr/local/include' '-DNDEBUG' '-DGSL_RANGE_CHECK_OFF'
'-DNOCHECK' '-pipe' '-Wno-reorder' '-Wno-sign-compare' '-O3'  '-fwhole-program'
'-combine' '-fopenmp' '-fomit-frame-pointer' '-funsafe-loop-optimizations'
'-shared-libgcc' '-pthread'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -E -quiet -v -I
/home/lvv/p/ -I /usr/local/include -D_GNU_SOURCE -D_REENTRANT
-DID="081213_223226-��g++-4.4.0-OPTIMIZE-adf3993d++M" -DNDEBUG
-DGSL_RANGE_CHECK_OFF -DNOCHECK b-array.cc -march=core2 -mcx16 -msahf --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096
-mtune=core2 -Wall -Wno-reorder -Wno-sign-compare -fwhole-program -fopenmp
-fomit-frame-pointer -funsafe-loop-optimizations -O3 -fpch-preprocess -o
b-array.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory "/usr/local/include"
  as it is a non-system directory that duplicates a system directory
ignoring duplicate directory "/usr/local/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 /home/lvv/p/

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-o' 'b-array' '-save-temps' '-v' '-Wall'
'-DID="081213_223226-��g++-4.4.0-OPTIMIZE-adf3993d++M"' '-I'
'/home/lvv/p/' '-I' '/usr/local/include' '-DNDEBUG' '-DGSL_RANGE_CHECK_OFF'
'-DNOCHECK' '-pipe' '-Wno-reorder' '-Wno-sign-compare' '-O3'  '-fwhole-program'
'-combine' '-fopenmp' '-fomit-frame-pointer' '-funsafe-loop-optimizations'
'-shared-libgcc' '-pthread'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -fpreprocessed
b-array.ii -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -quiet -dumpbase
b-array.cc -auxbase b-array -O3 -Wall -Wno-reorder -Wno-sign-compare -version
-fwhole-program -fopenmp -fomit-frame-pointer -funsafe-loop-optimizations -o
b-array.s
GNU C++ (GCC) version 4.4.0 20081208 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20081115 (experimental), GMP version
4.2.4, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f0165b2e8081c04e24b530c99a2b0b81
b-array.cc: In function ‘int main(int, char**)’:
b-array.cc:103: internal compiler error: in change_address_1, at
emit-rtl.c:1866
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [b-array] Error 1


-- 


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

[Bug fortran/38398] g0.w edit descriptor: Update for F2008 Tokyo meeting changes

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-12-13 21:08 
---
Please confirm.  Is the output for this correct?

write(*, '(g0.3)') 0.1
write(*, '(g0.9)') 1.0
write(*, '(g0.5)') 29.23
write(*, '(g0.8)') -28.4
write(*, '(g0.8)') -0.0001
write(*, '(a,g10.4,a)') ">",3.45,"<"
write(*, '(g0.4)') 3.45
end

  0.100
1.0
   29.23000
   -28.3962
-0.0001
> 3.450<
 3.4500


-- 


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

[Bug target/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768

[leonid at volnitsky dot com]

--- Comment #7 from leonid at volnitsky dot com  2008-12-13 21:15 ---
Found error cause.

By changing line:
const static unsigned long  N = 10;
to 
const static unsigned long  N = 1; 

I was able to compile.  I recall that I’ve seen this error in the past
too when I had similar const signed variable with negative value when it was
used as array declaration for dimension size.  


-- 


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

[Bug fortran/38398] g0.w edit descriptor: Update for F2008 Tokyo meeting changes

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-12-13 21:19 
---
Disregard comment #2, I found the relevant text describing this that I needed.


-- 


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

--- Comment #4 from nightstrike at gmail dot com  2008-12-13 21:19 ---
As per jakub, it is space separated.


-- 


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

[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2008-12-13 
21:43 ---
Using r142742, '-O1 -fgraphite-identity' now compiles Matrix.c, however '-O2
-fgraphite-identity' still has the compile time errors...

Matrix.c: In function ‘pymol_rg_’:
Matrix.c:3059: error: edge from 509 to 9 should be marked irreducible
Matrix.c:3059: error: basic block 512 should be marked irreducible
Matrix.c:3059: error: edge from 512 to 510 should be marked irreducible
Matrix.c:3059: error: edge from 508 to 11 should be marked irreducible
Matrix.c:3059: internal compiler error: in verify_loop_structure, at
cfgloop.c:1569


-- 


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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

--- Comment #5 from ktietz at gcc dot gnu dot org  2008-12-13 21:46 ---
Reasoned by the fact, that this patch will solve our build failures for w64, it
is really more to be treated as regression.

NightStrike, when all tests you are doing at the moment are passing, I'll sent
it tomorrow to gcc-patches.

Danny is this ok for you?


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

Version|unknown |4.4.0


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

--- Comment #6 from nightstrike at gmail dot com  2008-12-13 21:59 ---
Created an attachment (id=16906)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906&action=view)
Third attempt

There were a few lines in t-mingw32 that were commented out and shouldn't have
been there.  Fixed in this patch.


-- 

nightstrike at gmail dot com changed:

   What|Removed |Added

  Attachment #16849|0   |1
is obsolete||


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

[Bug c/38519] New: gcc build fails - won't link in 'gcc' on SVN obtained 20081213

[esmithmail at gmail dot com]

Works fine in SVN versions obtained 20081123 and earlier.  On SVN version
obtained 20081213:

This is what happens:


../configure --target=avr --prefix=/usr/local/avr --disable-nls
--enable-languages=c --disable-libssp

make (builds for a while and then) --

make[2]: Entering directory
`/home/eric/prog/avr/coreutils/20081213/avr-gcc/gcc-core/obj-avr/gcc'
gcc  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o
cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o  c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
dummy-checksum.o \
  main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -lmpfr -lgmp  
/usr/bin/ld: libbackend.a(dwarf2out.o)(.rodata+0x801bbc): reloc against
`.text': error 2
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[2]: *** [cc1-dummy] Error 1



Target is avr so this is a cross-compile.  My host system:

=
[e...@gum obj-avr]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)
==


My target -- this output was obtained with avr-gcc which built successfully
from SVN obtained 20081123 -- I am using the same configuration to attempt
today's build:

=
[e...@gum obj-avr]$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-libssp
Thread model: single
gcc version 4.4.0 20081123 (experimental) (GCC) 
=


-- 
   Summary: gcc build fails - won't link in 'gcc' on SVN obtained
20081213
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: esmithmail at gmail dot com
  GCC host triplet: i386-redhat-linux
GCC target triplet: avr


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

[Bug c++/37922] code generation error

[rwgk at yahoo dot com]

--- Comment #5 from rwgk at yahoo dot com  2008-12-13 22:09 ---
The bug is still present in svn revsion 140355 from last night.

I ran an automatic search through the svn history. The result is that
revision 129269 (svn log below) introduced the bug.

Could someone please confirm the bug with the reproducer I posted
last weekend? It should only take a second.



r129269 | rsandifo | 2007-10-12 09:54:38 -0700 (Fri, 12 Oct 2007) | 14 lines

gcc/
* dse.c (find_shift_sequence): Reinstate "<= UNITS_PER_WORD" condition.
* var-tracking.c (micro_operation_def): Update comment on u.loc.
(mode_for_reg_attrs, var_lowpart): New functions.
(add_uses): Consider recording a lowpart of LOC for MO_USE.
(add_stores): Likewise MO_SET and MO_COPY.  If the source of a set
or copy is known, set LOC to the SET that performs the set, instead
of the destination.
(find_src_status, find_src_set_src): Remove LOC parameter.
Replace INSN with the source value.
(compute_bb_dataflow, emit_notes_in_bb): Check for a SET u.loc when
handling MO_SET and MO_COPY.  Update the calls to find_src_status
and find_src_set_src.




-- 


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

[Bug middle-end/38520] New: [graphite] wrong code with -O3 -fgraphite-identity on polyhedron benchmarks

[dominiq at lps dot ens dot fr]

At revision 142742 some tests in the polyhedron suite are miscompiled with 
-O3 and some other graphite options (-fgraphite-identity with/without 
-fgraphite: first table, with all possible (?) options: second table,
the third table is given as reference).

I don't know how many of the failures are duplicates of pr38492, so I 
prefer to open a new pr. Note that protein.f90 is using recursivity.

Apparently fatigue.f90 is now compiled correctly (it was not the case when 
I posted http://gcc.gnu.org/ml/gcc/2008-12/msg00184.html).


Date & Time : 13 Dec 2008 22:13:50
Test Name   : pbharness
Compile Command : gfc %n.f90 -m64 -O3 -ffast-math -funroll-loops 
-fgraphite-identity -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct 
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   :  300.0
Target Error %  :  0.200
Minimum Repeats : 2
Maximum Repeats : 5

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  2.85   42560 12.35   2  0.1902
  aermod 87.02 1274632 30.31   2  0.1369
 air  5.49   77336  8.37   2  0.0657
capacita  3.43   60472 11.99   5  0.8089  <== WRONG CODE
 channel  1.55   30456  2.76   5  0.9950
   doduc 11.56  195928 43.25   2  0.0381
 fatigue  3.89   72640 11.49   2  0.0653
 gas_dyn  5.63  688104 22.08   5  0.4231  <-- twice slower
  induct  9.62  164784 34.31   2  0.0379
   linpk  1.52   42536 27.22   2  0.0349
mdbx  3.32   73000 14.88   2  0.0302
  nf  4.86   67328 32.46   5  0.1689
 protein  8.07  101912  0.12   5  0.3868  <== WRONG CODE
  rnflow 10.55  167368 36.43   2  0.0590
test_fpu  9.33  154224 12.88   2  0.0543
tfft  1.16   30528  2.86   5  0.2007

Geometric Mean Execution Time =  11.43 seconds


Polyhedron Benchmark Validator
Copyright (C) Polyhedron Software Ltd - 2004 - All rights reserved


Date & Time : 13 Dec 2008 21:29:49
Test Name   : pbharness
Compile Command : gfc %n.f90 -m64 -O3 -ffast-math -funroll-loops -fgraphite 
-fgraphite-identity -floop-block -floop-strip-mine -floop-interchange 
-ftree-loop-linear -fomit-frame-pointer -finline-limit=600 
--param min-vect-loop-bound=2 -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct 
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Times   :  300.0
Target Error %  :  0.200
Minimum Repeats : 2
Maximum Repeats : 5

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  4.82   42560 12.35   5  0.3124
  aermod 87.25 1266448 30.18   2  0.1872
 air  5.66   77336  8.36   5  0.1105
capacita  4.36   68664  9.61   2  0.0312  <== WRONG CODE
 channel  1.77   30456  2.74   2  0.0913
   doduc 11.48  195928 42.76   2  0.0900
 fatigue  4.09   72640 12.78   2  0.0039
 gas_dyn  5.78  688104  4.07   5  1.1516  <== WRONG CODE
  induct  9.44  172976 34.30   2  0.0889
   linpk  1.64   42536 27.14   2  0.0442
mdbx  3.42   73000 14.84   5  0.1817
  nf 15.02  108168 42.12   2  0.0772  <== WRONG CODE
 protein  9.77  114136  0.12   5  0.2319  <== WRONG CODE
  rnflow 11.13  171464  2.85   5  0.2826  <== WRONG CODE
test_fpu  9.27  150128  4.88   5  0.2239  <== WRONG CODE
tfft  1.08   26432  2.96   5  0.6601

Geometric Mean Execution Time =   8.34 seconds


Polyhedron Benchmark Validator
Copyright (C) Polyhedron Software Ltd - 2004 - All rights reserved


Date & Time : 10 Dec 2008 10:41:52
Test Name   : pbharness
Compile Command : gfc %n.f90 -m64 -O3 -ffast-math -funroll-loops 
-ftree-loop-linear -fomit-frame-pointer -finline-limit=600 
--param min-vect-loop-bound=2 -o %n
Benchmarks  : ac aermod air capacita channel doduc fatigue gas_dyn induct 
linpk mdbx nf protein rnflow test_fpu tfft
Maximum Time

[Bug bootstrap/38508] [4.4 Regression] Bootstrap of r142717 broken in libstdc++-v3

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-12-13 22:46 ---
Apparently fixed without regression at revision 142742. Closing.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

--- Comment #7 from nightstrike at gmail dot com  2008-12-13 23:01 ---
Tested and verified on win64


-- 


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

[Bug c/38521] New: -masm=intel, struct output for __asm__() block causes gcc to ask for bug report.

[vbernetr at gmail dot com]

I'm currently writing a small kernel, and gcc asked me to file a bug report.
I've scrapped the file from anything not directly related to the bug, which
makes it quite small.
I'm aware the assembly syntax is most likely wrong.
Hope this is useful.


Command line :
##
gcc -v -save-temps -nostdinc -masm=intel -Wall interrupt.c

Output :

Utilisation des specs internes.
Cible : i486-linux-gnu
Configuré avec: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Modèle de thread: posix
version gcc 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
 /usr/lib/gcc/i486-linux-gnu/4.2.4/cc1 -E -quiet -nostdinc -v interrupt.c
-masm=intel -mtune=generic -Wall -fpch-preprocess -o interrupt.i
la recherche pour #include "..." débute ici :
la recherche pour #include <...> débute ici:
Fin de la liste de recherche.
 /usr/lib/gcc/i486-linux-gnu/4.2.4/cc1 -fpreprocessed interrupt.i -quiet
-dumpbase interrupt.c -masm=intel -mtune=generic -auxbase interrupt -Wall
-version -fstack-protector -fstack-protector -o interrupt.s
GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (i486-linux-gnu)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e2971cf2189271aeeb10133511ecea3a
interrupt.c: Dans la fonction «f» :
interrupt.c:5: erreur interne du compilateur: dans print_operand, à
config/i386/i386.c:7961
Veuillez soumettre un rapport complet d'anomalies,
avec le source pré-traité si nécessaire.
Consultez http://gcc.gnu.org/bugs.html> pour plus de détail.
For Debian GNU/Linux specific bug reporting instructions,
see .

source code :
#
<--- interrupt.c ->
struct{}i;
void f() {
__asm__("sidt %0\n"
: "=m" (i));
}
<->


-- 
   Summary: -masm=intel, struct output for __asm__() block causes
gcc to ask for bug report.
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vbernetr at gmail dot com


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

[Bug middle-end/38520] [graphite] wrong code with -O3 -fgraphite-identity on polyhedron benchmarks

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2008-12-13 
23:10 ---
Only the capacita and protein benchmarks are compiled with wrong code at -O2
-fgraphite on i686-apple-darwin9.


-- 


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

[Bug c/37865] gfortran build fails in stage 3 bootstrap with --enable-intermodule

[bernard at brenda-arkle dot me dot uk]

--- Comment #2 from bernard at brenda-arkle dot me dot uk  2008-12-13 23:53 
---
I'm not sure what 'now' means.  It's still true for release 4.3.2!
I'm prepared to test with the live sources, but do you want me to?
Do you believe that the problem has been understood and addressed,
or are you hoping that it's gone away (not for the first time in
the history of gcc 4.x.x)?

The following configuration options work fine with --disable-intermodule
substituted for --enable-intermodule.

'../gcc-4.3.2/configure' '--prefix=/usr' '--libexecdir=/usr/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-libada'
'--enable-libssp' '--disable-werror' '--with-mpfr=/usr' '--with-gmp=/usr'
'--with-datarootdir=/usr/share' '--with-docdir=/usr/share/gcc-4.3.2/doc'
'--with-pdfdir=/usr/share/gcc-4.3.2/doc'
'--with-htmldir=/usr/share/gcc-4.3.2/doc/html' '--disable-coverage'
'--enable-nls' '--enable-__cxa_atexit' '--enable-decimal-float'
'--disable-fixed-point' '--enable-threads=posix' '--enable-clocale=gnu'
'--enable-shared' '--enable-intermodule'
'--enable-languages=ada,c++,fortran,java,objc,obj-c++,treelang,c'
'--with-local-prefix=/usr' '--with-gnu-ld' '--with-demangler-in-ld'
'--with-gnu-as' '--with-system-libunwind' '--with-system-zlib'
'--enable-bootstrap'

Configured exactly as given, the relevant bit of the build output is:

Comparing stages 2 and 3
warning: ./cc1objplus-checksum.o differs
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
Bootstrap comparison failure!
./libbackend.o differs

That's with *almost* unmodified sources.  As it happens, as
part of working around a bug which I reported, I've adopted
two patches which have made their way into the live tree:

  (a) the patch for "my" bug 37870: the patch functionally
  changes gcc/expmed.c and adds a new test
  (b) the patch noted at
  http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02201.html
  which I grabbed simply to confirm that it wasn't relevant
  (it also modifies gcc/expmed.c).

I don't believe that these changes are relevant (and in any case,
they make the 4.3.2 source more rather than less like the
current live tree).


-- 


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

[Bug fortran/38398] g0.w edit descriptor: Update for F2008 Tokyo meeting changes

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-12-13 23:54 
---
Let's try this again.  I need verification that I am interpreting the comments
correctly.  With this:

! { dg-do compile }
! { dg-options "-std=f2008" }
! PR36725 Compile time error for g0 edit descriptor
write(*, '(g0.3)') 0.1
write(*, '(g0.9)') 1.0
write(*, '(g0.5)') 29.23
write(*, '(g0.8)') -28.4
write(*, '(5(g0.8,1x))') -0.0001, 2.307, ">",3.45,"<"
write(*, '(2(f0.8,1x))') -0.0001, 2.307
write(*, '(a,g10.4,a)') ">",3.45,"<"
write(*, '(a,g0.4,a)') ">",3.45,"<"
write(*, '(a,f0.4,a)') ">",3.45,"<"
end

I get the following output:

$ ./a.out 
.100
1.0
29.23000
-28.3962
-.0001 2.3062 > 3.4505 <
-.0001 2.3062
> 3.450<
>3.4500<
>3.4500<


-- 


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

--- Comment #8 from nightstrike at gmail dot com  2008-12-14 00:11 ---
To complete this patch, we need to make multilib not be the default.


-- 


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

[Bug target/38423] [avr] function pointers in program memory have wrong addresses

[k dot kosciuszkiewicz+gcc at gmail dot com]

--- Comment #1 from k dot kosciuszkiewicz+gcc at gmail dot com  2008-12-14 
00:10 ---
My mistake, ICALL & IJMP instructions take word (not byte) addresses. Therefore
the generated code is correct.

Sorry for the noise. 


-- 

k dot kosciuszkiewicz+gcc at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/21674] basic_string vs debug_mode

[howarth at nitro dot med dot uc dot edu]

--- Comment #10 from howarth at nitro dot med dot uc dot edu  2008-12-14 
00:43 ---
Should really be XFAIL'ing this test on targets that don't use glibc? We have
been seeing...

XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test

...for this on darwin for ages now. Can't we use something like...

// { dg-do run { xfail *-*-![darwin]* } }

I noticed that testsuite/22_locale/ctype/is/char/2.cc is using a construct of
that form.


-- 


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

[Bug c++/38522] New: g++ -Wconversion warnings

[revel at muub dot net]

int main(int, char**)
{
char i = 1;
char j = 2;

i ^= j;
i |= j;
i &= j;

return 0;
}
---
g++ -Wconversion main.cpp -o main
---
main.cpp: In function ‘int main(int, char**)’:
main.cpp:6: warning: conversion to ‘char’ from ‘int’ may alter its
value
main.cpp:7: warning: conversion to ‘char’ from ‘int’ may alter its
value
main.cpp:8: warning: conversion to ‘char’ from ‘int’ may alter its
value
---
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix
--mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit
--disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch --with-tune=generic
Thread model: posix
gcc version 4.3.2 (GCC) 
---
Linux archer 2.6.27-ARCH #1 SMP PREEMPT Fri Nov 28 10:35:44 UTC 2008 x86_64
Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz GenuineIntel GNU/Linux


-- 
   Summary: g++ -Wconversion warnings
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: revel at muub dot net


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

[Bug target/38294] Enable multilib support for mingw

[dannysmith at users dot sourceforge dot net]

--- Comment #9 from dannysmith at users dot sourceforge dot net  2008-12-14 
05:54 ---
(In reply to comment #5)
> Reasoned by the fact, that this patch will solve our build failures for w64, 
> it
> is really more to be treated as regression.
> 
> NightStrike, when all tests you are doing at the moment are passing, I'll sent
> it tomorrow to gcc-patches.
> 
> Danny is this ok for you?
> 
I would prefer that this be left until 4.5. I don't understand how failing to
add a new feature is now a regression.

(In reply to comment #6)
> Created an attachment (id=16906)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906&action=view) [edit]
> Third attempt
> 
> There were a few lines in t-mingw32 that were commented out and shouldn't have
> been there.  Fixed in this patch.


Please also remove this unnecessary change in mingw32.h

+#if TARGET_64BIT_DEFAULT
 #define STANDARD_INCLUDE_DIR "/mingw/include"
+#else
+#define STANDARD_INCLUDE_DIR "/mingw/include"
 #endif

Nightstrike,  have you completed FSF copyright assignment formality

Danny


-- 


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

[Bug fortran/38504] double minus sign when printing integer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2008-12-14 06:52 
---
Subject: Bug 38504

Author: jvdelisle
Date: Sun Dec 14 06:50:53 2008
New Revision: 142747

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142747
Log:
2008-12-13  Jerry DeLisle  

PR libfortran/38504
io/write.c (write_decimal): Skip extra sign '-' at beginning of string
returned by gfc_itoa.

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


-- 


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

[Bug fortran/38504] double minus sign when printing integer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2008-12-14 07:00 
---
Subject: Bug 38504

Author: jvdelisle
Date: Sun Dec 14 06:58:38 2008
New Revision: 142748

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142748
Log:
2008-12-13  Jerry DeLisle  

PR libfortran/38504
* gfortran.dg/fmt_int_sign.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_int_sign.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/38504] double minus sign when printing integer?

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2008-12-14 07:01 
---
Fixed on trunk.


-- 

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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

--- Comment #10 from ktietz at gcc dot gnu dot org  2008-12-14 07:50 ---
(In reply to comment #9)
> (In reply to comment #5)
> > Reasoned by the fact, that this patch will solve our build failures for 
> > w64, it
> > is really more to be treated as regression.
> > 
> > NightStrike, when all tests you are doing at the moment are passing, I'll 
> > sent
> > it tomorrow to gcc-patches.
> > 
> > Danny is this ok for you?
> > 
> I would prefer that this be left until 4.5. I don't understand how failing to
> add a new feature is now a regression.

Yes, this bug is reasoned by preparations to support multilib in w64 crt. Now
we generate the target specific object files for 64-bit into the 'lib64'
folder. This reasoned the problem we talking about.
In the past we put our object (and library) files into /lib
folder, which has hidden the problem.
But for me it is ok to fix this for 4.5 (beside we need to work-a-round this
for version before 4.5).

> (In reply to comment #6)
> > Created an attachment (id=16906)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906&action=view) [edit]
> > Third attempt
> > 
> > There were a few lines in t-mingw32 that were commented out and shouldn't 
> > have
> > been there.  Fixed in this patch.
> 
> 
> Please also remove this unnecessary change in mingw32.h
> 
> +#if TARGET_64BIT_DEFAULT
>  #define STANDARD_INCLUDE_DIR "/mingw/include"
> +#else
> +#define STANDARD_INCLUDE_DIR "/mingw/include"
>  #endif

Yes, just make out of this '#define STANDARD_INCLUDE_DIR "/mingw/include"'

Kai


-- 


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