[Bug c/55811] New: [ERROR] - not enough GOT space for local GOT entries

2012-12-25 Thread manish.jamwal at gmail dot com 


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



 Bug #: 55811

   Summary: [ERROR] - not enough GOT space for local GOT entries

Classification: Unclassified

   Product: gcc

   Version: 4.3.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: manish.jam...@gmail.com





Hi



I am facing the "not enough GOT space for local GOT entries", while compiling

the component with gcc-4.3.3 for mips64 octeon processor. The binutils version

is 2.18.90 and linux kernel version is 2.6.32.27. The gcc command which is

throwing error is mentioned below. The same component was compiled with linux

kernel 2.6.21 and gcc-4.1 for mips64 octeon processor with below mentioned

command and it compiled successfully. Please provide some pointer...



mips64-octeon-linux-gnu-gcc -Wa,-xgot -mlong-calls -mabi=n32 -o controller \

-Wl,-Map,controller.map \

-Wl,--relax \

-Wl,--start-group \

bootos.o \ gcc

$(cat packageLibs | xargs) \

$(cat packageArcs | xargs) \

-lsqlite3 \

-L /home/v1/common/comps/../install-sdk-2.3.0/ \

-Wl,--end-group \

-Wl,-Bstatic -lstdc++ -lrt -lm \

-Wl,-Bdynamic -lpthread \



/home/v1/sdk2.3.0/tools-gcc-4.3/bin/../lib/gcc/mips64-octeon-linux-gnu/4.3.3/../../../../mips64-octeon-linux-gnu/bin/ld:

not enough GOT space for local GOT entries

/home/v1/sdk2.3.0/tools-gcc-4.3/bin/../lib/gcc/mips64-octeon-linux-gnu/4.3.3/../../../../mips64-octeon-linux-gnu/bin/ld:

BFD 2.19 internal error, aborting at ../../src/bfd/elfxx-mips.c line 9159 in

_bfd_mips_elf_relocate_section



/home/v1/common/bsp/sdk2.3.0/tools-gcc-4.3/bin/../lib/gcc/mips64-octeon-linux-gnu/4.3.3/../../../../mips64-octeon-linux-gnu/bin/ld:

Please report this bug.



collect2: ld returned 1 exit status

DONE!!



Note: Below mentioned lines in the above command resolve to static and dynamic

libs used at run time by the component.

$(cat packageLibs | xargs) \

$(cat packageArcs | xargs) \

[Bug c++/55810] pedantic-errors can not show message for redefined macros in system_header

2012-12-25 Thread pinskia at gcc dot gnu.org 


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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Andrew Pinski  2012-12-26 
03:41:19 UTC ---

You need -Wsystem-headers so GCC does not suppress warnings/pedatic errors from

system headers.

[Bug c++/55810] New: pedantic-errors can not show message for redefined macros in system_header

2012-12-25 Thread guojiufu at gmail dot com 


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



 Bug #: 55810

   Summary: pedantic-errors can not show message for redefined

macros in system_header

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: guoji...@gmail.com





Referenced from Bug 16358 and 55602.  If there is "#pragma GCC

system_header",  it silently overwrites the previous defined macro.

-pedantic-errors can not help.  

--a.h --

#pragma GCC system_header

#define A 1

#define A 2

-a.c

#include "a.h"



int main(){

  return A;

}



gcc a.c -pedantic-errors

[Bug preprocessor/55602] Does not generate Error message for redefined macros

2012-12-25 Thread guojiufu at gmail dot com 


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



Jeff Guo  changed:



   What|Removed |Added



 Status|VERIFIED|CLOSED



--- Comment #5 from Jeff Guo  2012-12-26 02:26:34 
UTC ---

using -pedantic-errors is helpful

[Bug c++/55809] New: Doesn't differentiate elaborated type specifier and typename specifier in dependent types

2012-12-25 Thread schaub.johannes at googlemail dot com 


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



 Bug #: 55809

   Summary: Doesn't differentiate elaborated type specifier and

typename specifier in dependent types

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: schaub.johan...@googlemail.com





