[Bug target/59952] -march=core-avx2 should not enable RTM

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-27
 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
PTA_HLE is IMHO fine, after all we enable it also for -mtune=generic.  But I
agree that enabling PTA_RTM when less than 50% of current Haswell CPUs don't
include RTM is a bad idea.  Not even say i7-4770K includes it.

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[y.gribov at samsung dot com]

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

--- Comment #22 from Yury Gribov  ---
(In reply to Paul H. Hargrove from comment #21)
> Do I need to test other branches too?

No, I don't think so.

[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap

[kcc at gcc dot gnu.org]

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

--- Comment #23 from Kostya Serebryany  ---
Relevant Kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=67651

[Bug target/59952] New: -march=core-avx2 should not enable RTM

[thiago at kde dot org]

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

Bug ID: 59952
   Summary: -march=core-avx2 should not enable RTM
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org

The option -march=core-avx2 to gcc is documented to enable:

  Intel Core CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2,
  SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AES, PCLMUL,
  FSGSBASE, RDRND, FMA, BMI, BMI2 and F16C instruction set
  support.

However, it is enabling RTM (Restricted Transactional Memory) too:

 $ ~/gcc4.9/bin/g++-4.9 -march=core-avx2 -dM -E -xc /dev/null | grep RTM  
#define __RTM__ 1
$ ~/gcc4.9/bin/g++-4.9 --version
g++-4.9 (GCC) 4.9.0 20140125 (experimental)

Only certain Haswell processors have TSX in either form in the CPU. The mobile
parts don't:

$ sed -n '/name/p;/flags/p;/^$/q' /proc/cpuinfo
model name  : Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2
erms invpcid

According to the source code, HLE is enabled too when it shouldn't:
#define PTA_HASWELL \
  (PTA_IVYBRIDGE | PTA_AVX2 | PTA_BMI | PTA_BMI2 | PTA_LZCNT \
   | PTA_FMA | PTA_MOVBE | PTA_RTM | PTA_HLE)

[Bug plugins/59335] Plugin doesn't build on trunk

[pageexec at gmail dot com]

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

--- Comment #8 from PaX Team  ---
Uroš, i tried your patch and it didn't install those two files. on the other
hand i found more missing headers:

gcc/tree-phinodes.h
gcc/stor-layout.h
gcc/ssa-iterators.h

[Bug target/59679] gcc version 4.7.3 and gcc version 4.5.3 cause an unaligned access exception on NetBSD/Alpha

[mcree at orcon dot net.nz]

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

--- Comment #12 from Michael Cree  ---
Created attachment 31958
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31958&action=edit
Preprocessed version of scope-reduced.c

[Bug target/59679] gcc version 4.7.3 and gcc version 4.5.3 cause an unaligned access exception on NetBSD/Alpha

[mcree at orcon dot net.nz]

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

--- Comment #11 from Michael Cree  ---
Created attachment 31957
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31957&action=edit
Reduced version of scope.c illustrating problem.

[Bug target/59679] gcc version 4.7.3 and gcc version 4.5.3 cause an unaligned access exception on NetBSD/Alpha

[mcree at orcon dot net.nz]

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

Michael Cree  changed:

   What|Removed |Added

 CC||mcree at orcon dot net.nz

--- Comment #10 from Michael Cree  ---
This misaligned access in perl is also seen on Debian Alpha Linux. I have been
able to reduce the scope.c file substantially while maintaining the misaligned
access.  I will attach that as scope-reduced.c.

The misaligned access occurs in line 60, being the case SAVEt_I8 of the switch
statement, and with -O2 compiles to:

extbl $4,1,$4
$LVL18:
ldl $1,0($6)
bic $1,255,$1
bis $4,$1,$4
stl $4,0($6)

Thus there is an assumption that ARG0_PTR (which expands to arg0.any_ptr)
points to an address at least divisible by four.

If one compiles with -fno-tree-ter as mentioned in the initial bug report then
one gets:

sll $5,48,$5
$LVL18:
ldq_u $1,0($4)
sra $5,56,$5
mskbl $1,$4,$1
insbl $5,$4,$5
bis $5,$1,$5
stq_u $5,0($4)

which copes with any alignment.

If either of the cases SAVEt_SAVESWITCHSTACK or SAVEt_SET_SVFLAGS is removed
from the switch statement then the ldq_u/mskbl/insbl sequence results. Thus
there appears to be some interaction between those two cases and the code at
the top of the while statement that the compiler is using to determine that
ARG0_PTR points to an address at least divisible by four.  I admit that I have
so far failed to see how such an inference can be made but look forward to
being educated by the erudite gcc maintainers.

Compilation was done with:

cc -DPERL_CORE  -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -D_FORTIFY_SOURCE=2 -g -O2
-v -S scope-reduced.c
Using built-in specs.
COLLECT_GCC=cc
Target: alpha-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-13'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp
--disable-libmudflap --disable-libitm --disable-libsanitizer
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-alpha/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-alpha
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-alpha
--with-arch-directory=alpha --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-long-double-128
--enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu
--target=alpha-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-13) 
COLLECT_GCC_OPTIONS='-D' 'PERL_CORE' '-D' '_REENTRANT' '-D' '_GNU_SOURCE' '-D'
'DEBIAN' '-D' '_FORTIFY_SOURCE=2' '-g' '-O2' '-v' '-S'
 /usr/lib/gcc/alpha-linux-gnu/4.8/cc1 -quiet -v -imultilib . -imultiarch
alpha-linux-gnu -D PERL_CORE -D _REENTRANT -D _GNU_SOURCE -D DEBIAN -D
_FORTIFY_SOURCE=2 scope-reduced.c -quiet -dumpbase scope-reduced.c -auxbase
scope-reduced -g -O2 -version -o scope-reduced.s
GNU C (Debian 4.8.2-13) version 4.8.2 (alpha-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/alpha-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/alpha-linux-gnu/4.8/../../../../alpha-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/alpha-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/alpha-linux-gnu/4.8/include-fixed
 /usr/include/alpha-linux-gnu
 /usr/include
End of search list.
GNU C (Debian 4.8.2-13) version 4.8.2 (alpha-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 503630c10eca9d1ddabc1e36fce68a5f
COMPILER_PATH=/usr/lib/gcc/alpha-linux-gnu/4.8/:/usr/lib/gcc/alpha-linux-gnu/4.8/:/usr/lib/gcc/alpha-linux-gnu/:/usr/lib/gcc/alpha-linux-gnu/4.8/:/usr/lib/gcc/alpha-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/alpha-linux-gnu/4.8/:/usr/lib/gcc/alpha-linux-gnu/4.8/../../../alpha-linux-gnu/:/usr/lib/gcc/alpha-linux-gnu/4.8/../../../:/lib/alpha-linux-gnu/:/lib/:/usr/lib/alpha-linux-gnu/:/usr/lib/
COLLECT_GCC_OPTIONS='-D' 'PERL_CORE' '-D' '_REENTRANT' '-D' '_GNU_SOURCE' '-D'
'DEBIAN' '-D' '_FORTIFY_SOURCE=2' '-g' '-O2' '-v' '-S'

I will also attach preprocessed source.

[Bug libstdc++/51749] Including pollutes global namespace

[redi at gcc dot gnu.org]

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

--- Comment #30 from Jonathan Wakely  ---
Thanks, Joseph, I'll determine what changes we would need. I hope we can make
some progress just by being a bit smarter in libstdc++, and then only need
glibc changes for what's left after that.

[Bug c++/59950] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #1 from Richard Smith  ---
Additional clarification was requested: "Foo() = Foo()" means
"Foo().operator=(Foo())". The 'operator=' has return type 'Foo&', thus that
expression is not a temporary.

[Bug bootstrap/59951] New: bootstrap comparison failure with -O3 for a week

[dcb314 at hotmail dot com]

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

Bug ID: 59951
   Summary: bootstrap comparison failure with -O3 for a week
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

With revision 207121, dated today 20140126, I tried a bootstrap
build with BOOT_CFLAGS="-g -O3". 

It went wrong in the following way

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/bitmap.o differs
gcc/fortran/decl.o differs
gcc/bt-load.o differs
libiberty/pic/md5.o differs
libiberty/md5.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/dcb/gcc/working'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/dcb/gcc/working'
make: *** [bootstrap] Error 2

real75m53.471s
user142m19.580s
sys6m42.084s
Sun 26 Jan 21:02:51 GMT 2014

configure line is

../src/trunk/configure --prefix=/home/dcb/gcc/results --enable-checking=yes 
--enable-languages=c,c++,fortran --disable-werror

Machine type is x86_64.

This also went wrong last Wednesday, 20140122 and last Sunday 20140119

[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[rmansfield at qnx dot com]

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

--- Comment #18 from Ryan Mansfield  ---
(In reply to Jakub Jelinek from comment #17)
> Can I ask for preprocessed source + options again?

$ cat ~/conftest.c
void bar ();
void clean (int *);
void foo ()
{
  int i __attribute__ ((cleanup (clean)));
  bar();  
}

ryan@zoidberg:~/gnu/gcc/trunk/arm-eabi/gcc$ ./xgcc -B. -fexceptions
~/conftest.c 
/home/ryan/conftest.c: In function 'foo':
/home/ryan/conftest.c:7:1: internal compiler error: Segmentation fault
 }
 ^
0x95cbcf crash_signal
../../gcc/toplev.c:337
0xbef5a6 arm_unwind_emit_sequence
../../gcc/config/arm/arm.c:28729
0xbef5a6 arm_unwind_emit
../../gcc/config/arm/arm.c:28970
0x708ede final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../gcc/final.c:2978
0x709885 final(rtx_def*, _IO_FILE*, int)
../../gcc/final.c:2024
0x709ca9 rest_of_handle_final
../../gcc/final.c:4438
0x709ca9 execute
../../gcc/final.c:4513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Can I ask for preprocessed source + options again?

[Bug c/59946] -mpcrel -O2 produces illegal asm code

[mikpelinux at gmail dot com]

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

--- Comment #2 from Mikael Pettersson  ---
Reproduced with m68k-elf and m68k-linux toolchains built from binutils-2.23.2
and gcc-4.9-20140119, 4.8.2, and 4.7.3.  Removing "-m68000" causes the ".l"
suffix to disappear and gas to accept the generated code.

[Bug c++/59950] New: Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 59950
   Summary: Bogus diagnostic "taking address of temporary" taking
address of trivial no-op assignment to temporary
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk

GCC rejects this valid code:

 struct Foo {};
 int f(Foo *p);
 int n = f(&(Foo() = Foo()));

... saying ...

:3:27: error: taking address of temporary [-fpermissive]

The incorrect diagnostic only appears if 'Foo' is empty and its assignment
operator is defaulted. (Maybe the assignment is getting folded away before the
check is performed?)

Google ref b/12744615

[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #5 from Richard Smith  ---
Under [over.best.ics]p4, I think both the original example in comment#0 and the
example in comment#2 are valid (so GCC is incorrect to reject both and Clang is
incorrect to reject #2).

The user-defined conversion from {"abc", {"aaa"}} to Foo is not considered when
forming the implicit conversion sequence for the first parameter of Foo's copy
or move constructor, so neither of those is viable in either case. But see also
core issue 1758.

[Bug c/59946] -mpcrel -O2 produces illegal asm code

[vincent.riviere at freesbee dot fr]

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

Vincent Riviere  changed:

   What|Removed |Added

 CC||vincent.riviere at freesbee 
dot fr

--- Comment #1 from Vincent Riviere  ---
Confirmed with the following compilers:

m68k-atari-mint-gcc 4.7.1
m68k-atari-mint-gcc 4.6.4
m68k-elf-gcc 4.5.2

[Bug fortran/59414] [4.8/4.9 Regression] [OOP] ICE in in gfc_conv_expr_descriptor on ALLOCATE inside SELECT TYPE

[paul.richard.thomas at gmail dot com]

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

--- Comment #15 from paul.richard.thomas at gmail dot com  ---
I hadn't forgotten - I will be back in France tomorrow night and will deal
with it then.

Cheers

Paul
On Jan 26, 2014 3:31 PM, "mikael at gcc dot gnu.org" <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
>
> Mikael Morin  changed:
>
>What|Removed |Added
>
> 
>  CC||mikael at gcc dot gnu.org
>
> --- Comment #14 from Mikael Morin  ---
> patch at:
> http://gcc.gnu.org/ml/fortran/2014-01/msg00086.html
> approved at:
> http://gcc.gnu.org/ml/fortran/2014-01/msg00086.html
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
>

[Bug libstdc++/51749] Including pollutes global namespace

[joseph at codesourcery dot com]

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

--- Comment #29 from joseph at codesourcery dot com  ---
As was discussed a couple of years ago, the glibc maintainers are willing 
to work with the libstdc++ maintainers on providing whatever features 
libstdc++ headers need in a namespace-clean way (not exposing symbols not 
reserved by the relevant version of standard C++, when standard libstdc++ 
headers are used in a strict mode such as -std=c++98 or -std=c++11 and 
libstdc++ is built for recent-enough glibc).  But the libstdc++ people 
will need to work out exactly what interfaces are needed so we can work 
out how to expose them cleanly.

https://sourceware.org/ml/libc-alpha/2012-03/msg00311.html

(In the case of 64, providing __64 is a good idea for other 
reasons where not already provided: it would allow fixing 
, 
_FILE_OFFSET_BITS=64 not being namespace-clean.  So I consider such a 
change appropriate for, at least, any function in a POSIX or C standard 
with a 64 version used for _FILE_OFFSET_BITS=64.)

I advise taking discussion of the details to libc-alpha, once you have 
more idea of exactly what features you would like glibc headers to expose 
in a C++-namespace-clean way.

[Bug fortran/57048] [4.9 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid

[mikael at gcc dot gnu.org]

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

--- Comment #3 from Mikael Morin  ---
Created attachment 31956
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31956&action=edit
Bigger patch (doesn't work better :-/ )

And this is how far I got before giving up.

[Bug fortran/57048] [4.9 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin  ---
This fixes this case;
However, it is not free of regressions.

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index adc34dd..24ceaea 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2366,8 +2366,6 @@ gfc_get_derived_type (gfc_symbol * derived)
   else
derived->backend_decl = pfunc_type_node;

-  derived->ts.kind = gfc_index_integer_kind;
-  derived->ts.type = BT_INTEGER;
   /* Set the f90_type to BT_VOID as a way to recognize something of type
  BT_INTEGER that needs to fit a void * for the purpose of the
  iso_c_binding derived types.  */

[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[rmansfield at qnx dot com]

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

--- Comment #16 from Ryan Mansfield  ---
(In reply to Jakub Jelinek from comment #15)
> Created attachment 31943 [details]
> gcc49-pr59575.patch
> 
> Updated patch, which should now handle the dummy pushes also in
> arm_unwind_emit_sequence.  Untested as before, just it doesn't ICE on the
> source you've attached anymore.

Thanks for the patch, but this one ICEs configuring libgcc. e.g.

configure:4222: checking whether to use setjmp/longjmp exceptions
configure:: /home/ryan/gnu/gcc/trunk/arm-eabi/./gcc/xgcc
-B/home/ryan/gnu/gcc/trunk/arm-eabi/./gcc/
-B/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/bin/
-B/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/lib/
-isystem
/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/include
-isystem
/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-include
   -c --save-temps -fexceptions  conftest.c >&5

conftest.c: In function 'foo':
conftest.c:19:1: internal compiler error: Segmentation fault
 }
 ^
0x95cbcf crash_signal
../../gcc/toplev.c:337
0xbef5a6 arm_unwind_emit_sequence
../../gcc/config/arm/arm.c:28729
0xbef5a6 arm_unwind_emit
../../gcc/config/arm/arm.c:28970
0x708ede final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../gcc/final.c:2978
0x709885 final(rtx_def*, _IO_FILE*, int)
../../gcc/final.c:2024
0x709ca9 rest_of_handle_final
../../gcc/final.c:4438
0x709ca9 execute
../../gcc/final.c:4513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/57033] [4.7/4.8/4.9 Regression] ICE on extended derived type and default initialization

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin  ---
Simple fix:

--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2544,7 +2544,8 @@ gfc_convert_to_structure_constructor (gfc_expr *e,
gfc_symbol *sym, gfc_expr **c
   if (parent && !comp)
 break;

-  actual = actual->next;
+  if (actual)
+actual = actual->next;
 }

   if (!build_actual_constructor (&comp_head, &ctor_head, sym))


I was about to commit it, then I thought there was something wrong;
Is the following code valid?  It is currently rejected with:

comment_0_modif.f90:14.6:

meo = me(1, 2)  ! ICE
  1
Error: No initializer for component 'j' given in the structure constructor at
(1)!




program ice

type m
integer i
logical :: f = .false.
end type m

type, extends(m) :: me
integer :: j
end type me

type(me) meo

meo = me(1, 2)  ! ICE
end program ice

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from Mikael Morin  ---
Fixed for 4.7.4, 4.8.3 and 4.9.0.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #18 from Mikael Morin  ---
Author: mikael
Date: Sun Jan 26 14:49:47 2014
New Revision: 207119

URL: http://gcc.gnu.org/viewcvs?rev=207119&root=gcc&view=rev
Log:
fortran/
PR fortran/58007
* module.c (fp2, find_pointer2): Remove.
(mio_component_ref): Don't forcedfully set the containing derived type
symbol for loading.  Remove unused argument.
(mio_ref): Update caller
(skip_list): New argument nest_level.  Initialize level with the new
argument.
(read_module): Add forced pointer components association for derived
type symbols.

testsuite/
PR fortran/58007
* gfortran.dg/unresolved_fixup_1.f90: New test.
* gfortran.dg/unresolved_fixup_2.f90: New test.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_1.f90
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_2.f90
Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/module.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug fortran/59414] [4.8/4.9 Regression] [OOP] ICE in in gfc_conv_expr_descriptor on ALLOCATE inside SELECT TYPE

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #14 from Mikael Morin  ---
patch at:
http://gcc.gnu.org/ml/fortran/2014-01/msg00086.html
approved at:
http://gcc.gnu.org/ml/fortran/2014-01/msg00086.html

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #17 from Mikael Morin  ---
Author: mikael
Date: Sun Jan 26 14:12:50 2014
New Revision: 207118

URL: http://gcc.gnu.org/viewcvs?rev=207118&root=gcc&view=rev
Log:
fortran/
PR fortran/58007
* module.c (read_module): Assert for component name correctness.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c

[Bug c++/59949] lambda expression as default argument of function template causes "already defined" messages in assembler

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||assemble-failure
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-26
 Blocks||54367
Summary|default value to|lambda expression as
   |std::function template  |default argument of
   |function parameter causes   |function template causes
   |»already defined« messages  |"already defined" messages
   |in assembler|in assembler
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
The problem is unrelated to std::function:

struct A
{
  template A(T) { }
};

template
void
stuff(A = []{ }) {
}

int main() {
  stuff();
  stuff();
}

[Bug ipa/59948] Optimize std::function

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to Marc Glisse from comment #0)
>   if (f != 0B)
> // Shouldn't we know that f!=0? It is defined just above.

This happens because the test in fold-const.c is:
  return !VAR_OR_FUNCTION_DECL_P (base) || !DECL_WEAK (base);
and f is marked as weak. If I remove 'inline' or put 'static' then this code is
folded to true. However, I can't easily do the same for _M_manager. The
condition in fold-const.c probably needs to be weakened (no pun), as I strongly
doubt it is legal to replace an inline f with 0.

Note that cp/class.c contains this:
  /* ??? Probably should check DECL_WEAK here.  */
  if (t && DECL_P (t))
*nonnull = 1;

which we may want to keep in sync.

With f static, we get the shorter but still not so good:

int m() ()
{
  struct function h;
  int _21;

  :
  MEM[(int (*) (int) *)&h] = f;
  h._M_invoker = _M_invoke;
  h.D.26465._M_manager = _M_manager;
  if (_M_manager == 0B)
// Can't make it non-weak
goto ;
  else
goto ;

  :
  std::__throw_bad_function_call ();

  :
  _21 = f (1);
// Did we notice the function is really f too late for inlining?
  std::_Function_base::_Base_manager::_M_manager (&MEM[(struct
_Function_base *)&h]._M_functor, &MEM[(struct _Function_base *)&h]._M_functor,
3);
// Again, not inlined
  h ={v} {CLOBBER};
  h ={v} {CLOBBER};
//Maybe we could remove one of the clobbers somewhere along the way?
  return _21;

}

If I change fold-const.c (the condition is probably wrong, I just wanted to
move forward):
-  return !VAR_OR_FUNCTION_DECL_P (base) || !DECL_WEAK (base);
+  return !VAR_OR_FUNCTION_DECL_P (base) || !DECL_WEAK (base) ||
DECL_DECLARED_INLINE_P (base);

It removes the test _M_manager == 0, but it still inlines neither f nor
_M_manager.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #16 from Mikael Morin  ---
Author: mikael
Date: Sun Jan 26 13:04:54 2014
New Revision: 207117

URL: http://gcc.gnu.org/viewcvs?rev=207117&root=gcc&view=rev
Log:
fortran/
PR fortran/58007
* module.c
(fp2, find_pointer2): Remove.
(mio_component_ref): Don't forcedfully set the containing derived type
symbol for loading.  Remove unused argument.
(mio_ref): Update caller
(skip_list): New argument nest_level.  Initialize level with the new
argument.
(read_module): Add forced pointer components association for derived
type symbols.

testsuite/
PR fortran/58007
* gfortran.dg/unresolved_fixup_1.f90: New test.
* gfortran.dg/unresolved_fixup_2.f90: New test.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_1.f90
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_2.f90
Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/module.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c/59940] Imprecise column number for -Wconversion

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-26
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug c++/59949] default value to std::function template function parameter causes »already defined« messages in assembler

[moritz at bunkus dot org]

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

--- Comment #1 from Moritz Bunkus  ---
Created attachment 31955
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31955&action=edit
compiler output with g++ 4.8.2

[Bug c++/59949] New: default value to std::function template function parameter causes »already defined« messages in assembler

[moritz at bunkus dot org]

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

Bug ID: 59949
   Summary: default value to std::function template function
parameter causes »already defined« messages in
assembler
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz at bunkus dot org

Created attachment 31954
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31954&action=edit
sample file causing the bug

I have a template function that takes an std::function argument. This argument
has a default value, an in-place declared lambda function. As soon as I use
that template function more than once with different types within a compilation
unit I receive error messages from the assembler about symbols that are defined
already.

I've distilled it down to a code snippet I'm going to attach. In the original
code the lambda function was actually using the template parameter T and could
therefore not be converted to standalone function.

This fails with 4.8 and 4.8.2, but I remember it failing back as early as
4.6.3.

It works nicely with clang++ 3.3 and 3.4. With »works nicely« I mean that it
compiles cleanly, links, and the resulting code does what I want it to (in my
original source; this sample code obviously doesn't do anything at all).

The command line used:

g++ -std=c++11 -o cpp1 cpp1.cpp

[Bug ipa/59948] New: Optimize std::function

[glisse at gcc dot gnu.org]

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

Bug ID: 59948
   Summary: Optimize std::function
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org

#include 

inline int f(int i){return i-1;}
int m(){
  std::function h=f;
  return h(1);
}

clang manages to optimize this to just:
int m(){return 0;}

However, g++ is stuck with a much longer code (comments inline):

int m() ()
{
  void * D.29797;
  struct function h;
  bool (*) (union _Any_data &, const union _Any_data &,
_Manager_operation) _8;
  bool (*) (union _Any_data &, const union _Any_data &,
_Manager_operation) _9;
  int (*) (const union _Any_data &, int) _24;
  int _26;

  :
  MEM[(struct _Function_base *)&h]._M_manager = 0B;
  if (f != 0B)
// Shouldn't we know that f!=0? It is defined just above.
goto ;
  else
goto ;

  :
  MEM[(int (*) (int) *)&h] = f;
  h._M_invoker = _M_invoke;
  h.D.26519._M_manager = _M_manager;
  if (_M_manager == 0B)
// Same, shouldn't we know that _M_manager!=0?
goto ;
  else
goto ;

  :
  std::__throw_bad_function_call ();

  :
  _24 = h._M_invoker;
// Why not _M_invoke directly, we can only arrive here from bb3
// and nothing can clobber h._M_invoker. Then we might have a chance
// to inline the next line.
  _26 = _24 (&h.D.26519._M_functor, 1);

  :
  _8 = MEM[(struct _Function_base *)&h]._M_manager;
// I guess we need to fix the call to _24 above to know
// there is nothing clobbering h._M_manager.
  if (_8 != 0B)
goto ;
  else
goto ;

  :
  _8 (&MEM[(struct _Function_base *)&h]._M_functor, &MEM[(struct _Function_base
*)&h]._M_functor, 3);

  :
  h ={v} {CLOBBER};
  h ={v} {CLOBBER};
  return _26;

:
  _9 = MEM[(struct _Function_base *)&h]._M_manager;
  if (_9 != 0B)
goto ;
  else
goto ;

  :
  _9 (&MEM[(struct _Function_base *)&h]._M_functor, &MEM[(struct _Function_base
*)&h]._M_functor, 3);

  :
  h ={v} {CLOBBER};
  _10 = __builtin_eh_pointer (2);
  __builtin_unwind_resume (_10);

}

Trying to modify std::function by removing tests, compiling with
-fno-exceptions, etc, I got to situations with f(1) (not inlined), or we still
had an uninlined call to _M_manager (which, inlined, would reduce to nothing),
but never a clean return 0.

If this simple example gets fixed, please check on the example in
http://gcc.gnu.org/ml/gcc/2014-01/msg00261.html

Related issues:
PR 45631
PR 45632
PR 47413
(PR 56551)

[Bug libstdc++/51749] Including pollutes global namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-26
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #28 from Jonathan Wakely  ---
PR 11196 is another example of the same general issue.

In addition to the uselocale stuff mentioned in comment 21 ...

 uses ftello64, fseeko64, etc. If glibc provided
__ftello64 etc instead we could use them, but another option that works now is
to define only _LARGEFILE64_SOURCE, rather than everything implied by
_GNU_SOURCE.

-std=c++11 and -std=gnu++11 need to define _ISOC99_SOURCE, and libstdc++ should
have a replacement for _GLIBCXX_USE_C99 so that it isn't true for -std=c++98
(but would be for -std=gnu++98, since that would define _GNU_SOURCE which
includes the C99 library anyway).

gthr-posix.h needs some _XOPEN_SOURCE value.

 uses pid_t which needs a POSIX/XOPEN/BSD/GNU feature
macro (which would be OK except that at least one tests uses -std=c++11 when it
should probably use -std=gnu++11)

So *most* of what we need is provided by _ISOC99_SOURCE and _LARGEFILE64_SOURCE
and POSIX. It's probably acceptable (and certainly more correct) not to define
_GLIBCXX_USE_C99 with -std=c++98 and figure out the few C99 functions that we
absolutely must have even in strict c++98 mode and find workarounds for them.

I'll look at this after GCC 4.9 is released.