[Bug other/44983] New: (configure) Using certain chars in --with-pkgversion
I do nothing special with gcc (yet), just build it locallay to have a controlled version. I CM control the cfg and scripts to build it. In doing so I want the build to reflect the version and hence I use the --with-pkgversion option during configure. The problem is that my identifier is an URI which most of the time is fine, however sometimes this URI may use fragments. E.g. it might look like this: eccm://xyz/iv.gcc/main/1.2.3 which is fine, but it might look like this: eccm://xyz/iv.gcc/main/1.2.x/42#keol/m...@40 In the last form, both the hashmark and the 'at' sign causes problems downstream, not too surprisingly. I've toyed with various ways of quoting those characters in order to protect them, but I haven't hit upon a workable method, so I'm supposing that it would need protection in places it is used/passed downstream but I must admit to being a bit intimidated by trying to find/fix this... At present for me, this is minor. However, at a guess this would also affect --with-bugurl, since an URL pointing to a fragment wouldn't be completely impossible. -- Summary: (configure) Using certain chars in --with-pkgversion Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kenneth at olwing dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44983
[Bug middle-end/44984] New: gcc passes unsigned instead of int for printf width/precision (warnings generated)
4.3.5 but 4.5.0 looks about the same, but it has an additional instance:
mber/dpd -I../libdecnumber -I/usr/local/include ../../gcc/gcc/opts.c -o
opts.o
../../gcc/gcc/opts.c: In function `wrap_help':
../../gcc/gcc/opts.c:1037: warning: field width is not type int (arg 3)
../../gcc/gcc/opts.c:1037: warning: field width is not type int (arg 5)
../../gcc/gcc/opts.c: In function `common_handle_option':
../../gcc/gcc/opts.c:1409: warning: field width is not type int (arg 3)
gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissin
jbook2:gcc jay$ diff -uw opts.c.orig opts.c
--- opts.c.orig2010-07-19 00:07:18.0 -0700
+++ opts.c2010-07-19 00:16:27.0 -0700
@@ -1034,7 +1034,10 @@
}
}
- printf( %-*.*s %.*s\n, col_width, item_width, item, len, help);
+ gcc_assert(col_width = INT_MAX);
+ gcc_assert(item_width = INT_MAX);
+ gcc_assert(len = INT_MAX);
+ printf ( %-*.*s %.*s\n, (int)col_width, (int)item_width, item,
(int)len, help);
item_width = 0;
while (help[len] == ' ')
len++;
@@ -1404,9 +1407,12 @@
}
if (i == cl_lang_count)
+ {
+gcc_assert (len = INT_MAX);
fnotice (stderr,
warning: unrecognized argument to --help= switch: %.*s\n,
- len, a);
+ (int)len, a);
+ }
}
if (comma == NULL)
This makes a line go a little over 80 columns, but one of the nearby lines
does already.
(nearby as presented here, not really in the code)
This probably isn't the best fix.
if the output is not important, and someone manages to create huge data,
should still work.
Yes, I'm aware of that huge is 2GB.
Maybe:
int to_reasonable_diagnostic_length(unsigned i)
{
return (i = INT_MAX) ? i : 255;
}
or
int unint_to_int_pin(unsigned i)
{
return (i = INT_MAX) ? i : INT_MAX;
}
and then apply those.
- Jay
--
Summary: gcc passes unsigned instead of int for printf
width/precision (warnings generated)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44984
[Bug middle-end/44985] New: warnings: gcc shifts integer by its entire size
Hm, it seems on some 32bit systems, where there is no -m64, wideint can be a
mere 32bits.
In which case the code should probably say:
hwi = ((hwi (shift - 1)) 1);
This was targeting OpenBSD/x86.
Maybe I should just stick need_64bit_hwint = yes on config.gcc for that and
move along?
Assume there is always long long or __int64?
Coverage of this case is pretty rare now from my skimming.
- Jay
From: jay.kr...@cornell.edu
To: g...@gcc.gnu.org
Subject: suggest assert wide_int larger than hashval_t
Date: Mon, 19 Jul 2010 06:44:33 +
I get this in 4.3.5:
../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
../../gcc/gcc/varasm.c:3387: warning: right shift count = width of type
./include/hashtab.h:typedef unsigned int hashval_t;
unsigned HOST_WIDE_INT hwi;
hashval_t h, *hp;
...
const int shift = sizeof (hashval_t) * CHAR_BIT;
const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
int i;
h ^= (hashval_t) hwi;
for (i = 1; i n; ++i)
{
hwi = shift; here
It looks about the same in 4.5.0 except without const:
int shift = (sizeof (hashval_t) * CHAR_BIT);
Something is amiss here locally, for the types to be the same size.
But maybe add gcc_assert(sizeof(hashval_t) sizeof(HOST_WIDE_INT),
outside the loop? It should be optimized away anyway.
Maybe I'd get -Werror but I use -disable-bootstrap.
Native compiler is gcc, but old.
Thanks,
- Jay
--
Summary: warnings: gcc shifts integer by its entire size
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44985
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #31 from dominiq at lps dot ens dot fr 2010-07-19 07:53 --- (In reply to comment #24) Created an attachment (id=21243) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21243action=view) [edit] Patch v4 This patch (with/without the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt) does not fix the bootstrap failure on x86_64-apple-darwin10.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug tree-optimization/36281] vector code is not parallelized
--- Comment #3 from rob1weld at aol dot com 2010-07-19 08:25 --- ... this does not get parallelized at all ... Also see 34501 Perhaps we could make some use of Pluto. It is a fully automatic (C to OpenMP C) parallelizer that makes code amenable to auto-vectorization. http://pluto-compiler.sourceforge.net/ Also see these Parallelizers: http://cri.ensmp.fr/pips/ or http://pips4u.org/ There was something I found a few days ago from here that I can no longer locate http://en.wikipedia.org/wiki/Automatic_parallelization It would be great to take that inner loop (if it were much larger) and 'Kernelize' it for co-processing on our Graphics Card. We could expand GCCs 'x-parallelize-x' and threading options to automatically find the sweeter spots to offload for co=processing (on a GPU, using OpenCL). Barra - NVIDIA G80 GPU Functional Simulator http://gpgpu.univ-perp.fr/index.php/Barra If we were 'allowed' to call a post-processor (like LTO used to do) we could call ATI's GPU SDK which supports OpenCL and outputs code BOTH to x86 and it's own GPUs. Commercial Projects: Auto-parallelizer and SIMDinator by Dalsoft http://www.dalsoft.com/documentation_simdinator.html NVidia's PTX http://en.wikipedia.org/wiki/Parallel_Thread_Execution Cray's work with LLVM http://llvm.org/devmtg/2009-10/Greene_180k_Cores.pdf Larrabee http://www.drdobbs.com/architecture-and-design/216402188?pgno=5 Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36281
[Bug middle-end/44982] [4.3/4.4/4.5/4.6 Regression] ICE in get_narrower, at tree.c:7832
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-19 09:12 --- Confirmed. ./cc1 -quiet t.c t.c: In function 'main': t.c:5:3: error: void value not ignored as it ought to be t.c:5:3: error: void value not ignored as it ought to be t.c:5:5: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in get_narrower, at tree.c:7832 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||error-recovery, ice-on- ||invalid-code Known to fail||4.0.0 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2010-07-19 09:12:57 date|| Summary|crash on invalid code |[4.3/4.4/4.5/4.6 Regression] |if((a==1) ? (void) (0) : 1) |ICE in get_narrower, at ||tree.c:7832 Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982
[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage
--- Comment #6 from paolo dot carlini at oracle dot com 2010-07-19 09:25 --- Any comment from the ARM maintainers about Mikael' patch? Otherwise, I mean to apply it and close the PR pretty soon... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
[Bug c++/44969] [C++0x] type_traits std::is_constructible broken for fundamental types.
--- Comment #8 from paolo dot carlini at oracle dot com 2010-07-19 09:38 --- OK, I'm committing my bits and leaving the PR open for you to investigate the second issue (PS: I noticed an ICE on invalid while quickly hacking the testcase, if I figure out isn't a duplicate I'll file a separate PR asap) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage
--- Comment #7 from mikpe at it dot uu dot se 2010-07-19 09:48 --- I had planned to include this patch in my native ARM bootstrap+regtest of the next 4.6 weekly snapshot (4.6-20100717) and then submit it properly, but with the bootstrap-breaking r162270 mess it slipped my mind. If people are Ok with it w/o native testing, I'll gladly submit it right now or have someone else apply it directly under the obvious rule. Otherwise I'll do an incremental re-build and libstd++-only test run with it once my current test cycle completes, and then submit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
[Bug rtl-optimization/44941] [4.6 Regression] ICE: RTL check: expected code 'mem', have 'reg' in emit_block_move_hints, at expr.c:1189
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-19 09:51 --- #3 0x0060425e in store_one_arg (arg=0x7fffbc10, argblock=0x77ee0540, flags=0, variable_size=0, reg_parm_stack_space=0) at /space/rguenther/src/svn/trunk/gcc/calls.c:4309 4309 emit_push_insn (arg-value, arg-mode, TREE_TYPE (pval), size_rtx, (gdb) call debug_rtx (arg-value) (reg:SI 61) (gdb) p arg-mode $2 = BLKmode (gdb) call debug_rtx (size_rtx) (const_int 0 [0]) (gdb) call debug_tree (arg-tree_value) mem_ref 0x77ff90a8 type record_type 0x75ae02a0 S type_0 BLK size integer_cst 0x77ed2b18 constant 0 unit size integer_cst 0x77ed2410 constant 0 align 8 symtab 0 alias set -1 canonical type 0x75ae02a0 context translation_unit_decl 0x77efb958 D.1621 pointer_to_this pointer_type 0x75ae0498 chain type_decl 0x77efb8a0 D.1615 arg 0 addr_expr 0x75b43030 type pointer_type 0x77ef6540 type integer_type 0x77ee7498 int unsigned DI size integer_cst 0x77ed27a8 constant 64 unit size integer_cst 0x77ed27d0 constant 8 align 64 symtab 0 alias set -1 canonical type 0x77ef6540 arg 0 parm_decl 0x77edb908 i type integer_type 0x77ee7498 int used SI file pr44941.c line 5 col 15 size integer_cst 0x77ed26e0 constant 32 unit size integer_cst 0x77ed23e8 constant 4 align 32 context function_decl 0x75afb100 foo (reg/v:SI 58 [ i ]) arg-type integer_type 0x77ee7498 int incoming-rtl (reg:SI 5 di [ i ]) pr44941.c:7:21 arg 1 integer_cst 0x75adc668 type pointer_type 0x75ae0498 constant 0 pr44941.c:7:7 I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44941
[Bug middle-end/44982] [4.3/4.4/4.5/4.6 Regression] ICE in get_narrower, at tree.c:7832
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-19 09:58 --- Should be easy, this one. I like easy. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-19 09:12:57 |2010-07-19 09:58:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982
[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage
--- Comment #8 from paolo dot carlini at oracle dot com 2010-07-19 10:15 --- If you can svn update to a revision pre-breakage and natively test there it would be great. But really, I just compared unwind-cxx.h to the actual definitions in eh_arm.cc and the patch seems pretty straightforward to me, I think we can safely go ahead for mainline. And well, if something is really wrong we have plenty of time to correct ourselves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #12 from victor dot pasko at gmail dot com 2010-07-19 10:25
---
Isn't really difficult to fix that in libgfortran sources by using:
if(pthread_cancel)
{
pthread_cancel(...);
}
instead of just
pthread_cancel(...);
as it is now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug c++/44969] [C++0x] type_traits std::is_constructible broken for fundamental types.
--- Comment #9 from paolo at gcc dot gnu dot org 2010-07-19 10:28 --- Subject: Bug 44969 Author: paolo Date: Mon Jul 19 10:27:58 2010 New Revision: 162303 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162303 Log: /cp 2010-07-19 Paolo Carlini paolo.carl...@oracle.com PR c++/44969 * typeck.c (build_x_compound_expr_from_list): Add tsubst_flags_t parameter. * cp-tree.h: Adjust declaration. * init.c (perform_member_init): Adjust caller. * decl.c (grok_reference_init, cp_finish_decl): Likewise. * typeck2.c (store_init_value): Likewise. (build_functional_cast): Pass complain argument to build_x_compound_expr_from_list. /testsuite 2010-07-19 Paolo Carlini paolo.carl...@oracle.com PR c++/44969 * g++.dg/template/sfinae23.C: New. Added: trunk/gcc/testsuite/g++.dg/template/sfinae23.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/cp/typeck.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
[Bug rtl-optimization/44973] SH: libjava failed to build with 'flow control insn inside a basic block'
--- Comment #4 from ro at gcc dot gnu dot org 2010-07-19 11:15 --- libada failed to build with the same error in i386-pc-solaris2.10. You patch patch fixed that as well. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44973
[Bug rtl-optimization/44973] SH: libjava failed to build with 'flow control insn inside a basic block'
--- Comment #5 from bernds at gcc dot gnu dot org 2010-07-19 11:27 --- Fixed now. -- bernds at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44973
[Bug driver/44986] New: -fuse-linker-plugin -save-temps gives resolution file base name of last argument
More an cosmetic issue: when -fuse-linker-plugin -save-temps is used for a LTO code generation link the resolution file passes to the linker is always the last argument on the command line. This means if it's an option (in my case -Wl,--end-group) you end up with --end-group.res, which is rather ugly. Should probably use the base name of the -o output argument instead. -- Summary: -fuse-linker-plugin -save-temps gives resolution file base name of last argument Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44986
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #28 from dberlin at gcc dot gnu dot org 2010-07-19 12:00 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 On Thu, Jul 15, 2010 at 7:04 PM, LpSolit at netscape dot net gcc-bugzi...@gcc.gnu.org wrote: --- Comment #27 from LpSolit at netscape dot net 2010-07-15 23:04 --- For those who are interested, I'm on vacation till mid-August, meaning that I have some free time to help upgrading GCC Bugzilla to 3.6.1. As it's not acceptable to play with a production installation, we would need a test installation on which we can apply patches and test them (we could file bugs and attach patches to the test installation directly, so that we can test the installation for real). That's fine. I used to do this on my local machine (home.dberlin.org). You could also setup a test instance on sourceware.org (which is what gcc.gnu.org is really running on) Once everybody is happy with how things work, and thinks everything which is needed has been ported to the new installation, we can make a monolithic patch with all changes in it, and attach it to this bug for the record (as the test installation will probably go away once the upgrade process is complete). Sounds right The only efficient way I know to customize a Bugzilla installation is to use e.g. CVS or bzr to apply patches, and let the test installation be upgraded from there, so that we can easily generate patches and back them out. Else it's going to be a mess pretty quickly. Is this doable by the GCC team? Currently bugzilla is under cvs, but it's a bit of a mess (my fault, of course ;P). The rest of GCC uses SVN, the www stuff has never been moved over because there are a bunch of automated checkin scripts/etc that nobody has had the urge to port. Else I would have to do it locally, and apply patches manually to the test installation, meaning that I would be the only one able to generate patches on top of other patches. What do you think? I think you should probably set yourself up an account on sourceware. Fill out this form: http://sourceware.org/cgi-bin/pdw/ps_form.cgi and list me as your referrer. The bugzilla stuff for GCC is in /www/gcc/bugzilla I honestly do not remember the qmail related magic that makes the incoming aliases go to the right perl scripts. However, overseers@ has the folks who set this up and understand how qmail works. --Dan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug fortran/44353] rejects legal fortran
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-19 12:07 --- Revert was due to: http://gcc.gnu.org/ml/fortran/2010-07/msg00248.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353
[Bug target/44987] New: *mmintrin.h files incompatible with partial __attribute__((target(sse...)))
The *mmintr.h files have checks like #ifndef __SSE4_2__ # error SSE4.2 instruction set not enabled #else Problem with this is that it assumes that the whole file is compiled with -msse4.2 or similar option. But with __attribute__((target(...))) it's possible and appropiate to let only part of the code use e.g. -msse4.2 and compile the rest of the file with different options. The problem is just that *mmintrin.h cannot be used then because __SSE4_2__ or similar is not set by the target attribute. One workaround I found was to specify all the defines manually before including the intrin.h header. But that's rather ugly because it needs 7 different defines or so. I think it would be better to drop these #ifdefs from the headers and check the code generation settings for the current function in the intrinsics instead. -- Summary: *mmintrin.h files incompatible with partial __attribute__((target(sse...))) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44987
[Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-19 12:47 --- Well, the list of problems is endless it seems - we are not consistent in how we build accesses for declD.1.u1.a.align = 13; vs. decl$u1$a$align_5 = BIT_FIELD_REF MEM[(unnamed-unsigned:24 *)declD.2], 24, 0; (the former is a COMPONENT_REF with DECL_BIT_FIELD while the latter is a BIT_FIELD_REF. The first access will be [0, 24] while the later [0, 32]. This causes us to scalarize declD.2 = declD.1; as declD.2 = declD.2; because we cannot find a matching access in load_assign_lhs_subreplacements and drop into the strange code for SRA_UDH_LEFT. So eventually we should not drop bit-field-ref kind outer accesses in favor of handling them as partial_ref or we should do the same for DECL_BIT_FIELD component-refs. I'm a bit lost and will attach the current WIP patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
[Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-19 12:49 --- Created an attachment (id=21249) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21249action=view) wip patch Testcase that shows this behavior is gcc.dg/tree-ssa/vrp14.c which is miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
[Bug target/25722] Stackpointer is not restored correct at end of function
--- Comment #3 from anitha dot boyapati at atmel dot com 2010-07-19 12:56 --- When I tried with AVR Studio 4.18, Build 684, the program didn't crash. I think the issue is not with compiler. Disassembly looks proper and call to Evaluate() is returned. This can be verified by using breakpoints in assembly statements. 119: Evaluate(); +023E: 940E0056CALL 0x0056 Call subroutine +0240: CFFFRJMP PC-0x Relative jump However when I tried to put breakpoint for 'while' statement, it did not work out as the corresponding source line couldn't be found in the program memory. This differs from the expected behavior. -- anitha dot boyapati at atmel dot com changed: What|Removed |Added CC||anitha dot boyapati at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25722
[Bug target/25722] Stackpointer is not restored correct at end of function
--- Comment #4 from anitha dot boyapati at atmel dot com 2010-07-19 13:03 --- SSA pass pass_remove_useless_stmts() removes useless statements and any code beyond statements like while(1); will not be generated. This might be why the breakpoint at while(TRUE); in the testcase is not recognised [and hence the simulation looks like hanged/or not returned from evaluate() ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25722
[Bug target/44987] *mmintrin.h files incompatible with partial __attribute__((target(sse...)))
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-19 13:03 --- Confirmed. -- 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 |2010-07-19 13:03:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44987
[Bug driver/44986] -fuse-linker-plugin -save-temps gives resolution file base name of last argument
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-19 13:11 --- Confirmed. -plugin-opt=-fresolution=%u.res is supposed to use a nice name as base with -save-temps (but appearantly it's choice isn't very good). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||lto Last reconfirmed|-00-00 00:00:00 |2010-07-19 13:11:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44986
[Bug fortran/44953] FAIL: gfortran.dg/char4_iunit_1.f03 * execution test
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-07-19 13:12 --- Subject: Bug 44953 Author: jvdelisle Date: Mon Jul 19 13:11:54 2010 New Revision: 162304 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162304 Log: 2010-07-19 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/44953 * io/unix.c (mem_alloc_w4): Return gfc_char4_t instead of char type pointer. (mem_write4): Remove cast to gfc_char4_t. * io/transfer.c (write_block): Use a gfc_char4_t pointer. (memset4): New helper function. (next_record_w): Use new helper function rather than sset for internal units. Don't attempt to pad with spaces if it is not needed. * io/unix.h: Update prototype for mem_alloc_w4. * io/write.c (memset4): Use gfc_char4_t pointer and chracter type. Don't use multiply by 4 to compute offset. (memcpy4): Likewise. (write_default_char4): Use a gfc_char4_t pointer and update memset4 and memcpy calls. (write_a): Likewise. (write_l): Likewise. (write_boz): Likewise. (write_decimal): Likewise. (write_x): Likewise. (write_char): Add support for character(kind=4) internal units that was previously missed. (write_integer): Use a gfc_char4_t pointer and update memset4 and memcpy calls. (write_character): Likewise. (write_separator): Add support for character(kind=4) internal units that was previously missed. * write_float.def (output_float): Use a gfc_char4_t pointer and update memset4 and memcpy calls. (write_infnan): Likewise. (output_float_FMT_G_): Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/unix.h trunk/libgfortran/io/write.c trunk/libgfortran/io/write_float.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44953
[Bug rtl-optimization/44979] [4.6 regression] Revision 162270 failed many x86-64 tests
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-19 13:19 --- According to http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01409.html this is an x86 backend bug. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44979
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2010-07-19 13:25 --- On x86_64-apple-darwin10, the bootstrap failure at r162303 is exhibited as a miscompiled build/genattrtab... /Users/howarth/darwin_objdir/./prev-gcc/xgcc -B/Users/howarth/darwin_objdir/./prev-gcc/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/bin/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/bin/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/lib/ -isystem /Users/howarth/dist/x86_64-apple-darwin10.4.0/include -isystem /Users/howarth/dist/x86_64-apple-darwin10.4.0/sys-include -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc \ build/gcov-iov.o -o build/gcov-iov build/gcov-iov '4.6.0' 'experimental' \ tmp-gcov-iov.h /bin/sh ../../gcc/gcc/../move-if-change tmp-gcov-iov.h gcov-iov.h /bin/sh: line 1: 30108 Illegal instruction build/genattrtab ../../gcc/gcc/config/i386/i386.md insn-conditions.md tmp-attrtab.c gdb ./build/genattrtab (gdb) r ../../gcc/gcc/config/i386/i386.md insn-conditions.md tmp-attrtab.c Starting program: /Users/howarth/darwin_objdir/gcc/build/genattrtab ../../gcc/gcc/config/i386/i386.md insn-conditions.md tmp-attrtab.c Reading symbols for shared libraries +. done Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x000125f7 in attr_rtx () (gdb) bt #0 0x000125f7 in attr_rtx () #1 0x00014a8c in check_attr_test () #2 0x0001482b in check_attr_test () #3 0x0001483e in check_attr_test () #4 0x00014edd in check_attr_value () #5 0x00018985 in main () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug target/44987] *mmintrin.h files incompatible with partial __attribute__((target(sse...)))
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-19 13:27 --- The design of target attribute is incomplete and its implementation is broken. See PR 37565. I'd like to see a new design/implementation. We should deal with all issues, including header files, in the new design/implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44987
[Bug rtl-optimization/44988] New: [4.6 Regression] ICE: in make_decl_rtl, at varasm.c:1346 at -O1
Command line: $ gcc -O testcase.c Compiler output: $ gcc -O testcase.c testcase.c: In function 'foo': testcase.c:12:22: internal compiler error: in make_decl_rtl, at varasm.c:1344 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r16 - crash r161659 - crash r161170 - OK -- Summary: [4.6 Regression] ICE: in make_decl_rtl, at varasm.c:1346 at -O1 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44988
[Bug rtl-optimization/44988] [4.6 Regression] ICE: in make_decl_rtl, at varasm.c:1346 at -O1
--- Comment #1 from zsojka at seznam dot cz 2010-07-19 13:33 --- Created an attachment (id=21250) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21250action=view) reduced testcase (from iptraf sources) Similiar to PR44941 testcase and reduced from the same file, this one doesn't use empty structs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44988
[Bug rtl-optimization/44941] [4.6 Regression] ICE: RTL check: expected code 'mem', have 'reg' in emit_block_move_hints, at expr.c:1189
--- Comment #5 from zsojka at seznam dot cz 2010-07-19 13:35 --- Thank you for fixing this. It seems the original ICE (in make_decl_rtl, at varasm.c:1346) is different, so I opened it as PR44988. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44941
[Bug fortran/44353] rejects legal fortran
--- Comment #6 from hjl at gcc dot gnu dot org 2010-07-19 13:35 --- Subject: Bug 44353 Author: hjl Date: Mon Jul 19 13:35:19 2010 New Revision: 162305 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162305 Log: Remove gfortran.dg/data_implied_do_2.f90. 2010-07-19 H.J. Lu hongjiu...@intel.com PR fortran/44353 * gfortran.dg/data_implied_do_2.f90: Removed. Removed: trunk/gcc/testsuite/gfortran.dg/data_implied_do_2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353
[Bug debug/44971] [4.6 Regression] -fcompare-debug failure with uninitialized read in walk_gimple_stmt
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-19 13:40 ---
The difference starts to appear with .030t.ealias, where with debug info
we get a massive re-ordering of immediate uses (diff from .029t.forwprop1):
prev_1 : --2 uses.
-D.2738_7 = *prev_1;
info_6 = *prev_1;
# DEBUG prev = prev_1
+D.2738_7 = *prev_1;
dpy_2(D) : -- no uses.
# DEBUG D#1 = (long int) dpy_2(D)
info_6 : -- single use.
-if (info_6 != 0B)
# DEBUG info = info_6
+if (info_6 != 0B)
D.2738_7 : -- single use.
prev_8 = D.2738_7-next;
prev_8 : -- single use.
-prev_1 = PHI _XftintInfo(2), prev_8(3)
# DEBUG prev = prev_8
+prev_1 = PHI _XftintInfo(2), prev_8(3)
.MEM_9(D) : --2 uses.
# VUSE .MEM_9(D)
-D.2738_7 = *prev_1;
-# VUSE .MEM_9(D)
info_6 = *prev_1;
+# VUSE .MEM_9(D)
+D.2738_7 = *prev_1;
Caused by the additional
+No longer having address taken event_base
+
+
+Symbols to be put in SSA form
+
+{ event_base }
+
+
+Incremental SSA update started at block: 0
+
in the debug enabled build (TODO_update_address_taken). Still
in referenced-vars but only for the debug-enabled build
(it is in fact never added for the -g0 build, added by
remap_decl called from remap_block during inlining).
I may have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44971
[Bug middle-end/44989] New: [4.6 regression] g++.dg/guality/redeclaration1.C
On Linux/x86, revision 162274 gave: FAIL: g++.dg/guality/redeclaration1.C -O2 -flto line 16 i == 24 FAIL: g++.dg/guality/redeclaration1.C -O2 -fwhopr line 16 i == 24 Revision 162258 is OK. -- Summary: [4.6 regression] g++.dg/guality/redeclaration1.C Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44989
[Bug middle-end/44989] [4.6 regression] g++.dg/guality/redeclaration1.C
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-19 13:42 --- Revision 162269 is bad and revision 162264 is good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44989
[Bug rtl-optimization/44979] [4.6 regression] Revision 162270 failed many x86-64 tests
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-07-19 13:43 --- The proposed patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01409.html shifts the bootstrap failure on x86_64-apple-darwin10 to... libtool: compile: /Users/howarth/darwin_objdir/./gcc/xgcc -B/Users/howarth/darwin_objdir/./gcc/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/bin/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/lib/ -isystem /Users/howarth/dist/x86_64-apple-darwin10.4.0/include -isystem /Users/howarth/dist/x86_64-apple-darwin10.4.0/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgomp -I../../../gcc/libgomp/config/bsd -I../../../gcc/libgomp/config/posix -I../../../gcc/libgomp -Wall -pthread -Werror -g -O2 -MT barrier.lo -MD -MP -MF .deps/barrier.Tpo -c ../../../gcc/libgomp/barrier.c -o barrier.o /dev/null 21 ../../../gcc/libgomp/error.c: In function gomp_error: ../../../gcc/libgomp/error.c:54:1: error: unrecognizable insn: (insn 32 31 11 2 ../../../gcc/libgomp/error.c:48 (parallel [ (set (mem/c:BLK (plus:DI (reg/f:DI 6 bp) (const_int -128 [0xff80])) [0 A64]) (unspec:BLK [ (reg:DI 21 xmm0) (reg:DI 22 xmm1) (reg:DI 23 xmm2) (reg:DI 24 xmm3) (reg:DI 25 xmm4) (reg:DI 26 xmm5) (reg:DI 27 xmm6) (reg:DI 28 xmm7) ] UNSPEC_SSE_PROLOGUE_SAVE_LOW)) (use (reg:DI 0 ax [58])) (use (const_int 0 [0])) (use (label_ref:DI 0)) (use (const_int 4 [0x4])) ]) -1 (nil)) ../../../gcc/libgomp/error.c:54:1: internal compiler error: in extract_insn, at recog.c:2127 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [error.lo] Error 1 make[5]: *** Waiting for unfinished jobs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44979
[Bug target/25722] Stackpointer is not restored correct at end of function
--- Comment #5 from eric dot weddington at atmel dot com 2010-07-19 13:43 --- Closing as WORKSFORME based on comments #3, #4. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25722
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
-- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-11 11:25:40 |2010-07-19 13:45:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug fortran/43851] Add _gfortran_error_stop_numeric
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-19 13:47 --- (In reply to comment #9) There is one last improvement we can do here. Currently we are using gfc_match_init_expr. This works fine, but the error messages are worded toward initialization expressions and not stop codes. We could generalize the messages in gfc_match_init_expr or come up with a way to either signal a different message for a stop code or create a new function such as gfc_match_stopcode_expr. Is this needed? The standard essentially says that is an initialization expression is required for STOP. (To be more precises: Fortran 2003's term initialization expression has been changed to constant expression in F2008 and STOP takes constant expressions as argument.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
[Bug middle-end/44989] [4.6 regression] g++.dg/guality/redeclaration1.C
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44989
[Bug target/43698] [4.5/4.6 Regression] Wrong use of ARMv6 REV instruction for endian bytewapping with -Os or -O2 optimizations
--- Comment #12 from siarhei dot siamashka at gmail dot com 2010-07-19 13:54 --- Updated the summary to better describe the problem (which is distro independent). The fact that this bug breaks pax-utils tool, which is a vital part of gentoo packaging system, thus rendering the system unusable is probably not so interesting in gcc bugzilla context :) -- siarhei dot siamashka at gmail dot com changed: What|Removed |Added Summary|[4.5/4.6 Regression] Invalid|[4.5/4.6 Regression] Wrong |code when building gentoo |use of ARMv6 REV instruction |pax-utils-0.1.19 with -Os |for endian bytewapping with |optimizations |-Os or -O2 optimizations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #33 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-19 14:31 --- Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap This patch (with/without the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt) does not fix the bootstrap failure on x86_64-apple-darwin10.4. Same on hppa64-hp-hpux11.11. With the rc-fix4.diff and entrymode.diff patches, we still fail compiling libgcc in stage2, although at a slightly different spot: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/g cc-4.6.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11 /lib/ -isystem /opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/include -isystem /op t/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/sys-include-g -O2 -O2 -g -O2 -DIN _GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-protot ypes -Wold-style-definition -isystem ./include -fPIC -Dpa64=1 -DELF=1 -mlong-c alls -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I.. /.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/.. /gcc -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o __gcc_bcmp. o -MT __gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c ../../../gcc/libg cc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__gcc_bcmp': ../../../gcc/libgcc/../gcc/libgcc2.c:1979:1: internal compiler error: Segmentati Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug tree-optimization/44988] [4.6 Regression] ICE: in make_decl_rtl, at varasm.c:1346 at -O1
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-19 14:43 ---
Ick. The problem is that with MEM_REF we now have local variables that
are is_gimple_reg () but not in SSA form.
void
foo (void)
{
int i = 0;
bar (*(struct S *) i);
}
is undefined and thus we remove the initializer and expand from
foo ()
{
int i;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
bar (MEM[(struct S *)i]);
return;
# SUCC: EXIT [100.0%]
}
where when processing the remaining local decls we stop processing 'i' at
/* Expanded above already. */
if (is_gimple_reg (var))
{
TREE_USED (var) = 0;
goto next;
}
the issue is probably latent on the 4.5 branch if we manage to end up with
bar (VIEW_CONVERT struct S(i));
instead.
We could rewrite i into SSA form but would have troubles with even more
undefined code which would require a VIEW_CONVERT_EXPR to a different
sized object (which we now reject during gimple validation - the
view-converted use is the reason we don't rewrite it in the first place).
Another long-standing idea was to extend the use of DECL_GIMPLE_REG_P
to all variables (including those that are always registers). That
enables a check for whether a variable is in SSA form.
OTOH update-address-taken is to properly honor this and it does, it
is just missing handling of call arguments. I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Component|rtl-optimization|tree-optimization
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-07-19 14:43:24
date||
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44988
[Bug c++/44969] [C++0x] type_traits std::is_constructible broken for fundamental types.
--- Comment #10 from jason at gcc dot gnu dot org 2010-07-19 14:51 --- Subject: Bug 44969 Author: jason Date: Mon Jul 19 14:50:52 2010 New Revision: 162307 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162307 Log: PR c++/44969 * tree.c (cp_tree_equal): Compare type of *CAST_EXPR. * pt.c (iterative_hash_template_arg): Hash type of *CAST_EXPR. Added: trunk/gcc/testsuite/g++.dg/template/sfinae24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
[Bug c++/44990] New: Wrong return value on error
When used with -V option, g++ return status is 0 even when the input file fails
to compile.
Example :
Program :
=
int mult(int a, int b)
{
dsss;
int y = a * b;
return y;
}
Command :
g++ -V 4.4.3 -c -Wall -pipe --no-exceptions -fPIC -ggdb mult.cc -o mult.o
mult.cc: In function int mult(int, int):
mult.cc:5: error: dsss was not declared in this scope
sf6:/home/parvizf/tmp/make_test echo $?
0
Note the return value of 0.
If compiled without the -V, the return value is 1
--
Summary: Wrong return value on error
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: parviz_fariborz at mentor dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44990
[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64
--- Comment #7 from burnus at gcc dot gnu dot org 2010-07-19 15:05 --- (In reply to comment #6) (In reply to comment #5) Is this now fixed on trunk? We had to deal with the TBAA problem with the arrival of mem-ref2. Seems to be fixed according to the result for 4.6.0 20100716 (experimental) [trunk revision 162264] (GCC) testsuite on ia64-unknown-linux-gnu Cf. http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg01612.html which has as only failures: maxlocval_3.f90 (excess errors) and typebound_proc_15.f03 (ICE, PR 44584). H.J and Jim: Can we close this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
[Bug c++/44991] New: default argument with '' cause compilation error
class bar {
void foo(bool a = 3 2, bool b = true) {}
};
$ g++ -c ./main.cpp
./main.cpp:2:39: error: redefinition of 'bool b'
./main.cpp:2:39: error: 'bool b' previously declared here
(This happends only if the funciton is a member function)
--
Summary: default argument with '' cause compilation error
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ogoffart at kde dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44991
[Bug c++/44990] Wrong return value on error
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-19 15:35 --- As noted at http://gcc.gnu.org/gcc-4.6/changes.html the -V option has been removed in the current development version, so this is unlikely to be fixed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44990
[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64
--- Comment #8 from hjl dot tools at gmail dot com 2010-07-19 15:38 --- It disappeared at least since revision 161672. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
[Bug c++/44991] [4.4/4.5/4.6 Regression] default argument with '' cause compilation error
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-19 15:38 --- confirmed, this worked with gcc 4.1 -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2010-07-19 15:38:28 date|| Summary|default argument with '' |[4.4/4.5/4.6 Regression] |cause compilation error |default argument with '' ||cause compilation error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44991
[Bug rtl-optimization/44941] [4.6 Regression] ICE: RTL check: expected code 'mem', have 'reg' in emit_block_move_hints, at expr.c:1189
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-19 15:40 --- Subject: Bug 44941 Author: rguenth Date: Mon Jul 19 15:39:51 2010 New Revision: 162308 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162308 Log: 2010-07-19 Richard Guenther rguent...@suse.de PR middle-end/44941 * expr.c (emit_block_move_hints): Move zero size check first. Move asserts to more useful places. * calls.c (load_register_parameters): Check for zero size. * gcc.c-torture/compile/pr44941.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr44941.c Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44941
[Bug rtl-optimization/44941] [4.6 Regression] ICE: RTL check: expected code 'mem', have 'reg' in emit_block_move_hints, at expr.c:1189
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-19 15:40 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44941
[Bug target/44987] *mmintrin.h files incompatible with partial __attribute__((target(sse...)))
--- Comment #3 from andi-gcc at firstfloor dot org 2010-07-19 15:47 --- HJ, are you saying that target(sse4.2) is broken too (seems to work here in simple tests?) or just that some target sub options are broken? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44987
[Bug lto/44992] New: ld -r breaks LTO
When object files containing LTO sections are linked together with ld -r the linker merges all sections with the same name. The LTO reader cannot deal with this. Currently it will just ignore excessive data behind the first entry for most sections, which leads to all kinds of errors. I have been working on a patch kit to solve this, this is just a tracking bug for it. -- Summary: ld -r breaks LTO Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
[Bug debug/44971] [4.6 Regression] -fcompare-debug failure with uninitialized read in walk_gimple_stmt
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-19 16:04 --- Bah, iterating over cfun-local_decls plus DECL_ARGUMENTS doesn't work because with IPA-SRA DECL_ARGUMENTs are not in referenced-vars. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44971
[Bug bootstrap/44993] New: [4.6 regression] sparc64-linux bootstrap broken
full 64 bit bootstrap is now failing: r161903 ok r161941 ko /home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/ -B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/bin/ -B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/lib/ -isystem /n/62/guerby/instal\ l-trunk-64/sparc64-unknown-linux-gnu/include -isystem /n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg a-cdlili.adb -o a-cdlili.o +===GNAT BUG DETECTED==+ | 4.6.0 20100708 (experimental) [trunk revision 161941] (sparc64-unknown-linux-gnu) | | Storage_Error stack overflow (or erroneous memory access)| | Error detected at s-finroo.ads:53:4 | Then at r162274 there's a new earlier failure in bootstrap, probably masking the above: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/dwarf2out.o differs gcc/tree-ssa.o differs libdecnumber/decNumber.o differs libdecnumber/decimal32.o differs libdecnumber/decimal64.o differs libdecnumber/decimal128.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/guerby/build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/guerby/build' make: *** [bootstrap] Error 2 configure line: export CC=gcc -m64 ../trunk/configure --prefix=/n/62/guerby/install-trunk-64 --disable-werror --enable-languages=c,ada --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1-64 --with-gmp=/opt/cfarm/gmp-4.2.4-64 --with-mpc=/opt/cfarm/mpc-0.8-64 -- Summary: [4.6 regression] sparc64-linux bootstrap broken Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC build triplet: sparc64-unknown-linux-gnu GCC host triplet: sparc64-unknown-linux-gnu GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44993
[Bug lto/44992] ld -r breaks LTO
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-19 16:20 --- And partial linking support will break mixed LTO / non-LTO objects. Unless we drop all non-LTO sections from LTO objects and thus the .text sections of partially linked mixed LTO / non-LTO objects will be still used in the final link. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||lto Last reconfirmed|-00-00 00:00:00 |2010-07-19 16:20:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
[Bug lto/44992] ld -r breaks LTO
--- Comment #2 from andi-gcc at firstfloor dot org 2010-07-19 16:31 --- Not sure I understand the comment. The case I've been looking at is ld -r (without a LTO code generation stage) to combine existing object and then using gold for the final linking/LTO code generation based on the combined objects. For me it seems like gold handles this correctly (with my patches) Your scenario sounds like ld -r with code generation? That's probably harder. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
[Bug middle-end/44989] [4.6 regression] g++.dg/guality/redeclaration1.C
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-19 16:32 --- The test is new, how could this be a regression? Yes, -flto/-fwhopr has lots of issues with debug info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44989
[Bug testsuite/44932] gcc.dg/uninit-pred-9_b.c fails
--- Comment #4 from davidxl at gcc dot gnu dot org 2010-07-19 16:34 --- Fixed in r162310. David -- davidxl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44932
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #13 from jakub at gcc dot gnu dot org 2010-07-19 16:52 --- You clearly haven't looked at the code. libgfortran uses gthr*.h macros/inlines for portability, and those test pthread_cancel != NULL (using weak undef; test that for many different inlines, see __gthread_active_p). The problem is that if pthread_cancel is linked in from libpthread.a, but some other pthread_* function is not, then it will crash when calling that non-available function. Testing all possible pthread_* functions that are ever mentioned in gthr*.h in __gthread_active_p would be terrible for performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug lto/44966] weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-07-19 17:50 --- mine -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-19 17:50:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
[Bug lto/44966] weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-07-19 17:52 --- Created an attachment (id=21251) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21251action=view) fix Hi, the problem is that alias is defined in one module, but aliases don't get cgraph nodes unless they are used. It is used in other modules and while merging we clash. It seems OK to just create new node in this case though it is bit ugly (at least ENABLE_CHECKING should verify that decl is indeed alias) or perhaps we can always create node. I will look into it more, but this patch at least solves ICE on the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
[Bug target/44987] *mmintrin.h files incompatible with partial __attribute__((target(sse...)))
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-19 18:01 --- For the time being, I suggest you compile it with a different file. One approach is to implement something similar to cpu dispatcher in icc via GNU_IFUNC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44987
[Bug c++/44994] New: [C++0x] ICE on invalid with variadic templates
The below ICEs with:
a.cc:11:32: error: expected nested-name-specifier before . token
a.cc:11:32: error: expected before . token
a.cc: In instantiation of const bool mini_is_constructibleint, A, A::value:
a.cc:20:44: instantiated from here
a.cc:15:63: error: no matching function for call to mini_is_constructibleint,
A, A::test(int)
Internal compiler error: Error reporting routines re-entered.
templatetypename Tp, typename... Args
class mini_is_constructible
{
typedef char one;
typedef struct { char arr[2]; } two;
templatetypename Tp1, typename... Args1
static decltype(Tp1(Args1()...), one())
test(int);
templatetypename, typename.. // Note missing dot.
static two test(...);
public:
static const bool value = sizeof(testTp, Args...(0)) == 1;
};
class A { };
int Test[mini_is_constructibleint, A, A::value ? -1 : 1];
--
Summary: [C++0x] ICE on invalid with variadic templates
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44994
[Bug debug/39705] enum constants don't appear in debug_pubnames
--- Comment #3 from tromey at gcc dot gnu dot org 2010-07-19 18:44 --- In the end, we decided not to use .debug_pubnames in gdb. And, GCC no longer generates this section on most platforms. So, I am closing this bug. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39705
[Bug fortran/42385] [OOP] poylmorphic operators do not work
--- Comment #8 from pault at gcc dot gnu dot org 2010-07-19 18:49 --- Subject: Bug 42385 Author: pault Date: Mon Jul 19 18:48:44 2010 New Revision: 162313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162313 Log: 2010-07-19 Paul Thomas pa...@gcc.gnu.org PR fortran/42385 * interface.c (matching_typebound_op): Add argument for the return of the generic name for the procedure. (build_compcall_for_operator): Add an argument for the generic name of an operator procedure and supply it to the expression. (gfc_extend_expr, gfc_extend_assign): Use the generic name in calls to the above procedures. * resolve.c (resolve_typebound_function): Catch procedure component calls for CLASS objects, check that the vtable is complete and insert the $vptr and procedure components, to make the call. (resolve_typebound_function): The same. * trans-decl.c (gfc_trans_deferred_vars): Do not deallocate an allocatable scalar if it is a result. 2010-07-19 Paul Thomas pa...@gcc.gnu.org PR fortran/42385 * gfortran.dg/class_defined_operator_1.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/class_defined_operator_1.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42385
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #8 from steven at gcc dot gnu dot org 2010-07-19 19:04 ---
Offending insns that are scheduled in the wrong order:
(insn:TI 28 48 9 2 vector-2.c:7 (set (reg:DI 9 r9 [+8 ])
(mem/c/i:DI (reg/f:DI 14 r14 [351]) [2 t+8 S8 A64])) 5 {movdi_internal}
(expr_list:REG_DEAD (reg/f:DI 14 r14 [351])
(nil)))
(insn 9 28 18 2 vector-2.c:5 (set (mem/s/j/c:SI (reg/f:DI 15 r15 [343]) [2 t+4
S4 A32])
(reg:SI 114 r34 [ a ])) 4 {movsi_internal} (expr_list:REG_DEAD (reg:SI
114 r34 [ a ])
(expr_list:REG_DEAD (reg/f:DI 15 r15 [343])
(nil
So the MEMs are:
load from (mem/c/i:DI (reg/f:DI 14 r14 [351]) [2 t+8 S8 A64])
store to (mem/s/j/c:SI (reg/f:DI 15 r15 [343]) [2 t+4 S4 A32])
There is no dependency of insn 28 on insn 9, even though this is a rather
obvious read-after-write dependency.
;; ==
;; -- basic block 2 from 30 to 39 -- after reload
;; ==
;; --- forward dependences:
;; --- EBB Dependences --- from bb2 to bb2
;; insn codebb dep prio cost reservation
;; -- --- ---
;; 30 5 2 0 3 1 2_A : 39 9 36 35
;; 29 5 2 0 2 1 2_A : 39 28 21
;; 35 5 2 1 2 1 2_M_only_um23 : 39 21 9 36
;; 36 5 2 2 1 1 2_M_only_um23 : 39 28 9
;;9 4 2 3 0 1 2_M_only_um23 : 39
;; 21 5 2 2 1 1 2_M_only_um01 : 39 18 28
;; 28 5 2 3 0 1 2_M_only_um01 : 39 18
;; 18-1 2 2 0 0 nothing : 39
;; 39 334 2 8 0 0 2_B :
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug lto/44966] weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1
--- Comment #4 from andi-gcc at firstfloor dot org 2010-07-19 19:13 --- The test case works, but my big project now crashes with 758 prevailing-node-local.used_from_object_file = false; (gdb) p prevailing-vnode $1 = (struct varpool_node *) 0x0 I think it's a different variable now. I assume you'll need a test case for this too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
[Bug lto/44992] ld -r breaks LTO
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-19 19:35 --- I must say I don't like your solution. IMHO much better is instead add a header to LTO sections, which says the length of the LTO chunk (similarly e.g. to how .debug_info section chunks have length in the header), perhaps version, followed by that length of bytes of compressed stream, and change LTO reader to iterate over all chunks in the LTO section. This will also have advantage that it doesn't require non-ELF object formats to have section length not a multiple of 4, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
[Bug lto/44992] ld -r breaks LTO
--- Comment #4 from andi-gcc at firstfloor dot org 2010-07-19 19:46 --- This is actually what I tried first, but it turned out to be quite complicated, had to change a lot of code and my patch was growing and growing and it didn't fit clearly with the different readers etc. That is why I ended up with the post fixes instead which is much simpler and isolated in a single part of the reader. I don't understand the comment about section lengths? There's no dependency on section lengths being a multiple of 4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
[Bug fortran/42385] [OOP] poylmorphic operators do not work
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-07-19 20:12 --- Subject: Re: [OOP] poylmorphic operators do not work Fixed on trunk Paul Author: pault Date: Mon Jul 19 18:48:44 2010 New Revision: 162313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162313 Log: 2010-07-19 Paul Thomas pa...@gcc.gnu.org PR fortran/42385 * interface.c (matching_typebound_op): Add argument for the return of the generic name for the procedure. (build_compcall_for_operator): Add an argument for the generic name of an operator procedure and supply it to the expression. (gfc_extend_expr, gfc_extend_assign): Use the generic name in calls to the above procedures. * resolve.c (resolve_typebound_function): Catch procedure component calls for CLASS objects, check that the vtable is complete and insert the $vptr and procedure components, to make the call. (resolve_typebound_function): The same. * trans-decl.c (gfc_trans_deferred_vars): Do not deallocate an allocatable scalar if it is a result. 2010-07-19 Paul Thomas pa...@gcc.gnu.org PR fortran/42385 * gfortran.dg/class_defined_operator_1.f03 : New test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42385
[Bug bootstrap/44993] [4.6 regression] sparc64-linux bootstrap broken
--- Comment #1 from mikpe at it dot uu dot se 2010-07-19 21:04 --- The second failure is PR44970. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44993
[Bug target/44995] New: define a macro for presence of -mregnames option
In some cases, it would be useful if the presence of the gcc -mregnames option was not only communicated to the assembler, but also to the C program being compiled. This comes up in an unusual usage of inline-assembler operands, where the ambiguity between literals and register names is a problem. (http://sourceware.org/PR11821). With such a macro (say, -D__GCC_REGNAMES), the inline-asm code could emit extra code strings to allow resolution of the ambiguities. -- Summary: define a macro for presence of -mregnames option Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995
[Bug target/44995] define a macro for presence of -mregnames option
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-19 21:48 --- ambiguity It is not ambiguous at all in correct usage of inline-asm. I don't support a macro for this option at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995
[Bug target/44995] define a macro for presence of -mregnames option
--- Comment #2 from fche at redhat dot com 2010-07-19 21:51 --- It is not ambiguous at all in correct usage of inline-asm. Well, considering that the g constraint can generate either a literal or a naked register number, the ambiguity is real even for normal inline assembly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44995
[Bug lto/44966] weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1
--- Comment #5 from hubicka at ucw dot cz 2010-07-19 22:13 --- Subject: Re: weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1 Hmm, I guess we can do the same trick for variables. Will make patch. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
[Bug c++/44996] New: decltype produces rvalue reference type for parenthesized id-expression
The expression '(y)' below that constitutes the operand to decltype is neither an unparenthesized id-expression, a class member access, a function call nor an invocation of an overloaded operator. Based on the wording in FCD 14882 (WG21 N3092), this parenthesized id-expression has type int and is an lvalue. The type of decltype((y)) is then 'int '. The following test case demonstrates that GCC is finding the type to be 'int '. The test case is meant to compile clean. ### Self-contained source (dataa.cpp): extern int y; typedef int myIntRef; typedef decltype((y)) myIntRef; ### Command to reproduce: g++ -std=c++0x -c dataa.cpp ### Compiler output: dataa.cpp:3:23: error: conflicting declaration 'typedef int myIntRef' dataa.cpp:2:14: error: 'myIntRef' has a previous declaration as 'typedef int myIntRef' ### g++ -v output: Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: ../gcc-4.5.0/configure --prefix=/data/gcc --program-suffix=-4.5.0 --disable-libssp --disable-libgcj --enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 (GCC) -- Summary: decltype produces rvalue reference type for parenthesized id-expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hstong at ca dot ibm dot com GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44996
[Bug c++/44996] [C++0x] decltype produces rvalue reference type for parenthesized id-expression
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-19 23:03 --- yup, Jason confirmed this is a gcc bug on the std reflector -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-19 23:03:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44996
[Bug lto/44966] weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1
--- Comment #6 from hubicka at ucw dot cz 2010-07-19 23:50 ---
Subject: Re: weak aliases LTO with gold causes ICE in
lto_symtab_merge_decls_1
Hi,
try this one
Index: lto-symtab.c
===
--- lto-symtab.c(revision 162310)
+++ lto-symtab.c(working copy)
@@ -783,9 +783,25 @@ lto_symtab_merge_cgraph_nodes_1 (void **
for (e = prevailing-next; e; e = e-next)
{
if (e-node != NULL)
- lto_cgraph_replace_node (e-node, prevailing-node);
+ {
+ if (!prevailing-node)
+ {
+ gcc_assert (!e-node-analyzed);
+ prevailing-node = cgraph_node (prevailing-decl);
+ prevailing-node-alias = true;
+ }
+ lto_cgraph_replace_node (e-node, prevailing-node);
+ }
if (e-vnode != NULL)
- lto_varpool_replace_node (e-vnode, prevailing-vnode);
+ {
+ if (!prevailing-vnode)
+ {
+ gcc_assert (!e-vnode-finalized);
+ prevailing-vnode = varpool_node (prevailing-decl);
+ prevailing-vnode-alias = true;
+ }
+ lto_varpool_replace_node (e-vnode, prevailing-vnode);
+ }
}
/* Drop all but the prevailing decl from the symtab. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
[Bug lto/44966] weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1
--- Comment #7 from andi-gcc at firstfloor dot org 2010-07-20 00:23 --- Thanks. Unfortunately with that patch I still get the same ICE: 758 prevailing-node-local.used_from_object_file = false; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
[Bug lto/44966] weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1
--- Comment #8 from hubicka at ucw dot cz 2010-07-20 00:29 --- Subject: Re: weak aliases LTO with gold causes ICE in lto_symtab_merge_decls_1 Thanks. Unfortunately with that patch I still get the same ICE: 758 prevailing-node-local.used_from_object_file = false; You might get around by just checking prevailing-node != NULL (and same for vnode). For aliases where we don't have nodes/vnoes we don't need this flag. I can try to send you updated patch tomorrow (now really need some sleep) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
--- Comment #2 from jyasskin at gmail dot com 2010-07-20 00:43 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01538.html. Please review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641
[Bug c++/44996] [C++0x] decltype produces rvalue reference type for parenthesized id-expression
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-07-19 23:03:41 |2010-07-20 00:56:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44996
[Bug fortran/43851] Add _gfortran_error_stop_numeric
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-07-20 01:07 --- Not needed. Closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
[Bug fortran/37077] Implement Internal Unit I/O for character KIND=4
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-07-20 01:09 --- Done. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37077
[Bug fortran/44953] FAIL: gfortran.dg/char4_iunit_1.f03 * execution test
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-07-20 01:10 --- Fixed, thanks for report. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44953
[Bug c++/44996] [C++0x] decltype produces rvalue reference type for parenthesized id-expression
--- Comment #2 from jason at gcc dot gnu dot org 2010-07-20 01:32 --- Subject: Bug 44996 Author: jason Date: Tue Jul 20 01:31:42 2010 New Revision: 162323 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162323 Log: PR c++/44996 * semantics.c (finish_decltype_type): Correct decltype of parenthesized rvalue reference variable. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype23.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44996
[Bug c++/44996] [C++0x] decltype produces rvalue reference type for parenthesized id-expression
--- Comment #4 from jason at gcc dot gnu dot org 2010-07-20 03:31 --- Fixed for 4.5.1. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44996
[Bug c++/44996] [C++0x] decltype produces rvalue reference type for parenthesized id-expression
--- Comment #3 from jason at gcc dot gnu dot org 2010-07-20 03:31 --- Subject: Bug 44996 Author: jason Date: Tue Jul 20 03:31:29 2010 New Revision: 162324 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162324 Log: PR c++/44996 * semantics.c (finish_decltype_type): Correct decltype of parenthesized rvalue reference variable. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/decltype23a.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/semantics.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44996
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #10 from kargl at gcc dot gnu dot org 2010-07-20 04:01 --- Subject: Bug 44929 Author: kargl Date: Tue Jul 20 04:01:32 2010 New Revision: 162325 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162325 Log: 2010-07-19 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * gfortran.dg/allocate_with_typespec.f90: New test. * gfortran.dg/allocate_derived_1.f90: Update error message. 2010-07-19 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * fortran/match.c (match_type_spec): Check for derived type before intrinsic types. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_derived_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44697] I/O testsuite failures: \r\n vs \n - gfortran.dg/ftell_3.f90
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-07-20 04:35 --- Kai, would you test this for me please. Index: ftell_3.f90 === --- ftell_3.f90 (revision 162291) +++ ftell_3.f90 (working copy) @@ -3,9 +3,10 @@ ! Contributed by Janne Blomqvist, Manfred Schwarb ! and Dominique d'Humieres. program ftell_3 - integer :: i + integer :: i, j + character(1) :: ch character(len=99) :: buffer - open(10, form='formatted', status='scratch', position='rewind') + open(10, form='formatted', position='rewind') write(10, '(a)') '123456' write(10, '(a)') '789' write(10, '(a)') 'CC' @@ -13,16 +14,29 @@ rewind(10) read(10, '(a)') buffer call ftell(10, i) - if(i /= 7) then - call abort() +! Expected: On '\n' systems: 7, on \r\n systems: 8 + if(i /= 7 .and. i /= 8) then +call abort end if read(10,'(a)') buffer if (trim(buffer) /= 789) then call abort() end if - call ftell(10,i) - if (i /= 11) then - call abort() + call ftell(10,j) + close(10) + open(10, access=stream) +! Expected: On '\n' systems: 11, on \r\n systems: 13 + if (i == 7) then +read(10, pos=7) ch +if (ch /= char(10)) call abort +if (j /= 11) call abort end if - close(10) + if (i == 8) then +read(10, pos=7) ch +if (ch /= char(13)) call abort +read(10) ch +if (ch /= char(10)) call abort +if (j /= 13) call abort + end if + close(10, status=delete) end program ftell_3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44697
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-20 05:39 --- Subject: Bug 44929 Author: kargl Date: Tue Jul 20 05:38:49 2010 New Revision: 162326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162326 Log: 2010-07-19 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * gfortran.dg/allocate_with_typespec.f90: New test. * gfortran.dg/allocate_derived_1.f90: Update error message. 2010-07-19 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * fortran/match.c (match_type_spec): Check for derived type before intrinsic types. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/match.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_derived_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #12 from kargl at gcc dot gnu dot org 2010-07-20 05:40 --- Fixed on 4,5 and trunk. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
