[Bug target/35634] [avr] result of char promotion comes out of CHAR_MIN/MAX
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-19 07:07 --- As I already mentioned this is undefined code, overflow for signed integeral types is undefined. char is a weird type as it is considered one of the character types but it is still an integeral type. Also it is weird that it defualt to either signed or unsigned (implementation defined, in GCC's case it is ABI defined). For AVR, it defaults to signed. -- 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=35634
[Bug bootstrap/25502] Werror problem in build
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-19 07:09 --- (In reply to comment #10) > Still, 4.3.0 can't recoginze %I64d And that is because it is just being added: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01109.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
100mg x 10 pills $7.00 per pill price
buy now 50mg x 30 pills US $ 89.95 http://maribelquirkqt898.blogspot.com
[Bug target/35504] incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions
--- Comment #5 from uros at gcc dot gnu dot org 2008-03-19 07:49 --- Subject: Bug 35504 Author: uros Date: Wed Mar 19 07:48:16 2008 New Revision: 16 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=16 Log: PR target/35504 * config/i386/i386.c (x86_this_parameter): Calculate correct location of "this" pointer when "regparm = N" or "fastcall" is in effect. testsuite/ChangeLog PR target/35504 * g++.dg/other/pr35504.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/pr35504.C - copied unchanged from r133324, trunk/gcc/testsuite/g++.dg/other/pr35504.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35504
[Bug target/35504] incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions
--- Comment #6 from ubizjak at gmail dot com 2008-03-19 08:05 --- Fixed for 4.3 and 4.4, no plans for backport to earlier branches. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35504
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2008-03-19 08:37 --- I'm hit by this, too - don't know when it started (it's in a namelist I've been using for years). -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added CC||toon at moene dot indiv dot ||nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug debug/35615] Debug information for .debug_loc section incorrect
--- Comment #10 from deuling at de dot ibm dot com 2008-03-19 08:48 --- I attached the binary compiled with gfortran 4.3 on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
[Bug debug/35615] Debug information for .debug_loc section incorrect
--- Comment #9 from deuling at de dot ibm dot com 2008-03-19 08:48 --- Created an attachment (id=15342) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15342&action=view) x86 binary (neg_array.F) with gfortran 4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
[Bug libfortran/32972] performance of pack/unpack
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-03-19 09:26 --- Here's something for internal_pack and internal_unpack: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01121.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug target/35634] [avr] result of char promotion comes out of CHAR_MIN/MAX
--- Comment #3 from schwab at suse dot de 2008-03-19 09:56 --- Actually, there is no undefined behaviour here, as long as CHAR_MAX < INT_MAX no overflow occurs. c++ is the same as c = (int)c + 1 (when ignoring the result), and the conversion from int to char is implementation defined. For gcc the result of such a conversion is always in the range of the target type. -- schwab at suse dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug testsuite/34168] runtime tests in gfortran.dg/vect fail for unsupported [non-SSE2] targets
--- Comment #3 from victork at gcc dot gnu dot org 2008-03-19 09:31 --- *** Bug 34878 has been marked as a duplicate of this bug. *** -- victork at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34168
[Bug testsuite/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #9 from victork at gcc dot gnu dot org 2008-03-19 09:31 --- *** This bug has been marked as a duplicate of 34168 *** -- victork at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug c/35634] [avr] result of char promotion comes out of CHAR_MIN/MAX
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-19 10:23 ---
This is a bug in the C frontend which does the increment on type char, not
on the promoted type (I noticed that while fixing bitfield issues as well),
code in question is in build_unary_op() and this way since forever.
Original dump as from the FE:
;; Function main (main)
;; enabled by -tree-original
{
char c;
char c;
c = 0;
:;
foo ((int) c);
c++ ;
goto ;
}
I tried to fix this once but failed. Joseph - can you give this a shot?
The FE should for all pre-/postincrements just emit the proper
{( int res = x; x = (typeof x)((int)x + 1); res; )}
with using TARGET_EXPR/COMPOUND_EXPRs as required.
Note the C++ frontend has the same problem here, so transition that bug
there once the C FE is fixed.
Thanks.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Component|target |c
Ever Confirmed|0 |1
Keywords||wrong-code
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2008-03-19 10:23:48
date||
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [avr] result of char promotion comes out of CHAR_MIN/MAX
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-19 10:26 --- To quote the standard (6.5.4.1/2): "The expression ++E is equivalent to (E+=1). See the discussions of additive operators and compound assignment for information on constraints, types, side effects, and CONVERSIONS and the effects of operations on pointers" emphasise mine, 6.5.6/4 then of course says "If both operands have arithmetic type, the usual arithmetic conversions are performed on them." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug libstdc++/35637] New: tr1::function fails with const member function pointer
The following program fails under GCC 4.3.0 in pedantic mode, but works under
4.2.3.
#include
struct S
{
void F() const {}
};
int main()
{
std::tr1::function a(&S::F); // doesn't work
std::tr1::function b(std::mem_fun(&S::F)); // works
}
g++ -c -pedantic test.cpp
...
c:/devel/mingw/lib/gcc/../../include/c++/4.3.0/tr1_impl/type_traits:320: error:
ignoring 'const' qualifiers added to function type 'void ()()const'
I think the problem has to do with the way the signature gets decomposed. It
starts off as void(S::*)()const. Next, tr1::is_member_function_pointer removes
S::*, yielding void()()const. Finally, tr1::is_function calls remove_cv, which
produces the above error.
--
Summary: tr1::function fails with const member function pointer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name
GCC host triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug testsuite/34168] runtime tests in gfortran.dg/vect fail for unsupported [non-SSE2] targets
--- Comment #4 from victork at gcc dot gnu dot org 2008-03-19 10:37 --- I've submitted a patch http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01129.html to fix this in testsuite. -- victork at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |victork at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-02-26 17:52:23 |2008-03-19 10:37:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34168
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Comment #23 from ubizjak at gmail dot com 2008-03-19 10:38 --- As stated in comment #16 and #17, the LCM infrastructure doesn't support mode switching in the way that would be usable for emms. Additionally, there are MANY problems expected when sharing x87 and MMX registers (i.e. handling of uninitialized x87 registers at the beginning of the function - this is the reason we don't implement x87 register passing ABI). Automatic MMX vectorization is not exactly a much usable feature nowadays (we have SSE that works quite well here). Due to recent changes in MMX register allocation area, excellent code is produced using MMX intrinsics, I'm closing this bug as WONTFIX. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #23 from ubizjak at gmail dot com 2008-03-19 10:45 --- As said in PR 19161: The LCM infrastructure doesn't support mode switching in the way that would be usable for emms. Additionally, there are MANY problems expected when sharing x87 and MMX registers (i.e. handling of uninitialized x87 registers at the beginning of the function - this is the reason we don't implement x87 register passing ABI). Automatic MMX vectorization is not exactly a much usable feature nowadays (we have SSE that works quite well here). Due to recent changes in MMX register allocation area, excellent code is produced using MMX intrinsics, I'm closing this bug as WONTFIX. Also, auto-vectorization would produce either MMX or SSE code, but not both of them: #define UNITS_PER_SIMD_WORD (TARGET_SSE ? 16 : UNITS_PER_WORD) -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug tree-optimization/35609] [4.3/4.4 Regression] "is used uninitialized in this function" should be may warning
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-19 10:45 --- Subject: Bug 35609 Author: rguenth Date: Wed Mar 19 10:44:52 2008 New Revision: 133341 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133341 Log: 2008-03-19 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/35609 * tree-ssa.c (always_executed): New global flag. (warn_uninitialized_var): If !always_executed warn with "maybe" instead of "is". (execute_early_warn_uninitialized): Compute post-dominators. Initialize always_executed before processing each basic block. * gcc.dg/testsuite/uninit-15.c: New testcase. * gcc.dg/testsuite/uninit-16.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/uninit-15.c trunk/gcc/testsuite/gcc.dg/uninit-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
[Bug tree-optimization/35609] [4.3 Regression] "is used uninitialized in this function" should be may warning
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-19 10:45 --- Fixed on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.3 |4.2.3 4.4.0 Summary|[4.3/4.4 Regression] "is|[4.3 Regression] "is used |used uninitialized in this |uninitialized in this |function" should be may |function" should be may |warning |warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
[Bug c++/35638] New: Internal error when trying to compile recursively instantiated class template
Compiler seg faults when trying to compile a recursively instantiated class template, possibly due to depth of recoursion -- Summary: Internal error when trying to compile recursively instantiated class template Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: james dot a dot kirkpatrick at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35638
[Bug c++/35638] Internal error when trying to compile recursively instantiated class template
--- Comment #1 from james dot a dot kirkpatrick at gmail dot com 2008-03-19 10:59 --- Created an attachment (id=15343) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15343&action=view) code for which error is obtained g++ -ftemplate-depth-10 ackermann.cc is the argument for compilation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35638
[Bug other/35094] RTL dump file letters hosed and partly undocumented
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-03-19 11:23 --- Subject: Bug 35094 Author: hubicka Date: Wed Mar 19 11:22:40 2008 New Revision: 133342 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133342 Log: * gcc.dg/20050811-2.c: Update dumping flags. * gcc.dg/sms-2.c: Update dumping flags. * gcc.dg/var-expand1.c: Update dumping flags. * gcc.dg/var-expand3.c: Update dumping flags. * gcc.dg/pr30957-1.c: Update dumping flags. * gcc.dg/20050811-1.c: Update dumping flags. * gcc.dg/cpp/cmdlne-dI-M.C: Do not xfail. * gcc.dg/cpp/cmdlne-dM-M.C: Do not xfail. PR other/35094 * toplev.c (decode_d_option): Handle all CPP flags. * tree-vrp.c: Update tree_pass descriptors. * regrename.c: Update tree_pass descriptors. * fwprop.c: Update tree_pass descriptors. * doc/invoke.texi: Remove documentation of dropped -d? flags. * tree-into-ssa.c: Update tree_pass descriptors. * tree-dump.c: Update tree_pass descriptors. * tree-complex.c: Update tree_pass descriptors. * tree-dump.h: Update tree_pass descriptors. * see.c: Update tree_pass descriptors. * cgraphbuild.c: Update tree_pass descriptors. * tracer.c: Update tree_pass descriptors. * tree-loop-distribution.c: Update tree_pass descriptors. * cgraph.c: Update tree_pass descriptors. * postreload-gcse.c: Update tree_pass descriptors. * postreload.c: Update tree_pass descriptors. * tree-ssa-loop-ch.c: Update tree_pass descriptors. * tree-tailcall.c: Update tree_pass descriptors. * tree-pass.h (tree_opt_pass): Rename to ... (opt_pass) ... this one; add "type" field and remove letter field. (gimple_opt_pass, rtl_opt_pass, simple_ipa_opt_pass): New. (execute_pass_list, execute_ipa_pass_list, all_passes, all_ipa_passes, all_lowering_passes): Update declaration. * ipa-cp.c: Update tree_pass descriptors. * final.c: Update tree_pass descriptors. * omp-low.c: Update tree_pass descriptors. * tree-ssa-dse.c: Update tree_pass descriptors. * ipa-reference.c: Update tree_pass descriptors. * tree-ssa-uncprop.c: Update tree_pass descriptors. * auto-inc-dec.c: Update tree_pass descriptors. * reorg.c: Update tree_pass descriptors. * cgraphunit.c: Update tree_pass descriptors. * tree-ssa-copyrename.c: Update tree_pass descriptors. * tree-ssa-ccp.c: Update tree_pass descriptors. * df-core.c: Update tree_pass descriptors. * mode-switching.c: Update tree_pass descriptors. * tree-nomudflap.c: Update tree_pass descriptors. * modulo-sched.c: Update tree_pass descriptors. * ipa-pure-const.c: Update tree_pass descriptors. * cse.c: Update tree_pass descriptors. * web.c: Update tree_pass descriptors. * tree-stdarg.c: Update tree_pass descriptors. * tree-ssa-math-opts.c: Update tree_pass descriptors. * tree-ssa-dom.c: Update tree_pass descriptors. * tree-nrv.c: Update tree_pass descriptors. * tree-ssa-alias.c: Update tree_pass descriptors. * loop-init.c: Update tree_pass descriptors. * gimple-low.c: Update tree_pass descriptors. * ipa-inline.c: Update tree_pass descriptors. * tree-ssa-sink.c: Update tree_pass descriptors. * global.c: Update tree_pass descriptors. * ifcvt.c: Update tree_pass descriptors. * jump.c: Update tree_pass descriptors. * predict.c: Update tree_pass descriptors. * tree-ssa-loop.c: Update tree_pass descriptors. * recog.c: Update tree_pass descriptors. * dse.c: Update tree_pass descriptors. * tree-ssa-ifcombine.c: Update tree_pass descriptors. * tree-eh.c: Update tree_pass descriptors. * regmove.c: Update tree_pass descriptors. * local-alloc.c * function.c: Update tree_pass descriptors. * tree-vectorizer.c: Update tree_pass descriptors. * gcse.c: Update tree_pass descriptors. * ipa-type-escape.c: Update tree_pass descriptors. * tree-if-conv.c: Update tree_pass descriptors. * init-regs.c: Update tree_pass descriptors. * ipa.c: Update tree_pass descriptors. * tree-ssa-phiopt.c: Update tree_pass descriptors. * rtl-factoring.c: Update tree_pass descriptors. * lower-subreg.c: Update tree_pass descriptors. * bt-load.c: Update tree_pass descriptors. * tree-dfa.c: Update tree_pass descriptors. * except.c: Update tree_pass descriptors. * emit-rtl.c: Update tree_pass descriptors. * cfgexpand.c: Update tree_pass descriptors. * tree-cfgcleanup.c: Update tree_pass descriptors. * cfgcleanup.c: Update tree_pass descriptors. * tree-ssa-pre.c: Update tree_pass descriptors.
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-03-19 12:35 --- I believe the problem is actual;y in read_logical and occurs on a short read. By short, I mean the case where we provide fewer data items in the namelist file then there are in the logical array. I am curious what has triggered this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug c++/35631] operator overloads defined as a friend within a class are not always correctly resolved
--- Comment #2 from nick dot orlov at mail dot ru 2008-03-19 12:44 --- Standard says: 11.4.6. A function can be defined in a friend declaration of a class if and only if the class is a non-local class (9.8), the function name is unqualified, and the function has namespace scope. 11.4.7 Such a function is implicitly inline. A friend function defined in a class is in the (lexical) scope of the class in which it is defined. A friend function defined outside the class is not (3.4.1) === So I would agree, but in my example operator is being called from a (static) class method. -- nick dot orlov at mail dot ru changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35631
[Bug c++/34022] C++0x: rvalue references and std::forward() broken with built-in types
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-03-19 13:12 --- This is core issue 664: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#664 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34022
[Bug tree-optimization/35629] [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-19 13:23 --- I think revision 133313 http://gcc.gnu.org/ml/gcc-cvs/2008-03/msg00531.html is the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35629
[Bug other/35094] RTL dump file letters hosed and partly undocumented
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-03-19 14:25 --- Dump letters removed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35094
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #21 from uros at gcc dot gnu dot org 2008-03-19 14:51 --- Subject: Bug 35496 Author: uros Date: Wed Mar 19 14:50:15 2008 New Revision: 133343 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133343 Log: PR target/35496 * stor-layout.c (update_alignment_for_field): Set minimum alignment of the underlying type of a MS bitfield layout to the natural alignment of the type. Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #22 from ubizjak at gmail dot com 2008-03-19 14:57 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug libfortran/32972] performance of pack/unpack
--- Comment #12 from tkoenig at gcc dot gnu dot org 2008-03-19 15:43 --- Subject: Bug 32972 Author: tkoenig Date: Wed Mar 19 15:42:55 2008 New Revision: 133344 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133344 Log: 2008-03-19 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/32972 * Makefile.am (in_pack_c): Add in_pack_i1.c, in_pack_i2.c, in_pack_r4.c, in_pack_r8.c, in_pack_r10.c and in_pack_r16.c. (in_unpack_c): Add in_unpack_i1.c, in_unpack_i2.c, in_unpack_r4.c, in_unpack_r8.c, in_unpack_r10.c and in_unpack_r16.c. * Makefile.in: Regenerate. * libgfortran.h: Add prototypes for internal_pack_1, internal_pack_2, internal_pack_16, internal_pack_r4, internal_pack_r8, internal_pack_r10, internal_pack_r16, internal_pack_c10 and internal_pack_c16. Add prototypes for internal_unpack_1, internal_unpack_2, internal_unpack_16, internal_unpack_r4, internal_unpack_r8, internal_unpack_r10, internal_unpack_r16, internal_unpack_c10 and internal_unpack_c16. * runtime/in_pack_generic.c (internal_pack): Use sizeof instead of hardwired sizes. Add calls to internal_pack_1, internal_pack_2, internal_pack_16, internal_pack_r4, internal_pack_r8, internal_pack_r10, internal_pack_r16, internal_pack_c10 and internal_pack_c16. * runtime/in_unpack_generic.c (internal_unpack): Use sizeof instead of hardwired sizes. Add calls to internal_unpack_1, internal_unpack_2, internal_unpack_16, internal_unpack_r4, internal_unpack_r8, internal_unpack_r10, internal_unpack_r16, internal_unpack_c10 and internal_unpack_c16. * generated/in_pack_r4.c: New file. * generated/in_pack_i2.c: New file. * generated/in_unpack_i1.c: New file. * generated/in_pack_r10.c: New file. * generated/in_unpack_r4.c: New file. * generated/in_unpack_i2.c: New file. * generated/in_unpack_r16.c: New file. * generated/in_pack_r8.c: New file. * generated/in_unpack_r10.c: New file. * generated/in_unpack_r8.c: New file. * generated/in_pack_r16.c: New file. * generated/in_pack_i1.c: New file. 2008-03-19 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/32972 * gfortran.dg/internal_pack_1.f90: New test case. * gfortran.dg/internal_pack_2.f90: New test case. * gfortran.dg/internal_pack_3.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/internal_pack_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_2.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_3.f90 trunk/libgfortran/generated/in_pack_i1.c trunk/libgfortran/generated/in_pack_i2.c trunk/libgfortran/generated/in_pack_r10.c trunk/libgfortran/generated/in_pack_r16.c trunk/libgfortran/generated/in_pack_r4.c trunk/libgfortran/generated/in_pack_r8.c trunk/libgfortran/generated/in_unpack_i1.c trunk/libgfortran/generated/in_unpack_i2.c trunk/libgfortran/generated/in_unpack_r10.c trunk/libgfortran/generated/in_unpack_r16.c trunk/libgfortran/generated/in_unpack_r4.c trunk/libgfortran/generated/in_unpack_r8.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/in_pack_generic.c trunk/libgfortran/runtime/in_unpack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug tree-optimization/35639] New: -fprofile-generate + PRE = big compile-time
The attached .i file (from sed) spends 50% of its compilation time on PRE with "-fprofile-generate -O2". -- Summary: -fprofile-generate + PRE = big compile-time Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug tree-optimization/35639] -fprofile-generate + PRE = big compile-time
--- Comment #1 from bonzini at gnu dot org 2008-03-19 15:51 --- Created an attachment (id=15344) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15344&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug tree-optimization/35639] -fprofile-generate + PRE = big compile-time
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-19 15:52:03 date|| Summary|-fprofile-generate + PRE = |-fprofile-generate + PRE = |big compile-time|big compile-time http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #6 from burnus at gcc dot gnu dot org 2008-03-19 15:54 --- (In reply to comment #5) > I believe the problem is actual;y in read_logical and occurs on a short read. > By short, I mean the case where we provide fewer data items in the namelist > file then there are in the logical array. I am curious what has triggered > this. I think it has something to do with read_real, though different from what I thought. In any case, we end up in read_real, trying to match "NaN" and go to unwind. However, afterwards it shows an error for "xlbtna" (for which read_real is called) and not for the item that comes next and is not NaN, namely "nbshapa". Just before the return, line_buffer contains in "unwind:" of read_real: line_buffer[0] == '\0' line_buffer[1] == 'n' line_buffer[2] == 'b' The problem is that the first element is '\0' and thus the rewinding does not happen. If one changes "nbshapa" into "nnnbshapa" it works. Thus the question is : Where does the "\0" come from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug libfortran/32972] performance of pack/unpack
--- Comment #13 from dominiq at lps dot ens dot fr 2008-03-19 16:48 --- There is a typo in libgfortran/runtime/in_pack_generic.c: --- ../_gcc_clean/libgfortran/runtime/in_pack_generic.c 2008-03-19 16:56:42.0 +0100 +++ ../gcc-4.4-work/libgfortran/runtime/in_pack_generic.c 2008-03-19 17:45:27.0 +0100 @@ -81,7 +81,7 @@ #if defined(HAVE_GFC_INTEGER_16) case sizeof (GFC_INTEGER_16): - return internal_pack_16 (gfc_array_i16 *) source); + return internal_pack_16 ((gfc_array_i16 *) source); #endif } break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug libfortran/32972] performance of pack/unpack
--- Comment #14 from tkoenig at gcc dot gnu dot org 2008-03-19 16:57 --- Subject: Bug 32972 Author: tkoenig Date: Wed Mar 19 16:56:22 2008 New Revision: 133345 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133345 Log: 2008-03-19 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/32972 * runtime/in_pack_generic.c (internal_pack): Fix typo in last commit. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/in_pack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug libfortran/32972] performance of pack/unpack
--- Comment #15 from tkoenig at gcc dot gnu dot org 2008-03-19 16:58 --- (In reply to comment #13) > There is a typo in libgfortran/runtime/in_pack_generic.c: Fixed. Thanks a lot for catching that one, Dominique! I would have hated to break bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug c++/35640] New: invalid access to protected base class
class A {
};
class B: protected A {
};
class C: protected A {
public:
C(B & b);
};
C::C(B & b)
: A(b)
{
}
int main() {
B b;
C c(b);
return 0;
}
should give an error for : A(b), the conversion from B to A is invalid as A is
protected.
This still fails on 4.4.0 20080317
radr://5805511
--
Summary: invalid access to protected base class
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35640
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-03-19 17:55 --- What I observed is that if you change the namelist file to nlco = 200*.TRUE. the subsequent real reads work fine. Likewise if you move the logical to the end after the real reads, it works fine. So this is why I suspect the read_logical may have an off by one leftover in line_buffer or we are not cleaning up correctly on that. This may be where the spurious \0 is coming from. I will have more time to look into it in the next few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug c++/35641] New: ICE on overload of friend function definition inside a class
The following:
**
template
struct Message
{
friend ostream & operator << (ostream & out, const Message & self)
{
cout << __PRETTY_FUNCTION__ << endl;
return out;
}
};
typedef Message IntMsg;
inline ostream & operator << (ostream & out, const IntMsg & self)
{
cout << __PRETTY_FUNCTION__ << endl;
return out;
}
int main()
{
IntMsg m;
cout << m << endl;
}
Produces:
*
templateoverload.cpp: In function `std::ostream& operator<<(std::ostream&,
const IntMsg&)':
templateoverload.cpp:33: instantiated from here
templateoverload.cpp:0: internal compiler error: in change_decl_assembler_name,
at cgraph.c:541
Resolved with out-of-class definition:
**
template
inline ostream & operator << (ostream & out, const Message & self)
{
cout << __PRETTY_FUNCTION__ << endl;
return out;
}
--
Summary: ICE on overload of friend function definition inside a
class
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe at fornux dot com
GCC build triplet: gcc version 3.4.5 (mingw special)
GCC host triplet: Windows XP
GCC target triplet: Mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35641
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #8 from burnus at gcc dot gnu dot org 2008-03-19 18:29 --- > So this is why I suspect the read_logical may have an off by one leftover I think you are right. In that sense it is an only bug which was only exposed by the new NaN support. Not very elegent, but the following works. One should probably do an audit of all l_push_char. The following works here, but I do not understand why element [0] was '\0' and not something else. Index: libgfortran/io/list_read.c === --- libgfortran/io/list_read.c (Revision 133342) +++ libgfortran/io/list_read.c (Arbeitskopie) @@ -680,6 +680,7 @@ read_logical (st_parameter_dt *dtp, int break; CASE_SEPARATORS: + dtp->u.p.item_count--; unget_char (dtp, c); eat_separator (dtp); return; /* Null value. */ @@ -741,6 +742,7 @@ read_logical (st_parameter_dt *dtp, int bad_logical: + dtp->u.p.item_count--; free_line (dtp); if (nml_bad_return (dtp, c)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug tree-optimization/35642] New: heisenbug in tree vectorizer
with svn version 133159 the following bugs show up in the tree vectorizer if you do not bootstrap the compiler: FAIL: gcc.dg/vect/vect-strided-store-u16-i4.c scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/vect-vfa-03.c scan-tree-dump-times vect "vectorized 1 loops" 1 XPASS: gcc.dg/vect/vect-vfa-03.c scan-tree-dump-times vect "vectorized 1 loops" 0 FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect "vectorized 4 loops" 1 FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 and the bugs go away when you bootstrap. I have made modifications to register allocator, and these downstream changes cause the compiler to be enough different so that the bugs become hard failures. however the bugs are easily reproducible by --enable-languages=c --with-cpu=default-32 --disable-multilib --disable-bootstrap with this version of the compiler. I have not played around with this in other revisions. I know that this combo will reproduce the issue. Since this is most likely a storage leak or an uninitialized variable, it is important to recreate the environment exactly. Kenny -- Summary: heisenbug in tree vectorizer Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zadeck at naturalbridge dot com GCC build triplet: powerpc-unknown-linux-gnu 32 bit compiler http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug rtl-optimization/35643] New: gcc-4.2 -O1 -fstrict-aliasing misoptimization
When I compile the testcase with -O2, or with '-O1 -fstrict-aliasing' incorrect code is generated. The testcase calls abort() in this case. This is a regression in gcc-4.2 only: gcc-4.1 and gcc-4.3 do not show the bug. $ gcc-4.2 -O1 test.i -o ok && ./ok $ gcc-4.2 -O2 test.i -o fails && ./fails Aborted $ gcc-4.2 -O1 -fstrict-aliasing test.i -o fails2 && ./fails2 Aborted $ gcc-4.2 -O3 test.i -o fails3 && ./fails3 Aborted The testcase gives no warnings: $ gcc-4.2 -Wall -W -O2 -Wstrict-aliasing test.i The original code that is miscompiled is ClamAV, but only if -O3 is used. I created an initial reduced testcase using delta. Manually inlining some functions show this bug even at -O2 on the reduced testcase. I reproduced this on 2 different systems: [EMAIL PROTECTED]:~$ uname -a Linux lightspeed2 2.6.25-rc4-00134-g84c6f60 #4 Sun Mar 9 19:40:34 EET 2008 x86_64 GNU/Linux [EMAIL PROTECTED]:~$ gcc-4.2 -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --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.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-2) I also reproduced the bug with gcc 4.2.3 built with --enable-checking=yes: [EMAIL PROTECTED]:~$ gcc-4.2.3/inst/bin/gcc -O1 -fstrict-aliasing test.i -o fails && ./fails Aborted [EMAIL PROTECTED]:~$ gcc-4.2.3/inst/bin/gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../configure --enable-languages=c --prefix=/home/edwin/gcc-4.2.3/obj/../inst --enable-checking=yes --disable-multilib --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap Thread model: posix gcc version 4.2.3 The second system: [EMAIL PROTECTED]:~$ uname -a Linux thunder 2.6.25-rc5-00323-g9a9e0d6 #22 SMP PREEMPT Sun Mar 16 10:23:46 EET 2008 i686 GNU/Linux [EMAIL PROTECTED]:~$ gcc-4.2 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --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.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-2) -- Summary: gcc-4.2 -O1 -fstrict-aliasing misoptimization Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35643
[Bug rtl-optimization/35643] gcc-4.2 -O1 -fstrict-aliasing misoptimization
--- Comment #1 from edwintorok at gmail dot com 2008-03-19 18:54 ---
Created an attachment (id=15345)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15345&action=view)
testcase
Some observations:
If you remove some dead code the optimization bug goes away:
Remove either of these and you'll get correct code, for example:
if (metadata->chunk_current >= metadata->chunk_end) {
}
If I remove that if and compare assembly output, I see this:
$ diff -wu bad.s ok.s
--- bad.s 2008-03-19 20:51:59.0 +0200
+++ ok.s2008-03-19 20:51:47.0 +0200
@@ -60,7 +60,7 @@
testb %al, %al
js .L9
movsbq %sil,%rax
- addq%rax, %rcx
+ leaq1(%rcx,%rax), %rcx
.L11:
movzbl (%rdx), %eax
addq$1, %rdx
Of course the original code that is miscompiled doesn't have dead code, it is
just because of the reduction.
If you need more info please ask.
This is related to this bug (but that occurs only at -O3):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470557
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35643
[Bug fortran/35152] Implicit procedure with keyword=argument is accepted
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-03-19 19:14 --- Subject: Bug 35152 Author: dfranke Date: Wed Mar 19 19:13:48 2008 New Revision: 133347 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133347 Log: gcc/fortran: 2008-03-19 Daniel Franke <[EMAIL PROTECTED]> PR fortran/35152 * interface.c (gfc_procedure_use): Check for keyworded arguments in procedures without explicit interfaces. gcc/testsuite: 2008-03-19 Daniel Franke <[EMAIL PROTECTED]> PR fortran/35152 * gfortran.dg/argument_checking_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/argument_checking_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35152
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-19 19:15 --- On PowerPC-darwin, I started to get the following failures between LAST_UPDATED: Wed Mar 12 03:41:52 UTC 2008 (revision 133132) and LAST_UPDATED: Tue Mar 18 21:37:03 UTC 2008 (revision 133327) +FAIL: gcc.dg/vect/vect-strided-store-u16-i4.c scan-tree-dump-times vect "vectorized 1 loops" 2 +FAIL: gcc.dg/vect/vect-vfa-03.c scan-tree-dump-times vect "vectorized 1 loops" 1 +XPASS: gcc.dg/vect/vect-vfa-03.c scan-tree-dump-times vect "vectorized 1 loops" 0 +FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect "vectorized 4 loops" 1 +FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 +FAIL: gcc.dg/vect/slp-7.c scan-tree-dump-times vect "vectorized 3 loops" 1 +FAIL: gcc.dg/vect/slp-7.c scan-tree-dump-times vect "vectorizing stmts using SLP" 3 I wonder if this is related to this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug fortran/35152] Implicit procedure with keyword=argument is accepted
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-03-19 19:15 --- Fixed in trunk, no backport as it is not a regression. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords|patch | Known to fail||4.3.0 Known to work||4.4.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35152
[Bug middle-end/35616] [4.1/4.2/4.3/4.4 Regression] Incorrect code while O2 compling
--- Comment #16 from matz at gcc dot gnu dot org 2008-03-19 19:15 --- Subject: Bug 35616 Author: matz Date: Wed Mar 19 19:15:03 2008 New Revision: 133348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133348 Log: PR middle-end/35616 * calls.c (expand_call): Check overlap of arguments with call address for sibcalls. * gcc.dg/pr35616.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr35616.c Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-19 19:17 --- I wonder if the following patch could have caused the use of a variable after a free: 2008-03-12 Victor Kaplansky <[EMAIL PROTECTED]> + Ira Rosen <[EMAIL PROTECTED]> + + * tree-vectorizer.c (free_stmt_vec_info): New function. + (destroy_loop_vec_info): Move code to free_stmt_vec_info(). + Call free_stmt_vec_info(). Free LOOP_VINFO_STRIDED_STORES.. + * tree-vectorizer.h (free_stmt_vec_info): Declare. + * tree-vect-transform.c (vectorizable_conversion): Free + vec_oprnds0 if it was allocated. + (vect_permute_store_chain): Remove unused VECs. + (vectorizable_store): Free VECs that are allocated in the.. + function. + (vect_transform_strided_load, vectorizable_load): Likewise. + (vect_remove_stores): Simplify the code. + (vect_transform_loop): Move code to vect_remove_stores(). + Call vect_remove_stores() and free_stmt_vec_info(). + -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #24 from astrange at ithinksw dot com 2008-03-19 19:21 ---
For
typedef short mmxw __attribute__ ((mode(V4HI)));
typedef int mmxdw __attribute__ ((mode(V2SI)));
mmxdw dw;
mmxw w;
void test(){
w+=w;
dw= (mmxdw)w;
}
void test2(){
w= __builtin_ia32_paddw(w,w);
dw= (mmxdw)w;
}
gcc SVN generates the expected code for test2(), but not test(). I don't think
using += on an MMX variable should count as autovectorization - if you're doing
either you should know where to put emms yourself.
For test() we get:
subl$28, %esp
movq_w, %mm0
movq%mm0, 8(%esp)
movzwl 8(%esp), %eax
movzwl 10(%esp), %edx
movzwl 12(%esp), %ecx
addl%eax, %eax
addl%edx, %edx
movw%ax, _w
movw%dx, _w+2
movzwl 14(%esp), %eax
addl%ecx, %ecx
addl%eax, %eax
movw%cx, _w+4
movw%ax, _w+6
movq_w, %mm0
movq%mm0, _dw
addl$28, %esp
ret
which touches mm0 (requiring emms, I think) but not using paddw (so being slow
and silly-looking).
LLVM generates expected code for both of them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #3 from zadeck at naturalbridge dot com 2008-03-19 19:26 --- I forgot to mention that valgrind does not find anything. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug rtl-optimization/35643] gcc-4.2 -O1 -fstrict-aliasing misoptimization
--- Comment #2 from edwintorok at gmail dot com 2008-03-19 19:35 --- Created an attachment (id=15346) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15346&action=view) another reduced testcase I reduced the testcase further using delta, however I had to be careful to avoid deleting initializations. This testcase is valgrind clean. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35643
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-03-19 19:37 --- I agree and plan to look at l_push_char. We just should never read a "\0" character. We may be ungetting it because we use "\0" to indicate that the line_buffer is empty and to not read from it, but maybe unget_char is not quite right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug middle-end/35616] [4.1/4.2/4.3/4.4 Regression] Incorrect code while O2 compling
--- Comment #17 from matz at gcc dot gnu dot org 2008-03-19 19:38 --- Subject: Bug 35616 Author: matz Date: Wed Mar 19 19:37:48 2008 New Revision: 133350 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133350 Log: Backport from mainline: PR middle-end/35616 * calls.c (expand_call): Check overlap of arguments with call address for sibcalls. * gcc.dg/pr35616.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr35616.c - copied unchanged from r133348, trunk/gcc/testsuite/gcc.dg/pr35616.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/calls.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #25 from astrange at ithinksw dot com 2008-03-19 19:39 --- Actually the first generates- subl$12, %esp movq_w, %mm0 paddw %mm0, %mm0 movq%mm0, _w movq_w, %mm0 movq%mm0, _dw addl$12, %esp ret which is better than the code in the original report but still has a useless store/reload. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug middle-end/35616] [4.1/4.2 Regression] Incorrect code while O2 compling
--- Comment #18 from matz at gcc dot gnu dot org 2008-03-19 19:40 --- trunk and 4.3 are fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|matz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Known to fail|3.4.0 4.0.4 4.1.3 4.4.0 |3.4.0 4.0.4 4.1.3 Priority|P2 |P4 Summary|[4.1/4.2/4.3/4.4 Regression]|[4.1/4.2 Regression] |Incorrect code while O2 |Incorrect code while O2 |compling|compling http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
[Bug rtl-optimization/35643] [4.2 Regression] gcc-4.2 -O1 -fstrict-aliasing misoptimization
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-19 19:56 ---
-O vs. -O -fstrict-aliasing. This is another flow-insensitive alias problem.
diff -u t.c.099t.optimized t.c.099t.optimizedx
--- t.c.099t.optimized 2008-03-19 20:45:05.0 +0100
+++ t.c.099t.optimizedx 2008-03-19 20:45:00.0 +0100
@@ -16,9 +16,9 @@
Analyzing Edge Insertions.
cli_chm_prepare_file (metadata)
{
- char * temp.77;
uint64_t section;
char * D.1574;
+ char * D.1572;
char * D.1565;
:
@@ -30,12 +30,10 @@
metadata->chunk_data = D.1565 + (char *) (unsigned int)
metadata->chunk_offset;
:;
- D.1574 = metadata->chunk_data + 20B;
- metadata->chunk_current = D.1574;
- temp.77 = D.1574 + 1B + (char *) (uint64_t) *D.1574;
- metadata->chunk_current = temp.77;
- section = (uint64_t) *temp.77;
- metadata->chunk_current = temp.77 + 1B;
+ D.1572 = metadata->chunk_data + 20B;
+ D.1574 = D.1572 + (char *) (uint64_t) *D.1572;
+ section = (uint64_t) *D.1574;
+ metadata->chunk_current = D.1574 + 1B;
if (section > 1) goto ; else goto ;
:;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||alias, wrong-code
Known to fail||4.2.3
Known to work||4.1.3 4.3.0
Last reconfirmed|-00-00 00:00:00 |2008-03-19 19:56:20
date||
Summary|gcc-4.2 -O1 -fstrict- |[4.2 Regression] gcc-4.2 -O1
|aliasing misoptimization|-fstrict-aliasing
||misoptimization
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35643
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-19 20:17 --- compile_program is the offending function. I'll probably can limit walking with the alias oracle. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-19 20:33 --- Created an attachment (id=15347) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15347&action=view) unincluded testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-19 20:35 --- Err, whoops? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug target/35619] gcc-4.3.0 build fails in gfortran section centos-4.6
--- Comment #9 from bill at cse dot ucdavis dot edu 2008-03-19 20:38 --- (In reply to comment #8) > (In reply to comment #6) > > Looks like the reason why it was not being fixed because of: > > __NTH (feof_unlocked (FILE *__stream)) > > > > So how would I fix it?(In reply to comment #6) > > Looks like the reason why it was not being fixed because of: > > __NTH (feof_unlocked (FILE *__stream)) > > > > BTW, this seems pretty common, I looked at Ubuntu Gutsy 7.10 system and it has > the same definition: > cat /usr/include/bits/stdio.h | grep feof_unlocked | head -1 > __NTH (feof_unlocked (FILE *__stream)) > I reproduced this error on Centos-5.1 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug bootstrap/25502] Werror problem in build
--- Comment #12 from dannysmith at users dot sourceforge dot net 2008-03-19 21:35 --- (In reply to comment #11) > (In reply to comment #10) > > Still, 4.3.0 can't recoginze %I64d > > > And that is because it is just being added: > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01109.html > Even with that patch, we still get "ISO C does not support the 'I64' printf length modifier" warnings because of --predantic. IMO, that warning is valid and useful and should not be "fixed". Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug bootstrap/35628] gcc-4.3.0 fails to build, mpfr problem, libmpfr.dylib, file is not of required architecture
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-19 21:49 --- This is a bug in how GMP and MPFR tries to figure out the target platform, it tries to always build a 64bit library on a 64bit machine even when the default is 32bits. Configure both GMP and MPFR with --host=powerpc-darwin . -- Pinski -- 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=35628
[Bug tree-optimization/35629] [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails
--- Comment #5 from danglin at gcc dot gnu dot org 2008-03-19 22:58 --- Also seen on hppa. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35629
[Bug tree-optimization/35629] [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails
--- Comment #6 from hubicka at ucw dot cz 2008-03-19 23:06 --- Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails This seems to affect about every target, but it is essentially harmless. I am discussing with Zdenek the proper fix. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35629
[Bug libgomp/35644] New: omp_set_num_threads not working?
This program aborts, much to my surprise.
#include
#include
int main()
{
// Explicitly set number of threads.
const int threads_wanted = 20;
omp_set_dynamic(false);
omp_set_num_threads(threads_wanted);
if (omp_get_num_threads() != threads_wanted)
abort();
// Do work.
return 0;
}
This is very similar to the omp_set_dynamic example in the OpenMP 3.0 draft
spec . See page 270.
--
Summary: omp_set_num_threads not working?
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35644
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #26 from uros at gcc dot gnu dot org 2008-03-19 23:39 ---
Subject: Bug 14552
Author: uros
Date: Wed Mar 19 23:38:35 2008
New Revision: 133354
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133354
Log:
PR target/14552
* config/i386/mmx.md (*mov_internal_rex64"): Adjust register
allocator preferences for "y" and "r" class registers.
("*mov_internal"): Ditto.
("*movv2sf_internal_rex64"): Ditto.
("*movv2sf_internal"): Ditto.
testsuite/ChangeLog:
PR target/14552
* gcc.target/i386/pr14552.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr14552.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/mmx.md
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #27 from ubizjak at gmail dot com 2008-03-19 23:46 --- (In reply to comment #25) > Actually the first generates- > subl$12, %esp > movq_w, %mm0 > paddw %mm0, %mm0 > movq%mm0, _w > movq_w, %mm0 > movq%mm0, _dw > addl$12, %esp > ret > > which is better than the code in the original report but still has a useless > store/reload. The store is not useless. Reload from "_w" is how gcc handles double stores nowadays and is not mmx specific. It looks that some pass forgot to check where the value came from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #28 from pinskia at gcc dot gnu dot org 2008-03-19 23:49 --- (In reply to comment #27) > The store is not useless. Reload from "_w" is how gcc handles double stores > nowadays and is not mmx specific. It looks that some pass forgot to check > where > the value came from. Do you happen to know if there are two different modes at work here? If so there are patches which fix this up in DSE and post-reload CSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #29 from ubizjak at gmail dot com 2008-03-20 00:01 --- Now we generate: -m32 -mmmx -msse2: test: subl$20, %esp movlw, %eax movlw+4, %edx movl%ebx, 12(%esp) movl%esi, 16(%esp) movl%eax, (%esp) movzwl (%esp), %ecx movl%edx, 4(%esp) movzwl 2(%esp), %ebx movzwl 4(%esp), %esi movzwl 6(%esp), %eax addl%ecx, %ecx addl%ebx, %ebx addl%esi, %esi addl%eax, %eax movw%bx, w+2 movl12(%esp), %ebx movw%si, w+4 movl16(%esp), %esi movw%ax, w+6 movlw+4, %edx movw%cx, w movlw, %eax movl%edx, dw+4 movl%eax, dw addl$20, %esp ret -m64 -mmmx -msse2: test: movabsq $9223231297218904063, %rax andqw(%rip), %rax addq%rax, %rax movq%rax, w(%rip) movqw(%rip), %rax movq%rax, dw(%rip) ret The issue with useless reload is PR 12395, as mentioned in Comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #30 from ubizjak at gmail dot com 2008-03-20 00:04 --- (In reply to comment #28) > (In reply to comment #27) > > The store is not useless. Reload from "_w" is how gcc handles double stores > > nowadays and is not mmx specific. It looks that some pass forgot to check > > where > > the value came from. > > Do you happen to know if there are two different modes at work here? If so > there are patches which fix this up in DSE and post-reload CSE. Yes, from comment #24 (slightly changed): typedef short mmxw __attribute__ ((vector_size (8))); typedef int mmxdw __attribute__ ((vector_size (8))); mmxdw dw; mmxw w; so, we have V4HI and V2SI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
Re: [Bug target/14552] compiled trivial vector intrinsic code is inefficient
See pr 33790. Sent from my iPhone On Mar 19, 2008, at 17:04, "ubizjak at gmail dot com" <[EMAIL PROTECTED] > wrote: --- Comment #30 from ubizjak at gmail dot com 2008-03-20 00:04 --- (In reply to comment #28) (In reply to comment #27) The store is not useless. Reload from "_w" is how gcc handles double stores nowadays and is not mmx specific. It looks that some pass forgot to check where the value came from. Do you happen to know if there are two different modes at work here? If so there are patches which fix this up in DSE and post-reload CSE. Yes, from comment #24 (slightly changed): typedef short mmxw __attribute__ ((vector_size (8))); typedef int mmxdw __attribute__ ((vector_size (8))); mmxdw dw; mmxw w; so, we have V4HI and V2SI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #31 from pinskia at gmail dot com 2008-03-20 00:23 --- Subject: Re: compiled trivial vector intrinsic code is inefficient See pr 33790. Sent from my iPhone On Mar 19, 2008, at 17:04, "ubizjak at gmail dot com" <[EMAIL PROTECTED] > wrote: > > > --- Comment #30 from ubizjak at gmail dot com 2008-03-20 00:04 > --- > (In reply to comment #28) >> (In reply to comment #27) >>> The store is not useless. Reload from "_w" is how gcc handles >>> double stores >>> nowadays and is not mmx specific. It looks that some pass forgot >>> to check where >>> the value came from. >> >> Do you happen to know if there are two different modes at work >> here? If so >> there are patches which fix this up in DSE and post-reload CSE. > > Yes, from comment #24 (slightly changed): > > typedef short mmxw __attribute__ ((vector_size (8))); > typedef int mmxdw __attribute__ ((vector_size (8))); > > mmxdw dw; > mmxw w; > > so, we have V4HI and V2SI. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug ada/35645] New: ICE in gimplify_expr, at gimplify.c:6120
Not sure the declaration below is legal, but it ICEs anyway. package pak1 is type T1(x1: integer) is record x2: integer := T1.x1; end record; end pak1; gcc-4.1 -c pak1.ads +===GNAT BUG DETECTED==+ | 4.1.3 20070518 (prerelease) (Debian 4.1.2-8) (x86_64-pc-linux-gnu) GCC error:| | in gimplify_expr, at gimplify.c:4519 | | No source file position information available| +===GNAT BUG DETECTED==+ | 4.2.2 (i686-unknown-linux-gnu) in gimplify_expr, at gimplify.c:5888 | | No source file position information available| gcc-4.3 -c pak1.ads +===GNAT BUG DETECTED==+ | 4.3.1 20080309 (prerelease) (x86_64-pc-linux-gnu) GCC error: | | in gimplify_expr, at gimplify.c:6120 | | Error detected around pak1.ads:3 | -- Summary: ICE in gimplify_expr, at gimplify.c:6120 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35645
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #32 from astrange at ithinksw dot com 2008-03-20 00:39 ---
This is missed on trees:
mmxdw dw;
mmxw w;
void test2(){
w= __builtin_ia32_paddw(w,w); w= (mmxdw)w;
}
void test3(){
mmxw w2= __builtin_ia32_paddw(w,w); dw= (mmxdw)w2;
}
test2 ()
{
vector short int w.4;
vector short int w.3;
:
w.3 = w;
w.4 = __builtin_ia32_paddw (w.3, w.3);
w = w.4;
dw = VIEW_CONVERT_EXPR(w);
return;
}
test3 ()
{
mmxw w2;
vector short int w.6;
:
w.6 = w;
w2 = __builtin_ia32_paddw (w.6, w.6);
dw = VIEW_CONVERT_EXPR(w2);
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug fortran/35632] [Regression] stream io broken on FreeBSD due to ftruncate changes.
--- Comment #6 from kargl at gcc dot gnu dot org 2008-03-20 00:56 ---
(In reply to comment #4)
> Since I do not have access to this system, can you try this:
>
> Index: transfer.c
> ===
> --- transfer.c (revision 133275)
> +++ transfer.c (working copy)
> @@ -2604,7 +2604,8 @@ next_record_w (st_parameter_dt *dtp, int
> if (is_stream_io (dtp))
> {
> dtp->u.p.current_unit->strm_pos += len;
> - struncate(dtp->u.p.current_unit->s);
> + if (done)
> + struncate(dtp->u.p.current_unit->s);
> }
> }
>
> streamio_15.f90 passes with this and it should reduce the number of calls to
> truncate. If this fixes it, then I would think we have some other latent bug
> and not really fixed it.
>
The patch does not fix the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35632
[Bug ada/34496] [4.2/4.3 Regression] prefixed notation allows changing the value of a constant
--- Comment #3 from ludovic at ludovic-brenta dot org 2008-03-20 01:01 --- Still present in 4.3.0: $ gnatmake -gnat05 test1 gcc-4.3 -c -gnat05 test1.adb gnatbind -x test1.ali gnatlink test1.ali $ ./test1 3 raised STORAGE_ERROR : stack overflow (or erroneous memory access) I am not concerned about the stack overflow because the program is illegal anyway. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Known to fail||4.2.2 4.3.0 Summary|[4.2 Regression] prefixed |[4.2/4.3 Regression] |notation allows changing the|prefixed notation allows |value of a constant |changing the value of a ||constant http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34496
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-03-20 01:17 --- Created an attachment (id=15348) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15348&action=view) A final patch l_push_char assumes the index which is item_count has been set to zero and after saving a character it bumps the index. This bug has been latent for a long time, Forgot to set item_count back to zero when when freeing the line_buffer. The simplest fix is this: @@ -741,6 +742,7 @@ read_logical (st_parameter_dt *dtp, int bad_logical: + dtp->u.p.item_count = 0; free_line (dtp); if (nml_bad_return (dtp, c)) However, I am going to move this reseting into free_line where it ought to be. The attachment is the final fix with some cleanup. Regression tested on x86-64. I will commit as obvious with the new test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug target/35646] New: gcc is not using the overflow flag
Two simple examples:
unsigned int add(unsigned int a,unsigned int b) {
if (a+bhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=35646
Come join me on ssbbw4u...
Come join me on ssbbw4u. Click here to join: http://ssbbw4u.ning.com/?xgi=ejLIHno Thanks, P Alb
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #33 from michaelni at gmx dot at 2008-03-20 01:37 --- Subject: Re: compiled trivial vector intrinsic code is inefficient On Wed, Mar 19, 2008 at 11:39:18PM -, uros at gcc dot gnu dot org wrote: > > > --- Comment #26 from uros at gcc dot gnu dot org 2008-03-19 23:39 --- > Subject: Bug 14552 [...] > * gcc.target/i386/pr14552.c: New test. > > > Added: > trunk/gcc/testsuite/gcc.target/i386/pr14552.c Thanks, i was already scared that the inverse proportional relation between version number and performance which was so nicely followed since 2.95 would stop. Adding a test to the testsuit to ensure that mmx intrinsics dont use mmx registers is well, just brilliant. Iam already eagerly awaiting the testcase which will check that floating point code doesnt use the FPU, i assume that will happen in gcc 5.0? Anyway iam glad ffmpeg compiles fine under icc. [...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-03-20 02:05 --- Subject: Bug 35627 Author: jvdelisle Date: Thu Mar 20 02:05:05 2008 New Revision: 133360 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133360 Log: 2008-03-19 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/35627 * io/list_read.c (free_line): Clear the line buffer enable flag and reset the index into line_buffer, aka item_count. (next_char): Cleanup whitespace. (read_logical): Use unget_char to assure that the first character of the bad logical is saved in case it is part of an object name. Remove the clearing of index and flag that is now in free_line. (read_real): Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-03-20 02:08 --- Subject: Bug 35627 Author: jvdelisle Date: Thu Mar 20 02:07:38 2008 New Revision: 133361 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133361 Log: 2008-03-19 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/35627 * gfortran.dg/namelist_46.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_46.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-03-20 02:09 --- Fixed on trunk. Will backport to 4.3 in a day or so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug fortran/35632] [Regression] stream io broken on FreeBSD due to ftruncate changes.
--- Comment #7 from kargl at gcc dot gnu dot org 2008-03-20 03:36 --- With a clean trunk as of 2 minutes ago, this program program streamtest implicit none character(1) :: lf = char(10) character(1) :: tchar integer:: i,j,k integer, parameter :: lines = 5231 open(10, file="teststream", access="stream", form="formatted") do i=1,lines do j=0,9 write(10,"(i5)") j end do if (mod(i,23) == 0) print *, 'i = ', i end do close(10) close(10,status="delete") end program streamtest yields ~/work/bin/gfortran -static -O -o z streamio_4.f90 time ./z 158.72 real 0.46 user 5.90 sys If I revert Jerry's commit, svn merge -r 132512:132511 . I then see ~/work/bin/gfortran -static -O -o z streamio_4.f90 time ./z 0.94 real 0.64 user 0.26 sys 158.72 / 0.94 = 169 Any chance, you'll revert the offending patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35632
Re: Works on dev-c..
beradero wrote: Hello, It's the code: http://www.nabble.com/file/p16128572/1.c 1.c Try enter the number 0010 (number then), 00010, etc.. and see the bizarre output.. Your code is buggy. This is an obvious string overflow problem. You can't fit a 6 character string into a 4 character array. Jim
[Bug debug/35615] Debug information for .debug_loc section incorrect
--- Comment #11 from wilson at tuliptree dot org 2008-03-20 06:56 --- Subject: Re: Debug information for .debug_loc section incorrect deuling at de dot ibm dot com wrote: > --- Comment #6 from deuling at de dot ibm dot com 2008-03-18 16:52 > --- > ./readelf --debug-dump=line give I get a little different output on the executable you attached to the PR, but the same effective result that the filename is missing. The Directory Table is empty. The File Name Table: Entry Dir TimeSizeName 1 0 0 0 Oh, wait, after I pasted it in here I see that I have a non-printing control character which wasn't obvious earlier. Anyways, I don't see this problem when I compile the file myself. The filename is there in the .s file and in the .o file, and in the executable. So there seems to be something wrong with your setup. You could try tracking down exactly where it fails. Look for a ".file 1 tmp.F" directive in the .s file. Look at the readelf --debug-dump=line output for the .o file. We already know that it is missing in the executable. Depending on where it first goes missing, this is either a compiler problem, an assembler problem, or a linker problem. As before, I do not see any compiler or binutils problem here. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
