[Bug c++/38380] New: explicitly defaulted constructors vs. empty direct initialization
Another C++0x default issue, with Last Changed Rev: 142359
// { dg-options -std=gnu++0x }
namespace std
{
struct atomic_bool
{
bool _M_i;
atomic_bool() = default;
~atomic_bool() = default;
atomic_bool(const atomic_bool) = delete;
atomic_bool operator=(const atomic_bool) = delete;
atomic_bool(bool __i) { _M_i = __i; }
operator bool() const volatile
{ return true; }
};
}
namespace __gnu_test
{
struct direct_list_initializable
{
templatetypename _Ttype, typename _Tvalue
void
operator()()
{
struct _Concept
{
void __constraint()
{
_Ttype __v1 { }; // default ctor
_Ttype __v2 { __a }; // single-argument ctor
}
_Tvalue __a;
};
void (_Concept::*__x)() __attribute__((unused))
= _Concept::__constraint;
}
};
}
int main()
{
__gnu_test::direct_list_initializable test;
test.operator()std::atomic_bool, bool();
return 0;
}
Gives:
%/mnt/share/bld/gcc/./gcc/g++ -shared-libgcc -B/mnt/share/bld/gcc/./gcc
-nostdinc++ -L/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/mnt/share/bld/H-x86-gcc/x86_64-unknown-linux-gnu/bin/
-B/mnt/share/bld/H-x86-gcc/x86_64-unknown-linux-gnu/lib/ -isystem
/mnt/share/bld/H-x86-gcc/x86_64-unknown-linux-gnu/include -isystem
/mnt/share/bld/H-x86-gcc/x86_64-unknown-linux-gnu/sys-include -g -O2
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR=. -nostdinc++
-I/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/mnt/share/src/gcc/libstdc++-v3/libsupc++
-I/mnt/share/src/gcc/libstdc++-v3/include/backward
-I/mnt/share/src/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections
/mnt/share/src/gcc/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/direct_list_2.cc
-std=gnu++0x ./libtestc++.a -lm -o ./direct_list.exe -Wfatal-errors
/mnt/share/src/gcc/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/direct_list_2.cc:
In member function 'void
__gnu_test::direct_list_initializable::operator()()::_Concept::__constraint()
[with _Ttype = std::atomic_bool, _Tvalue = bool]':
/mnt/share/src/gcc/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/direct_list_2.cc:76:
instantiated from 'void __gnu_test::direct_list_initializable::operator()()
[with _Ttype = std::atomic_bool, _Tvalue = bool]'
/mnt/share/src/gcc/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/direct_list_2.cc:86:
instantiated from here
/mnt/share/src/gcc/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/direct_list_2.cc:68:
error: converting to 'const std::atomic_bool' from initializer list would use
explicit constructor 'std::atomic_bool::atomic_bool()'
compilation terminated due to -Wfatal-errors.
It's the would use explicit constructor bits that are confusing, since there
is only an explicitly defaulted constructor.
Also, this message should say something about using the default constructor to
create the members of the initialization list.
--
Summary: explicitly defaulted constructors vs. empty direct
initialization
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: jason at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38380
[Bug rtl-optimization/38281] [4.4 Regression] ice: Segmentation fault
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-12-03 08:42 --- Subject: Bug 38281 Author: ebotcazou Date: Wed Dec 3 08:40:50 2008 New Revision: 142388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142388 Log: PR rtl-optimization/38281 * combine.c (distribute_notes): When invoking SET_INSN_DELETED on i2, set it to NULL_RTX afterwards. * emit-rtl.c (set_insn_deleted): Fix formatting. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20081203-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/emit-rtl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38281
[Bug rtl-optimization/38281] [4.4 Regression] segmentation fault with optimization enabled
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-12-03 08:47 --- Thanks for reporting the problem. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.4 Regression] ice: |[4.4 Regression] |Segmentation fault |segmentation fault with ||optimization enabled Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38281
[Bug ada/37799] SEGV compiling ada/ada.ads in stage2
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-12-03 08:58 --- The compilers were configured as follows: Target: sparc-sun-solaris2.11 Configured with: /vol/gcc/src/gcc-dist/configure CC=/vol/gcc/obj/gcc-4.4.0-20081202/11-gcc-v9/gccv9 --with-gmp-include=/vol/gcc/obj/gmp-4.2.1-v9 --with-gmp-lib=/vol/gcc/obj/gmp-4.2.1-v9/.libs --with-mpfr-include=/vol/gcc/obj/mpfr-2.3.2-v9 --with-mpfr-lib=/vol/gcc/obj/mpfr-2.3.2-v9/.libs --with-gnu-as --with-as=/vol/gcc/lib/gas-2.19 --enable-languages=c,ada --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls Thread model: posix gcc version 4.4.0 20081202 (experimental) [trunk revision 142371] (GCC) resp. Target: sparc-sun-solaris2.11 Configured with: /vol/gcc/src/gcc-dist/configure CC=/vol/gcc/obj/gcc-4.4.0-20081202/11-gcc-v9/gccv9 --with-gmp-include=/vol/gcc/obj/gmp-4.2.1-v9 --with-gmp-lib=/vol/gcc/obj/gmp-4.2.1-v9/.libs --with-mpfr-include=/vol/gcc/obj/mpfr-2.3.2-v9 --with-mpfr-lib=/vol/gcc/obj/mpfr-2.3.2-v9/.libs --enable-languages=c,ada --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls Thread model: posix gcc version 4.4.0 20081202 (experimental) [trunk revision 142371] (GCC) But these are not 64-bit compilers, see the target triplet. You need to pass --build=sparc64-sun-solaris2.11 and start with a 64-bit compiler. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37799
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-03 09:11 --- Subject: Bug 37610 Author: jakub Date: Wed Dec 3 09:09:43 2008 New Revision: 142389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142389 Log: PR target/37610 * configure.ac (gcc_cv_readelf): Look for readelf. (gcc_cv_as_cfi_advance_working): Check for working cfi advances with code alignment factor 1. (HAVE_GAS_CFI_DIRECTIVE): Don't define if cfi advances don't work properly. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug fortran/38268] gfortran doesn't link any 64 bits binaries on Solaris
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-12-03 09:12 --- gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o sol2-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/lib -L/usr/lib -lmpfr -lgmp -L/usr/lib -L/usr/lib -lmpfr -lgmp Undefined first referenced symbol in file libintl_gettext c-decl.o libintl_textdomain libbackend.a(intl.o) libintl_bindtextdomain libbackend.a(intl.o) libintl_dgettext../libcpp/libcpp.a(errors.o) ld: fatal: Symbol referencing errors. No output written to cc1-dummy collect2: ld returned 1 exit status gnu-make[3]: *** [cc1-dummy] Error 1 gnu-make[3]: Leaving directory `/home/delisle/gcc/obj44/gcc' gnu-make[2]: *** [all-stage1-gcc] Error 2 gnu-make[2]: Leaving directory `/home/delisle/gcc/obj44' gnu-make[1]: *** [stage1-bubble] Error 2 gnu-make[1]: Leaving directory `/home/delisle/gcc/obj44' gnu-make: *** [all] Error 2 Ah, yes, this is a classical one, see PR bootstrap/12482. You can work around it by passing --disable-nls to the configure script. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38268
[Bug tree-optimization/37716] [4.4 Regression] ice for legal C++ code with -O2 on 20080926
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||12/msg00144.html Status|NEW |ASSIGNED Last reconfirmed|2008-10-02 14:10:57 |2008-12-03 09:10:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #12 from jakub at gcc dot gnu dot org 2008-12-03 09:11 --- Fixed in gas, configury check added for gcc. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
�dv
Szia Pár napja kérdezted hogy nem e tudok egy jó letölt#337;s oldalt. És én most találtam egyet. Tele van jobbnál jobb filmekkel, és olcsó! 1 db sms elküldése után 500 kb/sec-el töltöttem napokig a legújabb premier filmeket és meséket. Szerintem neked is be fog válni: http://href.hu/x/7k7e __ E-mail címed a Country jóvoltából került bele hírlevél rendszerünkbe. Ha nem szeretnél több ilyet kapni. Írj a [EMAIL PROTECTED] email címre! A küld#337; Fiktív, kitalált személy, de az e-mail címen elérsz bennünket.
ERROR IN LINKING
hai friends...there is a error in linking my project ... the error is as follows.. please help me in this issue.thank u.. could not read symbols: Archive has no index; run ranlib to add one collect2: ld returned 1 exit status please help me in solving this... please mail me soln or in the forum.. my mail id is [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/ERROR-IN-LINKING-tp20809866p20809866.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-03 10:34
---
This sort-of inconsistency is essentially due to the glibc specifics (+ the
fact that we are dealing separately with C locale) see the below GNU C
snippet. In particular, note in numeric_members.cc that we already deal
correctly with the possibility of THOUSANDS_SEP == '\0'. In my opinion, all the
past discussions in this area considered, we should only tweak
monetary_members.cc vs __MON_DECIMAL_POINT == '\0' (possibly
__MON_THOUSANDS_SEP == '\0' too) in complete analogy with numeric_members.cc vs
THOUSANDS_SEP == '\0'.
/
#define _GNU_SOURCE
#include locale.h
#include stdio.h
#include langinfo.h
#include assert.h
int main()
{
__locale_t cloc = 0;
char ts = 'z';
cloc = __newlocale(1 LC_ALL,
LC_CTYPE=C;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C,
cloc);
ts = *(nl_langinfo_l(THOUSANDS_SEP, cloc));
assert( ts == '\0' );
printf(%c\n, ts);
cloc = 0;
ts = 'z';
cloc = __newlocale(1 LC_ALL,
LC_CTYPE=C;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C,
cloc);
ts = *(nl_langinfo_l(__MON_DECIMAL_POINT /*__MON_THOUSANDS_SEP*/, cloc));
assert( ts == '\0' );
printf(%c\n, ts);
return 0;
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||paolo at gcc dot gnu dot
||org, bkoz at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-03 10:46 --- Or maybe we should just report the __MON_DECIMAL_POINT == '\0' thing to glibc, which seems special to me (THOUSANDS_SEP == '\0' is well known, on the other hand). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug middle-end/38070] [4.3 Regression] ICE in compare_values_warnv
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.2 Known to work||4.2.4 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-12-03 12:11:09 date|| Summary|ICE in compare_values_warnv |[4.3 Regression] ICE in ||compare_values_warnv Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38070
[Bug debug/38367] [4.1/4.2/4.3/4.4 regression] Wrong debug information for big endian function parameters
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-03 12:12 --- I'd say the bug is in assign_parm_find_stack_rtl: stack_parm = crtl-args.internal_arg_pointer; if (offset_rtx != const0_rtx) stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx); stack_parm = gen_rtx_MEM (data-promoted_mode, stack_parm); set_mem_attributes (stack_parm, parm, 1); /* set_mem_attributes could set MEM_SIZE to the passed mode's size, while promoted mode's size is needed. */ if (data-promoted_mode != BLKmode data-promoted_mode != DECL_MODE (parm)) set_mem_size (stack_parm, GEN_INT (GET_MODE_SIZE (data-promoted_mode))); In addition to setting MEM_SIZE it should also set MEM_OFFSET. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-02 20:24:57 |2008-12-03 12:12:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38367
[Bug tree-optimization/37716] [4.4 Regression] ice for legal C++ code with -O2 on 20080926
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-03 12:29 --- Subject: Bug 37716 Author: jakub Date: Wed Dec 3 12:27:48 2008 New Revision: 142392 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142392 Log: PR tree-optimization/37716 * tree-sra.c (sra_build_assignment): For scalar bitfield SRC construct all the needed operations as trees and gimplify_assign it to dst. * g++.dg/torture/pr37716.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr37716.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
[Bug debug/38367] [4.1/4.2/4.3/4.4 regression] Wrong debug information for big endian function parameters
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-03 12:28 --- Patch posted. -- jakub at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||12/msg00166.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38367
[Bug tree-optimization/37716] [4.4 Regression] ice for legal C++ code with -O2 on 20080926
--- Comment #9 from jakub at gcc dot gnu dot org 2008-12-03 12:33 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
[Bug middle-end/38250] ICE with -O2 -ftree-loop-distribution
--- Comment #5 from tomby at gcc dot gnu dot org 2008-12-03 13:36 --- Subject: Bug 38250 Author: tomby Date: Wed Dec 3 13:35:13 2008 New Revision: 142394 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142394 Log: PR middle-end/38250 * tree-loop-distribution.c (build_size_arg): New function. (generate_memset_zero): Checks if DR_STEP(de) is NULL. Reorganized generating of stmts. * testsuite/gcc.dg/tree-ssa/pr38250.c: New file. * tree-data-ref.c (dr_analyze_innermost): Returns bool. Indicate if analysis succeed. * tree-data-ref.h (dr_analyze_innermost): Returns bool. * tree-predcom.c (valid_initializer_p, find_looparound_phi): Uses new definition of dr_analyze_innermost. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-loop-distribution.c trunk/gcc/tree-predcom.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
[Bug ada/38333] Illegal program not detected, ARM 6.1(20): pragma Import illegal for abstract subprograms
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-03 14:06:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38333
[Bug ada/37799] SEGV compiling ada/ada.ads in stage2
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-12-03 14:31 --- Subject: Re: SEGV compiling ada/ada.ads in stage2 ebotcazou at gcc dot gnu dot org writes: But these are not 64-bit compilers, see the target triplet. You need to pass --build=sparc64-sun-solaris2.11 and start with a 64-bit compiler. I fear you're right: it occured to me that the GCC 3.4.3 I started with didn't have proper multilib support. I had started with gcc3.4.3 -m64 (which would have been a 64-bit compiler), but forgot to specify the correct target triplet, though I'm pretty sure I did so when I first reported the bug. I've now used a 32-bit gcc 4.4.0 with -m64 as bootstrap compiler and specified --build=sparcv9-sun-solaris2.10. This time, the bootstrap finished, so this has been pilot error ;-( Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37799
[Bug middle-end/36326] gimplification of aggregate copies introduces extra aggregate copy
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-12-03 15:11 --- Subject: Bug 36326 Author: rguenth Date: Wed Dec 3 15:10:03 2008 New Revision: 142396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142396 Log: 2008-12-03 Richard Guenther [EMAIL PROTECTED] PR middle-end/36326 * gimplify.c (is_gimple_mem_or_call_rhs): Remove work-around for non-BLKmode types. * gcc.dg/tree-ssa/pr36326.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr36326.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36326
[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
--- Comment #12 from jakub at gcc dot gnu dot org 2008-12-03 15:20 ---
Created an attachment (id=16813)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16813action=view)
gcc44-pr36143.patch
I've tried to implement what Richi suggested in #c6, unfortunately that didn't
fix the failure.
After forwprop1 foo_char and foo_void contain:
D.2279_5 = (struct Foo *) i;
D.2279_5-i[0] ={v} 1;
D.2281_11 = i[0];
but the optimizers don't figure out that ((struct Foo *) i)-i[0]
and i[0] is the same thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36143
[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-12-03 15:33 --- We should be able to go via a VIEW_CONVERT_EXPR when propagating (struct Foo *) i into the LHS dereference D.2279_5-i[0]. That is, convert that to VIEW_CONVERT_EXPR struct Foo (i)-i[0] and further fold that by noting that the final access is at offset zero and of the same type as i. (or more generally, for a final offset zero access always strip all component-refs and fold to VIEW_CONVERT_EXPR final-access-type (i)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36143
[Bug middle-end/38250] ICE with -O2 -ftree-loop-distribution
--- Comment #6 from spop at gcc dot gnu dot org 2008-12-03 15:38 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
[Bug regression/38381] New: -b option seems to be broken
when i'm trying to use -b option i can get only unrecognized option -b how to reproduce: gcc -b something -- Summary: -b option seems to be broken Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gfuchedzhy at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38381
[Bug fortran/38382] New: Open(Unit=6 fails
The command: Open(Unit=6, is compiled without error but leads to missinterpration of the following commands (e.g. write(*,*) is comiled as write to file). Thus, if there is a write(*,*)-command after the open-command and the exe-file is executed there is the following error message: Fortran Run Time Error, Cannot write to file open for read. If the unit number is changed to anything else (e.g. 5 or 7) this error disappears and the exe works. Thus the compiler cannot work with the unit number 6. -- Summary: Open(Unit=6 fails Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vinzent dot boerner at gmx dot de GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38382
[Bug bootstrap/38383] New: fails to build cross gcc for target hppa64-hp-hpux11.00
fails to build because of a wrong LINK_GCC_C_SEQUENCE_SPEC definition in gcc/config/pa/pa64-hpux.h The required library milli.a is hardcoded as /usr/lib/pa20_64/milli.a. That doesn't work in the cross compiler case, becasue it has to be searched for in the sysroot. -- Summary: fails to build cross gcc for target hppa64-hp-hpux11.00 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: r dot emrich at de dot tecosim dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: hppa64-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38383
[Bug bootstrap/38383] fails to build cross gcc for target hppa64-hp-hpux11.00
--- Comment #1 from r dot emrich at de dot tecosim dot com 2008-12-03 16:09 --- Created an attachment (id=16814) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16814action=view) possible patch That works for me. But someone has to verify that it doesn't cause regressions on native hp-ux bootstraps. I can't, no hardware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38383
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- Comment #3 from tsyvarev at ispras dot ru 2008-12-03 16:27 --- Yes, I see, this is feature of glibc: for POSIX locale it defines THOUSANDS_SEP, __MON_THOUSANDS_SEP and __MON_DECIMAL_POINT as . According to documentation for C-locale, this value means N/A (not assigned). But this is seems not a bug - because in POSIX locale GROUPING is -1, grouping is not applied to numbers, so THOUSANDS_SEP shouldn't be used. Also __MON_THOUSANDS_SEP shouldn't be used (__MON_GROUPING is -1) and __MON_DECIMAL_POINT (__MON_FRAC_DIGITS is -1). C++ is dealing separately with C locale, so it may define some cases in its own way. But it should do this in self-consitent manner - the standard stays, that (from the description of name() method of locale, 22.1.1.3, p.5) If *this has a name, then locale(name().c_str()) is equivalent to *this. So, if for locale created via locale(C) numpunctchar::thousands_sep() returns ',' then for every locale with name C, even with only LC_NUMERIC=C numpunctchar::thousands_sep() should also return ',', not '\0'. The same for moneypunctchar::decimal_point() - because in locale(C) it returns ., it should return . in any other locale with LC_MONETARY=C. moneypunctchar::thousands_sep() return '\0' in locale(C) (intentionally or unintentionally, i don't know), so in other locale with LC_MONETARY=C it can return '\0', this isn't a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug libstdc++/38384] New: fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
fails with: gmake[4]: Entering directory `/home/SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/libmath' /bin/sh ../libtool --tag CC --tag=CC --mode=compile /SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/xgcc -B/SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/ -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/bin/ -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/lib/ -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/include -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/sys-include -DHAVE_CONFIG_H -I. -I/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath -I.. -g -O2 -c -o stubs.lo /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c libtool: compile: /SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/xgcc -B/SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/ -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/bin/ -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/lib/ -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/include -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/sys-include -DHAVE_CONFIG_H -I. -I/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath -I.. -g -O2 -c /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c -DPIC -o .libs/stubs.o /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c:39: error: expected identifier or ( before float /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c:39: error: expected ) before fabs gmake[4]: *** [stubs.lo] Error 1 gmake[4]: Leaving directory `/home/SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/libmath' gmake[3]: *** [all-recursive] Error 1 -- Summary: fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: r dot emrich at de dot tecosim dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: hppa64-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug middle-end/38271] [4.4 Regression] Spurious / missing ... used uninitialized in this function warning
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-03 16:28 --- I can't reproduce this any longer since http://gcc.gnu.org/viewcvs?view=revrevision=142396 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #1 from r dot emrich at de dot tecosim dot com 2008-12-03
16:30 ---
Created an attachment (id=16815)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16815action=view)
preproccesed source
the following looks weired for me:
# 31 /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c 2
# 1 ../config.h 1
# 32 /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c 2
float
((float)fabs((double)(float)(float x)))
{
return (float) fabs(x);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug middle-end/38385] New: ICE with -O2 -ftree-loop-distribution
gcc ICEs with options -O2 -ftree-loop-distribution reloadx.i:24: internal compiler error: Segmentation fault Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/abuild/tbily/install/ --disable-bootstrap --disable-multilib --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20081203 (experimental) (GCC) -- Summary: ICE with -O2 -ftree-loop-distribution Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tomby at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38385
[Bug middle-end/38385] ICE with -O2 -ftree-loop-distribution
--- Comment #1 from tomby at gcc dot gnu dot org 2008-12-03 16:35 --- Created an attachment (id=16816) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16816action=view) ICE with -O2 -ftree-loop-distribution -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38385
[Bug middle-end/38271] [4.4 Regression] Spurious / missing ... used uninitialized in this function warning
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-12-03 16:38 ---
Still warns for
truct xxx {
short a;
short b;
void *c;
};
void bar(struct xxx);
void foo(struct xxx *p, int i)
{
struct xxx s0 = *p;
struct xxx s = s0;
if (s.a) i++;
bar(s);
}
at -O -m32 -Wuninitialized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
[Bug fortran/38386] New: Update BIND(C,name= checking for Fortran 2008
At the J3 / WG5 mailing list (reply by Bill Long):
Reinhold Bader wrote:
before taking this offline, I'd like to understand something about BIND(C)
which other people might know ...
Take the following example program:
module mod_label_interf
use, intrinsic :: iso_c_binding
implicit none
interface foo
subroutine foo_1(x, n, i) bind(c, name='Foo')
import :: c_float, c_int
real(c_float) :: x
integer(c_int), value :: n, i
end subroutine
subroutine foo_2(x, n, i) bind(c, name='Foo')
import :: c_float, c_int
real(c_float) :: x(*)
integer(c_int), value :: n, i
end subroutine
end interface
end module
program label_interf
use mod_label_interf
implicit none
integer(c_int) :: i
real(c_float) :: xx, xxx(3)
i = 2
call foo(xx, 1, i)
call foo(xxx, 3, i)
write(*, *) xx
write(*, *) xxx
end program
together with the C implementation
#include math.h
void Foo(float *x, int n, int i) {
int j;
for (j=0; jn; j++) {
*(x+j) = (float) (i + j) + 0.1;
}
}
This code is accepted by various processors and executes in accordance with
my
personal expectations (for what that is worth :-)).
It is not accepted by NAG's compiler, and also not by IBM xlf. NAG's error
message is
Error: label_interf.f90: Duplicate binding label 'Foo' for external
procedure FOO_2 and external procedure FOO_1
This error message is consistent with the Fortran 2003 rules. An
(non-abstract) interface declares the procedure name to be external.
However, in the case of a separate binding label, that rule is being
changed in Fortran 2008 to be the way you want it. If there is a
separate binding label then the procedure's name becomes a local name,
not external.
--
Summary: Update BIND(C,name= checking for Fortran 2008
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38386
[Bug middle-end/38385] ICE with -O2 -ftree-loop-distribution
--- Comment #3 from tomby at gcc dot gnu dot org 2008-12-03 16:41 --- Created an attachment (id=16817) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16817action=view) This patch fixes the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38385
[Bug middle-end/38385] ICE with -O2 -ftree-loop-distribution
--- Comment #2 from tomby at gcc dot gnu dot org 2008-12-03 16:40 --- It seems that after removing bbs in generate_builtin (tree-loop-distribution.c) some phis has bad incoming edges. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38385
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #15 from hjl dot tools at gmail dot com 2008-12-03 16:50 --- Simulator is fine. AVX executable can only run on simulator. If there is a simulator which can run SSE5 and AVX, we will add a new switch for it. -- hjl dot tools at gmail dot com changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2008-12-03 16:50:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug c/38387] New: psim miscompiled [regression]
psim does not work when compiled with gcc SVN trunk. It fails with an assertion on all runs. This is true with gdb cvs or 6.8. It works when compiled with: + x86_64 Debian provided compiler. gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) + x86_64 4.3.2 (CFARM /opt/cfarm/releases/4.3.2) + 32 bit Fedora 9 provided compiler + 32 bit Fedora 9 built from SVN trunk So it has broken since 4.3.2. -- Summary: psim miscompiled [regression] Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug fortran/38382] Open(Unit=6 fails
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-03 16:49 --- If you write: OPEN(UNIT=OUTPUT_UNIT, FILE=foo.dat) then you want that all output to the OUTPUT_UNIT is written to the file foo.dat. And a asterix UNIT=* in a PRINT or WRITE statement denotes the OUTPUT_UNIT. In many compilers, including gfortran, the standard output is unit 6, the standard error output is 0 (ERROR_UNIT) and the standard input unit is 5 (= INPUT_UNIT). (The constants such as OUTPUT_UNIT are defined in the intrinsic module ISO_FORTRAN_ENV.) As a general advise, you should try not to use unit numbers smaller than 10 as some of them are likely to have a special meaning, depending on the compiler; especially the numbers 0, 5, 6 should be avoided (unless you want to redirect stdin/stderr/stdout). If a compiler prints Hello to the screen for the following program, it is invalid according to the Fortran 2003 standard, previous Fortran standard have not specified this. use iso_fortran_env ! Needs a (partially) Fortran 2003 supporting compiler open(unit=OUTPUT_UNIT, file=foo.txt) print *, Hello end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38382
[Bug c/38387] psim miscompiled [regression]
--- Comment #1 from joel at gcc dot gnu dot org 2008-12-03 16:54 --- Created an attachment (id=16818) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16818action=view) program to run with psim This is a random ACATS test executable that can be run with psim to show if it works or doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug middle-end/38360] [4.3/4.4 regression] ICE in gimple_op, at gimple.h:1636
--- Comment #7 from jakub at gcc dot gnu dot org 2008-12-03 16:59 --- Subject: Bug 38360 Author: jakub Date: Wed Dec 3 16:57:44 2008 New Revision: 142399 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142399 Log: PR middle-end/38360 * tree-ssa-ccp.c (ccp_fold_builtin): Bail out if the builtin doesn't have the right number of arguments. * gcc.c-torture/compile/pr38360.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr38360.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38360
[Bug debug/38367] [4.1/4.2/4.3/4.4 regression] Wrong debug information for big endian function parameters
--- Comment #5 from pint at tlink dot de 2008-12-03 17:00 --- Sorry, I can't try it. The patch cannot be applied to 4.3.2. There is no set_mem_size there in assign_parm_find_stack_rtl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38367
[Bug fortran/38382] Open(Unit=6 fails
--- Comment #2 from dominiq at lps dot ens dot fr 2008-12-03 17:03 --- Is not this pr a duplicate of an older one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38382
[Bug middle-end/38360] [4.3 regression] ICE in gimple_op, at gimple.h:1636
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-03 17:02 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.0 |4.3.2 Known to work||4.4.0 Summary|[4.3/4.4 regression] ICE in |[4.3 regression] ICE in |gimple_op, at gimple.h:1636 |gimple_op, at gimple.h:1636 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38360
[Bug c/38387] psim miscompiled [regression]
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-03 17:04 --- Does it work built with -fno-strict-aliasing? -O1 or -O0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug c/38387] psim miscompiled [regression]
--- Comment #3 from joel at gcc dot gnu dot org 2008-12-03 17:07 --- Created an attachment (id=16819) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16819action=view) psim device tree Run as follows: powerpc-rtems4.10-run -f psim_tree a22006c Expected output: ,.,. A22006C ACATS 2.5 88-01-01 00:00:00 A22006C CHECK THAT A COMPILATION CAN BE PRECEDED BY EXTRA LINES. A22006C PASSED . When psim is miscompiled, you get: events.c:329: assertion failed - !events-processing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug c/38387] psim miscompiled [regression]
--- Comment #4 from joel dot sherrill at oarcorp dot com 2008-12-03 17:09 --- Subject: Re: psim miscompiled [regression] rguenth at gcc dot gnu dot org wrote: --- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-03 17:04 --- Does it work built with -fno-strict-aliasing? -O1 or -O0? Not to be stupid but how do I compile gcc with those arguments? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug debug/38367] [4.1/4.2/4.3/4.4 regression] Wrong debug information for big endian function parameters
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-03 17:11 --- PR37408 got fixed on gcc-4_3-branch only after 4.3.2 release, you can probably apply both patches to 4.3.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38367
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-03 17:15 --- Ok, let's try to enforce this kind of consistency. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-03 17:15:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug c/38387] psim miscompiled [regression]
--- Comment #5 from joel at gcc dot gnu dot org 2008-12-03 17:22 --- Works with -O0 (CFLAGS=-O0 ~/old/test-gcc/gdb-6.8/configure --target=powerpc-rtems4.10 --enable-sim --enable-sim-hardware --enable-timebase --enable-sim-trace --prefix=/n/12/joel/test-gcc/install/ make make install) b.log 21 (In reply to comment #4) Subject: Re: psim miscompiled [regression] rguenth at gcc dot gnu dot org wrote: --- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-03 17:04 --- Does it work built with -fno-strict-aliasing? -O1 or -O0? Not to be stupid but how do I compile gcc with those arguments? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug c/38387] psim miscompiled [regression]
--- Comment #6 from joel at gcc dot gnu dot org 2008-12-03 17:32 --- At -O1, there was a core dump. (gdb) run -f psim_tree.joel /home/joel/test-gcc/gcc-svn/gcc/testsuite/ada/acats/work-psim/tests/a/a22006c/a22006c Starting program: /home/joel/test-gcc/install/bin/powerpc-rtems4.10-run -f psim_tree.joel /home/joel/test-gcc/gcc-svn/gcc/testsuite/ada/acats/work-psim/tests/a/a22006c/a22006c Program received signal SIGSEGV, Segmentation fault. 0x0040304a in psim_last_cpu () (gdb) bt #0 0x0040304a in psim_last_cpu () #1 0x00484268 in idecode_run () #2 0x00403b1e in psim_run () #3 0x00402990 in main () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug c/38387] psim miscompiled [regression]
--- Comment #7 from joel at gcc dot gnu dot org 2008-12-03 17:40 --- Works with -fno-strict-aliasing added. Core dumps at -O1 Works at -O0. Is there anything I can do to narrow this down further? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug ada/37799] SEGV compiling ada/ada.ads in stage2
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-12-03 17:42 --- I've now used a 32-bit gcc 4.4.0 with -m64 as bootstrap compiler and specified --build=sparcv9-sun-solaris2.10. This time, the bootstrap finished, so this has been pilot error ;-( Thanks for investigating on your side. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37799
[Bug c++/36921] [4.3/4.4 Regression] warning comparison does not have mathematical meaning is not correct for overloaded operators that do not return boolean
--- Comment #8 from mmitchel at gcc dot gnu dot org 2008-12-03 17:47 --- I'm not convinced that we shouldn't warn in these cases. Yes, there are cases where people overload the operators in ways that make normal precedence irrelevant. But, there are also cases where people define boolean-like objects that are not themselves bool. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36921
[Bug other/38388] New: parallel install failures in install-{libiberty,gnatlib}
during -j8 install i can observe failures.
--
Summary: parallel install failures in install-{libiberty,gnatlib}
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38388
[Bug other/38388] parallel install failures in install-{libiberty,gnatlib}
--- Comment #1 from pluto at agmk dot net 2008-12-03 18:34 --- Created an attachment (id=16820) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16820action=view) log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38388
[Bug other/38388] parallel install failures in install-{libiberty,gnatlib}
--- Comment #2 from pluto at agmk dot net 2008-12-03 18:34 --- Created an attachment (id=16821) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16821action=view) log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38388
[Bug other/38388] parallel install failures in install-{libiberty,gnatlib}
--- Comment #3 from pluto at agmk dot net 2008-12-03 18:35 --- this is a trunk/r142396 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38388
[Bug bootstrap/38388] parallel install failures in install-{libiberty,gnatlib}
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-03 18:38 --- Hardly anybody installs using make -j. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|other |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38388
[Bug c/38387] psim miscompiled [regression]
--- Comment #8 from steven at gcc dot gnu dot org 2008-12-03 18:53 --- You can enable the aliasing warnings (-Wstrict-aliasing=2) and see if there are warnings when compiling psim. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-03 19:01 --- But a regression at least on some targets. Confirmed. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-03 19:01:16 date|| Summary|[4.4 Regression] 15%|[4.4 Regression] 15% |slowdown of computational |slowdown w.r.t. 4.3 of |kernel |computational kernel on some ||architectures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug fortran/38389] New: (DE)ALLOCATE compile time check for same variable
The Intel Fortran compiler has: error #8112: The same name cannot be specified more than once in a DEALLOCATE statement. [X] deallocate(x, x, errmsg=err) ^ Expected: Similar diagnostics for gfortran -- Summary: (DE)ALLOCATE compile time check for same variable Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38389
[Bug c++/38380] explicitly defaulted constructors vs. empty direct initialization
--- Comment #1 from jason at gcc dot gnu dot org 2008-12-03 19:23 --- Subject: Bug 38380 Author: jason Date: Wed Dec 3 19:22:08 2008 New Revision: 142404 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142404 Log: PR c++/38380 * decl.c (grokdeclarator): Only set DECL_NONCONVERTING_P on explicit constructors. * pt.c (tsubst_copy_and_build) [CONSTRUCTOR]: Propagate CONSTRUCTOR_IS_DIRECT_INIT. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tc1/dr152.C trunk/gcc/testsuite/g++.old-deja/g++.eh/ctor1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38380
[Bug c++/36921] [4.3/4.4 Regression] warning comparison does not have mathematical meaning is not correct for overloaded operators that do not return boolean
--- Comment #9 from deba at inf dot elte dot hu 2008-12-03 19:26 --- (In reply to comment #8) I'm not convinced that we shouldn't warn in these cases. Yes, there are cases where people overload the operators in ways that make normal precedence irrelevant. But, there are also cases where people define boolean-like objects that are not themselves bool. If the user-defined boolean-like object can be compared with other types, then the user had to write such a comparison operator, therefore the user declared that the boolean-like type is comparable with the other type. So this case could not be a problem. However, in my point of view, the proposed patch is not surely the best solution. The C++ defined the bool, which could solve the (a b c) problem. But unfortunately, as a shortcoming of the backward compatibility with C, the bool type is convertible to numeric types, which is a quite wrong pitfall. I think, instead of the current patch, the implicit conversion of a bool to numeric value should be warned in C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36921
[Bug c++/38380] explicitly defaulted constructors vs. empty direct initialization
--- Comment #2 from jason at gcc dot gnu dot org 2008-12-03 19:28 --- Feext -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38380
[Bug debug/38367] [4.1/4.2/4.3/4.4 regression] Wrong debug information for big endian function parameters
--- Comment #7 from schwab at suse dot de 2008-12-03 19:48 --- Fixes the bug for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38367
[Bug c++/37234] [c++0x] =default definition outside template class fails
--- Comment #2 from jason at gcc dot gnu dot org 2008-12-03 19:58 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37234
[Bug c++/38256] [4.4 regression] ICE with operator auto
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-11-29 03:15:59 |2008-12-03 20:12:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38256
[Bug c/38387] psim miscompiled [regression]
--- Comment #9 from joel at gcc dot gnu dot org 2008-12-03 20:33 --- Created an attachment (id=16822) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16822action=view) Warning log from gdb build This is grep warning build.log | sort -u from a build with -Wstrict-aliasing=2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug c/38387] psim miscompiled [regression]
--- Comment #10 from joel at gcc dot gnu dot org 2008-12-03 20:35 --- I have attached e.log which contains the warnings. All of the warnings in ppc-instructions are for taking the address of a double and casting it as an unsigned64 *. ld-insn.c:814 is a print so that's irrelevant. I could probably fix the warnings in ppc-instructions by defining a union with a double and unsigned64, using the double field and taking the address of the unsigned64 field. But I don't that it is related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug tree-optimization/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar
--- Comment #7 from spop at gcc dot gnu dot org 2008-12-03 20:50 --- *** Bug 37851 has been marked as a duplicate of this bug. *** -- spop at gcc dot gnu dot org changed: What|Removed |Added CC||dwarak dot rajagopal at amd ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37684
[Bug middle-end/37851] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3617
--- Comment #7 from spop at gcc dot gnu dot org 2008-12-03 20:50 --- Already fixed. *** This bug has been marked as a duplicate of 37684 *** -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37851
[Bug c++/38232] [4.4 Regression] value-initialization of reference warning too strict
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-11-23 12:20:31 |2008-12-03 20:57:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38232
[Bug debug/38390] New: Missing DW_TAG_imported_module
It works on Fedora gcc-c++-4.3.2-7.x86_64 but on 4.4-HEAD DIEs for
DW_TAG_imported_module are just missing.
import.C
--
namespace A
{
int v;
}
int
f ()
{
using namespace A;
return v;
}
--
g++ -c -o import.o import.C -Wall -g
From gcc-c++-4.3.2-7.x86_64:
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2e DW_AT_external: 1
2f DW_AT_name: f
31 DW_AT_decl_file : 1
32 DW_AT_decl_line : 7
33 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x37): _Z1fv
37 DW_AT_type: 0x5b
3b DW_AT_low_pc : 0x0
43 DW_AT_high_pc : 0xc
4b DW_AT_frame_base : 0x0 (location list)
4f DW_AT_sibling : 0x5b
253: Abbrev Number: 3 (DW_TAG_imported_module)
54 DW_AT_decl_file : 1
55 DW_AT_decl_line : 9
56 DW_AT_import : 0x62 [Abbrev Number: 5 (DW_TAG_namespace)]
From
GNU C++ (GCC) version 4.4.0 20081202 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20081202 (experimental), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2e DW_AT_external: 1
2f DW_AT_name: f
31 DW_AT_decl_file : 1
32 DW_AT_decl_line : 7
33 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x2b): _Z1fv
37 DW_AT_type: 0x4f
3b DW_AT_low_pc : 0x0
43 DW_AT_high_pc : 0xc
4b DW_AT_frame_base : 0x0 (location list)
(other DIEs exactly the same, DW_TAG_imported_module is missing here)
--
Summary: Missing DW_TAG_imported_module
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38390
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #8 from hjl dot tools at gmail dot com 2008-12-03 21:28 ---
(In reply to comment #5)
(In reply to comment #4)
4.3:
-O3 -march=native -funroll-loops -ffast-math == 4.376
-O3 -march=native -funroll-loops -ffast-math -fschedule-insns == 3.372
strangely:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Optimize-Options.html#Optimize-Options
suggests -fschedule-insns is enabled by default at -O3 ?
This may be related to PR 37565. i386.c has
void
optimization_options (int level, int size ATTRIBUTE_UNUSED)
{
/* For -O2 and beyond, turn off -fschedule-insns by default. It tends to
make the problem with not enough registers even worse. */
#ifdef INSN_SCHEDULING
if (level 1)
flag_schedule_insns = 0;
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug c++/38256] [4.4 regression] ICE with operator auto
--- Comment #6 from jason at gcc dot gnu dot org 2008-12-03 21:43 --- Subject: Bug 38256 Author: jason Date: Wed Dec 3 21:42:22 2008 New Revision: 142410 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142410 Log: PR c++/38256 * parser.c (cp_parser_conversion_type_id): Diagnose 'operator auto' here. * decl.c (grokdeclarator): Not here. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38256
[Bug c++/38256] [4.4 regression] ICE with operator auto
--- Comment #5 from jason at gcc dot gnu dot org 2008-12-03 21:43 --- fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38256
[Bug c++/28985] [4.2/4.3/4.4 Regression] class member access using a qualified-id fails to check for match of classes
--- Comment #5 from jason at gcc dot gnu dot org 2008-12-03 21:52 --- This is open core issue 399: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#399 Suspending. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28985
[Bug middle-end/38385] ICE with -O2 -ftree-loop-distribution
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-03 22:20 --- Subject: Re: ICE with -O2 -ftree-loop-distribution The patch looks good. Please fix formatting of the braces on the for stmt, and also add a more detailed description for the function fix_phis, saying what the arguments are doing. Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38385
[Bug middle-end/38391] New: insufficient information available for CFA_FRAME_BASE_OFFSET/ ARG_POINTER_CFA_OFFSET
In order to get debug information about the incoming arguments right for functions with nonzero pretend_args_size, CFA_FRAME_BASE_OFFSET and ARG_POINTER_CFA_OFFSET need to take the size of the pretend arguments into account. This used to be easy in gcc 4.2.1, however in gcc 4.4 this is no longer possible to do conforming with the macro definition in tm.texi, since CFA_FRAME_BASE_OFFSET / ARG_POINTER_CFA_OFFSET are supposed to work for arbitrary function definitions, but the incoming_args struct is only available for the current function. -- Summary: insufficient information available for CFA_FRAME_BASE_OFFSET/ ARG_POINTER_CFA_OFFSET Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38391
[Bug c/12742] Type alignment is lost if const is added to typedef
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-12-03 22:45 --- Test case still fails with fairly recent trunk. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-12-18 00:38:33 |2008-12-03 22:45:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742
[Bug target/34780] Bootstrapping libstdc++-v3 failed
--- Comment #12 from tkoenig at gcc dot gnu dot org 2008-12-03 23:24 --- Still fails with today's trunk. Is this a regression? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Known to fail||4.4.0 Last reconfirmed|2008-07-06 09:47:31 |2008-12-03 23:24:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
[Bug middle-end/38371] Fold check error during bootstrap
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-03 23:27 --- This is a bug in fold_checksum_tree, TYPE_NEXT_VARIANT on a type is allowed to change. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-03 23:27:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38371
[Bug fortran/36457] preprocessing: option -idirafter undefined for fortran
--- Comment #1 from billingd at gcc dot gnu dot org 2008-12-03 23:28 --- This is causing testsuite failures and should be fixed. The -idirafter appears to be coming from the cpp section in specs file, while the warning is generated in gcc/opts.c. I can see several possible approaches: 1. Prune the warning with dejagnu 2. Modify the cygwin specs file so -idirafter is not used for .F or .F90 file (or when called from gfortran) 3. Modify the code to somewhere Thoughts? -- billingd at gcc dot gnu dot org changed: What|Removed |Added CC||billingd at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-03 23:28:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36457
[Bug c++/38232] [4.4 Regression] value-initialization of reference warning too strict
--- Comment #5 from jason at gcc dot gnu dot org 2008-12-03 23:58 --- Subject: Bug 38232 Author: jason Date: Wed Dec 3 23:57:19 2008 New Revision: 142418 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142418 Log: PR c++/38232 * init.c (build_value_init): Do initial zero-initialization of a class with an implicitly-defined constructor using build_zero_init rather than in build_value_init. (build_value_init_1): Fold into build_value_init. Added: trunk/gcc/testsuite/g++.dg/init/value5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38232
[Bug fortran/36457] preprocessing: option -idirafter undefined for fortran
--- Comment #2 from billingd at gcc dot gnu dot org 2008-12-04 00:25 --- I can kill this warning if I invoke gfortran with -nostdinc. I would have expected this to be the default. After all, why include C source code or headers in a Fortran file. I will test this patch then ask on fortran@ --- cpp.c 2008-11-21 16:37:52.0 +1100 +++ cpp.c.new 2008-12-04 11:13:09.0 +1100 @@ -294,7 +294,7 @@ gfc_cpp_option.dump_includes = 0; gfc_cpp_option.working_directory = -1; gfc_cpp_option.no_predefined = 0; - gfc_cpp_option.standard_include_paths = 1; + gfc_cpp_option.standard_include_paths = 0; gfc_cpp_option.verbose = 0; gfc_cpp_option.multilib = NULL; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36457
[Bug debug/19523] [4.2/4.3/4.4 Regression] DBX_USE_BINCL support broken in the C++ compiler
--- Comment #15 from sje at cup dot hp dot com 2008-12-04 00:27 --- I noticed the reference to hppa in comment #13 of this bug report. hppa uses stabs but does not define DBX_USE_BINCL so is probably not affected by this bug. If hppa is the only reason not to close it we can probably go ahead and close it. Looking at the GCC sources I see DBX_USE_BINCL defined in config/darwin.h, config/dbxcoff.h, and config/dbxelf.h. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug c++/38392] New: Template friend function injection
When defining a friend function in a template class it does not get correctly
defined if the class instantiation comes after the function has been already
called. Note: this happens even if you pre-declare the function in its correct
context before the same function is called.
The following is a code sample that reproduces the bug. Note that this has been
already discussed and concluded that this is valid c++ standard-compliant code
(precisely here:
http://groups.google.com/group/comp.lang.c++/browse_frm/thread/493afd501c807ffe#).
-- code --
void Function();
int main(int argc, char* argv[])
{
Function(); // This does not work
}
template typename T
class Test
{
public:
friend void Function() { printf(Function()); getchar(); }
};
template class Testint;
-- end code --
--
Summary: Template friend function injection
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: H9XLrv5oXVNvHiUI at spambox dot us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug fortran/33595] FAIL: gfortran.dg/nint_2.f90 -O0 execution test
--- Comment #6 from billingd at gcc dot gnu dot org 2008-12-04 03:04
---
Just had a look at this with cvs gfortran under cygwin.
A slightly modified test
program intrinsic_integer
implicit none
call test (0.0, (/0, 0, 0, 0/))
call test (0.3, (/0, 1, 0, 0/))
call test (0.7, (/0, 1, 0, 1/))
call test (-0.3, (/-1, 0, 0, 0/))
call test (-0.7, (/-1, 0, 0, -1/))
contains
subroutine test(val, res)
real :: val
integer, dimension(4) :: res
if ((floor(val) .ne. res(1)) .or. (ceiling(val) .ne. res(2))
.or. (int(val) .ne. res(3)) .or. (nint(val) .ne. res(4))) then
write(6,'(a,f4.1,a,i2,a,i2)') 'nint(', val, ')=', nint(val),
' require ', res(4)
end if
end subroutine
end program
at -O0, -O1, -O2 and -O3 gives
nint( 0.7)= 0 require 1
nint(-0.7)= 0 require -1
The C test program at #1, compiled with gcc-3.4.4 or CVS gcc 4.4.0 20081128
(experimental) [trunk revision 142255] gives 0 1 1 as expected.
--
billingd at gcc dot gnu dot org changed:
What|Removed |Added
CC||billingd at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595
[Bug c++/37898] aggregates vs. defaulted deleted functions
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-12-04 03:41 --- Yes, the default ctor is explicitly defaulted, but the copy ctor is an (explicitly) deleted function. Deleted functions are user-defined. Thus, this is not an aggregate. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords|rejects-valid | Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37898
[Bug c++/37898] aggregates vs. defaulted deleted functions
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-12-04 03:46 ---
FYI removing the deleted copy constructor does indeed make this an aggregate.
So:
struct test_type
{
int i;
test_type() = default;
~test_type() = default;
test_type operator=(const test_type) = delete;
};
void test()
{
test_type t1 { 1 };
test_type t2[4] = { {1}, {2}, {3}, {4} };
test_type t3[4] = { {1}, {2}, {3} };
}
compiles properly in C++0x mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37898
[Bug tree-optimization/37894] [graphite] Polyhedron is not compiling (Summary)
--- Comment #2 from grosser at gcc dot gnu dot org 2008-12-04 04:32 --- Actually this should be open for everyone. -- grosser at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|grosser at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37894
[Bug fortran/33595] FAIL: gfortran.dg/nint_2.f90 -O0 execution test
--- Comment #7 from billingd at gcc dot gnu dot org 2008-12-04 05:11 --- I missed fortran/33177 - nint() on Cygwin. Sorry. -- billingd at gcc dot gnu dot org changed: What|Removed |Added CC|billingd at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595
[Bug fortran/38291] Rejects I/O with POS= if FMT=*
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-12-04 05:32
---
I am holding off on committing the patch.
With this test case I have found a nasty problem:
! { dg-do run }
! PR38291 Rejects I/O with POS= if FMT=*
character(15) :: sAccess
character(1) :: instr
open(50, access=stream, form=formatted)
write(50, *, pos=1) Just something
read( 50, *,pos=7)
inquire(50, access=sAccess)
if (sAccess.ne.STREAM) call abort
close(50,status=delete)
end
With the patch submitted to list, I get unstable execution. Sometimes errors
with -m32, sometimes with -m64, Sometimes one execution to the next. I do not
know if this is a latent bug or one introduced by the patch. I suspect latent
because this is the first time we actually are using dtp-pos even though it
has been in the dtp structure. Here is a sample output:
$ gfc streamio_16.f90
$ ./a.out
At line 7 of file streamio_16.f90 (unit = 50, file = 'fort.50')
Fortran runtime error: End of file
$ ./a.out
$ ./a.out
At line 7 of file streamio_16.f90 (unit = 50, file = 'fort.50')
Fortran runtime error: End of file
$ ./a.out
$ ./a.out
At line 7 of file streamio_16.f90 (unit = 50, file = 'fort.50')
Fortran runtime error: End of file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
[Bug fortran/36457] preprocessing: option -idirafter undefined for fortran
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-04 07:07 --- I can kill this warning if I invoke gfortran with -nostdinc. But won't that break programs which use e.g. include netcdf.inc which is in /usr/include/netcdf.inc ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36457
[Bug c++/38232] [4.4 Regression] value-initialization of reference warning too strict
--- Comment #6 from cgd at google dot com 2008-12-04 07:12 --- verified after syncing that my test case is now fixed. (Would close, but not sure why Jason didn't close it... please close if there's nothing else to do, Jason, or tell me to.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38232
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #12 from dannysmith at gcc dot gnu dot org 2008-12-04 07:14 --- Subject: Bug 38054 Author: dannysmith Date: Thu Dec 4 07:13:05 2008 New Revision: 142429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142429 Log: Backport from mainline: PR target/38054 * config/i386/winnt.c (i386_pe_encode_section_info): Condition stdcall decoration of function RTL names here on Ada language. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/winnt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #13 from dannysmith at users dot sourceforge dot net 2008-12-04 07:16 --- Fixed in 4.3.3 -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.4 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
