[Bug middle-end/45274] New: __restrict__ type qualifier does not work on pointers to bitfields
I tested an svn build from 20100813 with the following code:
struct bar {
unsigned int a:1, b:1, c:1, d:1, e:28;
};
void foo(struct bar * __restrict__ src, struct bar * __restrict__ dst)
{
dst-a = src-a;
dst-b = src-b;
dst-c = src-c;
dst-d = src-d;
dst-e = src-e;
}
Built as 32bit, we see loads and stores as if the compiler is following pointer
aliasing rules:
# gcc -m32 -O2 -S foo.c
foo:
lwz 9,0(3)
lwz 0,0(4)
rlwimi 0,9,0,0,0
stw 0,0(4)
lwz 9,0(3)
rlwimi 0,9,0,1,1
stw 0,0(4)
lwz 9,0(3)
rlwimi 0,9,0,2,2
stw 0,0(4)
lwz 9,0(3)
rlwimi 0,9,0,3,3
stw 0,0(4)
lwz 9,0(3)
rlwimi 0,9,0,4,31
stw 0,0(4)
blr
Apologies if I am misusing or misinterpreting the use of __restrict__ here.
Also, when built as 64bit things are considerably more complex. Is there a
reason why we can't use the same code as 32bit?
# gcc -m64 -O2 -S foo.c
...
.L.foo:
lwz 9,0(4)
lwz 0,0(3)
rlwinm 9,9,0,1,31
rlwinm 0,0,0,0,0
or 0,9,0
stw 0,0(4)
rlwinm 0,0,1,1,31
rlwinm 0,0,31,0x
lwz 9,0(3)
rldicl 9,9,34,63
slwi 9,9,30
or 0,0,9
stw 0,0(4)
rlwinm 9,0,2,1,31
rlwinm 9,9,30,0x
lwz 0,0(3)
rldicl 0,0,35,63
slwi 0,0,29
or 0,9,0
stw 0,0(4)
rlwinm 0,0,3,1,31
rlwinm 0,0,29,0x
lwz 9,0(3)
rldicl 9,9,36,63
slwi 9,9,28
or 0,0,9
stw 0,0(4)
rlwinm 0,0,0,0,3
lwz 9,0(3)
rlwinm 9,9,0,4,31
or 0,0,9
stw 0,0(4)
blr
--
Summary: __restrict__ type qualifier does not work on pointers to
bitfields
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45274
[Bug middle-end/45273] [4.4/4.5/4.6 Regression] The compiler depends on the host double (-fprofile-corection only)
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-13 07:22 --- Should use sreal, then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273
[Bug preprocessor/45227] libcpp Makefile does not enable instrumentation
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-13 07:42 --- Does anyone have a daily autotester for profiled-bootstrap? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-13 07:42:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227
[Bug middle-end/45274] __restrict__ type qualifier does not work on pointers to bitfields
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-13 08:01 --- I don't think this has anything to do with restrict and all with lowering bitfield accesses only during expansion, and at RTL level the bitfield operations being too big for combiner to optimize them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45274
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #8 from roland at redhat dot com 2010-08-13 08:08 --- I think you've confused static variables (file scope) with C++ static members (global scope). At any rate, this is not the place to get an education about DWARF. You can use the dwarf-discuss mailing list for those questions. The DIEs you cited are correct for the code. There is no gcc bug here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-13 08:22 ---
Confirmed.
-fdump-tree-original shows only one difference when exchanging the use
statements:
--- c1.f90.003t.original2010-08-13 10:05:17.720283742 +0200
+++ c1.f90.003t.original.bug2010-08-13 10:04:53.912784753 +0200
@@ -215,7 +215,7 @@ MAIN__ ()
if (vtab$trivial_gradient_type.assign == 0B)
{
-vtab$trivial_gradient_type.assign = my_assign;
+vtab$trivial_gradient_type.assign = (void (*T4a1) (struct
class$trivial_gradient_type restrict, struct class$vector_class restrict))
my_assign;
}
class.8.$vptr = (struct vtype$gradient_class * {ref-all})
vtab$trivial_gradient_type;
class.8.$data = (struct gradient_class *) g_initial;
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2010-08-13 08:22:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug preprocessor/45227] libcpp Makefile does not enable instrumentation
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-13 08:26 --- No, we only have daily testers for SPEC 2000 with profile feedback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-13 08:48 --- Thus, INVALID. -- 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=45153
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-13 09:29 --- Here is a reduced test case: module abstract_vector implicit none type, abstract :: vector_class contains procedure(op_assign_v_v), deferred :: assign end type vector_class abstract interface subroutine op_assign_v_v(this,v) import vector_class class(vector_class), intent(inout) :: this class(vector_class), intent(in):: v end subroutine end interface end module abstract_vector module concrete_vector use abstract_vector implicit none type, extends(vector_class) :: trivial_vector_type contains procedure :: assign = my_assign end type contains subroutine my_assign (this,v) class(trivial_vector_type), intent(inout) :: this class(vector_class),intent(in):: v write (*,*) 'Oops in concrete_vector::my_assign' call abort () end subroutine end module concrete_vector module concrete_gradient use abstract_vector implicit none type, extends(vector_class) :: trivial_gradient_type contains procedure :: assign = my_assign end type contains subroutine my_assign (this,v) class(trivial_gradient_type), intent(inout) :: this class(vector_class), intent(in):: v write (*,*) 'concrete_gradient::my_assign' end subroutine end module concrete_gradient program main !--- exchange these two lines to make the code work: use concrete_vector! (1) use concrete_gradient ! (2) !--- implicit none type(trivial_gradient_type) :: g_initial class(vector_class), allocatable :: g print *, cg: before g%assign allocate(trivial_gradient_type :: g) call g%assign (g_initial) print *, cg: after g%assign end program main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #3 from mikael at gcc dot gnu dot org 2010-08-13 09:33 --- Might be related to pr41359 (whose patch was not committed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-13 09:50 ---
The problem is the following:
We have two routines called 'my_assign' (in two different modules). When
initializing the vtabs in the main program, we happen to use the wrong one:
if (vtab$trivial_gradient_type.assign == 0B)
{
vtab$trivial_gradient_type.assign = my_assign;
}
Possible solutions:
1) Make sure we use the right symbol from the right module.
2) Do the vtab initialization inside the module that defines the class, i.e.
add a module procedure like 'vtab$trivial_gradient_type$init' which does it,
and call this from the main program. Then there is no name ambiguity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #4 from jv244 at cam dot ac dot uk 2010-08-13 10:11 --- (In reply to comment #3) Might be related to pr41359 (whose patch was not committed). I think it is unrelated, since this used to work in 4.3, while pr41359 never worked AFAICT. Nevertheless, would be nice to commit the patch in pr41359, maybe there is a lucky side-effect. I think there is are no line-number tests in gfortran's testsuite. Would be a good thing to establish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #16 from hainque at adacore dot com 2010-08-13 10:14 --- Subject: Re: pthread_default_stacksize_np failed. dave at hiauly1 dot hia dot nrc dot ca wrote: I think the answer is to provide a stub for pthread_default_stacksize_np which is linked in last in final executables. I believe the function is always present in the pthread libraries, both shared and archive. We already do similar things for a number of functions on hppa64-hpux11. Hmm, certainly worth an attempt. We were caught by subtle bugs with similar attempts on other platforms in the past, like stub added to lib X, and corner case situation Bla leads to a link order that gets us the stub instead of the real implementation in multi threaded apps. That's probably settled by now :) We're discussing the options internally. Thanks much for your feedback. Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #10 from pj dot pandit at yahoo dot co dot in 2010-08-13 10:37 --- I think we've stepped away from DW_AT_external. This global linkage theory is not convincing for why DW_AT_external should be set for variables/functions that are defined outside of the compilation unit. -- pj dot pandit at yahoo dot co dot in changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #11 from redi at gcc dot gnu dot org 2010-08-13 10:51 --- But surely if (as you suggest) swscanf had a DIE without DW_AT_external that would imply it was private to the compilation unit, which would be wrong. If a non-static function has a DIE, it should include DW_AT_external. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-13 10:57 --- . -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #13 from redi at gcc dot gnu dot org 2010-08-13 11:05 --- (In reply to comment #7) Also, how does on locate the DIEs for variables/functions that are listed in the .debug_pubnames section($ eu-readelf -wpubnames file). The list of variables/functions that are *defined* in the same compilation unit and are *visible/accessible from outside* of it. Can't you look for DIEs which have DW_AT_external and which have a later DW_AT_specification, which completes the earlier non-defining declaration. DW_AT_specification tells you it's defined, DW_AT_external tells you it's visible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug fortran/45275] New: [4.6 Regression] FAIL: gfortran.dg/array_memcpy_3.f90
On x86_64-unknown-linux-gnu at r163221 I see the following testsuite regression: FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original memcpy|(ref-all.*ref-all) 2 -- Summary: [4.6 Regression] FAIL: gfortran.dg/array_memcpy_3.f90 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45275
[Bug libstdc++/45276] New: Need to document _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE
As of r163210 (http://gcc.gnu.org/viewcvs?view=revisionrevision=163210) libstdc++ has two new macros: _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER and a short documentation for them in include/bits/c++config I propose to add a more detailed documentation (though I don't know the exact place where to add it). The proposed text follows. See also the discussion at http://old.nabble.com/Re:-libstdc%2B%2B-and-race-detectors-to29116684.html Support for race detectors. All synchronization primitives used in the library internals should be understood by race detectors so that the race detectors do not produce false reports. We use two annotations (macros) to explain low-level synchronization to race detectors: - _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE() and - _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(). By default, these two macros are defined empty -- anyone who wants to use a race detector will need to redefine these macros to call appropriate race detector API. Since these macros are empty by default, redefining them in the user code will affect only the inline template code, i.e. shared_ptr. In order to redefine the macros in basic_string one will need to disable extern templates (by defining _GLIBCXX_EXTERN_TEMPLATE=-1) or rebuild the .so. The rest of the cases will require to rebuild the .so: - ios_base::Init::~Init - locale::_Impl and locale::facet The approach described above works at least with the following race detection tools: - DRD, http://valgrind.org/docs/manual/drd-manual.html - Helgrind, http://valgrind.org/docs/manual/hg-manual.html - Intel Parallel Inspector, http://software.intel.com/en-us/intel-parallel-inspector - ThreadSanitizer, http://code.google.com/p/data-race-test With DRD, Helgrind and ThreadSanitizer you will need to define the macros like this: #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(a) ANNOTATE_HAPPENS_BEFORE(a); #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(a) ANNOTATE_HAPPENS_AFTER(a); For Intel Parallel Inspector: #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(a) itt_notify_sync_releasing(a); #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(a) itt_notify_sync_acquired(a); Refer to the documentation of a particular tool for the details. -- Summary: Need to document _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: konstantin dot s dot serebryany at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45276
[Bug libstdc++/45276] Need to document _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-13 11:50 --- (In reply to comment #0) I propose to add a more detailed documentation (though I don't know the exact place where to add it). maybe http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html The html docs are generated from docbook sources in libstdc++-v3/doc/xml/manual -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-13 11:50:12 date|| Summary|Need to document|Need to document |_GLIBCXX_SYNCHRONIZATION_HAP|_GLIBCXX_SYNCHRONIZATION_HAP |PENS_BEFORE |PENS_BEFORE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45276
[Bug fortran/45277] New: make bootstrap fails at:checking whether the GNU Fortran compiler is working... no
Error message said to attach a log file, but don't find anything to attach a file on this form. Let me know how to attach if needed uname -a: SunOS frg-sol10-05 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T200 using binutils-2.20 (build on the same host) separate srcdir and objdir (build dir) Source directory: $HOME/tmp/GNU/src/sun4v/gcc-4.5.1 gmp, mpfr and mpc are linked into gcc-4.5.1 source tree: ls -l gcc-4.5.1/gmp gcc-4.5.1/mpfr gcc-4.5.1/mpc lrwxrwxrwx 1 philips frgit 13 Aug 12 14:44 gcc-4.5.1/gmp - ../gmp-5.0.1// lrwxrwxrwx 1 philips frgit 13 Aug 12 14:44 gcc-4.5.1/mpc - ../mpc-0.8.2// lrwxrwxrwx 1 philips frgit 14 Aug 12 14:44 gcc-4.5.1/mpfr - ../mpfr-2.4.2// Build directory: $HOME/tmp/GNU/build/sun4v/gcc-4.5.1 configure command: $HOME/tmp/GNU/src/sun4v/gcc-4.5.1/configure --prefix=$HOME/tmp/GNU/install/`uname -m`/gcc-4.5.1 --enable-languages=c,c++,fortran --with-gnu-as --with-as=$HOME/tmp/GNU/install/sun4v/binutils-2.20/bin/as --with-gnu-ld --with-ld=$HOME/tmp/GNU/install/sun4v/binutils-2.20/bin/ld make command: make bootstrap Below the last lines of 'make bootstrap' output: checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /home/philips/tmp/GNU/build/sun4v/gcc-4.5.1/sparc-sun-solaris2.10/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make[1]: Leaving directory `/nobackup/philips/tmp/GNU/build/sun4v/gcc-4.5.1' make: *** [bootstrap] Error 2 -- Summary: make bootstrap fails at:checking whether the GNU Fortran compiler is working... no Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: philippe_scelers at mentor dot com GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277
[Bug fortran/45277] make bootstrap fails at:checking whether the GNU Fortran compiler is working... no
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-08-13 12:01 --- Please run 'make check' for GMP and MPFR. Recent versions are miscompiled by older versions of GCC on this platform. I'd suggest sticking to the versions listed in http://gcc.gnu.org/install/prerequisites.html. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277
[Bug fortran/45277] make bootstrap fails at:checking whether the GNU Fortran compiler is working... no
--- Comment #2 from philippe_scelers at mentor dot com 2010-08-13 12:03 --- Created an attachment (id=21474) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21474action=view) requeste by error message output This file is requested for debugging: checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /home/philips/tmp/GNU/build/sun4v/gcc-4.5.1/sparc-sun-solaris2.10/libgfortran/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277
[Bug fortran/45277] make bootstrap fails at:checking whether the GNU Fortran compiler is working... no
--- Comment #3 from philippe_scelers at mentor dot com 2010-08-13 12:12 --- Subject: Re: make bootstrap fails at:checking whether the GNU Fortran compiler is working... no But I link GMP and MPFR into GCC source tree, how to make check on these? perhaps: cd objdir/gcc-4.5.1/gmp ; make check cd objdir/gcc-4.5.1/mpfr ; make check Please advise -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #34 from rogerio at rilhas dot com 2010-08-13 12:14 --- (In reply to comment #33) Not really, you could always subtract. However, far pointers gave predictable addresses, just like C99 says they pointer arithmetic should. They didn't. If you subtracted far pointers that pointed into different segment, the segment difference was ignored. If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. That's just ignorance on your part (nothing new, I guess I'm becoming used to that). You are saying things that you don't know. You said that without even knowing if there were any compilers back then that didn't do what you said. You just took your personal experience with some crappy compiler and generalized it for everyone. Wrong. What you don't know is that when you subtracted far pointers the compiler generated the code to change seg16:ofs16 into abs20. What you think is prohibitively expensive would come down to 4 instructions or something like that (2 shifts, 2 additions). But lets say 10. Is that prohibitively expensive?? If the user requested a pointer difference you would be happy as a compiler developer to just not compile (or produce an incorrect difference) instead of generating 10 machine instructions? Or 20? A compiler should NEVER EVER EVER refuse to compile (or compile bad code) because the resulting number of instructions is large. Your comment and opinion thus don't deserve any respect because we are defending the way to do a bad compiler. That claim is not just wrong, it is dumb. I'm not trying to offend you, I'm sure you are not dumb, but you let a dumb comment slip out. Anyway, again you are just plain wrong. The compilers I used back then did this operation well. In those days there were no real standards that developers would generally follow, and programmers used to rely on what they knew about a compiler. So I guess you might have used some crappy one that failed miserably at pointer arithmetic, and based your whole opinion that it is beller to compile bad arithmetic or not compile at all than to add 10 instructions to the code. Your ignorance is in not knowing that segmented addresses were already being abstracted to C programmers by mid-range compilers. I remember this being already done on 8088 compilers, abstraction of the underlying hardware was something every C compiler strived to do. No compiler I knew of didn't do an operation correctly because it had to generate 10 instructions or 20. or a loop. So you stated something as an absolute truth but failed to see that one single exception would prove you wrong. So you you threw yourself head on against the wall again. But don't worry, I think I know your type fairly well. You will probably just get right back up on the horse, shake it all off, forget about what you did wrong, and start anew with some other wrong statement. I'm basing this on your track record in our conversations, where almost 100% of your claims are wrong or miss the point. That is just impressive. In case I'm wrong about you my apologies. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. What the hell are you talking about? I personally disassembled code in the late 80's to see how the compiler implemented 32-bit arithmetic on a 286. It did, and it did it well. You weren't able to go beyond 16 bits in the 80's? Or are just making this stuff up? I'm sure you are making it up, on an 8-bit PIC I have written assembly code to do 32-bit shift-add and it uses up something like 12 instructions or so. Not hard at all. Not prohibitive at all. Again: you wished you were right, but you are wrong. You think you known, but you don't. But are you careful? No, you just keep throwing yourself against a wall. And you don't seem to realise that that is becomming a recurring pattern for you. Keep it up, it is fun to watch. And of course the subtraction of addresses of parameter is always meaningless in C, segmented or not, as pointed out multiple times. With or without cdecl. Yup, and multiple times you have been wrong. The cute C99 box you live in doesn't let you see beyond that. But param is not meaningless if the compiler adheres to cdecl, I've shown that numerous times, you are just unable to see (your bad). operation 1 - place parameters as cdecl (try to learn something here please, it is important that you don't run away and hide inside C99): push param3 to address X+8 on the stack push param2 to address X+4 on the stack push param1 to address X on the stack call function function: get address of param1: MUST BE X! get address of param2: MUST BE X+4! get address of param3: MUST BE X+8! But I guess you will just keep on losing yourself here because cdecl is outside of C99. And if you try to leave the C99 box your brain crashes and
[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-13 12:35 --- *** Bug 45275 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug fortran/45275] [4.6 Regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-13 12:35 --- *** This bug has been marked as a duplicate of 45266 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45275
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-13 12:36 --- We have two routines called 'my_assign' (in two different modules). When initializing the vtabs in the main program, we happen to use the wrong one: This is because the 'f2k_derived' namespace of 'trivial_gradient_type' contains the wrong symbol for 'my_assign'. Apparently the symbols are mixed up when reading the module files. The initialization of the vtab happens in gfc_trans_assign_vtab_procs (trans-expr.c). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug middle-end/44492] auto-inc-dec pushes PRE_MODIFY/PRE_INC into inline asm operands
--- Comment #24 from jakub at gcc dot gnu dot org 2010-08-13 12:47 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #35 from matz at gcc dot gnu dot org 2010-08-13 13:00 --- char* p1=(char*)0x3000; // address not pointing to any C-object in the C99 sense char* p2=(char*)0x4000; // address not pointing to any C-object in the C99 sense Can GCC users trust that p2-p1 will always return a predictable and well defined integer value of 0x1000 on any platform with 16-bit or more that GCC currently supports or that will come to support in the future? [ ] Yes [x] No -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #36 from matz at gcc dot gnu dot org 2010-08-13 13:14 --- If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. What you don't know is that when you subtracted far pointers the compiler generated the code to change seg16:ofs16 into abs20. What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset was unclear to you to expect that abs20==seg16*16+ofs16? The prohibitive expensive referred to the necessary lookup of the base in the LDT/GDT that would have been required for every far pointer subtraction. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. What the hell are you talking about? I personally disassembled code in the late 80's to see how the compiler implemented 32-bit arithmetic on a 286. It did, and it did it well. You weren't able to go beyond 16 bits in the 80's? Did I say that? Let's see: size limitation of ptrdiff_t that was 16bit. Nope. I didn't. The point being that if ptrdiff_t is only 16 bit, then no matter how fantastically capable the compiler was in emitting 32bit arithmetic, the result of subtracting to char pointers pointing more than 64KB (or in fact 32KB) apart would not fit into a ptrdiff_t. No, not me, I don't want to write nonsense on the web, Maybe you don't necessarily want to. But ... , well, there we are. I prefer to be clear headed. One never knows when stuff one wrote on the net will come back and bite one in the ass!! I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Much better than Pizarro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- Comment #14 from pj dot pandit at yahoo dot co dot in 2010-08-13 13:14 --- But surely if (as you suggest) swscanf had a DIE without DW_AT_external that would imply it was private to the compilation unit, which would be wrong. Hmmn...may be. DW_AT_specification tells you it's defined, DW_AT_external tells you it's visible. DW_AT_specification does not seem to be present all the time. It shows up in C++ program, but does not show up in a C program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-13 13:18 --- Subject: Re: pthread_default_stacksize_np failed. dave at hiauly1 dot hia dot nrc dot ca wrote: I think the answer is to provide a stub for pthread_default_stacksize_np which is linked in last in final executables. I believe the function is always present in the pthread libraries, both shared and archive. We already do similar things for a number of functions on hppa64-hpux11. Hmm, certainly worth an attempt. We were caught by subtle bugs with similar attempts on other platforms in the past, like stub added to lib X, and corner case situation Bla leads to a link order that gets us the stub instead of the real implementation in multi threaded apps. Same here. libtool isn't perfect and it links libc into shared libraries against the recommendation of HP. So, in applications with many libraries, it is not clear whether the dynamic loader will bind the real pthread functions or the stubs. The search rules are different for 32 and 64-bit hpux. The stub for pthread_default_stacksize_np would be in a archive library. The link option would essentially be the last item in the link command generated by the gcc driver. The stub will only be linked in if the symbol isn't resolved by one of the preceeding libraries. So, the above issue can't happen. That's probably settled by now :) Well no ... We're discussing the options internally. Thanks much for your feedback. Because of these issues, I have decided to revert the change on the branches (probably tomorrow). I will also try to add the stub on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #37 from paolo dot carlini at oracle dot com 2010-08-13 13:31 --- (In reply to comment #36) I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Well, I can easily imagine more funny things to do, some even summer-specific, but indeed, can be interesting, from a psychological point of view, I mean ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #6 from mikael at gcc dot gnu dot org 2010-08-13 14:25 ---
There is code to prevent duplicate names to be imported, but it is bypassed by
vtab and vtype stuff:
in module.c line 4373:
/* Exception: Always import vtabs vtypes. */
if (p == NULL (strcmp (xstrndup (name,5), vtab$) == 0
|| strcmp (xstrndup (name,6), vtype$) == 0))
p = name;
/* Skip symtree nodes not in an ONLY clause, unless there
is an existing symtree loaded from another USE statement. */
if (p == NULL)
{
st = gfc_find_symtree (gfc_current_ns-sym_root, name);
if (st != NULL)
info-u.rsym.symtree = st;
continue;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-13 14:31 --- (In reply to comment #6) There is code to prevent duplicate names to be imported, but it is bypassed by vtab and vtype stuff: This is fine. The problem is not in importing the vtab symbols, but importing the TBP targets (i.e. my_assign in the test case). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug c++/43922] internal compiler error: in copy_body_r, at tree-inline.c:748 when compiling with -fopenmp
--- Comment #2 from stephan dot aiche at fu-berlin dot de 2010-08-13 14:42 --- Just forgot to add the command line to reproduce the error c++ -DOpenMS_EXPORTS -DQT_DLL -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_DLL -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -DQT_NO_DEBUG -fopenmp -O3 -DNDEBUG -fPIC -Wall -Wextra -Wno-non-virtual-dtor -Wno-long-long --pedantic -fPIC -o FeatureFinder.C.o -c FeatureFinder.ii Any help would be appreciated since this problem is a blocker for our upcoming release Thanks Stephan -- stephan dot aiche at fu-berlin dot de changed: What|Removed |Added CC||stephan dot aiche at fu- ||berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43922
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #38 from rogerio at rilhas dot com 2010-08-13 14:47 --- (In reply to comment #36) If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. What you don't know is that when you subtracted far pointers the compiler generated the code to change seg16:ofs16 into abs20. What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset was unclear to you to expect that abs20==seg16*16+ofs16? The prohibitive expensive referred to the necessary lookup of the base in the LDT/GDT that would have been required for every far pointer subtraction. From wikipedia: Rather than concatenating the segment register with the address register, as in most processors whose address space exceeded their register size, the 8086 shifted the 16-bit segment only 4 bits left before adding it to the 16-bit offset (16·segment + offset), therefore producing a 20-bit external (or effective or physical) address from the 32-bit segment:offset pair. So there you go: the relation between effective abs20 address and seg16:ofs16 pair. And it is a linear relation: abs20=K*seg+ofs establishes a linear relation. Check your algebra, and check x86 operation before saying random stuff. Can you guess how tricky it is for a compiler to get an effective abs20 address out of a seg:ofs pair? abs20=seg*16+ofs (voilá! ...magic!!) What are you dreaming about LDT/GDT? Do you think you need any of that to get an abs20 from a seg16:ofs16 pair? Or maybe you think that a far qualifier would noke the compiler carry seg16 and ofs16 everywhere it went? You just made that stuff up again. Michael Michael Michael: what did I tell you about making stuff up? You don't need to prove to anyone that you are creative, will all know that by now. ... and if Wikipedia is not good enough for you then you can learn about segmentation and how to compute effective addresses in many places. All will teach you what Wikipedia shows. I would teach you if you paid me. No, scratch that: I woudn't, so I'll just leave you alone on this one. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. What the hell are you talking about? I personally disassembled code in the late 80's to see how the compiler implemented 32-bit arithmetic on a 286. It did, and it did it well. You weren't able to go beyond 16 bits in the 80's? Did I say that? Let's see: size limitation of ptrdiff_t that was 16bit. Nope. I didn't. The point being that if ptrdiff_t is only 16 bit, then no matter how fantastically capable the compiler was in emitting 32bit arithmetic, the result of subtracting to char pointers pointing more than 64KB (or in fact 32KB) apart would not fit into a ptrdiff_t. The code I used to do was somthing like long dif=ptr2-ptr1 (long was most often 32-bit back then). Why the hell did you bring ptrdiff_t to the conversation? I didn't get it, honestly. But if you brought it was was surely to show me that there was no point in doing 20-bit arithmetic because I would not be able to fit that result anywhere, right? Maybe not, you lost me with the whole ptrdiff_t that you decided to bring into the conversation. No, not me, I don't want to write nonsense on the web, Maybe you don't necessarily want to. But ... , well, there we are. Yup. You have still to make one valid claim, and I've been easily shooting you down everytime. And I back it up, isn't that an amazing concept? You should try it sometime. I prefer to be clear headed. One never knows when stuff one wrote on the net will come back and bite one in the ass!! I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Much better than Pizarro. ... is troll code for guy who doesn't forgive any false claims and repeatedly shoots down and squashes people who do that repeatedly like a mean son of a insert_repulsive_animal_here that he is? In that case thanks! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #39 from rogerio at rilhas dot com 2010-08-13 14:48 --- (In reply to comment #35) char* p1=(char*)0x3000; // address not pointing to any C-object in the C99 sense char* p2=(char*)0x4000; // address not pointing to any C-object in the C99 sense Can GCC users trust that p2-p1 will always return a predictable and well defined integer value of 0x1000 on any platform with 16-bit or more that GCC currently supports or that will come to support in the future? [ ] Yes [x] No Thanks. The comunity will be alerted to this. I'll get back to you when your name is in some famous place associated with this claim. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #40 from rogerio at rilhas dot com 2010-08-13 14:53 --- (In reply to comment #37) (In reply to comment #36) I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Well, I can easily imagine more funny things to do, some even summer-specific, but indeed, can be interesting, from a psychological point of view, I mean ;) Possibly... I'm on vacation, so this morning I just played a little bit of Half Life 2 on the console (yes, keep the wise cracks to yourself, I know I'm severely outdated when it comes to video games!). Anyway, after about half an hour of killing zombies and shooting down bad guys I got bored. Turned on the PC and THERE WAS MICHAEL It is easier and more entertaining to shoot him down than zombies with a 5 year old AI. Then I went for a swim, had lunch with the family, and the Sun got to strong to be outside. What else is there to do?? I know!!! Let's check on Michael again!! :-) So you see: I do have a problem. I will seek help. Promise. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/43922] internal compiler error: in copy_body_r, at tree-inline.c:748 when compiling with -fopenmp
--- Comment #3 from stephan dot aiche at fu-berlin dot de 2010-08-13 14:58 --- I just did some more tests and stumbled on sth interesting .. when compiling the same source on a Debian GNU/Linux 5.0.5 (lenny) I get the same error message internal compiler error: in copy_body_r, at tree-inline.c:748 but from a different part of the code /home/takifugu/aiche/RAID/open-ms-dev/release1.7/include/OpenMS/TRANSFORMATIONS/FEATUREFINDER/ProductModel.h: In member function 'virtual OpenMS::ProductModel2u OpenMS::ProductModel2u::operator=(const OpenMS::ProductModel2u)': /home/takifugu/aiche/RAID/open-ms-dev/release1.7/include/OpenMS/TRANSFORMATIONS/FEATUREFINDER/ProductModel.h:127: internal compiler error: in copy_body_r, at tree-inline.c:748 maybe this helps you guys compiler on Debian Lenny is g++ -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43922
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-08-13 15:11 --- I will try the other patch and see what this does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #41 from matz at gcc dot gnu dot org 2010-08-13 15:18 --- You should really adjust your glasses if you want to continue trolling with the high standards we're used to meanwhile: What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset So, I think it's pretty clear that I'm referring to the 80286, whereas you cite something ... From wikipedia: Rather than concatenating the segment register with the address register, as in most processors whose address space exceeded their register size, the 8086 shifted the 16-bit segment only 4 bits left ... about the 8086. To make it very obvious, even to you: 86 vs 286. As you have so huge experiences with such old processors, I'm sure you can guess what I meant with real segmentation aka protected mode now. In case you still can't and because we seem to start using wikipedia to back up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation . Now, implement a routine that subtracts two pointer for this memory model. You'll see that it requires bit-magic on the segment selector, lookup in the GDT or LDT and finally some 24bit arithmetic to produce the result. The arithmetic is of course trivial, the lookup is expensive. Doing it for every pointer subtract was what I called prohibitive expensive for a normal pointer subtraction. That, together with the fact that all segments are max 2^16 in size, and that it's impossible to map back all 24bit numbers into segmented addresses without generally adding new entries into the GDT/LDT made it useless to have pointer differences any larger than 16 bit, not impossible but useless in real compilers. Therefore the result of such a subtraction isn't always representable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #42 from matz at gcc dot gnu dot org 2010-08-13 15:25 --- [ ] Yes [x] No Thanks. The comunity will be alerted to this. I'll get back to you when your name is in some famous place associated with this claim. That's very good. Though I'm a bit confused because you only wanted to post my name everywhere if I got the answer wrong. Now, it's very obvious that my answer is the only correct one. Well, nevertheless I'm looking forward to become famous. Thanks for your help in that, though I fear somebody else will become even more famous than me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
--- Comment #16 from singler at kit dot edu 2010-08-13 15:48 --- I would really like to see this bug tackled. It has been confirmed two more times. Fixing it is easily done by lowering the spin count as proposed. Otherwise, please show cases where a low spin count hurts performance. In general, for a tuning parameter, a good-natured rather value should be preferred over a value that gives best results in one case, but very bad ones in another case. -- singler at kit dot edu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-13 15:48:18 date|| Target Milestone|4.4.5 |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
[Bug other/45278] New: -Wextra doesn't warn about (pointer 0 ).
$ cat ptr.cpp
extern void* p;
int main() { return ( p0 ? 1 : 0 ); }
$ g++ ptr.cpp -Wall -Wextra -O2 -S -fdump-tree-optimized
int main() ()
{
bb 2:
return 0;
}
gcc manual:
The option -Wextra also prints warning messages for the following cases:
#183; A pointer is compared against integer zero with , =, , or =.
so, this looks like a missed-diagnostics.
--
Summary: -Wextra doesn't warn about (pointer 0 ).
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86_64-gnu-linux
GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45278
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #43 from rogerio at rilhas dot com 2010-08-13 16:28 --- (In reply to comment #41) You should really adjust your glasses if you want to continue trolling with the high standards we're used to meanwhile: What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset So, I think it's pretty clear that I'm referring to the 80286, whereas you cite something ... Oh really? Because you so cleverly used the word real to lead me to believe you were talking about real mode 286? How clever of you, you were talking about protected mode after all. Ok, after interpreting your incorrect wording I can give you that: 286 protected mode was a pain. You just dropped your error rate to less than 100%, kudos!! (should adjust your phrasing though, if you want to be correctly inrepreted) From wikipedia: Rather than concatenating the segment register with the address register, as in most processors whose address space exceeded their register size, the 8086 shifted the 16-bit segment only 4 bits left ... about the 8086. To make it very obvious, even to you: 86 vs 286. As you have so huge experiences with such old processors, I'm sure you can guess what I meant with real segmentation aka protected mode now. There is no thing as real segmentation, you must have made it up. The Linux community seems to talk a little about it... but I never saw Intel say or write anything about it when I was studying the 286. Linux guys use that expression, is that why you thought it was standard? Wrong. What Intel defined was real mode and protected mode. So you see what you do when you don't use your words correctly and call it real segmentation? Of course it would look like segmentation in real mode. Your bad. Unless you can backup real segmentation with some official doccument from Intel, can you? In case you still can't and because we seem to start using wikipedia to back up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation . No mention of real segmentation. Is this what you wanted to show me? Now, implement a routine that subtracts two pointer for this memory model. You'll see that it requires bit-magic on the segment selector, lookup in the GDT or LDT and finally some 24bit arithmetic to produce the result. Yup, too much work. Better leave it alone and return some random pointer subtraction number. Better yet: don't compile such code. And never again guarantee to anyone anything about pointer subtraction unless it fits inside C99 box. I had one class on 286 which made us implement processes on a minimal protected mode OS for the 286. I can tell you it isn't that hard to read the LDT or GDT, and it didn't have any prohibitive performance penalty, contrary to what you claim. Maybe you are confusing yourself between reading from and writing to the GDT/LDT? Or maybe you can backup your claim that reading from GDT/LDT is prohibitive? The arithmetic is of course trivial, the lookup is expensive. Could you please back it up? That's contrary to my experience, you see, and since it lacks logic since the processor reads to those tables were designed to be fast to make it run fast... so I think you should back that up, otherwise it just looks like you are making it up (not to me though, I know it wasn't prohibitive). Doing it for every pointer subtract was what I called prohibitive expensive for a normal pointer subtraction. Yes, you are wrong to call it prohibitive. You just want to imagine it to be prohibitive so that you can stick to your claim that pointer subtraction result is not guaranteed by GCC *EVER* because of the 286. What a boring unsubstantiated argument. Without backing up such illogical claims its all just jiberish. So go ahead and find a techncal paper or report that shows that reading the LDT or GDT causes a significant performance penalty. Let's set a threshold: 50 instructions? So, ok: if you can find such a document that says that accessing those tables always costs 50 instructions or more then I'll grant you that the compiler should have an option to disable correct pointer subtraction. I will still not grant you an incorrect pointer subtraction by default, but I will insert apology here in that my experience with 286 was unexplainably better than yours. If you can't find such a document then insert apology here for making unsubstiated claims and forget about it (apology accepted). That, together with the fact that all segments are max 2^16 in size, and that it's impossible to map back all 24bit numbers into segmented addresses without generally adding new entries into the GDT/LDT made it useless to have pointer differences any larger than 16 bit, not impossible but useless in real compilers. Therefore the result of such a subtraction isn't always representable. In the copilers I used back then the far pointer was 32-bit, just like it was 32-bit on the
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #44 from rogerio at rilhas dot com 2010-08-13 16:30 --- (In reply to comment #35) char* p1=(char*)0x3000; // address not pointing to any C-object in the C99 sense char* p2=(char*)0x4000; // address not pointing to any C-object in the C99 sense Can GCC users trust that p2-p1 will always return a predictable and well defined integer value of 0x1000 on any platform with 16-bit or more that GCC currently supports or that will come to support in the future? [ ] Yes [x] No There you go, you are now famous. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism The comunity has been warned about GCC. It was a good day's work after all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #45 from redi at gcc dot gnu dot org 2010-08-13 16:32 --- Congratulations. Are you done now? What else are you hoping to achieve? Is this a cry for attention? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #46 from rogerio at rilhas dot com 2010-08-13 16:42 --- (In reply to comment #45) Congratulations. Are you done now? What else are you hoping to achieve? Is this a cry for attention? No much really. Now it is all up to the community. I just want everyone to know that computing pointer subtraction is not guaranteed to be accurate on GCC. My personal gains will be (possibly): 1) Maybe the community can force GCC to start making such guarantees. That would help all of us. The example I posted there is real, I'm not making anything up! 2) Showing all of you that a compiler should be more than just C99. A good compiler need to be more than C99. And an excelent compiler must be more than just C99. All of you confine your answers to C99 forgetting that a compiler will be used in many real world situation, for example in memory mapped devices. 3) Showing Michael that he says a lot of crap. Show him that he just shot himself in the foot for not thinking before speaking. Maybe get him to think before making claims? Even with all my warnings he didn't think of people that compile for memory mapped devices? He should think before he says something, he is not just some random guy like me, he is a representative of the GCC project and his answers (crap included) are GCC-binding. I confess I get some satisfaction out of that 3rd item. But I would do it even if I had the first 2. The community at large thinks more like I do, and expect the pointer subtraction to always return accurate results. I'm just warning them. I'm not lying. I'm not distorting anything. If it helps someone then good, otherwise it can«t harm anyone, right? That's it, really. As for the bugs I reported I have no further hope. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug fortran/45277] make bootstrap fails at:checking whether the GNU Fortran compiler is working... no
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-08-13 17:16 --- But I link GMP and MPFR into GCC source tree, how to make check on these? perhaps: cd objdir/gcc-4.5.1/gmp ; make check cd objdir/gcc-4.5.1/mpfr ; make check Yes, run make check in the build dir of GMP and MPFR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-13 17:23 --- Actually I think it's a duplicate of PR42769, or at least related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #26 from janus at gcc dot gnu dot org 2010-08-13 17:28 --- cf. also PR45271 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-08-13 17:24
---
With or without the other patch, the gimple code has:
main (integer(kind=4) argc, character(kind=1) * * argv)
[tx_f90_pointers.f90 : 30:0] {
integer(kind=4) D.1535;
static integer(kind=4) options.0[8] = {68, 511, 0, 0, 0, 1, 0, 1};
[tx_f90_pointers.f90 : 30:0] _gfortran_set_args (argc, argv);
[tx_f90_pointers.f90 : 30:0] _gfortran_set_options (8, [tx_f90_pointers.f90 :
30] options.0[0]);
[tx_f90_pointers.f90 : 30:0] test ();
[tx_f90_pointers.f90 : 30:0] D.1535 = 0;
[tx_f90_pointers.f90 : 30:0] return D.1535;
}
test ()
[tx_f90_pointers.f90 : 3:0] {
integer(kind=4) D.1540;
integer(kind=4) array1[10];
integer(kind=4) array2[100];
integer(kind=4) i;
struct array1_integer(kind=4) p1;
struct array1_integer(kind=4) p11;
[tx_f90_pointers.f90 : 3:0] p1.data = 0B;
[tx_f90_pointers.f90 : 3:0] p11.data = 0B;
[tx_f90_pointers.f90 : 12:0] p1.data = 0B;
[tx_f90_pointers.f90 : 3:0] i = 1;
[tx_f90_pointers.f90 : 3:0] if (i = 10) goto D.1537; else goto D.1538;
D.1537:
D.1539:
[tx_f90_pointers.f90 : 3:0] {
logical(kind=4) D.1529;
[tx_f90_pointers.f90 : 15:0] D.1540 = i + -1;
[tx_f90_pointers.f90 : 15:0] array1[D.1540] = i;
L.1:
[tx_f90_pointers.f90 : 3:0] D.1529 = i == 10;
[tx_f90_pointers.f90 : 3:0] i = i + 1;
[tx_f90_pointers.f90 : 3:0] if (D.1529 != 0) goto L.2; else goto D.1541;
D.1541:
}
[tx_f90_pointers.f90 : 3:0] goto D.1539;
D.1538:
L.2:
[tx_f90_pointers.f90 : 3:0] p1.dtype = 265;
[tx_f90_pointers.f90 : 3:0] p1.dim[0].lbound = 1;
[tx_f90_pointers.f90 : 3:0] p1.dim[0].ubound = 5;
[tx_f90_pointers.f90 : 3:0] p1.dim[0].stride = -2;
[tx_f90_pointers.f90 : 3:0] p1.data = array1[8];
[tx_f90_pointers.f90 : 3:0] p1.offset = 2;
[tx_f90_pointers.f90 : 3:0] p11.dtype = 265;
[tx_f90_pointers.f90 : 3:0] p11.dim[0].lbound = 1;
[tx_f90_pointers.f90 : 3:0] p11.dim[0].ubound = 5;
[tx_f90_pointers.f90 : 3:0] p11.dim[0].stride = 2;
[tx_f90_pointers.f90 : 3:0] p11.data = array1[0];
[tx_f90_pointers.f90 : 3:0] p11.offset = -2;
[tx_f90_pointers.f90 : 23:0] i = 1;
[tx_f90_pointers.f90 : 3:0] p1.dtype = 265;
[tx_f90_pointers.f90 : 3:0] p1.dim[0].lbound = 1;
[tx_f90_pointers.f90 : 3:0] p1.dim[0].ubound = 10;
[tx_f90_pointers.f90 : 3:0] p1.dim[0].stride = 1;
[tx_f90_pointers.f90 : 3:0] p1.data = array2[0];
[tx_f90_pointers.f90 : 3:0] p1.offset = -1;
[tx_f90_pointers.f90 : 28:0] p11 = p1;
}
The entire DO LOOP is one line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #47 from ubizjak at gmail dot com 2010-08-13 18:00 --- OK, here is the deal: Since you want this feature so much, I'm sure that everybody would gladly implement it for you, for - say - measly 5000 EUR. You can then offer this c-like compiler to the world and save the planet. Just imagine, how the link to this enhanced compiler would be a great addition to your Wikipedia entry! You can even call this custom compiler whatever you like, except gcc. You will rewrite the history! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-13 18:00 --- Dave, any news on this? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug libstdc++/45279] New: reading complex (nan,0) and (nan,nan): write o.k, reading back: wrong data read
In a C++ program I'd written data - complexlong real to a file: (66.184415158223105773,-0.00037139050691640109188) (nan,0) (nan,0) (nan,nan) (nan,0) (66.184390020754110227,0.00076665851805737529283) (66.201451462903545667,0.0097865244553575969136) (66.273663243057493816,0.011598247090358962108) (65.35171132660672394,-0.03138479279043892791) and so on. All written values are as expected. Reading back these data I get: (66.1844,-0.000371391) (0,0) (6.97431e-3261,0) (6.97431e-3261,0) (6.97431e-3261,0) and so on (exception: the first number after a line change is always read to (7.72947e-3833,0) ) There's no error message - it acts like a correct read -- Summary: reading complex (nan,0) and (nan,nan): write o.k, reading back: wrong data read Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kohlhz at t-online dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45279
[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)
--- Comment #5 from fang at csl dot cornell dot edu 2010-08-13 18:18
---
At least one fink-user has reported that Jack's latest packaging that
automatically uses --with-dwarf2 on darwin8 builds successfully (was on a G5,
built -j4). (My builds were aborted for other reasons, still working on it on
my G4.) Jack, do you plan to submit your configure{,.ac} patch, or just keep
it only in your package patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #7 from jv244 at cam dot ac dot uk 2010-08-13 18:20 --- (In reply to comment #6) With or without the other patch, the gimple code has: isn't the gimple output showing linenumbers even in the case where the .original dump is missing them ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug libstdc++/27904] operator to floating point variable does not support inf, infinity, or nan
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-13 18:39 --- *** Bug 45279 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||kohlhz at t-online dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/45279] reading complex (nan,0) and (nan,nan): write o.k, reading back: wrong data read
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 18:39 --- This has nothing to do with complex per se, it's simply about parsing nan, infinity, and so on. We'll reconsider the issue in the context of C++0x (but as a matter of fact I'm afraid we didn't manage to actually improve Stage 2 about that), but otherwise this is 27904. *** This bug has been marked as a duplicate of 27904 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45279
[Bug libstdc++/45280] New: Stream parsing of digit-then-e (with no exponent) now fails
In past versions of the C++ standard library, if I piped a string like 59e
into a double, it would set the double to '59' and set position of the get
pointer to after the e. This meant I had to check if the last char read was an
'e' and if so, back up, but that was OK.
Something changed (and I wish I could tell you when, but I don't know--probably
in my upgrade from ubuntu 9.04 to 10.04) so now when I do the same thing, the
stream parser just gets confused, sets the 'fail' bit, and sets the double to
0. Here's a test program:
#include sstream
#include iostream
using namespace std;
int main(int argc, char** argv)
{
stringstream withx, withe;
withx 59x;
withe 59e;
double num;
char cc;
withx num;
cc = withx.get();
cout From the string '59x', the streamed number is num , and the
next character is ' cc ' endl;
withe num;
cc = withe.get();
cout From the string '59e', the streamed number is num , and the
next character is ' cc ' endl;
cout tellg: withe.tellg() endl;
cout tellp: withe.tellp() endl;
cout eof? withe.eof() endl;
cout fail? withe.fail() endl;
cout bad? withe.bad() endl;
}
which outputs:
From the string '59x', the streamed number is 59, and the next character is 'x'
From the string '59e', the streamed number is 0, and the next character is
'#65533;'
tellg: -1
tellp: -1
eof? 0
fail?1
bad?0
Now, ideally, parsing '59e' should behave exactly the same as parsing '59x'--it
would notice that there's no exponent, decide the 'e' wasn't part of the
number, back up, export '59', and the next result of 'get' would return 'e'.
But barring that, going back to the old behavior of not failing and returning
59, even if the get position is post-e, would be great.
I apologize for not testing this in more recent builds--I did check the
changelog and the list of bug fixes, and didn't find this in there, though I
certainly could have missed it.
--
Summary: Stream parsing of digit-then-e (with no exponent) now
fails
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lpsmith at u dot washington dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #11 from bigotp at acm dot org 2010-08-13 20:11 ---
(In reply to comment #9)
(In reply to comment #8)
Hm, I only can see references to symbol not to either function or variable
declaration in the documentation. Can you cite the part that makes you
think
it restricts the use to functions?
It's documented in the section on function attributes, but not listed in the
section on variable attributes. Compare 'deprecated' or 'weak', which are
listed in both places.
Is there any intention to restrict use of weakref to functions? It seems to
be exactly what I want to use to allow a translation unit to reference a
memory-mapped register by its vendor-defined name, while not making that
name a global symbol that impacts other translation units, nor providing the
actual register address until the final link phase:
static volatile uint16_t P1IN __attribute((weakref(__P1IN)));
uint16_t c3 () { return P1IN; }
with __P1IN = 0x0020; in a linker script.
Other approaches seem to require that I have a definition for __P1IN
available at the time the object file is generated, which means I'd have a
potential for conflict if a different object file happened to include a
header that gave the register a different address; or that I use:
volatile uint16_t P1IN __attribute((weak));
uint16_t c3 () { return P1IN; }
which clutters the namespace.
Heck, I'll submit a patch to gcc/doc/extend.texi that explicitly allows use
of weakref on variables if that'd help.
--
bigotp at acm dot org changed:
What|Removed |Added
CC||bigotp at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug libstdc++/45281] New: performance/ext/pb_ds/priority_queue_text_modify_down_timing.cc fails at compile time
Today, after a few weeks, I ran check-performance, and this test didn't compile. I didn't manage to analyze the failure yet, and I will be away for a few days of vacations... This is the error: In file included from /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/common_type/priority_queue/string_form.hpp:43:0, from /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/performance/priority_queue/timing/modify_test.hpp:43, from /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/ext/pb_ds/priority_queue_text_modify_timing.hpp:41, from /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/ext/pb_ds/priority_queue_text_modify_down_timing.cc:32: /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/native_type/native_priority_queue.hpp: In member function void __gnu_pbds::test::native_priority_queueValue_Type, Vector, Cmp_Fn, Allocator::erase(__gnu_pbds::test::native_priority_queueValue_Type, Vector, Cmp_Fn, Allocator::const_reference) [with Value_Type = std::basic_stringchar, bool Vector = true, Cmp_Fn = std::lessstd::basic_stringchar , Allocator = std::allocatorchar, __gnu_pbds::test::native_priority_queueValue_Type, Vector, Cmp_Fn, Allocator::const_reference = const std::basic_stringchar]: /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/native_type/native_priority_queue.hpp:190:9: instantiated from void __gnu_pbds::test::native_priority_queueValue_Type, Vector, Cmp_Fn, Allocator::modify(__gnu_pbds::test::native_priority_queueValue_Type, Vector, Cmp_Fn, Allocator::const_reference, __gnu_pbds::test::native_priority_queueValue_Type, Vector, Cmp_Fn, Allocator::const_reference) [with Value_Type = std::basic_stringchar, bool Vector = true, Cmp_Fn = std::lessstd::basic_stringchar , Allocator = std::allocatorchar, __gnu_pbds::test::native_priority_queueValue_Type, Vector, Cmp_Fn, Allocator::const_reference = const std::basic_stringchar] /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/performance/priority_queue/timing/modify_test.hpp:234:17: instantiated from void __gnu_pbds::test::detail::push_modify_functorIt, Cntnr, __gnu_pbds::test::native_pq_tag::operator()(std::size_t) [with It = __gnu_cxx::__normal_iteratorconst std::pairstd::basic_stringchar, char*, std::vectorstd::pairstd::basic_stringchar, char , Cntnr = __gnu_pbds::test::native_priority_queuestd::basic_stringchar, true, std::size_t = long unsigned int] /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/performance/time/timing_test_base.hpp:108:2: instantiated from double __gnu_pbds::test::detail::timing_test_base::run_at_resolution(Functor, std::size_t) [with Functor = __gnu_pbds::test::detail::push_modify_functor__gnu_cxx::__normal_iteratorconst std::pairstd::basic_stringchar, char*, std::vectorstd::pairstd::basic_stringchar, char , __gnu_pbds::test::native_priority_queuestd::basic_stringchar, true, __gnu_pbds::test::native_pq_tag, std::size_t = long unsigned int] /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/performance/time/timing_test_base.hpp:77:4: instantiated from double __gnu_pbds::test::detail::timing_test_base::operator()(Functor) [with Functor = __gnu_pbds::test::detail::push_modify_functor__gnu_cxx::__normal_iteratorconst std::pairstd::basic_stringchar, char*, std::vectorstd::pairstd::basic_stringchar, char , __gnu_pbds::test::native_priority_queuestd::basic_stringchar, true, __gnu_pbds::test::native_pq_tag] /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/performance/priority_queue/timing/modify_test.hpp:316:70: instantiated from void __gnu_pbds::test::modify_testIt::operator()(Cntnr) [with Cntnr = __gnu_pbds::test::native_priority_queuestd::basic_stringchar, true, It = __gnu_cxx::__normal_iteratorconst std::pairstd::basic_stringchar, char*, std::vectorstd::pairstd::basic_stringchar, char ] /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/ext/pb_ds/priority_queue_text_modify_timing.hpp:85:19: instantiated from here /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/native_type/native_priority_queue.hpp:148:2: error: cannot bind __gnu_pbds::test::native_priority_queuestd::basic_stringchar, true::base_type lvalue to std::priority_queuestd::basic_stringchar, std::vectorstd::basic_stringchar, std::allocatorstd::basic_stringchar , std::lessstd::basic_stringchar /scratch/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_queue.h:459:7: error: initializing argument 1 of std::priority_queue_Tp, _Sequence, _Compare std::priority_queue_Tp, _Sequence, _Compare::operator=(std::priority_queue_Tp, _Sequence, _Compare) [with _Tp = std::basic_stringchar, _Sequence = std::vectorstd::basic_stringchar, std::allocatorstd::basic_stringchar , _Compare = std::lessstd::basic_stringchar , std::priority_queue_Tp, _Sequence, _Compare = std::priority_queuestd::basic_stringchar, std::vectorstd::basic_stringchar,
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 20:15 --- Yes, this is intended. We even have testcases about that. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #2 from lpsmith at u dot washington dot edu 2010-08-13 20:22 --- Is the reasoning explained somewhere? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-13 20:23 --- By the way, if you read 22.2.3.1 in C++98, it's clear that 'e' is *not* just any other character: after 'e', a sign is optional but at least a digit is compulsory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #4 from lpsmith at u dot washington dot edu 2010-08-13 20:34 --- Yes, exactly! Which is why the 'e' should not be parsed at all unless there is an optional sign and a compulsory digit following it. The 'e' in general is not compulsory. '59' is a valid double. The context is that I am parsing (among other things) chemical reactions. It is perfectly valid to have something like: 2EtOH - EtOHX -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug c++/45282] New: wrong decltype result for .*
This testcase should compile without error, as a .* is an rvalue if the LHS is
an rvalue.
struct A { int i; };
int A::*ipm = A::i;
template class T, class U class assert_same_type;
template class T class assert_same_typeT,T { };
assert_same_typedecltype(A().*ipm),int x2;
--
Summary: wrong decltype result for .*
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45282
[Bug c++/45282] wrong decltype result for .*
-- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-13 20:51:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45282
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #5 from lpsmith at u dot washington dot edu 2010-08-13 20:56 --- Followup: This still fails even if you're trying to pipe it into an integer and not a double. Integers, as per 22.2.3.1 in C++98, do not have an optional 'e' after them. (Though of course you could *cast* a floating point value to an integer.) Given that, I hope you won't mind if I reopen the bug. -- lpsmith at u dot washington dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-13 21:00 --- You are of course wrong. Parsing something like 59e as an integer type of course succeeds and gives 59. Really, we have *tons* of testcases about that in the testsuite. We know what we are doing ;) -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #7 from lpsmith at u dot washington dot edu 2010-08-13 21:14 --- You're right! Sorry; I apparently jumped to a conclusion while testing (but I did test!) I still disagree that an 'e' with no digit following can be reasonably construed as part of an improperly-formatted float, and think it should instead be considered not part of the float at all, since properly-formatted floats have both the e and the digit. I think you are erring on the side of assuming an error when a valid interpretation exists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #48 from rogerio at rilhas dot com 2010-08-13 21:16 --- (In reply to comment #47) OK, here is the deal: Since you want this feature so much, I'm sure that everybody would gladly implement it for you, for - say - measly 5000 EUR. You can then offer this c-like compiler to the world and save the planet. Just imagine, how the link to this enhanced compiler would be a great addition to your Wikipedia entry! You can even call this custom compiler whatever you like, except gcc. You will rewrite the history! It sounds like a good deal. Really, I'm not being sarcastic in any way. I would like to have 5000 to invest on GCC. Maybe you all got me wrong: the reason I wrote the 2 bug reports is because I do think GCC is a *very important project for the community*. I'm being honest. If GCC were not important I would not have gone to any trouble at all, yet alone spend several hours writing 2 or 3 complete reports (with files and snapshots) and many messages. Maybe it is time for you to understand what I really am all about. I say stuff about GCC, I've called lowest common denominator (and I mean it), but I still think it to be among the top 5 most important compiler projects in the world (including Microsoft's and Intel's and a bunch of comercial compilers). It could be top 1, if it weren't for being so confined to C99 and not *want* to go beyond it. And I would like to have 5K to put on GCC. As I said I know I can't demand anything, after all the thing is being offered to me! Even more than that: it is being offered to me without me having ever contributed with a bit. So, as I said before, I'm not demanding anything (nor could I). I was just hoping that you would see the importance of my feature (although I still call it a bug and not a feature, and if you want I can give you examples of why it is important to be able to initialize classes as function parameters). You didn't see it? Or you saw it but you don't agree that it is important? I'll insist, I'll bring new angles to the discussion. Still no? I'll insist some more, maybe get some other examples. Nothing still? Whatever, I'll shut up and go away, no problem. The reason I'm still here is (to a great extent) because of Michael... that guy just cracks me up. It is possibly the person that I've ever known that has such a high error rate (it was up to 100% for a while there!). But this conversation has stopped being about my bug reports a long long long long time ago. I'm on vacation, so I have had more time on my hands than I'm used to, and Half Life 2 bores me a little if I play it for too long! :-) ... so I keep comming back. As I said before I will seek help. Just one more, this is the last one!!! Promise!! I'll buy a new game and leave you all alone soon! :-) I posted the criticism on Wikipedia not to hurt anyone in particular. But I do criticize GCC for not being able to guarantee correct pointer arithmetic. And me, as a citizen of this world, have the right to make my criticism and post it where everybody can see and judge for themselves. And, being an important criticism, I should back it up. So I did, and posted 2 references. I was very careful not to write anything that might be incorrect or misleading. I quoted our conversation almost exactly. And even with the different words I made sure the content is exactly the same as in my conversation with Michael. I didn't lie. I didn't distort. I didn't exagerate. I didn't take it out of context. I said it like it is, no more, no less. So here is the deal to you: If you all agree with Michael then my Wikipedia post is correct and has a reason to exist, and people like me will want to be alerted to what it says. Programmers don't go around reading C99, generally speaking they just try to write good code. That's it. I would guess 90%+ of programmers don't go out checking if their line of code is C99 conformant or not. However, I believe their code can be more than 99.9% C99 conformant, so very little people have any problems. I'm one such programmer, I hadn't read C99 before talking to you but 99.9% of what I do falls completely within the things defined in C99. But there is a fraction of what I do that does not fall there, and I still have to do it. And like me there are many others, who have a fraction of their work fall outside C99 (without knowing). And the code still has to work. Always. Guaranteed. And we trust the compiler to give us the expected result. Always. Guaranteed. If I am wrong in trusting it then I want to be alerted. That's all I did in the Wikipedia post: alert people that do code for memory mapped devices and similar (like I often do). So if you think Michael is correct then he is, in fact, a hero. He is the one guy, on the face of this planet that I know of, that had the balls to come out and say beware of pointer subtraction when using GCC!!. No sarcasm here, I trully believe this. If he is, in fact, right then I will personally thank him because up
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-13 21:20 --- I'm not erring. We changes this behavior on purpose, after having also checked that *2* other, completely independent, implementations agree (ie, Dinkumware and Roguewave). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug c++/45278] -Wextra doesn't warn about (pointer 0 ).
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-13 21:28 --- It works with the C front-end but the C++ front-end fails to warn. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|other |c++ Ever Confirmed|0 |1 GCC build triplet|x86_64-gnu-linux| GCC host triplet|x86_64-gnu-linux| GCC target triplet|x86_64-gnu-linux| Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-08-13 21:28:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45278
[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-08-13
21:30 ---
(In reply to comment #5)
At least one fink-user has reported that Jack's latest packaging that
automatically uses --with-dwarf2 on darwin8 builds successfully (was on a G5,
built -j4). (My builds were aborted for other reasons, still working on it on
my G4.) Jack, do you plan to submit your configure{,.ac} patch, or just keep
it only in your package patch?
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00970.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #9 from lpsmith at u dot washington dot edu 2010-08-13 21:40 --- Fair enough! I still disagree, but I guess my task now is to get Dinkumware and Roguewave to change their implementations, and come back. I don't suppose you'd be swayed by Microsoft? I didn't think so ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails
--- Comment #10 from lpsmith at u dot washington dot edu 2010-08-13 21:41 --- Whoops, duh, dinkumware is ms. Never mind, it was a dumb joke anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
[Bug target/45264] Stack corruption with any function using frame
--- Comment #6 from darkdragon2000 at hotmail dot com 2010-08-13 22:30 --- OK thanks, is the code I attached here OK? I already submitted this to Atmel also (#605725). Last time I submitted a bug to them this is the reply I got back: Note that avr-gcc and avr-libC are open-source projects, which you may directly report bugs to (see http://www.nongnu.org/avr-libc/bugs.html). (In reply to comment #5) Marking this bug as INVALID because the AVR Toolchain 3.0.0.207 is not an officially released toolchain, and only in beta. If you have any potential bugs, then please send to avr AT atmel DOT com, and please CC me. AFAIK, Atmel did not (or should have not) sent you to here. When you do send a bug report, send a compilable test case that shows the bugs along with the command line you used, and especially show which device this is for. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264
[Bug libstdc++/45281] performance/ext/pb_ds/priority_queue_text_modify_down_timing.cc fails at compile time
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 22:38 --- Turns out this CH 15 (N3105). I'll implement it, at least as far as the container adaptors are concerned. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-13 22:38:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45281
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #49 from redi at gcc dot gnu dot org 2010-08-13 22:38 --- Please, start a blog and write your views somewhere else. PLEASE. You're rude, ignorant and annoying. (In reply to comment #48) of why it is important to be able to initialize classes as function parameters You clearly don't know what you're talking about. If you think the C++ language is incorrectly defined then take it up with the C++ Standard Committee, or your national standards body, not with GCC. GCC implements the C++ standard. If there's a problem with the standard, change the standard, not GCC. But the standard won't change in this respect. You cannot initialise a non-const reference with a temporary in C++, Microsoft's compiler is wrong to accept it, try Intel's compiler for confirmation if you don't believe me. Andrew already told you to read about rvalue-references, which allow you to bind a reference to a temporary, but you're too busy arguing to accept that maybe, JUST MAYBE, someone knows something you don't. So please, stop posting here and go away. Publish your ideas where someone gives a damn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #7 from sje at cup dot hp dot com 2010-08-13 22:39 --- Does memcpy|(ref-all.*ref-all) need to be (memcpy|(ref-all.*ref-all)) or perhaps (memcpy|ref-all.*ref-all). Everyplace else I see a | in a scan statement there are parentheses around the options. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #50 from redi at gcc dot gnu dot org 2010-08-13 22:40 --- Oh, and if you do get people to understand that pointer arithmetic is not always well-defined, that would be a good thing. There are other people who share you're incorrect understanding of the C and C++ languages, so educating them is a good thing. But you won't do that by posting here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug libstdc++/45283] New: performance/30_threads/future/polling.cc fails at compile time
I get the below. Jon, can you have a look? Thanks in advance... /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc: In function void poll(std::shared_futurevoid): /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc:25:13: error: class std::shared_futurevoid has no member named is_ready /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc: In function int main(): /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc:49:13: error: class std::shared_futurevoid has no member named is_ready -- Summary: performance/30_threads/future/polling.cc fails at compile time Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paolo dot carlini at oracle dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug libstdc++/45281] performance/ext/pb_ds/priority_queue_text_modify_down_timing.cc fails at compile time
--- Comment #2 from paolo at gcc dot gnu dot org 2010-08-14 00:09 --- Subject: Bug 45281 Author: paolo Date: Sat Aug 14 00:09:21 2010 New Revision: 163231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163231 Log: 2010-08-13 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/45281 * include/bits/stl_queue.h (queue(queue), operator=(queue), priority_queue(priority_queue), operator=(priority_queue)): Remove, per CH 15. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_queue.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45281
[Bug libstdc++/45281] performance/ext/pb_ds/priority_queue_text_modify_down_timing.cc fails at compile time
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-14 00:10 --- Fixed. -- 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=45281
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-14 00:19 --- oops, I see the problem -- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-14 00:19:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #51 from matz at gcc dot gnu dot org 2010-08-14 01:26 --- There you go, you are now famous. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism Thank you, that's encouraging, I just hope the language of that article won't be changed too much to also mention everyone else who has a clue. Because, you see, I'm of course very excited about me being famous now and about being the only one who knows the truth, but OTOH I fear there were some other clever people that happen to agree with me, and I now see a real danger of those replacing me in that wikipedia article. Even worse would be that the list of names would be too large to mention in wikipedia and that the list would be replaced by some more unspecific phrases like people who actually understood the standard or the like. The comunity has been warned about GCC. Which community? Rogerio-cdecl church followers? In that case I'm happy, because I'll expect less bug-reports from supporters of that specific religion. I'll continue to feel sorry for them (especially because I've learned over the conversation that you might actually influence new programmers, which is a terrible thing to do for you) but am not particularly looking forward to seeing misguided and crippled attempts of creating meagre imitations of stumbling pseudo bug-reports, especially because we can have the best there is: Rilhas bugs! If, OTOH, you mean a different community, like for instance that consisting of people who actually write C source code, I don't see any warning about using GCC for them. If anything, it's more like an invitation to use GCC for developing because it's more standard compliant than other compilers. It was a good day's work after all. You mean writing down incoherent brain-dumps? Uhm, well, if that's all your day-work is about... more power to you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug target/43999] Gcc (lib1funcs.asm) doesn't build on ARM/Thumb2
--- Comment #6 from mbarenh at alios dot org 2010-08-14 01:27 --- Created an attachment (id=21475) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21475action=view) patch fixes build on thumb2 platform - fixes typos -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43999
[Bug testsuite/37074] gcc.dg/torture/stackalign/builtin-apply-4.c failed with SSE2
--- Comment #7 from hjl at gcc dot gnu dot org 2010-08-14 02:29 --- Subject: Bug 37074 Author: hjl Date: Sat Aug 14 02:28:57 2010 New Revision: 163239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163239 Log: Support --with-fpmath=sse for x86. gcc/ 2010-08-13 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-02-26 H.J. Lu hongjiu...@intel.com * config.gcc: Support --with-fpmath=sse for x86. * config/i386/ssemath.h: New. * doc/install.texi (--with-fpmath=sse): Documented. gcc/testsuite/ 2010-08-13 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-02-26 H.J. Lu hongjiu...@intel.com PR testsuite/37074: * gcc.dg/torture/stackalign/stackalign.exp: Add -mno-mmx to x86. Added: branches/ix86/gcc-4_4-branch/gcc/config/i386/ssemath.h Modified: branches/ix86/gcc-4_4-branch/gcc/ChangeLog.ix86 branches/ix86/gcc-4_4-branch/gcc/config.gcc branches/ix86/gcc-4_4-branch/gcc/doc/install.texi branches/ix86/gcc-4_4-branch/gcc/testsuite/ChangeLog.ix86 branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/stackalign/stackalign.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37074
