[Bug bootstrap/59528] Profiledbootstrap should use stage1 compiler during stagefeedback
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59528 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 31810 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31810action=edit Makefile.in patch The attached patch to Makefile.in fixes the issue for me. I know that Makefile.in is a generated file, but how one translates the changes to Makefile.in back to Makefile.tpl is beyond me.
[Bug fortran/58026] [F03] Bad error recovery for allocatable component of undeclared type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026 --- Comment #12 from janus at gcc dot gnu.org --- Author: janus Date: Sun Jan 12 11:08:31 2014 New Revision: 206564 URL: http://gcc.gnu.org/viewcvs?rev=206564root=gccview=rev Log: 2014-01-12 Janus Weil ja...@gcc.gnu.org PR fortran/58026 * decl.c (gfc_match_data_decl): Improve error recovery. 2014-01-12 Janus Weil ja...@gcc.gnu.org PR fortran/58026 * gfortran.dg/alloc_comp_basics_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/37336] [F03] Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Bug 37336 depends on bug 58026, which changed state. Bug 58026 Summary: [F03] Bad error recovery for allocatable component of undeclared type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/58026] [F03] Bad error recovery for allocatable component of undeclared type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from janus at gcc dot gnu.org --- (In reply to janus from comment #10) So: The ICE regression is fixed and only the error-recovery problem of comment 8 persists. ... which is fixed on 4.9 trunk by r206564. Closing.
[Bug ada/59772] [4.7/4.8/4.9 regression ] floating-point constants are not correctly encoded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59772 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target||avr-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-12 CC||ebotcazou at gcc dot gnu.org Version|unknown |4.7.3 Target Milestone|--- |4.7.4 Summary|Floating point constants|[4.7/4.8/4.9 regression ] |are not correctly encoded |floating-point constants |on AVR target |are not correctly encoded Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Note that there is no official GNAT port for the AVR in the FSF tree, but we will nevertheless fix the bug.
[Bug ada/59772] [4.7/4.8/4.9 regression] floating-point constants are not correctly encoded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59772 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Summary|[4.7/4.8/4.9 regression ] |[4.7/4.8/4.9 regression] |floating-point constants|floating-point constants |are not correctly encoded |are not correctly encoded --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Fixing.
[Bug fortran/54851] Compiling gfortran.dg/class_array_7.f03 with '-O1 -flto' gives an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54851 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR has been fixed between r206354 (ICE) and r206560 (OK) (likely r206461). Closing as FIXED.
[Bug ada/59772] [4.7/4.8/4.9 regression] floating-point constants are not correctly encoded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59772 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Sun Jan 12 14:29:12 2014 New Revision: 206565 URL: http://gcc.gnu.org/viewcvs?rev=206565root=gccview=rev Log: PR ada/59772 * gcc-interface/cuintp.c (build_cst_from_int): Use 32-bit integer type as intermediate type. (UI_To_gnu): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/cuintp.c
[Bug ada/59772] [4.7/4.8/4.9 regression] floating-point constants are not correctly encoded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59772 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Sun Jan 12 14:29:44 2014 New Revision: 206566 URL: http://gcc.gnu.org/viewcvs?rev=206566root=gccview=rev Log: PR ada/59772 * gcc-interface/cuintp.c (build_cst_from_int): Use 32-bit integer type as intermediate type. (UI_To_gnu): Likewise. Modified: branches/gcc-4_8-branch/gcc/ada/ChangeLog branches/gcc-4_8-branch/gcc/ada/gcc-interface/cuintp.c
[Bug ada/59772] [4.7/4.8/4.9 regression] floating-point constants are not correctly encoded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59772 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Sun Jan 12 14:30:19 2014 New Revision: 206567 URL: http://gcc.gnu.org/viewcvs?rev=206567root=gccview=rev Log: PR ada/59772 * gcc-interface/cuintp.c (build_cst_from_int): Use 32-bit integer type as intermediate type. (UI_To_gnu): Likewise. Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/gcc-interface/cuintp.c
[Bug ada/59772] [4.7/4.8/4.9 regression] floating-point constants are not correctly encoded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59772 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- .
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
For the tests in comment 1, I think PR323 strikes back again. I the same
results for both -m32 and -m64 with the following patch
--- ../_clean/libgfortran/io/write_float.def2014-01-04 15:51:53.0
+0100
+++ libgfortran/io/write_float.def2014-01-12 15:55:24.0 +0100
@@ -1043,10 +1043,11 @@ output_float_FMT_G_ ## x (st_parameter_d
break;\
}\
\
- rexp_d = calculate_exp_ ## x (-d);\
- if ((m 0.0 ((m 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) =
1.0)))\
+ rexp_d = calculate_exp_ ## x (d);\
+ if ((m 0.0 ((10.0 * rexp_d * m rexp_d - r ) || ((m + r) = rexp_d)))\
|| ((m == 0.0) !(compile_options.allow_std\
- (GFC_STD_F2003 | GFC_STD_F2008\
+ (GFC_STD_F2003 | GFC_STD_F2008)))\
+ || d == 0)\
{ \
newf.format = FMT_E;\
newf.u.real.w = w;\
@@ -1069,7 +1070,7 @@ output_float_FMT_G_ ## x (st_parameter_d
volatile GFC_REAL_ ## x temp;\
mid = (low + high) / 2;\
\
- temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
+ temp = (calculate_exp_ ## x (mid - 1) * (rexp_d - r) / rexp_d);\
\
if (m temp)\
{ \
I think in order to avoid overflows (10.0 * rexp_d * m rexp_d - r ) and ((m +
r) = rexp_d) should be exchanged.
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- No regression with the patch in comment 5. What is the canonical way to ensure that -m32 and -m64 use the same arithmetic?
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- With the patch in comment 5 I get [Book15] f90/bug% cat pr48906_4_red.f90 print (ru,g45.25), .099e25 end [Book15] f90/bug% gfc pr48906_4_red.f90 [Book15] f90/bug% a.out 99005063032291983360.000 [Book15] f90/bug% gfc pr48906_4_red.f90 -m32 [Book15] f90/bug% a.out 99005063032291983360.0
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Even worse [Book15] f90/bug% cat pr48906_4_red.f90 print (ru,g45.20), .099e21 end [Book15] f90/bug% gfc pr48906_4_red.f90 [Book15] f90/bug% a.out 9900576671973376.0 [Book15] f90/bug% gfc pr48906_4_red.f90 -m32 [Book15] f90/bug% a.out 10. Note that without the patch I get 10. for both -m32 and -m64.
[Bug c++/59775] New: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 Bug ID: 59775 Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com I am trying to build Libreoffice 4.1.4.3 with current trunk. S=/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2 O=$S/solver/unxlngx6.pro W=$S/workdir/unxlngx6.pro mkdir -p $W/CxxObject/oox/source/core/ $W/Dep/CxxObject/oox/source/core/ cd /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2 x86_64-pc-linux-gnu-g++ -DCPPU_ENV=gcc3 -DLIBO_INTERNAL_ONLY -DLINUX -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DSOLAR_JAVA -DSUPD=410 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -DRTL_USING -DOOX_DLLIMPLEMENTATION -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fvisibility-inlines-hidden -DLIBO_MERGELIBS -fPIC -Wshadow -Woverloaded-virtual -Wnon-virtual-dtor -std=gnu++0x -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -fPIC -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -mno-avx -mno-sse4.2 -mno-3dnow -fno-lto -fno-use-linker-plugin -c $S/oox/source/core/fragmenthandler.cxx -o $W/CxxObject/oox/source/core/fragmenthandler.o -I$S/oox/source/core/ -I$S/include -I$O/inc/external -I$O/inc -I/usr/lib64/icedtea7/include -I/usr/lib64/icedtea7/include/linux -I$S/config_host -I$W/CustomTarget/oox/generated -I$S/oox/inc -I$W/UnoApiHeadersTarget/udkapi/normal -I$W/UnoApiHeadersTarget/offapi/normal -I/usr/include [build CXX] oox/source/core/recordparser.cxx /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/oox/source/core/filterdetect.cxx: In member function ‘com::sun::star::uno::Referencecom::sun::star::io::XInputStream oox::core::FilterDetect::extractUnencryptedPackage(comphelper::MediaDescriptor) const’: /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/oox/source/core/filterdetect.cxx:778:1: internal compiler error: Segmentation fault } // namespace oox ^ /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/oox/source/core/fragmenthandler2.cxx:200:1: warning: macro __code_model_small__ is not used [-Wunused-macros] } // namespace oox ^ S=/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2 O=$S/solver/unxlngx6.pro W=$S/workdir/unxlngx6.pro mkdir -p $W/CxxObject/oox/source/core/ $W/Dep/CxxObject/oox/source/core/ cd /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2 x86_64-pc-linux-gnu-g++ -DCPPU_ENV=gcc3 -DLIBO_INTERNAL_ONLY -DLINUX -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DSOLAR_JAVA -DSUPD=410 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -DRTL_USING -DOOX_DLLIMPLEMENTATION -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fvisibility-inlines-hidden -DLIBO_MERGELIBS -fPIC -Wshadow -Woverloaded-virtual -Wnon-virtual-dtor -std=gnu++0x -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -fPIC -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -mno-avx -mno-sse4.2 -mno-3dnow -fno-lto -fno-use-linker-plugin -c $S/oox/source/core/recordparser.cxx -o $W/CxxObject/oox/source/core/recordparser.o -I$S/oox/source/core/ -I$S/include -I$O/inc/external -I$O/inc -I/usr/lib64/icedtea7/include -I/usr/lib64/icedtea7/include/linux -I$S/config_host -I$W/CustomTarget/oox/generated -I$S/oox/inc -I$W/UnoApiHeadersTarget/udkapi/normal -I$W/UnoApiHeadersTarget/offapi/normal -I/usr/include [build CXX] oox/source/core/relations.cxx /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/oox/source/core/fragmenthandler.cxx:132:1: warning: macro __code_model_small__ is not used [-Wunused-macros] } // namespace oox ^ Please submit a full bug report, with preprocessed source if appropriate. See https://bugs.gentoo.org/ for instructions. I am reducing a testcase but based on that I search for a string internal compiler error: Segmentation fault it can reduce it to an invalid case so I am attaching original ii file too.
[Bug c++/59775] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 --- Comment #1 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 31811 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31811action=edit Un-reduced ii file
[Bug c++/59775] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 --- Comment #2 from David Kredba nheghathivhistha at gmail dot com --- $O, $W and $S expanded command to compiler is x86_64-pc-linux-gnu-g++ -DCPPU_ENV=gcc3 -DLIBO_INTERNAL_ONLY -DLINUX -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DSOLAR_JAVA -DSUPD=410 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -DRTL_USING -DOOX_DLLIMPLEMENTATION -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -save-temps -fvisibility-inlines-hidden -DLIBO_MERGELIBS -fPIC -Wshadow -Woverloaded-virtual -Wnon-virtual-dtor -std=gnu++0x -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -fPIC -O2 -ggdb -march=native -mtune=native -flto=4 -fuse-linker-plugin -mno-avx -mno-sse4.2 -mno-3dnow -fno-lto -fno-use-linker-plugin -c /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/oox/source/core/recordparser.cxx -o ./recordparser.o -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/oox/source/core/ -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/solver/unxlngx6.pro/inc/external -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/solver/unxlngx6.pro/inc -I/usr/lib64/icedtea7/include -I/usr/lib64/icedtea7/include/linux -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/config_host -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CustomTarget/oox/generated -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/inc -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/inc/UnoApiHeadersTarget/udkapi/normal -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/inc/UnoApiHeadersTarget/offapi/normal -I/usr/include -I /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/UnoApiHeadersTarget/udkapi/normal -I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/UnoApiHeadersTarget/offapi/normal Reducing it with x86_64-pc-linux-gnu-g++ -fPIC -O2 -ggdb -std=gnu++0x -c.
[Bug c++/59775] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #3 from David Kredba nheghathivhistha at gmail dot com ---
typedef int sal_Int8;
typedef int sal_Int64;
namespace com
{
namespace sun
{
namespace star
{
namespace uno
{
template class class Sequence
{
};
}
}
} typedef com::sun::star::uno::Sequence sal_Int8 StreamDataSequence;
class BinaryStreamBase
{
public:
virtual void seek (sal_Int64);
void seekToStart ()
{
seek (0);
} int mbEof;
};
class BinaryInputStream:public virtual BinaryStreamBase
{
};
class SequenceInputStream:public BinaryInputStream
{
public:
SequenceInputStream (StreamDataSequence );
};
namespace core
{
void RecordParserparseStream ()
{
StreamDataSequence aRecData;
SequenceInputStream aRecStrm (aRecData);
aRecStrm.seekToStart ();
}
}
}
[Bug c++/59775] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 --- Comment #4 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 31812 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31812action=edit (c-)Reduced testcase
[Bug c/59776] New: gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776
Bug ID: 59776
Summary: gcc -g -O1 ICE in expand_debug_locations, at
cfgexpand.c:3865
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
/* gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 */
/* gcc 4.8.2-7 20131212 */
typedef struct {
float re,im;
} Complex;
void sub_(Complex *var_Dummy)
{
Complex var_;
auto Complex dummy_;
var_ = *var_Dummy;
*(((int *)(dummy_.re))) = 0;
*(((int *)(dummy_.im))) = 0;
dummy_ = var_;
}
/*
gccerr8.c: In function ‘sub_’:
gccerr8.c:6:6: internal compiler error: in expand_debug_locations, at
cfgexpand.c:3865
void sub_(var_Dummy)
^
Please submit a full bug report, with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/ccrC9Ofk.out file, please attach this to
your bugreport.
// /usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1 -quiet gccerr8.c -quiet
-dumpbase gccerr8.c -mtune=generic -march=x86-64 -auxbase gccerr8 -g -O1 -o -
-frandom-seed=0
# 1 gccerr8.c
# 1 /home/vitti/f95/cc//
# 1 command-line
# 1 /usr/include/stdc-predef.h 1 3 4
# 1 command-line 2
# 1 gccerr8.c
typedef struct {
float re,im;
} Complex;
void sub_(Complex *var_Dummy)
{
Complex var_;
auto Complex dummy_;
var_ = *var_Dummy;
*(((int *)(dummy_.re))) = 0;
*(((int *)(dummy_.im))) = 0;
dummy_ = var_;
}
*/
[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-12 CC||mpolacek at gcc dot gnu.org Component|c |middle-end Target Milestone|--- |4.8.4 Summary|gcc -g -O1 ICE in |[4.8/4.9 Regression] gcc -g |expand_debug_locations, at |-O1 ICE in |cfgexpand.c:3865|expand_debug_locations, at ||cfgexpand.c:3865 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug middle-end/59777] New: Incorrect expansion of TLS arguments in a call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59777 Bug ID: 59777 Summary: Incorrect expansion of TLS arguments in a call Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Created attachment 31813 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31813action=edit Testcase. The attached testcase shows the problem. Argument expressions containing a TLS symbol reference need to be precomputed as a call may be needed to legitimize the address and this may clobber the setup for earlier arguments causing wrong code. For example, compilation of the testcase with: gcc-4.8 -fPIC -DPIC -W -Wall -Wextra -Wshadow -Wformat -Wundef -D_GNU_SOURCE -O0 cap-ng.c -fPIC -DPIC -o cap-ng results in the following output: $ ./cap-ng cc m.hdr1 = 0x400015c8 pid = 0 There seems to be some attempt to handle this in precompute_register_parameters().
[Bug middle-end/59777] Incorrect expansion of TLS arguments in a call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59777 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- Created attachment 31814 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31814action=edit Output from expand. One can see in .expand that TLS arguments to printf are not being precomputed causing wrong code.
[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
struct S { float f, g; };
void
sub_ (struct S *p)
{
struct S s1, s2;
s1 = *p;
*(int *) s2.f = 0;
s2 = s1;
}
[Bug bootstrap/59528] Profiledbootstrap should use stage1 compiler during stagefeedback
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59528 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Attachment #31810|0 |1 is obsolete|| --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 31815 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31815action=edit Makefile.in patch
[Bug fortran/31601] RFC: legacy-only allowed: State that code is allowed with -std=legacy ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31601 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Examples: Integer too big for its kind at %C - Integer too big for its kind at %C. Use -fno-range-check to disable this check One now gets This check can be disabled with the option -fno-range-check since at least 4.3.1. Duplicate PROTECTED attribute specified at %L - Duplicate PROTECTED attribute specified at %L. Use -std=legacy to disable this check From if (!gfc_notify_std (GFC_STD_LEGACY, Duplicate PROTECTED attribute specified at %L, where)) this has not yet been implemented. If this deemed of any relevance, this is the kind of fix I can handle, otherwise this PR can be closed as WONTFIX. It would help me if a test case already exists, but I can do without it. Last question, are there other cases one can think of?
[Bug c++/59775] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-01-12
CC||hubicka at gcc dot gnu.org,
||trippels at gcc dot gnu.org
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
--- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Confirmed.
A bit more reduced:
markus@x4 /tmp % cat test.ii
class A {
public:
virtual void m_fn1();
void m_fn2() { m_fn1(); }
int mbEof;
};
class B : public virtual A {};
class C : public B {
public:
C(int );
};
int a;
void fn1() {
C b(a);
b.m_fn2();
}
Started with r206061.
[Bug target/59778] New: FAIL: gcc.dg/atomic/c11-atomic-exec-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59778 Bug ID: 59778 Summary: FAIL: gcc.dg/atomic/c11-atomic-exec-5.c Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/ -L/home/dave/gnu/gcc/ob jdir/hppa-linux-gnu/./libatomic/.libs -latomic -fno-diagnostics-show-caret -fdi agnostics-color=never -O0 -std=c11 -pedantic-errors -pthread -D_POSIX_C_SOURC E=200809L -lm -o ./c11-atomic-exec-5.exe(timeout = 300) spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/ dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c -B/home/dave/gn u/gcc/objdir/hppa-linux-gnu/./libatomic/ -L/home/dave/gnu/gcc/objdir/hppa-linux- gnu/./libatomic/.libs -latomic -fno-diagnostics-show-caret -fdiagnostics-color=n ever -O0 -std=c11 -pedantic-errors -pthread -D_POSIX_C_SOURCE=200809L -lm -o ./c 11-atomic-exec-5.exe PASS: gcc.dg/atomic/c11-atomic-exec-5.c -O0 (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/obj dir/hppa-linux-gnu/./libatomic/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/g nu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-li nux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/. libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/o bjdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/ gnu/gcc/objdir/./prev-gcc spawn [open ...] float_add_invalid (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_add_invalid_prev (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_add_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_add_overflow_prev (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_add_overflow_double (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_add_overflow_long_double (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_add_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_add_inexact_int (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_preinc_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_postinc_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail long_add_float_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail complex_float_add_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_sub_invalid (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_sub_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_sub_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_sub_inexact_int (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_predec_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_postdec_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail long_sub_float_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail complex_float_sub_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_mul_invalid (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_mul_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_mul_underflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_mul_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_mul_inexact_int (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail long_mul_float_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail complex_float_mul_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_div_invalid_divbyzero (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_div_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_div_underflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_div_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail float_div_inexact_int (a) 4999 pass, 0 fail; (b) 5000 pass, 1 fail int_div_float_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail complex_float_div_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail double_add_invalid (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail double_add_overflow (a) 4999 pass, 0 fail; (b) 5001 pass, 0 fail double_add_overflow_long_double (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail double_add_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail double_add_inexact_int (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail double_preinc_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail double_postinc_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail long_long_add_double_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail complex_double_add_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail double_sub_invalid (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail double_sub_overflow
[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
I've reduced it to:
struct A
{
virtual void foo () = 0;
void bar () { foo (); }
bool a;
};
struct B : public virtual A
{
virtual void foo ();
};
struct C : public B
{
C ();
};
void
baz ()
{
C c;
c.bar ();
}
[Bug tree-optimization/59779] New: [4.9 Regression] FAIL: gcc.dg/autopar/outer-1.c scan-tree-dump-times parloops parallelizing outer loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59779 Bug ID: 59779 Summary: [4.9 Regression] FAIL: gcc.dg/autopar/outer-1.c scan-tree-dump-times parloops parallelizing outer loop Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Created attachment 31816 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31816action=edit Tree dump Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/autopar/outer-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-parallelize-loops=4 -fdump-tree-parloops-details -fdump-tree-optimized -S -o outer-1.s(timeout = 300)spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/ dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/autopar/outer-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-parallelize-loops=4 -fdump-tree-parloops-details -fdump-tree-optimized -S -o outer-1.sPASS: gcc.dg/autopar/outer-1.c (test for excess errors) FAIL: gcc.dg/autopar/outer-1.c scan-tree-dump-times parloops parallelizing oute r loop 1FAIL: gcc.dg/autopar/outer-1.c scan-tree-dump-times optimized loopfn 4 r204343 was ok. r204829 failed.
[Bug tree-optimization/59779] [4.9 Regression] FAIL: gcc.dg/autopar/outer-1.c scan-tree-dump-times parloops parallelizing outer loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59779 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- Created attachment 31817 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31817action=edit tree dump
[Bug target/59780] New: ICE in aarch64_split_128bit_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59780
Bug ID: 59780
Summary: ICE in aarch64_split_128bit_move
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
when building r206565 with target aarch64-linux-gnu I run into several ICEs
like this:
...
/home/vries/gcc_versions/devel/src/libgcc/soft-fp/negtf2.c: In function
‘__negtf2’:
/home/vries/gcc_versions/devel/src/libgcc/soft-fp/negtf2.c:46:1: internal
compiler error: RTL check: expected code 'reg', have 'const_int' in rhs_regno,
at rtl.h:1125
}
^
0xbde5de rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/home/vries/gcc_versions/devel/src/gcc/rtl.c:773
0xfe4c1d rhs_regno
/home/vries/gcc_versions/devel/src/gcc/rtl.h:1125
0xfe62a1 aarch64_split_128bit_move(rtx_def*, rtx_def*)
/home/vries/gcc_versions/devel/src/gcc/config/aarch64/aarch64.c:688
0x1048a60 gen_split_2245(rtx_def*, rtx_def**)
/home/vries/gcc_versions/devel/src/gcc/config/aarch64/aarch64.md:752
b0x13fc389 split_1
/home/vries/gcc_versions/devel/src/gcc/config/aarch64/aarch64.md:751
0x1475285 split_insns(rtx_def*, rtx_def*)
/home/vries/gcc_versions/devel/src/gcc/config/aarch64/aarch64.md:352
0x7ec8f6 try_split(rtx_def*, rtx_def*, int)
/home/vries/gcc_versions/devel/src/gcc/emit-rtl.c:3471
0xb535ea split_insn
/home/vries/gcc_versions/devel/src/gcc/recog.c:2850
0xb545f2 split_all_insns()
/home/vries/gcc_versions/devel/src/gcc/recog.c:2940
0xb573f6 rest_of_handle_split_after_reload
/home/vries/gcc_versions/devel/src/gcc/recog.c:3889
0xb57440 execute
/home/vries/gcc_versions/devel/src/gcc/recog.c:3918
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.
...
Investigating one of them shows:
...
(gdb) down
#6 0x00fe62a2 in aarch64_split_128bit_move (dst=0x766fa0e0,
src=0x7687c470)
at /home/vries/gcc_versions/devel/src/gcc/config/aarch64/aarch64.c:688
688 int src_regno = REGNO (src);
(gdb) call debug_rtx (src)
(const_int 0 [0])
(gdb) call debug_rtx (dst)
(reg/v:TI 2 x2 [orig:80 _flo ] [80])
...
...
void
aarch64_split_128bit_move (rtx dst, rtx src)
{
rtx low_dst;
enum machine_mode src_mode = GET_MODE (src);
enum machine_mode dst_mode = GET_MODE (dst);
int src_regno = REGNO (src);
int dst_regno = REGNO (dst);
...
We're doing REGNO (src) while src == (const_int 0).
[Bug fortran/59678] Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #9 from Hossein Talebi talebi.hossein at gmail dot com --- I looked at it in more details by overloading the automatic assignment (=) with a self written one and I found the problem. This is a minimalistic example that the program crashes. Funny thing is that when I put MAX_PART_FEM=2, it runs but not with any other number. I use ubuntu 13.1, GCC 4.8.1. module module1 integer,parameter :: MAX_PART_FEM=32 type ty_type3 integer a,b integer, allocatable :: vec1(:) end type ty_type3 type ptr_ty_part_fem type(ty_type3), allocatable :: OBJ end type ptr_ty_part_fem type ty_type2 type(ptr_ty_part_fem):: parts_fem(MAX_PART_FEM) integer :: a2=1 end type ty_type2 end module module1 program hello use module1 implicit none type(ty_type2):: m2, m3 m3=m2 print *,m2%a2 end program
[Bug target/59780] ICE in aarch64_split_128bit_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59780
--- Comment #1 from vries at gcc dot gnu.org ---
I'm using this as workaround for the moment:
...
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 3b1f6b5..2c75c1c 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -685,7 +685,7 @@ aarch64_split_128bit_move (rtx dst, rtx src)
enum machine_mode src_mode = GET_MODE (src);
enum machine_mode dst_mode = GET_MODE (dst);
- int src_regno = REGNO (src);
+ int src_regno;
int dst_regno = REGNO (dst);
gcc_assert (dst_mode == TImode || dst_mode == TFmode);
@@ -693,6 +693,7 @@ aarch64_split_128bit_move (rtx dst, rtx src)
if (REG_P (dst) REG_P (src))
{
gcc_assert (src_mode == TImode || src_mode == TFmode);
+ src_regno = REGNO (src);
/* Handle r - w, w - r. */
if (FP_REGNUM_P (dst_regno) GP_REGNUM_P (src_regno))
@@ -754,6 +755,7 @@ aarch64_split_128bit_move (rtx dst, rtx src)
}
return;
case TFmode:
+src_regno = REGNO (src);
emit_move_insn (gen_rtx_REG (DFmode, dst_regno),
gen_rtx_REG (DFmode, src_regno));
emit_move_insn (gen_rtx_REG (DFmode, dst_regno + 1),
...
[Bug fortran/59678] Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #10 from Hossein Talebi talebi.hossein at gmail dot com --- I forgot to say, when I allocate the variables manually and then do assignment, it works fine.
[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com --- Missing right brace at end of code.
[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|WAITING |NEW
Summary|Segmentation fault on |[F03] Segfault on
|equalizing variables of a |equalizing variables of a
|complex derived data type |complex derived type
--- Comment #11 from janus at gcc dot gnu.org ---
Confirmed. Slightly reduced test case (fails at least with 4.6 up to trunk):
program hello
implicit none
type t3
integer b
integer, allocatable :: vec(:)
end type
type t2
type(t3), allocatable :: obj
end type
type t1
type(t2) :: parts
integer :: a=1
end type
type(t1):: x, y
y=x
end
The dump shows that the assignment is translated into:
{
void * restrict D.2321;
integer(kind=8) D.2320;
integer(kind=8) D.2319;
integer(kind=8) D.2318;
struct t1 D.2317;
D.2317 = y;
y = x;
y.parts = x.parts;
y.parts.obj = x.parts.obj;
if ((void *) x.parts.obj.vec.data != 0B)
{
D.2318 = (x.parts.obj.vec.dim[0].ubound -
x.parts.obj.vec.dim[0].lbound) + 1;
D.2319 = NON_LVALUE_EXPR D.2318;
D.2320 = D.2319 * 4;
D.2321 = (void * restrict) __builtin_malloc (MAX_EXPR (unsigned long)
D.2320, 1);
y.parts.obj.vec.data = D.2321;
__builtin_memcpy ((integer(kind=4)[0:] * restrict)
y.parts.obj.vec.data, (integer(kind=4)[0:] * restrict) x.parts.obj.vec.data,
(unsigned long) (D.2319 * 4));
}
else
{
y.parts.obj.vec.data = 0B;
}
if (D.2317.parts.obj != 0B)
{
if (D.2317.parts.obj-vec.data != 0B)
{
__builtin_free ((void *) D.2317.parts.obj-vec.data);
}
D.2317.parts.obj-vec.data = 0B;
__builtin_free ((void *) D.2317.parts.obj);
}
D.2317.parts.obj = 0B;
}
[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the test in comment 9, valgrind gives ==30542== Conditional jump or move depends on uninitialised value(s) ==30542==at 0x10D3C: MAIN__ (pr59678.f90:25) ==30542==by 0x10E95: main (pr59678.f90:21) ==30542== ==30542== Conditional jump or move depends on uninitialised value(s) ==30542==at 0x7FE007B0: ??? ==30542==by 0x10DCB: MAIN__ (pr59678.f90:25) ==30542==by 0x10E95: main (pr59678.f90:21) ==30542== ==30542== Conditional jump or move depends on uninitialised value(s) ==30542==at 0x7FE007B6: ??? ==30542==by 0x10DCB: MAIN__ (pr59678.f90:25) ==30542==by 0x10E95: main (pr59678.f90:21) ==30542== ==30542== Conditional jump or move depends on uninitialised value(s) ==30542==at 0x7FE007F3: ??? ==30542==by 0x10DCB: MAIN__ (pr59678.f90:25) ==30542==by 0x10E95: main (pr59678.f90:21) ==30542== ==30542== Use of uninitialised value of size 8 ==30542==at 0x7FE012B1: ??? ==30542==by 0x7FE00879: ??? ==30542==by 0x10DCB: MAIN__ (pr59678.f90:25) ==30542==by 0x10E95: main (pr59678.f90:21) ==30542== ==30542== Invalid read of size 1 ==30542==at 0x7FE012B1: ??? ==30542==by 0x7FE00879: ??? ==30542==by 0x10DCB: MAIN__ (pr59678.f90:25) ==30542==by 0x10E95: main (pr59678.f90:21) ==30542== Address 0xe41 is not stack'd, malloc'd or (recently) free'd I am not sure that the code is valid: allocatables not allocated.
[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the test in comment 11 valgrind gives ==41825== Invalid read of size 4 ==41825==at 0x7FE007BF: ??? ==41825==by 0x10DAF: MAIN__ (pr59678_1.f90:20) ==41825==by 0x10ED4: main (pr59678_1.f90:21) ==41825== Address 0x1 is not stack'd, malloc'd or (recently) free'd
[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678
--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to janus from comment #11)
The dump shows that the assignment is translated into:
{
void * restrict D.2321;
integer(kind=8) D.2320;
integer(kind=8) D.2319;
integer(kind=8) D.2318;
struct t1 D.2317;
D.2317 = y;
y = x;
y.parts = x.parts;
y.parts.obj = x.parts.obj;
Up to here the dump is fine, but it the next line things start to go wrong:
if ((void *) x.parts.obj.vec.data != 0B)
We fail to check if obj is allocated.
[Bug fortran/59781] New: Incorrect initialisation of derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781
Bug ID: 59781
Summary: Incorrect initialisation of derived type
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: james.s.spencer at gmail dot com
Created attachment 31818
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31818action=edit
Tarball containing example code, tree produced by gfortran 4.8.2 and Makefile.
(Complete modules and a makefile is attached. Also confirmed against 4.6.3)
With the definition
type dSFMT_t
private
type(c_ptr) :: dSFMT_state = c_null_ptr
real(c_double), allocatable :: random_store(:)
end type dSFMT_t
the dSFMT_t objects in the following module should both be initialised with a
null pointer for the dSFMT_state component:
module hilbert_space
implicit none
contains
subroutine test_rng()
use dSFMT_interface
type(dSFMT_t) :: rng
call dSFMT_init(7, 5, rng)
end subroutine test_rng
subroutine estimate_hilbert_space()
use dSFMT_interface
type(dSFMT_t) :: rng
call dSFMT_init(7, 5, rng)
end subroutine estimate_hilbert_space
end module hilbert_space
Instead only the rng object in estimate_hilbert_space is correctly initialised.
The relevant parts of the tree are:
estimate_hilbert_space ()
{
struct dsfmt_t rng;
try
{
{
struct dsfmt_t dsfmt_t.0;
dsfmt_t.0.dsfmt_state = 0B;
dsfmt_t.0.random_store.data = 0B;
rng = dsfmt_t.0;
}
[...]
}
}
test_rng ()
{
struct dsfmt_t rng;
try
{
rng.random_store.data = 0B;
[...]
}
}
This bug is tricky to observe---small changes to the code (e.g. making rng a
pointer, code reorganisation, having additional or fewer procedures in the same
file, removing the random_store allocatable component etc. can lead to the
dSFMT_t objects being correctly initialised. I had the above code (with
additions) in a large code base for several months until an innocuous
refactoring revealed it.
See also discussion at
https://groups.google.com/forum/#!topic/comp.lang.fortran/WogpvhUny4c, where
Janus posted a smaller example which breaks under gfortran trunk.
[Bug fortran/59781] [4.9 Regression] [F03] Incorrect initialisation of derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-12 CC||janus at gcc dot gnu.org Summary|Incorrect initialisation of |[4.9 Regression] [F03] |derived type|Incorrect initialisation of ||derived type Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- (In reply to james.s.spencer from comment #0) See also discussion at https://groups.google.com/forum/#!topic/comp.lang.fortran/WogpvhUny4c, where Janus posted a smaller example which breaks under gfortran trunk. namely this one (which apparently is a regression in 4.9 trunk): module hilbert_space use, intrinsic :: iso_c_binding implicit none type dSFMT_t type(c_ptr) :: dSFMT_state = c_null_ptr real(c_double), allocatable :: random_store(:) end type contains subroutine dSFMT_init (arg) type(dSFMT_t) :: arg end subroutine subroutine test_rng() type(dSFMT_t) :: rng call dSFMT_init (rng) end subroutine end module
[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Vittorio Zecca from comment #3) Missing right brace at end of code. What do you mean?
[Bug fortran/59781] [4.9 Regression] [F03] Incorrect initialisation of derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781 --- Comment #2 from janus at gcc dot gnu.org --- Here is a reduced test case of comment 0, which shows the wrong dump with all gfortran versions I tried (4.4, 4.6, 4.7, 4.8 and trunk): module dSFMT_interface use, intrinsic :: iso_c_binding implicit none type dSFMT_t type(c_ptr) :: state = c_null_ptr real(c_double), allocatable :: store(:) end type end module use dSFMT_interface implicit none contains subroutine dSFMT_init(rng) type(dSFMT_t) :: rng end subroutine subroutine test_rng() type(dSFMT_t) :: rng call dSFMT_init(rng) end subroutine end It is very similar to comment 1, just that the derived type is defined in a separate module.
[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- mine.
[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- OK, this testcase shows the get_binfo_at_offset bug I mentioned in the first virtual inheritance PR. We call get_binfo_at_offset for binfo of C looking for A at offset 64. This is correct query, but becase get_binfo_at_offsets walks fields and then it tries to match binfos, it actually looks up field representing A already in C and does not find A among direct bases of C. I suppose we will need to dive into the bases in get_binfo_at_offset same way as ipa-devirt does.
[Bug preprocessor/59782] New: libcpp does not avoid bug #48326 when compiled by older GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59782 Bug ID: 59782 Summary: libcpp does not avoid bug #48326 when compiled by older GCC Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: michael at talosis dot ca GCC 4.7.0 and other older versions have a bug (#48326) where the target attribute can leak, causing illegal instructions to be emitted in code intended to be generic. GCC 4.6.0 through 4.8.2 also contain code that triggers this bug, in libcpp/lex.c. That file uses the target attribute to opportunistically use MMX/SSE even in a generic binary. The result is that bootstrap is blocked if starting from 4.7.0 when the actual CPU does not support the new instructions. Currently the problem block of code is preprocessed in if GCC 4.5.0 or later is detected. It should instead only be used for 4.7.1 or later. Note that it is somewhat important to also fix this in 4.7.4. This bug only bites when upgrading from an old GCC. If someone has an old GCC with C++ not installed, then they cannot move directly to 4.8.x, and will have to build 4.7.x as an intermediate.
[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
This is fix I am testing. It makes get_binfo_at_offset to walk down the
non-virtual
part of the hiearchy until it hits the proper base.
I hope to significantly simplify get_binfo_at_offset by making it to walk bases
only and use get_class_context to walk structure fields/array indexes. In that
case
it would make more sense to implement it same was as record_target_from_binfo
(i.e.
omit the fields walk completely and only care about bases), but for 4.9 I think
this
can be resonable fix.
Honza
Index: tree.c
===
--- tree.c(revision 206542)
+++ tree.c(working copy)
@@ -11995,16 +11995,35 @@ get_binfo_at_offset (tree binfo, HOST_WI
represented in the binfo for the derived class. */
else if (offset != 0)
{
- tree base_binfo, found_binfo = NULL_TREE;
- for (i = 0; BINFO_BASE_ITERATE (binfo, i, base_binfo); i++)
-if (types_same_for_odr (TREE_TYPE (base_binfo), TREE_TYPE (fld)))
- {
-found_binfo = base_binfo;
-break;
- }
- if (!found_binfo)
-return NULL_TREE;
- binfo = found_binfo;
+ tree base_binfo, binfo2 = binfo;
+
+ /* Find BINFO corresponding to FLD. This is bit harder
+ by a fact that in virtual inheritance we may need to walk down
+ the non-virtual inheritance chain. */
+ while (true)
+{
+ tree containing_binfo = NULL, found_binfo = NULL;
+ for (i = 0; BINFO_BASE_ITERATE (binfo2, i, base_binfo); i++)
+if (types_same_for_odr (TREE_TYPE (base_binfo), TREE_TYPE (fld)))
+ {
+found_binfo = base_binfo;
+break;
+ }
+else
+ if (BINFO_OFFSET (base_binfo) - BINFO_OFFSET (binfo) pos
+ (!containing_binfo
+ || (BINFO_OFFSET (containing_binfo)
+ BINFO_OFFSET (base_binfo
+containing_binfo = base_binfo;
+ if (found_binfo)
+{
+ binfo = found_binfo;
+ break;
+}
+ if (!containing_binfo)
+return NULL_TREE;
+ binfo2 = containing_binfo;
+}
}
type = TREE_TYPE (fld);
[Bug target/59744] miscompilation of unsigned comparison on aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59744 --- Comment #4 from Michael Hudson-Doyle michael.hudson at linaro dot org --- Hi, thanks for the super fast fix. Could it be backported to 4.8? git cherry-pick gives a conflict in aarch64.md which is probably easy to fix if you know how this code works: (define_insn *compare_negmode HEAD [(set (reg:CC CC_REGNUM) (compare:CC (match_operand:GPI 0 register_operand r) (neg:GPI (match_operand:GPI 1 register_operand r] ||| parent of 46b590a... PR target/9744 [(set (reg:CC_SWP CC_REGNUM) (compare:CC_SWP (neg:GPI (match_operand:GPI 0 register_operand r)) (match_operand:GPI 1 register_operand r)))] === [(set (reg:CC_Z CC_REGNUM) (compare:CC_Z (neg:GPI (match_operand:GPI 0 register_operand r)) (match_operand:GPI 1 register_operand r)))] 46b590a... PR target/9744 cmn\\t%w0, %w1 [(set_attr v8type alus) (set_attr mode MODE)] )
[Bug target/59778] FAIL: gcc.dg/atomic/c11-atomic-exec-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59778 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- Please see the advice to architecture maintainers at http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html.
[Bug other/59783] New: inline expansion stack when attribute error/warning triggered is displayed incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783
Bug ID: 59783
Summary: inline expansion stack when attribute error/warning
triggered is displayed incorrectly
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.santos at pobox dot com
In C C11, __attribute__((error())) is a wonderful replacement for
_Static_assert() (e.g.,
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler.h#n316).
However, when used in nested __always_inline functions where parameters to the
function are treated as compiletime constants and tested via such a mechanism,
the compiler doesn't tell us the correct root cause of the problem.
static void inline __attribute__((always_inline)) validate_pair(int x, int y) {
extern void diedie() __attribute__((error(x + y = too many)));
if (x + y 32)
diedie();
}
static void inline __attribute__((always_inline)) a1(int x, int y) {
validate_pair(x, y);
/* do some stuff */
}
static void inline __attribute__((always_inline)) a2(int x, int y) {
validate_pair(x, y);
/* do some other stuff */
}
static void inline __attribute__((always_inline)) b(int x, int y) {
if (x 1)
a1(x, y);
else
a2(x, y);
}
int main(int argc, char *argv[]) {
b(4, 12);
b(5, 13);
b(6, 13);
b(28, 14);
b(27, 14);
b(2, 15);
return 0;
}
When built with -O1 or greater, it yields this output:
In function ‘validate_pair’,
inlined from ‘main’ at asdf.c:15:18:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
diedie();
^
In function ‘validate_pair’,
inlined from ‘main’ at asdf.c:10:18:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
diedie();
^
It is correct that these two errors were inlined from the function main, but
the line number given is the function that actually calls validate_pair(),
although the actual inline instantiation stack for the first error was main()
- b() - a1() - validate_pair() and for the second error main() - b() -
a1() - validate_pair(). The work-around is essentially to use a preprocessor
macro, although a lot of simplicity, type-safety, etc. are then lost.
Since we are working with compile-time constant values, what would be nice
(similar to what is requested for bug #41373) is to display the entire inline
function instantiation/expansion stack, e.g.:
In function ‘validate_pair’,
inlined from ‘a2’ at asdf.c:15:18:
inlined from ‘b’ at asdf.c:23:25:
inlined from ‘main’ at asdf.c:30:15:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
diedie();
This way, we can trace it to the exact function call (or inline function
expansion) that caused the problem. Welcome to the new age of C
metaprogramming! (and thank you for helping to make it possible) This is an age
of compile-time data (if not types, like C++ metaprogramming). So if you
*really* wanted to be helpful, you could do something like this:
In function ‘validate_pair’,
inlined from ‘a2’ [with x=28, y=14] at asdf.c:15:18:
inlined from ‘b’ [with x=28, y=14] at asdf.c:23:25:
inlined from ‘main’ [with x=28, y=14] at asdf.c:30:15:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
diedie();
Now I realize that actually involves a lot as many data types can be treated as
compiletime constants, even structs and pointers to structs and functions, but
I didn't think it could hurt to throw it out there. Essentially, displaying
the constant parameters of an inlined function call like you do the template
parameters in a C++ templatized function or type.
See also: bug #41373
[Bug rtl-optimization/59754] [ree.c] Incorrect merge while working with vector registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59754 --- Comment #6 from Yukhin Kirill kirill.yukhin at intel dot com --- (In reply to Jeffrey A. Law from comment #3) Kirill, can you verify that Jakub's patch restores proper behaviour for your tests? It'd be greatly appreciated. Hello, I've checked recent trunk with Jakub's changes checked in and it seems that at the moment all of AVX-512 tests are pass (under simulator). Thanks a lot for fixing that!
[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776 --- Comment #5 from Vittorio Zecca zeccav at gmail dot com --- I am sorry I was not clear enough, in your shorter test case, after s2 = s1; there is a right brace } missing.
[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jan 13 07:56:40 2014 New Revision: 206572 URL: http://gcc.gnu.org/viewcvs?rev=206572root=gccview=rev Log: PR libgomp/59194 * omp-low.c (expand_omp_atomic_pipeline): Expand the initial load as __atomic_load_N if possible. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c
