[Bug c/15685] printf(%s\n) optimized to puts also when parameter might be null
--- Comment #4 from mathias dot hasselmann at gmx dot de 2007-10-01 06:45 --- (In reply to comment #1) Not a bug as printf can segfault if it is supplied a NULL pointer for the string formatter. If glibc does something different than that, glibc is does not have a bug either as it is undefined really so converting the call to a puts is a vaild transformation. Even if its a valid transformation, there is the question if this is a reasonable transformation. Obviously that optimization was introduced because quite alot of people do not know about the puts function and use printf to output static lines of text. On the other hand there are people who rely on glibc's handling of the undefined NULL pointer situation. Question is: Which group is bigger. The missuse printf as puts group or the rely on glibc's relaxed NULL handling group. My guess would be that people who do not even know puts care even less about the fact that ANSI and ISO didn't care about NULL handling in format strings. If that would true, this optimization would be valid, but unreasonable as it breaks the expections of your clients. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15685
[Bug fortran/33554] [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values
--- Comment #11 from pault at gcc dot gnu dot org 2007-10-01 07:01 ---
(In reply to comment #10)
Yes, the initialization is occurring in the wrong place in
gfc_trans_deferred_vars. It looks to be easily fixable. I'll be onto it
tonight.
I figured out how to do it on the way to work. The patch below fixes the
regression and is regtesting (slowly, under Cygwin!).
The trick is to make sure that the block doing the initialization is added to
the top of the function body, so that it follows all the setting of bounds and
offsets.
Paul
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(révision 128833)
--- gcc/fortran/trans-decl.c(copie de travail)
*** gfc_trans_vla_type_sizes (gfc_symbol *sy
*** 2558,2563
--- 2558,2600
}
+ /* Initialize INTENT(OUT) derived type dummies. */
+ static tree
+ init_intent_out_dt (gfc_symbol * proc_sym, tree body)
+ {
+ stmtblock_t fnblock;
+ gfc_init_block (fnblock);
+ gfc_formal_arglist *f;
+ gfc_expr *tmpe;
+ tree tmp;
+ tree present;
+
+ for (f = proc_sym-formal; f; f = f-next)
+ {
+ if (f-sym f-sym-attr.intent == INTENT_OUT
+f-sym-ts.type == BT_DERIVED
+!f-sym-ts.derived-attr.alloc_comp
+f-sym-value)
+ {
+ gcc_assert (!f-sym-attr.allocatable);
+ gfc_set_sym_referenced (f-sym);
+ tmpe = gfc_lval_expr_from_sym (f-sym);
+ tmp = gfc_trans_assignment (tmpe, f-sym-value, false);
+
+ present = gfc_conv_expr_present (f-sym);
+ tmp = build3 (COND_EXPR, TREE_TYPE (tmp), present,
+ tmp, build_empty_stmt ());
+ gfc_add_expr_to_block (fnblock, tmp);
+ gfc_free_expr (tmpe);
+ }
+ }
+
+ gfc_add_expr_to_block (fnblock, body);
+ return gfc_finish_block (fnblock);
+ }
+
+
+
/* Generate function entry and exit code, and add it to the function body.
This includes:
Allocation and initialization of array variables.
*** gfc_trans_deferred_vars (gfc_symbol * pr
*** 2612,2617
--- 2649,2659
proc_sym-ts.type == BT_COMPLEX);
}
+ /* Initialize the INTENT(OUT) derived type dummy arguments. This
+ should be done here so that the offsets and lbounds of arrays
+ are available. */
+ fnbody = init_intent_out_dt (proc_sym, fnbody);
+
for (sym = proc_sym-tlink; sym != proc_sym; sym = sym-tlink)
{
bool sym_has_alloc_comp = (sym-ts.type == BT_DERIVED)
*** gfc_trans_deferred_vars (gfc_symbol * pr
*** 2709,2735
gcc_assert (f-sym-ts.cl-backend_decl != NULL);
if (TREE_CODE (f-sym-ts.cl-backend_decl) == PARM_DECL)
gfc_trans_vla_type_sizes (f-sym, body);
- }
-
- /* If an INTENT(OUT) dummy of derived type has a default
-initializer, it must be initialized here. */
- if (f-sym f-sym-attr.intent == INTENT_OUT
-f-sym-ts.type == BT_DERIVED
-!f-sym-ts.derived-attr.alloc_comp
-f-sym-value)
- {
- gfc_expr *tmpe;
- tree tmp, present;
- gcc_assert (!f-sym-attr.allocatable);
- gfc_set_sym_referenced (f-sym);
- tmpe = gfc_lval_expr_from_sym (f-sym);
- tmp = gfc_trans_assignment (tmpe, f-sym-value, false);
-
- present = gfc_conv_expr_present (f-sym);
- tmp = build3 (COND_EXPR, TREE_TYPE (tmp), present,
- tmp, build_empty_stmt ());
- gfc_add_expr_to_block (body, tmp);
- gfc_free_expr (tmpe);
}
}
--- 2751,2756
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
[Bug c++/33607] New: -O2 optimisation causes null pointer exception at runtime when calling g++ from java using jni
I have experienced a null pointer exception when calling g++ from java (using swig generated bindings). I have made a reduced test case that exhibits the same behaviour which is attached to this report. If I run this on Fedora Core 6 I get: [EMAIL PROTECTED] ~]$ tar -z -x -f java-test.tar.gz [EMAIL PROTECTED] ~]$ cd java-test [EMAIL PROTECTED] java-test]$ ./test.sh Exception in thread main java.lang.NullPointerException at test.mytest.Status.getKind(Status.java:45) at test.main(test.java:9) Running on RHEL 4 works: [EMAIL PROTECTED] ~]$ tar -z -x -f java-test.tar.gz [EMAIL PROTECTED] ~]$ cd java-test [EMAIL PROTECTED] java-test]$ ./test.sh OK If I remove the -O2 optimisation flag from the compilation of the C++ code generated by swig as part of the Java binding it works also on FC6: [EMAIL PROTECTED] java-test]$ OPT=no ./test.sh OK My RHEL 4 installation has g++ 3.4.6-8, my FC6 installation has g++ 4.1.2-13. The same behaviour has been seen using Debian/Etch g++ 4.1.1-21. Since removing the -O2 flag makes the code work I suspect this to be an optimisation problem in g++. Since it works with the -O2 flag with the older g++ in RHEL4 this would be a regression. -- Summary: -O2 optimisation causes null pointer exception at runtime when calling g++ from java using jni Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mattias dot ellert at tsl dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33607
[Bug c++/33607] -O2 optimisation causes null pointer exception at runtime when calling g++ from java using jni
--- Comment #1 from mattias dot ellert at tsl dot uu dot se 2007-10-01 08:41 --- Created an attachment (id=14277) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14277action=view) The test case... This is the test case used above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33607
[Bug c/15685] printf(%s\n) optimized to puts also when parameter might be null
--- Comment #5 from manu at gcc dot gnu dot org 2007-10-01 09:12 --- (In reply to comment #4) Question is: Which group is bigger. The missuse printf as puts group or the rely on glibc's relaxed NULL handling group. My guess would be that people who do not even know puts care even less about the fact that ANSI and ISO didn't care about NULL handling in format strings. If that would true, this optimization would be valid, but unreasonable as it breaks the expections of your clients. The expectations of our clients is to follow standards while producing fastest code possible. Glibc behaviour is inconsistent here. In principle there should be no difference between puts(s) and printf(%s,s) and fprintf(stdout, %s, s). Imagine that the two last ones did something different (I haven't tested, so they actually may) when s == NULL, wouldn't you consider it glibc's fault? Then, why you don't request the same for puts(s)? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15685
[Bug c++/33604] significantly slower results with 4.3 compared to 4.2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-01 09:46 --- With a more recent 4.3 version I get 4.2 4.3 -O2 6.1s 5.1s -O3 4.1s 5.1s both -O3 variants have one function not inlined in the main loop. For 4.2 it is EiEvalEiMatrixProductEiMatrixdouble, 3, 3, EiMatrixdouble, 3, 3 operator*double, EiMatrixdouble, 3, 3, EiMatrixdouble, 3, 3 (EiObjectdouble, EiMatrixdouble, 3, 3 const, EiObjectdouble, EiMatrixdouble, 3, 3 const) for 4.3 it is EiMatrixdouble, 3, 3 EiObjectdouble, EiMatrixdouble, 3, 3 ::operator=EiSumEiMatrixdouble, 3, 3, EiScalarProductEiSumEiMatrixdouble, 3, 3, EiMatrixdouble, 3, 3 (EiObjectdouble, EiSumEiMatrixdouble, 3, 3, EiScalarProductEiSumEiMatrixdouble, 3, 3, EiMatrixdouble, 3, 3 const) but even complete inlining does not improve numbers much. There's also nothing obvious in the asm - we simply have too little registers and load/store from/to memory very often. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug libstdc++/33605] Comparable concepts cause errors with abstract types
--- Comment #2 from pcarlini at suse dot de 2007-10-01 10:06 --- The most recent boost release (1.34.1) of those checks uses the same code of our adaption. Given that, and given of course that we are finally in the era of real concepts in the core language for the forthcoming new standard, I don't think we should change anything non-trivial in this area: in any case a library-only solution will be always affected by serious problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33605
[Bug fortran/21881] ICE instead of error for large arrays in derived types
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-21 19:56:35 |2007-10-01 10:52:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881
[Bug fortran/26682] gfortran fails with -fwhole-program optimization
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-01 10:58 --- There are three different issues: 1. -fwhole-program should be documented as not working for the Fortran programs. 2. The Fortran main program (MAIN__) needs to be kept by the -fwhole-program optimization; I think one way of achieving this is to mark it as externally_visible, but I might be wrong (I've already been wrong on that issue,!). 3. We need to generate a correct call graph for Fortran code, either by emitting one single decl per function, or by making the cgraph calculation aware of this possible situation. I'll try to tackle 1 and 2, but 3 needs to wait until 4.3 is branched. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||documentation Last reconfirmed|2007-07-13 15:47:54 |2007-10-01 10:58:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26682
[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-10-01 11:19 --- (In reply to comment #10) It looks like it is now only a Macintosh PowerPC version problem. It also works Ok on the Intel Macintosh and on the MSYS versions of gfortran. I can confirm that bug on ppc-darwin. It disappears when you change -g into -gdwarf-2, making it a stabs-related issue. This is further proved by running under valgrind on x86_64-linux with -gstabs, where I can see invalid reads, even for the very small testcase: $ cat out.f # 1 outt.F end $ valgrind ./libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 out.f -quiet -gstabs ==501== Memcheck, a memory error detector. ==501== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==501== Using LibVEX rev 1658, a library for dynamic binary translation. ==501== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==501== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==501== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==501== For more details, rerun with: -v ==501== ==501== Invalid read of size 1 ==501==at 0x4A1C7D1: strcmp (mc_replace_strmem.c:341) ==501==by 0x50E1F1: dbxout_source_line (dbxout.c:1231) ==501==by 0x50E5C4: dbxout_begin_prologue (dbxout.c:1258) ==501==by 0x59174F: final_start_function (final.c:1444) ==501==by 0x593EA6: rest_of_handle_final (final.c:4049) ==501==by 0x6516C0: execute_one_pass (passes.c:1116) ==501==by 0x65189F: execute_pass_list (passes.c:1169) ==501==by 0x6518B4: execute_pass_list (passes.c:1170) ==501==by 0x6518B4: execute_pass_list (passes.c:1170) ==501==by 0x72BEC7: tree_rest_of_compilation (tree-optimize.c:404) ==501==by 0x8A1973: cgraph_expand_function (cgraphunit.c:1070) ==501==by 0x8A2C45: cgraph_assemble_pending_functions (cgraphunit.c:431) [... rest of output snipped ...] Now, there are good news: my patch for PR33502 (the updated one, attached to the PR), which reworks the way the front-end treats preprocessor lines and emits debug info, apparently fixes this simple testcase. So, there's a good chance that this PR will be fixed when that patch gets committed. Wait and see! (Or apply the patch and test for yourself, Dale, if you have the resources to do so). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-17 09:33:47 |2007-10-01 11:19:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug bootstrap/33608] New: [4.3 Regression] Bootstrap with ada fails linking gnatbind with 4.3 host compiler
gcc -static-libgcc -o gnatbind ada/b_gnatb.o ada/adaint.o ada/argv.o
ada/exit.o ada/cio.o ada/cstreams.o ada/env.o ada/final.o ada/init.o
ada/initialize.o ada/seh_init.o ada/link.o ada/targext.o ada/raise.o
ada/tracebak.o ada/ada.o ada/a-clrefi.o ada/a-comlin.o ada/a-elchha.o
ada/a-except.o ada/ali-util.o ada/ali.o ada/alloc.o ada/atree.o ada/bcheck.o
ada/binde.o ada/binderr.o ada/bindgen.o ada/bindusg.o ada/butil.o ada/casing.o
ada/csets.o ada/debug.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o
ada/erroutc.o ada/fmap.o ada/fname.o ada/g-hesora.o ada/g-htable.o
ada/s-os_lib.o ada/s-string.o ada/gnat.o ada/gnatbind.o ada/gnatvsn.o
ada/hostparm.o ada/interfac.o ada/lib.o ada/namet.o ada/nlists.o ada/opt.o
ada/osint-b.o ada/osint.o ada/output.o ada/rident.o ada/s-addope.o
ada/s-assert.o ada/s-carun8.o ada/s-casuti.o ada/s-crc32.o ada/s-crtl.o
ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imgenu.o ada/s-mastop.o
ada/s-memory.o ada/s-parame.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o
ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o
ada/s-stoele.o ada/s-strops.o ada/s-traceb.o ada/s-traent.o ada/s-unstyp.o
ada/s-utf_32.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scng.o
ada/scans.o ada/sdefault.o ada/sinfo.o ada/sinput.o ada/sinput-c.o ada/snames.o
ada/stand.o ada/stringt.o ada/switch-b.o ada/switch.o ada/style.o ada/styleg.o
ada/stylesw.o ada/system.o ada/table.o ada/targparm.o ada/tree_io.o ada/types.o
ada/uintp.o ada/uname.o ada/urealp.o ada/widechar.o prefix.o version.o
../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-lmpfr -lgmp
ada/tracebak.o: In function `_Unwind_GetTextRelBase':
/usr/lib/gcc/ia64-suse-linux/4.3.0/include/unwind.h:229: undefined reference to
`fancy_abort'
collect2: ld returned 1 exit status
make[3]: *** [gnatbind] Error 1
make[3]: *** Waiting for unfinished jobs
this is because unwind-generic.h (installed as unwind.h) contains
static inline _Unwind_Ptr
_Unwind_GetTextRelBase (struct _Unwind_Context *_C __attribute__
((__unused__)))
{
abort ();
return 0;
}
and we define abort to fancy_abort and gnatbind does not link against an
object providing that.
--
Summary: [4.3 Regression] Bootstrap with ada fails linking
gnatbind with 4.3 host compiler
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33608
[Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #20 from aldot at gcc dot gnu dot org 2007-10-01 11:55 --- Tripping exactly this while thinking about uclibc on hurd. To me it looks like linux.h shouldn't be included and gnu.h should be made uclibc-aware.. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug fortran/33584] FAIL: gfortran.dg/integer_exponentiation_4.f90 -O (internal compiler error)
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-01 13:05 --- You might also want to build GMP and MPFR with internal checking enabled (--enable-assert, I think). Doesn't this one appear on hpux11? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
[Bug fortran/33595] FAIL: gfortran.dg/nint_2.f90 -O0 execution test
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-10-01 13:13
---
Can you compile and run the following C test code? (gcc -std=c99, or the system
compiler)
#include math.h
#include stdio.h
int main (void)
{
printf (%ld %ld %ld\n, lround (nextafter(0.5,-9.0)), lround (0.5), lround
(nextafter(0.5,9.0)));
}
It should print 0 1 1. If it prints 1 1 1, then your system libm has a bug.
(HP-UX is not alone there, as we already discovered such a problem in AIX and
powerpc-glibc, see PR33271). In that case, you might want to file a bug-report
to HP, and I will xfail the testcase on hppa-hpux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595
[Bug fortran/33341] unnecessary stores for array constructor
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 13:15:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341
[Bug fortran/33609] New: ICE on arithmetic overflow
The following code: print *, real(huge(1.0_8),16) end gives an ICE on gcc version 4.3.0 20071001 (experimental) (GCC): print *, real(huge(1.0_8),16) 1 Error: Arithmetic overflow converting REAL(8) to REAL(16) at (1). This check can be disabled with the option -fno-range-check ice_huge_16.f90:0: internal compiler error: Bus error I see the same on gcc version 4.2.1, but the error is only: Error: Arithmetic overflow converting REAL(8) to REAL(16) at (1) -- Summary: ICE on arithmetic overflow Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
[Bug other/33606] cannot find library
--- Comment #2 from virtualphoton at hotmail dot com 2007-10-01 14:22 --- That's it. I went to gcc IRC and pestered people to help me with it till a guy named 'damjan' caved. Hehe. I just wonder, why can't it be literal? Is there a reason? I'll ask the mailing group. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33606
[Bug c++/32470] [4.2/4.3 regression] fvisibility=hidden without effect in some cases
--- Comment #7 from gd at spherenet dot de 2007-10-01 14:42 ---
Just to be sure I understood everything correctly. Assume the following code:
namespace foo __attribute__((__visibility__(default))) {
...
}
namespace foo {
...
}
The same binding level is used for both namespace definitions, but visibility
is pushed/popped only when entering/leaving the scope of the first definition.
The only purpose of has_visibility is to indicate that visibility was pushed
for the current namespace definition and needs to be popped when leaving. Yes?
Then we have to reset the has_visibility flag (or drop the flag and find
another way to signal that visibility needs to be popped).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32470
[Bug fortran/33609] ICE on arithmetic overflow
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-10-01 14:44 --- What does it do with -fno-range-check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
[Bug c++/33441] [4.2 Regression] FAIL: g++.dg/ext/vla4.C (test for errors, line 10)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-01 15:06 --- Confirmed. Also fails on x86_64, i586 and ia64. So I guess everywhere. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, mark at codesourcery ||dot com GCC build triplet|hppa*-*-* | GCC host triplet|hppa*-*-* | GCC target triplet|hppa*-*-* | Known to fail||4.2.2 Known to work||4.2.1 Summary|FAIL: g++.dg/ext/vla4.C |[4.2 Regression] FAIL: |(test for errors, line 10) |g++.dg/ext/vla4.C (test for ||errors, line 10) Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33441
[Bug c++/33441] [4.2 Regression] FAIL: g++.dg/ext/vla4.C (test for errors, line 10)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-01 15:06 --- Err, confirmed I said. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 15:06:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33441
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-01 15:09 --- I see this as well, on all archs for 4.2.2 (a regression from 4.2.1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug fortran/33609] ICE on arithmetic overflow
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-01 15:13 --- Subject: Re: ICE on arithmetic overflow What does it do with -fno-range-check? compiles and outputs +Infinity -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
[Bug tree-optimization/30565] ICE with -O1 -ftree-pre -ftree-loop-linear
--- Comment #7 from pthaugen at gcc dot gnu dot org 2007-10-01 15:15 --- Subject: Bug 30565 Author: pthaugen Date: Mon Oct 1 15:14:57 2007 New Revision: 128907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128907 Log: 2007-10-01 Pat Haugen [EMAIL PROTECTED] Backport the following patch: 2007-05-03 Zdenek Dvorak [EMAIL PROTECTED] PR tree-optimization/30565 * lambda-code.c (perfect_nestify): Fix updating of dominators. Modified: branches/ibm/gcc-4_1-branch/gcc/ChangeLog branches/ibm/gcc-4_1-branch/gcc/lambda-code.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30565
[Bug c++/33441] [4.2 Regression] FAIL: g++.dg/ext/vla4.C (test for errors, line 10)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-01 15:18 --- r128363 is good, r128394 is bad. Which points to: Author: jason Date: Tue Sep 11 15:20:47 2007 New Revision: 128382 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128382 Log: PR c++/15745 * except.c (prepare_eh_type): Use type_decays_to. * except.c (initialize_handler_parm): Use fold_build_cleanup_point_expr. PR c++/31411 * except.c (initialize_handler_parm): Put a CLEANUP_POINT_EXPR inside the MUST_NOT_THROW_EXPR. Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/except.c and Author: jason Date: Tue Sep 11 15:40:51 2007 New Revision: 128383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128383 Log: PR c++/31419 * call.c (reference_binding): Don't look for user-defined conversions to the same type. Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33441
[Bug fortran/33584] FAIL: gfortran.dg/integer_exponentiation_4.f90 -O (internal compiler error)
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01 15:23 --- Subject: Re: FAIL: gfortran.dg/integer_exponentiation_4.f90 -O (internal compiler error) You might also want to build GMP and MPFR with internal checking enabled (--enable-assert, I think). Doesn't this one appear on hpux11? It doesn't appear on hpux11. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
[Bug c/33610] New: Access to long double struct member from nested procedure crashes
Compile the following program:
#include stdio.h
long double d = 22092007.192016;
struct abc {
long double a, b, c;
};
void outer(void) {
struct abc x;
void inner(struct abc p) {
printf(Enter inner\n);
/* Next line causes problem: bus error, segmentation fault or
result of comparison is false */
if (x.a == d)
printf(OK\n);
else
printf(Fail\n);
}
x.a = d;
inner(x);
}
int main (int argc, const char * argv[]) {
outer();
return 0;
}
Compile
petersch% /Developer/Pascal/gpc421/bin/gcc -v -Wall -save-temps -o schorn3
schorn3.c
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: ../gcc-4.2.1/configure --enable-languages=c
--enable-threads=posix --target=powerpc-apple-darwin8
--host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8
--prefix=/Developer/Pascal/gpc421n
Thread model: posix
gcc version 4.2.1
/Developer/Pascal/gpc421/bin/../libexec/gcc/powerpc-apple-darwin8/4.2.1/cc1 -E
-quiet -v -iprefix
/Developer/Pascal/gpc421/bin/../lib/gcc/powerpc-apple-darwin8/4.2.1/
-D__DYNAMIC__ schorn3.c -fPIC -Wall -fpch-preprocess -o schorn3.i
ignoring nonexistent directory
/Developer/Pascal/gpc421/bin/../lib/gcc/powerpc-apple-darwin8/4.2.1/../../../../powerpc-apple-darwin8/include
ignoring nonexistent directory /Developer/Pascal/gpc421n/include
ignoring nonexistent directory
/Developer/Pascal/gpc421n/lib/gcc/powerpc-apple-darwin8/4.2.1/include
ignoring nonexistent directory
/Developer/Pascal/gpc421n/powerpc-apple-darwin8/include
#include ... search starts here:
#include ... search starts here:
/Developer/Pascal/gpc421/bin/../lib/gcc/powerpc-apple-darwin8/4.2.1/include
/usr/local/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
/Developer/Pascal/gpc421/bin/../libexec/gcc/powerpc-apple-darwin8/4.2.1/cc1
-fpreprocessed schorn3.i -fPIC -quiet -dumpbase schorn3.c -auxbase schorn3
-Wall -version -o schorn3.s
GNU C version 4.2.1 (powerpc-apple-darwin8)
compiled by GNU C version 4.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 08ab063eb304b807ad0f3113ee916e74
as -arch ppc -o schorn3.o schorn3.s
/Developer/Pascal/gpc421/bin/../libexec/gcc/powerpc-apple-darwin8/4.2.1/collect2
-dynamic -arch ppc -weak_reference_mismatches non-weak -o schorn3 -lcrt1.o
/Developer/Pascal/gpc421/bin/../lib/gcc/powerpc-apple-darwin8/4.2.1/crt2.o
-L/Developer/Pascal/gpc421/bin/../lib/gcc/powerpc-apple-darwin8/4.2.1
-L/Developer/Pascal/gpc421/bin/../lib/gcc
-L/Developer/Pascal/gpc421/bin/../lib/gcc/powerpc-apple-darwin8/4.2.1/../../..
schorn3.o -lgcc -lSystemStubs -lSystem
Running it will create a Bus error or might print Fail or terminate with a
segmentation fault depending on the nature of the wrong address of x.a. The
problem disappears when compiling with -fpack-struct=4.
petersch% ./schorn3
Enter inner
Bus error
[petersch%
--
Summary: Access to long double struct member from nested
procedure crashes
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter_schorn at yahoo dot com
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33610
[Bug c/33610] Access to long double struct member from nested procedure crashes
--- Comment #1 from peter_schorn at yahoo dot com 2007-10-01 16:11 --- Created an attachment (id=14278) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14278action=view) Source code of program showing the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33610
[Bug c/33610] Access to long double struct member from nested procedure crashes
--- Comment #2 from peter_schorn at yahoo dot com 2007-10-01 16:12 --- Created an attachment (id=14279) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14279action=view) After pre-processing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33610
[Bug fortran/33609] ICE on arithmetic overflow
--- Comment #3 from kargl at gcc dot gnu dot org 2007-10-01 16:32 --- (In reply to comment #2) Subject: Re: ICE on arithmetic overflow What does it do with -fno-range-check? compiles and outputs +Infinity What does -fdump-tree-original give when you use the -fno-range-check option? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
[Bug fortran/33595] FAIL: gfortran.dg/nint_2.f90 -O0 execution test
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01 16:33 --- Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test It should print 0 1 1. If it prints 1 1 1, then your system libm has a bug. It prints 0 1 1 on hpux11. lround and nextafter aren't available on hpux10. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595
[Bug middle-end/22156] [4.0/4.1/4.2/4.3 Regression] bit-field copying regressed
--- Comment #16 from aoliva at gcc dot gnu dot org 2007-10-01 16:36 --- Subject: Bug 22156 Author: aoliva Date: Mon Oct 1 16:35:55 2007 New Revision: 128908 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128908 Log: PR middle-end/22156 * tree-sra.c (struct sra_elt): Add in_bitfld_block. (sra_hash_tree): Handle BIT_FIELD_REFs. (sra_elt_hash): Don't hash bitfld blocks. (sra_elt_eq): Skip them in parent compares as well. Handle BIT_FIELD_REFs. (build_element_name_1): Handle BIT_FIELD_REFs. (instantiate_element): Propagate nowarn from parents. Create BIT_FIELD_REF for variables that are widened by scalarization. Gimple-zero-initialize all bit-field variables that are not part of parameters that are going to be scalarized on entry. (instantiate_missing_elements_1): Return the sra_elt. (canon_type_for_field): New. (try_instantiate_multiple_fields): New. Infer widest possible access mode from decl or member type, but clip it at word size, and only widen it if a field crosses an alignment boundary. (instantiate_missing_elements): Use them. (generate_one_element_ref): Handle BIT_FIELD_REFs. (scalar_bitfield_p): New. (sra_build_assignment): Optimize assignments from scalarizable BIT_FIELD_REFs. Use BITS_BIG_ENDIAN to determine shift counts. (REPLDUP): New. (sra_build_bf_assignment): New. Optimize assignments to scalarizable BIT_FIELD_REFs. (sra_build_elt_assignment): New. Optimize BIT_FIELD_REF assignments to full variables. (generate_copy_inout): Use the new macros and functions. (generate_element_copy): Likewise. Handle bitfld differences. (generate_element_zero): Don't recurse for blocks. Use sra_build_elt_assignment. (generate_one_element_init): Take elt instead of var. Use sra_build_elt_assignment. (generate_element_init_1): Adjust. (bitfield_overlap_info): New struct. (bitfield_overlaps_p): New. (sra_explode_bitfield_assignment): New. Adjust widened variables to account for endianness. (sra_sync_for_bitfield_assignment): New. (scalarize_use): Re-expand assignment to/from scalarized BIT_FIELD_REFs. Explode or sync needed members for BIT_FIELD_REFs accesses or assignments. Use REPLDUP. (scalarize_copy): Use REPLDUP. (scalarize_ldst): Move assert before dereference. Adjust EH handling. (dump_sra_elt_name): Handle BIT_FIELD_REFs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug fortran/33595] FAIL: gfortran.dg/nint_2.f90 -O0 execution test
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-01 16:39 --- (In reply to comment #2) lround and nextafter aren't available on hpux10. Does hpux10 have round()? And does it have ceil()? (I assume that the last answer is yes, because it's ANSI C, but hpux could surprise me again.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595
[Bug middle-end/22156] [4.0/4.1/4.2/4.3 Regression] bit-field copying regressed
--- Comment #17 from aoliva at gcc dot gnu dot org 2007-10-01 16:46 --- Patch checked in. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug fortran/33609] ICE on arithmetic overflow
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-01 16:48 ---
Subject: Re: ICE on arithmetic overflow
What does -fdump-tree-original give when you use the -fno-range-check
option?
MAIN__ ()
{
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options (7, (void *) options.0);
{
struct __st_parameter_dt dt_parm.1;
dt_parm.1.common.filename = ice_huge_16.f90[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 1;
dt_parm.1.common.flags = 128;
dt_parm.1.common.unit = 6;
_gfortran_st_write (dt_parm.1);
{
static real16 C.536 =
1.79769313486231570814527423731704356798070567526e+308;
_gfortran_transfer_real (dt_parm.1, C.536, 16);
}
_gfortran_st_write_done (dt_parm.1);
}
}
Dominique
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
[Bug c++/33611] New: Optimizations generate incorrect code
The following snipped when compiled with -O0 generates a program that quickly
finishes (correct behavior). But when compiled with any optimizations (-O1, -O2
or -O3) generates a program that never finishes. Variations on the code, (such
as the comment line) geneate valid program with either level of optimization.
Checked in 4.1.1 too (i386) and the bug is there too. Checked in 4.1.2 on
x86_64 and the bug is NOT there.
-- star of file aa.cpp
struct A
{
unsigned int e;
};
A a = {1};
double f[] = {0.0461109, 0.285433};
int main(void)
{
for (bool bEncore = true; bEncore; )
{
bEncore = false;
double p = 0.422244 * f[a.e];
//double p = 0.422244 * f[1];
if (f[0] p)
{
f[0] = p;
bEncore = true;
}
}
return 0;
}
-- end of file aa.cpp
g++ -O3 aa.cpp
./a.out -- goes into infinite loop
--
Summary: Optimizations generate incorrect code
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: macracan at yahoo dot com
GCC build triplet: GNU/linux i386/i686
GCC host triplet: GNU/linux i386/i686
GCC target triplet: GNU/linux i386/i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33611
[Bug c++/33611] Optimizations generate incorrect code
--- Comment #1 from macracan at yahoo dot com 2007-10-01 17:05 --- Created an attachment (id=14280) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14280action=view) source file and the result of 'gcc -v -save-temps -O3 aa.cpp 2stderr' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33611
[Bug middle-end/33611] Optimizations generate incorrect code
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-01 17:10 --- I think you should read http://www.validlab.com/goldberg/paper.pdf . I think what is happening is on x86, there is extra precision so really you are running into bug 323. Can you try to add -ffloat-store? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33611
[Bug middle-end/33611] [4.1/4.2/4.3 regression] Optimizations generate incorrect code
--- Comment #3 from bangerth at dealii dot org 2007-10-01 17:16 --- For once a real floating point bug. In this code double p = 0.422244 * f[a.e]; if (f[0] p) with a.e=1, f[1]=0.285433, we should calculate p=0.285433. Since f[0]=0.0461109, we shouldn't enter the if-clause, but we do when optimization is on. Since the numbers aren't even close, this isn't due to excess precision or any other floating point instability but a real bug. Funny enough, this was already broken in 2.95, 3.2.3 and 3.3.6 but then worked in 3.4.6 and 4.0.x only to be broken again in 4.1.2. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||2.95 3.2.3 3.3.6 4.1.2 Known to work||3.4.6 4.0.4 Last reconfirmed|-00-00 00:00:00 |2007-10-01 17:16:44 date|| Summary|Optimizations generate |[4.1/4.2/4.3 regression] |incorrect code |Optimizations generate ||incorrect code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33611
[Bug fortran/33595] FAIL: gfortran.dg/nint_2.f90 -O0 execution test
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01 17:29 --- Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test Does hpux10 have round()? And does it have ceil()? (I assume that the last answer is yes, because it's ANSI C, but hpux could surprise me again.) It doesn't have round. It has ceil, floor and rint. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595
[Bug middle-end/33611] [4.1/4.2/4.3 regression] Optimizations generate incorrect code
--- Comment #4 from macracan at yahoo dot com 2007-10-01 17:43 --- (In reply to comment #3) For once a real floating point bug. In this code double p = 0.422244 * f[a.e]; if (f[0] p) with a.e=1, f[1]=0.285433, we should calculate p=0.285433. Since f[0]=0.0461109, we shouldn't enter the if-clause, but we do when Sorry, but this isn't quite accurate; the math is off, and the code _should_ enter the if branch the first time around, just not the second time around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33611
[Bug middle-end/33611] [4.1/4.2/4.3 regression] Optimizations generate incorrect code
--- Comment #5 from macracan at yahoo dot com 2007-10-01 17:43 --- *** This bug has been marked as a duplicate of 323 *** -- macracan at yahoo dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33611
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #99 from macracan at yahoo dot com 2007-10-01 17:43 --- *** Bug 33611 has been marked as a duplicate of this bug. *** -- macracan at yahoo dot com changed: What|Removed |Added CC||macracan at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #21 from ams at gnu dot org 2007-10-01 18:04 --- Subject: Re: [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared To me it looks like linux.h shouldn't be included It should be included. and gnu.h should be made uclibc-aware.. This would be nice, would you like to do that? I have far to much to handle right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug libstdc++/33612] New: make check -jN should fully use N cores
See: http://gcc.gnu.org/ml/libstdc++/2007-09/msg00089.html Some of the older cruft (-j1 mandated) has been removed from the libstdc++ Makefiles, but the older problem remains. This is because there is basically one large call to runtest, which then runs on one processor. And I have not found any way to convince runtest to run its test cases in parallel. This could also be categorized as testsuite. -- Summary: make check -jN should fully use N cores Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org GCC build triplet: all GCC host triplet: all GCC target triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33612
[Bug libstdc++/33612] make check -jN should fully use N cores
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33612
[Bug libstdc++/33612] make check -jN should fully use N cores
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-01 18:30 --- This needs dejagnu support (or just forcing the move over to qmtest which I think is a big task). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33612
[Bug c++/33607] -O2 optimisation causes null pointer exception at runtime when calling g++ from java using jni
--- Comment #2 from tromey at gcc dot gnu dot org 2007-10-01 18:32 --- The SWIG code violates strict aliasing rules. Try adding -Wstrict-aliasing and you will see what I mean. If I add -fno-strict-aliasing to the -O2 case, it works. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33607
Re: [Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On 1 Oct 2007 18:04:09 -, ams at gnu dot org [EMAIL PROTECTED] wrote: --- Comment #21 from ams at gnu dot org 2007-10-01 18:04 --- Subject: Re: [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared To me it looks like linux.h shouldn't be included It should be included. Again why? You still have not explained why HURD is Linux? Because as far as I can tell it is not. -- Pinski
[Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-10-01 18:36 --- Subject: Re: [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared On 1 Oct 2007 18:04:09 -, ams at gnu dot org [EMAIL PROTECTED] wrote: --- Comment #21 from ams at gnu dot org 2007-10-01 18:04 --- Subject: Re: [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared To me it looks like linux.h shouldn't be included It should be included. Again why? You still have not explained why HURD is Linux? Because as far as I can tell it is not. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug c++/32125] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #2 from pcarlini at suse dot de 2007-10-01 19:15 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 19:15:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
[Bug c++/32126] [4.3 regression] ICE with invalid definition of variadic template
--- Comment #1 from pcarlini at suse dot de 2007-10-01 19:18 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 19:18:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
[Bug libstdc++/33613] New: compilation inconsistency upper_bound vs lower_bound with -D_GLIBCXX_DEBUG
The following code fails to compile when -D_GLIBCXX_DEBUG is used. If
-D_GLIBCXX_DEBUG is not used, or the upper_bound call is commented out, the
code compiles fine.
// test.cc begin
#include algorithm
struct A {};
struct B {};
bool ab(A, B);
bool ba(B, A);
void test(A* a, B b)
{
std::lower_bound(a,a,b, ab);
std::upper_bound(a,a,b, ba);
}
/// test.cc end
Expected behaviour is that since everything compiles without the define, it
would also compile with the define, and since lower_bound call compiles even
with that, then at least both lower_bound and upper_bound would either both
fail or both compile.
The current behaviour of just upper_bound failing and only with that define is
confusing at best.
Perhaps you could add a check that the iterator sequence iterates elements of
the same type as the third parameter, or if this should not be required, make
that noncompiling case compile too.
$ g++ -v -save-temps -D_GLIBCXX_DEBUG test.cc
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-mpfr
--enable-targets=all --disable-werror --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.1 (Debian 4.2.1-5)
/usr/lib/gcc/i486-linux-gnu/4.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE
-D_GLIBCXX_DEBUG test.cc -mtune=generic -fpch-preprocess -o test.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.2.1/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.2
/usr/include/c++/4.2/i486-linux-gnu
/usr/include/c++/4.2/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.2.1/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.2.1/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cc -mtune=generic -auxbase test -version -o test.s
GNU C++ version 4.2.1 (Debian 4.2.1-5) (i486-linux-gnu)
compiled by GNU C version 4.2.1 (Debian 4.2.1-5).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 96235c4da4910435a4a1e0ded06ae124
/usr/include/c++/4.2/debug/functions.h: In function bool
__gnu_debug::__check_partitioned(_ForwardIterator, _ForwardIterator, const
_Tp, _Pred) [with _ForwardIterator = A*, _Tp = B, _Pred = bool (*)(B, A)]:
/usr/include/c++/4.2/bits/stl_algo.h:3043: instantiated from
_ForwardIterator std::upper_bound(_ForwardIterator, _ForwardIterator, const
_Tp, _Compare) [with _ForwardIterator = A*, _Tp = B, _Compare = bool (*)(B,
A)]
test.cc:9: instantiated from here
/usr/include/c++/4.2/debug/functions.h:285: error: conversion from A to
non-scalar type B requested
/usr/include/c++/4.2/debug/functions.h:287: error: conversion from A to
non-scalar type B requested
Leo Moisio
--
Summary: compilation inconsistency upper_bound vs lower_bound
with -D_GLIBCXX_DEBUG
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: leo dot moisio at gmail dot com
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33613
[Bug libstdc++/33613] compilation inconsistency upper_bound vs lower_bound with -D_GLIBCXX_DEBUG
--- Comment #1 from leo dot moisio at gmail dot com 2007-10-01 19:55 --- Created an attachment (id=14281) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14281action=view) The preprocessed source as created by g++ -v -save-temps -D_GLIBCXX_DEBUG test.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33613
[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
--- Comment #13 from aoliva at gcc dot gnu dot org 2007-10-01 19:55 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00061.html is quite likely to fix this. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572
[Bug fortran/33609] ICE on arithmetic overflow
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-01 20:11 --- This is not target-specific: $ cat u.f90 print *, real(huge(1.0_8),4) end $ gfortran u.f90 u.f90:1.16: print *, real(huge(1.0_8),4) 1 Error: Arithmetic overflow converting REAL(8) to REAL(4) at (1). This check can be disabled with the option -fno-range-check f951: internal compiler error: Segmentation fault Program received signal SIGSEGV, Segmentation fault. gfc_range_check (e=0x0) at ../../../trunk/gcc/fortran/arith.c:524 524 switch (e-ts.type) (gdb) where #0 gfc_range_check (e=0x0) at ../../../trunk/gcc/fortran/arith.c:524 #1 0x00463719 in range_check (result=0x0, name=0xb57e35 REAL) at ../../../trunk/gcc/fortran/simplify.c:73 #2 0x00425e8b in do_simplify (specific=0xed5168, e=0xf58d70) at ../../../trunk/gcc/fortran/intrinsic.c:3179 #3 0x00426d3a in gfc_intrinsic_func_interface (expr=0xf58d70, error_flag=1) at ../../../trunk/gcc/fortran/intrinsic.c:3437 #4 0x004598b0 in gfc_resolve_expr (e=0xf58d70) at ../../../trunk/gcc/fortran/resolve.c:1553 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin8 | GCC host triplet|powerpc-apple-darwin8 | GCC target triplet|powerpc-apple-darwin8 | Keywords||error-recovery, ice-on- ||invalid-code Last reconfirmed|-00-00 00:00:00 |2007-10-01 20:11:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
[Bug bootstrap/33418] [4.1/4.2/4.3]: Gcc failed to detect HJL's binutils linker
--- Comment #5 from hjl at lucon dot org 2007-10-01 20:43 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33418
[Bug other/30530] dfp.c assumes DPD encoding
--- Comment #3 from hjl at lucon dot org 2007-10-01 20:50 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30530
[Bug c++/15745] exception specification incorrectly changes the type of the exception thrown
--- Comment #5 from jason at gcc dot gnu dot org 2007-10-01 20:53 --- Subject: Bug 15745 Author: jason Date: Mon Oct 1 20:53:09 2007 New Revision: 128917 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128917 Log: PR c++/15745 * except.c (prepare_eh_type): Use type_decays_to. Modified: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/vla4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15745
[Bug c++/32562] -Wunused doesn't warn about static function only called by itself.
-- manu at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32562
[Bug c++/33441] [4.2 Regression] FAIL: g++.dg/ext/vla4.C (test for errors, line 10)
--- Comment #4 from jason at gcc dot gnu dot org 2007-10-01 20:54 --- This is not a compiler bug; I forgot to apply the same patch to vla4.C on the branch that I did on the trunk. Fixed now. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33441
[Bug c++/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2
--- Comment #4 from hjl at lucon dot org 2007-10-01 21:04 --- I saw 40% performance regression at -O3 with testcase in comment #1 on Linux/x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
Re: [Bug c++/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2
I'm not fixing this until someone can tell me what exactly is going wrong. There have been *so* many changes to PTA since that revision that the majority of the code it touched doesn't even do the same thing anymore. My guess is that this is a case where adding extra vdefs/vuses made some dumb optimizer able to see something it can't when the chains are separate like they should be. On 1 Oct 2007 21:04:40 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: --- Comment #4 from hjl at lucon dot org 2007-10-01 21:04 --- I saw 40% performance regression at -O3 with testcase in comment #1 on Linux/x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug c++/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-10-01 21:07 --- Subject: Re: [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2 I'm not fixing this until someone can tell me what exactly is going wrong. There have been *so* many changes to PTA since that revision that the majority of the code it touched doesn't even do the same thing anymore. My guess is that this is a case where adding extra vdefs/vuses made some dumb optimizer able to see something it can't when the chains are separate like they should be. On 1 Oct 2007 21:04:40 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: --- Comment #4 from hjl at lucon dot org 2007-10-01 21:04 --- I saw 40% performance regression at -O3 with testcase in comment #1 on Linux/x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug c++/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2
--- Comment #3 from hjl at lucon dot org 2007-10-01 21:03 --- I have verified that revision 119502: http://gcc.gnu.org/ml/gcc-cvs/2006-12/msg00119.html is the cause. -- hjl at lucon dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org GCC build triplet|i486-linux-gnu | GCC host triplet|i486-linux-gnu | GCC target triplet|i486-linux-gnu | Summary|significantly slower results|[4.3 Regression] Revision |with 4.3 compared to 4.2|119502 causes significantly ||slower results with 4.3 ||compared to 4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug libstdc++/33613] compilation inconsistency upper_bound vs lower_bound with -D_GLIBCXX_DEBUG
--- Comment #2 from pcarlini at suse dot de 2007-10-01 21:26 --- Yes. In short, the debug-mode checks must implement the detailed requirements of DR270. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270 In practice, probably we need a dual version of __check_partitioned using __pred(__value, *__first) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 21:26:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33613
[Bug tree-optimization/33614] New: ICE on semi-constant vector CONSTRUCTORs
The following code:
---
typedef float V2SF __attribute__ ((vector_size (8)));
V2SF
foo (int x, V2SF a)
{
while (x--)
a += (V2SF) {1.0f/0.0f - 1.0f/0.0f, 1.0f/0.0f - 1.0f/0.0f};
return a;
}
---
produces an ICE when optimisation is enabled:
---
/tmp/foo.c: In function 'foo':
/tmp/foo.c:9: error: invalid reference prefix
{1.0e+0 / 0.0 + 1.0e+0 / -0.0, 1.0e+0 / 0.0 + 1.0e+0 / -0.0}
/tmp/foo.c:9: error: invalid reference prefix
{1.0e+0 / 0.0 + 1.0e+0 / -0.0, 1.0e+0 / 0.0 + 1.0e+0 / -0.0}
/tmp/foo.c:9: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
---
--
Summary: ICE on semi-constant vector CONSTRUCTORs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
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=33614
[Bug tree-optimization/33614] ICE on semi-constant vector CONSTRUCTORs
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-10-01 21:37 --- I have a patch. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 21:37:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33614
[Bug tree-optimization/33615] New: Hoisting of potentially-throwing values for -fnon-call-exceptions
If the following C++ code is compiled with -fnon-call-exceptions,
the tree optimisers still hoist 1.0 / 0.0:
-
extern volatile int y;
double
foo (double a, int x)
{
while (x--)
{
y++;
a += 1.0 / 0.0;
}
return a;
}
-
Header copying ensures that 1.0 / 0.0 is only executed when the
incoming x is nonzero, but the division happens before the
assignment to y.
At -O, the hoisting is done by LIM; at -O2, it's done be PRE.
--
Summary: Hoisting of potentially-throwing values for -fnon-call-
exceptions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
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=33615
[Bug tree-optimization/33615] Hoisting of potentially-throwing values for -fnon-call-exceptions
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-10-01 21:41 --- I have a patch. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 21:41:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33615
[Bug c++/33616] New: lvalue required as unary '' operand with template pmf
[EMAIL PROTECTED]:/tmp$ cat non-lvalue-pmf.cpp
struct Receive {
};
struct TcpStats {
Receive rx;
};
typedef void (Receive::*StatsGatherer)(void);
template StatsGatherer gatherStats
void test(TcpStats* tcpStats) {
(tcpStats-rx.*gatherStats)();
}
[EMAIL PROTECTED]:/tmp$ g++ -W -Wall -pedantic -g -c -o non-lvalue-pmf.o
non-lv
alue-pmf.cpp
non-lvalue-pmf.cpp: In function ?void test(TcpStats*)?:
non-lvalue-pmf.cpp:12: error: lvalue required as unary '' operand
[EMAIL PROTECTED]:/tmp$
If this is indeed a bug then it's a regression between 3.3.6 (Debian
1:3.3.6-15) and Debian 4.2.1-5:
[EMAIL PROTECTED]:/tmp$ g++-3.3 -W -Wall -pedantic -g -c -o non-lvalue-pmf.o
non-lvalue-pmf.cpp
[EMAIL PROTECTED]:/tmp$
The regression, if that's what it is, was before 4.1.3 20070831 (prerelease)
(Debian 4.1.2-16). The error message was improved between 4.1 and 4.2 but the
same underlying problem is in 4.1.
Various easy and harmless work-arounds are possible, for example, changing the
body of the function to read:
Receive rx = tcpStats-rx;
(rx.*gatherStats)();
I tried to simplify the example further but I've been unable to. One of the
changes that makes the problem go away is to replace the line:
template StatsGatherer gatherStats
With:
StatsGatherer gatherStats;
I don't see why that should affect the lvalue-ness of tcpStats-rx but I've
been wrong about such things many times before and I look forward to being
amazed.
Extra parentheses around (tcpStats-rx) don't help, just to save anyone from
looking up the operator precedence tables (which was the first thing I did).
--
Summary: lvalue required as unary '' operand with template pmf
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mdorey at bluearc 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=33616
[Bug middle-end/33617] New: ICE for nonconstant callee-copied constructor arguments
The following code:
---
typedef float V8SF __attribute__ ((vector_size (32)));
void test0 (V8SF);
void
foo (float x)
{
test ((V8SF) { x, x, x, x, x, x, x, x });
}
---
causes an ICE on targets for which the vector argument is callee-copied:
---
/tmp/foo.c: In function 'foo':
/tmp/foo.c:6: internal compiler error: in copy_constant, at varasm.c:3067
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
---
We try to take the address of the original CONSTRUCTOR (rather than
a temporary as in the caller-copied case) and expand_expr_addr_expr_1
assumes that all constructors are constant.
--
Summary: ICE for nonconstant callee-copied constructor arguments
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC target triplet: mipsisa32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33617
[Bug middle-end/33617] ICE for nonconstant callee-copied constructor arguments
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-10-01 21:43 --- I have a patch. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 21:43:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33617
[Bug libgcj/33618] New: libtool passes invalid option to 2.18 linker
bash# /build/gcc-4.2.1/configure --enable-threads --disable-static --with-arch=i586 --disable-libjava-multilib /bin/sh ./libtool --tag=GCJ --mode=link /root/object/gcc/gcj -B/root/object/i686-pc-linux-gnu/libjava/ -B/root/object/gcc/ -L/root/object/i686-pc-linux-gnu/libjava -ffloat-store -fomit-frame-pointer -g -O2 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /usr/local/lib -shared-libgcc -L/root/object/i686-pc-linux-gnu/libjava/.libs libgcj.la /root/object/gcc/gcj -B/root/object/i686-pc-linux-gnu/libjava/ -B/root/object/gcc/ -ffloat-store -fomit-frame-pointer -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/root/object/i686-pc-linux-gnu/libjava -L/root/object/i686-pc-linux-gnu/libjava/.libs ./.libs/libgcj.so -L/root/object/i686-pc-linux-gnu/libstdc++-v3/src -L/root/object/i686-pc-linux-gnu/libstdc++-v3/src/.libs -lpthread -lrt -ldl -L/root/object/./gcc -L/usr/local//bin -L/usr/local//lib -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.1 -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/lib -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.1/../../.. -lgcc_s -lc -lgcc_s -Wl,--rpath -Wl,/usr/local/lib /usr/local/i686-pc-linux-gnu/bin/ld: unrecognized option '-Wl,-rpath' /usr/local/i686-pc-linux-gnu/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status make[3]: *** [jv-convert] Error 1 make[3]: Leaving directory `/root/object/i686-pc-linux-gnu/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/object/i686-pc-linux-gnu/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/root/object' make: *** [bootstrap] Error 2 -- Summary: libtool passes invalid option to 2.18 linker Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: william dot adams at dot dot state dot fl dot us http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33618
[Bug tree-optimization/33619] New: [4.1/4.2/4.3 Regression] TER breaks some inline-asm code (again)
Related to PR 29877.
Take the following PPC64-linux code (ignore the fact the inline-asm should be
improved a lot via use of clobbers).
static inline int sys_ppu_thread_set_priority(sys_ppu_thread_t thread_id,int
prio)
{
register uint64_t p1 __asm__ (3) = thread_id;
register uint64_t p2 __asm__ (4) = prio;
register uint64_t p3 __asm__ (5); register uint64_t p4 __asm__ (6);
register uint64_t p5 __asm__ (7); register uint64_t p6 __asm__ (8);
register uint64_t p7 __asm__ (9);
register uint64_t p8 __asm__ (10);
register uint64_t n __asm__ (11) = 47;
__asm__ volatile (sc : =r (p1), =r (p2), =r (p3), =r (p4), =r
(p5), =r (p6), =r (p7), =r (p8), =r (n) : r (p1), r (p2), r (p3),
r (p4), r (p5), r (p6), r (p7), r (p8), r (n) : 0, 12, lr,
ctr, xer, cr0, cr1, cr5, cr6, cr7, memory);
return (int)(p1);
}
int32_t P(int32_t priority){return 0;}
struct Thread {
sys_ppu_thread_t tid;
Thread();
void setPriority(int32_t p);
};
void Thread::setPriority(int32_t p)
{
sys_ppu_thread_t a = tid;
sys_ppu_thread_set_priority(a, P(p));
}
CUT
Right now we get in .optimized:
p1 = this-tid;
p2 = (uint64_t) P (p);
Which is wrong as the assignment of p1 happens before the call to P so we
clobber it during the setup of the call.
--
Summary: [4.1/4.2/4.3 Regression] TER breaks some inline-asm code
(again)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: blocker
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33619
[Bug tree-optimization/33619] [4.1/4.2/4.3 Regression] TER breaks some inline-asm code (again)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33619
[Bug c++/33620] New: [4.3 regression] internal compiler error: canonical types differ for identical types const QListQStringList and const QListQStringList
Compiling the attached preprocessed code with gcc 4.3 svn rev. 128893 (regardless of compiler flags) results in project.cpp:2826: internal compiler error: canonical types differ for identical types const QListQStringList and const QListQStringList Please submit a full bug report, See http://gcc.gnu.org/bugs.html for instructions. This breaks building Qt 4.x. -- Summary: [4.3 regression] internal compiler error: canonical types differ for identical types const QListQStringList and const QListQStringList Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org 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=33620
[Bug c++/33620] [4.3 regression] internal compiler error: canonical types differ for identical types const QListQStringList and const QListQStringList
--- Comment #1 from bero at arklinux dot org 2007-10-01 22:14 --- Created an attachment (id=14282) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14282action=view) bzip2-ed preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33620
[Bug c/33621] New: Sysgen Make depend fails in aicasm.c at line 320
Sysgen make depend fails in fuction usage. Message: Internal compiler error Bus Error 10 Please submit a bug report to ... Routine being compiled was not modified from CDROM distribution. Using compiler supplied with the distribution CDROM. -- Summary: Sysgen Make depend fails in aicasm.c at line 320 Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jlevine at boulder dot nist dot gov GCC host triplet: Dell Optiplex 745 GCC target triplet: FreeBSD V6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33621
[Bug middle-end/33621] Sysgen Make depend fails in aicasm.c at line 320
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33621
[Bug tree-optimization/33614] ICE on semi-constant vector CONSTRUCTORs
--- Comment #2 from rsandifo at gcc dot gnu dot org 2007-10-01 23:23 --- ...but the patch was deemed unacceptable. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rsandifo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33614
[Bug libfortran/33469] Default formats for real input are not precise enough
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-01 23:28 --- Hum, the real(16) case looks like loads of fun to come! $ cat k.f90 integer, parameter :: k = 16 character(80) :: buf real(k) :: xk, yk xk = 1.0_k - epsilon(xk) write (buf,'(1PG60.40)') xk read (buf,*) yk write (*,'(1PG60.40)') xk write (*,'(1PG60.40)') yk if (xk /= yk) print *, Mismatch print * xk = 1.0_k + epsilon(xk) write (buf,'(1PG60.40)') xk read (buf,*) yk write (*,'(1PG60.40)') xk write (*,'(1PG60.40)') yk if (xk /= yk) print *, Mismatch print * end $ gfortran k.f90 ./a.out 1.999753481000 4.9303806576313237838233035330174139355000E-32 Mismatch 1.000246519000 1.000246519000 (Also, in the case of real(16), you need to add an E4 to the format anyway.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33469
[Bug libfortran/33469] Default formats for real input are not precise enough
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-10-02 00:37
---
(In reply to comment #5)
Hum, the real(16) case looks like loads of fun to come!
Part of it is simply a libc bug. There are numbers close to 1.0 and -1.0 that
the darwin libc can't output properly:
$ cat k2.c
#include stdio.h
int main (void)
{
long double x;
x = 0.8L;
printf (%Lg\n, x);
printf (%.60Lg\n, x);
x = -0.99975L;
printf (%Lg\n, x);
printf (%.60Lg\n, x);
}
$ gcc k2.c ./a.out
2
1.7999548766360788798414493987417
-2
-1.9997534809671184338108088348233
I've reported this to Apple (it is now bug #5516762). Otherwise, as far as I
can tell, the default format width seems wide enough for real(kind=16).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33469
[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
--- Comment #14 from aoliva at gcc dot gnu dot org 2007-10-02 01:38 --- Subject: Bug 33572 Author: aoliva Date: Tue Oct 2 01:37:59 2007 New Revision: 128939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128939 Log: PR tree-optimization/33572 * tree-cfg.c (verify_stmts): Check for missing PHI defs. * tree-inline.c (update_ssa_across_eh_edges): Renamed to... (update_ssa_across_abnormal_edges): ... this. Set slots in the return PHI node. (copy_edges_for_bb): Handle nonlocal label edges. (make_nonlocal_label_edges): Deleted. (optimize_inline_calls): Don't call it. Modified: branches/var-tracking-assignments-branch/gcc/ChangeLog.vta branches/var-tracking-assignments-branch/gcc/tree-cfg.c branches/var-tracking-assignments-branch/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572
[Bug testsuite/31828] FAIL: gcc.dg/float-range-[3-5].c (test for excess errors)
--- Comment #5 from danglin at gcc dot gnu dot org 2007-10-02 02:18 --- Subject: Bug 31828 Author: danglin Date: Tue Oct 2 02:17:50 2007 New Revision: 128947 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128947 Log: PR testsuite/31828 gcc.dg/float-range-3.c (INFINITY): Define if not defined. (overflow): Use INFINITY, not FP_INFINITE. gcc.dg/float-range-4.c: Likewise. gcc.dg/float-range-5.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/float-range-3.c trunk/gcc/testsuite/gcc.dg/float-range-4.c trunk/gcc/testsuite/gcc.dg/float-range-5.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31828
[Bug testsuite/31828] FAIL: gcc.dg/float-range-[3-5].c (test for excess errors)
--- Comment #6 from danglin at gcc dot gnu dot org 2007-10-02 02:19 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31828
