[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #19 from burnus at gcc dot gnu dot org 2010-09-10 06:02 --- Subject: Bug 45186 Author: burnus Date: Fri Sep 10 06:01:50 2010 New Revision: 164143 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164143 Log: 2010-09-10 Tobias Burnus bur...@net-b.de PR fortran/45186 * trans.h (build1_stat_loc, build2_stat_loc, build3_stat_loc, build4_stat_loc): New inline functions. (build1_loc, build2_loc, build3_loc, build4_loc): New macros. (build1_v, build2_v, build3_v, build4_v): Use input_location as locus. * trans-array.c (gfc_trans_scalarized_loop_end, gfc_conv_array_parameter): Replace build[1-4] by build[1-4]_loc. * trans.c (gfc_build_addr_expr, gfc_build_array_ref, gfc_finish_wrapped_block): Ditto. * trans-decl.c (gfc_init_default_dt, init_intent_out_dt): Ditto. * trans-expr.c (gfc_conv_missing_dummy, gfc_trans_alloc_subarray_assign, gfc_trans_zero_assign): Ditto. * trans-openmp.c (gfc_omp_clause_default_ctor, gfc_trans_omp_critical, gfc_trans_omp_parallel, gfc_trans_omp_parallel_do, gfc_trans_omp_parallel_sections, gfc_trans_omp_parallel_workshare, gfc_trans_omp_sections gfc_trans_omp_single, gfc_trans_omp_task, gfc_trans_omp_workshare): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #20 from jv244 at cam dot ac dot uk 2010-09-10 06:36 --- Tobias, many thanks for working on this... I mentioned this before in the PR, but it would be very good if some line number testcases were added to the regression tests. Both for performance measurements and debugging, this is essential info, and it is too remarkable good lineno info could 'disappear' from a released (4.5) compiler just like that. If there would be some semi-automatic way of checking the lineno quality (such as e.g. in the original dump line numbers should always increase??), I'd be happy to give it a try on CP2K. Joost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug libstdc++/45628] New: std::fstream::tellg invalidates I/O buffer
Querying the position in a file uses filebuf::seekoff( 0, ios::cur ). Although the Standard specifies that this combination of parameters does not flush putback or the output sequence, it does anyway, which results in a performance hit. (§27.8.1.4/11) Regression: http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/fstream.tcc?r1=68163r2=68420 (@@ -473,41 +486,26 @@) This has been broken a long time! -- Summary: std::fstream::tellg invalidates I/O buffer Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: potswa at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #1 from potswa at mac dot com 2010-09-10 07:09 --- Created an attachment (id=21762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21762action=view) simple testcase This little program attempts to read three characters from its own source, checking the position each time. Reading three bytes from buffered file should only underflow once, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #21 from burnus at gcc dot gnu dot org 2010-09-10 07:25 --- (In reply to comment #20) many thanks for working on this... I mentioned this before in the PR, but it would be very good if some line number testcases were added to the regression tests. I concur - with -dump-tree-original-lineno this should be possible. If there would be some semi-automatic way of checking the lineno quality (such as e.g. in the original dump line numbers should always increase??) No! As the example in comment 18 shows the line numbers should not always monotonically increase. Or at least I expect the i = i + 1 to be associated with the line do i = 1, 10 rather than with the line a(i) = b(i) as the gfortran currently does. If you disagree, I can simply close this PR as fixed ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45629] New: libgfortran/io/list_read.c:1872:10: warning: variable 'elem' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
At least on MinGW64 (as reported by nightstrike), the following warning is
printed when compiling libgfortran:
libgfortran/io/list_read.c:1872:10: warning: variable 'elem' might be clobbered
by 'longjmp' or 'vfork' [-Wclobbered]
If one looks at the source, one sees:
1869 list_formatted_read (st_parameter_dt *dtp, bt type, void *p, int kind,
1870 size_t size, size_t nelems)
1871 {
1872size_t elem;
[...]
1880for (elem = 0; elem nelems; elem++)
1881 {
1882dtp-u.p.item_count++;
1883list_formatted_read_scalar (dtp, type, tmp + stride*elem, kind,
size);
with
1704 list_formatted_read_scalar (st_parameter_dt *dtp, volatile bt type,
void *p,
1710jmp_buf eof_jump;
However, I do not see how elem itself gets clobbered - thus the warning looks
bogus to me, but I have only glanced at the code.
--
Summary: libgfortran/io/list_read.c:1872:10: warning: variable
'elem' might be clobbered by 'longjmp' or 'vfork' [-
Wclobbered]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45629
[Bug bootstrap/45630] New: [4.6 Regression] Revision 164050 breaks bootstrap on powerpc-apple-darwin9
Revision 164050 breaks bootstrap on powerpc-apple-darwin9 ... /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/sys-include-c -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.6-work/gcc -I../../gcc-4.6-work/gcc/. -I../../gcc-4.6-work/gcc/../include -I../../gcc-4.6-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.6-work/gcc/../libdecnumber -I../../gcc-4.6-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -DCLOOG_PPL_BACKEND../../gcc-4.6-work/gcc/dwarf2out.c -o dwarf2out.o ../../gcc-4.6-work/gcc/dwarf2out.c: In function 'get_ref_die_offset_label': ../../gcc-4.6-work/gcc/dwarf2out.c:6549:5: error: format '%lld' expects type 'long long int', but argument 4 has type 'dw_offset' [-Werror=format] cc1: all warnings being treated as errors -- Summary: [4.6 Regression] Revision 164050 breaks bootstrap on powerpc-apple-darwin9 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45630
[Bug middle-end/45631] New: devirtualization with profile feedback does not work for function pointers
Following simple example:
#include stdio.h
static void a(void)
{
printf(a\n);
}
static void b(void)
{
printf(b\n);
}
static void __attribute__((noinline)) do_call(void (*p)(void))
{
p();
}
int main(void)
{
int i;
for (i = 0; i 30; i++)
do_call((i%4) 3 ? a : b);
return 0;
}
I compile it with profile feedback and generate feedback data
% gcc -O3 -fprofile-generate x.c
% ./a.out
... output ...
% gcc -O3 -fprofile-use x.c
Examining the output do_call of the final code is just:
00400520 do_call:
400520: ff e7 jmpq *%rdi
But I would have expected the profile feedback code to detect
that a is much more likely than b in the indirect call
and inline a through devirtualization.
--
Summary: devirtualization with profile feedback does not work
for function pointers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
[Bug middle-end/45632] New: const function pointer propagation issues with inlining
The attached test case is testing inlining of const function pointers in a typical OO code written in C situation. The code shows two optimization problems: - a_foo is inlined into main, b_foo is not. The only difference is that new_a() returns a const pointer and new_b() does not. I would have assumed that gcc detects that the pointer coming out of new_b() is const. - p-ops-op2 is never inlined, not even for a, even though the compiler should have enough information to do so (everything that is passed in is const). I assume this is because cloning does not work through function pointers? -- Summary: const function pointer propagation issues with inlining Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
[Bug middle-end/45632] const function pointer propagation issues with inlining
--- Comment #1 from andi-gcc at firstfloor dot org 2010-09-10 08:50 --- Created an attachment (id=21763) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21763action=view) testcase, compiled with -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-09-10 09:15 --- (In reply to comment #5) I agree that the front-end is missing a statement walker to infer information out of the code. I have a patch for a more general statement walker, which I will probably submit after the weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
[Bug middle-end/45632] const function pointer propagation issues with inlining
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org, jamborm at gcc dot ||gnu dot org Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
[Bug bootstrap/45630] [4.6 Regression] Revision 164050 breaks bootstrap on powerpc-apple-darwin9
-- 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=45630
[Bug tree-optimization/45626] [4.6 Regression] Segfault in fold_const_aggregate_ref
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Segfault in |[4.6 Regression] Segfault in |fold_const_aggregate_ref|fold_const_aggregate_ref Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45626
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #41 from rguenth at gcc dot gnu dot org 2010-09-10 09:33 --- (In reply to comment #40) A test installation based on a copy of the GCC Bugzilla database (snapshot taken today, September 9) and upgraded to Bugzilla 3.6.2 is now live at http://gcc.gnu.org/bugzilla-test/. Please give it a look, and file bugs related to missing or broken customizations in the new Bugzilla product on the test installation, i.e. using this link: http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla Note that I didn't port *any* customization yet, so you probably have a lot to say. ;) You probably should announce this on g...@gcc.gnu.org. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug rtl-optimization/45621] [4.6 Regression] ICE: verify_cgraph_node failed: inlined_to pointer is set but no predecessors found with -fipa-cp-clone -flto
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org, jamborm at gcc dot gnu ||dot org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45621
[Bug c++/45605] Missed devirtualization
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-10 09:42 --- Subject: Bug 45605 Author: hubicka Date: Fri Sep 10 09:42:20 2010 New Revision: 164148 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164148 Log: PR tree-optimization/45605 * cp/class.c (build_vtbl_initializer): Avoid wrong type conversion in ADDR_EXPR Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/inherit/covariant7.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug ada/43993] Foreign thread results in Task_Alternate_Stack being used unitialized on linux
--- Comment #1 from charlet at gcc dot gnu dot org 2010-09-10 09:47 --- Fixed by revision 164149 -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43993
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #16 from redi at gcc dot gnu dot org 2010-09-10 09:55 --- There certainly is a race condition: there's no ordering between pthread_cancel and pthread_testcancel so the main thread can run f2(50) before thread2 calls pthread_cancel, which is why you see it sometimes run beyond the cancellation point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #42 from jv244 at cam dot ac dot uk 2010-09-10 09:58 --- (In reply to comment #40) Please give it a look, and file bugs related to missing or broken customizations in the new Bugzilla product on the test installation, i.e. using this link: http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla FYI, I can't login to the new bugzilla because my current password is 5 chars, which seemingly is less than the minimum for the new bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #17 from redi at gcc dot gnu dot org 2010-09-10 10:11 --- (In reply to comment #15) In particular, it does not appear that the thread is being reliably cancelled at the pthread_testcancel call - sometimes f2 seems to run beyond the pthread_testcancel, As I said above, that's consistent with f2(50) executing before pthread_cancel. which causes the throw to execute, and results in an abort (seems to want to act like an uncaught exception propagated out). If you comment out the throw, f2 will sometimes continue to construct additional objects past 50. I have also noticed that sometimes a bunch of the Y objects get destructed, but then the program suddenly summarily exits. I think that's because f2(50) leaves cancellation enabled and writing to cout is a cancellation point, so the exit happens when some ~Y destructor coincides with thread2 calling pthread_cancel. I also tried setting the cancellation type to asynchronous, but that doesn't make any difference - sometimes it works, sometimes it don't. Its very unpredictable. Yes, race conditions tend to have unpredictable results. If I change the condition in f2 to (i = 50) and disable cancellation again after the call to pthread_testcancel then I get more predictable behaviour, because that ensures that the only cancellation points are the calls to pthread_testcancel in f2, which still occur in f2(51), f2(52) etc. i.e. cancellation still occurs at the intended place even if f2(50) happens before the call to pthread_cancel. That seems to validate my theory that the cancel happens after f2(50), and so takes effect at the first cancellation point after the cancellation request. I don't think there's a gcc or glibc bug here, just non-portable code with indeterminate behaviour. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #43 from burnus at gcc dot gnu dot org 2010-09-10 10:29 --- The attachment is not viewable in your browser due to security restrictions enabled by Bugzilla. In order to view the attachment, you first have to download it. I think at least text/* attachments should be shown. I think the restriction is to avoid problems with, e.g., HTML attachments, which can steal cookies. Thus some sites (like bugzilla.mozilla.org) use a different (sub)domain for the attachments. (A different subdomain would be fine for me as well - as would be HTTPS [at least for the login] but I think that's an item for overseers.) In any case, I would like to see the possibility to view patches and examples w/o downloading. Example: http://gcc.gnu.org/bugzilla-test/attachment.cgi?id=21126action=edit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #44 from LpSolit at netscape dot net 2010-09-10 10:34 --- (In reply to comment #43) I think at least text/* attachments should be shown. Ah yes, sorry, I forgot to enable the allow_attachment_display parameter (which is off by default). This is now fixed. Thanks for catching that! :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #45 from jakub at gcc dot gnu dot org 2010-09-10 10:46 ---
The Log In line in elinks looks quite weird. There is
a text field Bugzilla_login, then Bugzilla_password (both expected), but then
there is another text field prefilled with password:
input id=Bugzilla_login_top
class=bz_login
name=Bugzilla_login
onfocus=mini_login_on_focus('_top')
input class=bz_password
id=Bugzilla_password_top
name=Bugzilla_password
type=password
input class=bz_password bz_default_hidden bz_mini_login_help type=text
id=Bugzilla_password_dummy_top value=password
onfocus=mini_login_on_focus('_top')
Took me a while to figure out one shouldn't input password in there...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug bootstrap/45630] [4.6 Regression] Revision 164050 breaks bootstrap on powerpc-apple-darwin9
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-10 10:52 --- Subject: Bug 45630 Author: jakub Date: Fri Sep 10 10:52:16 2010 New Revision: 164163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164163 Log: PR bootstrap/45630 * dwarf2out.c (get_ref_die_offset_label): Use %ld instead of HOST_WIDE_INT_PRINT_DEC to print ref-die_offset. (implicit_ptr_descriptor): Return NULL if dwarf_strict. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45630
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-10 10:55 --- _M_terminate_output, correctly, does nothing in this case, cannot be the problem, and there is nothing wrong wrt the standard mandated behavior. The problem is that in our implementation, similarly to traditional C stdio impls, reading and writing are completely separate operations, and the user switches between the two with seeks, essentially. Any seek puts back the internal status to uncommitted (_M_reading = false, _M_writing = false) and afterwards the user can start *either* reading or writing, irrespective of the previous history, and the seek logic doesn't know what will actually happen in the future, of course. The user should not perform redundant seeks, because they have a cost, they do something more than just seeking. On the other hand, a series of read or write operations has maximum performance, we don't think we could possibly do better. Thus, I'm open to ideas, but I don't think that within the current design one can change / improve much. Note that the patch you linked is exactly the one implementing the above semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug tree-optimization/45633] New: [4.6 regression] internal compiler error: verify_stmts failed
gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --prefix=/usr --disable-win32-registry --enable-threads=posix --enable-languages=c,c++,lto --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp Thread model: posix gcc version 4.6.0 20100910 (experimental) (GCC) COLLECT_GCC_OPTIONS='-MMD' '-MF' 'libmpcodecs/vd_ffmpeg.d' '-MT' 'libmpcodecs/vd_ffmpeg.o' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wundef' '-Wdisabled-optimization' '-Wno-pointer-sign' '-Wdeclaration-after-statement' '-std=gnu99' '-Wall' '-Wno-switch' '-Wno-parentheses' '-Wpointer-arith' '-Wredundant-decls' '-O4' '-pipe' '-ffast-math' '-fomit-frame-pointer' '-D' '_LARGEFILE_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-D' '_LARGEFILE64_SOURCE' '-I' 'libdvdread4' '-I' '.' '-march=core2' '-mfpmath=sse' '-fno-common' '-I' '/usr/include/freetype2' '-c' '-o' 'libmpcodecs/vd_ffmpeg.o' '-v' '-save-temps' /usr/libexec/gcc/i686-pc-cygwin/4.6.0/cc1.exe -E -quiet -v -I libdvdread4 -I . -I /usr/include/freetype2 -MMD libmpcodecs/vd_ffmpeg.d -MF libmpcodecs/vd_ffmpeg.d -MT libmpcodecs/vd_ffmpeg.o -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../../include/w32api -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D _LARGEFILE64_SOURCE libmpcodecs/vd_ffmpeg.c -march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2 -march=core2 -mfpmath=sse -std=gnu99 -Wstrict-prototypes -Wmissing-prototypes -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -ffast-math -fomit-frame-pointer -fno-common -O4 -fpch-preprocess -o vd_ffmpeg.i ignoring duplicate directory /usr/include ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../../include/w32api #include ... search starts here: #include ... search starts here: libdvdread4 . /usr/include/freetype2 /usr/lib/gcc/i686-pc-cygwin/4.6.0/include /usr/local/include /usr/lib/gcc/i686-pc-cygwin/4.6.0/include-fixed /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/include /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../include/w32api End of search list. COLLECT_GCC_OPTIONS='-MMD' '-MF' 'libmpcodecs/vd_ffmpeg.d' '-MT' 'libmpcodecs/vd_ffmpeg.o' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wundef' '-Wdisabled-optimization' '-Wno-pointer-sign' '-Wdeclaration-after-statement' '-std=gnu99' '-Wall' '-Wno-switch' '-Wno-parentheses' '-Wpointer-arith' '-Wredundant-decls' '-O4' '-pipe' '-ffast-math' '-fomit-frame-pointer' '-D' '_LARGEFILE_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-D' '_LARGEFILE64_SOURCE' '-I' 'libdvdread4' '-I' '.' '-march=core2' '-mfpmath=sse' '-fno-common' '-I' '/usr/include/freetype2' '-c' '-o' 'libmpcodecs/vd_ffmpeg.o' '-v' '-save-temps' /usr/libexec/gcc/i686-pc-cygwin/4.6.0/cc1.exe -fpreprocessed vd_ffmpeg.i -march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2 -quiet -dumpbase vd_ffmpeg.c -march=core2 -mfpmath=sse -auxbase-strip libmpcodecs/vd_ffmpeg.o -O4 -Wstrict-prototypes -Wmissing-prototypes -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -std=gnu99 -version -ffast-math -fomit-frame-pointer -fno-common -o vd_ffmpeg.s GNU C (GCC) version 4.6.0 20100910 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.6.0 20100825 (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 GNU C (GCC) version 4.6.0 20100910 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.6.0 20100825 (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: 4bea862be3a27aad0f75be2c3cad166f libmpcodecs/vd_ffmpeg.c: In function init: libmpcodecs/vd_ffmpeg.c:428:9: warning: AVPaletteControl is deprecated (declared at ./libavcodec/avcodec.h:2879) [-Wdeprecated-declarations] libmpcodecs/vd_ffmpeg.c: In function decode: libmpcodecs/vd_ffmpeg.c:917:6: warning: return discards const qualifier from pointer target type [enabled by default] libmpcodecs/vd_ffmpeg.c: At top level: libmpcodecs/vd_ffmpeg.c:84:25: warning: get_format declared static but never defined [-Wunused-function] libmpcodecs/vd_ffmpeg.c: In function draw_slice: libmpcodecs/vd_ffmpeg.c:489:13: error: type mismatch
[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #1 from jojelino at gmail dot com 2010-09-10 11:19 --- Created an attachment (id=21764) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21764action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45633
[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-10 11:29 --- Are you really using the fortran-dev branch? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 Version|fortran-dev |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45633
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #21 from burnus at gcc dot gnu dot org 2010-09-10 12:09 --- Created an attachment (id=21765) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21765action=view) Updated patch Updated patch to fix review issues and the Cray patch issue. I won't be able to work on this (i.e. regtest + submit) for the next days thus I put it here. Cf. http://gcc.gnu.org/ml/fortran/2010-09/msg00198.html and http://gcc.gnu.org/ml/fortran/2010-09/msg00234.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #21265|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-10 12:09 --- I *think* it can work to minimally change what we have now to not reset the get area buffers when (0, ios::cur) and we have been reading: as far as I can see, if in that specific case we get back to reading again, the get area remains completely valid indeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
-- 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-09-10 12:11:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #22 from burnus at gcc dot gnu dot org 2010-09-10 12:12 --- (In reply to comment #21) Created an attachment (id=21765) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21765action=view) [edit] Updated patch Note: I forgot to include the test case from attachment 21265 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #3 from jojelino at gmail dot com 2010-09-10 12:13 --- (In reply to comment #2) Are you really using the fortran-dev branch? $ git branch * trunk it is trunk. i don't recognize how fortran-dev version have been selected. maybe i've mistaken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45633
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-10 12:20 --- Does not work: when we reach the end of the buffer and we access again the file to refill it, we start reading from the wrong position, the position we seeked to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-10 12:36 --- To clarify: when we start reading in a buffered mode, the first underflow reads the buffer and leaves the physical file at the first char beyond the buffer. If we do afterwards a seek to the current reading position, belonging to the buffer, the physical position along the file also changes of course, an underlying fseek is performed. Then, if we don't refresh the buffer with a new underflow, an inconsistency is born: the physical position along the file doesn't correspond to the first char after the buffer and the next underflow will read from the wrong position. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug tree-optimization/45598] [4.6 Regression] ICE; in build_int_cst_wide, at tree.c:1218
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-10 12:59 --- The test in comment #0 has been fixed by revision 164111. However it seems that 191.fma3d in SPEC CPU 2K is not fixed by this revision (see http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00913.html ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45598
[Bug middle-end/45634] New: [4.6 regression] Revision 163973 faild to compile 191.fma3d in SPEC CPU 2K
On Linux/x86-64, revision 163997 failed to build 191.fma3d in SPEC CPU 2K: [...@gnu-27 0001]$ /export/gnu/import/svn/gcc-test/usr/bin/gfortran -c -o getirv.o -DSPEC_CPU2000_LP64 -O3 -funroll-loops -ffast-math getirv.f90 getirv.f90: In function #65533;rcrdrd#65533;: getirv.f90:213:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-27 0001]$ This is caused by revision 163973: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00265.html It isn't fixed as of revision 164143. -- Summary: [4.6 regression] Revision 163973 faild to compile 191.fma3d in SPEC CPU 2K Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45634
[Bug middle-end/45634] [4.6 regression] Revision 163973 faild to compile 191.fma3d in SPEC CPU 2K
-- 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=45634
[Bug tree-optimization/45598] [4.6 Regression] ICE; in build_int_cst_wide, at tree.c:1218
--- Comment #5 from dominiq at lps dot ens dot fr 2010-09-10 13:24 --- Since pr45634 has been opened for the failure of 191.fma3d in SPEC CPU 2K, I am closing this one as fixed. Thanks for the commit. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45598
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC
-- 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=45612
[Bug c++/45606] [4.5/4.6 Regression] match a method prototyped a typedef alias with the original type (using stdlib)
-- 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=45606
[Bug rtl-optimization/45593] [4.5/4.6 regression] segfault with -Os
-- 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=45593
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
-- 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=45577
[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45470
[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-10 13:26 ---
(In reply to comment #6)
(In reply to comment #5)
I see before SLP:
bb 2:
MEM[(struct A *)this_1(D)].a = 0;
MEM[(struct A *)this_1(D)].b = 0;
MEM[(struct A *)this_1(D)].c = 0;
[LP 2] MEM[(struct A *)this_1(D) + 12B].a = 0;
and after:
bb 2:
vect_cst_.1_16 = { 0, 0, 0, 0 };
vect_p.5_17 = MEM[(struct A *)this_1(D)].a;
M*vect_p.5_17{misalignment: 0} = vect_cst_.1_16;
so EH info has not been properly transfered.
How should it be done? Is it ok to assume that if one of the old stmts can
throw, then we can set TREE_THIS_NOTRAP for the new access to 0? (and then we
can call maybe_duplicate_eh_stmt (new_stmt, old_stmt)).
Or maybe it's better to avoid vectorization?...
I think it's best to avoid vectorization if one of the old stmts can
throw.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45470
[Bug middle-end/45634] [4.6 regression] Revision 163973 faild to compile 191.fma3d in SPEC CPU 2K
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-10 13:39 --- [...@gnu-16 0001]$ cat pr45634.f90 SUBROUTINE RCRDRD (VTYP) CHARACTER(4), INTENT(OUT) :: VTYP CHARACTER(1), SAVE :: DBL = D VTYP = DBL END [...@gnu-16 0001]$ /export/gnu/import/svn/gcc-test/usr/bin/gcc -S -O2 pr45634.f90 pr45634.f90: In function \u2018rcrdrd\u2019: pr45634.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-16 0001]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45634
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #6 from don dot wakefield at gmail dot com 2010-09-10 14:06 --- Re: comment 5 - what is needed is for filebuf::seekoff(0,ios::cur) to: 1) *not* invalidate the buffer 2) *not* move the file pointer since all that special case asks is where am I in the 'logical' file? This can be accomplished by having filebuf::seekoff() recognize an off_type of 0, and a seekdir of cur, and special-case the code to call _M_file.seekoff(0,cur) (not moving the file pointer, right?) and then adjusting the resulting pos_type to reflect the true, earlier position held by gptr(). Am I missing something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug c++/45635] New: [4.6 regression] Failed to bootstrap on Linux/ia64
On Linux/ia64, revision 164164 gave ../../../../src-trunk/libstdc++-v3/libsupc++/array_type_info.cc:33:1: internal compiler error: tree check: expected tree that contains 'decl with RTL' structure, have 'addr_expr' in output_constant, at varasm.c:4408 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [array_type_info.lo] Error 1 make[7]: Leaving directory `/export/gnu/import/svn/gcc-test/bld/ia64-unknown-linux-gnu/libstdc++-v3/libsupc++' Revision 164140 is OK. -- Summary: [4.6 regression] Failed to bootstrap on Linux/ia64 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
[Bug debug/44115] gcc.dg/guality/sra-1.c failure
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-10 14:22 --- Subject: Bug 44115 Author: rguenth Date: Fri Sep 10 14:22:22 2010 New Revision: 164179 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164179 Log: 2010-09-10 Richard Guenther rguent...@suse.de PR debug/44115 * tree.c (free_lang_data_in_decl): Do not clear DECL_DEBUG_EXPR. * lto-streamer-out.c (lto_output_ts_decl_common_tree_pointers): Output DECL_DEBUG_EXPR. * lto-streamer-in.c (lto_input_ts_decl_common_tree_pointers): Input DECL_DEBUG_EXPR. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44115
[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
[Bug debug/44115] gcc.dg/guality/sra-1.c failure
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-10 14:38 --- Fixed for 4.6. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44115
[Bug middle-end/45634] [4.6 regression] Revision 163973 faild to compile 191.fma3d in SPEC CPU 2K
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-10 14:39 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00951.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||09/msg00951.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45634
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-10 14:39 --- Then, seekoff would also return a position beyond the buffer, right? Or you want it to return 1 anyway? Actually, I think the standard want us to use width * off for the underlying fseek anyway, not only for off == 0, and this is not what we have been doing. I think there is something seriously different here, beyond the performance issue, which we should ponder much more, after so many years. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-10 14:40 --- For the interprocedural analysis I believe static points-to is the only reasonable thing to do, anything else would have too big complexity (both space and time). Within one function, sure, you have the code, but not in a form which makes it very easy to do such analysis (e.g. SSA form is much more suitable for that), and you need to understand many different constructs (IF, loops, GOTO, CYCLE, BREAK, OpenMP constructs, ...) and handle propagating the information through the callgraph (which isn't built). I think reimplementing many middle-end passes on the Front-end trees is not the right way to go, and I hope the static points-to analysis should catch most of the interesting cases in real-world code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
[Bug middle-end/45634] [4.6 regression] Revision 163973 faild to compile 191.fma3d in SPEC CPU 2K
--- Comment #3 from hjl at gcc dot gnu dot org 2010-09-10 14:44 --- Subject: Bug 45634 Author: hjl Date: Fri Sep 10 14:44:20 2010 New Revision: 164183 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164183 Log: Check that result of string folding is of integral type. gcc/ 2010-09-10 H.J. Lu hongjiu...@intel.com PR middle-end/45634 * tree-ssa-ccp.c (fold_const_aggregate_ref): Check that result of string folding is of integral type. gcc/testsuite/ 2010-09-10 H.J. Lu hongjiu...@intel.com PR middle-end/45634 * gfortran.fortran-torture/compile/pr45634.f90: New. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr45634.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45634
[Bug fortran/45636] New: Failed to fold simple Fortran string
For this simple Fortran string: [...@gnu-6 pr45634]$ cat pr45634.f90 SUBROUTINE RCRDRD (VTYP) CHARACTER(4), INTENT(OUT) :: VTYP CHARACTER(1), SAVE :: DBL = D VTYP = DBL END GCC generates: [...@gnu-6 pr45634]$ cat pr45634.s .file pr45634.f90 .text .p2align 4,,15 .globl rcrdrd_ .type rcrdrd_, @function rcrdrd_: .LFB0: .cfi_startproc movzbl dbl.1557(%rip), %eax movw$8224, 1(%rdi) movb$32, 3(%rdi) movb%al, (%rdi) ret .cfi_endproc .LFE0: .size rcrdrd_, .-rcrdrd_ .section.rodata .type dbl.1557, @object .size dbl.1557, 1 dbl.1557: .ascii D .ident GCC: (GNU) 4.6.0 20100910 (experimental) .section.note.GNU-stack,,@progbits IFORT generates: [...@gnu-6 pr45634]$ cat icc.s # -- Machine type EFI2 # mark_description Intel(R) Fortran Compiler XE for applications running on Intel(R) 64, Version 12.0.0 Beta Build 20100512; # mark_description -O3 -S; .file pr45634.f90 .text ..TXTST0: # -- Begin rcrdrd_ # mark_begin; .align16,0x90 .globl rcrdrd_ rcrdrd_: # parameter 1: %rdi # parameter 2: %rsi ..B1.1: # Preds ..B1.0 ..___tag_value_rcrdrd_.1: #1.18 movl $538976324, (%rdi)#4.7 ret #5.7 -- Summary: Failed to fold simple Fortran string Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-10 14:52 --- It may be caused by revision 164148: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00440.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #8 from don dot wakefield at gmail dot com 2010-09-10 14:54 --- Paolo, yes, _M_file.seekoff(0,cur) would return the current physical file position, and then filebuf::seekoff would adjust the returned pos_type to reflect the position within the *logical* file, framed by the buffer and pointed to by gptr(). As for the mechanics of width*off, I confess that locale issues leave me completely befuddled, so I won't try to address that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-10 15:00 --- Ok. I don't think we should change the code to deal such specially with off == 0, if we are going to change it we should decouple the return value from what the underlying seek returns, and always call fseek(..., width * off, ...) as the standard mandates. Then dealing with off == 0 becomes simple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug c/45637] New: Suspicious code for bit fields
Please have a look at this test case:
#include stdint.h
struct type1 {
union {
uint8_t reg;
struct {
uint8_t : 7;
uint8_t b : 1;
} bit;
} foo [1];
uint8_t bar;
};
volatile struct type1 *var1;
void f1(int i)
{
var1-foo [i].bit.b = 1;
var1-foo [0].bit.b = 1;
}
struct type2 {
union {
uint8_t reg;
struct {
uint8_t : 7;
uint8_t b : 1;
} bit;
} foo [1];
uint16_t bar;
};
volatile struct type2 *var2;
void f2(int i)
{
var2-foo [i].bit.b = 1;
var2-foo [0].bit.b = 1;
}
struct type3 {
union {
uint8_t reg;
struct {
uint8_t : 7;
uint8_t b : 1;
} bit;
} foo [1];
uint32_t bar;
};
volatile struct type3 *var3;
void f3(int i)
{
var3-foo [i].bit.b = 1;
var3-foo [0].bit.b = 1;
}
And the produced assembler file generated with (powerpc-rtems4.11-gcc -O2 -c
-mcpu=8540 -meabi -msdata -fno-common -save-temps):
.file bitfields.c
.gnu_attribute 4, 2
.gnu_attribute 8, 1
.gnu_attribute 12, 1
.section.text
.align 2
.globl f1
.type f1, @function
f1:
lwz 9,v...@sda21(0)
lbzx 0,9,3
ori 0,0,1
stbx 0,9,3
lbz 0,0(9)
ori 0,0,1
stb 0,0(9)
blr
.size f1, .-f1
.align 2
.globl f2
.type f2, @function
f2:
lwz 9,v...@sda21(0)
lbzx 0,9,3
ori 0,0,1
stbx 0,9,3
lhz 0,0(9)
ori 0,0,256
sth 0,0(9)
blr
.size f2, .-f2
.align 2
.globl f3
.type f3, @function
f3:
lwz 9,v...@sda21(0)
li 11,1
lbzx 0,9,3
ori 0,0,1
stbx 0,9,3
lwz 0,0(9)
rlwimi 0,11,24,7,7
stw 0,0(9)
blr
.size f3, .-f3
.globl var1
.globl var2
.globl var3
.section.sbss,aw,@nobits
.align 2
.type var1, @object
.size var1, 4
var1:
.zero 4
.type var2, @object
.size var2, 4
var2:
.zero 4
.type var3, @object
.size var3, 4
var3:
.zero 4
.ident GCC: (GNU) 4.5.1 20100731 (RTEMS
gcc-4.5.1-5.suse11.2/newlib-1.18.0-20.suse11.2)
Here you can see, that the access to the 'foo' field depends on
1. index is constant or variable, and
2. the 'bar' field type.
I think that both dependencies are wrong. In any case byte accesses should be
used.
--
Summary: Suspicious code for bit fields
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: powerpc-rtems4.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637
[Bug fortran/45636] Failed to fold simple Fortran string
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-10 15:12 --- I have a slightly different result with your code. troutmask:sgk[212] gfc4x -c -O g.f90 g.f90: In function 'rcrdrd': g.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. If I replace the SAVE attribute by PARAMETER (which will most likely cause the folding you want), everything compiles fine. The ICE also goes away if I increase the length of DBL from one to any larger value. troutmask:sgk[219] gfc4x -v Using built-in specs. COLLECT_GCC=/home/sgk/work/4x/bin/gfortran COLLECT_LTO_WRAPPER=/usr/home/sgk/work/4x/bin/../libexec/gcc/x86_64-unknown-freebsd9.0/4.6.0/lto-wrapper Target: x86_64-unknown-freebsd9.0 Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x --enable-languages=c,fortran --disable-libmudflap --disable-bootstrap --with-quad=/home/sgk/work Thread model: posix gcc version 4.6.0 20100909 (experimental) (GCC) -- kargl at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #10 from don dot wakefield at gmail dot com 2010-09-10 15:15 --- (In reply to comment #9) Ok. I don't think we should change the code to deal such specially with off == 0, if we are going to change it we should decouple the return value from what the underlying seek returns, and always call fseek(..., width * off, ...) as the standard mandates. Then dealing with off == 0 becomes simple. I'm not sure I understand what you are saying. My concern is that calls to filebuf::seekoff(0,ios::cur) should not invalidate the buffer just to return a correct answer to where am I?. Whether this is an accident of history or not, I've seen this usage enshrined in code as a respected idiom. Does your text above specify this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10 15:15 --- Subject: Re: [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC A reghunt identified that the regression was caused by this patch: 2010-09-07 Jan Hubicka j...@suse.cz * tree-inline.c (tree_inlinable_function_p): Do not test DECL_REPLACEABL E_P. * ipa-inline.c (cgraph_default_inline_p, update_caller_keys, update_call ee_keys, cgraph_decide_inlining): Test function availability. * cif-code.def (OVERWRITABLE): New code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
--- Comment #4 from ro at gcc dot gnu dot org 2010-09-10 15:19 --- Jan, could you please have a look. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Summary|[4.6 regression] Reference |[4.6 regression] Reference |to undefined label building |to undefined label building |libada no Solaris 2/SPARC |libada on Solaris 2/SPARC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-10 15:19 --- Sure. What I meant - contrary to wait you said, I think - is that an elegant and complete solution to this issue involves changing much more generally our code to *always* behave as if fseek(off * width) were called, not just fseek(0) in the special case you care about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug fortran/45636] Failed to fold simple Fortran string
--- Comment #2 from kargl at gcc dot gnu dot org 2010-09-10 15:20 ---
The -fdump-tree-original for HJ's original code look like
rcrdrd (character(kind=1)[1:4] restrict vtyp, integer(kind=4) _vtyp)
{
static character(kind=1) dbl[1:1] = D;
(MEM[(c_char * {ref-all})vtyp] = MEM[(c_char * {ref-all})dbl];, (void *)
vtyp;);
__builtin_memset ((void *) vtyp + 1, 32, 3);
}
If I increase the length of DBL to 2, then the dump looks like
rcrdrd (character(kind=1)[1:4] restrict vtyp, integer(kind=4) _vtyp)
{
static character(kind=1) dbl[1:2] = D ;
__builtin_memmove ((void *) vtyp, (void *) dbl, 2);
__builtin_memset ((void *) vtyp + 2, 32, 2);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #12 from don dot wakefield at gmail dot com 2010-09-10 15:24 --- (In reply to comment #11) Sure. What I meant - contrary to wait you said, I think - is that an elegant and complete solution to this issue involves changing much more generally our code to *always* behave as if fseek(off * width) were called, not just fseek(0) in the special case you care about. Okay, I understand better now. My apologies, and thanks for your comments on this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug testsuite/45638] New: No rule to make target `check-lto', needed by `check'. Stop.
When gcc is configured with --enable-languages=...,lto,..., make check fails with: make[3]: Leaving directory `/home/smatz/build-164162-lto-fortran-checking-yes-rtl-df/gcc' make[2]: *** No rule to make target `check-lto', needed by `check'. Stop. make[2]: Leaving directory `/home/smatz/build-164162-lto-fortran-checking-yes-rtl-df/gcc' make[1]: *** [check-gcc] Error 2 make[1]: Leaving directory `/home/smatz/build-164162-lto-fortran-checking-yes-rtl-df' make: *** [do-check] Error 2 check-gcc, check-g++ and check-gfortran finish fine Version information: $ /mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/bin/gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk/configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/ Thread model: posix gcc version 4.6.0 20100910 (experimental) (GCC) I think this never worked (as far as I remember) According to http://gcc.gnu.org/install/configure.html, --enable-languages=lto is allowed, as its output by: gcc $ grep language= */config-lang.in ada/config-lang.in:language=ada cp/config-lang.in:language=c++ fortran/config-lang.in:language=fortran java/config-lang.in:language=java lto/config-lang.in:language=lto objc/config-lang.in:language=objc objcp/config-lang.in:language=obj-c++ -- Summary: No rule to make target `check-lto', needed by `check'. Stop. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45638
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #24 from tstarling at wikimedia dot org 2010-09-10 15:25 --- Created an attachment (id=21766) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21766action=view) dynamic_cast hack The attached patch uses a dynamic_cast hack to avoid the need to break the ABI. I added *_unlocked functions to cstdio, I'm not sure if this is necessary, but it's easy enough to remove that part if not. I also added some lightly-tested autoconf stuff. I'm an autoconf newbie so that part should probably be reviewed carefully. stdio_sync_filebufwchar_t::_M_getline() is currently unreachable, since I only edited basic_istreamchar::getline() and not basic_istreamwchar_t::getline(). It would be easy enough to fix that. I haven't used getwc_unlocked() because it's a GNU extension, POSIX only has non-wide unlocked I/O. The timings for 1M lines with 500 bytes per line, user time only, are: Old library: 26.7s New library: 1.65s fgets: 0.280s So it's better, but not perfect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug tree-optimization/45639] New: [4.6 Regression] /usr/ccs/bin/ld: Data address is out of range for short load or store
cd rts; ../../xgcc -B../../ -shared -g -O2 \ -fPIC -frandom-seed=fixed-seed \ -o libgnat-4.6.sl \ a-assert.o a-calari.o a-calcon.o a-caldel.o a-calend.o a-calfor. o a-catizo.o a-cdlili.o a-cgaaso.o a-cgarso.o a-cgcaso.o a-chacon.o a-chahan.o a -charac.o a-chlat1.o a-chlat9.o a-chtgke.o a-chtgop.o a-chzla1.o a-chzla9.o a-ci dlli.o a-cihama.o a-cihase.o a-ciorma.o a-ciormu.o a-ciorse.o a-clrefi.o a-coham a.o a-cohase.o a-cohata.o a-coinve.o a-colien.o a-colire.o a-comlin.o a-contai.o a-convec.o a-coorma.o a-coormu.o a-coorse.o a-coprnu.o a-coteio.o a-crbltr.o a- crbtgk.o a-crbtgo.o a-crdlli.o a-cwila1.o a-cwila9.o a-decima.o a-diocst.o a-dir ect.o a-direio.o a-dirval.o a-einuoc.o a-elchha.o a-envvar.o a-except.o a-exctra .o a-filico.o a-finali.o a-flteio.o a-fwteio.o a-fzteio.o a-inteio.o a-ioexce.o a-iwteio.o a-izteio.o a-lcteio.o a-lfteio.o a-lfwtio.o a-lfztio.o a-liteio.o a-l iwtio.o a-liztio.o a-llctio.o a-llftio.o a-llfwti.o a-llfzti.o a-llitio.o a-lliw ti.o a-llizti.o a-ncelfu.o a-ngcefu.o a-ngcoty.o a-ngelfu.o a-ngrear.o a-nlcefu. o a-nlcoty.o a-nlelfu.o a-nllcef.o a-nllcty.o a-nllefu.o a-nscefu.o a-nscoty.o a -nselfu.o a-nucoty.o a-nudira.o a-nuelfu.o a-nuflra.o a-numaux.o a-numeri.o a-rb tgso.o a-scteio.o a-secain.o a-sequio.o a-sfteio.o a-sfwtio.o a-sfztio.o a-shcai n.o a-siocst.o a-siteio.o a-siwtio.o a-siztio.o a-slcain.o a-ssicst.o a-ssitio.o a-ssiwti.o a-ssizti.o a-stboha.o a-stfiha.o a-stmaco.o a-storio.o a-strbou.o a- stream.o a-strfix.o a-strhas.o a-string.o a-strmap.o a-strsea.o a-strsup.o a-str unb.o a-ststio.o a-stunau.o a-stunha.o a-stuten.o a-stwibo.o a-stwifi.o a-stwiha .o a-stwima.o a-stwise.o a-stwisu.o a-stwiun.o a-stzbou.o a-stzfix.o a-stzhas.o a-stzmap.o a-stzsea.o a-stzsup.o a-stzunb.o a-suenco.o a-suesen.o a-suewse.o a-s uezse.o a-suteio.o a-swbwha.o a-swfwha.o a-swmwco.o a-swunau.o a-swuwha.o a-swuw ti.o a-szbzha.o a-szfzha.o a-szmzco.o a-szunau.o a-szuzha.o a-szuzti.o a-tags.o a-teioed.o a-textio.o a-tgdico.o a-tiboio.o a-ticoau.o a-ticoio.o a-tideau.o a-t ideio.o a-tienau.o a-tienio.o a-tifiio.o a-tiflau.o a-tiflio.o a-tigeau.o a-tiin au.o a-tiinio.o a-timoau.o a-timoio.o a-tiocst.o a-tirsfi.o a-titest.o a-tiunio. o a-unccon.o a-uncdea.o a-wichun.o a-widcha.o a-witeio.o a-wrstfi.o a-wtcoau.o a -wtcoio.o a-wtcstr.o a-wtdeau.o a-wtdeio.o a-wtedit.o a-wtenau.o a-wtenio.o a-wt fiio.o a-wtflau.o a-wtflio.o a-wtgeau.o a-wtinau.o a-wtinio.o a-wtmoau.o a-wtmoi o.o a-wttest.o a-wwboio.o a-wwunio.o a-zchara.o a-zchuni.o a-zrstfi.o a-ztcoau.o a-ztcoio.o a-ztcstr.o a-ztdeau.o a-ztdeio.o a-ztedit.o a-ztenau.o a-ztenio.o a- ztexio.o a-ztfiio.o a-ztflau.o a-ztflio.o a-ztgeau.o a-ztinau.o a-ztinio.o a-ztm oau.o a-ztmoio.o a-zttest.o a-zzboio.o a-zzunio.o ada.o calendar.o directio.o g- allein.o g-alleve.o g-altcon.o g-altive.o g-alveop.o g-alvety.o g-alvevi.o g-arr spl.o g-awk.o g-bubsor.o g-busora.o g-busorg.o g-byorma.o g-bytswa.o g-calend.o g-casuti.o g-catiio.o g-cgi.o g-cgicoo.o g-cgideb.o g-comlin.o g-comver.o g-crc3 2.o g-ctrl_c.o g-curexc.o g-debpoo.o g-debuti.o g-decstr.o g-deutst.o g-diopit.o g-dirope.o g-dynhta.o g-dyntab.o g-encstr.o g-enutst.o g-excact.o g-except.o g- exctra.o g-expect.o g-flocon.o g-heasor.o g-hesora.o g-hesorg.o g-htable.o g-io. o g-io_aux.o g-locfil.o g-mbdira.o g-mbflra.o g-md5.o g-memdum.o g-moreex.o g-os _lib.o g-pehage.o g-rannum.o g-regexp.o g-regpat.o g-sechas.o g-sehamd.o g-sehas h.o g-sercom.o g-sestin.o g-sha1.o g-sha224.o g-sha256.o g-sha384.o g-sha512.o g -shsh32.o g-shsh64.o g-shshco.o g-souinf.o g-spchge.o g-speche.o g-spipat.o g-sp itbo.o g-sptabo.o g-sptain.o g-sptavs.o g-string.o g-strspl.o g-table.o g-tasloc .o g-timsta.o g-traceb.o g-u3spch.o g-utf_32.o g-wispch.o g-wistsp.o g-zspche.o g-zstspl.o gnat.o i-c.o i-cexten.o i-cobol.o i-cpoint.o i-cpp.o i-cstrea.o i-cst rin.o i-fortra.o i-pacdec.o interfac.o ioexcept.o machcode.o s-addima.o s-addope .o s-arit64.o s-assert.o s-atacco.o s-auxdec.o s-bitops.o s-boarop.o s-carsi8.o s-carun8.o s-casi16.o s-casi32.o s-casi64.o s-casuti.o s-caun16.o s-caun32.o s-c aun64.o s-chepoo.o s-commun.o s-conca2.o s-conca3.o s-conca4.o s-conca5.o s-conc a6.o s-conca7.o s-conca8.o s-conca9.o s-crc32.o s-crtl.o s-crtrun.o s-direio.o s -dsaser.o s-except.o s-exctab.o s-exnint.o s-exnllf.o s-exnlli.o s-expint.o s-ex plli.o s-expllu.o s-expmod.o s-expuns.o s-fatflt.o s-fatgen.o s-fatlfl.o s-fatll f.o s-fatsfl.o s-ficobl.o s-fileio.o s-filofl.o s-finimp.o s-finroo.o s-fishfl.o s-fore.o s-fvadfl.o s-fvaffl.o s-fvagfl.o s-geveop.o s-gloloc.o s-htable.o s-im enne.o s-imgbiu.o s-imgboo.o s-imgcha.o s-imgdec.o s-imgenu.o s-imgint.o s-imgll b.o s-imglld.o s-imglli.o s-imgllu.o s-imgllw.o s-imgrea.o s-imguns.o s-imgwch.o s-imgwiu.o s-io.o s-maccod.o s-mantis.o s-mastop.o s-memcop.o s-memory.o s-os_l ib.o s-osprim.o s-pack03.o s-pack05.o s-pack06.o s-pack07.o s-pack09.o s-pack10. o s-pack11.o s-pack12.o s-pack13.o s-pack14.o s-pack15.o s-pack17.o s-pack18.o s -pack19.o
[Bug target/45637] Suspicious code for bit fields
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 15:30 --- 1. index is constant or variable, and Yes that is correct. 2. the 'bar' field type. The alignment of the access is different in those cases. In any case byte accesses should be used. Why, word access is just as fast (if not faster) than a byte access on PPC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637
[Bug fortran/45636] Failed to fold simple Fortran string
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-10 15:32 --- (In reply to comment #1) I have a slightly different result with your code. troutmask:sgk[212] gfc4x -c -O g.f90 g.f90: In function 'rcrdrd': g.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It is fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00475.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug fortran/45636] Failed to fold simple Fortran string
--- Comment #4 from kargl at gcc dot gnu dot org 2010-09-10 15:34 --- (In reply to comment #3) (In reply to comment #1) I have a slightly different result with your code. troutmask:sgk[212] gfc4x -c -O g.f90 g.f90: In function 'rcrdrd': g.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It is fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00475.html HJ, Thanks. I updated by trunk right before your patch, so I missed it my most recent build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug lto/45638] No rule to make target `check-lto', needed by `check'. Stop.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-10 15:35 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|testsuite |lto Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-10 15:35:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45638
[Bug target/45637] Suspicious code for bit fields
--- Comment #2 from sebastian dot huber at embedded-brains dot de 2010-09-10 15:43 --- (In reply to comment #1) 1. index is constant or variable, and Yes that is correct. 2. the 'bar' field type. The alignment of the access is different in those cases. Sorry, the test case was not good. If you expand foo [1] to foo [4] you still have this behavior. In any case byte accesses should be used. Why, word access is just as fast (if not faster) than a byte access on PPC. Yes, but we have 'volatile struct type1 *varN;'. For volatile fields we should use accesses of the appropriate width. The background is that a major hardware manufacturer provided structure definitions like the above test case for register definitions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #13 from paolo dot carlini at oracle dot com 2010-09-10 15:45 --- Good, I think we are close to a fix, I'm already testing something. So, do we have a symmetric issue with the put area or not? I'm not sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug target/45637] Suspicious code for bit fields
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 15:46 --- For volatile fields we should use accesses of the appropriate width. The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC it says they should be doing the largest available (up to the register size) size. This is different from the ARM ABI which says the opposite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637
[Bug fortran/45636] Failed to fold simple Fortran string
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-10 15:47 --- For arbitrary lengths (both of the constant string and of the padding) the memmove (which will be optimized to memcpy as the source is read-only) + memset is the best thing to do, replacing say memmove (x, 900 bytes long string, 900); memset (x + 900, ' ', 100); would be very .rodata size unfriendly. So, the question is, do we want to optimize this for very small sizes of both (what sizes? Should we call can_store_by_pieces to determine that from the FE?) in the FE by transforming that say memmove (x, ABCDE, 5); memset (x + 5, ' ', 3); into memcpy (x, ABCDE , 8); or should we do this generically in the middle-end, where we'd do this transformation for such cases even for other languages? -- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10 15:48 --- Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC --- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-09 13:27 --- I don't have access to sparc-sun-solaris2*, so I can't bootstrap it (but at most build a cross cc1). Not even sparc-linux? I very much doubt the bug is Solaris-specific. So please attach a testcase (easiest is probably in a non-bootstrapped tree run make check and pick a simple one that fails from the C testsuite). Ok, I'll try to find one. Is sparc-sun-solaris2* a STRICT_ALIGNMENT target? What's the clr instruction? Is it a store or a load? Yes, cf. sparc.h. clr and clrx store 0 (4 or 8 bytes) at the target address, requiring natural alignment (which fails with your patch for the clrx case). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #6 from rguenther at suse dot de 2010-09-10 15:51 --- Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC On Fri, 10 Sep 2010, ro at CeBiTec dot Uni-Bielefeld dot DE wrote: --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10 15:48 --- Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC --- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-09 13:27 --- I don't have access to sparc-sun-solaris2*, so I can't bootstrap it (but at most build a cross cc1). Not even sparc-linux? I very much doubt the bug is Solaris-specific. No, not even sparc-linux. So please attach a testcase (easiest is probably in a non-bootstrapped tree run make check and pick a simple one that fails from the C testsuite). Ok, I'll try to find one. Is sparc-sun-solaris2* a STRICT_ALIGNMENT target? What's the clr instruction? Is it a store or a load? Yes, cf. sparc.h. clr and clrx store 0 (4 or 8 bytes) at the target address, requiring natural alignment (which fails with your patch for the clrx case). Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug target/45637] Suspicious code for bit fields
--- Comment #4 from sebastian dot huber at embedded-brains dot de 2010-09-10 15:59 --- (In reply to comment #3) For volatile fields we should use accesses of the appropriate width. The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC it says they should be doing the largest available (up to the register size) size. This is different from the ARM ABI which says the opposite. Thank you very much for your comments. I will investigate the PowerPC ABI issue and contact the manufacturer. Ironically they produced the ABI and these register definitions. -- sebastian dot huber at embedded-brains dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #14 from potswa at mac dot com 2010-09-10 15:59 --- (In reply to comment #13) Good, I think we are close to a fix, I'm already testing something. So, do we have a symmetric issue with the put area or not? I'm not sure. I believe so. tellg and tellp are both handled by seekoff( 0, ios::cur ), and the required behavior doesn't differentiate between them, partly because for an fstream the get and put pointers are the same. (The result doesn't depend on the pointers, it comes from fseek.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #25 from paolo dot carlini at oracle dot com 2010-09-10 16:01 --- Good. Please give me a couple of days to come to your code. Note, since you don't have a Copyright Assignment on file, it will be difficult to fully acknowledge your work in the ChangeLog. Thus, I would suggest having first a minimal patch, limited to char, limited in any way ;) but still sufficient to bring most of the improvement we are aiming to within the ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug fortran/45624] Division by zero compiler error
--- Comment #5 from leftynm at umich dot edu 2010-09-10 16:06 --- Thanks guys. Yeah, I guess my use of PARAMETER wasn't consistent with how it works. I was using it to set a variable such that it cannot be changed. I found a work around though lets me keep it as a PARAMETER, but allows me to compile. PROGRAM test IMPLICIT NONE REAL*8, PARAMETER :: alpha = 0.D0 REAL*8, DIMENSION(5,5) :: matrix INTEGER :: i REAL*8 :: dummy matrix = 0.D0 DO i=1,5 IF (alpha == 0.D0) THEN matrix(i,i) = 0.D0 ELSE dummy = alpha matrix(i,i) = 1.D0/dummy ENDIF ENDDO END PROGRAM This is what I need, since when I don't make my variable a PARAMETER, it causes other problems. This requires less work to fix, so I'm happy with it. I tried PROTECTED, but my code has to be F90 because it's a small part of a bigger project. Thanks to everyone though. I wouldn't have figured this out without your inputs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45624
[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE
--- Comment #8 from mikael at gcc dot gnu dot org 2010-09-10 16:11 --- In the patch there is a small mistake : + if (symtree-n.sym-attr.flavor == FL_PARAMETER + symtree-n.sym-attr.intent != INTENT_OUT) +symtree-n.sym-points_to = gfc_pt_dummy; Parameters in the fortran jargon are named constants. It should probably be `symtree-n.sym-attr.dummy' instead of `symtree-n.sym-attr.flavor == FL_PARAMETER' (In reply to comment #7) For the interprocedural analysis I believe static points-to is the only reasonable thing to do, anything else would have too big complexity (both space and time). Within one function, sure, you have the code, but not in a form which makes it very easy to do such analysis (e.g. SSA form is much more suitable for that), and you need to understand many different constructs (IF, loops, GOTO, CYCLE, BREAK, OpenMP constructs, ...) and handle propagating the information through the callgraph (which isn't built). I think reimplementing many middle-end passes on the Front-end trees is not the right way to go, and I hope the static points-to analysis should catch most of the interesting cases in real-world code. I see. Given my knowledge of the middle-end, I have nothing to oppose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #15 from potswa at mac dot com 2010-09-10 16:15 --- (In reply to comment #14) (The result doesn't depend on the pointers, it comes from fseek.) I re-read Comment 5 and understand it this time ;v) . Well, any solution should fix both tellg and tellp, since the pointers are the same upon synchronization. Then, yes, we need to check which type of operation occurred last, and either update whichever pointer is stale, or selectively use the correct one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug target/45640] New: gcc.c-torture/execute/20050316-2.c ICEs with -mno-mmx -m3dnow -flto
Compiler output: $ gcc -mno-mmx -m3dnow -flto gcc.c-torture/execute/20050316-2.c In file included from gcc.c-torture/execute/20050316-2.c:34:0, from :0: gcc.c-torture/execute/20050316-2.c: In function 'main': gcc.c-torture/execute/20050316-2.c:45:15: internal compiler error: in copy_to_mode_reg, at explow.c:636 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/bin/gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status $ gcc -mno-mmx -m3dnow -flto gcc.c-torture/execute/20050316-2.c -O In file included from gcc.c-torture/execute/20050316-2.c:34:0, from :0: gcc.c-torture/execute/20050316-2.c: In function 'test3': gcc.c-torture/execute/20050316-2.c:24:3: internal compiler error: in expand_expr_real_1, at expr.c:8484 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/bin/gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status $ gcc -mno-mmx -m3dnow -flto gcc.c-torture/execute/20050316-2.c -m32 In file included from :0:0: gcc.c-torture/execute/20050316-2.c: In function 'test1': gcc.c-torture/execute/20050316-2.c:10:1: warning: MMX vector argument without MMX enabled changes the ABI [enabled by default] In file included from gcc.c-torture/execute/20050316-2.c:34:0, from :0: gcc.c-torture/execute/20050316-2.c: In function 'main': gcc.c-torture/execute/20050316-2.c:45:15: internal compiler error: in emit_move_insn, at expr.c:3386 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/bin/gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status Tested revisions: r164162 - crash r153685 - crash -- Summary: gcc.c-torture/execute/20050316-2.c ICEs with -mno-mmx - m3dnow -flto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45640
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #16 from paolo dot carlini at oracle dot com 2010-09-10 17:11 --- Actually, however, I don't think we can really always call fseek(off * width) as the Standard want us to do. In a sense I'm happy because the change is gonna be less invasive, on the other hand I'm a bit puzzled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-10 17:14 --- Hi, would be possible to have preprocessed source for a cross compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
[Bug fortran/45641] New: configure: error: GNU Fortran is not working
Have problem to make fortran work in x64 environment. Linux test1.us.icap.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-46) cat /root/gcc-4.5.0/x86_64-unknown-linux-gnu/libgfortran/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU Fortran Runtime Library configure 0.3, which was generated by GNU Autoconf 2.64. Invocation command line was $ /root/gcc-4.5.0/libgfortran/configure --cache-file=./config.cache --enable-multilib --prefix=/usr/local/x64/gcc_4_5_0 --with-gmp=/usr/local/x64/gmp_4_3_2 --with-mpfr=/usr/local/x64/mpfr_2_4_2 --with-mpfr-include=/usr/local/x64/mpfr_2_4_2/include --with-mpfr-lib=/usr/local/x64/mpfr_2_4_2/lib --with-mpc=/usr/local/x64/mpc_0_8_2 --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre --with-cpu=generic --enable-languages=c,c++,fortran,java,objc,obj-c++ --program-transform-name=s,y,y, --disable-option-checking --with-target-subdir=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu --srcdir=../.././libgfortran ## - ## ## Platform. ## ## - ## hostname = test1.us.icap.com uname -m = x86_64 uname -r = 2.6.18-164.el5 uname -s = Linux uname -v = #1 SMP Thu Sep 3 03:28:30 EDT 2009 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/kerberos/sbin PATH: /usr/kerberos/bin PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /root/bin ## --- ## ## Core tests. ## ## --- ## configure:2502: creating cache ./config.cache configure:2607: checking build system type configure:2621: result: x86_64-unknown-linux-gnu configure:2691: checking for --enable-version-specific-runtime-libs configure:2704: result: no configure:2708: checking for --enable-intermodule configure:2720: result: configure:2747: checking host system type configure:2760: result: x86_64-unknown-linux-gnu configure:2780: checking target system type configure:2793: result: x86_64-unknown-linux-gnu configure:2848: checking for a BSD-compatible install configure:2916: result: /usr/bin/install -c configure:2927: checking whether build environment is sane configure:2977: result: yes configure:3118: checking for a thread-safe mkdir -p configure:3157: result: /bin/mkdir -p configure:3170: checking for gawk configure:3197: result: gawk configure:3208: checking whether make sets $(MAKE) configure:3230: result: yes configure:3303: checking whether to enable maintainer-specific portions of Makefiles configure:3312: result: no configure:3422: checking for x86_64-unknown-linux-gnu-gcc configure:3449: result: /root/gcc-4.5.0/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/root/gcc-4.5.0/host-x86_64-unknown-linux-gnu/gcc/ -B/usr/local/x64/gcc_4_5_0/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x64/gcc_4_5_0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x64/gcc_4_5_0/x86_64-unknown-linux-gnu/include -isystem /usr/local/x64/gcc_4_5_0/x86_64-unknown-linux-gnu/sys-include configure:3718: checking for C compiler version configure:3727: /root/gcc-4.5.0/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/root/gcc-4.5.0/host-x86_64-unknown-linux-gnu/gcc/ -B/usr/local/x64/gcc_4_5_0/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x64/gcc_4_5_0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x64/gcc_4_5_0/x86_64-unknown-linux-gnu/include -isystem /usr/local/x64/gcc_4_5_0/x86_64-unknown-linux-gnu/sys-include--version 5 xgcc (GCC) 4.5.0 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3738: $? = 0 configure:3727: /root/gcc-4.5.0/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/root/gcc-4.5.0/host-x86_64-unknown-linux-gnu/gcc/
[Bug fortran/45641] configure: error: GNU Fortran is not working
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 17:20 --- libmpfr.so.1: undefined symbol: __gmp_get_memory_functions That means libmpfr is finding the incorrect GMP. This is not a GCC bug but rather a bug in your LD_LIBRARY_PATH or ld.so configuration. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45641
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #17 from potswa at mac dot com 2010-09-10 17:25 --- (In reply to comment #16) Actually, however, I don't think we can really always call fseek(off * width) as the Standard want us to do. In a sense I'm happy because the change is gonna be less invasive, on the other hand I'm a bit puzzled. Could you post a patch? I'm not sure what you mean by generalizing (off * width), if off == 0 then width is irrelevant. If width 0 then the only valid value for off is 0. If width 0, off != 0 then repositioning is the primary effect. The task is to call fseek(0,cur), and then subtract the number of bytes in the put area plus the external characters, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #18 from paolo dot carlini at oracle dot com 2010-09-10 17:29 --- I'm almost ready for the patch, please be patient ;) If look at the standard, it says that the last step of seekoff is *always* as if calling fseek(..., off * width, ...). If look at the current code, we have the concept of __computed_off and, in many cases we end up calling the equivalent of fseek with something != off * width. I'm changing that to (0, cur) for the case you care about, but not changing anything else otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #19 from paolo dot carlini at oracle dot com 2010-09-10 17:30 --- Of course here I'm always under the assumption width 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug c++/45642] g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved
--- Comment #1 from tbptbp at gmail dot com 2010-09-10 17:34 --- Created an attachment (id=21767) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21767action=view) large fugly testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
[Bug c++/45642] New: g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved
Since around 2010/09/07 g++ started to barf on the attached source about a mismatched prototype. Apparently the culprit is the forward declaration + later definition with additional attribute of one of the argument, and, if the forward declaration is sprinkled with said attribute, the error goes away. I've failed to reduce both manually and with delta (mismatched prototypes are too easily produced). Sorry. $ /usr/local/gcc-4.6-20100910/bin/g++ -std=c++0x -c synth.ii src/audio/synth_voice_impl.h:140:6: error: prototype for 'bool synth::voice::voice_t::produce_chunk(const synth::semitones_lut_t, const synth::midi_channels_params_t, synth::chunk_array_mono_t)' does not match any in class 'synth::voice::voice_t' src/audio/synth_voice.h:153:156: error: candidate is: templatesynth::voice::waves::waves_enum_t wave_shape bool synth::voice::voice_t::produce_chunk(const synth::semitones_lut_t, const synth::midi_channels_params_t, synth::chunk_array_mono_t) ... $ /usr/local/gcc-4.6-20100910/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.6-20100910/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6-20100910/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc-4.6.0 --enable-languages=c,c++ --enable-threads=posix --disable-checking --disable-nls --with-system-zlib --disable-bootstrap --enable-checking=none --enable-mpfr --enable-gold --enable-lto --with-ppl --with-cloog --with-arch=native Thread model: posix gcc version 4.6.0 20100910 (experimental) (GCC) midi_channels_params_t is the trigger. Known to work on g++ 4.4.x, 4.5.x and up to and including 4.6-20100901. PS: http://gcc.gnu.org/ml/gcc/2010-09/msg00152.html -- Summary: g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbptbp at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
[Bug c++/45642] g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-10 17:34 --- I think you need __attribute((aligned(16))) on the original forward declared class too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
[Bug c++/45642] g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 17:35 --- This seems related to PR 45112. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #20 from potswa at mac dot com 2010-09-10 17:35 ---
(In reply to comment #17)
The task is to call fseek(0,cur), and then subtract the number of bytes in the
put area plus the external characters, right?
Er, I don't mean bytes in the put area exactly, but you know what I meanâ¦
what I'm asking is, how does your simplification relate to the task of figuring
out how many file bytes the buffers hold, without flushing them, which the code
does not currently seem designed to do.
For regression, note that the code previous to the linked patch was
// NB: Need to do this in case _M_file in indeterminate
// state, ie _M_file._offset == -1
pos_type __tmp = _M_file.seekoff(__off, ios_base::cur, __mode);
if (__tmp = 0)
{
// Seek successful.
__ret = __tmp;
__ret += std::max(this-_M_out_cur, this-_M_in_cur)
- _M_filepos;
}
which does not appear to do multibyte compensation correctly. Was _M_filepos
the number of file bytes in whichever area was currently being used?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