The following looks well-formed



template void f() { } 

template void f() { } 



struct A { typedef int X; }; 

struct B { void X(); class X { }; }; 



class B::X x1; 

int x2; 



int main() { f(); f(); }



But GCC shouts:



  prog.cpp:1:94: error: redefinition of 'template > void f()'

  prog.cpp:1:46: error: 'template > void

f()' previously declared here



Related Bugreport (responsible for accepting the above testcase too, when it's

fixed): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48920 . 



Clang accepts the above code, so my statement in PR48920 that the Itanium ABI

does not allow to distiguish between the different signatures appears to be

wrong and GCC should support this code.

[Bug c/55808] New: excessive memory usage from gcc 4.7.2 when compiling mame source code

2012-12-25 Thread mister.freeman at laposte dot net 


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



 Bug #: 55808

   Summary: excessive memory usage from gcc 4.7.2 when compiling

mame source code

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mister.free...@laposte.net





I notice that gcc 4.7.2 uses very excessive amount of memory when I compile the

mame source code ( an arcade emulator ) :



http://mamedev.org/release.html



I have archlinux 32 bits on a virtualbox ( 4.2.6 version ) virtual machine (

CPU dual core 3.3 Ghz, 1 Gb ram and 512 Mb swap partition ),



with PC configuration who have little memory ( 1 Gb for example ) and little

swap partition ( 512 Mb ) it is impossible to compile mame, because the memory

usage is excessive, I monitored the usage of the memory and gcc often takes

almost 2 Gb of ram,



if the system memory is too low ( 1 Gb physical ram and 512 Mb swap partition )

it will cause a fail with this error message :



Compiling src/emu/cpu/tms32051/tms32051.c...

Generating TMS57002 source file...

obj/sdl/build/tmsmake src/emu/cpu/tms57002/tmsinstr.lst

obj/sdl/emu/cpu/tms57002/tms57002.inc

Compiling src/emu/cpu/tms57002/tms57002.c...

{standard input}: Assembler messages:

{standard input}:3066: Warning: end of file not at end of a line; newline

inserted

{standard input}: Error: open CFI at the end of file; missing .cfi_endproc

directive

gcc: internal compiler error: Killed (program cc1plus)

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

make: *** [obj/sdl/emu/cpu/tms57002/tms57002.o] Error 4

==> ERROR: A failure occurred in build().

Aborting... 





if I use an older version of GCC ( for example : gcc 4.4.5 ) I can compile mame

without problems on systems who have low memory ( 1 Gb and 512 Mb swap

partition ), so it's clearly a regression bug in gcc 4.7.2,



and check the first comment here ( padremayi ), same error with gcc 4.7.2 :



https://aur.archlinux.org/packages/sdlmame-wout-gconf/?setlang=fr



we need to improve the memory consumption of gcc

