gcc-bugs@gcc.gnu.org
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 07:06 --- Indeed, the library side of this is rather straightforward, we are already implementing the FCD correctly (I also checked there no DRs or NBCs open): template inline pair::__type, typename __decay_and_strip<_T2>::__type> make_pair(_T1&& __x, _T2&& __y) thus, if something is wrong isn't the GNU library. CCing Jason in case he can spot something about the C++ front-end... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45253
[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared
--- Comment #43 from paolo dot carlini at oracle dot com 2010-08-11 07:08 --- Ok, even more obscure ;) Can you further investigate? Possibly pinging somebody knowledgeable about the specs? Before applying to the library the -nostdinc++ bits I'd like to make sure we fully understand the issue. Thanks... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
[Bug bootstrap/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-11 07:26 --- Thanks for your feedback Ian. Now, I'm not sure which target maintainer to suggest for powerpc-linux... David Edelsohn? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
[Bug bootstrap/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-11 07:30:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
[Bug libstdc++/42925] [GB 99] Not possible to compare unique_ptr with 0
--- Comment #15 from paolo at gcc dot gnu dot org 2010-08-11 08:50 --- Subject: Bug 42925 Author: paolo Date: Wed Aug 11 08:49:47 2010 New Revision: 163094 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163094 Log: 2010-08-11 Paolo Carlini PR libstdc++/42925 * include/bits/unique_ptr.h (operator==(const unique_ptr<>&, nullptr_t), operator==(nullptr_t, const unique_ptr<>&), operator!=(const unique_ptr<>&, nullptr_t), operator!=(nullptr_t, const unique_ptr<>&)): Add. * include/bits/shared_ptr_base.h (operator==(const __shared_ptr<>&, nullptr_t), operator==(nullptr_t, const __shared_ptr<>&), operator!=(const __shared_ptr<>&, nullptr_t), operator!=(nullptr_t, const __shared_ptr<>&)): Likewise. * include/bits/shared_ptr.h (operator==(const shared_ptr<>&, nullptr_t), operator==(nullptr_t, const shared_ptr<>&), operator!=(const shared_ptr<>&, nullptr_t), operator!=(nullptr_t, const shared_ptr<>&)): Likewise. * testsuite/20_util/unique_ptr/comparison/42925.cc: New. * testsuite/20_util/shared_ptr/comparison/42925.cc: Likewise. * testsuite/20_util/weak_ptr/comparison/cmp_neg.cc: Adjust dg-error line numbers. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/comparison/42925.cc trunk/libstdc++-v3/testsuite/20_util/unique_ptr/comparison/ trunk/libstdc++-v3/testsuite/20_util/unique_ptr/comparison/42925.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr.h trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/include/bits/unique_ptr.h trunk/libstdc++-v3/testsuite/20_util/weak_ptr/comparison/cmp_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] [GB 99] Not possible to compare unique_ptr with 0
--- Comment #16 from paolo dot carlini at oracle dot com 2010-08-11 08:51 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #8 from iains at gcc dot gnu dot org 2010-08-11 09:11 --- (In reply to comment #7) > (In reply to comment #5) > > -(hopefully) Andrew's analysis is correct (but, I guess I'd like to know > > why it > > fixed them ... ).. > > IIRC the issue with section anchors and the objective-c front-end was the decl > was being finialized in size after it had been pushed into the variable > cgraph. > So you moved that pushing later which fixed this issue. And in fact you can > now test powerpc-linux (or AIX; I think darwin now too) removing the check in > the back-end for objc language and section anchors. indeed, there are a couple of other issues with section anchors (on darwin) but the ObjC ones are resolved there too. Closing as fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug middle-end/45251] [4.6 Regression] Java testsuite regressions on hppa-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45251
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-11 09:27 --- I don't see why any change is needed. If a function (or variable) isn't defined in the current translation unit, then it necessarily has to be accessible from outside of the translation unit containing it. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||roland at redhat dot com, ||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug tree-optimization/41881] [4.5/4.6 regression] Complete unrolling (inner) versus vectorization of reduction
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-11 09:28 --- I think that SLP doesn't handle reduction. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41881
[Bug c++/45254] New: data declaration parse error
$cat main.cc && g++ -v && g++ -o m main.cc
#include
#include
#include
#include
using namespace std;
struct record
{
int date;
int key[5];
};
std::istream&
operator >> ( std::istream& lhs, record& rhs )
{
lhs >> rhs.date;
lhs >> rhs.key[0];
lhs >> rhs.key[1];
lhs >> rhs.key[2];
lhs >> rhs.key[3];
lhs >> rhs.key[4];
return lhs;
}
std::ostream&
operator << ( std::ostream& lhs, const record& rhs )
{
lhs << rhs.date << "\n";
lhs << "\t" << rhs.key[0] << "\n";
lhs << "\t" << rhs.key[1] << "\n";
lhs << "\t" << rhs.key[2] << "\n";
lhs << "\t" << rhs.key[3] << "\n";
lhs << "\t" << rhs.key[4] << "\n";
return lhs;
}
int main()
{
copy( (istream_iterator(cin)),
(istream_iterator()),
(ostream_iterator((ofstream("record.dat",
ios::out)), "\n"))
);
//istream_iterator r1(cin);
//istream_iterator rn;
//ofstream o("record.dat", ios::out);
//ostream_iterator o1(o, "\n");
//copy( r1, rn, o1 );
return 0;
}
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr
--enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib
--disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info
Thread model: posix
gcc version 4.5.0 20100610 (prerelease) (GCC)
main.cc: In function ¡®int main()¡¯:
main.cc:44:70: error: no matching function for call to
¡®std::ostream_iterator::ostream_iterator(std::ofstream, const char
[2])¡¯
/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stream_iterator.h:185:7:
note: candidates are: std::ostream_iterator<_Tp, _CharT,
_Traits>::ostream_iterator(const std::ostream_iterator<_Tp, _CharT, _Traits>&)
[with _Tp = record, _CharT = char, _Traits = std::char_traits,
std::ostream_iterator<_Tp, _CharT, _Traits> = std::ostream_iterator]
/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stream_iterator.h:181:7:
note: std::ostream_iterator<_Tp, _CharT,
_Traits>::ostream_iterator(std::ostream_iterator<_Tp, _CharT,
_Traits>::ostream_type&, const _CharT*) [with _Tp = record, _CharT = char,
_Traits = std::char_traits, std::ostream_iterator<_Tp, _CharT,
_Traits>::ostream_type = std::basic_ostream]
/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stream_iterator.h:169:7:
note: std::ostream_iterator<_Tp, _CharT,
_Traits>::ostream_iterator(std::ostream_iterator<_Tp, _CharT,
_Traits>::ostream_type&) [with _Tp = record, _CharT = char, _Traits =
std::char_traits, std::ostream_iterator<_Tp, _CharT,
_Traits>::ostream_type = std::basic_ostream]
--
Summary: data declaration parse error
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wanng dot fenng at gmail dot com
GCC build triplet: ../configure --prefix=/usr --enable-
languages=c,c++,fortran,obj
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45254
[Bug tree-optimization/45255] New: [4.6 regression] internal compiler error: verify_stmts failed with -fwhopr
Using built-in specs. COLLECT_GCC=i686-pc-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ./configure --prefix=/usr --enable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --target=i686-pc-mingw32 --enable-shared --enable-interpreter --disable-sjlj-exceptions Thread model: win32 gcc version 4.6.0 20100811 (experimental) (GCC) COLLECT_GCC_OPTIONS='-fwhopr' '-v' '-mtune=generic' '-march=pentiumpro' /usr/libexec/gcc/i686-pc-mingw32/4.6.0/cc1.exe -quiet -v memrefimp.c -quiet -dumpbase memrefimp.c -mtune=generic -march=pentiumpro -auxbase memrefimp -version -fwhopr -o /cygdrive/d/temp/cache/cc4ZWTyf.s GNU C (GCC) version 4.6.0 20100811 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.6.0 20100801 (experimental), GMP version 5.0.0, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/sys-include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-pc-mingw32/4.6.0/include /usr/lib/gcc/i686-pc-mingw32/4.6.0/include-fixed /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/include End of search list. GNU C (GCC) version 4.6.0 20100811 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.6.0 20100801 (experimental), GMP version 5.0.0, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 9a889a1670479f5d154f4d8fce5782ed COLLECT_GCC_OPTIONS='-fwhopr' '-v' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/bin/as.exe -o /cygdrive/d/temp/cache/cctnwsqQ.o /cygdrive/d/temp/cache/cc4ZWTyf.s COMPILER_PATH=/usr/libexec/gcc/i686-pc-mingw32/4.6.0/:/usr/libexec/gcc/i686-pc-mingw32/4.6.0/:/usr/libexec/gcc/i686-pc-mingw32/:/usr/lib/gcc/i686-pc-mingw32/4.6.0/:/usr/lib/gcc/i686-pc-mingw32/:/usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/bin/ LIBRARY_PATH=/usr/lib/gcc/i686-pc-mingw32/4.6.0/:/usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/lib/ COLLECT_GCC_OPTIONS='-fwhopr' '-v' '-mtune=generic' '-march=pentiumpro' /usr/libexec/gcc/i686-pc-mingw32/4.6.0/collect2.exe -fwhopr -Bdynamic /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/lib/crt2.o /usr/lib/gcc/i686-pc-mingw32/4.6.0/crtbegin.o -L/usr/lib/gcc/i686-pc-mingw32/4.6.0 -L/usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/lib /cygdrive/d/temp/cache/cctnwsqQ.o -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i686-pc-mingw32/4.6.0/crtend.o collect2 version 4.6.0 20100811 (experimental) (x86 MinGW) /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/bin/ld -Bdynamic /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/lib/crt2.o /usr/lib/gcc/i686-pc-mingw32/4.6.0/crtbegin.o -L/usr/lib/gcc/i686-pc-mingw32/4.6.0 -L/usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/lib /cygdrive/d/temp/cache/cctnwsqQ.o -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i686-pc-mingw32/4.6.0/crtend.o /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/bin/nm -n /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/lib/crt2.o /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/bin/nm -n /usr/lib/gcc/i686-pc-mingw32/4.6.0/crtbegin.o /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/bin/nm -n /cygdrive/d/temp/cache/cctnwsqQ.o /usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/bin/nm -n /usr/lib/gcc/i686-pc-mingw32/4.6.0/crtend.o /usr/libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe /cygdrive/d/temp/cache/cctnwsqQ.o i686-pc-mingw32-gcc @/cygdrive/d/temp/cache/ccxQFBDB.args Using built-in specs. COLLECT_GCC=i686-pc-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ./configure --prefix=/usr --enable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --target=i686-pc-mingw32 --enable-shared --enable-interpreter --disable-sjlj-exceptions Thread model: win32 gcc version 4.6.0 20100811 (experimental) (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=pentiumpro' '-fltrans-output-list=/cygdrive/d/temp/cache/ccCFAe8S.ltrans.out' '-fwpa' '-comb
[Bug tree-optimization/45255] [4.6 regression] internal compiler error: verify_stmts failed with -fwhopr
--- Comment #1 from jojelino at gmail dot com 2010-08-11 09:57 --- Created an attachment (id=21451) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21451&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45255
[Bug tree-optimization/45255] [4.6 regression] internal compiler error: verify_stmts failed with -fwhopr
--- Comment #2 from jojelino at gmail dot com 2010-08-11 09:59 ---
(In reply to comment #1)
> Created an attachment (id=21451)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21451&action=view) [edit]
> testcase
>
and it is resolved by changing __attribute__ ((dllimport)) to __attribute__
((visibility("default")))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45255
[Bug c++/45254] data declaration parse error
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 10:03 --- This is plain invalid: you are constructing a temporary ofstream and then hoping to pass it to a constructor taking a ref, not a const ref, cannot work. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet| ../configure --prefix=/usr |../configure --prefix=/usr - |--enable- |-enable- |languages=c,c++,fortran,obj |languages=c,c++,fortran,obj Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45254
[Bug tree-optimization/45255] [4.6 regression] internal compiler error: verify_stmts failed with -fwhopr
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-11 10:17 --- WHOPR involved, MEM_REF involved... Richi? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45255
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #20 from iains at gcc dot gnu dot org 2010-08-11 10:21 --- also on i686-darwin9, closing as fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug tree-optimization/44137] [4.6 Regression]: objc.dg/torture/tls/thr-init-2.m and thr-init.m
--- Comment #4 from iains at gcc dot gnu dot org 2010-08-11 10:22 --- AFAICT from testing on cris-elf Xd from i686-darwin9 this is fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44137
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #13 from iains at gcc dot gnu dot org 2010-08-11 10:23 --- AFAICT, from testing on cris-elf Xf from i686-darwin9 this is fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug tree-optimization/41881] [4.5/4.6 regression] Complete unrolling (inner) versus vectorization of reduction
--- Comment #7 from irar at il dot ibm dot com 2010-08-11 10:24 --- (In reply to comment #6) > I think that SLP doesn't handle reduction. > Not all kinds of reduction. We handle #a1 = phi #b1 = phi ... a2 = a1 + x b2 = b1 + y Here we also have: #a1 = phi ... a2 = a1 + x ... a3 = a2 + y ... a9 = a8 + z -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41881
[Bug fortran/44595] INTENT of arguments to intrinsic procedures not checked
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-11 10:50 --- Subject: Bug 44595 Author: janus Date: Wed Aug 11 10:49:56 2010 New Revision: 163096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163096 Log: 2010-08-11 Janus Weil PR fortran/44595 * intrinsic.c (gfc_current_intrinsic_arg): Change type from 'char' to 'gfc_intrinsic_arg'. (check_arglist,check_specific): Add reference to 'name' field. (init_arglist): Remove reference to 'name' field. * intrinsic.h (gfc_current_intrinsic_arg): Modify prototype. * check.c (variable_check): Reverse order of checks. Respect intent of formal arg. (int_or_proc_check): New function. (coarray_check): New function. (allocatable_check): New function. (gfc_check_allocated,gfc_check_move_alloc): Use 'allocatable_check'. (gfc_check_complex): Use 'int_or_real_check'. (gfc_check_lcobound,gfc_check_image_index,gfc_check_this_image, gfc_check_ucobound): Use 'coarray_check'. (gfc_check_pack): Use 'real_or_complex_check'. (gfc_check_alarm_sub,gfc_check_signal,gfc_check_signal_sub): Use 'int_or_proc_check'. (scalar_check,type_check,numeric_check,int_or_real_check, real_or_complex_check,kind_check,double_check,logical_array_check, array_check,same_type_check,rank_check,nonoptional_check, kind_value_check,gfc_check_a_p,gfc_check_associated,gfc_check_cmplx, gfc_check_cshift,gfc_check_dcmplx,gfc_check_dot_product,gfc_check_dprod, gfc_check_eoshift,gfc_check_fn_rc2008,gfc_check_index,gfc_check_kind, gfc_check_matmul,gfc_check_minloc_maxloc,check_reduction,gfc_check_null, gfc_check_present,gfc_check_reshape,gfc_check_same_type_as, gfc_check_spread,gfc_check_unpack,gfc_check_random_seed, gfc_check_getarg,gfc_check_and,gfc_check_storage_size): Add reference to 'name' field. 2010-08-11 Janus Weil Steve Kargl PR fortran/44595 * gfortran.dg/move_alloc_3.f90: New. * gfortran.dg/random_seed_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/move_alloc_3.f90 trunk/gcc/testsuite/gfortran.dg/random_seed_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44595
[Bug bootstrap/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
--- Comment #8 from dv at vollmann dot ch 2010-08-11 10:56 --- Subject: Re: libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc @Ian: > I'm surprised that it doesn't work, as libgcc/config/rs6000/t-ppccomm includes > crtsavgpr.S and crtresgpr.S in LIB2ADD_ST. I would expect that to include the > required functions. Maybe the problem is that the functions are only referenced if you use -Os. So if there's some automatism going on that collects all the required symbols, this automatism needs to use -Os for target-optspace. But I have no real idea how the build process works, so this is just guessing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
[Bug tree-optimization/45255] [4.6 regression] internal compiler error: verify_stmts failed with -fwhopr
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-11 10:59 ---
Well. I do not have access to i686-pc-mingw32-gcc and this seems related to
/* Return whether OP is a DECL whose address is function-invariant. */
bool
decl_address_invariant_p (const_tree op)
{
/* The conditions below are slightly less strict than the one in
staticp. */
...
case VAR_DECL:
if (((TREE_STATIC (op) || DECL_EXTERNAL (op))
&& !DECL_DLLIMPORT_P (op))
|| DECL_THREAD_LOCAL_P (op)
|| DECL_CONTEXT (op) == current_function_decl
|| decl_function_context (op) == current_function_decl)
return true;
break;
WTF !DECL_DLLIMPORT_P (op)!? (also noticed by rth recently)
A fix is to remove that check here, but I can't test that.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45255
[Bug fortran/44595] INTENT of arguments to intrinsic procedures not checked
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-11 11:01 --- Fixed with r163096. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44595
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #12 from rogerio at rilhas dot com 2010-08-11 11:20 --- Created an attachment (id=21452) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21452&action=view) Preprocessed file (with example 2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #13 from rogerio at rilhas dot com 2010-08-11 11:21 --- Created an attachment (id=21453) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21453&action=view) Source file (example 2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #14 from rogerio at rilhas dot com 2010-08-11 11:22 ---
No, you are not correct. The equivalent code to what I'm doing would be
something like:
int buffer[4]; // 16 bytes on stack
buffer[0]=(int)&format
buffer[1]=(int)10
buffer[2]=(int)&another_string
buffer[3]=(int)20
call format_direct
format_direct:
char** PTR4=(char**)&buffer[0];
push PTR4
call format_indirect
format_indirect:
char** PTR4=get_from_stack // gets PTR4 as pushed in format_direct
printf("%s %d %s %d",
PTR4[0], // the same as (char*)buffer[0]
PTR4[1], // the same as (int)buffer[1]
PTR4[2], // the same as (char*)buffer[2]
PTR4[3] // the same as (int)buffer[3]
);
This code must work, obviously. There is no undefined behaviour, it is correct
and portable code, and well defined and established. Even if the machine is 16
bits this would work without changes, just replace comment "16 bytes" by "8
bytes" and name PTR4 to PTR2, if you like the cosmetic changes.
I understand that when you look at your code you would call it undefined
behaviour, but your code is not the correct one: this one is. That is what I've
been trying to explain. The calling convention states that the parameters
should be packed ajdacent, like I did in the struct above, and not as you did
in your example, and getting the address of the parameter should get the
address of the start of the buffer, as I did manually.
Your code just ignored this and, of course, would not work (you don't even say
where you think the other parameters are). This is not an invention of mine, or
something that only works when I'm lucky, packing all parameters adjacent to
each other is something the compiler really needs to do, so if it gives me the
correct address of the first parameter then this code works *always* and is
very portable.
To show you that you are not correct I've done some changes to the source file,
where I created a new function "format_direct2" that does something like this:
void format_direct2(char* dst_buffer, int dst_buffer_size_bytes, const char*
format, ...) {
int buffer[3];
buffer[0]=(int)format;
buffer[1]=(int)__DATE__;
buffer[2]=(int)__TIME__;
format_indirect(dst_buffer, dst_buffer_size_bytes, (const
char**)&buffer[0]);
}
The new code works always, of course, since I'm the one ensuring that the
parameters are adjacent, and I'm the one selecting the correct address to pass
to "format_indirect". I am, in fact, manually generating the 2 requirements -
compliance with the calling convention and passing the correct address to
"format_indirect". It also works with GCC, of course, even when optimized (as
expected) and I attach the corresponding files. So, when optimized, you get
"format_direct2" to work correctly and "format_direct" causes a segmentation
fault (and it shouldn't).
It would sure be interesting to see if you could quote some standard for C
which says that I'm not allowed to do this!!! I simply don't believe you can
find such text, or have I been wrong about C all my life and I can't use
pointers to navigate through buffers?? :-)
--
rogerio at rilhas dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-08-11 11:37
---
(In reply to comment #14)
> No, you are not correct. The equivalent code to what I'm doing would be
> something like:
>
> int buffer[4]; // 16 bytes on stack
> buffer[0]=(int)&format
> buffer[1]=(int)10
> buffer[2]=(int)&another_string
> buffer[3]=(int)20
> call format_direct
>
> format_direct:
> char** PTR4=(char**)&buffer[0];
> push PTR4
> call format_indirect
>
> format_indirect:
> char** PTR4=get_from_stack // gets PTR4 as pushed in format_direct
> printf("%s %d %s %d",
> PTR4[0], // the same as (char*)buffer[0]
> PTR4[1], // the same as (int)buffer[1]
> PTR4[2], // the same as (char*)buffer[2]
> PTR4[3] // the same as (int)buffer[3]
> );
>
> This code must work, obviously. There is no undefined behaviour, it is correct
> and portable code, and well defined and established. Even if the machine is 16
> bits this would work without changes, just replace comment "16 bytes" by "8
> bytes" and name PTR4 to PTR2, if you like the cosmetic changes.
>
> I understand that when you look at your code you would call it undefined
> behaviour, but your code is not the correct one: this one is. That is what
> I've
> been trying to explain. The calling convention states that the parameters
> should be packed ajdacent, like I did in the struct above, and not as you did
> in your example, and getting the address of the parameter should get the
> address of the start of the buffer, as I did manually.
>
> Your code just ignored this and, of course, would not work (you don't even say
> where you think the other parameters are). This is not an invention of mine,
> or
> something that only works when I'm lucky, packing all parameters adjacent to
> each other is something the compiler really needs to do, so if it gives me the
> correct address of the first parameter then this code works *always* and is
> very portable.
>
> To show you that you are not correct I've done some changes to the source
> file,
> where I created a new function "format_direct2" that does something like this:
>
> void format_direct2(char* dst_buffer, int dst_buffer_size_bytes, const char*
> format, ...) {
> int buffer[3];
> buffer[0]=(int)format;
> buffer[1]=(int)__DATE__;
> buffer[2]=(int)__TIME__;
> format_indirect(dst_buffer, dst_buffer_size_bytes, (const
> char**)&buffer[0]);
> }
>
> The new code works always, of course, since I'm the one ensuring that the
> parameters are adjacent, and I'm the one selecting the correct address to pass
> to "format_indirect". I am, in fact, manually generating the 2 requirements -
> compliance with the calling convention and passing the correct address to
> "format_indirect". It also works with GCC, of course, even when optimized (as
> expected) and I attach the corresponding files. So, when optimized, you get
> "format_direct2" to work correctly and "format_direct" causes a segmentation
> fault (and it shouldn't).
>
> It would sure be interesting to see if you could quote some standard for C
> which says that I'm not allowed to do this!!! I simply don't believe you can
> find such text, or have I been wrong about C all my life and I can't use
> pointers to navigate through buffers?? :-)
In the C language these implementation details are not exposed and thus
not accessible. Hence your code invokes undefined behavior as you are
trying to circumvent this impossibility.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-08-11 11:41 --- Btw, just use vsnprintf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #17 from redi at gcc dot gnu dot org 2010-08-11 11:55 --- As already stated, what you are doing is not valid C or C++, the standards do not guarantee the behaviour you are expecting w.r.t stack layout, and an optimising C or C++ compiler follows the rules of the language standard. If you want to rely on your assumptions write assembler or do not enable optimisation. (In reply to comment #13) > Created an attachment (id=21453) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21453&action=view) [edit] > Source file (example 2) > // linux (cannot use stdarg because this function does not take variable > parameters and > // so the compiler generates an error (shouldn't it be a warning?). Have you checked how va_start is defined? void va_start(va_list ap, parmN); ... The parameter parmN is the identifier of the rightmost parameter in the variable parameter list in the function definition (the one just before the , ...). You use *format_address as parmN, which is not an identifier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #3 from pj dot pandit at yahoo dot co dot in 2010-08-11 12:15 --- DW_AT_external is meant to indicate whether a variable/function, that is defined in the compilation unit, is accessible/visible from the outside of it or not. It's a subtle difference between `accessible from' and `accessed from' outside. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #44 from iains at gcc dot gnu dot org 2010-08-11 12:32 --- I do not think the current solution is complete/correct. For 4.5.x and current trunk we still have a significant problem. (4.4.x apparently still works, as of 4.4.5/r163091, at least for trivial cases) [apollo is i686-darwin9 with r163091 bootstrapped and installed; CWD=build-top-level]. apollo:gcc-4-5-branch-build$ /GCC/gcc-4-5-install/bin/gcj-4.5 ../tests/HelloWorld.java --main=HelloWorld -o hw gcj-4.5: Internal error: Abort trap (program ecj1): FAILS apollo:gcc-4-5-branch-build$ DYLD_LIBRARY_PATH=gcc /GCC/gcc-4-5-install/bin/gcj-4.5 ../tests/HelloWorld.java --main=HelloWorld -o hw . OK - builds... try to invoke the generated exe: apollo:gcc-4-5-branch-build./hw ... a long wait ... (on powerpc-darwin9 .. you get some interesting error messages about repeated allocation of 1Gb memory chunks :/). Abort trap apollo:gcc-4-5-branch-build$ DYLD_LIBRARY_PATH=gcc ./hw Hello, World Incidentally, this applies equally if one starts from HelloWorld.class It seems to me that we have some dependancy issue that is causing libgcj to link (some) symbols from /libgcc_s.1dylib that should really be linked from /usr/lib/libgcc_s.1.dylib - i.e. the unwinder is being invoked in two different libs :( see = 4.6-trunk behaves the same on Darwin9, I've not tried Darwin10 (for reasons which should be evident below). = Taking the case of Darwin9/OSX 10.5: (a) the code for _Unwind_FindEnclosingFunction &c. as posted on http://www.opensource.apple.com/release/mac-os-x-1058/ is the same as fsf-gcc (AFAICT from browsing it online) -- so I'm not sure why we added in the darwin10_Unwind_FindEnclosingFunction (it's the same code as already present in the system lib). [having said that, even if the system code _is_ broken and unusable, (b) applies. and one needs to work around the breakage without bypassing said system code] (b) As the design(s) stand, we can only have one unwinder.. the choices are: 1/ to use the system one in which case you can integrate your code with system-supplied libraries [which is what, I suspect, the majority of users want] 2/ You can replace the system unwinder with the one in /libgcc_s.1.dylib - in which case you must point DYLD to that before invoking any code generated by gcj (including the compiler itself). That code cannot use _any_ system facilities that might require the unwinder. (ergo, the test-suite passes, but one can't build a general application using arbitrary system facilities). it seems we have (2) at present, and I wonder how useful that is to the majority of end users? (I guess there is also option (3) -> overwrite the system libgcc_s with the one .. but, if you do that, then you must take responsibility for any other system breakage or security issues you cause ... not a route I'd recommend for most end-users ;)). = Incidentally, this is the whole reason we implemented the libgcc_ext.dylib --- so that extensions to gcc (like emutls) could be applied to OSX without interfering with the unwinder ;) .. and that is the reason that both /usr/lib/libgccs.1.dylib _and_ /libgcc_s.1.dylib are linked into darwin executables, (taking advantage of the different namespaces). However, in this case, if I regress the darwin10_Unwind_FindEnclosingFunction change out, the code still fails - which indicates to me that: (i) somewhere else in the build of libgcj or the classpath there is a dependency on some part of the unwinder that is being satisfied by a link from /libgcc_s.1dylib (although a look at the Makefile didn't show anything obvious, perhaps someone more familiar with libjava would be able to spot it?). (ii) or.. that there's a bug/incompatibility between the system unwinder & fsf gcc that we haven't worked around. in the case of (ii) the endgame is much the same as for darwin 10 = For Darwin10/OSX10.6 (a) I'm not sure that the current libjava design applies; it seems that the relevant routines might have been replaced by no-ops (from comments posted elsewhere, and a quick check of otool -tv -p _Unwind_FindEnclosingFunction). I.E the unwinder has changed to a different implementation.. However, as for darwin9, (b) applies - one can "replace" the system unwinder with the one in libgcc - but, again, that means the user will be limited to self-contained code. = If no-one has time to implement an integration of libjava with the Darwin 10 unwinders [and/or fix the breakage with Darwin9] (I don't, sorry), then essentially gcj > 4.5 is unusable on current Darwin in any other manner than stand-alone (and, frankly, I wonder how generally useful that is?). -- iains at gcc dot gnu dot org changed: What|Removed |Added CC|
[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-08-11 12:33 --- We can also expand __builtin_memcpy (&local, ¶m, 9); to multiple copies based on src/dest alignment and size (similar to store_by_pieces) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13954
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-11 12:46 --- I don't see the standard saying that anywhere. "A DW_AT_external attribute, which is a flag, if the name of a variable is visible outside of its enclosing compilation unit." "If the name of the subroutine described by an entry with the tag DW_TAG_subprogram is visible outside of its containing compilation unit, that entry has a DW_AT_external attribute, which is a flag." Nothing says that the variable/function has to be defined in that compilation unit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug c++/45254] data declaration parse error
--- Comment #2 from wanng dot fenng at gmail dot com 2010-08-11 12:49 --- Subject: Re: data declaration parse error On 08/11/2010 06:03 PM, paolo dot carlini at oracle dot com wrote: > --- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 10:03 > --- > This is plain invalid: you are constructing a temporary ofstream and then > hoping to pass it to a constructor taking a ref, not a const ref, cannot work. Thank you Carlini for your quick reply, I just read the c++ standard and confirmed this is not a bug. It just confused me when some other one who are using M$ vc telling me this way works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45254
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #45 from andreast at gcc dot gnu dot org 2010-08-11 12:50 --- I no longer have time to work on this. -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|andreast 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=41991
[Bug c/44555] [4.3 Regression] Pointer evalutions, is that expected ?
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-08-11 13:00 --- Subject: Bug 44555 Author: rguenth Date: Wed Aug 11 12:59:47 2010 New Revision: 163098 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163098 Log: 2010-08-11 Richard Guenther PR c/44555 * c-common.c (c_common_truthvalue_conversion): Remove premature and wrong optimization concering ADDR_EXPRs. * gcc.c-torture/execute/pr44555.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr44555.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-common.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44555
[Bug c/44555] [4.3 Regression] Pointer evalutions, is that expected ?
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-08-11 13:00 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|3.3.3 4.4.5 4.5.1 4.6.0 |3.3.3 4.3.6 4.4.5 4.5.1 ||4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44555
gcc-bugs@gcc.gnu.org
--- Comment #2 from jason at gcc dot gnu dot org 2010-08-11 13:06 --- This result, while unfortunate, is not a bug; template argument deduction only uses the type and lvalueness of the function argument (unsigned, lvalue) and therefore deduces the type of __x to be unsigned&. But an reference cannot bind to a bitfield, so the call is ill-formed. You can work around this issue by using the unary + to make the argument an rvalue: std::make_pair ( + X::s.addr, true ); -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45253
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #18 from rogerio at rilhas dot com 2010-08-11 13:11 --- Of course vsnprintf was my first choice, as you can see from the WIN32 part of the code I sent you. In WIN32 I can use vsnprint in a very natural and predictable way in "format_indirect". In LINUX this cannot be used in "format_indirect" as GCC does not allow me to use vsnprintf on a function that doesn't take variable parameters. I tried to bypass it specifying variable parameters for "format_indirect", but of course the results are wrong because GCC will have placed the wrong address in "format_address" inside "format_indirect". So, in fact, vsnprintf will have exactly the same problem as I had, and I would report exactly the same bug like I did. As you can see I've tried very hard to explain all details of the problem, and why this is a bug in GCC. You just keep dismissing all my arguments without any justification whatsoever. When you did justify I just proved your arguments to be false (no disrespect intended) in the hope that this conversation would progress. You don't explain why I can't rely on the calling convention to ensure the parameters will be adjacent, and you don't explain why I can't use &format to get the address of that packed data on the stack. You just keep invoking some standard where these 2 things are alledgedly not defined but without materializing it (which I don't believe you can anyway!). You have not yet shown why GCC is not required to place the parameters correctly on the stack, and why GCC does not need to give me the true &format. So I'm stuck with your "you can't because you can't" replies and this conversation will not progress any further, of course. Best regards, Rogerio -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #46 from howarth at nitro dot med dot uc dot edu 2010-08-11 13:14 --- (In reply to comment #44) > I do not think the current solution is complete/correct. Don't confuse the darwin9 and darwin10 unwinder issues. They are different incompatiibilities with the darwin unwinder. Also keep in mind that darwin9 uses an unwinder derived from libgcc whereas darwin10 uses a compatibility unwinder from libSystem. > Taking the case of Darwin9/OSX 10.5: > > (a) the code for _Unwind_FindEnclosingFunction &c. as posted on > http://www.opensource.apple.com/release/mac-os-x-1058/ is the same as fsf-gcc > (AFAICT from browsing it online) -- so I'm not sure why we added in the > darwin10_Unwind_FindEnclosingFunction (it's the same code as already present > in > the system lib). [having said that, even if the system code _is_ broken and > unusable, (b) applies. and one needs to work around the breakage without > bypassing said system code] > Read http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00998.html which explains the logic of re-exporting _Unwind_FindEnclosingFunction() under a different name for darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-11 13:15 --- Subject: Re: [4.6 Regression]: gcc.dg/tls/alias-1.c > AFAICT, from testing on cris-elf Xf from i686-darwin9 this is fixed. It also appears fixed on hppa64-hp-hpux11.11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2010-08-11 13:42 --- Also from a the darwin unwinder maintainer... > I took a look at the bug report you made. Right off, I can tell that > the problem is that _Unwind_FindEnclosingFunction() is not > implemented. Well, it is implemented as a not_implemented macro... > It is an FSF extension and has some semantics that can't be supported. ... > _Unwind_Find_FDE is implemented on 10.6. > > The general issue is that on 10.6 and later the dwarf unwind info may > not exist. It may be replaced (by the linker tool) with compact > unwind info. So any function that assumes FDEs exist may not work. This is the reason that the _Unwind_FindEnclosingFunction() call is re-exported under a different name in libgcc_ext. This call requires _Unwind_Find_FDE and has been replaced with a not_implemented macro which silently aborts. A radar is open to have the gross use of not_implemented macros replaced with a check if -no-compact-unwind is in use. In that case, the compatibility unwinder in libSystem (which supports FDEs) would be in use and those calls could be made functional again. Note that this all stems from the fact that darwin10 has the compact unwind code generation as the default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #19 from redi at gcc dot gnu dot org 2010-08-11 14:10 ---
(In reply to comment #18)
> Of course vsnprintf was my first choice, as you can see from the WIN32 part of
> the code I sent you. In WIN32 I can use vsnprint in a very natural and
> predictable way in "format_indirect". In LINUX this cannot be used in
It's Linux (or GNU/Linux) not LINUX.
> "format_indirect" as GCC does not allow me to use vsnprintf on a function that
> doesn't take variable parameters.
I explained why, see 7.15 in the C99 standard.
> I tried to bypass it specifying variable
> parameters for "format_indirect", but of course the results are wrong because
> GCC will have placed the wrong address in "format_address" inside
> "format_indirect". So, in fact, vsnprintf will have exactly the same problem
> as
> I had, and I would report exactly the same bug like I did.
Not if you use it correctly, which you are not doing.
void format_direct3(char* dst_buffer, int dst_buffer_size_bytes, const char*
format, ...) {
va_list va;
va_start(va, format);
vsnprintf(dst_buffer, dst_buffer_size_bytes, format, va);
va_end(va);
}
> As you can see I've tried very hard to explain all details of the problem,
> and
> why this is a bug in GCC.
GCC claims to support C and C++. Can you point to part of either standard
which says your code is valid?
> You just keep dismissing all my arguments without any justification
> whatsoever.
What you're doing is not defined by the C or C++ standard.
GCC is a C and C++ compiler. Can you show where in the C or C++ standards it
says the stack must be laid out as you want?
> When you did justify I just proved your arguments to be false (no disrespect
> intended) in the hope that this conversation would progress.
>
> You don't explain why I can't rely on the calling convention to ensure the
> parameters will be adjacent,
Because the C and C++ standards do not make any guarantees about layout of
arguments in memory, so when using a C or C++ compiler to compile C or C++ code
you should not assume any particular layout.
> and you don't explain why I can't use &format to
> get the address of that packed data on the stack. You just keep invoking some
> standard where these 2 things are alledgedly not defined but without
> materializing it (which I don't believe you can anyway!). You have not yet
> shown why GCC is not required to place the parameters correctly on the stack,
> and why GCC does not need to give me the true &format.
The standard does not define how arguments are laid out, therefore it is
undefined.
> So I'm stuck with your "you can't because you can't" replies and this
> conversation will not progress any further, of course.
The onus is on you to show where in the C standard it says that your code is
well defined. If the standard doesn't say it, it's not portable and not well
defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug tree-optimization/45256] New: Missed arithmetic simplification at tree level
I'll attach a testcase, which shows a missed simplification at tree level:
D.2276_42 = i_53 + 1;
D.2277_43 = D.2276_42 * 32;
iftmp.3_55 = __fswab32 (xb_54);
__asm__("clz %0, %1" : "=r" ret_56 : "r" iftmp.3_55 : "cc");
ret_58 = 32 - ret_56;
ret_59 = D.2277_43 - ret_58;
In effect, the constant 32 is both added and subtracted from the result. With
a four-insn combiner, this is caught at the RTL stage (compiling for Thumb-1):
- add r2, r2, #1
lsl r2, r2, #5
- add r3, r3, r2
- sub r3, r3, #32
+ add r3, r2, r3
--
Summary: Missed arithmetic simplification at tree level
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45256
[Bug tree-optimization/45256] Missed arithmetic simplification at tree level
--- Comment #1 from bernds at gcc dot gnu dot org 2010-08-11 15:19 --- Created an attachment (id=21454) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21454&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45256
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #48 from howarth at nitro dot med dot uc dot edu 2010-08-11 15:23 --- These messages from the Apple developers also are useful in explaining the situation... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug c++/44172] Compiling never ends
--- Comment #6 from steven at gcc dot gnu dot org 2010-08-11 15:27 --- I don't see how the compiler can know that this input causes an infinite loop. This is just the halting problem. Not a bug in the sense that there is anything to fix. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44172
[Bug libstdc++/45257] New: struct in6_pktinfo is guarded by __USE_GNU macro
The reduced code below used to successfully compile on previous releases of
GCC. I can get this code to compile with GCC 4.1.2, but when I try it with GCC
4.3.4, I get the following error message:
a.c: In function 'main':
a.c:4: error: storage size of 'test' isn't known
Clearly, this is happening because the struct in6_pktinfo is not defined
anywhere before a variable of that type is declared. Looking into the header
file, the struct definition is guarded by a macro __USE_GNU. I have come to
understand that to get this macro defined (thus get the struct defined), one
would define the macro _GNU_SOURCE before including the GCC header files. This
way, types like the in6_pktinfo struct can be defined.
However, this is causing compiler failures for us, and it's not feasible for us
to define this macro (whether on command line, or inside source code) files.
Please take a look and see if this change is unavoidable, and whether there is
a way to reverse it.
Reduced Source Code:
#include
int main()
{
struct in6_pktinfo test;
}
--
Summary: struct in6_pktinfo is guarded by __USE_GNU macro
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: murtadha at ca dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45257
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #20 from matz at gcc dot gnu dot org 2010-08-11 16:10 ---
A conforming variant of what you probably are trying to code is:
#include
#include
void format_indirect(char* dst_buffer, size_t dst_buffer_size_bytes,
const char *format, va_list va)
{
vsnprintf(dst_buffer, dst_buffer_size_bytes, format, va);
dst_buffer[dst_buffer_size_bytes-1]=0;
}
void format_direct(char* dst_buffer, size_t dst_buffer_size_bytes,
const char* format, ...)
{
va_list va;
va_start (va, format);
format_indirect(dst_buffer, dst_buffer_size_bytes, format, va);
va_end (va);
}
int main(void)
{
char buffer[1000];
format_direct((char*)buffer, sizeof(buffer), "%s %s", __DATE__, __TIME__);
printf("Result: \"%s\"\n", buffer);
return 0;
}
---
Note how the va_list is constructed in the function that actually is
a varargs one, in particular how the necessary parameter is mentioned.
Note further how that va_list is passsed to the function that is not
varargs in order to capture all variable arguments of its caller.
There, no assumption on stack-layout. It will work with all types and
ABIs, even those that happen to pass even some varargs in registers,
not on the stack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug libstdc++/45257] struct in6_pktinfo is guarded by __USE_GNU macro
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-11 16:11 --- This has nothing to do with GCC, netinet/in.h is a glibc header, not GCC header. And the guarding of that type with __USE_GNU is intentional AFAIK. Just use -D_GNU_SOURCE. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45257
[Bug target/45258] New: linkage on -lm and -lpthread should be purged from darwin build
Currently libjava is being improperly linked (PR java/41991) due to the presence of -lm and -lpthreads on the shared library linkages. This causes libSystem.dylib to be pushed to the front of the linkage and breaks the logic used by libgcc_ext. We should add and set defines for HAVE_LIBSYSTEM_PTHREADS and HAVE_LIBSYSTEM_LIBMATH to configure and use these for conditionals in the Makefile.am's where appropriate to avoid passing -lm and -lpthread on darwin. -- Summary: linkage on -lm and -lpthread should be purged from darwin build Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258
Re: [Bug target/45258] New: linkage on -lm and -lpthread should be purged from darwin build
What about removing those in the driver? This way it works correctly for other makefiles too? On Aug 11, 2010, at 9:30 AM, "howarth at nitro dot med dot uc dot edu" wrote: Currently libjava is being improperly linked (PR java/41991) due to the presence of -lm and -lpthreads on the shared library linkages. This causes libSystem.dylib to be pushed to the front of the linkage and breaks the logic used by libgcc_ext. We should add and set defines for HAVE_LIBSYSTEM_PTHREADS and HAVE_LIBSYSTEM_LIBMATH to configure and use these for conditionals in the Makefile.am's where appropriate to avoid passing -lm and -lpthread on darwin. -- Summary: linkage on -lm and -lpthread should be purged from darwin build Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258
[Bug target/45258] linkage on -lm and -lpthread should be purged from darwin build
--- Comment #1 from pinskia at gmail dot com 2010-08-11 17:03 --- Subject: Re: New: linkage on -lm and -lpthread should be purged from darwin build What about removing those in the driver? This way it works correctly for other makefiles too? On Aug 11, 2010, at 9:30 AM, "howarth at nitro dot med dot uc dot edu" wrote: > Currently libjava is being improperly linked (PR java/41991) due to > the > presence of -lm and -lpthreads on the shared library linkages. This > causes > libSystem.dylib to be pushed to the front of the linkage and breaks > the logic > used by libgcc_ext. We should add and set defines for > HAVE_LIBSYSTEM_PTHREADS > and HAVE_LIBSYSTEM_LIBMATH to configure and use these for > conditionals in the > Makefile.am's where appropriate to avoid passing -lm and -lpthread > on darwin. > > > -- > Summary: linkage on -lm and -lpthread should be purged from >darwin build > Product: gcc > Version: 4.6.0 >Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: target >AssignedTo: unassigned at gcc dot gnu dot org >ReportedBy: howarth at nitro dot med dot uc dot edu > GCC build triplet: *-apple-darwin* > GCC host triplet: *-apple-darwin* > GCC target triplet: *-apple-darwin* > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #21 from rogerio at rilhas dot com 2010-08-11 17:04 ---
Subject: Re: Indirect variable parameters sometimes cause
segmentation fault
Yes, I was using that solution up to 2003, but then I stopped
using it in favour of the more confortable &format (the one I
showed you) because it is less error-prone and easier to automate
(no need for the va_list declaration, start, and end). My teams
usually have a lot of rookies (we have schollarship programs)
and bugs would popup a lot (like switching the order of
parameters, for example).
I could go back to using it, of course, but I already have a lot
of code done with this &format method, and it is not convenient
for me to go back and change anything in old code.
Anyway, I seem to have found a workaround for this problem
in GCC: it seems that if I use the &format before calling the
format_indirect then there will be no problem (still to conform).
void format_direct(char* dst_buffer, int dst_buffer_size_bytes, const
char* format, ...) {
const char** format_address=&format;
format_indirect(dst_buffer, dst_buffer_size_bytes, format_address);
}
If I confirm this then this problem would no longer be blocking
and I would be able to live with it by creating a special macro
in Linux to use the &format before calling format_indirect:
#define GCC_SPECIFIC_ADDRESS_OF(format) const char** format_address(&format)
void format_direct(char* dst_buffer, int dst_buffer_size_bytes, const
char* format, ...) {
format_indirect(dst_buffer, dst_buffer_size_bytes,
GCC_SPECIFIC_ADDRESS_OF(format));
}
... or something along these lines. Maybe I should also replace const
char** by some other GCC-specificy defined type (that would have
no effect on Windows) just to get compilation errors where people try
to pass &format directly whitout using the macro.
matz at gcc dot gnu dot org wrote:
> --- Comment #20 from matz at gcc dot gnu dot org 2010-08-11 16:10 ---
> A conforming variant of what you probably are trying to code is:
>
> #include
> #include
>
> void format_indirect(char* dst_buffer, size_t dst_buffer_size_bytes,
> const char *format, va_list va)
> {
> vsnprintf(dst_buffer, dst_buffer_size_bytes, format, va);
> dst_buffer[dst_buffer_size_bytes-1]=0;
> }
>
> void format_direct(char* dst_buffer, size_t dst_buffer_size_bytes,
>const char* format, ...)
> {
> va_list va;
> va_start (va, format);
> format_indirect(dst_buffer, dst_buffer_size_bytes, format, va);
> va_end (va);
> }
>
> int main(void)
> {
> char buffer[1000];
> format_direct((char*)buffer, sizeof(buffer), "%s %s", __DATE__, __TIME__);
> printf("Result: \"%s\"\n", buffer);
> return 0;
> }
> ---
>
> Note how the va_list is constructed in the function that actually is
> a varargs one, in particular how the necessary parameter is mentioned.
> Note further how that va_list is passsed to the function that is not
> varargs in order to capture all variable arguments of its caller.
>
> There, no assumption on stack-layout. It will work with all types and
> ABIs, even those that happen to pass even some varargs in registers,
> not on the stack.
>
>
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #22 from rogerio at rilhas dot com 2010-08-11 17:15 ---
(In reply to comment #19)
> (In reply to comment #18)
> > Of course vsnprintf was my first choice, as you can see from the WIN32 part
> > of
> > the code I sent you. In WIN32 I can use vsnprint in a very natural and
> > predictable way in "format_indirect". In LINUX this cannot be used in
> It's Linux (or GNU/Linux) not LINUX.
It is probably Win32, not WIN32. But thanks for the info.
> > "format_indirect" as GCC does not allow me to use vsnprintf on a function
> > that
> > doesn't take variable parameters.
> I explained why, see 7.15 in the C99 standard.
didn't need your explanations, I already knew it. That just shows you have been
missing the point from the start. I told why I didn't use vsnprintf, but you
seem to have missed it. Note that if I didn't need format_indirect to do the
actual work then I wouldn't have found any bug in GCC.
Maybe you are not realizing that format_indirect will not actually use
vanprintf, and will, instead, use my own parsing routines for several types of
parameters. The reason why I need a format_indirect is because I may have users
of my modules who are the ones that receive the variables parameters, and must
then pass the work on to my format_indirect to do the actual work.
> > I tried to bypass it specifying variable
> > parameters for "format_indirect", but of course the results are wrong
> > because
> > GCC will have placed the wrong address in "format_address" inside
> > "format_indirect". So, in fact, vsnprintf will have exactly the same
> > problem as
> > I had, and I would report exactly the same bug like I did.
> Not if you use it correctly, which you are not doing.
> void format_direct3(char* dst_buffer, int dst_buffer_size_bytes, const char*
> format, ...) {
> va_list va;
> va_start(va, format);
> vsnprintf(dst_buffer, dst_buffer_size_bytes, format, va);
> va_end(va);
> }
You missed the point again. I don't have any problem with any of the
format_direct functions if they were to do the actual formatting work. But they
are not. Many of our older software uses specific parameter parsing, so we
developed functions over the years to parse format strings ourselves with
specific parsing instructions. To reuse code as much as possible the work is
done in a format_indirect function that can be called by any of the several
format_direct functions.
If I could use format_direct I would have no problem and the GCC bug would not
bug me at all. But that would mean copying and maintainig our special
functionality which currently resides in one format_indirect function in
several (maybe dozens) of diferent format_direct functions.
You must have noted that I used va_start/va_end in my WIN32 example, so you
must be aware that I know how to use it. You must also be aware that in the
*Linux* :-) version I used snprintf instead, so you must have realized that I
already knew that I could not use va_start/va_end in the format_indirect
function.
Microsoft's compiler developers didn't see the need to limit use of
va_start/va_end inside format_indirect, so I was able to use it without any
problem. I tried it in GCC anyway but to no avail. I understood it and moved
on, you were the one to bring vsnprintf as a solution to format_indirect which
I pointed out to you was not a solution (the GCC bug persists). However, now
you know that the actual work is not done by vsnprintf.
> > As you can see I've tried very hard to explain all details of the problem,
> > and
> > why this is a bug in GCC.
> GCC claims to support C and C++. Can you point to part of either standard
> which says your code is valid?
Yes, sure. Or, at least, I can get close enough since I'm not interested in
really making you believe that GCC would be a better product if it didn't mess
up the pair of requirements I mentioned before. I'll just leave you to believe
whatever you like.
The first thing to note is that GCC doesn't only claim to be a C/C++ compiler:
it claims it can produce cdecl calls. So I will have to go a little outside of
the scope of C99.
The GCC manual "http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc.pdf"; describes the
usage of cdecl as a possible option. Although not present in the code I sent
you I tried cdecl and stdcall specifiers and GCC didn't change anything in the
compiled code. This is the first suspicion that GCC is not conforming to what
it was supposed to do.
If GCC supports cdecl on a x86 plaform then it must support the packing of
parameters as defined for x86 (it is not standardize that I know of, but it is
well defined). I sugest reading
http://en.wikipedia.org/wiki/X86_calling_conventions for a number of references
on this parameter packing in the stack, one of my favorites is
"http://sco.com./developers/devspecs/abi386-4.pdf"; where you can read in
"Figure 3-48: C Stack Frame" how the parameters should be placed on the stack.
GCC would only be cdecl-compliant if it were to conf
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #12 from sje at cup dot hp dot com 2010-08-11 17:20 ---
I have a slightly smaller test case for this, but it still needs to bootstrap
to fail. If I bootstrap just the C part of the compiler I get a successful
build (with partial inlining enabled) but when I use that compiler to compile
this test case (with -O2) I get a segfault in the compiler:
char *s4;
test2_sub (int i, ...)
{
__builtin_va_list ap;
__builtin___vsprintf_chk (s4, 0, __builtin_object_size (s4, 0), "%s %d", ap);
}
If I modify the gimple_rewrite_call_expr call in builtins.c and replace the
call to gimple_call_num_args with a new function that I don't inline (or that I
inline completely) the segfault goes away.
Looking at some of the dump files, builtins.c.041t.fnsplit shows
gimple_call_num_args getting split but I don't see any indication of inlining
in builtins.c.015/025/043. fnsplit creates gimple_call_num_args.part.22 and
changes gimple_call_num_args to call that routine the dump doesn't show
imple_rewrite_call_expr calling part.22 but later dumps do show this. I will
attach builtins.c.041t.fnsplit.
Any help on this bug would be appreciated, IA64 HP-UX has not bootstrapped with
ToT sources in some time now.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-08-11 17:20:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug libstdc++/26211] [DR 419, US 137 / US 139] basic_istream::tellg, seekg are unformatted input functions
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-11 17:22 --- The solution involves clearing eofbit first, see US 137 / US 139. Maybe we should prototype it before Batavia. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|[DR 419]|[DR 419, US 137 / US 139] |basic_istream::tellg, seekg |basic_istream::tellg, seekg |are unformatted input |are unformatted input |functions |functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26211
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #13 from sje at cup dot hp dot com 2010-08-11 17:23 --- Created an attachment (id=21455) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21455&action=view) compressed builtins.c.041t.fnsplit dump file I believe that the splitting and inlining of gimple_call_num_args into gimple_rewrite_call_expr is causing the failure but I do not know why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug target/45084] configure: error: no 8-bit type
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 17:25 --- Andreas, can you have a look to this? I'm recategorizing it as target, I have never seen anything similar on Linux (or anywhere else for that matter) -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||schwab at linux-m68k dot org Component|libstdc++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084
[Bug target/45084] configure: error: no 8-bit type
--- Comment #2 from schwab at linux-m68k dot org 2010-08-11 17:30 --- Obviously the compiler is not working. That needs config.log to tell anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084
[Bug target/45084] configure: error: no 8-bit type
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-11 17:32 --- Ok, thanks. Let's ask for feedback then. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #23 from pinskia at gcc dot gnu dot org 2010-08-11 17:49 --- First off I already mentioned what is undefined in this example in comment #11. The part of the standard that mentions about arrays. And how the address of a scalar is considered an array of size 1. I don't have the standard in front of me right now but those are what I remember from the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #24 from redi at gcc dot gnu dot org 2010-08-11 17:57 --- (In reply to comment #22) > > If GCC supports cdecl on a x86 plaform then it must support the packing of > parameters as defined for x86 (it is not standardize that I know of, but it is > well defined). I sugest reading > http://en.wikipedia.org/wiki/X86_calling_conventions for a number of > references > on this parameter packing in the stack, one of my favorites is > "http://sco.com./developers/devspecs/abi386-4.pdf"; where you can read in > "Figure 3-48: C Stack Frame" how the parameters should be placed on the stack. That's a good reference. Did you see page 70? If you're not interested in writing portable code, don't blame the compiler. > Anyway, that enough for me, I already spent way too much energy and time At least we can agree on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-11 18:44 --- Apparently some KVM versions claim to be GenuineIntel family 6 model 6 with lm, but not ssse3, see https://bugzilla.redhat.com/show_bug.cgi?id=620562 Perhaps the has_longmode -> core2 test should be restored... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #10 from hjl dot tools at gmail dot com 2010-08-11 19:12 --- (In reply to comment #9) > Apparently some KVM versions claim to be GenuineIntel family 6 model 6 with > lm, > but not ssse3, see > https://bugzilla.redhat.com/show_bug.cgi?id=620562 > Perhaps the has_longmode -> core2 test should be restored... > There are no such processors from Intel. If you look at SSE3 and LM, it sounds like Nocona. But it also has family 6 and model 6. It looks like Pentium-M. If we pass -march=core2, it will generate SSSE3, which isn't supported. The bug is in KVM. It should never make up fake Intel processors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug fortran/40994] ICE in gfc_undo_symbols
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-11 19:30 --- Both comment #0 and comment #6 work for me without ICE on 4.6 trunk r163095. Closing as fixed. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.4.1 4.5.0 4.6.0 |4.4.1 4.5.0 Known to work||4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40994
[Bug debug/45259] New: [4.5/4.6 Regression
-- Summary: [4.5/4.6 Regression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45259
[Bug debug/45259] [4.5/4.6 Regression] ICE in save_call_clobbered_regs
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-11 19:42 ---
/* PR debug/45259 */
/* { dg-do compile } */
/* { dg-options "-g -O2 -fpic -w" { target fpic } } */
struct S { void (*bar) (long); };
struct T { struct S *t; };
int w;
extern int baz (int);
void
foo (int x, int u, char *z)
{
struct T *v;
static void *y[256] = { &&l1, &&l2 };
for (;;)
switch (x)
{
l2:
x = 9;
case 9:
goto *y[*z++];
case 10:
case 27:
case 54:
case 99:
case 100:
case 120:
case 122:
case 131:
case 132:
case 134:
case 141:
case 142:
v->t->bar (u);
v->t->bar (u);
case 143:
continue;
l1:
default:
baz (w);
}
}
ICEs:
internal compiler error: in save_call_clobbered_regs, at caller-save.c:896
with both trunk and 4.5. last here is a JUMP_INSN with ADDR_DIFF_VEC before bb
5 (but last->block is 5), this is followed by barrier, code_label and a
debug_insn. So before the debug_insn isn't any note, nor last->insn, but
code_label (and barrier).
--
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
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2010-08-11 19:42:30
date||
Summary|[4.5/4.6 Regression |[4.5/4.6 Regression] ICE in
||save_call_clobbered_regs
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45259
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #25 from rogerio at rilhas dot com 2010-08-11 19:51 ---
(In reply to comment #24)
> (In reply to comment #22)
> >
> > If GCC supports cdecl on a x86 plaform then it must support the packing of
> > parameters as defined for x86 (it is not standardize that I know of, but it
> > is
> > well defined). I sugest reading
> > http://en.wikipedia.org/wiki/X86_calling_conventions for a number of
> > references
> > on this parameter packing in the stack, one of my favorites is
> > "http://sco.com./developers/devspecs/abi386-4.pdf"; where you can read in
> > "Figure 3-48: C Stack Frame" how the parameters should be placed on the
> > stack.
> That's a good reference. Did you see page 70?
> If you're not interested in writing portable code, don't blame the compiler.
> > Anyway, that enough for me, I already spent way too much energy and time
> At least we can agree on that.
The reason for the reference of page 70 is exactly because of compilers like
GCC which claim to be cdecl compliant and are not. If GCC would do what it
claims to do and be cdecl compliant I would not blame the compiler and my code
(and code from many others) would be portable.
In other words my code is not portable because GCC is not doing what it should.
GCC causes code not to be portable a lot of times, like in the following case
(which does not compile because of GCC's shortcommings):
class Temp {
public:
Temp(int b);
Temp(Temp& t);
void operator=(Temp& t);
};
void func(int a, class Temp& b, int c);
func(10, Temp(20), 30); // error
This code does not compile in GCC, and so is not portable. That's shortcomming
of GCC that makes my code be not portable, not me. Its GCC's fault that code
that invokes Temp(20) as a parameter is not portable, not the programmer's
fault.
Unfortunately, conversations like this one show that GCC will never be perfect,
because people like you will insist that the compiler doesn't need to do what I
said it should (even when facing the obvious references that I've posted), and
prove that page 70 is right about warning programmers not to rely on compilers
to do correct parameter placements.
My personal experience is that GCC is the cause for such portability problems.
You still insist that GCC doesn't need to improve in this respect, and that
shows why GCC will never be as good as other compilers. Microsoft, for example,
appreciates comments like mine because it helps them improve the product, but
you just want to dismiss it as bad code on my part. I know Microsoft's people
get paid to do so, but, still, I'm talking about the right mind set.
Note that you have not stated why you think my reply #22 is wrong, and I'm
pretty sure that's because you can't. All my arguments are solidly backed up,
but you just looked at page 70, interpreted it incorrectly (because you didn't
realize that compilers like GCC are the ones responsible for that remark), and
didn't bother to see that I'm right about my arguments. You just say that I
can't do it, but I have shown why I should be able to do it. You just dismissed
it, I think is a loss for GCC, but whatever.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-08-11 19:51 --- I will have a look tomorrow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-08-11 17:20:41 |2010-08-11 19:51:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #26 from pinskia at gcc dot gnu dot org 2010-08-11 19:54 --- >This code does not compile in GCC, and so is not portable. No it is not portable because that code is just plain invalid; though MS accepts it as it is implementing something called "move constructor" as an extension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45201] ICE: stack overflow
--- Comment #8 from mr dot chr dot schmidt at online dot de 2010-08-11 20:00 --- (In reply to comment #7) > (In reply to comment #6) > > Created an attachment (id=21434) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21434&action=view) [edit] > > gdb backtrace > > > > Hmm, GGC strikes again. Well really a small stack size on windows strikes > with > GGC. > I added another testcase. When compiled with -O0 -g -std=c++0x on i686-mingw32, 3-stage bootstraped with "-g0 -O3 -fomit-frame-pointer", the reserved stack size of cc1plus must be between 8,3MB and 9,4MB. The default reserved stack size is about 2,09MB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug c++/45201] ICE: stack overflow
--- Comment #9 from mr dot chr dot schmidt at online dot de 2010-08-11 20:01 --- Created an attachment (id=21456) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21456&action=view) another testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug c/44772] -Wc++-compat warns incorrectly for anonymous unions [regression from 4.4]
--- Comment #2 from lennox at cs dot columbia dot edu 2010-08-11 20:01 --- This problem still exists in GCC 4.5.1. -- lennox at cs dot columbia dot edu changed: What|Removed |Added Version|4.5.0 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44772
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #27 from rogerio at rilhas dot com 2010-08-11 20:04 --- (In reply to comment #26) > >This code does not compile in GCC, and so is not portable. > No it is not portable because that code is just plain invalid; though MS > accepts it as it is implementing something called "move constructor" as an > extension. I already told you "you can't because you can't" (or in this case "is plain invalid") is not an answer. Please explain concisely: a) If GCC is cdecl compliant should it put the parameters on the stack as the figure 3-48 shows? Can you quote any standard that there is any exception that GCC can take advantage of and still claim to be cdecl-compliant? b) When I code &format shouldn't GCC give me the address of the format parameter on the stack? Can you quote any standard that shows that the quote I shoewd you of C99 has an exception anywhere that is applicable to this case? Both in a) and b) the answer should be yes. A good non-buggy compiler will do both things a)+b), as Microsoft does (without any extension). If GCC can be made to do a)+b) simultaneously then don't worry about the portability of my code because I just need a)+b) together and I will have no problem, just leave the rest to me and don't you worry. I think it would settle the issue if you could just simply answer these 2 questions a) and b) directly and clearly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #28 from rogerio at rilhas dot com 2010-08-11 20:07 --- (In reply to comment #23) > First off I already mentioned what is undefined in this example in comment > #11. > The part of the standard that mentions about arrays. And how the address of > a > scalar is considered an array of size 1. I don't have the standard in front > of > me right now but those are what I remember from the standard. Right. And I clearly explained in my comment #14 why you were wrong. Getting back to comment #11 so that we can run around in circles brings no improvement to this conversation, and you will just keep on being wrong, even if you had the standard in front of you, because your example in comment #11 does not correspond to the code I'm doing. My comment #14 explains what is the correct code for comparison. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug tree-optimization/45260] New: g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541
See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2190 $ g++-4.5 -fprefetch-loop-arrays TargetLowering.ii -c -O2 ../../../../clamav-devel/libclamav/c++/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp: In member function void llvm::TargetLowering::computeRegisterProperties(): ../../../../clamav-devel/libclamav/c++/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:608:6: internal compiler error: in verify_expr, at tree-cfg.c:2541 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. g++-4.4 works: $ g++-4.4 -fprefetch-loop-arrays TargetLowering.ii -c -O2 $ g++-4.5 -v Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.1-1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --program-suffix=-4.5 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.1 (Debian 4.5.1-1) -- Summary: g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
[Bug tree-optimization/45260] g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541
--- Comment #1 from edwintorok at gmail dot com 2010-08-11 20:27 --- Created an attachment (id=21457) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21457&action=view) TargetLowering.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
[Bug debug/45259] [4.5/4.6 Regression] ICE in save_call_clobbered_regs
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-11 20:30 --- Created an attachment (id=21458) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21458&action=view) gcc46-pr45259.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45259
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-11 20:31 --- Maybe we can improve the unknown processor support: 1. For 32bit, use i686 + -mSSEx. 2. For 64bit, use x86_64 + -mSSEx. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-08-11 20:33 --- (In reply to comment #28) > (In reply to comment #23) > > First off I already mentioned what is undefined in this example in comment > > #11. > > The part of the standard that mentions about arrays. And how the address > > of a > > scalar is considered an array of size 1. I don't have the standard in > > front of > > me right now but those are what I remember from the standard. > > > Right. And I clearly explained in my comment #14 why you were wrong. Getting > back to comment #11 so that we can run around in circles brings no improvement > to this conversation, and you will just keep on being wrong, even if you had > the standard in front of you, because your example in comment #11 does not > correspond to the code I'm doing. My comment #14 explains what is the correct > code for comparison. We're indeed running in circles. Maybe you can find someone that can explain to you better on comp.lang.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug tree-optimization/45260] [4.5/4.6 Regression] g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|g++4.5: -prefetch-loop- |[4.5/4.6 Regression] g++4.5: |arrays internal compiler|-prefetch-loop-arrays |error: in verify_expr, at |internal compiler error: in |tree-cfg.c:2541 |verify_expr, at tree- ||cfg.c:2541 Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #30 from rogerio at rilhas dot com 2010-08-11 20:58 --- Really? Your comment #11 has so many mistakes in it that maybe you are the one who should learn a little bit more on C. >The ABI is not of concern here really. The issue comes down to you have: >char *a; >char **b = &a; >use(b[1]); This comment just means you missed the point. Maybe you just memorized the C standar, maybe not, but you didn't understand that I was doing something different. Did you miss the part in my comment #14 where I mentioned that &a does not point to only 4 bytes but, instead, 16 bytes? Didn«t you understand the equivalent code would be: char* a[4]; char **b =&a[0]; use(b[1]); Didn't you realize that there is nothing wrong with this code? Its basic C. The code does not work because GCC is not doing its job right, otherwise, by cdecl definition, there would a would be an array of 4 pointers, like I showed. It seems you didn't understand, but it is, in fact, quite simple. Check what cdecl means, then you will realize that the 4 parameters are supposed to be equivalent to char* a[4]. Nothing else I can do here, really, if you don«t understand this then maybe you should be responsible for answering to comments on such an important project as GCC. >It is undefined what happens when you access b[1]. It does not matter if the >ABI defines that the arguments are passed via the stack in ascending order or >not. It could pass them via descending order. Accessing an out of bounds >array is causing the issue here. This is very wrong again. Don«t hide in out of bounds array. The point is exactly that, you are wrong about what the problem is. The problem is that the address GCC gives me is not to the 4 packed parameters, not the out of bounds. If GCC packed the 4 entries there would be no out of bounds problem. Maybe you need to learn C, I did learn it and well, so I know what a pointer does and what happens when you go out of bounds. So the problem is the underlying buffer of data created by GCC is bad, not that I use the 1-entry pointer to an array to access the following elements. You are just wrong, and I seem to be unable to make you see just how wrong you are. >This is not about GCC vs MS Visual studio issue, this is a C/C++ standard issue >saying what you are doing is undefined. Can you quote some part of the standard to back up your claims? I did backup my claims, you have not yet backed up yours. >Another thing well defined in C is what happens when navigating an array out of its bounds. Kinda, you can go one past the array bounds for the address but you cannot access it. That is what the C/C++ standard says. I can quote the standard if needed. Anything else is undefined. You are just wrong again. char* a[4]; char** b=&a[0]; access(b[0], b[1], b[2], b[3]). This code is valid although b is a pointer to one and only one address. This is the example in my code (assuming cdecl), you can try to avoid it, and compare to wrong code like you did in comment #11, but that will not be helpful to the GCC project, you will just keep wasting resources. So, as you can see, there is nothing correct about your comment #11. Should't you be reading something somewhere then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #31 from pinskia at gcc dot gnu dot org 2010-08-11 21:02 --- >Didn't you understand the equivalent code would be: No, as the variables act the same if they are automatic variables or arguments. there is no different between the two. That has been my point from the beginning. I think it is time for me to end my part and say please follow up to the C standards news group as we are going in circles as a misunderstanding about ABI and how arguments are passed have no concern to what the C standard says about variables (automatic and arguments) and the size of an array for an address of one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #32 from rogerio at rilhas dot com 2010-08-11 21:12 --- (In reply to comment #31) > >Didn't you understand the equivalent code would be: > No, as the variables act the same if they are automatic variables or > arguments. > there is no different between the two. That has been my point from the > beginning. Wrong again. The cdecl definition is for parameters, there is no such thing for automatic variables. So I can expect a given packing of arguments in a cdecl-compliant compiler, and I can expect no such thing from automatic variables. Can you backup your claim? (I'm not really interested, just to let you know that you missed a critical aspect again) > I think it is time for me to end my part and say please follow up to the C > standards news group as we are going in circles as a misunderstanding about > ABI > and how arguments are passed have no concern to what the C standard says about > variables (automatic and arguments) and the size of an array for an address of > one. Yes, I agree that is better as you don't backup anything you say. You didn't even bother to answer to a) and b) of my comment 27 (and you woldn't, obviously, as you dismiss cdecl as an important part to this discussion). I can only assume that that is because you simply can't, since you so cleverly avoided answering the questions I placed there which would surely settle the matter. Anyway, I found a workaround that makes GCC behave properly so I got my code running again. So you can leave the bug as is and it won't bother me anymore. -- rogerio at rilhas dot com changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #33 from pinskia at gcc dot gnu dot org 2010-08-11 21:16 --- Yes GCC implements that ABI and &argument will get you the address of that argument. But that does not deter from that &argument will produce an array of size 1 rather than what you want which is the rest of the arguments too. Does that answer your question about how I could just ignore the ABI in the context of the C/C++ standard? The ABI only says how they are passed and not how you can access them through C/C++ code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #79 from jasmin at revisionfx dot com 2010-08-11 21:26 --- > I am not exactly sure how to report a bug here Find the answer here: https://bugs.launchpad.net/sbcl/+bug/539632 " Compile with -mpreferred-stack-boundary=2. This will force GCC to compile code that adheres to the ABI and therefore properly adjusts its own stack pointer." that works -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #34 from redi at gcc dot gnu dot org 2010-08-11 21:27 ---
(In reply to comment #25)
> In other words my code is not portable because GCC is not doing what it
> should.
> GCC causes code not to be portable a lot of times, like in the following case
> (which does not compile because of GCC's shortcommings):
>
> class Temp {
> public:
> Temp(int b);
> Temp(Temp& t);
> void operator=(Temp& t);
> };
>
> void func(int a, class Temp& b, int c);
>
> func(10, Temp(20), 30); // error
ISO/IEC 14882:2003(E) 8.5.3 [dcl.init.ref] paragraph 5
> This code does not compile in GCC, and so is not portable. That's shortcomming
> of GCC that makes my code be not portable, not me. Its GCC's fault that code
> that invokes Temp(20) as a parameter is not portable, not the programmer's
> fault.
ibid.
> Unfortunately, conversations like this one show that GCC will never be
> perfect,
> because people like you will insist that the compiler doesn't need to do what
> I
> said it should (even when facing the obvious references that I've posted), and
> prove that page 70 is right about warning programmers not to rely on compilers
> to do correct parameter placements.
What a charming idea, that a compiler could become perfect by doing "what I
said it should"
> My personal experience is that GCC is the cause for such portability problems.
> You still insist that GCC doesn't need to improve in this respect, and that
> shows why GCC will never be as good as other compilers. Microsoft, for
> example,
> appreciates comments like mine because it helps them improve the product, but
> you just want to dismiss it as bad code on my part. I know Microsoft's people
> get paid to do so, but, still, I'm talking about the right mind set.
Oh, how delightfully quaint!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug rtl-optimization/45235] const volatile read moved out of order
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-11 21:41 --- Hmm, I don't think this is correct as const volatile is a bit weird. It means a read must happen but it does not say order compared to other volatile variables (or at least I think). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45235
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #35 from rogerio at rilhas dot com 2010-08-11 22:16 --- (In reply to comment #33) > Yes GCC implements that ABI and &argument will get you the address of that > argument. If that is so then the format parameter will be placed at some address X, param 1 at address X+4, param 2 at address X+8, and param 3 at X+12. Figure 3-48 shows these addresses to be very predictable and well defined. It is very important for you to follow this reasoning, as this makes all the difference. This is what makes X an array of 4 entries, and not simply an array of 1 isolated entry. > But that does not deter from that &argument will produce an array of > size 1 rather than what you want which is the rest of the arguments too. Can you backup your claim that "&argument will produce an array of size 1"? Can you even backup the claim that &argument "produces" any array at all? As I showed using C99, the & just produces a value X (an address which can be travelled without boundary issues), so C99 shows that "&argument" does not "produce" an array, nor allocates storage for a 1-entry copy of "argument" at some unpredictable address Y (C99 clearly states that &a retuns "address of a", not "address of copy of a"). So I don't see how you could ever backup your claim with any standard, but I'm open to be surprised by your creativity! :-) Based on C99 const char** PTR4=&format will set PTR4 to X. It's all good as long as PTR4 contains the value X. As C99 defines this, GCC doesn't have the option to copy the "format" to some random address Y and return it when I ask for "&format". It simply should not do this. I've backed this claim with C99 text that states that & operator is the address of the item, not the address of a copy of the item invented by the compiler. I also showed you in C99 that PTR4[0] accesses the 4 bytes of address X, and I've backed up my claim (based on C99) that PTR4[1] will access the 4 bytes at X+4 (i.e the 4 bytes of param 1), and that there is no "size of array limitation" specified in C99. Similarly, PTR4[2] will access the 4 bytes at X+8, (i.e the 4 bytes of param 2), and so on. I've clearly backed up this with C99. So, all this is backed up. Can you refute the reasoning up to this point with any C99 reference? Or a reference to any other standard for that matter? > Does that answer your question about how I could just ignore the ABI in the > context of the C/C++ standard? The ABI only says how they are passed and not > how you can access them through C/C++ code. So no, not really. If the ABI is respected then the 4 parameters will be stored at predictable places, all together, as a 4-entry array at address X, which is fundamental for me to access them using a PTR4 set to X. If you told me right from the start that GCC didn't comply to cdecl, or that it did but only sometimes, then this conversation would have ended immediately, because I would have absolutely no way to trust that the 4 items would be present at contiguous bytes X to X+15, and I would, therefore, not be able to access PTR4[1], PTR4[2], and so on. This should help you understand why the ABI is an important part of this problem, and where I base my claim that GCC's behaviour is wrong. So, if GCC were not cdecl-compliant, I would have no other option but to shut up and think about new approaches in my code. Well, maybe I would not just shut up and maybe I would then complain that GCC should be cdecl-compliant always, but I would not call it a bug and I would post it as a feature request. You could reason that the ABI was not important if the compiler were free to create a copy of "format" to some address Y when I ask for "&format" (as in that case it would probably just copy "format" and not the remaining 3 parameters to location Y - hence you would be right, an array of size 1), but C99 says the compiler cannot do that because &format is X (the address of the item, not Y the address of a copy of it). But GCC does not return X when I ask for "&format", at least not always (as sometimes returns a random Y), and it should (as I backed up with C99). If under GCC "&argument will produce an array of size 1 [with a copy of format and not of the other parameters]" then you would be right and you would be proving GCC to have a bug that contradicts C99. If GCC didn't have a bug it would comply with C99 and would return X, which the cdecl ABI states is a 4-entry array, not 1-entry array as you claimed (making your claim wrong). So you are right because GCC has a bug, if it hadn't you would be wrong. In other words, what you say in fact happens in real life because GCC is not strictly conforming to C99 (and while that happens you are right to say that is the current behaviour to "&argument will produce an array of size 1"), but if GCC behaved as C99 says it should then what you say would not be hapening in real life (and so you would be wrong when saying "&argument will produce an array of size 1"). I have the feeling I
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #36 from rguenth at gcc dot gnu dot org 2010-08-11 22:27 --- (In reply to comment #35) > (In reply to comment #33) > > Yes GCC implements that ABI and &argument will get you the address of that > > argument. > > If that is so then the format parameter will be placed at some address X, > param > 1 at address X+4, param 2 at address X+8, and param 3 at X+12. Figure 3-48 > shows these addresses to be very predictable and well defined. It is very > important for you to follow this reasoning, as this makes all the difference. > This is what makes X an array of 4 entries, and not simply an array of 1 > isolated entry. It doesn't make it an array in the C sense. > > But that does not deter from that &argument will produce an array of > > size 1 rather than what you want which is the rest of the arguments too. > > Can you backup your claim that "&argument will produce an array of size 1"? > Can > you even backup the claim that &argument "produces" any array at all? As I > showed using C99, the & just produces a value X (an address which can be > travelled without boundary issues), so C99 shows that "&argument" does not > "produce" an array, nor allocates storage for a 1-entry copy of "argument" at > some unpredictable address Y (C99 clearly states that &a retuns "address of > a", > not "address of copy of a"). So I don't see how you could ever backup your > claim with any standard, but I'm open to be surprised by your creativity! :-) > > Based on C99 const char** PTR4=&format will set PTR4 to X. It's all good as > long as PTR4 contains the value X. As C99 defines this, GCC doesn't have the > option to copy the "format" to some random address Y and return it when I ask > for "&format". It simply should not do this. I've backed this claim with C99 > text that states that & operator is the address of the item, not the address > of > a copy of the item invented by the compiler. > > I also showed you in C99 that PTR4[0] accesses the 4 bytes of address X, and > I've backed up my claim (based on C99) that PTR4[1] will access the 4 bytes at > X+4 (i.e the 4 bytes of param 1), and that there is no "size of array > limitation" specified in C99. Similarly, PTR4[2] will access the 4 bytes at > X+8, (i.e the 4 bytes of param 2), and so on. I've clearly backed up this with > C99. > > So, all this is backed up. Can you refute the reasoning up to this point with > any C99 reference? Or a reference to any other standard for that matter? &X gives you an address of X which happens to be on the stack. Following parameters happen to be in adjacent stack slots. Still C does not give you a way to access adjacent parameters by doing pointer arithmetic on &X. &X does _not_ get you access to anything like a "stack" as there is no such concept in the C language. In foo (int x, int y, int z) there are only x, y and z. There is no array of parameters, the only "arrays" are that of implicit size 1 at locations &x, &y and &z which allows you to compute &x + 1 (but not dereference that pointer). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-08-11 22:30 --- Btw, 6.5.6/7 "For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #38 from rogerio at rilhas dot com 2010-08-11 22:35 ---
(In reply to comment #34)
> (In reply to comment #25)
> > In other words my code is not portable because GCC is not doing what it
> > should.
> > GCC causes code not to be portable a lot of times, like in the following
> > case
> > (which does not compile because of GCC's shortcommings):
> >
> > class Temp {
> > public:
> > Temp(int b);
> > Temp(Temp& t);
> > void operator=(Temp& t);
> > };
> >
> > void func(int a, class Temp& b, int c);
> >
> > func(10, Temp(20), 30); // error
> ISO/IEC 14882:2003(E) 8.5.3 [dcl.init.ref] paragraph 5
Thanks for this. I didn't know why GCC was unable to compile such code and now
I know: GCC is unable to convert a initialization passed as parameter to an
lvalue. Microsoft's compiler does know how to do that - there is no problem in
getting the address of such temporary variables, right? Oh, wrong, GCC can't,
that's just too hard on the poor thing.
... oh well, let's just not call that a portability issue created by GCC,
because no one explained to its developers how to get the address of a
temporary variable. Let's just not initialize temporary variables and stick to
the lowest common denominator, which is GCC.
Really?? Was that rally the explanation you wanted to provide??? I think its
just embarassing. Note that I didn't open a bug for this issue because I can,
in fact, reduce to the lowest common denominator. So, I can live without
(although not as confortably).
> > This code does not compile in GCC, and so is not portable. That's
> > shortcomming
> > of GCC that makes my code be not portable, not me. Its GCC's fault that code
> > that invokes Temp(20) as a parameter is not portable, not the programmer's
> > fault.
> ibid.
> > Unfortunately, conversations like this one show that GCC will never be
> > perfect,
> > because people like you will insist that the compiler doesn't need to do
> > what I
> > said it should (even when facing the obvious references that I've posted),
> > and
> > prove that page 70 is right about warning programmers not to rely on
> > compilers
> > to do correct parameter placements.
> What a charming idea, that a compiler could become perfect by doing "what I
> said it should"
You must have missed something in the discussion because you failed to see that
"what I say" is what "C99+cdecl" say. Please forgive me for cutting sentences
short, I didn't think anyone would start making comments without reading the
whole conversation, my bad.
... is it still a charming idea after you read all the backups to my claims?
> > My personal experience is that GCC is the cause for such portability
> > problems.
> > You still insist that GCC doesn't need to improve in this respect, and that
> > shows why GCC will never be as good as other compilers. Microsoft, for
> > example,
> > appreciates comments like mine because it helps them improve the product,
> > but
> > you just want to dismiss it as bad code on my part. I know Microsoft's
> > people
> > get paid to do so, but, still, I'm talking about the right mind set.
> Oh, how delightfully quaint!
It is, isn't it? And it makes sense too, doesn't it? I bet that thinking that
GCC needs not improve on the stuff I commented here is a sure way to get you
there fast. I'm sorry I even tried!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #39 from rogerio at rilhas dot com 2010-08-11 22:37 --- (In reply to comment #37) > Btw, 6.5.6/7 "For the purposes of these operators, a pointer to an object that > is > not an element of an array behaves the same as a pointer to the first element > of an array of length one with the type of the object as its element type." No problem, as long as it doesn't make a copy. I clearly stated this, and explained with C99, that even 1-entry arrays can be navigated beyond the boundaries. I thoroughly explained the arithmetic. Where did you read that 1-entry arrays can be copied to a different location when someone requests the address operator? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #40 from rguenth at gcc dot gnu dot org 2010-08-11 22:48 --- (In reply to comment #39) > (In reply to comment #37) > > Btw, 6.5.6/7 "For the purposes of these operators, a pointer to an object > > that > > is > > not an element of an array behaves the same as a pointer to the first > > element > > of an array of length one with the type of the object as its element type." > > No problem, as long as it doesn't make a copy. Why do you think GCC makes it the address of a copy? > I clearly stated this, and > explained with C99, that even 1-entry arrays can be navigated beyond the > boundaries. I thoroughly explained the arithmetic. Where did you read that > 1-entry arrays can be copied to a different location when someone requests the > address operator? You are wrong here. The next paragraph, 6.5.6/8, explains that, "... otherwise the behavior is undefined. If the result points one past the last element of the array object, it shall not be used as the operator of a unary * operator that is evaluated.". Where I point you to 6.5.3.2/3 if you now claim that x[2] isn't invoking the unary * operator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #41 from rogerio at rilhas dot com 2010-08-11 22:50 --- > It doesn't make it an array in the C sense. What is an array in the C sense? Isn't it a sequence of entries? Is there any other concept to go along with it that allows PTR4 to be set to any other value than X? If so, where did you read it? I read in C99 that a pointer is simply a variable that contains an address, and that C doesn't navigate "arrays in the C sense" in anyway diferently than with "simple pointers". Do you have a C99 section that shows a distinction significant to this issue? > &X gives you an address of X which happens to be on the stack. Following > parameters happen to be in adjacent stack slots. Still C does not give > you a way to access adjacent parameters by doing pointer arithmetic on > &X. Can you explain then how &X gets the format parameter from the stack and X[1] doesn't get the next adjacent entry on the stack? Note that C99 is pretty clear about the fact that X[1] will access bytes 4 to 7 after X. Can you backup your claim with C99 or any other reference besides your personal interpretation? > &X does _not_ get you access to anything like a "stack" as there is > no such concept in the C language. No problem. I don«t want PTR4 to be a specific "pointer to stack", I want it to be a "general pointer to memory". I don«t need more than that and C99 says I should be able to get such "generic address" to PTR4 and dereference it. Where can it be read that to access stack address space I should need a special pointer? Where does it read I cannot derreference PTR4 if it points to stack? Where can it be read that if I dereference PTR4 while its is pointing to stack that pointer arithmetic will not be the same as any other? > In > foo (int x, int y, int z) > there are only x, y and z. There is no array of parameters, the only > "arrays" are that of implicit size 1 at locations &x, &y and &z which > allows you to compute &x + 1 (but not dereference that pointer). No, cdecl states that &x+1==&y, and that &x+2==&z. If a compiler is cdecl-compliant I can trust this to be true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c/45261] New: Doesn't indicate failure status when it doesn't support (attiny2313A)
When configuration script of avr-libc tries to check if gcc has support for Attiny2313A it doesn't indicate any failure even if it really doesn't support it. I found about that trying to build avr toolchain using this version of gcc. Here is a part of config.log: configure:5374: checking if avr-gcc has support for attiny2313a configure:5390: avr-gcc -c -mmcu=attiny2313a conftest.c >&5 unknown MCU 'attiny2313a' specified ... configure:5397: $? = 0 configure:5416: result: yes (which should indicate NO) this bug doesn't allow to build avr-libc-1.7.0 because it doesn't let 'make' to build the code. -- Summary: Doesn't indicate failure status when it doesn't support (attiny2313A) Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rootolini at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: avr GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45261
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #42 from rogerio at rilhas dot com 2010-08-11 22:51 --- > It doesn't make it an array in the C sense. What is an array in the C sense? Isn't it a sequence of entries? Is there any other concept to go along with it that allows PTR4 to be set to any other value than X? If so, where did you read it? I read in C99 that a pointer is simply a variable that contains an address, and that C doesn't navigate "arrays in the C sense" in anyway diferently than with "simple pointers". Do you have a C99 section that shows a distinction significant to this issue? > &X gives you an address of X which happens to be on the stack. Following > parameters happen to be in adjacent stack slots. Still C does not give > you a way to access adjacent parameters by doing pointer arithmetic on > &X. Can you explain then how &X gets the format parameter from the stack and X[1] doesn't get the next adjacent entry on the stack? Note that C99 is pretty clear about the fact that X[1] will access bytes 4 to 7 after X. Can you backup your claim with C99 or any other reference besides your personal interpretation? > &X does _not_ get you access to anything like a "stack" as there is > no such concept in the C language. No problem. I don«t want PTR4 to be a specific "pointer to stack", I want it to be a "general pointer to memory". I don«t need more than that and C99 says I should be able to get such "generic address" to PTR4 and dereference it. Where can it be read that to access stack address space I should need a special pointer? Where does it read I cannot derreference PTR4 if it points to stack? Where can it be read that if I dereference PTR4 while its is pointing to stack that pointer arithmetic will not be the same as any other? > In > foo (int x, int y, int z) > there are only x, y and z. There is no array of parameters, the only > "arrays" are that of implicit size 1 at locations &x, &y and &z which > allows you to compute &x + 1 (but not dereference that pointer). No, cdecl states that &x+1==&y, and that &x+2==&z. If a compiler is cdecl-compliant I can trust this to be true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #43 from rogerio at rilhas dot com 2010-08-11 22:52 --- > It doesn't make it an array in the C sense. What is an array in the C sense? Isn't it a sequence of entries? Is there any other concept to go along with it that allows PTR4 to be set to any other value than X? If so, where did you read it? I read in C99 that a pointer is simply a variable that contains an address, and that C doesn't navigate "arrays in the C sense" in anyway diferently than with "simple pointers". Do you have a C99 section that shows a distinction significant to this issue? > &X gives you an address of X which happens to be on the stack. Following > parameters happen to be in adjacent stack slots. Still C does not give > you a way to access adjacent parameters by doing pointer arithmetic on > &X. Can you explain then how &X gets the format parameter from the stack and X[1] doesn't get the next adjacent entry on the stack? Note that C99 is pretty clear about the fact that X[1] will access bytes 4 to 7 after X. Can you backup your claim with C99 or any other reference besides your personal interpretation? > &X does _not_ get you access to anything like a "stack" as there is > no such concept in the C language. No problem. I don«t want PTR4 to be a specific "pointer to stack", I want it to be a "general pointer to memory". I don«t need more than that and C99 says I should be able to get such "generic address" to PTR4 and dereference it. Where can it be read that to access stack address space I should need a special pointer? Where does it read I cannot derreference PTR4 if it points to stack? Where can it be read that if I dereference PTR4 while its is pointing to stack that pointer arithmetic will not be the same as any other? > In > foo (int x, int y, int z) > there are only x, y and z. There is no array of parameters, the only > "arrays" are that of implicit size 1 at locations &x, &y and &z which > allows you to compute &x + 1 (but not dereference that pointer). No, cdecl states that &x+1==&y, and that &x+2==&z. If a compiler is cdecl-compliant I can trust this to be true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
