[Bug c/65679] Too strict alias analysis?

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65679

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #1 from Harald van Dijk  ---
There are two separate issues here: the assignment, and the comparison.

Assignment to *q (*(&x + 1)) is not allowed, that's still assignment past the
end of an object, even if there happens to be a valid object immediately
following it in memory. Two pointers comparing as equal does not make them
equivalent. There's no bug there.

The comparison p == q (&y == &x + 1) gets optimised to 0, and that part is
questionable: it may or may not technically be allowed here, but regardless,
this optimisation also causes valid code to get miscompiled. That's bug 61502.

[Bug target/65676] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f -funsigned-char and __builtin_ia32_pmovsxwq512_mask()

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65676

--- Comment #2 from Uroš Bizjak  ---
Looking at the definition of __mmask8 and __mmask16 in vx512fintrin.h:

typedef unsigned char  __mmask8;
typedef unsigned short __mmask16;

the masks should use:

DEF_PRIMITIVE_TYPE (UQI, unsigned_intQI_type_node)
DEF_PRIMITIVE_TYPE (UHI, unsigned_intHI_type_node)

[Bug c++/65681] New: [c++-concepts] spurious ambiguous template instantiation error; regression from r211824

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681

Bug ID: 65681
   Summary: [c++-concepts] spurious ambiguous template
instantiation error; regression from r211824
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net

The following test case demonstrates what I believe to be a spurious error in
resolving constrained class template partial specializations.  This appears to
be a regression introduced at some point.  The error occurs using a gcc r221861
based build.  I have an old gcc build (r211824) that compiles it successfully.

The test case is rather long.  It may be possible to reduce it a little bit
more, but it seems to be a little fragile as is.  For example, changing concept
C to specify a type requirement rather than a member function call requirement
suffices to avoid the error.  Additionally, swapping the requirements of CA1
with CB1 and the type alias targets of MA1 and MB1 (while retaining the
existing dependent type names) suffices to avoid the error.

The test case defines two parallel concept hierarchies, CA[1-3] and CB[1-3],
with accompanying models MA[1-3] and MB[1-3].  Class template S defines the
problematic constrained partial specializations.  The specializations are
intended to select alternate behavior when the type for T1 is less refined than
the type for T2, in a covariant sense.

$ cat t.cpp
template
concept bool C() {
return requires (T t) {
   { t.mf() }
   };
}

struct MC {
void mf();
};
static_assert(C(), "");

template
concept bool CA1() {
return C();
}
template
concept bool CA2() {
return CA1()
&& requires () {
   typename T::ca2_type;
   };
}
template
concept bool CA3() {
return CA2()
&& requires () {
   typename T::ca3_type;
   };
}

template
concept bool CB1() {
return requires () {
   typename T::cb1_type;
   };
}
template
concept bool CB2() {
return CB1()
&& requires () {
   typename T::cb2_type;
   };
}
template
concept bool CB3() {
return CB2()
&& requires () {
   typename T::cb3_type;
   };
}

struct MA1 {
using ca1_type = MC;
};
struct MA2 : MA1 {
using ca2_type = int;
};
struct MA3 : MA2 {
using ca3_type = int;
};
static_assert(CA1(), "");
static_assert(CA2(), "");
static_assert(CA3(), "");

struct MB1 {
using cb1_type = int;
};
struct MB2 : MB1 {
using cb2_type = int;
};
struct MB3 : MB2 {
using cb3_type = int;
};
static_assert(CB1(), "");
static_assert(CB2(), "");
static_assert(CB3(), "");

template
struct S;
template
struct S {   // Specialization #1
static constexpr int value = 1;
};
template
requires ! CA2()
struct S {   // Specialization #2
static constexpr int value = 2;
};
template
requires ! CA3()
struct S {   // Specialization #3
static constexpr int value = 3;
};

S s11;
S s12;
S s13;
S s21;
S s22;
S s23;
S s31;
S s32;
S s33;

static_assert(S::value == 1, "");
static_assert(S::value == 2, "");
static_assert(S::value == 2, "");
static_assert(S::value == 1, "");
static_assert(S::value == 1, "");
static_assert(S::value == 3, "");
static_assert(S::value == 1, "");
static_assert(S::value == 1, "");
static_assert(S::value == 1, "");

$ svn info   # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221861
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221857
Last Changed Date: 2015-04-03 12:47:32 -0400 (Fri, 03 Apr 2015)

# Using the gcc build above, an error is produced.
$ g++ -Wfatal-errors -c -std=c++1z t.cpp
t.cpp:101:12: error: ambiguous template instantiation for ‘struct S’
 S s23;