[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign

2012-12-25 Thread jb at gcc dot gnu.org 


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



Janne Blomqvist  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #8 from Janne Blomqvist  2012-12-25 22:21:51 
UTC ---

Fixed on trunk, closing.

[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign

2012-12-25 Thread jb at gcc dot gnu.org 


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



--- Comment #7 from Janne Blomqvist  2012-12-25 22:11:21 
UTC ---

Author: jb

Date: Tue Dec 25 22:11:16 2012

New Revision: 194717



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

Log:

PR fortran/55539 Fix regression in -fno-sign-zero.



libgfortran ChangeLog:



2012-12-26  Janne Blomqvist  



PR fortran/55539

* io/write_float.def (output_float): Take into account decimal dot.



testsuite ChangeLog:



2012-12-26  Janne Blomqvist  



PR fortran/55539

* gfortran.dg/nosigned_zero_3.f90: New testcase.



Added:

trunk/gcc/testsuite/gfortran.dg/nosigned_zero_3.f90

Modified:

trunk/gcc/testsuite/ChangeLog

trunk/libgfortran/ChangeLog

trunk/libgfortran/io/write_float.def

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread pinskia at gcc dot gnu.org 


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



Andrew Pinski  changed:



   What|Removed |Added



   Severity|normal  |enhancement



--- Comment #9 from Andrew Pinski  2012-12-25 
21:50:46 UTC ---

Patches are to be submitted to gcc-patches@.

[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc

2012-12-25 Thread danglin at gcc dot gnu.org 


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



--- Comment #12 from John David Anglin  2012-12-25 
21:05:28 UTC ---

Author: danglin

Date: Tue Dec 25 21:05:21 2012

New Revision: 194716



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

Log:

PR target/53789

* config/pa/pa.md (movsi): Reject expansion of TLS symbol references

after reload starts.





Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/pa/pa.md

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

2012-12-25 Thread Joost.VandeVondele at mat dot ethz.ch 


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



--- Comment #16 from Joost VandeVondele  
2012-12-25 20:23:07 UTC ---

many things appear to work fine, but seemingly parallel do loops with a dynamic

schedule generate warnings in libgomp. I also seem to observe that they are not

strictly deterministic, sometimes these warnings happen, sometimes not.



Testcase:



!$OMP PARALLEL PRIVATE(j)



j=OMP_GET_THREAD_NUM()



! no warnings without the dynamic schedule

!$OMP DO SCHEDULE(DYNAMIC,2) 

DO i=1,10

ENDDO



!$OMP END PARALLEL

END



Result:



vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out

vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out

vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out

vjo...@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out

==

WARNING: ThreadSanitizer: data race (pid=35190)

  Read of size 8 at 0x7d327290 by main thread:

#0 gomp_iter_dynamic_next

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/iter.c:190

(libgomp.so.1+0x6678)

#1 GOMP_loop_dynamic_start

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:128

(libgomp.so.1+0x7a03)

#2 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d)

#3 MAIN__ test.f90:0 (exe+0x0ccb)

#4 main ??:0 (exe+0x0d1a)



  Previous write of size 8 at 0x7d327290 by thread 1:

#0 gomp_loop_init

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:41

(libgomp.so.1+0x7a96)

#1 MAIN__._omp_fn.0 test.f90:0 (exe+0x0d7d)

#2 gomp_thread_start

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116

(libgomp.so.1+0xd012)



  Location is heap block of size 1568 at 0x7d327100 allocated by main

thread:

#0 malloc ??:0 (libtsan.so.0+0x0001896e)

#1 gomp_malloc

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/alloc.c:36

(libgomp.so.1+0x417a)

#2 gomp_new_team

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:145

(libgomp.so.1+0xd27a)

#3 GOMP_parallel_start

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108

(libgomp.so.1+0xafc7)

#4 MAIN__ test.f90:0 (exe+0x0cc1)

#5 main ??:0 (exe+0x0d1a)



  Thread 1 (tid=35191, running) created at:

#0 pthread_create ??:0 (libtsan.so.0+0x0001a868)

#1 gomp_team_start

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440

(libgomp.so.1+0xd908)

#2 GOMP_parallel_start

/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108

(libgomp.so.1+0xafd7)

#3 MAIN__ test.f90:0 (exe+0x0cc1)

#4 main ??:0 (exe+0x0d1a)



==

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



--- Comment #8 from lu_zero at gentoo dot org 2012-12-25 20:20:59 UTC ---

Created attachment 29051

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29051

x86 linker support

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



--- Comment #7 from lu_zero at gentoo dot org 2012-12-25 20:19:11 UTC ---

Created attachment 29050

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29050

powerpc linker support

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



--- Comment #6 from lu_zero at gentoo dot org 2012-12-25 20:18:38 UTC ---

Created attachment 29049

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29049

microblaze linker support

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



--- Comment #5 from lu_zero at gentoo dot org 2012-12-25 20:17:56 UTC ---

Created attachment 29048

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29048

mips linker support

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



--- Comment #4 from lu_zero at gentoo dot org 2012-12-25 20:17:24 UTC ---

Created attachment 29047

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29047

arm linker support

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



--- Comment #3 from lu_zero at gentoo dot org 2012-12-25 20:15:57 UTC ---

Created attachment 29046

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29046

Fix gomp assumption

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



--- Comment #2 from lu_zero at gentoo dot org 2012-12-25 20:14:57 UTC ---

Created attachment 29045

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29045

C++ missing bits

[Bug bootstrap/55807] Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



--- Comment #1 from lu_zero at gentoo dot org 2012-12-25 20:14:15 UTC ---

Created attachment 29044

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29044

gcc configuration

[Bug bootstrap/55807] New: Support musl libc

2012-12-25 Thread lu_zero at gentoo dot org 


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



 Bug #: 55807

   Summary: Support musl libc

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

   URL:  https://bitbucket.org/GregorR/musl-gcc-patches/

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: lu_z...@gentoo.org

Target: *-linux-musl





Here the patches against 4.7 series



Updated version of them are available at the url above

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

2012-12-25 Thread Joost.VandeVondele at mat dot ethz.ch 


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



--- Comment #15 from Joost VandeVondele  
2012-12-25 19:30:15 UTC ---

(In reply to comment #13)

> (In reply to comment #12)

> > That's great that gcc tsan works for Fortran/OpenMP out of the box!

> 

> I'm afraid it yields false positives.



The obvious solution to this seems to be that also the OMP runtime (libgomp)

must be compiled with -fsanitize=thread. If I do that, it appears to work.

That's cool, I will try to do some more testing.



A reasonable approach could be to build two versions of libgomp. One standard

one, and one sanitized one (libgomp_tsan ?). -fsanitize=thread -fopenmp could

link the second version automatically. 



Just for those trying this out...



I used the following to build&install a sanitized libgomp (based on Jakub's

comments in PR55374 and a hack of mine (-L...)) after an initial normal build



cd /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/

make clean

make CFLAGS="-std=gnu99 -g -O2 -fsanitize=thread" FCFLAGS="-g -O2

-fsanitize=thread"

LDFLAGS="-L/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/

-B/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/

-Wl,-rpath,/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/

-fsanitize=thread"

cd /data/vjoost/gnu/gcc_trunk/obj/

make install



compilation as



gfortran -fopenmp -fsanitize=thread -pie -fPIC test.f90

[Bug fortran/55806] Missed optimization with ANY or ALL

2012-12-25 Thread burnus at gcc dot gnu.org 


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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2012-12-25 
18:37:57 UTC ---

See https://groups.google.com/d/msg/comp.lang.fortran/Gad1-auDYuU/_F-Jt8fZIVAJ

in thread "Nearest Neighbour Search".

[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc

2012-12-25 Thread danglin at gcc dot gnu.org 


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



--- Comment #11 from John David Anglin  2012-12-25 
17:57:39 UTC ---

Author: danglin

Date: Tue Dec 25 17:57:35 2012

New Revision: 194714



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

Log:

PR target/53789

* config/pa/pa.md (movsi): Reject expansion of TLS symbol references

after reload starts.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/pa/pa.md

[Bug fortran/55806] New: Missed optimization with ANY or ALL

2012-12-25 Thread tkoenig at gcc dot gnu.org 


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



 Bug #: 55806

   Summary: Missed optimization with ANY or ALL

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: tkoe...@gcc.gnu.org





Mike Metcalf complains (correctly) in

<44daf54c-3de5-4b1c-a1f7-cb7bf0d49...@googlegroups.com>

that using ANY as an idiom instead of .or. for a small number of conditions.







Look at this:



module mymod

contains

  subroutine bar(a,b,c)

integer, dimension(3,3), intent(in) :: a,b

integer, intent(out) :: c

real, parameter :: acc = 1e-4

integer :: i



c = 0

do i=1,3

   if (any([abs(a(i,1) - b(i,1)) > acc,  &

abs(a(i,2) - b(i,2)) > acc, &

abs(a(i,3) - b(i,3)) > acc])) cycle

   c = c + 1

end do

  end subroutine bar

end module mymod



This generates a logical array, assigns the values to them,

and then loops over the array to generate the values:





  atmp.1.dtype = 273;

  atmp.1.dim[0].stride = 1;

  atmp.1.dim[0].lbound = 0;

  atmp.1.dim[0].ubound = 2;

  atmp.1.data = (void * restrict) &A.2;

  atmp.1.offset = 0;

  (*(logical(kind=4)[3] * restrict) atmp.1.data)[0] =

(real(kind=4)) ABS_EXPR <(*a)[(integer(kind=8)) i + -1] -

(*b)[(integer(kind=8)) i + -1]> > 9.9974737875163555145263671875e-5;

  (*(logical(kind=4)[3] * restrict) atmp.1.data)[1] =

(real(kind=4)) ABS_EXPR <(*a)[(integer(kind=8)) i + 2] - (*b)[(integer(kind=8))

i + 2]> > 9.9974737875163555145263671875e-5;

  (*(logical(kind=4)[3] * restrict) atmp.1.data)[2] =

(real(kind=4)) ABS_EXPR <(*a)[(integer(kind=8)) i + 5] - (*b)[(integer(kind=8))

i + 5]> > 9.9974737875163555145263671875e-5;

  {

integer(kind=8) S.4;



S.4 = 0;

while (1)

  {

if (S.4 > 2) goto L.5;

if (NON_LVALUE_EXPR <(*(logical(kind=4)[3] * restrict)

atmp.1.data)[S.4]>)

  {

test.0 = 1;

goto L.4;

  }

S.4 = S.4 + 1;

  }

L.5:;

  }

  L.4:;

  if (test.0) goto L.1;

}

L.3:;

*c = *c + 1;

L.1:;

D.1907 = i == 3;

i = i + 1;

if (D.1907) goto L.2;

  }



The middle-end then fails to remove this array.



Compare this to the result of



module mymod

contains

  subroutine bar(a,b,c)

real, dimension(3,3), intent(in) :: a,b

integer, intent(out) :: c

real, parameter :: acc = 1e-4

integer :: i



c = 0.

do i=1,3

   if (abs(a(i,1) - b(i,1)) > acc .or. &

abs(a(i,2) - b(i,2)) > acc .or. &

abs(a(i,3) - b(i,3)) > acc) cycle

   c = c + 1

end do

  end subroutine bar

end module mymod



What the Fortran FE generates here isn't very idiomatic when you

write in a language like C.  Should we tackle this in the middle

end, or would issuing the version with .or instead of the ANY

to the middle end be preferred?

[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work

2012-12-25 Thread tkoenig at gcc dot gnu.org 


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



Thomas Koenig  changed:



   What|Removed |Added



 Status|REOPENED|NEW

 AssignedTo|tkoenig at gcc dot gnu.org  |unassigned at gcc dot

   ||gnu.org



--- Comment #42 from Thomas Koenig  2012-12-25 
15:26:24 UTC ---

I'll try to find a system I have access to where this also fails;

unassigning myself until then.

[Bug c++/55805] New: Empty brace-init-list causes warning "missing initializer for member" in C++11

2012-12-25 Thread moritz at bunkus dot org 


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



 Bug #: 55805

   Summary: Empty brace-init-list causes warning "missing

initializer for member" in C++11

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mor...@bunkus.org





The C++11 standard has this to say on empty brace-init-lists in 8.5.4.3:



  " If the initializer list has no elements and T is a class type with a

default constructor, the object is value-initialized."



However, g++ issues a warning with "-Wmissing-field-initializers" (which is

included in "-Wextra"). Example:



class A {

public:

  int f;

};



int

main() {

  A a3{};

  return 0;

}



Compile with "g++ -Wextra -std=c++11 -o test1 test1.cpp"



clang++ 3.1 does not emit that warning. g++ 4.6, 4.7 and 4.7.2 do (those are

the ones I have available here).

[Bug c++/55804] [4.7/4.8 regression] GCC omits required call to constructor

2012-12-25 Thread ppluzhnikov at google dot com 


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



--- Comment #1 from Paul Pluzhnikov  2012-12-25 
08:06:13 UTC ---

Re-confirmed with today's trunk (r194713).