[Bug c++/53473] [C++11] static constexpr noexcept cannot be specialized

2012-05-24 Thread daniel.kruegler at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53473

--- Comment #1 from Daniel Krügler  
2012-05-25 06:56:06 UTC ---
This looks indeed like an odd compiler error and one really needs all three
specifiers static, constexpr, and *any* exception-specification to produce the
problem. For completeness the error is:

"7|error: declaration of 'static constexpr T A::foo() [with T = int]' has a
different exception specifier|
3|error: from previous declaration 'static constexpr T A::foo() noexcept
(true) [with T = int]'
"


[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

2012-05-24 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2012-05-25 
06:40:25 UTC ---
The typedef has been there as kind of static assertion.
IMHO it would be better to replace it with
extern char check_count[(N == 2 || N == 4) * 2 - 1];
or something similar.


[Bug c/39283] volatile data types ignore __attribute__ ((__aligned ...))

2012-05-24 Thread hp at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39283

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Version|4.3.3   |4.7.1
 Resolution||FIXED
  Known to fail||

--- Comment #5 from Hans-Peter Nilsson  2012-05-25 
06:04:33 UTC ---
Seems to be gone on "[gcc-4_7-branch revision 185763]" for
crisv32-axis-linux-gnu
as well as for cris-elf with "[trunk revision 187855]" (16, 16, 16, 16) so
let's close this.


[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

2012-05-24 Thread mrs at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453

m...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #12 from mrs at gcc dot gnu.org  2012-05-25 
05:53:19 UTC ---
Darwin bits are Ok.


[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

2012-05-24 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453

--- Comment #11 from Jack Howarth  2012-05-24 
23:26:22 UTC ---
Proposed patch bootstraps on x86_64-apple-darwin12 under Xcode 4.4 and
eliminates the dsymutil warnings for...

gcc-fsf-4.8 
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120524/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120524/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120524/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
-fno-diagnostics-show-caret --save-temps -v -w -O3 -g -lm -m64 -o 20010124-1.x4

with the missing AT_comp_dir attribute now being emitted on darwin...


dwarfdump --debug-info main.o
-- File:
main.o
(x86_64)--
.debug_info contents:

0x: Compile Unit: length = 0x0178  version = 0x0002  abbr_offset =
0x  addr_size = 0x08  (next CU at 0x017c)

0x000b: TAG_compile_unit [1] *
 AT_producer( "GNU C 4.8.0 20120524 (experimental) -fpreprocessed
-fPIC -feliminate-unused-debug-symbols -mmacosx-version-min=10.8.0 -m64
-mtune=core2 -g -O3" )
 AT_language( DW_LANG_C89 )
 AT_name(
"/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120524/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c"
)
 AT_comp_dir( "/Users/howarth/xcode44_bugv2/bad_binary" )
 AT_stmt_list( 0x )

0x0135: TAG_subprogram [2]  
 AT_external( 0x01 )
 AT_name( "main" )
 AT_decl_file(
"/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120524/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c"
)
 AT_decl_line( 7 )
 AT_type( {0x0156} ( int ) )
 AT_low_pc( 0x )
 AT_high_pc( 0x001d )
 AT_frame_base( 0x
0x - 0x0001: rsp+8
0x0001 - 0x001c: rsp+16
0x001c - 0x001d: rsp+8 )

0x0156: TAG_base_type [3]  
 AT_byte_size( 0x04 )
 AT_encoding( DW_ATE_signed )
 AT_name( "int" )

0x015d: TAG_variable [4]  
 AT_name( "inside_main" )
     AT_decl_file(
"/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120524/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c"
)
 AT_decl_line( 4 )
 AT_type( {0x0156} ( int ) )
 AT_external( 0x01 )
 AT_location( [0x] )

0x017b: NULL


[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

2012-05-24 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453

--- Comment #10 from Jack Howarth  2012-05-24 
23:22:21 UTC ---
Created attachment 27494
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27494
proposed patch to emit AT_comp_dir on darwin using target hook


[Bug target/53483] unwind.inc:140:1: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:11176

2012-05-24 Thread jbemmel at zonnet dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53483

--- Comment #3 from Jeroen van Bemmel  2012-05-24 
23:21:21 UTC ---
(In reply to comment #2)
> I don't think the RTD calling convention is supported on Linux at all.  In 
> fact
> if you don't have your glibc compiled with it, there is no way for this to 
> work
> correctly.
> 
> I suspect we should just error out if -mrtd is used under Linux.

I'm building my own OS kernel here. -mrtd is probably not used much anymore,
but the compiler shouldn't ICE when it is used


[Bug c/53467] xgcc:Internal error: Bus error (program cc1)

2012-05-24 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-24
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Eric Botcazou  2012-05-24 
22:46:26 UTC ---
> If you need more informations let me know it.

Sure, nobody has access to this kind of systems here.  Please post a backtrace.


[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org |
 Resolution||FIXED
  Known to fail||

--- Comment #14 from Paolo Carlini  2012-05-24 
22:36:47 UTC ---
So this fixed, I think already in 4.6.0.


[Bug tree-optimization/53436] Volatile behaves strange with OpenMP

2012-05-24 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53436

--- Comment #9 from Andrew Pinski  2012-05-24 
22:34:30 UTC ---
(In reply to comment #8)
> You cannot invoke the C99 standard when there is concurrency in your program,
> as the standard doesn't deal with it at all.

Though C++11/C11 does but we don't have it implemented yet.


[Bug tree-optimization/53436] Volatile behaves strange with OpenMP

2012-05-24 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53436

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #8 from Eric Botcazou  2012-05-24 
22:31:58 UTC ---
> Yes, I get, that it's not a good way to do things, as (among other reasons) a
> volatile access is no memory fence. So accesses to other locations may not be
> ordered. But just for the sake of correctness, accesses should be ordered, if
> they all go to volatile variables, no? From the C99-standard, section 5.1.2.3:
> 
> > At sequence points, volatile objects are stable in the sense that previous 
> > accesses are complete and subsequent accesses have not yet occurred.
> 
> This means buffering the reads to the volatile variable over multiple
> iterations of the while loop is not allowed, or do I get this wrong?

You cannot invoke the C99 standard when there is concurrency in your program,
as the standard doesn't deal with it at all.


[Bug target/53483] unwind.inc:140:1: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:11176

2012-05-24 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53483

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-redhat-linux
  Component|c   |target

--- Comment #2 from Andrew Pinski  2012-05-24 
22:31:21 UTC ---
I don't think the RTD calling convention is supported on Linux at all.  In fact
if you don't have your glibc compiled with it, there is no way for this to work
correctly.

I suspect we should just error out if -mrtd is used under Linux.


[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap

2012-05-24 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-24
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #9 from Eric Botcazou  2012-05-24 
22:20:47 UTC ---
> Only happened with bootstrap-lto.

Yes, I can reproduce it on an OpenSuSE 11.3 machine.


[Bug c/53483] unwind.inc:140:1: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:11176

2012-05-24 Thread jbemmel at zonnet dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53483

--- Comment #1 from Jeroen van Bemmel  2012-05-24 
22:19:33 UTC ---
The gcc_assert which fails is in i386.c line 10897 (latest SVN):

/* Stack align doesn't work with eh_return.  */
gcc_assert (!stack_realign_drap);


[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #6 from Paolo Carlini  2012-05-24 
22:17:15 UTC ---
I think you should post your ongoing work on the mailing lists (gcc-patches and
CC libstdc++)


[Bug c/53483] New: unwind.inc:140:1: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:11176

2012-05-24 Thread jbemmel at zonnet dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53483

 Bug #: 53483
   Summary: unwind.inc:140:1: internal compiler error: in
ix86_expand_epilogue, at config/i386/i386.c:11176
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jbem...@zonnet.nl


Created attachment 27493
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27493
Output of -save-temps

Looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206 is back:

Compiling function '_Unwind_RaiseException' in unwind.inc (adapted from gcc
code base) with the following flags triggers this ICE:

-march=core2 -O3 -m32 -mpreferred-stack-boundary=3 -mrtd

* -march=nocona also triggers it, -march=pentium does not
* -mpreferred-stack-boundary=2 also triggers it, =4 does not
* -O2 or -O1 also don't trigger it
* -m64 or omitting -m32 fixes it too
* leaving out -mrtd fixes it

Commandline and preprocessed sources attached below. Note that this ICE is
still present in the latest GCC SVN (different line number):

code/Core/src/Exceptions/unwind.inc: In function '_Unwind_RaiseException':
code/Core/src/Exceptions/unwind.inc:140:1: internal compiler error: in
ix86_expand_epilogue, at config/i386/i386.c:10897

$ /usr/bin/gcc -Icode/Core/include -c code/Core/src/Exceptions/unwind-dw2.c
-march=core2 -O3 -m32 -mpreferred-stack-boundary=3 -mrtd -save-temps -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-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-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--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-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) 
COLLECT_GCC_OPTIONS='-I' 'code/Core/include' '-c' '-march=core2' '-O3' '-m32'
'-mpreferred-stack-boundary=3' '-mrtd' '-save-temps' '-v'
 /usr/libexec/gcc/x86_64-redhat-linux/4.6.3/cc1 -E -quiet -v -I
code/Core/include -imultilib 32 code/Core/src/Exceptions/unwind-dw2.c
-march=core2 -m32 -mpreferred-stack-boundary=3 -mrtd -O3 -fpch-preprocess -o
unwind-dw2.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.6.3/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 code/Core/include
 /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-I' 'code/Core/include' '-c' '-march=core2' '-O3' '-m32'
'-mpreferred-stack-boundary=3' '-mrtd' '-save-temps' '-v'
 /usr/libexec/gcc/x86_64-redhat-linux/4.6.3/cc1 -fpreprocessed unwind-dw2.i
-quiet -dumpbase unwind-dw2.c -march=core2 -m32 -mpreferred-stack-boundary=3
-mrtd -auxbase unwind-dw2 -O3 -version -o unwind-dw2.s
GNU C (GCC) version 4.6.3 20120306 (Red Hat 4.6.3-2) (x86_64-redhat-linux)
compiled by GNU C version 4.6.3 20120306 (Red Hat 4.6.3-2), GMP version
4.3.2, MPFR version 3.0.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.3 20120306 (Red Hat 4.6.3-2) (x86_64-redhat-linux)
compiled by GNU C version 4.6.3 20120306 (Red Hat 4.6.3-2), GMP version
4.3.2, MPFR version 3.0.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a832aa6a2b1e3d9f3b0f3b81987c045f
In file included from code/Core/src/Exceptions/unwind-dw2.c:1587:0:
code/Core/src/Exceptions/unwind.inc: In function '_Unwind_RaiseException':
code/Core/src/Exceptions/unwind.inc:140:1: internal compiler error: in
ix86_expand_epilogue, at config/i386/i386.c:11176
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccqFcOpp.out file, please attach this to
your bugreport.


[Bug rtl-optimization/53482] New: -mtune=pentium[pro, 2, 3, 4], insn does not satisfy constraints

2012-05-24 Thread ncahill_alt at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53482

 Bug #: 53482
   Summary: -mtune=pentium[pro, 2, 3, 4], insn does not satisfy
constraints
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com


This error cropped up today with gcc 4.7.0, but it only occurs with this
combination of flags:

gcc -O2 -fPIC -mtune=pentium[pro,2,3,4] -c source.c -o source.o

There seems to be no error with -O1, without -fPIC, or with other mtune
settings.

Here is the test case.  What is interesting is, replacing "i = 0" with "i = 1"
is enough to stop the error occurring.

### source.c ###
unsigned char uc;

void fa() 
{
  unsigned char i, a;

a = fb();
fc();
uc += a;
for (i = 0; i < uc;) 
{
  fd();
}
}

### error message ###
source.c: In function 'fa':
source.c:14:1: error: insn does not satisfy its constraints:
(insn 58 9 14 2 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (plus:QI (mem/c:QI (reg/f:SI 4 si [68]) [0 uc+0 S1
A8])
(reg:QI 5 di [orig:59 D.1370 ] [59]))
(const_int 0 [0])))
(set (mem/c:QI (reg/f:SI 4 si [68]) [0 uc+0 S1 A8])
(plus:QI (mem/c:QI (reg/f:SI 4 si [68]) [0 uc+0 S1 A8])
(reg:QI 5 di [orig:59 D.1370 ] [59])))
]) source.c:10 199 {*addqi_2}
 (nil))
source.c:14:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:767


### gcc -v ###
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.7.0/configure --disable-bootstrap --disable-libada
--disable-ld --disable-gold --enable-lto --enable-libssp
--enable-cloog-backend=isl --without-cloog --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --enable-nls --without-included-gettext
--with-system-zlib --disable-werror --enable-secureplt --disable-multilib
--enable-libmudflap --disable-libgomp
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.0/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran,lto
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
Thread model: posix
gcc version 4.7.0 (GCC) 


The workaround is to use -mtune=i686 instead.
Thank you.
Neil.


[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

2012-05-24 Thread dodji at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459

--- Comment #3 from Dodji Seketeli  2012-05-24 
21:06:24 UTC ---
Fixed in trunk (4.8).


[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

2012-05-24 Thread dodji at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459

--- Comment #2 from Dodji Seketeli  2012-05-24 
21:05:55 UTC ---
Author: dodji
Date: Thu May 24 21:05:49 2012
New Revision: 187853

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187853
Log:
PR bootstrap/53459 - unused local typedef when building on altivec

libcpp/

PR bootstrap/53459
* lex.c (search_line_fast): Remove unused typedef check_count.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

--- Comment #3 from Dodji Seketeli  2012-05-24 
21:06:24 UTC ---
Fixed in trunk (4.8).


[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

2012-05-24 Thread dodji at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459

--- Comment #2 from Dodji Seketeli  2012-05-24 
21:05:55 UTC ---
Author: dodji
Date: Thu May 24 21:05:49 2012
New Revision: 187853

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187853
Log:
PR bootstrap/53459 - unused local typedef when building on altivec

libcpp/

PR bootstrap/53459
* lex.c (search_line_fast): Remove unused typedef check_count.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c


[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

2012-05-24 Thread rbmj at verizon dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #5 from rbmj at verizon dot net 2012-05-24 20:39:20 UTC ---
Would something like the following fixincludes hacks work?

/*
 *  Wrap VxWorks ioctl to keep everything pretty
 */
fix = {
hackname= vxworks_ioctl_macro;
files   = ioLib.h;
test= " -r vxWorks.h ";

c_fix   = format;
c_fix_arg   = "%0\n"
"#define ioctl(fd, func, arg) ((ioctl)((fd), (func), ((int)(arg\n";
c_fix_arg   = "extern[\t ]+int[\t ]+ioctl[\t ]*\([\t ,[:alnum:]]\);";

test_text   = "`touch vxWorks.h`"
"extern int ioctl ( int asdf1234, int jkl, int qwerty ) ;";
};


/*
 *  This hack makes makes unistd.h more POSIX-compliant on VxWorks
 */
fix = {
hackname= vxworks_unistd;
files   = unistd.h;
test= " -r vxWorks.h ";

select  = "#[\t ]*include[\t ]+";
c_fix   = format;
c_fix_arg   = "%0\n#include \n"
"#ifndef STDIN_FILENO\n"
"#define STDIN_FILENO 0\n"
"#endif\n"
"#ifndef STDOUT_FILENO\n"
"#define STDOUT_FILENO 1\n"
"#endif\n"
"#ifndef STDERR_FILENO\n"
"#define STDERR_FILENO 2\n"
"#endif\n";

test_text   = "`touch vxWorks.h`"
"#include \n";
}; 

For some reason fixincludes doesn't seem to be doing *anything* when I build
though - I'm confused as to how I run it.  Though looking at fixincludes/README
and the make check tests, everything *looks* correct.

I'm not sure why fixincludes doesn't appear to be applying any fixes.  I can't
find any headers in GCC's build tree that it's applying to, and it's not
applying them to the system headers either.


[Bug c/52952] Wformat location info is bad (wrong column number)

2012-05-24 Thread dodji at seketeli dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952

--- Comment #11 from dodji at seketeli dot org  
2012-05-24 20:30:10 UTC ---
"manu at gcc dot gnu.org"  a écrit:

>> With the current infrastructure, I fear we cannot re-process the format
>> string *after* the initial pre-processing phase is done, to create new
>> locations that we'd a in the line maps.
>
> Could you elaborate on the reasons for this? Is it impossible to create new
> locations on the fly? 

Not really, no.  It is not practical to insert new locations inside an
existing location map because that would imply to update (modify) all
the maps that come after the one you have modified.  Also, that would
invalidate all the locations that have been encoded by the maps that you
would have updated.

Basically, the current encoding of the map requires that a new location
encoding in a map must always be the last location of that map.  You
cannot insert a location in the "middle" of an existing map.

> As a brute-force approach, we at least should be able to re-preproces the 
> whole
> file, no?

I guess that would take re-processing the whole compilation unit,
starting from the location map that you have changed.  And, just handling
locations wouldn't be enough, we'd need to basically re-tokenize the
files that are re-processed, because the locations are primarily carried
by instances of cpp_token, and we need the locations of these tokens to
be updated.

That doesn't seem practical.

> Could we do this by invoking libcpp directly rather than calling a
> command?

Yes, even though it wouldn't be practical, in my opinion.

>
>> Does that make sense?
>
> This implies that the diagnostics code would need to handle a byte
> offset, no?

Yes, probably.

> And I am not sure this will handle well the case of split strings and macro
> expansion, like Clang does.

Yeah.  Which makes me think that maybe we might want to introduce a new
way to represent string literal tokens in libcpp, that keeps the
underlying raw format.  There would be a character oriented iterator API
for that string literal representation.  And that iterator API could
provide its user with the file/line/column information for the current
character.  And one could pass any such iterator to some of the
diagnostic routines.


[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

2012-05-24 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #3 from Jonathan Wakely  2012-05-24 
20:21:57 UTC ---
No, there's nothing wrong with the cast.

A scoped enumeration type without an explicitly-specified underlying type has a
fixed underlying type of int, so the values of the enumeration type are the
values of int.

Your switch doesn't handle all values, so control can flow off the end of the
function, so the warning is correct.


[Bug fortran/53456] Add time support for VxWorks

2012-05-24 Thread jb at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456

--- Comment #9 from Janne Blomqvist  2012-05-24 20:19:46 
UTC ---
Author: jb
Date: Thu May 24 20:19:37 2012
New Revision: 187846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187846
Log:
PR 53456 CPU timing fallback using clock_gettime.

2012-05-24  Janne Blomqvist  

PR fortran/53456
* intrinsics/time_1.h (gf_cputime): Fallback for clock_gettime.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/time_1.h


[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

2012-05-24 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453

--- Comment #9 from Jakub Jelinek  2012-05-24 
20:12:52 UTC ---
It is correct and desirable.  If you really need and we want to continue the
endless stream of workarounds for Darwin toolchain bugs, then you'd add some
target macro TARGET_FORCE_AT_COMP_DIR or similar, define it in darwin.h and if
non-zero, force addition of the attribute even when the filename is absolute.


[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

2012-05-24 Thread dodji at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-24
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1


[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

2012-05-24 Thread 0xd34df00d at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #2 from Georg Rudoy <0xd34df00d at gmail dot com> 2012-05-24 
20:04:56 UTC ---
(In reply to comment #1)
>   Foo f = Foo(2);
>   assert( DoFoo( f ) );
> 
> Undefined behaviour.

Yes, it is. And isn't it happening at the point of cast of an integer to the
enum class type?


[Bug fortran/53481] Allow for gfortran (f951) specs option

2012-05-24 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53481

--- Comment #1 from Andrew Pinski  2012-05-24 
19:59:20 UTC ---
The trick is to edit cc1_options instead of *cc1.


[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

2012-05-24 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #1 from Jonathan Wakely  2012-05-24 
19:57:19 UTC ---
  Foo f = Foo(2);
  assert( DoFoo( f ) );

Undefined behaviour.


[Bug fortran/53481] New: Allow for gfortran (f951) specs option

2012-05-24 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53481

 Bug #: 53481
   Summary: Allow for gfortran (f951) specs option
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Cf. http://gcc.gnu.org/ml/fortran/2012-05/msg00135.html

As far as I know there is no spec f951, and there is no way to use the
specs file to change the options passed to the Fortran compiler.  The
Fortran frontend doesn't use any named specs that you can change; the
specs are compiled into the driver program directly, from the source
file gcc/fortran/lang-specs.h.


Seemingly, "cc1plus" supports spec files, cf. gcc -dumpspecs


[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

2012-05-24 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453

--- Comment #8 from Jack Howarth  2012-05-24 
19:52:04 UTC ---
Are we sure this test for...

  /* Don't add cwd for .  */
  if (!IS_ABSOLUTE_PATH (filename) && filename[0] != '<')
add_comp_dir_attribute (die);

is still required? The original description says "When dwarf2out sees an input
file without a dir separator, it puts the current working directory
in the list of directories to search.". However this change predates

r70189
Author: aoliva
Date:   Tue Aug 5 21:15:57 2003 UTC (8 years, 9 months ago)
Changed paths:  17
Log Message:
* c.opt: Introduce -fworking-directory.
* doc/cpp.texi, doc/invoke.texi, doc/cppopts.texi: Document it.
* c-common.h (flag_working_directory): Declare.
* c-common.c (flag_working_directory): Define.
* c-opts.c (c_common_handle_options): Set it.
(sanitize_cpp_opts): Set...
* cpplib.h (struct cpp_options): ... working_directory option.
(struct cpp_callbacks): Add dir_change.
* cppinit.c (read_original_filename): Call...
(read_original_directory): New.  Look for # 1 "directory//"
and process it.
(cpp_read_main_file): Call dir_change callback if working_directory
option is set.
* gcc.c (cpp_unique_options): Pass -g*.
* c-lex.c (cb_dir_change): New.
(init_c_lex): Set dir_change callback.
* toplev.c (src_pwd): New static variable.
(set_src_pwd, get_src_pwd): New functions.
* toplev.h (get_src_pwd, set_src_pwd): Declare.
* dbxout.c (dbxout_init): Call get_src_pwd() instead of getpwd().
* dwarf2out.c (gen_compile_unit_die): Likewise.
* dwarfout.c (output_compile_unit_die, dwarfout_init): Likewise.  

which changed...

--- trunk/gcc/dwarf2out.c   2003/08/01 21:51:13 70072
+++ trunk/gcc/dwarf2out.c   2003/08/05 21:15:57 70189
@@ -9506,7 +9506,7 @@
 static void
 add_comp_dir_attribute (dw_die_ref die)
 {
-  const char *wd = getpwd ();
+  const char *wd = get_src_pwd (); 
   if (wd != NULL)
 add_AT_string (die, DW_AT_comp_dir, wd);
 }

so that DW_AT_comp_dir pointed at the source directory rather than at the
working directory. Might that not eliminate dwarf2out putting the current
working directory
in the list of directories to search? Perhaps the hack...

  /* Don't add cwd for .  */
  if (!IS_ABSOLUTE_PATH (filename) && filename[0] != '<')

is no longer required post revision 70189.


[Bug c++/50477] -Wunused-parameter should not warn about virtual method declarations with bodies

2012-05-24 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50477

--- Comment #6 from Jason Merrill  2012-05-24 
19:46:02 UTC ---
I sympathize with your argument, but I think that some users will want the
current behavior.  One way you could work around this that wouldn't involve
uglifying every affected function would be to add

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"



#pragma GCC diagnostic pop

around the header.


[Bug tree-optimization/53480] warning "may be used uninitialized" issued with -m32 but not with -m64

2012-05-24 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53480

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization

--- Comment #1 from Andrew Pinski  2012-05-24 
19:41:07 UTC ---
This warning depends on optimization.  In this case, it depends on sra doing
something.


[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

2012-05-24 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453

--- Comment #7 from Jack Howarth  2012-05-24 
19:35:09 UTC ---
Are we really sure that gen_compile_unit_die() shouldn't being emitting calling
add_comp_dir_attribute  in this case. It seems that the origin of test...

  /* Don't add cwd for .  */
  if (!IS_ABSOLUTE_PATH (filename) && filename[0] != '<')
add_comp_dir_attribute (die);

Dates back to...

Author: amylaar
Date:   Wed Jun 4 17:19:36 2003 UTC (8 years, 11 months ago)
Changed paths:  3
Log Message:
* c-decl.c (c_init_decl_processing): Clear input_file_name
while building common nodes.
* dwarf2out.c (gen_compile_unit_die, dwarf2out_finish):
Don't add working directory for strings like  .

The reasoning for that change is described in the patch proposal at
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00149.html
which says...

I have found that pch/system-1.c fails on sh-elf because
the function that is called by BUILD_VA_LIST_TYPE generates
some declarations which end up in the debugging output for
this testcase.  toplev.c has previously set the input filename
to that of the main file - which is different when you compile
a header than when you do an ordinary source compilation.
This causes an anadorned "system-1.h" to be considered among
the source files in the pch case (even though it does nothing
but include other header files).  When dwarf2out sees an input
file without a dir separator, it puts the current working directory
in the list of directories to search.

The patch was revised a number of times...

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00289.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00151.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00279.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00284.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00289.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00301.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00303.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00308.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00337.html

Reading through reviews doesn't give much confidence that this code is test is
bullet-proof.


[Bug c/53480] New: warning "may be used uninitialized" issued with -m32 but not with -m64

2012-05-24 Thread gbburkhardt at verizon dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53480

 Bug #: 53480
   Summary: warning "may be used uninitialized" issued with -m32
but not with -m64
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gbburkha...@verizon.net


For the following program, a warning is issued with "-m32", but not with
"-m64".

armis@armis-00:~$ gcc -c -O2 -g -Wall -m32 -std=gnu99 tt.c
tt.c: In function ‘sub’:
tt.c:18:29: warning: ‘v0.minValue’ may be used uninitialized in this function
[-Wuninitialized]
tt.c:21:29: warning: ‘v0.maxValue’ may be used uninitialized in this function
[-Wuninitialized]
armis@armis-00:~$ gcc -c -O2 -g -Wall -m64 -std=gnu99 tt.c
armis@armis-00:~$

#include 
typedef struct {
double minValue, maxValue;
} Range;

void getNewRange(Range*);

void sub() 
{
Range v0, v1;

for (int i=0; i < 2; i++) {
getNewRange(&v1);
if (i == 0) {
v0.minValue = v1.minValue;
v0.maxValue = v1.minValue;
} else {
if (v0.minValue > v1.minValue)
v0.minValue = v1.minValue;

if (v0.maxValue < v1.maxValue)
v0.maxValue = v1.maxValue;
}
}

printf("min=%f, max=%f\n", v0.minValue, v0.maxValue);   
}

armis@armis-00:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)


[Bug c++/53479] New: Control flow analysis too alarming with switch over an enum class

2012-05-24 Thread 0xd34df00d at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

 Bug #: 53479
   Summary: Control flow analysis too alarming with switch over an
enum class
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 0xd34df...@gmail.com


Created attachment 27492
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27492
A very simple testcase

If a non-void function consists of a switch over a variable of an enum class,
and all possible values of the enum class are listed in the cases, and each
case ends with a return, gcc 4.6 and later still emits a "control reaches end
of non-void function" warning. gcc 4.5 and earlier don't exhibit such behavior
(as well as clang, if that matters). See the attached file for an example.

While this is a somewhat reasonable behavior for switches over a plain enum, I
doubt it is OK to emit this warning, at least, with such a generic option as
-Wreturn-type. If neither case succeeds, then you have had an UB somewhere in
your code previously, but I doubt it's good to warn the user in the switch.

Moreover, adding a 'default' clause allows to shoot yourself in the foot later
when adding one more field in the enum — the compiler won't warn you that you
didn't check it. Adding a dummy return after the switch seems more like a
kludge.

If there are strong considerations for this warning in this case, I suggest
moving it to a separate warning class, like -Wreturn-enum-class or something
like that. This way those who don't need this check will be able to disable it
without hurting other cases where it's useful for them.


[Bug c/52952] Wformat location info is bad (wrong column number)

2012-05-24 Thread manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952

--- Comment #10 from Manuel López-Ibáñez  2012-05-24 
19:05:26 UTC ---
(In reply to comment #9)
> "manu at gcc dot gnu.org"  a écrit:
> 
> > So either one keeps track of all source locations of all "interesting"
> > characters within strings, which sounds infeasible. Or one needs to
> > re-preprocess the format string, creating new locations on-the-fly. Dodji, 
> > is
> > this possible?
> 
> With the current infrastructure, I fear we cannot re-process the format
> string *after* the initial pre-processing phase is done, to create new
> locations that we'd a in the line maps.

Could you elaborate on the reasons for this? Is it impossible to create new
locations on the fly? 

As a brute-force approach, we at least should be able to re-preproces the whole
file, no? Could we do this by invoking libcpp directly rather than calling a
command? 

> Does that make sense?

This implies that the diagnostics code would need to handle a byte offset, no? 

And I am not sure this will handle well the case of split strings and macro
expansion, like Clang does.


[Bug c++/50134] -Wmissing-prototypes doesn't work for C++

2012-05-24 Thread manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|NEW

--- Comment #12 from Manuel López-Ibáñez  2012-05-24 
18:53:07 UTC ---
I was planning to submit this doc patch for approval, but I am quite busy with
personal stuff right now. Feel free to adopt the patch, if you think it is
interesting enough.


[Bug fortran/53478] gfortran segfaults when module name clashes with C binding name of procedure

2012-05-24 Thread sgk at troutmask dot apl.washington.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53478

--- Comment #3 from Steve Kargl  
2012-05-24 18:44:54 UTC ---
On Thu, May 24, 2012 at 05:57:26PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> This patch allows the code to compile.  I haven't
> tried to construct a longer example that may show
> that the module name  may collide with the C binding
> name.
> 

I've now constructed a simple test and needed to
revise the patch.

troutmask:sgk[263] cat a.f90
module exports

   implicit none

   contains

  subroutine f_exports() bind(C, name='exports')
 print *, 'Exported'
  end subroutine

end module exports
troutmask:sgk[264]  cat e.c
#include 

void exports(void);

int
main(void)
{
  exports();
  return 0;
}
troutmask:sgk[265] gfc4x -c a.f90
troutmask:sgk[266] cc -o z e.c a.o -L$HOME/work/4x/lib -lgfortran
troutmask:sgk[267] ./z
 Exported

The patch is attached.


[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

2012-05-24 Thread dodji at seketeli dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53459

--- Comment #1 from dodji at seketeli dot org  
2012-05-24 18:43:52 UTC ---
Right, and there is:

#elif (GCC_VERSION >= 4005) && defined(__ALTIVEC__)

right before the offending line, which explains why I haven't seen the
bootstrap error before committing, as I don't run any ALTIVEC system.

I'll cook up a patch for this.  Thank you for filling this bug.


[Bug c/52952] Wformat location info is bad (wrong column number)

2012-05-24 Thread dodji at seketeli dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952

--- Comment #9 from dodji at seketeli dot org  
2012-05-24 18:38:40 UTC ---
"manu at gcc dot gnu.org"  a écrit:

> So either one keeps track of all source locations of all "interesting"
> characters within strings, which sounds infeasible. Or one needs to
> re-preprocess the format string, creating new locations on-the-fly. Dodji, is
> this possible?

With the current infrastructure, I fear we cannot re-process the format
string *after* the initial pre-processing phase is done, to create new
locations that we'd a in the line maps.

However, briefly looking at the source code, we might be able to pull
this whole shebang off, in a way.

I am thinking that in gcc/c-family/c-format.c:check_format_info_main, we
can arrange for the instance of format_kind_info (that is the result of
parsing the format string) to carry the virtual location  of the
beginning of the format string *and* the offset of the relevant
character we might want to warn about.

Then, later the routines that trigger the warning by analyzing the instance of
format_kind_info could be passed the relevant location for the beginning
of the of the format string as well as the byte offset of the relevant
character I talked about above.  At warning type, it could re-construct
the exact column where of that relevant character, with its byte offset
and the virtual location of the beginning of the format string.

Does that make sense?


[Bug c++/53322] Wunused-local-typedefs is not enabled by Wall or Wunused

2012-05-24 Thread dodji at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53322

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Dodji Seketeli  2012-05-24 
18:06:09 UTC ---
Fixed in trunk (4.8).


[Bug fortran/53478] gfortran segfaults when module name clashes with C binding name of procedure

2012-05-24 Thread sgk at troutmask dot apl.washington.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53478

--- Comment #2 from Steve Kargl  
2012-05-24 17:57:26 UTC ---
On Thu, May 24, 2012 at 05:23:50PM +, kargl at gcc dot gnu.org wrote:
> #1  0x0050aa91 in gfc_verify_binding_labels (sym=0x203cd1280)
> at ../../gcc4x/gcc/fortran/resolve.c:9847
> 9847  if (sym->attr.if_source == IFSRC_DECL 
> (gdb) list
> 9842
> 9843  bind_c_sym = gfc_find_gsymbol (gfc_gsym_root,
> sym->binding_label);
> 9844  if (bind_c_sym != NULL 
> 9845  && strcmp (bind_c_sym->name, sym->binding_label) == 0)
> 9846{
> 9847  if (sym->attr.if_source == IFSRC_DECL 
> 9848  && (bind_c_sym->type != GSYM_SUBROUTINE 
> 9849  && bind_c_sym->type != GSYM_FUNCTION) 
> 9850  && ((sym->attr.contained == 1 
> 9851   && strcmp (bind_c_sym->sym_name, sym->name) != 0) 
> (gdb) print *bind_c_sym
> $1 = {priority = 41101, left = 0x0, right = 0x0, name = 0x20400bf80 
> "exports", 
>   sym_name = 0x0, mod_name = 0x0, binding_label = 0x0, type = GSYM_MODULE, 
>   defined = 1, used = 0, where = {nextc = 0x203ca61f8, lb = 0x203ca61a0}, 
>   ns = 0x203c62c00}
> 
> Note, sym->binding_label is 0x0


This patch allows the code to compile.  I haven't
tried to construct a longer example that may show
that the module name  may collide with the C binding
name.


Index: resolve.c
===
--- resolve.c   (revision 187464)
+++ resolve.c   (working copy)
@@ -9848,6 +9848,8 @@ gfc_verify_binding_labels (gfc_symbol *s
   && (bind_c_sym->type != GSYM_SUBROUTINE 
   && bind_c_sym->type != GSYM_FUNCTION) 
   && ((sym->attr.contained == 1 
+  && bind_c_sym->sym_name != NULL
+  && sym->name != NULL
&& strcmp (bind_c_sym->sym_name, sym->name) != 0) 
   || (sym->attr.use_assoc == 1 
   && (strcmp (bind_c_sym->mod_name, sym->module) != 0


[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c

2012-05-24 Thread hp at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #2 from Hans-Peter Nilsson  2012-05-24 
17:44:51 UTC ---
Must be universal; cris-elf too, 187822:187825.


[Bug fortran/53478] gfortran segfaults when module name clashes with C binding name of procedure

2012-05-24 Thread kargl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53478

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-24
 CC||kargl at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org 2012-05-24 17:23:50 UTC ---
Confirmed.
(gdb) bt
#0  0x000202c0103c in strcmp () from /lib/libc.so.7
#1  0x0050aa91 in gfc_verify_binding_labels (sym=0x203cd1280)
at ../../gcc4x/gcc/fortran/resolve.c:9847
#2  0x0052cf40 in do_traverse_symtree (st=0x203c183a0, st_func=0, 
sym_func=0x50a840 )
at ../../gcc4x/gcc/fortran/symbol.c:3386
#3  0x0051c030 in resolve_types (ns=0x203c63600)
at ../../gcc4x/gcc/fortran/resolve.c:13984
#4  0x0051bef8 in resolve_types (ns=0x203c62c00)
at ../../gcc4x/gcc/fortran/resolve.c:13965
#5  0x0050feec in gfc_resolve (ns=0xfff8)
at ../../gcc4x/gcc/fortran/resolve.c:14054
#6  0x00502a48 in gfc_parse_file ()
at ../../gcc4x/gcc/fortran/parse.c:4594
#7  0x0053c90e in gfc_be_parse_file ()
at ../../gcc4x/gcc/fortran/f95-lang.c:191
#8  0x008f57f0 in compile_file () at ../../gcc4x/gcc/toplev.c:552
#9  do_compile () at ../../gcc4x/gcc/toplev.c:1874
#10 0x008f5e4c in toplev_main (argc=2, argv=0x7fffd4e0)
at ../../gcc4x/gcc/toplev.c:1950
#11 0x00499a6d in _start ()
(gdb) up 1
#1  0x0050aa91 in gfc_verify_binding_labels (sym=0x203cd1280)
at ../../gcc4x/gcc/fortran/resolve.c:9847
9847  if (sym->attr.if_source == IFSRC_DECL 
(gdb) list
9842
9843  bind_c_sym = gfc_find_gsymbol (gfc_gsym_root,
sym->binding_label);
9844  if (bind_c_sym != NULL 
9845  && strcmp (bind_c_sym->name, sym->binding_label) == 0)
9846{
9847  if (sym->attr.if_source == IFSRC_DECL 
9848  && (bind_c_sym->type != GSYM_SUBROUTINE 
9849  && bind_c_sym->type != GSYM_FUNCTION) 
9850  && ((sym->attr.contained == 1 
9851   && strcmp (bind_c_sym->sym_name, sym->name) != 0) 
(gdb) print *bind_c_sym
$1 = {priority = 41101, left = 0x0, right = 0x0, name = 0x20400bf80 "exports", 
  sym_name = 0x0, mod_name = 0x0, binding_label = 0x0, type = GSYM_MODULE, 
  defined = 1, used = 0, where = {nextc = 0x203ca61f8, lb = 0x203ca61a0}, 
  ns = 0x203c62c00}

Note, sym->binding_label is 0x0


[Bug lto/53470] [4.8 LTO] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264

2012-05-24 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-24
 CC||hjl.tools at gmail dot com
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2012-05-24 17:15:57 
UTC ---
Works for me on Linux/x86-64 with revision 187825 and BFD linker on
trunk.  Can you try BFD linker?


[Bug lto/53471] [4.7/4.8 Regression] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)

2012-05-24 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471

H.J. Lu  changed:

   What|Removed |Added

  Component|debug   |lto
   Target Milestone|4.8.0   |4.7.1
Summary|[4.8 LTO] ICE in|[4.7/4.8 Regression] ICE in
   |pp_base_format, at  |pp_base_format, at
   |pretty-print.c:510 (-flto   |pretty-print.c:510 (-flto
   |-g) |-g)


[Bug debug/53471] [4.8 LTO] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)

2012-05-24 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-24
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2012-05-24 17:07:47 
UTC ---
It is caused by revision 182479:

http://gcc.gnu.org/ml/gcc-cvs/2011-12/msg00618.html


[Bug fortran/53478] New: gfortran segfaults when module name clashes with C binding name of procedure

2012-05-24 Thread solomon.gibbs.lists at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53478

 Bug #: 53478
   Summary: gfortran segfaults when module name clashes with C
binding name of procedure
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: solomon.gibbs.li...@gmail.com


gfortran segfaults rather than producing a compiler error when a module
procedure is bound with the same name as the module.

e.g.

module exports
implicit none

contains

subroutine f_exports() bind(C, name='exports')
end subroutine

end module exports


gfortran -funderscoring -O0 -g -Wall -c -fmessage-length=0 -o "exports.o"
"../exports.f08"
f951.exe: internal compiler error: Segmentation fault

Possibly related to Bug 48858 ?


[Bug libstdc++/53477] New: pretty printer fails with: Python Exception list index out of range

2012-05-24 Thread pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477

 Bug #: 53477
   Summary: pretty printer fails with: Python Exception  list index out of range
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


Created attachment 27490
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27490
testcase

$ x86_64-gnu-linux-g++ t.cpp -Wall -o t -g2 -gdwarf-4
$ cgdb ./t

in line 15 pretty printer fails with error.

 7│ int main()
 8│ {
 9│ icapSelection_[ /* frame */ 7 ][ /* word */ 3 ].insert( 5 );
10│ icapSelection_[ /* frame */ 7 ][ /* word */ 3 ].insert( 1 );
11│ for ( IcapSelection::const_iterator i = icapSelection_.begin(); i
!= icapSelection_.end(); ++i )
12│ {
13│ IcapSelection::key_type frame( i->first );
14│ IcapSelection::mapped_type const& wordBitsetMap( i->second
);
15├───> for ( IcapSelection::mapped_type::const_iterator j =
wordBitsetMap.begin(); j != wordBitsetMap.end(); ++j )
16│ {
17│ IcapSelection::mapped_type::key_type word( j->first
);
18│ IcapSelection::mapped_type::mapped_type const&
bits( j->second );
19│ for (
IcapSelection::mapped_type::mapped_type::const_iterator k = bits.begin(); k !=
bits.end(); ++k )
20│ {
21│ unsigned bit( *k );
22│ }
23│ }
24│ }
25│ }
/home/users/pawels/dvm.git/t.cpp

Breakpoint 1, main () at t.cpp:9
(gdb) n
(gdb)
(gdb) p icapSelection_
$1 = std::map with 1 elements = {
  [7] = std::map with 1 elements = {
[3] = std::set with 2 elements = {
  [0] = 1,
  [1] = 5
}
  }
}
(gdb) n
(gdb)
(gdb)
(gdb) p wordBitsetMap
$2 = Python Exception  list index out of range:
std::map with 1 elements


[Bug c++/50477] -Wunused-parameter should not warn about virtual method declarations with bodies

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50477

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Paolo Carlini  2012-05-24 
15:33:22 UTC ---
Jason, it would be great if you could help us completing the triage of this.


[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c

2012-05-24 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476

H.J. Lu  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.8.0

--- Comment #1 from H.J. Lu  2012-05-24 15:31:31 
UTC ---
It is caused by revision 187823:

http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00820.html


[Bug c++/50134] -Wmissing-prototypes doesn't work for C++

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134

--- Comment #11 from Paolo Carlini  2012-05-24 
15:29:42 UTC ---
Manuel, what happened to this, out of curiosity? I see an Assigned status (but
the Assigned To field still blank) and a documentation patchlet of yours in the
audit trail?!


[Bug c++/25751] Poor error when templating on undefined types

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25751

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|gcc-bugs at gcc dot gnu.org |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #3 from Paolo Carlini  2012-05-24 
15:25:35 UTC ---
Let's see if we can make some progress.


[Bug c++/25751] Poor error when templating on undefined types

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25751

Paolo Carlini  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  2012-05-24 
15:22:08 UTC ---
*** Bug 53412 has been marked as a duplicate of this bug. ***


[Bug c++/53412] Error recovery for class types is poor

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53412

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Paolo Carlini  2012-05-24 
15:22:08 UTC ---
It's the same issue. Note, the bit about default template arguments is very
easy to fix.

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


[Bug c++/53464] Invalid default value for non-type template parameter is accepted

2012-05-24 Thread paolo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53464

--- Comment #6 from paolo at gcc dot gnu.org  
2012-05-24 15:12:45 UTC ---
Author: paolo
Date: Thu May 24 15:12:37 2012
New Revision: 187842

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187842
Log:
2012-05-24  Paolo Carlini  

PR c++/53464
* g++.dg/cpp0x/constexpr-default1.C: New.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-default1.C
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug c++/32080] Can goto a function try-block

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32080

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #4 from Paolo Carlini  2012-05-24 
15:10:03 UTC ---
Fixed.


[Bug c++/53455] boost::python segfault

2012-05-24 Thread org.gnu.gcc.bugtracker at sotecware dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455

--- Comment #8 from Jonas Wielicki  2012-05-24 14:48:23 UTC ---
I was able to use the VM sooner than expected, so sorry for the doublepost.

I found that whether using no_init or init<>() does not make a difference in my
case. To use init<>() on the base class, I had to change the pure virtual
function to be non-pure, but that did not affect the result.


[Bug c++/32080] Can goto a function try-block

2012-05-24 Thread paolo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32080

--- Comment #3 from paolo at gcc dot gnu.org  
2012-05-24 14:47:12 UTC ---
Author: paolo
Date: Thu May 24 14:47:06 2012
New Revision: 187837

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187837
Log:
/cp
2012-05-24  Paolo Carlini  

PR c++/32080
* parser.c (cp_parser_ctor_initializer_opt_and_function_body,
cp_parser_function_body): Add a bool parameter, true when parsing
a function-try-block.
(cp_parser_function_try_block): Pass true to the above.
(cp_parser_function_definition_after_declarator,
cp_parser_function_transaction): Adjust.

/testsuite
2012-05-24  Paolo Carlini  

PR c++/32080
* g++.dg/eh/goto2.C: New.


Added:
trunk/gcc/testsuite/g++.dg/eh/goto2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


[Bug libstdc++/53475] Section type conflict errors in libstdc++ testsuite

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475

--- Comment #1 from Paolo Carlini  2012-05-24 
14:41:59 UTC ---
Please try to narrow the commit which is causing the problem a bit more: to be
really honest, it's the first time in my life I see this kind of error message
and I really doubt the library itself or even the C++ front-end is the culprit.


[Bug c++/53455] boost::python segfault

2012-05-24 Thread org.gnu.gcc.bugtracker at sotecware dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455

--- Comment #7 from Jonas Wielicki  2012-05-24 14:32:37 UTC ---
Interestingly, I am using no_init too, but without supplying an alternative
constructor. I am not at the testing machine right now, but I thought I'd share
that bit of information. Testing whether the bug reoccurs when using bp::init
will follow soon!


[Bug middle-end/53476] New: [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c

2012-05-24 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476

 Bug #: 53476
   Summary: [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86, revision 187825 gave:

FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
Excess errors:
attr-weakref-1.c:(.text.startup+0x78): undefined reference to `Wv10a'
attr-weakref-1.c:(.text.startup+0x82): undefined reference to `Wv11a'

WARNING: gcc.dg/attr-weakref-1.c compilation failed to produce executable

Revision 187799 is OK.


[Bug libstdc++/53475] New: Section type conflict errors in libstdc++ testsuite

2012-05-24 Thread Greta.Yorsh at arm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475

 Bug #: 53475
   Summary: Section type conflict errors in libstdc++ testsuite
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: greta.yo...@arm.com
CC: paolo.carl...@oracle.com


Failures due to "section type conflict" in libstdc++-v3 testsuite:

FAIL: 20_util/tuple/creation_functions/tie2.cc (test for excess errors)
Excess errors:
/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/include/tuple:1057:25:
error: std::ignore causes a section type conflict with std::ignore

FAIL: 25_algorithms/stable_sort/49559.cc (test for excess errors)
Excess errors:
/work/local-checkouts/gcc-fsf/libstdc++-v3/testsuite/25_algorithms/stable_sort/49559.cc:37:11:
error: A causes a section type conflict with A

Known to fail: r187724
Known to work: r187546

Executing on host: /work/builds/a9-may/arm-none-eabi/gcc2/./gcc/g++
-shared-libgcc -B/work/builds/a9-may/arm-none-eabi/gcc2/./gcc -nostdinc++
-L/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/src
-L/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/src/.libs
-B/work/builds/a9-may/install/arm-none-eabi/bin/
-B/work/builds/a9-may/install/arm-none-eabi/lib/ -isystem
/work/builds/a9-may/install/arm-none-eabi/include -isystem
/work/builds/a9-may/install/arm-none-eabi/sys-include
-B/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-g -O2 -DLOCALEDIR="." -nostdinc++
-I/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/include/arm-none-eabi
-I/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/include
-I/work/local-checkouts/gcc-fsf/libstdc++-v3/libsupc++
-I/work/local-checkouts/gcc-fsf/libstdc++-v3/include/backward
-I/work/local-checkouts/gcc-fsf/libstdc++-v3/testsuite/util
/work/local-checkouts/gcc-fsf/libstdc++-v3/testsuite/20_util/tuple/creation_functions/tie2.cc
libstdc++_tg.o   -std=gnu++0x ./libtestc++.a-Wl,-wrap,exit
-Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm   -o ./tie2.exe(timeout
= 600)
In file included from
/work/local-checkouts/gcc-fsf/libstdc++-v3/testsuite/20_util/tuple/creation_functions/tie2.cc:22:0:
/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/include/tuple:1057:25:
error: std::ignore causes a section type conflict with std::ignore
   const _Swallow_assign ignore{};
 ^

Executing on host: /work/builds/a9-may/arm-none-eabi/gcc2/./gcc/g++
-shared-libgcc -B/work/builds/a9-may/arm-none-eabi/gcc2/./gcc -nostdinc++
-L/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/src
-L/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/src/.libs
-B/work/builds/a9-may/install/arm-none-eabi/bin/
-B/work/builds/a9-may/install/arm-none-eabi/lib/ -isystem
/work/builds/a9-may/install/arm-none-eabi/include -isystem
/work/builds/a9-may/install/arm-none-eabi/sys-include
-B/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-g -O2 -DLOCALEDIR="." -nostdinc++
-I/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/include/arm-none-eabi
-I/work/builds/a9-may/arm-none-eabi/gcc2/arm-none-eabi/libstdc++-v3/include
-I/work/local-checkouts/gcc-fsf/libstdc++-v3/libsupc++
-I/work/local-checkouts/gcc-fsf/libstdc++-v3/include/backward
-I/work/local-checkouts/gcc-fsf/libstdc++-v3/testsuite/util
/work/local-checkouts/gcc-fsf/libstdc++-v3/testsuite/25_algorithms/stable_sort/49559.cc
libstdc++_tg.o   -std=gnu++0x ./libtestc++.a-Wl,-wrap,exit
-Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm   -o ./49559.exe(timeout
= 600)
/work/local-checkouts/gcc-fsf/libstdc++-v3/testsuite/25_algorithms/stable_sort/49559.cc:37:11:
error: A causes a section type conflict with A
 const int A[] = { 10 };
   ^


[Bug c++/53455] boost::python segfault

2012-05-24 Thread ndbecker2 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455

Neal Becker  changed:

   What|Removed |Added

 CC||ndbecker2 at gmail dot com

--- Comment #6 from Neal Becker  2012-05-24 
14:22:43 UTC ---
I believe I hit the same bug, using extract on a polymorphic type.

In the old code (which segfaults), I used make_constructor, passing object to
it, and using 
extract.

In the new code (which does not segfault), I don't use make_constructor, just
use bp::init.  My segfault 
is gone.  Maybe just luck?

valgrind python test_constellation.py 
==6162== Memcheck, a memory error detector
==6162== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==6162== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6162== Command: python test_constellation.py
==6162== 
==6162== Invalid read of size 8
==6162==at 0x11B79748:
boost::python::objects::polymorphic_id_generator
>::execute(void*) (inheritance.hpp:43)
==6162==by 0x13F585A3: boost::(anonymous namespace)::convert_type(void*,
boost::python::type_info, boost::python::type_info, bool) (in
/usr/local/src/boost_1_49_0.hg.nondarray/stage/lib/libboost_python.so.1.49.0)
==6162==by 0x11B857D9:
boost::python::objects::pointer_holder
>, QAMconstellation >::holds(boost::python::type_info, bool)
(pointer_holder.hpp:150)
==6162==by 0x13F50006: boost::python::objects::find_instance_impl(_object*,
boost::python::type_info, bool) (in
/usr/local/src/boost_1_49_0.hg.nondarray/stage/lib/libboost_python.so.1.49.0)
==6162==by 0x13F4B304:
boost::python::converter::rvalue_from_python_stage1(_object*,
boost::python::converter::registration const&) (in
/usr/local/src/boost_1_49_0.hg.nondarray/stage/lib/libboost_python.so.1.49.0)
==6162==by 0x11B82F02:
boost::python::converter::arg_rvalue_from_python
const&>::arg_rvalue_from_python(_object*) (arg_from_python.hpp:299)
==6162==by 0x11B81BEA: boost::python::arg_from_python
const&>::arg_from_python(_object*) (arg_from_python.hpp:70)
...

This particular code uses inheritance (I rarely use it).  It looks something
like:


BOOST_PYTHON_MODULE(constellation) {

  boost::numpy::initialize();

  class_, boost::noncopyable > ("constellation_base",
no_init)
.def ("__call__", &apply_constellation)
.def ("hard_decision", &apply_hard_decision)
.add_property ("size", &constellation::size)
.add_property ("gain", &constellation::gain)
;

  class_ , bases > >
("QAMconstellation", no_init)
.def ("__init__", make_constructor (qam_from_object))
.add_property ("map", &get_map)
.def_pickle(const_pickle_suite())
;
...


[Bug bootstrap/53472] contrib/compare-debug should strip out .comment section

2012-05-24 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53472

H.J. Lu  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org
   Target Milestone|--- |4.8.0

--- Comment #1 from H.J. Lu  2012-05-24 14:02:52 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01623.html


[Bug ada/5911] Support for multilib in Ada

2012-05-24 Thread peter777778 at hotmail dot co.uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911

online games  changed:

   What|Removed |Added

 CC||peter78 at hotmail dot
   ||co.uk

--- Comment #29 from online games  2012-05-24 
14:00:32 UTC ---
http://free-online-games-mmorpg.blogspot.co.uk/


[Bug fortran/53456] Add time support for VxWorks

2012-05-24 Thread rbmj at verizon dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456

rbmj at verizon dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #8 from rbmj at verizon dot net 2012-05-24 14:00:00 UTC ---
Fixed in 187806.  Enhancements pending:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01579.html


[Bug target/53474] [4.8 regression] Solaris/x86 bootstrap with Sun as broken: j.e

2012-05-24 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53474

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-24
 AssignedTo|unassigned at gcc dot   |ubizjak at gmail dot com
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Uros Bizjak  2012-05-24 13:59:02 
UTC ---
Created attachment 27489
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27489
Untested patch

Can you please test attached patch?


[Bug c++/20624] [4.0 Regression] wrong "control reaches end of non-void function" warning

2012-05-24 Thread peter777778 at hotmail dot co.uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20624

online games  changed:

   What|Removed |Added

 CC||peter78 at hotmail dot
   ||co.uk

--- Comment #29 from online games  2012-05-24 
13:57:55 UTC ---
http://free-online-games-mmorpg.blogspot.co.uk/


[Bug target/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

2012-05-24 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385

--- Comment #15 from William J. Schmidt  
2012-05-24 13:54:24 UTC ---
Author: wschmidt
Date: Thu May 24 13:54:16 2012
New Revision: 187835

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187835
Log:
2012-05-24  Bill Schmidt  

Backport from mainline
2012-05-18  Bill Schmidt  

PR target/53385
* config/rs6000/rs6000.c (print_operand): Revise code that unsafely
relied on signed overflow behavior.

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


[Bug target/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

2012-05-24 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385

--- Comment #14 from William J. Schmidt  
2012-05-24 13:53:03 UTC ---
Author: wschmidt
Date: Thu May 24 13:52:56 2012
New Revision: 187834

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187834
Log:
2012-05-24  Bill Schmidt  

Backport from mainline
2012-05-18  Bill Schmidt  

PR target/53385
* config/rs6000/rs6000.c (print_operand): Revise code that unsafely
relied on signed overflow behavior.

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

--- Comment #15 from William J. Schmidt  
2012-05-24 13:54:24 UTC ---
Author: wschmidt
Date: Thu May 24 13:54:16 2012
New Revision: 187835

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187835
Log:
2012-05-24  Bill Schmidt  

Backport from mainline
2012-05-18  Bill Schmidt  

PR target/53385
* config/rs6000/rs6000.c (print_operand): Revise code that unsafely
relied on signed overflow behavior.

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


[Bug target/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

2012-05-24 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385

--- Comment #14 from William J. Schmidt  
2012-05-24 13:53:03 UTC ---
Author: wschmidt
Date: Thu May 24 13:52:56 2012
New Revision: 187834

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187834
Log:
2012-05-24  Bill Schmidt  

Backport from mainline
2012-05-18  Bill Schmidt  

PR target/53385
* config/rs6000/rs6000.c (print_operand): Revise code that unsafely
relied on signed overflow behavior.

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


[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

2012-05-24 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453

--- Comment #6 from Jack Howarth  2012-05-24 
13:53:34 UTC ---
(In reply to comment #5)
> gcc hasn't changed the emitted DWARF in this case for more than 12 years.

Actually Apple gcc-4.2.1 doesn't seem to emit AT_comp_dir either but both
llvm-gcc-4.2 and clang do. Since Apple has deprecated support for the legacy
non-llvm based compilers, I believe they are expected the same dwarf output as
from llvm based compilers for the linker now. This means that both AT_name and
AT_comp_dir have to be present in the TAG_compile_unit section of each object
file.


[Bug target/53474] [4.8 regression] Solaris/x86 bootstrap with Sun as broken: j.e

2012-05-24 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53474

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0


[Bug target/53474] New: [4.8 regression] Solaris/x86 bootstrap with Sun as broken: j.e

2012-05-24 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53474

 Bug #: 53474
   Summary: [4.8 regression] Solaris/x86 bootstrap with Sun as
broken: j.e
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ubiz...@gmail.com
  Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
 Build: i386-pc-solaris2.11


As of 20120524, Solaris/x86 bootstrap with Sun as is broken configuring the
stage1
libgcc:

configure:4192: checking whether to use setjmp/longjmp exceptions
configure:: /var/gcc/regression/trunk/11-gcc/build/./gcc/xgcc
-B/var/gcc/regression/trunk/11-gcc/build/./gcc/
-B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/
-isystem /vol/gcc/i386-pc-solaris2.11/include -isystem
/vol/gcc/i386-pc-solaris2.11/sys-include-c --save-temps -fexceptions 
conftest.c >&5
Assembler: conftest.c
"conftest.s", line 26 : Illegal mnemonic
Near line: "j.e.L10"
"conftest.s", line 26 : Syntax error
Near line: "j.e.L10"
"conftest.s", line 26 : Illegal mnemonic
Near line: "j.e.L10"

The only change from 4.7 is:

--- conftest47.s2012-05-24 15:29:43.645405136 +0200
+++ conftest.s  2012-05-24 15:30:03.887899516 +0200
@@ -23,7 +23,7 @@
callclean
 .LEHE1:
cmpl$1, %ebx
-   je  .L10
+   j.e .L10
jmp .L9
 .L7:
movl%eax, %esi

I'm pretty sure one of your last i386 changes is the culprit, but couldn't
immediately pinpoint it.

  Rainer


[Bug c++/53473] New: [C++11] static constexpr noexcept cannot be specialized

2012-05-24 Thread kretz at kde dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53473

 Bug #: 53473
   Summary: [C++11] static constexpr noexcept cannot be
specialized
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kr...@kde.org


The following testcase does not compile.

template struct A
{
static constexpr T foo() noexcept { return 0; }
};

template<> constexpr int A::foo() noexcept { return 0; }

This would be a common pattern to specialize functions of std::numeric_limits,
but it's currently only possible to specialize the whole numeric_limits class.


[Bug bootstrap/53472] New: contrib/compare-debug should strip out .comment section

2012-05-24 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53472

 Bug #: 53472
   Summary: contrib/compare-debug should strip out .comment
section
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


From

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00284.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197

Now, as to why for me BUILD_CONFIG isn't bootstrap-debug: configure.ac
activates this by default, but then checks if contrib/compare-debug
actually works for comparing a debug and non-debug .o file.  And for
SuSE systems it doesn't, because our system compilers encode some command
line options (among them -g) into a special .comment section.

Any chance you could adjust the script to strip out the .comment section
you mentioned elsewhere, so that you get faster bootstrap with
bootstrap-debug testing too?


[Bug fortran/45170] [F2003] allocatable character lengths

2012-05-24 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170

--- Comment #37 from Tobias Burnus  2012-05-24 
13:08:33 UTC ---
(In reply to comment #36)
> REMAINING issues:
> - comment 24 first "Does not work.", see also comment 34

One has in gfc_trans_assignment_1:

   string_length = gfc_evaluate_now (rse.string_length, &rse.pre);
   ...
   if (...)
 gfc_add_block_to_block (&block, &rse.pre);

where the (...) evaluates to false. (The call in gfc_trans_scalar_assign then
works on rse->string_length, which seems seems to handle the
gfc_add_block_to_block for rse.pre.)

The following works, but I am not sure about the condition; I have the feeling
that it could be handled unconditionally.

--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6893,3 +6897,2 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr *
expr2, bool init_flag,
   bool scalar_to_array;
-  bool def_clen_func;
   tree string_length;
@@ -7012,9 +7015,4 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr *
expr2, bool init_flag,
  parameter available to the caller; gfortran saves it in the .mod files.
*/
-  def_clen_func = (expr2->expr_type == EXPR_FUNCTION
-  || expr2->expr_type == EXPR_COMPCALL
-  || expr2->expr_type == EXPR_PPC);
-  if (gfc_option.flag_realloc_lhs
-   && expr2->ts.type == BT_CHARACTER
-   && (def_clen_func || expr2->expr_type == EXPR_OP)
-   && expr1->ts.deferred)
+  if (gfc_option.flag_realloc_lhs && expr2->ts.type == BT_CHARACTER
+  && expr1->ts.deferred)
 gfc_add_block_to_block (&block, &rse.pre);


[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant

2012-05-24 Thread Greta.Yorsh at arm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53463

Greta Yorsh  changed:

   What|Removed |Added

 CC||Greta.Yorsh at arm dot com

--- Comment #2 from Greta Yorsh  2012-05-24 
13:08:57 UTC ---
The following tests fail on arm-none-eabi:

FAIL: gcc.dg/cpp/19990407-1.c (test for excess errors)
FAIL: gcc.dg/cpp/paste12.c (test for excess errors)
FAIL: gcc.dg/cpp/strp1.c (test for excess errors)
FAIL: gcc.dg/cpp/strp2.c (test for excess errors)
FAIL: gcc.dg/struct-ret-libc.c (test for excess errors)

For example:

/work/builds/a9-may/install/bin/arm-none-eabi-gcc
/work/local-checkouts/gcc-fsf/gcc/testsuite/gcc.dg/cpp/19990407-1.c
-mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon -fno-diagnostics-show-caret
-pedantic-errors -o 19990407-1.exe
/work/builds/a9-may/install/arm-none-eabi/include/machine/_default_types.h:98:39:
error: use of C99 long long integer constant [-Wlong-long]


[Bug fortran/49954] ICE assigning concat expression to an array deferred-length string (realloc on assignment)

2012-05-24 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49954

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2012-05-24 
13:05:56 UTC ---
(In reply to comment #1)
> I thought about something like:
> +  tmp = rss->string_length;

That's nonsense as "rss" should be "rse" and "rse" is not available in that
function - just expr2.

> However, that yields ".array_length" (i.e. the LHS) even for
>   array_string(:)(1:1)

I think that problem is closely related to PR 51976: For deferred-length
components, using ts.u.cl->backend_decl directly is not possible; one needs to
have "var->component" and not "component".

Here, the issue is rather similar. I believe that one needs some conversion
function which makes string_length available by walking an expr. (It should
also work for the "length" part of parameterized DT.)


[Bug middle-end/53460] [4.7/4.8 Regression] Internal compiler error: in calc_dfs_tree, at dominance.c:395

2012-05-24 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Richard Guenther  2012-05-24 
12:50:30 UTC ---
Fixed.


[Bug middle-end/53460] [4.7/4.8 Regression] Internal compiler error: in calc_dfs_tree, at dominance.c:395

2012-05-24 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Richard Guenther  2012-05-24 
12:50:21 UTC ---
Author: rguenth
Date: Thu May 24 12:50:15 2012
New Revision: 187832

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187832
Log:
2012-05-24  Richard Guenther  

PR middle-end/53460
* tree-profile.c (tree_profiling): Cleanup the CFG if
execute_fixup_cfg requests it.

* g++.dg/tree-prof/pr53460.C: New testcase.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/tree-prof/pr53460.C
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-profile.c

--- Comment #11 from Richard Guenther  2012-05-24 
12:50:30 UTC ---
Fixed.


[Bug middle-end/53460] [4.7/4.8 Regression] Internal compiler error: in calc_dfs_tree, at dominance.c:395

2012-05-24 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460

--- Comment #10 from Richard Guenther  2012-05-24 
12:50:21 UTC ---
Author: rguenth
Date: Thu May 24 12:50:15 2012
New Revision: 187832

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187832
Log:
2012-05-24  Richard Guenther  

PR middle-end/53460
* tree-profile.c (tree_profiling): Cleanup the CFG if
execute_fixup_cfg requests it.

* g++.dg/tree-prof/pr53460.C: New testcase.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/tree-prof/pr53460.C
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-profile.c


[Bug middle-end/53460] [4.7/4.8 Regression] Internal compiler error: in calc_dfs_tree, at dominance.c:395

2012-05-24 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460

--- Comment #9 from Richard Guenther  2012-05-24 
12:46:57 UTC ---
Author: rguenth
Date: Thu May 24 12:46:53 2012
New Revision: 187831

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187831
Log:
2012-05-24  Richard Guenther  

PR middle-end/53460
* tree-profile.c (tree_profiling): Cleanup the CFG if
execute_fixup_cfg requests it.

* g++.dg/tree-prof/pr53460.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-prof/pr53460.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-profile.c


[Bug bootstrap/53466] [4.8 Regression] Bootstrap failure

2012-05-24 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53466

--- Comment #4 from Richard Guenther  2012-05-24 
12:36:47 UTC ---
Author: rguenth
Date: Thu May 24 12:36:40 2012
New Revision: 187830

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187830
Log:
2012-05-24  Richard Guenther  

PR bootstrap/53466
* g++.dg/debug/pr53466.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr53466.C
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug c++/24375] Wrong line number in diagnostic

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24375

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #2 from Paolo Carlini  2012-05-24 
12:32:32 UTC ---
Looking into it.


[Bug c++/51222] [C++11][SFINAE] Unevaluated combined delete new expression completely broken

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51222

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.8.0

--- Comment #4 from Paolo Carlini  2012-05-24 
12:16:54 UTC ---
I worked on this and a patch is essentially ready, AFAICS. But there are ABI
implications waiting to be resolved, if I understand correctly.


[Bug c++/42129] ICE in pointer difference with sizeof(int)>sizeof(void *)

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42129

--- Comment #4 from Paolo Carlini  2012-05-24 
12:04:17 UTC ---
Pinging Nathan, maybe we can do this for 4.8...


[Bug c++/39679] Some absent attributes in the tree-dump should be added

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39679

Paolo Carlini  changed:

   What|Removed |Added

 CC|susanin at ispras dot ru|g...@integrable-solutions.ne
   ||t

--- Comment #5 from Paolo Carlini  2012-05-24 
11:56:37 UTC ---
Hi Gaby. What do you think about this? I suppose, if we like the idea, we could
apply the patch even without a Copyright assignment, because it's so small, and
resolve the issue.


[Bug tree-optimization/53465] [4.7/4.8 Regression] wrong code with -O1 -ftree-vrp

2012-05-24 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[4.7 regression] wrong code |[4.7/4.8 Regression] wrong
   |with -O1 -ftree-vrp |code with -O1 -ftree-vrp

--- Comment #9 from Jakub Jelinek  2012-05-24 
11:54:30 UTC ---
Fixed.


[Bug tree-optimization/53465] [4.7/4.8 Regression] wrong code with -O1 -ftree-vrp

2012-05-24 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[4.7 regression] wrong code |[4.7/4.8 Regression] wrong
   |with -O1 -ftree-vrp |code with -O1 -ftree-vrp

--- Comment #8 from Jakub Jelinek  2012-05-24 
11:53:33 UTC ---
Author: jakub
Date: Thu May 24 11:53:29 2012
New Revision: 187828

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187828
Log:
PR tree-optimization/53465
* tree-vrp.c (extract_range_from_cond_expr): First copy_value_range
vr0 into *vr, then vrp_meet that.
(vrp_meet): If one vr type is VR_UNDEFINED, ensure the result doesn't
have any equivalences.
(vrp_visit_phi_node): Call copy_value_range instead of vrp_meet the
first time.

* gcc.c-torture/execute/pr53465.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr53465.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-vrp.c

--- Comment #9 from Jakub Jelinek  2012-05-24 
11:54:30 UTC ---
Fixed.


[Bug tree-optimization/53465] [4.7 regression] wrong code with -O1 -ftree-vrp

2012-05-24 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465

--- Comment #8 from Jakub Jelinek  2012-05-24 
11:53:33 UTC ---
Author: jakub
Date: Thu May 24 11:53:29 2012
New Revision: 187828

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187828
Log:
PR tree-optimization/53465
* tree-vrp.c (extract_range_from_cond_expr): First copy_value_range
vr0 into *vr, then vrp_meet that.
(vrp_meet): If one vr type is VR_UNDEFINED, ensure the result doesn't
have any equivalences.
(vrp_visit_phi_node): Call copy_value_range instead of vrp_meet the
first time.

* gcc.c-torture/execute/pr53465.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr53465.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-vrp.c


[Bug tree-optimization/53465] [4.7 regression] wrong code with -O1 -ftree-vrp

2012-05-24 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465

--- Comment #7 from Jakub Jelinek  2012-05-24 
11:51:15 UTC ---
Author: jakub
Date: Thu May 24 11:51:09 2012
New Revision: 187827

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187827
Log:
PR tree-optimization/53465
* tree-vrp.c (extract_range_from_cond_expr): First copy_value_range
vr0 into *vr, then vrp_meet that.
(vrp_meet): If one vr type is VR_UNDEFINED, ensure the result doesn't
have any equivalences.
(vrp_visit_phi_node): Call copy_value_range instead of vrp_meet the
first time.

* gcc.c-torture/execute/pr53465.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr53465.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


[Bug c++/53464] Invalid default value for non-type template parameter is accepted

2012-05-24 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53464

--- Comment #5 from Paolo Carlini  2012-05-24 
11:39:10 UTC ---
Later today I will add it.


[Bug c++/53464] Invalid default value for non-type template parameter is accepted

2012-05-24 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53464

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2012-05-24 
11:27:10 UTC ---
The testcase would be nice for the testsuite though.


[Bug middle-end/53460] [4.7/4.8 Regression] Internal compiler error: in calc_dfs_tree, at dominance.c:395

2012-05-24 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Guenther  2012-05-24 
11:00:53 UTC ---
Mine.


[Bug middle-end/53460] [4.7/4.8 Regression] Internal compiler error: in calc_dfs_tree, at dominance.c:395

2012-05-24 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460

--- Comment #7 from Richard Guenther  2012-05-24 
10:50:42 UTC ---
We have an unreachable block:

  # BLOCK 4
  # PRED:
:
  operator delete (D.2260_4);
  # SUCC: 5 [100.0%]  (fallthru)

after profiling.  Somehow we transform

void offsetToMiddleOfGlyph(const SimpleFontData*) (const struct SimpleFontData
* fontData)
{
  void * D.2260;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.2260_4 = operator new (1);
  GlyphMetricsMap::GlyphMetricsMap (D.2260_4);
  goto ;
  # SUCC: 4 [100.0%]  (fallthru,exec) 3 (eh,exec)

  # BLOCK 3
  # PRED: 2 (eh,exec)
:
  operator delete (D.2260_4);
  resx 1
  # SUCC:

to

void offsetToMiddleOfGlyph(const SimpleFontData*) (const struct SimpleFontData
* fontData)
{
  void * __gcov_indirect_call_callee.8;
  long int * __gcov_indirect_call_counters.7;
  long int PROF_edge_counter.6;
  void * D.2260;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  __gcov_indirect_call_counters.7_15 = __gcov_indirect_call_counters;
  __gcov_indirect_call_callee.8_16 = __gcov_indirect_call_callee;
  __gcov_indirect_call_profiler (__gcov_indirect_call_counters.7_15, 2,
offsetToMiddleOfGlyph, __gcov_indirect_call_callee.8_16);
  __gcov_indirect_call_callee = 0B;
  PROF_edge_counter.6_6 =
__gcov0._Z21offsetToMiddleOfGlyphPK14SimpleFontData[0];
  PROF_edge_counter.6_8 = PROF_edge_counter.6_6 + 1;
  __gcov0._Z21offsetToMiddleOfGlyphPK14SimpleFontData[0] =
PROF_edge_counter.6_8;
  D.2260_4 = operator new (1);
  # SUCC: 3 [100.0%]  (fallthru)

  # BLOCK 3 freq:1
  # PRED: 2 [100.0%]  (fallthru)
  PROF_edge_counter.6_9 =
__gcov0._Z21offsetToMiddleOfGlyphPK14SimpleFontData[1];
  PROF_edge_counter.6_10 = PROF_edge_counter.6_9 + 1;
  __gcov0._Z21offsetToMiddleOfGlyphPK14SimpleFontData[1] =
PROF_edge_counter.6_10;
  GlyphMetricsMap::GlyphMetricsMap (D.2260_4);
  goto ;
  # SUCC: 6 [100.0%]  (fallthru,exec)

  # BLOCK 4
  # PRED:
:
  operator delete (D.2260_4);
  # SUCC: 5 [100.0%]  (fallthru)



branch_prob () splits the block this way, invalidating EH edges.


[Bug c++/53464] Invalid default value for non-type template parameter is accepted

2012-05-24 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53464

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jonathan Wakely  2012-05-24 
10:48:58 UTC ---
Invalid then, thanks.


[Bug debug/53471] New: [4.8 LTO] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)

2012-05-24 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471

 Bug #: 53471
   Summary: [4.8 LTO] ICE in pp_base_format, at pretty-print.c:510
(-flto -g)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


Created attachment 27488
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27488
real-life code (preprocessed file)

bzip2 -d prettyBug.ii.bz2 
[vocms123] /build/vin/newb/CMSSW_6_0_X_2012-05-14-1400 $ c++ -c -O2 -std=c++11
-g prettyBug.ii
[vocms123] /build/vin/newb/CMSSW_6_0_X_2012-05-14-1400 $ c++ -c -O2 -std=c++11
-g prettyBug.ii -flto
'
In file included from
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/include/c++/4.8.0/map:61:0,
 from
/build/vin/newb/CMSSW_6_0_X_2012-05-14-1400/src/CondFormats/EcalCorrections/interface/EcalShowerContainmentCorrections.h:37,
 from
src/CondFormats/EcalCorrections/src/T_EventSetup_EcalShowerContainmentCorrections.cc:1:
in pp_base_format, at pretty-print.c:510
   equal_range(const key_type& __x) const
   ^


  1   2   >