^
compilation terminated due to -Wfatal-errors.

# Using an old gcc r211824 based build, compilation is successful (note
# that this old build required -std=c++1y to enable support for concepts.
$ g++ -c -std=c++1y t.cpp
$ echo $?
0

[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi

[adconrad at 0c3 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670

Adam Conrad  changed:

   What|Removed |Added

 CC||adconrad at 0c3 dot net

--- Comment #9 from Adam Conrad  ---
Testing in an Ubuntu 15.04 chroot with the latest distro 4.9 and the latest 5.0
from Matthias's PPA, I see this:

(vivid-ppc64el)adconrad@kelsey01:~$ objdump -T
/usr/lib/powerpc64le-linux-gnu/libstdc++.so.6.0.20 | grep 17bad_function_call
0014f268  w   DO .data.rel.ro   0028  GLIBCXX_3.4.15
_ZTVSt17bad_function_call
000f7ff0 gDF .text  0050  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD0Ev
000f7f80 gDF .text  0020  GLIBCXX_3.4.18 0x60
_ZNKSt17bad_function_call4whatEv
000f7fa0 gDF .text  0044  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD1Ev
0014f250  w   DO .data.rel.ro   0018  GLIBCXX_3.4.15
_ZTISt17bad_function_call
000f7fa0 gDF .text  0044  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD2Ev
(vivid-ppc64el)adconrad@kelsey01:~$ objdump -T
whee/usr/lib/powerpc64le-linux-gnu/libstdc++.so.6.0.21 | grep
17bad_function_call
000e1e70 gDF .text  0050  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD0Ev
000e1e20 gDF .text  0044  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD2Ev
000e1e00 gDF .text  0020  GLIBCXX_3.4.18 0x60
_ZNKSt17bad_function_call4whatEv
001ea988  w   DO .data.rel.ro   0028  GLIBCXX_3.4.15
_ZTVSt17bad_function_call
001ea970  w   DO .data.rel.ro   0018  GLIBCXX_3.4.15
_ZTISt17bad_function_call
000e1e20 gDF .text  0044  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD1Ev

In other words, it all looks fine to me, so I'm not entirely sure where he's
seeing the regression.

[Bug target/65614] [5 Regression] PowerPC VSX systems should use XSCPSGNDP to copy scalar fp data to/from Altivec registers

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65614

--- Comment #6 from Michael Meissner  ---
Author: meissner
Date: Tue Apr  7 03:36:05 2015
New Revision: 221888

URL: https://gcc.gnu.org/viewcvs?rev=221888&root=gcc&view=rev
Log:
[gcc]
2015-04-06  Michael Meissner  

PR target/65614
* config/rs6000/rs6000.c (struct processor_costs): Add cost field
for SF->DF conversions to make FLOAT_EXTEND more expensive, so
that LFD is used to load double constants instead of LFS.  Add
defaults for all costs structures.  Add comments for missing
initialization fields.
(size32_cost): Likewise.
(size64_cost): Likewise.
(rs64a_cost): Likewise.
(mpccore_cost): Likewise.
(ppc403_cost): Likewise.
(ppc405_cost): Likewise.
(ppc440_cost): Likewise.
(ppc476_cost): Likewise.
(ppc601_cost): Likewise.
(ppc603_cost): Likewise.
(ppc604_cost): Likewise.
(ppc604e_cost): Likewise.
(ppc620_cost): Likewise.
(ppc630_cost): Likewise.
(ppccell_cost): Likewise.
(ppc750_cost): Likewise.
(ppc7450_cost): Likewise.
(ppc8540_cost): Likewise.
(ppce300c2c3_cost): Likewise.
(ppce500mc_cost): Likewise.
(ppce500mc64_cost): Likewise.
(ppce5500_cost): Likewise.
(ppce6500_cost): Likewise.
(titan_cost): Likewise.
(power4_cost): Likewise.
(power6_cost): Likewise.
(power7_cost): Likewise.
(power8_cost): Likewise.
(ppca2_cost): Likewise.
(rs6000_rtx_costs): Make FLOAT_EXTEND use SFDF_convert field.

* config/rs6000/rs6000.md (extendsfdf2_fpr): Generate XSCPSGNDP
instead of XXLOR to copy SFmode to clear out dirty bits created
when SFmode denormals are generated.
(mov_hardfloat, FMOVE32 case): Likewise.
(truncdfsf2_fpr): Add support for ISA 2.07 XSRSP instruction.

[gcc/testsuite]
2015-04-06  Michael Meissner  

PR target/65614
* gcc.target/powerpc/compress-float-ppc-pic.c: Run test on power5
to get floating point compression.
* gcc.target/powerpc/compress-foat-ppc.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/compress-float-ppc-pic.c
trunk/gcc/testsuite/gcc.target/powerpc/compress-float-ppc.c

[Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org

--- Comment #7 from amker at gcc dot gnu.org ---
I saw similar cases on arm.  If it's fine I would like to revisit this in the
coming stage1.

[Bug middle-end/65680] New: ICE at -O1 and above on x86_64-linux-gnu in expand_assignment, at expr.c:4830

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65680

Bug ID: 65680
   Summary: ICE at -O1 and above on x86_64-linux-gnu in
expand_assignment, at expr.c:4830
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux-gnu in the 64-bit mode (but not in the 32-bit
mode). 

It also affects 4.9.2 and 4.8.4. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150406 (experimental) [trunk revision 221876] (GCC) 
$ 
$ gcc-trunk -O0 -c small.c
$   
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn1’:
small.c:9:28: internal compiler error: in expand_assignment, at expr.c:4830
   a[10][0] = b;
^
0x81f0c5 expand_assignment(tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/expr.c:4830
0x71fbb7 expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:3401
0x71fbb7 expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:3497
0x7248e6 expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:5509
0x727607 execute
../../gcc-trunk/gcc/cfgexpand.c:6127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


struct S0 
{
  int f0:1;
} a[11][3];

void fn1() 
{
  struct S0 b = { 0 };
  a[10][0] = b;
}

[Bug libstdc++/65675] make bootstrap fails when configured with --disable-hosted-libstdcxx

[ian at ianshome dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65675

Ian Collins  changed:

   What|Removed |Added

   Severity|blocker |normal

--- Comment #2 from Ian Collins  ---
Specifying --disable-bootstrap as a configure option allows make
all-target-libstdc++-v3 to complete, given an existing compiler install.

[Bug libstdc++/65675] make bootstrap fails when configured with --disable-hosted-libstdcxx

[ian at ianshome dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65675

--- Comment #1 from Ian Collins  ---
The same error occurs building the 4.9 branch.

[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670

--- Comment #8 from Bill Schmidt  ---
I do plan to add the baseline_symbols.txt file for powerpc64le-linux-gnu in a
patch shortly.  I thought this had been done, but it seems to have fallen
through the cracks.

[Bug fortran/59016] f951: internal compiler error: Segmentation fault

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016

--- Comment #24 from Dominique d'Humieres  ---
Created attachment 35240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35240&action=edit
Cleaned patch

I have cleaned the patch along the Mikael's comment and fixed the test case.

[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression

[skunk at iskunk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644

Daniel Richard G.  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #7 from Daniel Richard G.  ---
Reopening due to lack of resolution.

If system patches should resolve the issue, then I am open to trying any that
are appropriate; if they work, then they can be noted in the documentation. But
it is also possible that this is a limitation of this particular version of
Solaris that cannot be patched, and thus will need a workaround in GCC.

[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[rai...@emrich-ebersheim.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #7 from Rainer Emrich  ---
Created attachment 35239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35239&action=edit
reproducer with temporaries and verbose gcc output

[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #6 from Jan Hubicka  ---
Can you please compile with --verbose --save-temps and attach the output +
temporary files produced?
(in particular I wonder about resolution file that should be named *.res)

[Bug debug/65678] [5 Regression] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:909

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65678

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r215450.

Re: [Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[Jan Hubicka]

Can you please compile with --verbose --save-temps and attach the output + 
temporary files produced?
(in particular I wonder about resolution file that should be named *.res)

[Bug debug/65678] [5 Regression] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:909

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65678

Uroš Bizjak  changed:

   What|Removed |Added

  Component|c++ |debug
   Target Milestone|--- |5.0
Summary|internal compiler error: in |[5 Regression] internal
   |gen_rtx_SUBREG, at  |compiler error: in
   |emit-rtl.c:909  |gen_rtx_SUBREG, at
   ||emit-rtl.c:909

[Bug c++/65678] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:909

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65678

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-06
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Confirmed:

$ /ssd/uros/gcc-build/gcc/cc1plus -Os -ggdb -quiet pr65678.C
pr65678.C: In function ‘void FastFixedDtoa(double)’:
pr65678.C:28:1: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:909
 }
 ^
0x9936fb gen_rtx_SUBREG(machine_mode, rtx_def*, int)
/home/uros/gcc-svn/trunk/gcc/emit-rtl.c:909
0xf2bc16 dead_debug_insert_temp(dead_debug_local*, unsigned int, rtx_insn*,
debug_temp_where)
/home/uros/gcc-svn/trunk/gcc/valtrack.c:743
0x93079d df_note_bb_compute
/home/uros/gcc-svn/trunk/gcc/df-problems.c:3179
0x93079d df_note_compute
/home/uros/gcc-svn/trunk/gcc/df-problems.c:3286
0x92b730 df_analyze_problem(dataflow*, bitmap_head*, int*, int)
/home/uros/gcc-svn/trunk/gcc/df-core.c:1205
0x92b828 df_analyze_1
/home/uros/gcc-svn/trunk/gcc/df-core.c:1265
0x1244c91 rest_of_handle_dse
/home/uros/gcc-svn/trunk/gcc/dse.c:3736
0x1244c91 execute
/home/uros/gcc-svn/trunk/gcc/dse.c:3837
Please submit a full bug report,

[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670

--- Comment #7 from Bill Schmidt  ---
Like Andreas, this works for me with latest 4.9 and trunk.  I see the 3.4.15
symbols in both cases.

[Bug target/65676] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f -funsigned-char and __builtin_ia32_pmovsxwq512_mask()

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65676

--- Comment #1 from Uroš Bizjak  ---
This looks like a consequence of following i386-builtin-types.c comment:

# ??? Logically this should be intQI_type_node, but that maps to "signed char"
# which is a different type than "char" even if "char" is signed.  This must
# match the usage in emmintrin.h and changing this would change name mangling
# and so is not advisable.
DEF_PRIMITIVE_TYPE (QI, char_type_node)

[Bug target/65582] [5 Regression] testsuite lto issue: xgcc.exe: warning: '-x lto' after last input file has no effect, fatal error: no input files

[rai...@emrich-ebersheim.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65582

--- Comment #6 from Rainer Emrich  ---
Created attachment 35238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35238&action=edit
compile temporaries and compile log.

$ gcc -v
/opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/testsuite/gcc.c-torture/execute/2403-1.c
-flto -w -lm --save-temps -o ./2403-1.exe
Using built-in specs.
COLLECT_GCC=D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/../libexec/gcc/x86_64-w64-mingw32/5.0.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/configure
--prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0
--with-gnu-as
--with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/as
--with-gnu-ld
--with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/ld
--build=x86_64-w64-mingw32 --enable-threads=posix
--enable-languages=c,c++,fortran,java,lto,objc,obj-c++
--with-gmp-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-gmp-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-mpfr-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-mpfr-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-mpc-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-mpc-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-isl-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-isl-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0
--enable-libgomp --enable-fully-dynamic-string --disable-multilib
--enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk
Thread model: posix
gcc version 5.0.0 20150403 (experimental) [trunk revision 221852] (GCC)
COLLECT_GCC_OPTIONS='-v' '-flto' '-w' '-save-temps' '-o' './2403-1.exe'
'-mtune=generic' '-march=x86-64'

d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/../libexec/gcc/x86_64-w64-mingw32/5.0.0/cc1.exe
-E -quiet -v -iprefix
d:\opt\devel\gnu\gcc\mingw_nt\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\../lib/gcc/x86_64-w64-mingw32/5.0.0/
-D_REENTRANT
D:/opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/testsuite/gcc.c-torture/execute/2403-1.c
-mtune=generic -march=x86-64 -w -flto -fpch-preprocess -o 2403-1.i
ignoring nonexistent directory
"d:\opt\devel\gnu\gcc\mingw_nt\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\../lib/gcc/x86_64-w64-mingw32/5.0.0/../../../../x86_64-w64-mingw32/include"
ignoring duplicate directory
"D:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.0.0/include"
ignoring nonexistent directory
"D:/x86_64-w64-trunkD:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/lib/gcc/x86_64-w64-mingw32/5.0.0/../../../../include"
ignoring duplicate directory
"D:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.0.0/include-fixed"
ignoring nonexistent directory
"D:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.0.0/../../../../x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:

d:\opt\devel\gnu\gcc\mingw_nt\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\../lib/gcc/x86_64-w64-mingw32/5.0.0/include

d:\opt\devel\gnu\gcc\mingw_nt\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\../lib/gcc/x86_64-w64-mingw32/5.0.0/include-fixed
 D:/x86_64-w64-trunk/mingw/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-flto' '-w' '-save-temps' '-o' './2403-1.exe'
'-mtune=generic' '-march=x86-64'

d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/../libexec/gcc/x86_64-w64-mingw32/5.0.0/cc1.exe
-fpreprocessed 2403-1.i -quiet -dumpbase 2403-1.c -mtune=generic
-march=x86-64 -auxbase 2403-1 -w -version -flto -o 2403-1.s
GNU C11 (GCC) version 5.0.0 20150403 (experimental) [trunk revision 221852]
(x86_64-w64-mingw32)
compiled by GNU C version 5.0.0 20150403 (experimental) [trunk revision
221852], GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.0.0 20150403 (experimental) [trunk revision 221852]
(x86_64-w64-mingw32)
compiled by GNU C version 5.0.0 20150403 (experimental) [trunk revision
221852], GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Dominique d'Humieres  ---
> So if this PR is not a duplicate of pr59016, both bugs seem related to
> p->sym->name being in an unpredictable state.

Both PRs are fixed by the same patch and this PR is almost identical to the one
in pr59016 comment 1.

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

[Bug fortran/59016] f951: internal compiler error: Segmentation fault

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016

--- Comment #23 from Dominique d'Humieres  ---
*** Bug 65469 has been marked as a duplicate of this bug. ***

[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'

[rai...@emrich-ebersheim.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581

--- Comment #16 from Rainer Emrich  ---
Indeed this seems to be a linker bug in ld on binutils head.
Doesn't reproduce with binutils 2.25.

[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[rai...@emrich-ebersheim.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #5 from Rainer Emrich  ---
Created attachment 35237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35237&action=edit
reproducer with temporaries

$ gcc fprintf.c fprintf-lib.c main.c -fno-diagnostics-show-caret
-fdiagnostics-color=never -w -O2 -flto -flto-partition=none
-fno-tree-loop-distribute-patterns --save-temps -Wl,--allow-multiple-definition
-lm -o fprintf.x7
lto1.exe: internal compiler error: in read_cgraph_and_symbols, at
lto/lto.c:2960
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper.exe: fatal error:
D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\gcc.exe
returned 1 exit status
compilation terminated.
d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/../lib/gcc/x86_64-w64-mingw32/5.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

$ gcc -v
Using built-in specs.
COLLECT_GCC=D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/../libexec/gcc/x86_64-w64-mingw32/5.0.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/configure
--prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0
--with-gnu-as
--with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/as
--with-gnu-ld
--with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/bin/ld
--build=x86_64-w64-mingw32 --enable-threads=posix
--enable-languages=c,c++,fortran,java,lto,objc,obj-c++
--with-gmp-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-gmp-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-mpfr-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-mpfr-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-mpc-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-mpc-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-isl-include=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/include
--with-isl-lib=/opt/devel/SCRATCH/tmp.ZMSUJS8SO8/install/lib64
--with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0
--enable-libgomp --enable-fully-dynamic-string --disable-multilib
--enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk
Thread model: posix
gcc version 5.0.0 20150403 (experimental) [trunk revision 221852] (GCC)

[Bug c/65679] New: Too strict alias analysis?

[gcc at robbertkrebbers dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65679

Bug ID: 65679
   Summary: Too strict alias analysis?
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at robbertkrebbers dot nl

Consider the following example:

  #include
  #include

  int main() {
int x = 1, y = 2, *p = &y, *q = &x + 1;
if ((intptr_t)p == (intptr_t)q) {
  *q = 10;
  printf("%d %d %d\n", x, y, p == q);
}
  }

When compiled with "gcc -pedantic -std=c99 -O2" (and even with
-fno-strict-aliasing added), the compiled program prints:

  1 2 0

So, despite the fact that is has been "observed" that p and q have identical
representations, they are still not being treated as equal.

Is this intended?

[Bug fortran/61669] Error recovery ICE

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61669

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Error-recovery fixes aren't generally backported.

[Bug c++/65678] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:909

[nheghathivhistha at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65678

--- Comment #1 from David Kredba  ---
C-reduced test case:

extern "C" void *memmove(void *, const void *, unsigned long);
long a;
template  int BitCast(Source &p1) {
  memmove(&a, &p1, sizeof a);
  return a;
}

static int double_to_uint64(double p1) { return BitCast(p1); }

class A {
public:
  A(double p1) : d64_(double_to_uint64(p1)) {}
  int m_fn1();
  int m_fn2() {
int b;
b = d64_;
if (b)
  return 0;
  }
  int d64_;
};

void FillFractionals();
void FastFixedDtoa(double p1) {
  int c = A(p1).m_fn2(), d = A(p1).m_fn1();
  if (d)
FillFractionals();
}

[Bug c++/65678] New: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:909

[nheghathivhistha at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65678

Bug ID: 65678
   Summary: internal compiler error: in gen_rtx_SUBREG, at
emit-rtl.c:909
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nheghathivhistha at gmail dot com

Created attachment 35236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35236&action=edit
Preprocessed source file

I can't compile debug enabled Gentoo Mozilla Firefox 37.0.1 package with
Gcc-5.0 trunk revision 221871:

srv5 mfbt # x86_64-pc-linux-gnu-g++ -o Unified_cpp_mfbt0.o -c 
-I../dist/system_wrappers -include
/var/tmp/portage/www-client/firefox-37.0.1/work/mozilla-release/config/gcc_hidden.h
-DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DAB_CD=en-US -DNO_NSPR_10_SUPPORT
-I/var/tmp/portage/www-client/firefox-37.0.1/work/mozilla-release/mfbt -I. 
-I../dist/include   -I/usr/include/nspr -I/usr/include/nss   
-I/usr/include/pixman-1-fPIC   -DMOZILLA_CLIENT -include
../mozilla-config.h -MD -MP -MF .deps/Unified_cpp_mfbt0.o.pp  -Wall
-Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings
-Wno-invalid-offsetof -Wcast-align -ggdb -pipe -march=core2 -mtune=core2
-mno-avx -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions
-fno-math-errno -std=gnu++0x -pthread -pipe  -DDEBUG -DTRACING -g
-freorder-blocks -Os  -fno-omit-frame-pointer 
/var/tmp/portage/www-client/firefox-37.0.1/work/mozilla-release/ff/mfbt/Unified_cpp_mfbt0.cpp
--save-temps
x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
In file included from
/var/tmp/portage/www-client/firefox-37.0.1/work/mozilla-release/ff/mfbt/Unified_cpp_mfbt0.cpp:110:0:
/var/tmp/portage/www-client/firefox-37.0.1/work/mozilla-release/mfbt/double-conversion/fixed-dtoa.cc:
In function ‘bool double_conversion::FastFixedDtoa(double, int,
double_conversion::Vector, int*, int*)’:
/var/tmp/portage/www-client/firefox-37.0.1/work/mozilla-release/mfbt/double-conversion/fixed-dtoa.cc:400:1:
internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:909
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.0.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-5.0.0/work/gcc-5.0.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.0.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.0.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.0.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.0.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.0.0/python
--enable-languages=c,c++,fortran,ada --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.0.0' --enable-libstdcxx-time --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-altivec
--disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libcilkrts --enable-lto
--with-isl --disable-isl-version-check --enable-libsanitizer
Thread model: posix
gcc version 5.0.0 20150405 (experimental) [trunk revision 221871] (Gentoo
5.0.0)

Attaching ii file now and will try to reduce it.

[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647

--- Comment #9 from Jeffrey A. Law  ---
Either soft or softfp will trigger the failure.  Given that it's just a compile
test, rather than  link & run test, can we just add a -mfloat-abi=soft to the
test and avoid the dg-skip-if?

[Bug target/65614] [5 Regression] PowerPC VSX systems should use XSCPSGNDP to copy scalar fp data to/from Altivec registers

[meissner at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65614

--- Comment #5 from Michael Meissner  ---
On Fri, Apr 03, 2015 at 07:19:24PM +, dje at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65614
> 
> --- Comment #4 from David Edelsohn  ---
> Comment on attachment 35227
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35227
> Proposed patch to fix the problem
> 
> The FLOAT_EXTEND cost should be based on the processor tuning, not the ISA.

This patch moves the decision to the cost structure based on the processor
tuning.  Is it ok to install?

[gcc]
2015-04-06  Michael Meissner  

PR target/65614
* config/rs6000/rs6000.c (struct processor_costs): Add cost field
for SF->DF conversions to make FLOAT_EXTEND more expensive, so
that LFD is used to load double constants instead of LFS.  Add
defaults for all costs structures.  Add comments for missing
initialization fields.
(size32_cost): Likewise.
(size64_cost): Likewise.
(rs64a_cost): Likewise.
(mpccore_cost): Likewise.
(ppc403_cost): Likewise.
(ppc405_cost): Likewise.
(ppc440_cost): Likewise.
(ppc476_cost): Likewise.
(ppc601_cost): Likewise.
(ppc603_cost): Likewise.
(ppc604_cost): Likewise.
(ppc604e_cost): Likewise.
(ppc620_cost): Likewise.
(ppc630_cost): Likewise.
(ppccell_cost): Likewise.
(ppc750_cost): Likewise.
(ppc7450_cost): Likewise.
(ppc8540_cost): Likewise.
(ppce300c2c3_cost): Likewise.
(ppce500mc_cost): Likewise.
(ppce500mc64_cost): Likewise.
(ppce5500_cost): Likewise.
(ppce6500_cost): Likewise.
(titan_cost): Likewise.
(power4_cost): Likewise.
(power6_cost): Likewise.
(power7_cost): Likewise.
(power8_cost): Likewise.
(ppca2_cost): Likewise.
(rs6000_rtx_costs): Make FLOAT_EXTEND use SFDF_convert field.

* config/rs6000/rs6000.md (extendsfdf2_fpr): Generate XSCPSGNDP
instead of XXLOR to copy SFmode to clear out dirty bits created
when SFmode denormals are generated.
(mov_hardfloat, FMOVE32 case): Likewise.
(truncdfsf2_fpr): Add support for ISA 2.07 XSRSP instruction.

[gcc/testsuite]
2015-04-06  Michael Meissner  

PR target/65614
* gcc.target/powerpc/compress-float-ppc-pic.c: Run test on power5
to get floating point compression.
* gcc.target/powerpc/compress-foat-ppc.c: Likewise.

[Bug fortran/61669] Error recovery ICE

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61669

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code

--- Comment #5 from Dominique d'Humieres  ---
AFAICT this PR is fixed on trunk. Is there any plan to back port the fix? If
no, this PR can be closed as FIXED, isn't it?

[Bug preprocessor/61977] [4.8/4.9/5 Regression] powerpc preprocessor breaks on lines that end with "vector"

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61977

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
Fixed.

[Bug preprocessor/61977] [4.8/4.9/5 Regression] powerpc preprocessor breaks on lines that end with "vector"

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61977

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr  6 17:01:50 2015
New Revision: 221882

URL: https://gcc.gnu.org/viewcvs?rev=221882&root=gcc&view=rev
Log:
PR preprocessor/61977
* lex.c (cpp_peek_token): If peektok is CPP_EOF, back it up
with all tokens peeked by the current function.

* gcc.dg/cpp/pr61977.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/pr61977.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)

[fweimer at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726

--- Comment #12 from Florian Weimer  ---
(In reply to Chip Salzenberg from comment #11)
> Indeed, 16 is required by the ABI; see
> http://www.x86-64.org/documentation/abi.pdf page 12.  Only the SIMD __m256
> is bigger than 16, and there seems no end to Intel's extensions to SIMD
> registers, so holding at 16 seems like the Right Thing.

Even for allocations smaller than 16 bytes?

[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #8 from James Greenhalgh  ---
The new testcase fails for ARM targets configured with --with-float-abi=hard .

  .../gcc/testsuite/gcc.target/arm/pr65647.c:26:8: sorry, unimplemented:
Thumb-1 hard-float VFP ABI

The fix would be to add an explicit -mfloat-abi= option to the testcase, but I
can't guess from the bug report whether that should be soft or softfp. Could
somebody please confirm which it should be and patch the testcase on both
branches?

[Bug driver/65639] -nostdlib/-nodefaultlibs should not affect ASan runtime

[earthdok at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65639

--- Comment #2 from Sergey Matveev  ---
This is also discussed in the email thread following the clang commit:
https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg106622.html

You could say that by passing -fsanitize=address at link time, we explicitly
tell clang to link in the sanitizer runtime. So -nodefaultlibs shouldn't negate
-fsanitize=address much as it wouldn't negate -lc. I think this was the logic
behind the final decision.

While -l:libasan.a helps, it must be applied to non-shared objects only, which
is more awkward than just adding -fsanitize=address.

[Bug fortran/65677] New: Incomplete assignment on deferred-length character variable

[jwmwalrus at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677

Bug ID: 65677
   Summary: Incomplete assignment on deferred-length character
variable
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwmwalrus at gmail dot com

The code below fails to produce the expected results.


module mod1
implicit none
contains
subroutine getKeyword(string, keyword, rest)
character(:), allocatable, intent(IN) :: string
character(:), allocatable, intent(OUT) :: keyword, rest
integer :: idx
character(:), allocatable :: text

keyword = ''
rest = ''
text = string
text = ADJUSTL(text(2:))!***
idx = INDEX(text, ' ')

if (idx == 0) then
keyword = TRIM(text)
else
keyword = text(:idx-1)
rest = TRIM(ADJUSTL(text(idx+1:)))
endif
end subroutine
end module mod1

use mod1
implicit none

character(:), allocatable :: line, keyword, rest

line = '@HEREIT IS'

call getKeyword(line, keyword, rest)

print *, 'line: ', line
print *, 'keyword: ', keyword
print *, 'rest: ', rest
end


It seems that whenever a deferred-length character variable that's being
assigned something is also a substring in the right-hand side expression,
assignment is wrong/incomplete. The offending line is marked with "!***" in the
code. This is the output I get:


~$ ll `which gfortran-5.0`
lrwxrwxrwx 1 root staff 35 Feb 26 11:01 /usr/local/bin/gfortran-5.0 ->
../../lib/gcc-snapshot/bin/gfortran*
~$ gfortran-5.0 test_deferred.f90 
~$ ./a.out 
 line: @HEREIT IS
 keyword: HERE
 rest: IT I


So far I've noticed the error occurs only when the substring does not coincide
with the beginning of the string. I get the same error with gfortran 4.9.

The system and compiler information is:

$ lsb_release -rd && gfortran-5.0 -v
Description:Debian GNU/Linux 8.0 (jessie)
Release:8.0
Using built-in specs.
COLLECT_GCC=gfortran-5.0
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20150404-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--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-5-snap-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--disable-werror --enable-checking=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.0.0 20150404 (experimental) [trunk revision 221867] (Debian
20150404-1)

[Bug fortran/65541] [5 Regression] namelist regression

[jwmwalrus at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541

--- Comment #11 from John  ---
Yes, -static does the trick when it comes to the namelist ---although, in the
actual program, I get an obscure error when I try to invoke C's execv/waitpid.

Thanks a lot for the help provided, and sorry for the inconvenience.

[Bug driver/65639] -nostdlib/-nodefaultlibs should not affect ASan runtime

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65639

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
IMNSHO the GCC behavior is desirable.  If you use these flags, you should take
care of linking all the needed runtimes, making a weird exception just for one
runtime is IMHO very much undesirable.
-nostdlib isn't just about libc, but about libgcc, libstdc++ etc., you name it.

[Bug c++/39934] Union member incorrectly disallowed

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #13 from Jason Merrill  ---
Agreed.  Fixed with -std=c++0x in GCC 4.6.

[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670

--- Comment #6 from Matthias Klose  ---
both seen with 2.25 release, and powerpc64le with 2.25 branch.

[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi

[mkuvyrkov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670

--- Comment #5 from Maxim Kuvyrkov  ---
Mattias, Andreas,

What binutils versions are you using?  I'm starting to think this can be a
linker optimization or linker bug.

[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670

--- Comment #4 from Andreas Schwab  ---
Worksforme.

$ objdump -T usr/lib64/libstdc++.so.6.0.21 | grep bad_function_callD
000e7a90 gDF .text  0050  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD0Ev
000e7a40 gDF .text  0044  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD2Ev
000e7a40 gDF .text  0044  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD1Ev
$ objdump -T usr/lib64/libstdc++.so.6.0.20 | grep 17bad_function_callD
000fce10 gDF .text  0050  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD0Ev
000fcdc0 gDF .text  0044  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD1Ev
000fcdc0 gDF .text  0044  GLIBCXX_3.4.15 0x60
_ZNSt17bad_function_callD2Ev

[Bug target/65676] New: ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f -funsigned-char and __builtin_ia32_pmovsxwq512_mask()

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65676

Bug ID: 65676
   Summary: ICE: in extract_insn, at recog.c:2343 (unrecognizable
insn) with -mavx512f -funsigned-char and
__builtin_ia32_pmovsxwq512_mask()
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 35235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35235&action=edit
reduced testcase

Compiler output:
$ gcc testcase.c -mavx512f -funsigned-char
testcase.c: In function 'foo':
testcase.c:7:1: error: unrecognizable insn:
 }
 ^
(insn 8 7 9 2 (set (reg:QI 90)
(const_int 255 [0xff])) testcase.c:6 -1
 (nil))
testcase.c:7:1: internal compiler error: in extract_insn, at recog.c:2343
0xbd2e38 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/mnt/svn/gcc-trunk/gcc/rtl-error.c:110
0xbd2ec8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/mnt/svn/gcc-trunk/gcc/rtl-error.c:118
0xb89698 extract_insn(rtx_insn*)
/mnt/svn/gcc-trunk/gcc/recog.c:2343
0x962e67 instantiate_virtual_regs_in_insn
/mnt/svn/gcc-trunk/gcc/function.c:1598
0x962e67 instantiate_virtual_regs
/mnt/svn/gcc-trunk/gcc/function.c:1966
0x962e67 execute
/mnt/svn/gcc-trunk/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r221818 - ICE

[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670

--- Comment #3 from Matthias Klose  ---
at least on powerpc64le this looks like a versioning issue. in 4.9 these were
versioned @CXXABI_1.3.5, now in 5, they are versioned @GLIBCXX_3.4.15.

[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi

[mkuvyrkov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #2 from Maxim Kuvyrkov  ---
Demangled, these are:

std::bad_function_call::~bad_function_call()
std::bad_function_call::~bad_function_call()
std::bad_function_call::~bad_function_call()
vtable for std::bad_function_call