Re: Proposing switch -fsmart-pointers
On Oct 8, 2012, at 5:17 PM, Andrew Haley a...@redhat.com wrote:
On 10/06/2012 11:59 AM, _ wrote:
Not that I think that STL/Boost are not great solutions for many
problems out there.
But the fact is that there is and always will be c/c++ code that can't
and will not use it.
But surely the set of people refusing to use C++ smart pointers is the
same set that will refuse to use your -fsmart-pointers.
It all boils down whether they are othodox or just simply pragmatic. I am
optimist and belive in second :)
C or C like templateless C++ code is still domain of most os /
drivers source code out there.
Just go agead and try to ask Linus to wrap all pointers to stl
templates ;D
And he'd have the same response to -fsmart-pointers. Face it, the
only real differences a compiler builtin would bring are:
1. A fossilized smart pointer type.
2. A different declaration syntax.
Now imagine you have 300 developers with varying experience or ability to work
under pressure.
You will have 100 libs to manage. And for each lot of patch reviews.
Now which way you decide to go
Way A: manual cleanup. 30
Proc A {
Alloc resource 1
If alloc failed return error
Process resource 1
If problem with processing and alloc successfull release resource 1 and
exit
Alloc 100 different resources
}
Andrew.
Re: Proposing switch -fsmart-pointers
Ahh ... sorry for that incomplete mail. I lost my right hand in
paragliding accident 2 months ago. And writing mail with one hand on
tablet is kinda weird. Again sorry .;(
Here is the complete version.
On Mon, Oct 8, 2012 at 5:17 PM, Andrew Haley a...@redhat.com wrote:
On 10/06/2012 11:59 AM, _ wrote:
Not that I think that STL/Boost are not great solutions for many
problems out there.
But the fact is that there is and always will be c/c++ code that can't
and will not use it.
But surely the set of people refusing to use C++ smart pointers is the
same set that will refuse to use your -fsmart-pointers.
On 10/06/2012 11:59 AM, _ wrote:
Not that I think that STL/Boost are not great solutions for many
problems out there.
But the fact is that there is and always will be c/c++ code that can't
and will not use it.
But surely the set of people refusing to use C++ smart pointers is the
same set that will refuse to use your -fsmart-pointers.
It all boils down whether they are othodox or just simply pragmatic. I
am optimist and belive in second :)
Andrew.
C or C like templateless C++ code is still domain of most os /
drivers source code out there.
Just go agead and try to ask Linus to wrap all pointers to stl
templates ;D
And he'd have the same response to -fsmart-pointers. Face it, the
only real differences a compiler builtin would bring are:
1. A fossilized smart pointer type.
2. A different declaration syntax.
Andrew.
Now imagine you have 300 developers with varying experience or ability
to work under pressure.
You will have 100 libs to manage. And for each lot of patch reviews.
Now Tell me which way you decide to go in those projects?. A or B?
Way A: code is still C but with automatic cleanup like with static
objects, 100% of time of code review you focus on code logic. ie code
reviews are faster. Code is shorter faster to compile has the same
speed and a lot of less places to make bugs
Proc A {
alloc resource 1
if problem exit
process resource 1
If problem exit
alloc 100 different resources
if problem exit
process 100 resources with resource 1
if problem exit
release resources 1-50
process result with resources 50-100 and resource 1
if problem exit
return success
}
Way B: manual cleanup. 30. pretty much 50% of time spend on patch
review was spend on checking wheter no errors were made in releasing
of resources in error handling. The time you could had spend reviewing
other code logic.
The code is unnecessary long it's logic is les obvious and takes more
time to compile.
Proc {
alloc resource 1
if problem exit
process resource 1
If problem release resource 1 exit
alloc 100 different resources
if problem release resource 1 and those that didn't fail and exit
process 100 resources with resource 1
if problem release resource 1 and 100 resources and exit
release resources 1-50
process result with resources 50-100 and resource 1
if problem release resource 1 plus resource 50-100 and exit
release resources 50-100
release resource 1
return success
}
Re: DECL_STRUCT_FUNCTION(cgraphnode-decl) == NULL when attempting Link-Time Optimization in plugin
On Mon, Oct 8, 2012 at 11:29 PM, David Malcolm dmalc...@redhat.com wrote: On Mon, 2012-10-08 at 18:21 +0200, Richard Guenther wrote: On Mon, Oct 8, 2012 at 5:17 PM, David Malcolm dmalc...@redhat.com wrote: I'm working on a static analysis extension to GCC via my gcc-python-plugin [1] The analysis is interprocedural (memory leak detection, as it happens). I have it working on one translation unit at a time, and I'm attempting to get it to work within Link Time Optimization so that it can see the interactions of all of the functions within a program or library, but I'm running what might be a bug (or I could be misunderstanding LTO). I have my plugin working within lto1, using -flto and -fplugin; my command line looks like: $ gcc -fPIC -shared -flto -g -fplugin=/home/david/coding/gcc-python/gcc-python/sm/python.so -fplugin-arg-python-script=examples/show-lto-supergraph.py tests/sm/lto/input-*.c --save-temps lto1 appears to be invoked twice by gcc. The first time, there are two passes: IPA_PASS named whole-program IPA_PASS named inline and in_lto_p is true. The second invocation has these passes, called per-function: GIMPLE_PASS *free_cfg_annotations GIMPLE_PASS cplxlower0 GIMPLE_PASS optimized RTL_PASS expand GIMPLE_PASS *rest_of_compilation RTL_PASS *init_function ...etc.., normal rest of compilation from RTL stage onwards and in_lto_p is false. I've attempted to wire in my interprocedural analysis as a new IPA pass before or after whole-program and inline within the first invocation of lto1. In each case it is able to walk the callgraph, and the callgraph it sees appears to be correct: walking the linked list of cgraph_nodes the various cgraph_edge and cgraph_node are as expected, and for each cgraph_node, cgraph_node-decl is a non-NULL tree instance of type FUNCTION_DECL (as expected); I'm able to generate a graphviz rendering of the whole-program callgraph within lto1 from my plugin. However, for every cgraph_node, the DECL_STRUCT_FUNCTION(cgraph_node-decl) is (struct function*)NULL, which thwarts my code's attempt to look up the CFG of each underlying function and work on the underlying gimple. Looking with eu-readelf at the .o files shows these lto sections are present (f is the name of one of the functions that I'd like to access the gimple CFG of): $ eu-readelf -a input-f.o|grep lto [ 5] .gnu.lto_.inline.c8904cb9a96e7417 PROGBITS 006c 0026 0 E 0 0 1 [ 6] .gnu.lto_f.c8904cb9a96e7417 PROGBITS 0092 0164 0 E 0 0 1 [ 7] .gnu.lto_.cgraph.c8904cb9a96e7417 PROGBITS 01f6 0032 0 E 0 0 1 [ 8] .gnu.lto_.vars.c8904cb9a96e7417 PROGBITS 0228 0012 0 E 0 0 1 [ 9] .gnu.lto_.refs.c8904cb9a96e7417 PROGBITS 023a 0013 0 E 0 0 1 [10] .gnu.lto_.statics.c8904cb9a96e7417 PROGBITS 024d 0014 0 E 0 0 1 [11] .gnu.lto_.decls.c8904cb9a96e7417 PROGBITS 0261 01f3 0 E 0 0 1 [12] .gnu.lto_.symtab.c8904cb9a96e7417 PROGBITS 0454 0011 0 E 0 0 1 [13] .gnu.lto_.opts PROGBITS 0465 00e9 0 E 0 0 1 25: 0001 1 OBJECT GLOBAL DEFAULT COMMON __gnu_lto_v1 [2a] __gnu_lto_v1 Are the (struct function*) and CFG meant to exist at this stage, and be in gimple form, and is DECL_STRUCT_FUNCTION meant to be non-NULL for functions in translation units that were compiled with -flto? (or have I misunderstood LTO?) It depends if you are in the WPA stage (lto1 was invoked with -fwpa) in which case no function bodies and thus no CFG is available at all, or if you are in LTRANS stage (lto1 was invoked with -fltrans) which see _part_ of the whole programs callgraph and function bodies (and thus CFGs). As a workaround you probably can make your example work by using -flto-partition=none which merges WPA and LTRANS stages and pull in the wole program into a single link-time TU. Many thanks: -fwpa was indeed being passed by gcc to lto1, and on adding -flto-partition=none to the gcc command line -fwpa goes away, and my plugin is able to see all of the gimple CFG from all of the .o files (and thus generate pretty graphviz renderings of the supergraph of all CFGs etc). FWIW the -fwpa behavior was surprising to me, and felt like something of a gotcha. Based on my reading of http://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html#LTO-Overview I had assumed that LTO mode was the default when setting -flto, and that WHOPR mode was something that I had to add an extra option to enable (and thus I merely skimmed those parts of the docs), whereas it seems to be the other way around. In my defense, the
Cannot modify jumps after sched2
Hi, Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such that jumps are not modified after sched2? Or in other words, is there a way to recognize if sched2 has already been ran (sched2_completed, maybe)? Cheers, Paulo Matos
Re: Cannot modify jumps after sched2
Quoting Steven Bosscher stevenb@gmail.com: Paul Matos wrote (http://gcc.gnu.org/ml/gcc/2012-10/msg00123.html): Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such that jumps are not modified after sched2? No, there isn't. Well, you could add a target-specific pass after sched2 with the sole purpoe of setting a flag in the machine_function struct. For simpler prototyping work you could also play with PLUGIN_OVERRIDE_GATE and use a static/global variable in the target code for the flag.
Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
Hi Joey Thank you for explanations. Now I have some comments and additional questions. Since now it will be a discussion rather than looking for help, I am re-routing the discussion to GCC mailing list. For those looking for the complete history, here is the context: http://gcc.gnu.org/ml/gcc-help/2012-10/msg00055.html On 09.10.2012 12:21, Joey Ye wrote: [snip] On 24.09.2012 12:30, Ilija Kocho wrote: Hi colleagues In a course of implementing lazy context switching I the following link come to me: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/DA FIFGGE.html [snip] Therefore here are my questions: 1) Does GCC use VFP registers for holding data other than floating point values (unsolicited VFP usage)? It doesn't so far. Although GCC has no problem use FP for non-FP, the cost model in ARM backend says using VFP isn't performing better than otherwise. For Cortex-M4F this isn't the best approach. I worked out a patch to tune the cost model for M4F together with an option to enable/disable it. I'm hoping to submit it later this year and it should enable Cortex-M4F to use VFP extensively for non-FP data when option enabled. If (1) is true: 1.1) What conditions, in addition to selecting -mfloat-abi=hard (or softfp) shall cause such behaviour. I would appreciate some test case. When the patch is upstreamed, and given that -ffpreg-for-nonfpdata is provided, VFP will be used for non-FP data when ever register pressure is high. [snip] 1.4) Can it be disabled? I found no such command line option for ARM targets. The command line will be as -f[no-]fpreg-for-nonfpdata According to current GCC conventions shoulfn't it begin with m i.e. -m[no]fpreg-for-nonfpdata ? 2) Above quote states that -mfloat-abi=soft should be used for libs, but ld refuses to link them with code produced with -mfloat-abi=hard even if the libs do not use floating point operations. Is there a waay to tweak this? The quote isn't accurate nowadays. More and more libraries are built with hard. Also a mechanism called multilib enables you to pick soft or hard automatically according to linker command line Although I am not GCC expert I am aware of multilibs. Indeed, I have succeeded in building of GCC with a pretty rich multilib collection. But my point is: at present, due to floating point ABI incompatibility, we can't link functions/libs compiled with -mfloat-abi=soft flag to functions/libs compiled with -mfloat-abi=hard flag, regardless whether floating point is effectively in use or not. But, won't particular functions, that _do not_ use floating point, effectively have same ABI regardless of flags used (-mfloat-abi=soft or -mfloat-abi=hard)? Then shouldn't it be possible to link them to both /soft/ and /hard/ float-abi code? Any comments? Ilija
Re: Proposing switch -fsmart-pointers
On 10/09/2012 12:31 AM, Peter wrote: On Oct 8, 2012, at 5:17 PM, Andrew Haley a...@redhat.com wrote: On 10/06/2012 11:59 AM, _ wrote: Not that I think that STL/Boost are not great solutions for many problems out there. But the fact is that there is and always will be c/c++ code that can't and will not use it. But surely the set of people refusing to use C++ smart pointers is the same set that will refuse to use your -fsmart-pointers. It all boils down whether they are othodox or just simply pragmatic. I am optimist and belive in second :) Me too, but there's nothing more pragmatic about adding -fsmart-pointers to gcc when we already have smart pointers in C++. C or C like templateless C++ code is still domain of most os / drivers source code out there. Just go agead and try to ask Linus to wrap all pointers to stl templates ;D And he'd have the same response to -fsmart-pointers. Face it, the only real differences a compiler builtin would bring are: 1. A fossilized smart pointer type. 2. A different declaration syntax. Now imagine you have 300 developers with varying experience or ability to work under pressure. I don't have to imagine that. But of course you have to do the cleanup anyway because it is unlikely that in a large application it is appropriate to replace *every* use of a pointer with a smart pointer: some you do, some you don't. Andrew.
unsigned integers and the calculation of PI
Hi All, I'm trying to verify the 'fldpi' instruction on the Intel Processor. Hope you would like to have a look at the following piece of example code? Best Regards, Mischa. http://www.cyberfiber.org/sites/default/files/2012020314%20-%20algorithms%20on%20the%20intel%20processor%20-%20unsigned%20integers%20of%20extended%20order%20_64-bit_.tar.bz2
Re: Cannot modify jumps after sched2
Paulo Matos schrieb:
Hi,
Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such
that jumps are not modified after sched2?
Or in other words, is there a way to recognize if sched2 has already
been ran (sched2_completed, maybe)?
Such flags would be really helpful, but unfortunately there is nothing
like that. In an ideal world, such flags are not needed, but there are
situations with the complexity of real-world hardware where such flags
were really appreciated.
I came across a similar situation where a flag like combine_completed or
split1_completed or ira_in_progress would have been very handy, see
http://gcc.gnu.org/ml/gcc/2011-07/msg00146.html
http://gcc.gnu.org/ml/gcc/2011-07/msg00154.html
In that case I thought about something like
#include tree-pass.h
bool
avr_gate_split1 (void)
{
if (current_pass-static_pass_number
pass_match_asm_constraints.pass.static_pass_number)
return true;
return false;
}
What happened is that I did not use this. Instead, the code does not
use pass meta-information and produced sub-optimal code for that reason.
Johann
RE: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
-Original Message- From: Ilija Kocho [mailto:ili...@siva.com.mk] Sent: Tuesday, October 09, 2012 21:08 To: Joey Ye Cc: gcc@gcc.gnu.org; Terry Guo Subject: Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F Hi Joey Thank you for explanations. Now I have some comments and additional questions. Since now it will be a discussion rather than looking for help, I am re-routing the discussion to GCC mailing list. For those looking for the complete history, here is the context: http://gcc.gnu.org/ml/gcc-help/2012-10/msg00055.html On 09.10.2012 12:21, Joey Ye wrote: [snip] On 24.09.2012 12:30, Ilija Kocho wrote: Hi colleagues In a course of implementing lazy context switching I the following link come to me: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/DA FIFGGE.html [snip] Therefore here are my questions: 1) Does GCC use VFP registers for holding data other than floating point values (unsolicited VFP usage)? It doesn't so far. Although GCC has no problem use FP for non-FP, the cost model in ARM backend says using VFP isn't performing better than otherwise. For Cortex-M4F this isn't the best approach. I worked out a patch to tune the cost model for M4F together with an option to enable/disable it. I'm hoping to submit it later this year and it should enable Cortex-M4F to use VFP extensively for non-FP data when option enabled. If (1) is true: 1.1) What conditions, in addition to selecting -mfloat-abi=hard (or softfp) shall cause such behaviour. I would appreciate some test case. When the patch is upstreamed, and given that -ffpreg-for-nonfpdata is provided, VFP will be used for non-FP data when ever register pressure is high. [snip] 1.4) Can it be disabled? I found no such command line option for ARM targets. The command line will be as -f[no-]fpreg-for-nonfpdata According to current GCC conventions shoulfn't it begin with m i.e. -m[no]fpreg-for-nonfpdata ? My typo. Should be -m. 2) Above quote states that -mfloat-abi=soft should be used for libs, but ld refuses to link them with code produced with -mfloat-abi=hard even if the libs do not use floating point operations. Is there a waay to tweak this? The quote isn't accurate nowadays. More and more libraries are built with hard. Also a mechanism called multilib enables you to pick soft or hard automatically according to linker command line Although I am not GCC expert I am aware of multilibs. Indeed, I have succeeded in building of GCC with a pretty rich multilib collection. But my point is: at present, due to floating point ABI incompatibility, we can't link functions/libs compiled with -mfloat-abi=soft flag to functions/libs compiled with -mfloat-abi=hard flag, regardless whether floating point is effectively in use or not. But, won't particular functions, that _do not_ use floating point, effectively have same ABI regardless of flags used (-mfloat-abi=soft or -mfloat-abi=hard)? Then shouldn't it be possible to link them to both /soft/ and /hard/ float-abi code? Then linker need to detect if there is really _no_ FP usage in a /hard/ copy, which is difficult if not impossible. The whole idea of different float ABI is to avoid such kind of check or the quiet runtime error without appropriate check. No matter what motivation behinds, I won't try to interlink soft and hard from maintain-ability and stability point of view. Any comments? Ilija
[Bug c++/54427] Expose more vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org 2012-10-09 06:18:35
UTC ---
Author: glisse
Date: Tue Oct 9 06:18:29 2012
New Revision: 192238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192238
Log:
2012-10-09 Marc Glisse marc.gli...@inria.fr
PR c++/54427
c/
* c-typeck.c: Include c-common.h.
(enum stv_conv): Moved to c-common.h.
(scalar_to_vector): Moved to c-common.c.
(build_binary_op): Adapt to scalar_to_vector's new prototype.
* Make-lang.in: c-typeck.c depends on c-common.h.
c-family/
* c-common.c (scalar_to_vector): Moved from c-typeck.c. Support
more operations. Make error messages optional.
* c-common.h (enum stv_conv): Moved from c-typeck.c.
(scalar_to_vector): Declare.
cp/
* typeck.c (cp_build_binary_op): Handle mixed scalar-vector
operations.
[LSHIFT_EXPR, RSHIFT_EXPR]: Likewise.
gcc/
* fold-const.c (fold_binary_loc): Use build_zero_cst instead of
build_int_cst for a potential vector.
testsuite/
* c-c++-common/vector-scalar.c: New testcase.
* g++.dg/ext/vector18.C: New testcase.
* g++.dg/ext/vector5.C: This is not an error anymore.
* gcc.dg/init-vec-1.c: Move ...
* c-c++-common/init-vec-1.c: ... here. Adapt error message.
* gcc.c-torture/execute/vector-shift1.c: Move ...
* c-c++-common/torture/vector-shift1.c: ... here.
* gcc.dg/scal-to-vec1.c: Move ...
* c-c++-common/scal-to-vec1.c: ... here. Avoid narrowing for
C++11. Adapt error messages.
* gcc.dg/convert-vec-1.c: Move ...
* c-c++-common/convert-vec-1.c: ... here.
* gcc.dg/scal-to-vec2.c: Move ...
* c-c++-common/scal-to-vec2.c: ... here.
Added:
trunk/gcc/testsuite/c-c++-common/convert-vec-1.c
- copied unchanged from r191610,
trunk/gcc/testsuite/gcc.dg/convert-vec-1.c
trunk/gcc/testsuite/c-c++-common/init-vec-1.c
- copied, changed from r191610, trunk/gcc/testsuite/gcc.dg/init-vec-1.c
trunk/gcc/testsuite/c-c++-common/scal-to-vec1.c
- copied, changed from r191610, trunk/gcc/testsuite/gcc.dg/scal-to-vec1.c
trunk/gcc/testsuite/c-c++-common/scal-to-vec2.c
- copied unchanged from r191610,
trunk/gcc/testsuite/gcc.dg/scal-to-vec2.c
trunk/gcc/testsuite/c-c++-common/torture/vector-shift1.c
- copied, changed from r191610,
trunk/gcc/testsuite/gcc.c-torture/execute/vector-shift1.c
trunk/gcc/testsuite/c-c++-common/vector-scalar.c (with props)
trunk/gcc/testsuite/g++.dg/ext/vector18.C (with props)
Removed:
trunk/gcc/testsuite/gcc.c-torture/execute/vector-shift1.c
trunk/gcc/testsuite/gcc.dg/convert-vec-1.c
trunk/gcc/testsuite/gcc.dg/init-vec-1.c
trunk/gcc/testsuite/gcc.dg/scal-to-vec1.c
trunk/gcc/testsuite/gcc.dg/scal-to-vec2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/Make-lang.in
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/vector5.C
Propchange: trunk/gcc/testsuite/c-c++-common/vector-scalar.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/c-c++-common/vector-scalar.c
('svn:keywords' added)
Propchange: trunk/gcc/testsuite/g++.dg/ext/vector18.C
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/g++.dg/ext/vector18.C
('svn:keywords' added)
[Bug middle-end/54860] [4.8 Regression]: build fails on cris-elf configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-10-09 06:37:12 UTC --- I can confirm the failure on alpha: (gdb) bt #0 0x000120b4c288 in htab_find_with_hash () #1 0x000120b4fac0 in lookup_scoped_attribute_spec(tree_node const*, tree_node const*) () at ../../gcc-svn/trunk/gcc/attribs.c:325 #2 0x000120915950 in comp_type_attributes(tree_node const*, tree_node const*) () at ../../gcc-svn/trunk/gcc/tree.c:4353 #3 0x000120918118 in build_type_attribute_qual_variant(tree_node*, tree_node*, int) () at ../../gcc-svn/trunk/gcc/tree.c:4303 #4 0x0001201ecf44 in build_library_function_decl_1(tree_node*, char const*, tree_node*, int, __va_list_tag) () at ../../gcc-svn/trunk/gcc/fortran/trans-decl.c:2650 #5 0x0001201f3770 in gfc_build_library_function_decl_with_spec(tree_node*, char const*, tree_node*, int, ...) () at ../../gcc-svn/trunk/gcc/fortran/trans-decl.c:2692 #6 0x0001201f38d0 in gfc_build_builtin_function_decls() () at ../../gcc-svn/trunk/gcc/fortran/trans-decl.c:3067 #7 0x0001201c49f8 in gfc_be_parse_file() () at ../../gcc-svn/trunk/gcc/fortran/f95-lang.c:175 #8 0x00012067516c in compile_file() () at ../../gcc-svn/trunk/gcc/toplev.c:546 #9 0x00012067772c in toplev_main(int, char**) () at ../../gcc-svn/trunk/gcc/toplev.c:1866 #10 0x0001200db798 in main () at ../../gcc-svn/trunk/gcc/main.c:36
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-10-09 07:23:05 UTC --- (In reply to comment #1) What has changed is that now -static-libstdc++ is used, in addition to -static-libgcc, to fix other builds failures since the switch to g++ by default. So I guess this would mean that you do NOT have a static libstdc++ with your base C++ compiler? I got the same error on arm-linux-gnueabi; the system compiler had installed the shared but not the static libstdc++ libraries. On that machine, the entire user-space is built without any static libstdc++ libraries, so it's quite annoying (and unexpected) to have to install them for Ada bootstrap. Couldn't Ada use the g++/libstdc++ bits from the compiler being built?
[Bug bootstrap/54863] New: [4.8 regresssion] multiple 'comparison between signed and unsigned integer expressions' errors in simplify-rtx.c:simplify_truncation broke m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54863 Bug #: 54863 Summary: [4.8 regresssion] multiple 'comparison between signed and unsigned integer expressions' errors in simplify-rtx.c:simplify_truncation broke m68k-linux bootstrap Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Attempting to bootstrap gcc-4.8-20121007 on m68k-linux failed with: /mnt/scratch/objdir48/./prev-gcc/g++ -B/mnt/scratch/objdir48/./prev-gcc/ -B/mnt/scratch/install48/m68k-unknown-linux-gnu/bin/ -nostdinc++ -B/mnt/scratch/objdir48/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -B/mnt/scratch/objdir48/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir48/prev-m68k-unknown-linux-gnu/libstdc++-v3/include/m68k-unknown-linux-gnu -I/mnt/scratch/objdir48/prev-m68k-unknown-linux-gnu/libstdc++-v3/include -I/mnt/scratch/gcc-4.8-20121007/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir48/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/scratch/objdir48/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-4.8-20121007/gcc -I/mnt/scratch/gcc-4.8-20121007/gcc/. -I/mnt/scratch/gcc-4.8-20121007/gcc/../include -I/mnt/scratch/gcc-4.8-20121007/gcc/../libcpp/include -I/mnt/scratch/gcc-4.8-20121007/gcc/../libdecnumber -I/mnt/scratch/gcc-4.8-20121007/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/scratch/gcc-4.8-20121007/gcc/../libbacktrace /mnt/scratch/gcc-4.8-20121007/gcc/simplify-rtx.c -o simplify-rtx.o /mnt/scratch/gcc-4.8-20121007/gcc/simplify-rtx.c: In function 'rtx_def* simplify_truncation(machine_mode, rtx, machine_mode)': /mnt/scratch/gcc-4.8-20121007/gcc/simplify-rtx.c:671:34: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] INTVAL (XEXP (op, 1)) precision) ^ /mnt/scratch/gcc-4.8-20121007/gcc/simplify-rtx.c:683:34: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] INTVAL (XEXP (op, 1)) precision) ^ /mnt/scratch/gcc-4.8-20121007/gcc/simplify-rtx.c:695:34: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] INTVAL (XEXP (op, 1)) precision) ^ /mnt/scratch/gcc-4.8-20121007/gcc/simplify-rtx.c:709:34: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] INTVAL (XEXP (op, 1)) op_precision) ^ cc1plus: all warnings being treated as errors make[3]: *** [simplify-rtx.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir48/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir48' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir48' make: *** [bootstrap] Error 2 The previous weekly snapshot, 4.8-20120930, bootstrapped fine. Complete configuration parameters: /mnt/scratch/gcc-4.8-20121007/configure --prefix=/mnt/scratch/install48 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --disable-sjlj-exceptions --disable-libmudflap --disable-plugin --disable-lto --disable-multilib
[Bug c++/54864] New: Decltype in nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54864
Bug #: 54864
Summary: Decltype in nested class
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following code:
struct S
{
int foo();
struct nested
{
S* outer;
auto bar() - decltype(outer-foo());
};
};
fails to compile with the following errors:
test.cpp:9:37: error: invalid use of incomplete type 'struct S'
auto bar() - decltype(outer-foo());
^
test.cpp:1:8: error: forward declaration of 'struct S'
struct S
^
test.cpp:9:37: error: invalid use of incomplete type 'struct S'
auto bar() - decltype(outer-foo());
^
test.cpp:1:8: error: forward declaration of 'struct S'
struct S
^
I believe this code is valid. It is accepted by clang trunk.
Tested with gcc-4.8-20121007.
[Bug middle-end/54862] [4.8 Regression] error: comparison between signed and unsigned integer expressions in simplify-rtx.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54862 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-10-09 07:40:08 UTC --- *** Bug 54863 has been marked as a duplicate of this bug. ***
[Bug bootstrap/54863] [4.8 regresssion] multiple 'comparison between signed and unsigned integer expressions' errors in simplify-rtx.c:simplify_truncation broke m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54863 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-10-09 07:40:08 UTC --- Dup of PR54862. *** This bug has been marked as a duplicate of bug 54862 ***
[Bug middle-end/54862] [4.8 Regression] error: comparison between signed and unsigned integer expressions in simplify-rtx.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54862 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-10-09 07:41:22 UTC --- I got the exact same failure with gcc-4.8-20121007 on m68k-linux.
[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.8 Regression]: build |[4.8 Regression]: build |fails on cris-elf |fails when configuring |configuring libgfortran due |libgfortran due to recent |to recent attribute |attribute changes in core |changes in core gcc |gcc --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-10-09 07:55:40 UTC --- I can also trigger this ICE with a cross from x86_64-pc-linux-gnu to alpha-linux-gnu: #0 htab_find_with_hash (htab=0x0, element=0x7fffcb30, hash=484198) at ../../gcc-svn/trunk/libiberty/hashtab.c:600 #1 0x00c2dbb6 in lookup_scoped_attribute_spec (ns=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc-svn/trunk/gcc/attribs.c:325 #2 0x00a91bc9 in comp_type_attributes (type1=0x2e8199d8, type2=0x2e819930) at ../../gcc-svn/trunk/gcc/tree.c:4353 #3 0x00a91f0b in build_type_attribute_qual_variant (ttype=0x2e819930, attribute=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc-svn/trunk/gcc/tree.c:4303 The problem is dereference of htab (=0x0) in htab_find_with_hash.
[Bug libstdc++/54754] [parallel mode] 'make check-parallel' only works on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54754 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-09 08:16:36 UTC --- Author: redi Date: Tue Oct 9 08:16:13 2012 New Revision: 192240 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192240 Log: PR libstdc++/54754 * include/parallel/compatibility.h: Use atomic built-ins when they are lock-free. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/compatibility.h
[Bug libstdc++/54754] [parallel mode] 'make check-parallel' only works on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54754 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-09 08:17:22 UTC --- fixed
[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org, ||ubizjak at gmail dot com Target Milestone|--- |4.8.0 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2012-10-09 08:24:06 UTC --- No, this is certainly wrong: I'm seeing the same failure on i386-pc-solaris2.1[01] (cf. PR testsuite/53365) and i686-unknown-linux-gnu. The same failure also occurs for FAIL: gcc.target/i386/pr53249.c (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr53249.c:1:0: error: address mode 'short' not supported in the 64 bit mode also on i386-pc-solaris2.1[01] and i686-unknown-linux-gnu. There's something amiss that's not darwin-specific. Rainer
[Bug testsuite/53365] gcc.target/i386/pr53249.c FAILs for -m64 on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53365 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-10-09 08:25:56 UTC --- The same bug is already handled in PR target/54257, so closing as dup. *** This bug has been marked as a duplicate of bug 54257 ***
[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||gseanmcg at gmail dot com --- Comment #6 from Rainer Orth ro at gcc dot gnu.org 2012-10-09 08:25:56 UTC --- *** Bug 53365 has been marked as a duplicate of this bug. ***
Re: [Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
On that machine, the entire user-space is built without any static libstdc++ libraries, so it's quite annoying (and unexpected) to have to install them for Ada bootstrap. Couldn't Ada use the g++/libstdc++ bits from the compiler being built? That would probably be better indeed, it's dangerous to rely on the base compiler too much, in particular when the base compiler is a C++ compiler. This whole switch to C++ is causing all sort of subtle troubles in particular wrt building GNAT, so if people who worked on the switch could have a look and suggest a change, I'll be happy to review it. Arno
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 --- Comment #4 from charlet at adacore dot com charlet at adacore dot com 2012-10-09 08:34:03 UTC --- On that machine, the entire user-space is built without any static libstdc++ libraries, so it's quite annoying (and unexpected) to have to install them for Ada bootstrap. Couldn't Ada use the g++/libstdc++ bits from the compiler being built? That would probably be better indeed, it's dangerous to rely on the base compiler too much, in particular when the base compiler is a C++ compiler. This whole switch to C++ is causing all sort of subtle troubles in particular wrt building GNAT, so if people who worked on the switch could have a look and suggest a change, I'll be happy to review it. Arno
[Bug target/54661] mcore_output_movedouble: operation on ‘memexp’ may be undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54661 --- Comment #1 from Nick Clifton nickc at gcc dot gnu.org 2012-10-09 08:37:10 UTC --- Author: nickc Date: Tue Oct 9 08:37:00 2012 New Revision: 192241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192241 Log: PR target/54661 * config/mcore/mcore.c (mcore_output_movedouble): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mcore/mcore.c
[Bug target/54661] mcore_output_movedouble: operation on ‘memexp’ may be undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54661 --- Comment #2 from Nick Clifton nickc at redhat dot com 2012-10-09 08:39:03 UTC --- This was due to a silly typo, now fixed.
[Bug libstdc++/54865] New: [parallel mode] tests timeout on power64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54865 Bug #: 54865 Summary: [parallel mode] tests timeout on power64 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu FAIL: 25_algorithms/copy/deque_iterators/1.cc execution test FAIL: 25_algorithms/copy_backward/deque_iterators/1.cc execution test FAIL: 25_algorithms/move/deque_iterators/1.cc execution test FAIL: 25_algorithms/move_backward/deque_iterators/1.cc execution test On gcc110, a 64 processor ppc64 box, the first one completes in 0.23s when built single-threaded with -O2, but when built with parallel mode and -O2 it still doesn't complete after 93m40s cpu time. Maybe there's something buggy about libgomp on ppc64, or maybe the libstdc++ parallel mode just doesn't scale to lots of processors.
[Bug target/54866] New: gcc.target/i386/long-double-80-7.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54866 Bug #: 54866 Summary: gcc.target/i386/long-double-80-7.c FAILs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: hjl.to...@gmail.com Host: i386-pc-solaris2.9, i686-unknown-linux-gnu Target: i386-pc-solaris2.9, i686-unknown-linux-gnu Build: i386-pc-solaris2.9, i686-unknown-linux-gnu The new gcc.target/i386/long-double-80-7.c test FAILs on Solaris 9/x86 and 32-bit Linux/x86: FAIL: gcc.target/i386/long-double-80-7.c (test for excess errors) WARNING: gcc.target/i386/long-double-80-7.c compilation failed to produce executable Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/long-double-80-7.c:1:0 : warning: SSE instruction set disabled, using 387 arithmetics [enabled by defau lt] /var/gcc/regression/trunk/9-gcc/build/gcc/include/xmmintrin.h:32:3: error: #erro r SSE instruction set not enabled /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/m128-check.h:52:3: err or: unknown type name '__m128' No idea what the right fix might be: just adding -msse2? Don't we also need sse2_runtime for a run test? Rainer
[Bug target/54866] gcc.target/i386/long-double-80-7.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54866 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug debug/54826] gdb test case failure (bs15503) due to gaps in lexical block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54826 Andreas Arnez arnez at linux dot vnet.ibm.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Andreas Arnez arnez at linux dot vnet.ibm.com 2012-10-09 09:02:08 UTC --- Very well, thanks!
[Bug rtl-optimization/54867] New: gcc.dg/pr44194-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54867 Bug #: 54867 Summary: gcc.dg/pr44194-1.c FAILs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ebotca...@gcc.gnu.org Host: i386-pc-solaris2.1[01], amd64-pc-solaris2.1[01] Target: i386-pc-solaris2.1[01], amd64-pc-solaris2.1[01] Build: i386-pc-solaris2.1[01], amd64-pc-solaris2.1[01] Since about 20120918 gcc.dg/pr44194-1.c FAILs on 64-bit Solaris/x86 (both 32-bit and 64-bit compilers): FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final set (mem Rainer
[Bug tree-optimization/54868] New: gcc.dg/tree-ssa/forwprop-22.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54868 Bug #: 54868 Summary: gcc.dg/tree-ssa/forwprop-22.c FAILs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: gli...@gcc.gnu.org Host: i386-pc-solaris2.9, i686-unknown-linux-gnu Target: i386-pc-solaris2.9, i686-unknown-linux-gnu Build: i386-pc-solaris2.9, i686-unknown-linux-gnu The new gcc.dg/tree-ssa/forwprop-22.c testcase FAILs on Solaris 9/x86 and 32-bit Linux/x86: FAIL: gcc.dg/tree-ssa/forwprop-22.c scan-tree-dump-times copyprop1 VEC_PERM_EXPR 1 FAIL: gcc.dg/tree-ssa/forwprop-22.c scan-tree-dump-not copyprop1 BIT_FIELD_REF Rainer
[Bug tree-optimization/54868] gcc.dg/tree-ssa/forwprop-22.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54868 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/53934] Better CPP macro diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53934 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-09 09:15:10 UTC --- (In reply to comment #0) Expected: Something similar. Possibly related to PR44054 and PR53552 See tree-diagnostic.c: maybe_unwind_expanded_macro_loc. You could reimplement it in gfortran using fortran diagnostics machinery. But if you reimplemented the gfortran diagnostics machinery in terms of the general diagnostics machinery, it will just work (and you will also fix those PRs). Note that the function does not use anything C/C++ specific, not even tree-specific.
[Bug libstdc++/54869] New: ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 Bug #: 54869 Summary: ext/random/simd_fast_mersenne_twister_engine/cons/defa ult.cc FAILs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: drepper@gmail.com, ebotca...@gcc.gnu.org, paolo.carl...@oracle.com Host: sparc*-*-solaris2* Target: sparc*-*-solaris2* Build: sparc*-*-solaris2* The new ext/random/simd_fast_mersenne_twister_engine/cons/default.cc testcase FAILs on Solaris/SPARC (both 32 and 64-bit): 1318548553 vs 1318548553 1985957974 vs 1985957974 1367744196 vs 1367744196 3463392791 vs 3463392791 2780736231 vs 2780736231 3894488561 vs 3894488561 3157036262 vs 3157036262 3491812767 vs 3491812767 1724574180 vs 1724574180 3645035493 vs 3645035493 15030273820155882740 vs 15510024334182072935 7424847061300251637 vs 5793753331747412752 12274779367645387890 vs 16198353238554625740 2232540708403540888 vs 2233208824926016498 17502480069811850555 vs 3566091399820823780 4216703503856069688 vs 16608268514591292798 166208635478247899 vs 10684941689666043359 4604613833690380892 vs 12463424292910456802 5930322781620806096 vs 5902567440240131366 8093226496393420735 vs 7228030834036501150 Assertion failed: success, file /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/default.cc, line 44, function run_test Rainer
[Bug rtl-optimization/54739] [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 Splitting reg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54739 --- Comment #11 from Nick Clifton nickc at gcc dot gnu.org 2012-10-09 09:22:00 UTC --- Author: nickc Date: Tue Oct 9 09:21:47 2012 New Revision: 192244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192244 Log: PR rtl-optimization/54739 * config/mcore/mcore.md: (anddi3, iordi3, xordi3): Delete patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mcore/mcore.md
[Bug fortran/54870] New: gfortran.dg/array_constructor_4.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54870 Bug #: 54870 Summary: gfortran.dg/array_constructor_4.f90 FAILs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ebotca...@gcc.gnu.org Host: sparc*-*-solaris2* Target: sparc*-*-solaris2* Build: sparc*-*-solaris2* Since about 20120608, the gfortran.dg/array_constructor_4.f90 FAILS on Solaris/SPARC with -m64: FAIL: gfortran.dg/array_constructor_4.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/array_constructor_4.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/array_constructor_4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/array_constructor_4.f90 -O3 -g execution test The -O3 -g test aborts like this: Backtrace for this error: #0 fffb5c822bcb [New Thread 1 (LWP 1)] Program received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0x7eee7620 in _lwp_kill () from /lib/64/libc.so.1 (gdb) where #0 0x7eee7620 in _lwp_kill () from /lib/64/libc.so.1 #1 0x7ee94624 in raise () from /lib/64/libc.so.1 #2 0x7ee6a10c in abort () from /lib/64/libc.so.1 #3 0xfffb5c824ed8 in _gfortrani_sys_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:173 #4 0xfffb5c8e3178 in _gfortran_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:33 #5 0x0001107c in MAIN__ () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/array_constructor_4.f90:9 #6 main (argc=optimized out, argv=0x7538) at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/array_constructor_4.f90:23 #7 0x00010d04 in _start ()
[Bug fortran/54871] New: [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54871 Bug #: 54871 Summary: [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ebotca...@gcc.gnu.org Host: sparc*-*-solaris2* Target: sparc*-*-solaris2* Build: sparc*-*-solaris2* Since about 20120803, the gfortran.dg/vector_subscript_1.f90 testcase FAILs on Solaris/SPARC (32-bit only): FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test It aborts like this: Backtrace for this error: #0 ff219d6b [New Thread 1 (LWP 1)] Program received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xff0da400 in _lwp_kill () from /lib/libc.so.1 (gdb) where #0 0xff0da400 in _lwp_kill () from /lib/libc.so.1 #1 0xff083d50 in raise () from /lib/libc.so.1 #2 0xff05b55c in abort () from /lib/libc.so.1 #3 0xff21bcd4 in _gfortrani_sys_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:173 #4 0xff2b5d0c in _gfortran_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:33 #5 0x000141cc in test (rhs=..., lhs=...) at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/vector_subscript_1.f90:160 #6 MAIN__ () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/vector_subscript_1.f90:68 This is a regression from 4.7. Rainer
[Bug lto/54856] Corrupted LTO type merging
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54856 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-09 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-09 09:40:07 UTC --- Which revision was that with? Doesn't seem to reproduce for me.
[Bug fortran/54871] [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54871 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libstdc++/54872] New: [4.8 regression] abi_check FAILs on Solaris 10/11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54872 Bug #: 54872 Summary: [4.8 regression] abi_check FAILs on Solaris 10/11 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: b...@gcc.gnu.org Host: *-*-solaris2.1[01] Target: *-*-solaris2.1[01] Build: *-*-solaris2.1[01] abi_check currently FAILs on Solaris 10 and 11(both SPARC and x86, 32 and 64-bit), Solaris 9 is unaffected. On Solaris 10, I get 1 incompatible symbols 0 _ZNSt12system_errorC1ESt10error_codeRKSs std::system_error::system_error(std::error_code, std::string const) version status: incompatible GLIBCXX_3.4.11 type: function status: added On Solaris 11, I get: 2 incompatible symbols 0 _ZNSt12system_errorC2ESt10error_codeRKSs std::system_error::system_error(std::error_code, std::string const) version status: incompatible GLIBCXX_3.4.11 type: function status: added 1 _ZNSt12system_errorC1ESt10error_codeRKSs std::system_error::system_error(std::error_code, std::string const) version status: incompatible GLIBCXX_3.4.11 type: function status: added Rainer
[Bug target/54866] gcc.target/i386/long-double-80-7.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54866 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-10-09 09:45:15 UTC --- (In reply to comment #0) /var/gcc/regression/trunk/9-gcc/build/gcc/include/xmmintrin.h:32:3: error: #erro r SSE instruction set not enabled /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/m128-check.h:52:3: err or: unknown type name '__m128' No idea what the right fix might be: just adding -msse2? Don't we also need sse2_runtime for a run test? Just add -msse2. The test already uses sse2-check.h, so sse2_runtime is not neccessary. The patch that adds -msse2 is pre-approved.
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 09:49:08 UTC --- Guys, I don't have Sparc-Solaris machines and didn't design the testcase. To be honest, I didn't even realize so far that this simd_* variant was meant for other targets besides x86_64. Ulrich, please help a bit the target maintainers...
[Bug libstdc++/54865] [parallel mode] tests timeout on power64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54865 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||singler at kit dot edu --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 09:51:24 UTC --- Let's add Johannes in CC.
[Bug go/54873] New: runtime/pprof FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54873 Bug #: 54873 Summary: runtime/pprof FAILs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* The runtime/pprof testcase FAILs on Solaris: Undefinedfirst referenced symbol in file nanosleep /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/.libs/libgo.a(syscall.o) sched_yield /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/.libs/libgo.a(yield.o) sem_timedwait /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/.libs/libgo.a(thread-sema.o) sem_init /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/.libs/libgo.a(thread-sema.o) sem_post /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/.libs/libgo.a(thread-sema.o) sem_wait /var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/.libs/libgo.a(thread-sema.o) ld: fatal: symbol referencing errors. No output written to a.out collect2: error: ld returned 1 exit status FAIL: runtime/pprof This happens due to runtime_pprof_check_GOCFLAGS = -static-libgo in libgo/Makefile.am. The generated Makefile has LIBS = -lrt but this is not added by gccgo in the static case. Rainer
[Bug tree-optimization/54868] [4.8 Regression]gcc.dg/tree-ssa/forwprop-22.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54868
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-10-09 09:57:58
UTC ---
I expected these 2 lines to disqualify a basic x86 target:
/* { dg-require-effective-target vect_double } */
/* { dg-require-effective-target vect_perm } */
but sadly it looks like they just answer that i386 has hardware vectors :-(
(is that really the case? there seem to be other tests using these checks)
Any suggestion on a better test for targets that really support vectors?
[Bug middle-end/54862] [4.8 Regression] error: comparison between signed and unsigned integer expressions in simplify-rtx.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54862 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 Bug #: 54874 Summary: OOP: polymorphic allocation with SOURCE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 28396 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28396 test case Hi, I am getting the following output from the test case. It seems wrong, I do not see why allocating the polymorphic component in p%vect(4) should change the entries p%vect(1:3) This may or may not be a duplicate of 54784. [sfilippo@jacobi bug34]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7.2/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.7.2 (GCC) [sfilippo@jacobi bug34]$ gfortran -o testpolyvect testpolyvect.f90 [sfilippo@jacobi bug34]$ ./testpolyvect level1 New inner descr level1 New inner descr level2 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level1 Base inner descr level2 Base inner descr level3 Base inner descr level4 Base inner descr
[Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 --- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 09:59:28 UTC --- Just opened 54874. May or may not be a duplicate of this one.
[Bug c++/54194] misleading suggestion about arithmetic in operand of '|'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54194 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-10-09 10:01:37 UTC --- Author: paolo Date: Tue Oct 9 10:01:31 2012 New Revision: 192246 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192246 Log: 2012-10-09 Paolo Carlini paolo.carl...@oracle.com PR c++/54194 * tree.h: Add EXPR_LOC_OR_LOC. c-family/ 2012-10-09 Paolo Carlini paolo.carl...@oracle.com PR c++/54194 * c-common.c (warn_about_parentheses): Add location_t parameter; use EXPR_LOC_OR_LOC. * c-common.h: Update declaration. c/ 2012-10-09 Paolo Carlini paolo.carl...@oracle.com PR c++/54194 * c-typeck.c (parser_build_binary_op): Update warn_about_parentheses call. /cp 2012-10-09 Paolo Carlini paolo.carl...@oracle.com PR c++/54194 * typeck.c (build_x_binary_op): Update warn_about_parentheses call. * parser.c (cp_parser_binary_expression): Use SET_EXPR_LOCATION on current.lhs. /testsuite 2012-10-09 Paolo Carlini paolo.carl...@oracle.com PR c++/54194 * g++.dg/warn/Wparentheses-26.C: Adjust. * g++.dg/warn/Wparentheses-27.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wparentheses-27.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wparentheses-26.C trunk/gcc/tree.h
[Bug fortran/54874] OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 10:02:41 UTC --- Interestingly, taking out the outer container p% makes the code work... --- [sfilippo@jacobi bug34]$ gfortran -o poywork polywork.f90 [sfilippo@jacobi bug34]$ ./poywork level1 New inner descr level1 New inner descr level2 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level4 Base inner descr -- program testsource use testmod type(level), allocatable :: vect(:) class(outer), allocatable :: outvar1, outvar2 integer :: i,j,k,n,info n = 4 allocate(outer :: outvar1) allocate(outer :: outvar2) allocate(new_inner :: outvar1%var) allocate(inner :: outvar2%var) allocate(vect(n)) do i=1, n if (in) then allocate(vect(i)%outvar,source=outvar1) else allocate(vect(i)%outvar,source=outvar2) end if write(0,*) do k=1,i write(0,*) 'level ',k call vect(k)%outvar%var%descr() end do end do end program testsourc
[Bug c++/54194] misleading suggestion about arithmetic in operand of '|'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54194 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 10:02:45 UTC --- Fixed for 4.8.0.
[Bug rtl-optimization/54867] [4.8 Regression] gcc.dg/pr44194-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54867
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-10-09
Ever Confirmed|0 |1
--- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-09
10:14:10 UTC ---
Would you mind trying this patchlet?
Index: gcc.dg/pr44194-1.c
===
--- gcc.dg/pr44194-1.c(revision 192137)
+++ gcc.dg/pr44194-1.c(working copy)
@@ -15,5 +15,5 @@ void func() {
/* { dg-final { scan-rtl-dump global deletions = (2|3) dse1 } } */
/* { dg-final { cleanup-rtl-dump dse1 } } */
-/* { dg-final { scan-rtl-dump-not set \\(mem final } } */
+/* { dg-final { scan-rtl-dump-not insn .*set \\(mem final } } */
/* { dg-final { cleanup-rtl-dump final } } */
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|sparc*-*-solaris2* |sparc*-*-solaris2* ||powerpc*-*-* ||hppa-unknown-linux-gnu ||s390-ibm-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-09 Host|sparc*-*-solaris2* |sparc*-*-solaris2* ||powerpc*-*-* Ever Confirmed|0 |1 Build|sparc*-*-solaris2* |sparc*-*-solaris2* ||powerpc*-*-* --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-09 10:14:45 UTC --- Also fails for at least powerpc*-*-* (see http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg00888.html ), hppa-unknown-linux-gnu ( http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg00525.html ), and s390-ibm-linux-gnu ( http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg00602.html ). Endianness issue?
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 10:20:45 UTC --- Can also be something even more trivial, because I bet we didn't exercise much the codepath for __SSE2__ undefined before committing the code. Actually - and this is a question for Ulrich - is the code actually useful when __SSE2__ is undefined?
[Bug fortran/54874] OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #2 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 10:37:13 UTC --- And it is also a regression, as it works on 4.6.3: --- [sfilippo@jacobi bug34]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6.3/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.6.3 (GCC) [sfilippo@jacobi bug34]$ gfortran -o testpolyvect testpolyvect.f90 [sfilippo@jacobi bug34]$ ./testpolyvect level1 New inner descr level1 New inner descr level2 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level4 Base inner descr
[Bug target/54699] [4.8 Regression] [SH] gfortran.dg/class_array_9.f03 ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54699
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-10-09
Ever Confirmed|0 |1
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-09 10:41:23
UTC ---
(In reply to comment #3)
Doing this...
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 191865)
+++ gcc/config/sh/sh.c(working copy)
@@ -10079,6 +10079,9 @@
static bool
sh_legitimate_address_p (enum machine_mode mode, rtx x, bool strict)
{
+ if (reload_completed)
+return true;
+
if (MAYBE_BASE_REGISTER_RTX_P (x, strict))
return true;
else if ((GET_CODE (x) == POST_INC || GET_CODE (x) == PRE_DEC)
makes the ICE go away. However, I have not tested this for any other
consequences.
I'm wondering whether there is anything after reload that actually needs
address validation. I guess that after the reload pass pretty much everything
should have been fixed up which could generate invalid addresses that need to
be transformed. Of course, in one of the split passes after reload or the
peephole2 pass somebody could write a pattern that would result in an invalid
address. But even now with the address checking after reload, if there is an
invalid address left after reload, which pass would legitimize it?
[Bug fortran/54874] OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-09 10:48:30 UTC --- And it is also a regression, as it works on 4.6.3: ... Well, this may be more complicated. On x86_64-apple-darwin10, compiling the attached test with 4.6.3 gives: [macbook] f90/bug% a.out level1 New inner descr level1 New inner descr level2 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level4 Base inner descr a.out(97528) malloc: *** error for object 0x100201030: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug while I get the same result minus the error with 4.7.2 and trunk. For the test in comment #1, I always get [macbook] f90/bug% gfortran-fsf-4.6 pr54874_1.f90 -g Undefined symbols: ___testmod_MOD___vtab_testmod_Outer, referenced from: _MAIN__ in cclihViD.o _MAIN__ in cclihViD.o _MAIN__ in cclihViD.o _MAIN__ in cclihViD.o _MAIN__ in cclihViD.o ___testmod_MOD___vtab_testmod_Inner, referenced from: _MAIN__ in cclihViD.o ___testmod_MOD___vtab_testmod_New_inner, referenced from: _MAIN__ in cclihViD.o ld: symbol(s) not found collect2: ld returned 1 exit status
[Bug fortran/54874] OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 11:03:10 UTC --- (In reply to comment #3) And it is also a regression, as it works on 4.6.3: ... Well, this may be more complicated. On x86_64-apple-darwin10, compiling the attached test with 4.6.3 gives: Something is very fishy here..
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #4 from Ulrich Drepper drepper.fsp at gmail dot com 2012-10-09 11:23:41 UTC --- (In reply to comment #0) The new ext/random/simd_fast_mersenne_twister_engine/cons/default.cc testcase FAILs on Solaris/SPARC (both 32 and 64-bit): That's expected. I mentioned when I posted the patches that the implementation is for little endian machines. I don't have access to any big endian machines and therefore didn't even try to make it work. It might be sufficient, at end of _M_gen_rand, to swap the order of the four 32-bit words in a 128-bit word. I never tested this, someone else will have to do this.
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 11:28:45 UTC --- Ok, thanks, I missed that remark of yours. Well, at present nothing prevents people with big endian machines to try to use the code, and we unconditionally run the testsuite. That's not Ok. Let's keep the PR open for a while in case somebody wants to try your suggestion, otherwise, as far as I'm concerned, for 4.8.0, I will just disable the code and its tests on big endian.
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-09 11:35:19 UTC --- ... I don't have access to any big endian machines and therefore didn't even try to make it work. AFAICT there are big endian machines in the CompileFarm (see http://gcc.gnu.org/wiki/CompileFarm ) and any maintainer has access to it.
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-09 11:39:17 UTC --- As Nathan Froyd said at http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00772.html Please try to consider what's best for all the people who use GCC, not just the cases you happen to be working with every day.
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-09 11:43:00 UTC --- On that machine, the entire user-space is built without any static libstdc++ libraries, so it's quite annoying (and unexpected) to have to install them for Ada bootstrap. Couldn't Ada use the g++/libstdc++ bits from the compiler being built? No, this is stage 1 so the libstdc++ of the base compiler must be used. In the end, requiring a static libstdc++ is probably overzealous and should be dropped.
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 11:44:09 UTC --- Boy, nobody cites me like that, at least, not while I'm still alive.
[Bug middle-end/54862] [4.8 Regression] error: comparison between signed and unsigned integer expressions in simplify-rtx.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54862 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-09 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-09 11:53:57 UTC --- Created attachment 28397 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28397 gcc48-pr54862.patch Untested fix. Guess you get the warning only for 32-bit HWI host/target combinations. We shouldn't try to optimize anything for negative shift counts, so IMHO using UINTVAL is the right thing to do.
Re: [Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
On that machine, the entire user-space is built without any static libstdc++ libraries, so it's quite annoying (and unexpected) to have to install them for Ada bootstrap. Couldn't Ada use the g++/libstdc++ bits from the compiler being built? No, this is stage 1 so the libstdc++ of the base compiler must be used. Well, we could first build g++ and libstdc++, and then Ada I guess, but that's probably too ambitious. In the end, requiring a static libstdc++ is probably overzealous and should be dropped. Annoying for other reasons, but fine with me, feel free to make that change. Arno
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 --- Comment #6 from charlet at adacore dot com charlet at adacore dot com 2012-10-09 13:09:38 UTC --- On that machine, the entire user-space is built without any static libstdc++ libraries, so it's quite annoying (and unexpected) to have to install them for Ada bootstrap. Couldn't Ada use the g++/libstdc++ bits from the compiler being built? No, this is stage 1 so the libstdc++ of the base compiler must be used. Well, we could first build g++ and libstdc++, and then Ada I guess, but that's probably too ambitious. In the end, requiring a static libstdc++ is probably overzealous and should be dropped. Annoying for other reasons, but fine with me, feel free to make that change. Arno
[Bug rtl-optimization/54867] [4.8 Regression] gcc.dg/pr44194-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54867 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2012-10-09 13:35:01 UTC --- Created attachment 28398 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28398 final dump Unfortunately, this doesn't help. I'm attaching the -m64 dump for reference.
[Bug tree-optimization/54868] [4.8 Regression]gcc.dg/tree-ssa/forwprop-22.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54868 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 2012-10-09 13:37:56 UTC --- Maybe moving the test from tree-ssa/ to vect/ would be enough? Seems like vect.exp uses check_vect_support_and_set_flags (I don't see how to use that for a single test).
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-09 13:37:57 UTC --- Well, we could first build g++ and libstdc++, and then Ada I guess, but that's probably too ambitious. Very likely indeed, since you need to have binary compatibility between the base Ada compiler and the C/C++ compiler used during stage 1. Annoying for other reasons, but fine with me, feel free to make that change. Thanks, will do.
[Bug c++/54875] New: Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875
Bug #: 54875
Summary: Forward declare enums cannot be used as a template
argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following simple code snippet shows the problem:
templatetypename T
using AddConst = T const;
enum FwdEnum : int;
int main() {
AddConstFwdEnum *ptr = nullptr;
}
Trying to instantiate the alias template, in this case to declare a pointer but
the problem is more general, produces an internal compiler error. The problem
is probably older than the gcc 4.8 I am testing with, but it does give a nice
assertion from the compiler:
main.cpp: In function 'int main()':
main.cpp:7:20: internal compiler error: tree check: expected enumeral_type,
have template_type_parm in tsubst_enum, at cp/pt.c:18923
AddConstFwdEnum *ptr = nullptr;
^
main.cpp:7:20: internal compiler error: Abort trap: 6
g++-mp-4.8: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
Version info of the compiler I am testing with:
gcc -v -save-temps -std=c++11
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure
--disable-checking --enable-werror
--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
[Bug target/54866] gcc.target/i386/long-double-80-7.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54866 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2012-10-09 13:40:32 UTC --- Author: ro Date: Tue Oct 9 13:40:21 2012 New Revision: 192253 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192253 Log: Fix gcc.target/i386/long-double-80-7.c (PR target/54866) PR target/54866 * gcc.target/i386/long-double-80-7.c: Add -msse2 to dg-options. Modified: trunk/gcc/testsuite/gcc.target/i386/long-double-80-7.c
[Bug target/54866] gcc.target/i386/long-double-80-7.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54866 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-10/msg00863.htm ||l Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2012-10-09 13:42:27 UTC --- Fixed for 4.8.0.
[Bug ada/54845] [trunk/gcc/c-family/c-ada-spec.c:3114]: (error) Buffer is accessed out of bounds.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54845 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added CC||charlet at gcc dot gnu.org AssignedTo|unassigned at gcc dot |charlet at gcc dot gnu.org |gnu.org | --- Comment #1 from Arnaud Charlet charlet at gcc dot gnu.org 2012-10-09 13:43:04 UTC --- Thanks for the report, I'll fix that.
[Bug bootstrap/54834] bootstrap fails when building libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 --- Comment #3 from Tobias Schlüter tobi at gcc dot gnu.org 2012-10-09 14:00:43 UTC --- Created attachment 28399 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28399 toplevel config.log I'm attaching the toplevel config.log. From it I read that the compiler is configure:4103: gcc --version 5 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Copyright (C) 2007 Free Software Foundation, Inc. The configure command was ../configure --enable-languages=c,c++,fortran (my build directory is a subdirectory of the gcc directory)
[Bug bootstrap/54834] bootstrap fails when building libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 --- Comment #4 from Tobias Schlüter tobi at gcc dot gnu.org 2012-10-09 14:06:19 UTC --- I ran make in a directory with a pre-existing build, ao maybe that include file was an old leftover. Please don't invest any further time in this now, I'll try a clean build first.
[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 --- Comment #8 from dodji at seketeli dot org dodji at seketeli dot org 2012-10-09 14:08:20 UTC --- I can reproduce it now. I guess I shouldn't look at bugs around midnight or something.
[Bug c++/54808] error: non-trivial conversion at assignment (with bit fields)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54808 --- Comment #3 from chgena at mail dot ru 2012-10-09 14:10:09 UTC --- Some 4.8 betas seem to be affected too
[Bug bootstrap/54837] [4.8 Regression] lto bootstrap error: ICE in expand_debug_source_expr, at cfgexpand.c:3538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54837 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-09 14:14:36 UTC --- DECL_ABSTRACT_ORIGIN (parm) == aexp (gdb) call debug_tree (parm) parm_decl 0x75f34000 unit_num type integer_type 0x760c85e8 int asm_written public SI size integer_cst 0x760cc0a0 constant 32 unit size integer_cst 0x760cc0c0 constant 4 align 32 symtab -165706496 alias set 2 canonical type 0x760c85e8 precision 32 min integer_cst 0x760cc040 -2147483648 max integer_cst 0x760cc060 2147483647 pointer_to_this pointer_type 0x760d02a0 used SI file /space/rguenther/src/svn/trunk/gcc/genautomata.c line 3573 col 61 size integer_cst 0x760cc0a0 32 unit size integer_cst 0x760cc0c0 4 align 32 context function_decl 0x761fff00 _ZL16test_unit_reservPmii.3701.constprop.227 abstract_origin parm_decl 0x761fce80 unit_num (reg/v:SI 71 [ unit_num ]) arg-type integer_type 0x760c85e8 int incoming-rtl (reg:SI 4 si [ unit_num ]) (gdb) call debug_tree (aexp) parm_decl 0x761fce80 unit_num type integer_type 0x760c85e8 int asm_written public SI size integer_cst 0x760cc0a0 constant 32 unit size integer_cst 0x760cc0c0 constant 4 align 32 symtab -165706496 alias set 2 canonical type 0x760c85e8 precision 32 min integer_cst 0x760cc040 -2147483648 max integer_cst 0x760cc060 2147483647 pointer_to_this pointer_type 0x760d02a0 used SI file /space/rguenther/src/svn/trunk/gcc/genautomata.c line 3573 col 61 size integer_cst 0x760cc0a0 32 unit size integer_cst 0x760cc0c0 4 align 32 context function_decl 0x761ffe00 test_unit_reserv arg-type integer_type 0x760c85e8 int I'm testing a quick hack. Broken LTO bootstrap is annoying.
[Bug c++/54875] Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-10-09 14:23:36 UTC --- I can reproduce this error with gcc 4.8.0 20120930 (experimental), were I get: main.cpp|7|internal compiler error: tree check: expected enumeral_type, have template_type_parm in tsubst_enum, at cp/pt.c:18886| [Note the slight difference in the source code line number]
[Bug c++/54875] Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 14:38:06 UTC --- As far as I can see, the alias declaration is essential. As such, let's add Dodji in CC, maybe he can have a look.
[Bug bootstrap/54837] [4.8 Regression] lto bootstrap error: ICE in expand_debug_source_expr, at cfgexpand.c:3538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54837 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-09 14:40:12 UTC --- Author: rguenth Date: Tue Oct 9 14:40:01 2012 New Revision: 192255 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192255 Log: 2012-10-09 Richard Guenther rguent...@suse.de PR middle-end/54837 * cfgexpand.c (expand_debug_source_expr): Move checking code conditional on a found decl_debug_args vector. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c
[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-09 Ever Confirmed|0 |1 --- Comment #5 from janus at gcc dot gnu.org 2012-10-09 14:42:48 UTC --- (In reply to comment #0) I am getting the following output from the test case. It seems wrong, I do not see why allocating the polymorphic component in p%vect(4) should change the entries p%vect(1:3) This may or may not be a duplicate of 54784. Yes, this is surely a duplicate of PR54784, which is confirmed by the fact that the patch given there also fixes the behavior here.
[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 14:46:15 UTC --- (In reply to comment #5) (In reply to comment #0) I am getting the following output from the test case. It seems wrong, I do not see why allocating the polymorphic component in p%vect(4) should change the entries p%vect(1:3) This may or may not be a duplicate of 54784. Yes, this is surely a duplicate of PR54784, which is confirmed by the fact that the patch given there also fixes the behavior here. Great news! Thanks Salvatore
[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #7 from janus at gcc dot gnu.org 2012-10-09 14:47:38 UTC --- (In reply to comment #3) Well, this may be more complicated. On x86_64-apple-darwin10, compiling the attached test with 4.6.3 gives: [...] a.out(97528) malloc: *** error for object 0x100201030: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug while I get the same result minus the error with 4.7.2 and trunk. For the test in comment #1, I always get [macbook] f90/bug% gfortran-fsf-4.6 pr54874_1.f90 -g Undefined symbols: ___testmod_MOD___vtab_testmod_Outer, referenced from: _MAIN__ in cclihViD.o _MAIN__ in cclihViD.o _MAIN__ in cclihViD.o _MAIN__ in cclihViD.o _MAIN__ in cclihViD.o ___testmod_MOD___vtab_testmod_Inner, referenced from: _MAIN__ in cclihViD.o ___testmod_MOD___vtab_testmod_New_inner, referenced from: _MAIN__ in cclihViD.o ld: symbol(s) not found So, the only additional problems here are these errors on darwin. While the first one only seems to occur with 4.6, the second one also persists in 4.7 and trunk, if I get you right.
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-10-09 14:50:31 UTC --- Author: paolo Date: Tue Oct 9 14:50:19 2012 New Revision: 192256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192256 Log: 2012-10-09 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/54869 * include/ext/random (simd_fast_mersenne_twister_engine): Provide only for little endian targets. * include/ext/random.tcc: Likewise. * config/cpu/i486/opt/ext/opt_random.h: Likewise. * testsuite/lib/libstdc++.exp (check_v3_target_little_endian): Add. * testsuite/lib/dg-options.exp (dg-require-little-endian): Add. * testsuite/ext/random/simd_fast_mersenne_twister_engine/ operators/equal.cc: Use the latter. * testsuite/ext/random/simd_fast_mersenne_twister_engine/ operators/serialize.cc: Likewise. * testsuite/ext/random/simd_fast_mersenne_twister_engine/ operators/inequal.cc: Likewise. * testsuite/ext/random/simd_fast_mersenne_twister_engine/ cons/copy.cc: Likewise. * testsuite/ext/random/simd_fast_mersenne_twister_engine/ cons/seed1.cc: Likewise. * testsuite/ext/random/simd_fast_mersenne_twister_engine/ cons/seed2.cc: Likewise. * testsuite/ext/random/simd_fast_mersenne_twister_engine/ cons/default.cc: Likewise. * testsuite/ext/random/simd_fast_mersenne_twister_engine/ cons/seed_seq.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/cpu/i486/opt/ext/opt_random.h trunk/libstdc++-v3/include/ext/random trunk/libstdc++-v3/include/ext/random.tcc trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/copy.cc trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/default.cc trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/seed1.cc trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/seed2.cc trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/seed_seq.cc trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/equal.cc trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/inequal.cc trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/serialize.cc trunk/libstdc++-v3/testsuite/lib/dg-options.exp trunk/libstdc++-v3/testsuite/lib/libstdc++.exp
[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 --- Comment #9 from Dodji Seketeli dodji at gcc dot gnu.org 2012-10-09 14:52:24 UTC --- Created attachment 28400 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28400 Candidate fix patch Guys, could you please test this patch on your trees to see if it fixes the issue for you? I am testing it on my side. Thank you in advance, and sorry for the inconvenience.
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 14:53:14 UTC --- If the problem is endianness should be fixed now. Providing an implementation for big endian targets is enhancement.
[Bug libstdc++/54869] ext/random/simd_fast_mersenne_twister_engine/cons/default.cc FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54869 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-10-09 15:05:31 UTC --- --- Comment #4 from Ulrich Drepper drepper.fsp at gmail dot com 2012-10-09 11:23:41 UTC --- (In reply to comment #0) The new ext/random/simd_fast_mersenne_twister_engine/cons/default.cc testcase FAILs on Solaris/SPARC (both 32 and 64-bit): That's expected. I mentioned when I posted the patches that the implementation is for little endian machines. I don't have access to any big endian machines and therefore didn't even try to make it work. It might be sufficient, at end of _M_gen_rand, to swap the order of the four 32-bit words in a 128-bit word. I never tested this, someone else will have to do this. I'm not familiar with the code at all. Could you provide a tentative patch for me to try? Thanks. Rainer
[Bug bootstrap/54837] [4.8 Regression] lto bootstrap error: ICE in expand_debug_source_expr, at cfgexpand.c:3538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54837 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-10-09 15:15:23 UTC --- Fixed.
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 --- Comment #8 from Andy Nelson andy.nelson at lanl dot gov 2012-10-09 15:19:36 UTC --- Interesting. Didn't see this dup originally in my search. In response to your other email (that it is very very hard), can you explain a bit why if you've got the time/inclination? My first thought was that it would be a fairly simple pass through/reimplementation of the fpclassify functionality of c. Thanks, Andy Nelson On Oct 6, 2012, at 6:08 PM, kargl at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 kargl at gcc dot gnu.org changed: What|Removed |Added CC||andy.nelson at lanl dot gov --- Comment #7 from kargl at gcc dot gnu.org 2012-10-07 00:08:49 UTC --- *** Bug 54840 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug bootstrap/54876] New: [4.8 Regression] LTO bootstrap broken, streaming garbage-collected BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54876
Bug #: 54876
Summary: [4.8 Regression] LTO bootstrap broken, streaming
garbage-collected BLOCK
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: de...@gcc.gnu.org, jamb...@gcc.gnu.org
We are streaming a GCed TREE_BLOCK of
(gdb) p expr-base.code
$5 = MEM_REF
(gdb) p expr-base.code
$6 = ADDR_EXPR
from output_node_opt_summary here:
/* At the moment we assume all old trees to be PARM_DECLs, because we
have no
mechanism to store function local declarations into summaries. */
gcc_assert (parm);
streamer_write_uhwi (ob, parm_num);
gcc_assert (EXPR_LOCATION (map-new_tree) == UNKNOWN_LOCATION);
stream_write_tree (ob, map-new_tree, true);
we need to clear all TREE_BLOCKs from this. Not sure if new_tree originates
from a tree that eventually comes along prune_expression_for_jf, but
static tree
prune_expression_for_jf (tree exp)
{
if (EXPR_P (exp))
{
exp = unshare_expr (exp);
SET_EXPR_LOCATION (exp, UNKNOWN_LOCATION);
}
return exp;
}
is not enough. You need to walk_tree exp, as in this case it is MEM_REF
and all sub-expressions can contain a location.
[Bug bootstrap/54876] [4.8 Regression] LTO bootstrap broken, streaming garbage-collected BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54876
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-10-09
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-09
15:24:26 UTC ---
Like the following:
Index: gcc/ipa-prop.c
===
--- gcc/ipa-prop.c (revision 192255)
+++ gcc/ipa-prop.c (working copy)
@@ -287,6 +287,16 @@ ipa_print_all_jump_functions (FILE *f)
}
}
+/* Worker for prune_expression_for_jf. */
+
+static tree
+prune_expression_for_jf_1 (tree *tp, int *, void *)
+{
+ if (EXPR_P (*tp))
+SET_EXPR_LOCATION (*tp, UNKNOWN_LOCATION);
+ return *tp;
+}
+
/* Return the expression tree EXPR unshared and with location stripped off.
*/
static tree
@@ -295,7 +305,7 @@ prune_expression_for_jf (tree exp)
if (EXPR_P (exp))
{
exp = unshare_expr (exp);
- SET_EXPR_LOCATION (exp, UNKNOWN_LOCATION);
+ walk_tree (exp, prune_expression_for_jf_1, NULL, NULL);
}
return exp;
}
not sure if we shouldn't simply bite the bullet and identify whether we
stream to a non-function section and drop LOCATION_BLOCK there during
streaming itself.
Testing the above now.
[Bug bootstrap/54876] [4.8 Regression] LTO bootstrap broken, streaming garbage-collected BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54876
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-10-09
15:29:12 UTC ---
Err,
static tree
prune_expression_for_jf_1 (tree *tp, int *walk_subtrees, void *)
{
if (EXPR_P (*tp))
SET_EXPR_LOCATION (*tp, UNKNOWN_LOCATION);
else
*walk_subtrees = 0;
return NULL_TREE;
}
of course.
[Bug c++/51228] [4.6 Regression] ICE with transparent union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51228 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.0 Resolution||FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 15:52:41 UTC --- I propose to declare this fixed in 4.7.0. Otherwise please re-open, thanks.
[Bug tree-optimization/53397] Scimark performance drops by 10x times when compiled -O3 -march=amdfam10 due to generation more prefecthes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53397 Venkataramanan venkataramanan.kumar at amd dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Venkataramanan venkataramanan.kumar at amd dot com 2012-10-09 15:55:04 UTC --- Fixed. http://gcc.gnu.org/viewcvs?view=revisionrevision=192261
[Bug c++/53763] Missing error check on decltype when used within variadic template argument list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53763 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-09 16:01:06 UTC --- Let's add the testcase and close this as fixed for 4.8.0.
