Re: Enabling a function based on Language
Ian Lance Taylor wrote: Iyer, Balaji Vbalaji.v.i...@intel.com writes: Is there a #define in GCC that will turn on only for certain languages? I am trying to use build_array_ref but it is giving me a undefined reference for f951. This code that I am trying to use will ONLY execute if we have a C/C++ code. Is it possible for me to enclose this inside some #defines (or a combination of them)? By definition, no, there isn't. The middle-end is compiled once, into a library. Then each frontend is linked against that library. Calling a frontend function like build_array_ref from the middle-end is always a mistake. In the middle-end you should probably be making a POINTER_PLUS_EXPR node or something along those lines. Unless, of course, one goes the route which Richard once suggested: Adding array and scalarizer support to the middle end, http://gcc.gnu.org/wiki/GCCGathering2011Fortran#Scalarizer (See all three links; mistakes in the Wiki are mine, made when I tried to summarize/understand Richard's draft patches. The project got stalled as there was not enough developer time on the Fortran side and as the current approach works relatively well. ME support would be beneficial as it would allow for certain optimizations which are not possible in the front end.) Tobias
RE: A question about loop ivopt
-Original Message- From: Richard Guenther [mailto:richard.guent...@gmail.com] Sent: Tuesday, May 15, 2012 10:17 PM To: Zdenek Dvorak Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu Subject: Re: A question about loop ivopt On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak rakd...@iuuk.mff.cuni.cz wrote: Hi, Why can't we replace function force_expr_to_var_cost directly with function computation_cost in tree-ssa-loop-ivopt.c? Actually I think it is inaccurate for the current recursive algorithm in force_expr_to_var_cost to estimate expr cost. Instead computation_cost can count some back-end factors and make the estimation more accurate. For example, using computation_cost, we may check whether back-ends can tie some modes transformation expressed by SUBREG or not. If we use force_expr_to_var_cost, some more computations around type promotion/demotion would increase the cost estimated. Looking at the algorithm in force_expr_to_var_cost, it is just to analyze the operator in the expression and give estimation. Should it be the same as expanding EXPR to RTX and give estimation like in computation_cost? Any thoughts? I suppose Zdenek may remember. computation_cost actually expands the expression to RTL. Since cost estimates are computed a lot in ivopts, using it directly would require a huge amount of memory, Zdenek, Do you know how huge is it? Any data on this? For GCC, is this huge memory consumption is critical enough, and there aren't any other else consuming even more memory? no, not really (I haven't worked on this for a few years now), although of course I did some measurements when ivopts were created. Feel free to experiment with that, if it turned out that the memory consumption and extra time spent by it is negligible, it would be a nice cleanup. Well, I don't think we should feed arbitrary expressions to expand at IVOPTs time. What probably matters most is address costs, no? At least that is where expand probably makes the most difference. So why not improve force_expr_to_var_cost instead? OK, yes, the thing that matter most is just address cost, so I can improve force_expr_to_var_cost. Would it sound OK if I expose MODES_TIEABLE_P to middle-end by defining a new target hook? I need this function to strip some operations and make the cost estimate more accurate. If I don't expand to RTL, I would need a method to check the modes conversion in middle end, anyway. Any idea? Thanks, -Jiangning Richard. Zdenek
Re: A question about loop ivopt
On Tue, May 22, 2012 at 11:19 AM, Jiangning Liu jiangning@arm.com wrote: -Original Message- From: Richard Guenther [mailto:richard.guent...@gmail.com] Sent: Tuesday, May 15, 2012 10:17 PM To: Zdenek Dvorak Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu Subject: Re: A question about loop ivopt On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak rakd...@iuuk.mff.cuni.cz wrote: Hi, Why can't we replace function force_expr_to_var_cost directly with function computation_cost in tree-ssa-loop-ivopt.c? Actually I think it is inaccurate for the current recursive algorithm in force_expr_to_var_cost to estimate expr cost. Instead computation_cost can count some back-end factors and make the estimation more accurate. For example, using computation_cost, we may check whether back-ends can tie some modes transformation expressed by SUBREG or not. If we use force_expr_to_var_cost, some more computations around type promotion/demotion would increase the cost estimated. Looking at the algorithm in force_expr_to_var_cost, it is just to analyze the operator in the expression and give estimation. Should it be the same as expanding EXPR to RTX and give estimation like in computation_cost? Any thoughts? I suppose Zdenek may remember. computation_cost actually expands the expression to RTL. Since cost estimates are computed a lot in ivopts, using it directly would require a huge amount of memory, Zdenek, Do you know how huge is it? Any data on this? For GCC, is this huge memory consumption is critical enough, and there aren't any other else consuming even more memory? no, not really (I haven't worked on this for a few years now), although of course I did some measurements when ivopts were created. Feel free to experiment with that, if it turned out that the memory consumption and extra time spent by it is negligible, it would be a nice cleanup. Well, I don't think we should feed arbitrary expressions to expand at IVOPTs time. What probably matters most is address costs, no? At least that is where expand probably makes the most difference. So why not improve force_expr_to_var_cost instead? OK, yes, the thing that matter most is just address cost, so I can improve force_expr_to_var_cost. Would it sound OK if I expose MODES_TIEABLE_P to middle-end by defining a new target hook? I need this function to strip some operations and make the cost estimate more accurate. If I don't expand to RTL, I would need a method to check the modes conversion in middle end, anyway. Any idea? You are already in the middle-end and thus can use MODES_TIABLE_P directly. Modes are also available on gimple variables via DECL/TYPE_MODE. Richard. Thanks, -Jiangning Richard. Zdenek
C++98/C++11 ABI compatibility for gcc-4.7
I've put together the following description of C++98/11 ABI
(in)compatibility, so people can tell which libraries need to be
recompiled. This is useful when you've bought a library that didn't
come with source code, and you're trying to figure out if you need to
buy a new version. I think this belongs on the Wiki somewhere, but I
wanted to run it by the list first to make sure it's accurate. You can
probably skip the first section, since it's just a description of how
to use the subsequent list.
This page explains how to identify when your pre-compiled library (.a
or .so) defines a symbol that has a different enough definition in
C++98 vs C++11 that it could cause runtime problems if it's linked
into a program compiled for the other version.
First, get a list of demangled symbols from your .a or .so:
$ (find . -name '*.a'|xargs nm -f posix; find . -name '*.so' | xargs
nm -f posix -D)|cut -f1 -d' '|LANG=C sort -u|c++filt|sort
(There may be better ways to get this list.)
Next, find instances in this list of the ABI changes listed below.
For example, you might find:
std::_List_baseFooBar, std::allocatorFooBar ::_M_clear()
Since std::_List_base::_M_clear() destroys nodes, it's affected by the
addition of the _M_size field and can't be used by C++11 code if it
was compiled for C++98, or vice versa. If it's possible that code
outside the library would use this instance of _List_base, then you
have to recompile the library. On the other hand, if FooBar is a type
used only inside this library, then code using the library is safe.
If FooBar is defined by the library but exposed in one of the
library's headers, then the library still needs to be recompiled,
since code using it could wind up including the other version's
implementation.
=== ABI Changes ===
complex::{real,imag}(), std::{real,imag}(complex)
The non-const overloads go from returning _Tp to _Tp.
[Since gcc-4.4]
std::list, std::_List_impl, and std::_List_base
New _M_size member, meaning any method that adds or removes nodes or
inspects the size has a new ABI.
[Since gcc-4.7]
std::operator-(reverse_iterator) and std::operator-(__normal_iterator)
may return a different type if
reverse_iterator_IteratorL::difference_type (respectively,
__normal_iterator_IteratorL, _Container::difference_type) isn't
accurate.
[Since gcc-4.4]
map::erase(iterator), multimap::erase(iterator),
set::erase(const_iterator), set::erase(const_iterator,
const_iterator), multiset::erase(const_iterator),
multiset::erase(const_iterator, const_iterator):
Return type changes from void to iterator.
[Since gcc-4.5]
_Rb_treeT, T::erase(const_iterator), _Rb_treeT,
T::erase(const_iterator, const_iterator), _Rb_treeT,
pair::erase(iterator):
Return type changes from void to iterator. these are instantiated from
map and set.
[Since gcc-4.5]
vector::data()'s return type changes from pointer to _Tp*
This is a no-op with most allocators, but any allocator that defines a
non-default pointer typedef will be incompatible.
[Since gcc-4.6]
Probably safe: istreambuf_iterator::reference changes from _CharT to _CharT.
This could affect return types if they mention 'reference', but they
appear not to mention it when istreambuf_iterator is involved.
[Since gcc-4.7]
Probably safe: map::erase(iterator, iterator),
multimap::erase(iterator, iterator)
C++11 uses const_iterator, which doesn't collide. Other versions of
gcc are unlikely to have defined this overload in C++98 mode, and
C++11 is unlikely to have defined the iterator version.
[Since gcc-4.5]
Probably safe: Types with node allocators, like deque and tree
C++11 uses _M_get_Node_allocator().construct(node, ...), while C++98
uses get_allocator().construct(node-_M_value_field, ...). The node's
constructor forwards to the value_field's constructor, so this works
by default. Can this cause problems with some mix of C++98/C++11
allocator compilations?
I haven't analyzed the debug and profile headers.
I found these differences by grepping for GXX_EXPERIMENTAL_CXX0X
inside libstdc++, and examining each instance to see if there was an
#else clause that had different behavior in C++11 vs C++98.
=== ABI non-changes ===
libstdc++'s binary component is nearly ABI-compatible between C++98
and C++11. Most incompatibilities are in the templates defined in
headers, but the complex stream operators call the real() and imag()
methods that change return type. If these calls aren't inlined, (and
they're likely to be inlined), then libstdc++ (which is compiled in
C++98 mode by default) could cause problems when linked into C++11
programs. (http://gcc.gnu.org/PR53429)
There have been some claims that the change in the definition of POD
types causes an ABI incompatibility, but apparently it doesn't in
practice: http://gcc.gnu.org/ml/gcc/2012-01/msg00056.html.
RE: Enabling a function based on Language
Thanks Tobias, I am wanting to call this function right before we hit the gimplify_function_tree (), so I guess I am right before the middle-end... -Balaji V. Iyer. -Original Message- From: Tobias Burnus [mailto:bur...@net-b.de] Sent: Tuesday, May 22, 2012 3:25 AM Cc: i...@google.com; Iyer, Balaji V; 'gcc@gcc.gnu.org' Subject: Re: Enabling a function based on Language Ian Lance Taylor wrote: Iyer, Balaji Vbalaji.v.i...@intel.com writes: Is there a #define in GCC that will turn on only for certain languages? I am trying to use build_array_ref but it is giving me a undefined reference for f951. This code that I am trying to use will ONLY execute if we have a C/C++ code. Is it possible for me to enclose this inside some #defines (or a combination of them)? By definition, no, there isn't. The middle-end is compiled once, into a library. Then each frontend is linked against that library. Calling a frontend function like build_array_ref from the middle-end is always a mistake. In the middle-end you should probably be making a POINTER_PLUS_EXPR node or something along those lines. Unless, of course, one goes the route which Richard once suggested: Adding array and scalarizer support to the middle end, http://gcc.gnu.org/wiki/GCCGathering2011Fortran#Scalarizer (See all three links; mistakes in the Wiki are mine, made when I tried to summarize/understand Richard's draft patches. The project got stalled as there was not enough developer time on the Fortran side and as the current approach works relatively well. ME support would be beneficial as it would allow for certain optimizations which are not possible in the front end.) Tobias
Re: MULTILIB_OPTIONS and DRIVER_SELF_SPEC
On 21/05/12 15:21, Christian Bruel wrote: Options not explicitly described in the compiler before their use in a spec rules are now rejected. So you probably need to describe it into your target optimization file, (something like xap.opt). OK, thanks for letting me know about this. Cheers, -- PMatos
RE: A question about loop ivopt
-Original Message- From: Richard Guenther [mailto:richard.guent...@gmail.com] Sent: Tuesday, May 22, 2012 6:36 PM To: Jiangning Liu Cc: Zdenek Dvorak; Jiangning Liu; gcc@gcc.gnu.org Subject: Re: A question about loop ivopt On Tue, May 22, 2012 at 11:19 AM, Jiangning Liu jiangning@arm.com wrote: -Original Message- From: Richard Guenther [mailto:richard.guent...@gmail.com] Sent: Tuesday, May 15, 2012 10:17 PM To: Zdenek Dvorak Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu Subject: Re: A question about loop ivopt On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak rakd...@iuuk.mff.cuni.cz wrote: Hi, Why can't we replace function force_expr_to_var_cost directly with function computation_cost in tree-ssa-loop-ivopt.c? Actually I think it is inaccurate for the current recursive algorithm in force_expr_to_var_cost to estimate expr cost. Instead computation_cost can count some back-end factors and make the estimation more accurate. For example, using computation_cost, we may check whether back-ends can tie some modes transformation expressed by SUBREG or not. If we use force_expr_to_var_cost, some more computations around type promotion/demotion would increase the cost estimated. Looking at the algorithm in force_expr_to_var_cost, it is just to analyze the operator in the expression and give estimation. Should it be the same as expanding EXPR to RTX and give estimation like in computation_cost? Any thoughts? I suppose Zdenek may remember. computation_cost actually expands the expression to RTL. Since cost estimates are computed a lot in ivopts, using it directly would require a huge amount of memory, Zdenek, Do you know how huge is it? Any data on this? For GCC, is this huge memory consumption is critical enough, and there aren't any other else consuming even more memory? no, not really (I haven't worked on this for a few years now), although of course I did some measurements when ivopts were created. Feel free to experiment with that, if it turned out that the memory consumption and extra time spent by it is negligible, it would be a nice cleanup. Well, I don't think we should feed arbitrary expressions to expand at IVOPTs time. What probably matters most is address costs, no? At least that is where expand probably makes the most difference. So why not improve force_expr_to_var_cost instead? OK, yes, the thing that matter most is just address cost, so I can improve force_expr_to_var_cost. Would it sound OK if I expose MODES_TIEABLE_P to middle-end by defining a new target hook? I need this function to strip some operations and make the cost estimate more accurate. If I don't expand to RTL, I would need a method to check the modes conversion in middle end, anyway. Any idea? You are already in the middle-end and thus can use MODES_TIABLE_P directly. Modes are also available on gimple variables via DECL/TYPE_MODE. Richard, But MODES_TIEABLE_P is a macro hook and isn't exposed to TREE level, so I would have to modify xxx-protos.h for all back-ends. An alternative way is I define a new function hook. This way I needn't to change all back-ends, but support several back-ends required first. Which solution is usually preferred? Thanks, -Jiangning Richard. Thanks, -Jiangning Richard. Zdenek
Re: A question about loop ivopt
On Tue, May 22, 2012 at 8:04 PM, Jiangning Liu jiangning@arm.com wrote: Richard, But MODES_TIEABLE_P is a macro hook and isn't exposed to TREE level, so I would have to modify xxx-protos.h for all back-ends. As far as I can tell it is exposed already to the middle-end via that hook in that you should be able to use MODES_TIEABLE_P from tree-ssa-loop-ivopts.c without modifying anything else. It looks like the arm and i386 are have both broken xxx-protos.h. Both rs6000 and mips will work without touching their xxx-protos.h. I think it is better if you just fix the targets which have a broken xxx-protos.h. Thanks, Andrew Pinski An alternative way is I define a new function hook. This way I needn't to change all back-ends, but support several back-ends required first. Which solution is usually preferred? Thanks, -Jiangning Richard. Thanks, -Jiangning Richard. Zdenek
[Bug c++/53380] .ehframe could be smaller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-22 Ever Confirmed|0 |1
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.2 |4.7.1
[Bug bootstrap/49707] GCC sends incorrect flags to native IRIX ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49707 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:10:04 UTC --- IRIX 6.5 support was removed so closing as won't fix.
[Bug gcov-profile/53414] gcov does not generate 'Lines' record for final block of functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53414 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-22 Ever Confirmed|0 |1 Severity|major |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 05:59:35 UTC --- Can you provide a full testcase that is runnable? Also does this happen with newer versions of GCC?
[Bug c++/53350] Internal compiler error when compiling boost/smart_ptr/intrusive_ptr.hpp 1.49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53350 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:03:10 UTC --- Fixed as mentioned already.
[Bug bootstrap/49707] GCC sends incorrect flags to native IRIX ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49707 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-22 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:08:55 UTC --- How was irix-crti.o built from the GCC Log?
[Bug bootstrap/37308] bootstrap hangs in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37308 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:11:58 UTC --- No feedback in over 4 months so closing.
[Bug gcov-profile/53406] Unit Record not present in header files or in GCOV output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53406 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 05:57:23 UTC --- function == unit .
[Bug bootstrap/42666] xgcc: Internal error: segmentation violation (program cc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42666 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:12:42 UTC --- No feedback in over 3 months so closing.
[Bug bootstrap/51450] configure's test for -fno-rtti -fno-exceptions broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51450 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW
[Bug bootstrap/40650] gcc-4.5-20090702 won't build on OS X 10.5 with GMP/MPFR in-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40650 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:13:05 UTC --- No feedback in over 3 months so closing.
[Bug c++/53380] .ehframe could be smaller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:01:32 UTC --- Did -fno-asynchronous-unwind-tables do what you wanted it to do? In that disable the unwinding tables when not using exceptions?
[Bug bootstrap/50993] IRIX: fails to build in lto for sgi1.0 linker flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50993 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:09:42 UTC --- IRIX 6.5 support was removed so closing as won't fix.
[Bug bootstrap/49986] Compilation of cross GCC (Linux - AIX) fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49986 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-22 06:11:30 UTC --- No feed back in over 4 months so closing. Also IIRC binutils is not fully supported targeting AIX yet.
[Bug target/53447] New: missed optimization of 64bit ALU operation with small constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53447
Bug #: 53447
Summary: missed optimization of 64bit ALU operation with small
constant
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-unknown-linux-gnueabi
Compile the following code with options -march=armv7-a -O2 -mthumb
void t0p(long long *p)
{
*p += 1;
}
GCC 4.8 generates:
t0p:
ldrdr2, [r0]
push{r4, r5}
movsr4, #1 //A
addsr2, r2, r4 //B
movr5, #0 //C
adcr3, r3, r5 //D
strdr2, [r0]
pop{r4, r5}
bxlr
Instructions ABCD can be simplified as
adds r2, r2, 1
adcr3, r3, 0
This sequence is smaller and faster than original code, it uses two less
registers, so the push/pop instructions can also be removed.
Both arm/thumb mode and Os/O2 generates similar code.
This optimization can also be applied to other alu operations, such as
sub/and/or/xor/cmp.
[Bug tree-optimization/53436] Volatile behaves strange with OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53436 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 07:37:14 UTC --- The testcase is not valid OpenMP, there is no flush operation in between the store and reads, that said, there was a bug on the GCC side that I've fixed.
[Bug tree-optimization/53366] [4.7/4.8 Regression] wrong code generation by tree vectorizer using AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53366 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.1 Summary|wrong code generation by|[4.7/4.8 Regression] wrong |tree vectorizer using AVX |code generation by tree ||vectorizer using AVX --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 07:38:53 UTC --- Fixed.
[Bug tree-optimization/53410] [4.7/4.8 Regression] ICE in build_int_cst_wide, at tree.c:1219
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53410 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|c |tree-optimization Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 07:39:49 UTC --- Fixed.
[Bug middle-end/53409] [4.7/4.8 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:630
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53409 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 07:38:01 UTC --- Fixed.
[Bug tree-optimization/53436] Volatile behaves strange with OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53436 --- Comment #4 from o.mangold at googlemail dot com 2012-05-22 07:45:46 UTC --- (In reply to comment #3) The testcase is not valid OpenMP, there is no flush operation in between the store and reads, Is that also needed with volatile variables? Would be quite counterintuitive. that said, there was a bug on the GCC side that I've fixed. Great, thanks.
[Bug tree-optimization/53436] Volatile behaves strange with OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53436 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 07:59:01 UTC --- (In reply to comment #4) (In reply to comment #3) The testcase is not valid OpenMP, there is no flush operation in between the store and reads, Is that also needed with volatile variables? Would be quite counterintuitive. I believe so. Volatile only makes sure the compiler emits a store of the variable to memory, but the CPU can just store it into a cache. There is nothing that orders that store compared to other stores/loads. So, just use the appropriate OpenMP directives for synchronization, rather than bad attempts at busy waiting using volatile.
[Bug target/53192] Incorrect arguments to AVX2's gather intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192 Yukhin Kirill kirill.yukhin at intel dot com changed: What|Removed |Added CC||areg.melikadamyan at gmail ||dot com --- Comment #3 from Yukhin Kirill kirill.yukhin at intel dot com 2012-05-22 08:23:56 UTC --- (In reply to comment #1) Please provide a testcase to show the problem. I have no idea, which kind of test it should be. These is just MS-ICC-GCC incompatibility issue
[Bug target/53447] missed optimization of 64bit ALU operation with small constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53447 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-22 Ever Confirmed|0 |1
[Bug tree-optimization/53436] Volatile behaves strange with OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53436 --- Comment #6 from o.mangold at googlemail dot com 2012-05-22 08:32:03 UTC --- Yes, I get, that it's not a good way to do things, as (among other reasons) a volatile access is no memory fence. So accesses to other locations may not be ordered. But just for the sake of correctness, accesses should be ordered, if they all go to volatile variables, no? From the C99-standard, section 5.1.2.3: At sequence points, volatile objects are stable in the sense that previous accesses are complete and subsequent accesses have not yet occurred. This means buffering the reads to the volatile variable over multiple iterations of the while loop is not allowed, or do I get this wrong?
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22
08:29:08 UTC ---
The format string could be even something like
void f() {
__builtin_printf(
u8Rabcd(%.)abcd
*d);
}
So, the question is, if we have a way to find from the source_location on the
ADDR_EXPR around STRING_CST the original non-concatenated tokens, and given
index into the (possibly) translated STRING_CST redo the lexing of those
tokens, looking at which byte in the source tokens maps to that offset in the
STRING_CST.
[Bug target/53448] [avr] ignoring __attribute__((aligned(2)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53448 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-22 AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-22 08:39:51 UTC --- Created attachment 27474 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27474 C test case More test cases
[Bug target/53448] New: [avr] ignoring __attribute__((aligned(2)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53448 Bug #: 53448 Summary: [avr] ignoring __attribute__((aligned(2))) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org CC: eric.wedding...@atmel.com Target: avr int var __attribute__((aligned(2))) = 1; gets compiled to .globalvar .data .typevar, @object .sizevar, 2 var: .word1 i.e. the alignment directive .p2align 1 is missing.
[Bug c/52862] [4.5/4.6 Regression] ICE convert_to_pointer, at convert.c:50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.6.4 Resolution||FIXED Target Milestone|4.5.4 |4.6.4 Known to fail|4.6.4 |4.6.3 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:18:41 UTC --- Fixed for 4.6.4, I don't intend to backport this further.
[Bug target/53447] missed optimization of 64bit ALU operation with small constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53447
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-05-22
08:24:52 UTC ---
Confirmed.
Here is the assembler output with the -dAp -fdump-rtl-all-details options:
t0p:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ BLOCK 2 freq:1 seq:0
@ PRED: ENTRY [100.0%] (fallthru)
ldrdr2, [r0]@ 6*arm_movdi/4[length = 8]
push{r4, r5}@ 20*push_multi[length = 2]
movsr4, #1@ 16*thumb2_movsi_shortim[length = 2]
addsr2, r2, r4@ 18*addsi3_compare_op1/1[length = 4]
movr5, #0@ 17*thumb2_movsi_insn/2[length = 4]
adcr3, r3, r5@ 19*addsi3_carryin_ltu[length = 4]
strdr2, [r0]@ 9*arm_movdi/5[length = 8]
@ SUCC: EXIT [100.0%]
pop{r4, r5}
bxlr
The add is a DImode add up to the pr53447.c.195r.postreload dump:
(insn 6 3 13 2 (set (reg:DI 2 r2 [orig:137 D.4118 ] [137])
(mem:DI (reg/v/f:SI 0 r0 [orig:136 p ] [136]) [2 *p_1(D)+0 S8 A64]))
pr53447.c:3 182 {*arm_movdi}
(nil))
(insn 13 6 8 2 (set (reg:DI 4 r4 [139])
(const_int 1 [0x1])) pr53447.c:3 182 {*arm_movdi}
(expr_list:REG_EQUIV (const_int 1 [0x1])
(nil)))
(insn 8 13 9 2 (parallel [
(set (reg:DI 2 r2 [orig:137 D.4118 ] [137])
(plus:DI (reg:DI 2 r2 [orig:137 D.4118 ] [137])
(reg:DI 4 r4 [139])))
(clobber (reg:CC 24 cc))
]) pr53447.c:3 1 {*arm_adddi3}
(nil))
(insn 9 8 12 2 (set (mem:DI (reg/v/f:SI 0 r0 [orig:136 p ] [136]) [2 *p_1(D)+0
S8 A64])
(reg:DI 2 r2 [orig:137 D.4118 ] [137])) pr53447.c:3 182 {*arm_movdi}
(nil))
The add is split in the pr53447.c.197r.split2 dump:
(insn 6 3 16 2 (set (reg:DI 2 r2 [orig:137 D.4118 ] [137])
(mem:DI (reg/v/f:SI 0 r0 [orig:136 p ] [136]) [2 *p_1(D)+0 S8 A64]))
pr53447.c:3 182 {*arm_movdi}
(nil))
(insn 16 6 17 2 (set (reg:SI 4 r4 [139])
(const_int 1 [0x1])) pr53447.c:3 718 {*thumb2_movsi_insn}
(nil))
(insn 17 16 18 2 (set (reg:SI 5 r5 [+4 ])
(const_int 0 [0])) pr53447.c:3 718 {*thumb2_movsi_insn}
(nil))
(insn 18 17 19 2 (parallel [
(set (reg:CC_C 24 cc)
(compare:CC_C (plus:SI (reg:SI 2 r2 [orig:137 D.4118 ] [137])
(reg:SI 4 r4 [139]))
(reg:SI 2 r2 [orig:137 D.4118 ] [137])))
(set (reg:SI 2 r2 [orig:137 D.4118 ] [137])
(plus:SI (reg:SI 2 r2 [orig:137 D.4118 ] [137])
(reg:SI 4 r4 [139])))
]) pr53447.c:3 10 {*addsi3_compare_op1}
(nil))
(insn 19 18 9 2 (set (reg:SI 3 r3 [ D.4118+4 ])
(plus:SI (plus:SI (reg:SI 3 r3 [ D.4118+4 ])
(reg:SI 5 r5 [+4 ]))
(ltu:SI (reg:CC_C 24 cc)
(const_int 0 [0] pr53447.c:3 14 {*addsi3_carryin_ltu}
(nil))
(insn 9 19 12 2 (set (mem:DI (reg/v/f:SI 0 r0 [orig:136 p ] [136]) [2 *p_1(D)+0
S8 A64])
(reg:DI 2 r2 [orig:137 D.4118 ] [137])) pr53447.c:3 182 {*arm_movdi}
(nil))
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:03:53 UTC --- It should be a bitfield on both sides, otherwise the GIMPLE verifier would complain.
[Bug target/52407] [4.6 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:20:41 UTC --- Fixed.
[Bug c/52862] [4.5/4.6 Regression] ICE convert_to_pointer, at convert.c:50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:17:53 UTC --- Author: rguenth Date: Tue May 22 09:17:42 2012 New Revision: 187762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187762 Log: 2012-05-22 Richard Guenther rguent...@suse.de Backport from mainline 2012-04-12 Richard Guenther rguent...@suse.de PR c/52862 * convert.c (convert_to_pointer): Remove special-casing of zero. * gcc.dg/pr52862.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr52862.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/convert.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/51071] [4.7 Regression] ICE in gimple_has_side_effects, at gimple.c:2513
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51071 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:23:14 UTC --- Author: rguenth Date: Tue May 22 09:23:01 2012 New Revision: 187764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187764 Log: 2012-05-22 Richard Guenther rguent...@suse.de Backport from mainline 2011-11-10 Richard Guenther rguent...@suse.de PR middle-end/51071 * gimple.c (gimple_has_side_effects): Remove checking code that doesn't belong here. * gcc.dg/torture/pr51071.c: New testcase. * gcc.dg/torture/pr51071-2.c: Likewise. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr51071-2.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr51071.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/gimple.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug regression/52383] [4.6 Regression] miscompiles Perl on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2012-05-22 08:35:14 UTC --- (In reply to comment #4) Upgrading didn’t help, but in the meantime, I got it built. I blame ARAnyM, as it succeeds on a box I put Petr’s .deb on… so no wonder Andreas couldn’t reproduce it. FWIW, I've just built perl-5.12.4 with gcc-4.6.3 (+ patches) on ARAnyM (0.9.11) running a Linux 3.x kernel. It seems to work fine, and the make_patchnum.pl error you mentioned did not occur. IOW, I'm more inclined to suspect Debian's gcc-4.6 (at the time) than ARAnyM.
[Bug target/53334] [4.8 Regression] ICE in extract_insn, at recog.c:2131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-22 09:07:03 UTC --- Author: ramana Date: Tue May 22 09:06:55 2012 New Revision: 187761 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187761 Log: Fix PR target/53334 2012-05-22 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/53334 * config/arm/arm-protos.h (arm_validize_comparison): Declare. * config/arm/arm.c (arm_validize_comparison): Define. * config/arm/arm.md (cbranchsi4): Cleanup expansion and use arm_validize_comparison. (cbranchdi4): Likewise. (cstoredi4): Likewise. (movsicc): Likewise. (movsfcc): Likewise. (movdfcc): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md
[Bug middle-end/51071] [4.7 Regression] ICE in gimple_has_side_effects, at gimple.c:2513
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51071 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:28:44 UTC --- Author: rguenth Date: Tue May 22 09:28:38 2012 New Revision: 187765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187765 Log: 2012-05-22 Richard Guenther rguent...@suse.de PR middle-end/51071 * gcc.dg/torture/pr51071-2.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr51071-2.c Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/53437] [4.8 Regression] FAIL: gcc.dg/guality/inline-params.c -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53437 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:33:51 UTC --- Author: rguenth Date: Tue May 22 09:33:42 2012 New Revision: 187767 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187767 Log: 2012-05-22 Richard Guenther rguent...@suse.de PR middle-end/53437 * tree-inline.c (setup_one_parameter): Create a dummy init statement for unused parameters when not optimizing. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug middle-end/53437] [4.8 Regression] FAIL: gcc.dg/guality/inline-params.c -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53437 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:36:02 UTC --- Fixed.
[Bug tree-optimization/53336] [4.8 Regression] invalid types in nop conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53336 --- Comment #4 from Paolo Bonzini bonzini at gnu dot org 2012-05-22 08:32:07 UTC --- Author: bonzini Date: Tue May 22 08:31:52 2012 New Revision: 187759 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187759 Log: gcc: 2012-05-16 Paolo Bonzini bonz...@gnu.org PR tree-optimization/53336 * tree-cfg.c (verify_gimple_assign_unary): Allow conversion from non-integer integral types to offset type and vice versa. gcc/testsuite: 2012-05-16 Paolo Bonzini bonz...@gnu.org PR tree-optimization/53336 * g++.dg/torture/pr53336.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr53336.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug objc++/53441] [4.8 Regression] obj-c++.dg/ivar-invalid-type-1.mm ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53441 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-22 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:51:52 UTC --- Confirmed.
[Bug target/52407] [4.6 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:20:24 UTC --- Author: rguenth Date: Tue May 22 09:20:15 2012 New Revision: 187763 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187763 Log: 2012-05-22 Richard Guenther rguent...@suse.de Backport from mainline 2012-02-28 Richard Guenther rguent...@suse.de PR target/52407 * config/i386/i386.c (ix86_expand_vector_set): Fix element ordering for the VEC_CONCAT for two element vectors for V2SFmode, V2SImode and V2DImode. * gcc.dg/torture/pr52407.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr52407.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/i386.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/53192] Incorrect arguments to AVX2's gather intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192 --- Comment #2 from Yukhin Kirill kirill.yukhin at intel dot com 2012-05-22 08:22:12 UTC --- (In reply to comment #1) Please provide a testcase to show the problem. I have no idea, which kind of test it should be. These is just MS-ICC-GCC incompatibility issue
[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function resul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53389 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-22 10:10:55 UTC --- Author: burnus Date: Tue May 22 10:10:47 2012 New Revision: 187769 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187769 Log: 2012-05-22 Tobias Burnus bur...@net-b.de PR fortran/53389 * trans-array.c (gfc_add_loop_ss_code): Don't evaluate * expression, if ss-is_alloc_lhs is set. 2012-05-22 Tobias Burnus bur...@net-b.de PR fortran/53389 * gfortran.dg/realloc_on_assign_15.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug target/53448] [avr] ignoring __attribute__((aligned(2)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53448 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug middle-end/51071] [4.7 Regression] ICE in gimple_has_side_effects, at gimple.c:2513
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51071 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:24:10 UTC --- Backported with a new testcase.
[Bug tree-optimization/53426] [4.8 Regression] ICE:create_variable_info_for at ../../gcc-trunk/gcc/tree-ssa-structalias.c:5581
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:44:41 UTC --- (In reply to comment #4) Hum. IPA-PTA ... yeah ... :/ Mine I guess (note ipa-pta is experimental). Honza - we are trying to access the varinfo for _ZTIN5boost16exception_detail19error_info_injectorISt13runtime_errorEE which is mentioned in the initializer of _ZTVN5boost16exception_detail19error_info_injectorISt13runtime_errorEE but that variable, despite mentioned, does not have a varpool entry. Is that by design? Can we not look at the initializer of a decl via I suppose it is the case where _ZTVN5boost16exception_detail19error_info_injectorISt13runtime_errorEE is external but with constructor known. I recently fixed that on mainline by making those analyzed, too. So if this still reproduce on mainline, it is possible that you arrive to the constructor in some way that is not visible by varpool? I'm arriving at it by walking all of varpool via FOR_EACH_VARIABLE, reaching _ZTVN5boost16exception_detail19error_info_injectorISt13runtime_errorEE which is readonly addressable used public ignored external virtual BLK file /afs/cern.ch/cms/slc5_amd64_gcc470/external/boost/1.49.0/include/boost/exception/exception.hpp line 315 col 9 size integer_cst 0x75c07640 576 unit size integer_cst 0x75c07740 72 align 256 context record_type 0x75c70930 error_info_injector initial constructor 0x75c6f078 looking at its DECL_INITIAL which contains an address of _ZTIN5boost16exception_detail19error_info_injectorISt13runtime_errorEE which does not have a varpool entry and is readonly addressable used public ignored external weak BLK file /afs/cern.ch/cms/slc5_amd64_gcc470/external/boost/1.49.0/include/boost/exception/exception.hpp line 315 col 9 size integer_cst 0x75c07460 448 unit size integer_cst 0x75c074c0 56 align 256 initial error_mark 0x75ad4bb8 it's the pointer to the typeinfo struct, so I'm not sure we ever create varpool entries for that. I can of course simply guard the code doing struct varpool_node *vnode = varpool_get_node (decl); /* For escaped variables initialize them from nonlocal. */ if (!varpool_all_refs_explicit_p (vnode)) make_copy_constraint (vi, nonlocal_id); by changing it to if (!vnode || DECL_INITIAL (vnode) == error_mark_node || !varpool_all_refs_explicit_p (vnode)) make_copy_constraint (vi, nonlocal_id); also noting the special error_mark_node DECL_INITIAL (what's that coming from!?)
[Bug tree-optimization/53436] Volatile behaves strange with OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53436 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 10:01:11 UTC --- What GCC did was wrong. But your testcase is clearly invalid as per OpenMP 3.1, 1.4.1: Similarly, if at least one thread reads from a memory unit and at least one thread writes without synchronization to that same memory unit, including cases due to atomicity considerations as described above, then a data race occurs. If a data race occurs then the result of the program is unspecified.
[Bug middle-end/51071] [4.7 Regression] ICE in gimple_has_side_effects, at gimple.c:2513
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51071 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 09:35:40 UTC --- Author: rguenth Date: Tue May 22 09:35:32 2012 New Revision: 187768 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187768 Log: 2012-05-22 Richard Guenther rguent...@suse.de PR middle-end/51071 * gcc.dg/torture/pr51071-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr51071-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-22
09:54:29 UTC ---
(In reply to comment #3)
What does clang report for this:
#include stdio.h
void f() {
printf(
%.
*d);
}
?
/tmp/webcompile/_2090_0.c:5:2: warning: '.*' specified field precision is
missing a matching 'int' argument
*d);
~^~
1 warning generated.
They have an awesome online demo: http://llvm.org/demo/
[Bug bootstrap/53449] New: [4.8 regression] fortran fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53449 Bug #: 53449 Summary: [4.8 regression] fortran fails to build Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch with revision 187761 I now get an error while building fortran In file included from ../../gcc-trunk/gcc/fortran/trans-common.c:1310:0, from ./gt-fortran-trans-io.h:88, from :4794: ../../gcc-trunk/gcc/fortran/parse.c: In function 'gfc_parse_file': ../../gcc-trunk/gcc/fortran/parse.c:4603:60: error: 'errors_before' may be used uninitialized in this function [-Werror=maybe-uninitialized] gfc_dump_module (s.sym-name, errors_before == errors); ^ In file included from ../../gcc-trunk/gcc/fortran/trans-common.c:1310:0, from ./gt-fortran-trans-io.h:88, from :4794: ../../gcc-trunk/gcc/fortran/parse.c:4487:21: note: 'errors_before' was declared here int seen_program, errors_before, errors; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/innocent/ccixchHw.ltrans30.ltrans.o] Error 1 configuration that fails ../gcc-trunk/configure --prefix=/afs/cern.ch/user/i/innocent/w2 --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl --with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib configuration that succeeds ../gcc-trunk/configure --enable-languages=c,c++,fortran --disable-multilib --enable-gold=yes --disable-nls --enable-lto --with-mpc=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --with-gmp=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --with-mpfr=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --prefix=/afs/cern.ch/user/i/innocent/w3/gcc47slc5
[Bug bootstrap/53449] [4.8 regression] fortran fails to build with LTO bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53449 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|[4.8 regression] fortran|[4.8 regression] fortran |fails to build |fails to build with LTO ||bootstrap --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 10:25:13 UTC --- LTO bootstrap I suppose.
[Bug bootstrap/49707] GCC sends incorrect flags to native IRIX ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49707 --- Comment #3 from kais58 at sucs dot org 2012-05-22 10:33:03 UTC --- I should have updated this earlier, it turned out to be a problem with the standard ld in IRIX 6.5, using the updated one included with MIPSPro made it work without error.
[Bug middle-end/53408] [4.6/4.7 Regression] ICE in get_initial_def_for_induction, at tree-vect-loop.c:3222
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53408 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 10:46:25 UTC --- Author: rguenth Date: Tue May 22 10:46:21 2012 New Revision: 187770 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187770 Log: 2012-05-22 Richard Guenther rguent...@suse.de PR tree-optimization/53408 * tree-vect-loop.c (vectorizable_induction): Properly check the restriction that we cannot handle induction results from the inner loop outside of the outer loop. * gcc.dg/torture/pr53408.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53408.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-loop.c
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-05-22
Ever Confirmed|0 |1
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22
10:47:53 UTC ---
Confirmed. The following C testcase works correctly:
struct S { _Bool b : 1; char c : 7; };
void bar (struct S s)
{
if (s.c != 7)
abort ();
}
int foo (_Bool b)
{
struct S s;
s.c = 7;
s.b = b;
bar (s);
return s.c;
}
but for some reason your reduced testcase ends up producing a MEM_REF
instead of a component-ref to store b instead.
[Bug target/53440] [arm] generic thunk code fails for method which uses '...'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53440 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-22 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-22
10:55:49 UTC ---
(In reply to comment #5)
The format string could be even something like
void f() {
__builtin_printf(
u8Rabcd(%.)abcd
*d);
}
So, the question is, if we have a way to find from the source_location on the
ADDR_EXPR around STRING_CST the original non-concatenated tokens, and given
index into the (possibly) translated STRING_CST redo the lexing of those
tokens, looking at which byte in the source tokens maps to that offset in the
STRING_CST.
Is it possible to re-preprocess some tokens only? Do the line-maps keep track
of the locations of the tokens which make up a single string? If not, we would
need to create new source locations on-the-fly. Is this possible at all?
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-22
11:04:41 UTC ---
(In reply to comment #3)
What does clang report for this:
#include stdio.h
void f() {
printf(
%.
*d);
}
?
An even more interesting example is this:
#define FORMAT .*d
#include stdio.h
void f() {
printf(
%
FORMAT);
}
for which Clang prints:
/tmp/webcompile/_17428_0.c:6:1: warning: '.*' specified field precision is
missing a matching 'int' argument
FORMAT);
^
/tmp/webcompile/_17428_0.c:1:18: note: expanded from:
#define FORMAT .*d
^
1 warning generated.
So either one keeps track of all source locations of all interesting
characters within strings, which sounds infeasible. Or one needs to
re-preprocess the format string, creating new locations on-the-fly. Dodji, is
this possible?
[Bug target/53192] Incorrect arguments to AVX2's gather intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 11:18:50 UTC --- Can you explain how are the two incompatible? You mean you get a warning if you pass an address of int64_t to this intrinsic? Even if this weirdo __int64 is compatible with long rather than long long in LP64, both are layed out the same.
[Bug middle-end/53450] New: [4.8 Regression] ICE in compiling libiberty/cp-demangle.c with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53450 Bug #: 53450 Summary: [4.8 Regression] ICE in compiling libiberty/cp-demangle.c with -O2 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch compile: /home/data/newsoft/gcc-build/./gcc/xgcc -B/home/data/newsoft/gcc-build/./gcc/ -B/afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/bin/ -B/afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/lib/ -isystem /afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/include -isystem /afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.. -I/home/data/newsoft/gcc-trunk/libstdc++-v3/../libiberty -I/home/data/newsoft/gcc-trunk/libstdc++-v3/../include -I/home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/data/newsoft/gcc-trunk/libstdc++-v3/libsupc++ -g -O2 -ftree-vectorize -fPIC -DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c -fPIC -DPIC -o cp-demangle.o In file included from /usr/include/string.h:637:0, from cp-demangle.c:112: cp-demangle.c: In function 'd_print_comp.part.9': cp-demangle.c:3933:16: internal compiler error: in int_mode_for_mode, at stor-layout.c:424 strncmp (dcl-u.s_name.s, JArray, 6) == 0) ^ cd /home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++ [innocent@vinavx0 libsupc++]$ /home/data/newsoft/gcc-build/./gcc/xgcc -B/home/data/newsoft/gcc-build/./gcc/ -B/afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/bin/ -B/afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/lib/ -isystem /afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/include -isystem /afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.. -I/home/data/newsoft/gcc-trunk/libstdc++-v3/../libiberty -I/home/data/newsoft/gcc-trunk/libstdc++-v3/../include -I/home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/data/newsoft/gcc-trunk/libstdc++-v3/ -g -ftree-vectorize -fPIC -DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c -fPIC -DPIC -o cp-demangle.o succeds…
[Bug plugins/41757] Add PLUGIN_FINISH_DECL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757 pageexec at freemail dot hu changed: What|Removed |Added CC||pageexec at freemail dot hu --- Comment #5 from pageexec at freemail dot hu 2012-05-22 11:49:47 UTC --- this feature seems to have been implemented already in gcc 4.7.x, can it be backported to 4.5.x and 4.6.x perhaps? it would make life easier for plugin writers who would like to provide the same features for all the plugin capable gcc series.
[Bug c++/53380] .ehframe could be smaller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380
--- Comment #3 from msharov at users dot sourceforge.net 2012-05-22 11:21:41
UTC ---
Did -fno-asynchronous-unwind-tables do what you wanted it to do? In that
disable the unwinding tables when not using exceptions?
No, it did not. For example:
#include stdio.h
int calculate (int x, int y) { return (x * y); }
void print (void) { printf (%d, calculate(1,2)); }
int main (void) { print(); return (0); }
g++ -Os -c -fno-asynchronous-unwind-tables -o tes.o tes.cc
readelf --debug-dump=frames tes.o
Contents of the .eh_frame section:
0014 CIE
Version: 1
Augmentation: zR
Code alignment factor: 1
Data alignment factor: -8
Return address column: 16
Augmentation data: 1b
DW_CFA_def_cfa: r7 (rsp) ofs 8
DW_CFA_offset: r16 (rip) at cfa-8
DW_CFA_nop
DW_CFA_nop
0018 0010 001c FDE cie= pc=..0006
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
002c 0010 0030 FDE cie= pc=0006..0017
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
0040 0014 0044 FDE cie= pc=..000a
DW_CFA_advance_loc: 1 to 0001
DW_CFA_def_cfa_offset: 16
DW_CFA_advance_loc: 8 to 0009
DW_CFA_def_cfa_offset: 8
DW_CFA_nop
As you can see, all three functions still have unwind entries emitted.
According to documentation I saw on the web, -fno-asynchronous-unwind-tables
increases unwind information granularity to function-level, meaning that it
supposedly avoids stepping cfa unless there is a function call there. While I
don't regularly read the unwind tables, I was under impression that this was
happening by default.
[Bug target/53192] Incorrect arguments to AVX2's gather intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22
11:52:12 UTC ---
BTW, to avoid that warning, you could use in C:
extern __inline __m128i
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm_i32gather_epi64 (
#ifdef __cplusplus
long long int const *base,
#else
union __attribute__((__transparent_union__)) { long long
int const *__ll; long int const *__l; } base,
#endif
__m128i index, const int scale)
and for C++ add another overload (of course, for _LP64 only).
[Bug c++/53451] New: [4.8 regression] ICE verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53451
Bug #: 53451
Summary: [4.8 regression] ICE verify_gimple failed
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
requires boost
(p.s. last working version of 4.8 for what I'm concerned is revision 187326)
cat ice2205.cc
#include vector
#include algorithm
#include boost/bind/bind.hpp
struct A {
int i;
};
bool foo(std::vectorA const va, int q) {
auto it = std::find_if(va.begin(), va.end(), boost::bind(A::i, _1) == q);
return it != va.end();
}
[vocms123] ~/public/ctest/bugs48 $ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --enable-languages=c,c++,fortran
--disable-multilib --enable-gold=yes --disable-nls --enable-lto
--with-mpc=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0
--with-gmp=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0
--with-mpfr=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0
--prefix=/afs/cern.ch/user/i/innocent/w3/gcc47slc5
--with-build-time-tools=/build/ge/new-binutils/a/slc5_amd64_gcc470/external/gcc/4.7.0-cms/bin
Thread model: posix
gcc version 4.8.0 20120522 (experimental) [trunk revision 187760] (GCC)
[vocms123] ~/public/ctest/bugs48 $ c++ -std=c++11 -c ice2205.cc
-I/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include
In file included from
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/mem_fn.hpp:22:0,
from
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/bind/bind.hpp:26,
from ice2205.cc:3:
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/bind/mem_fn.hpp:
In member function 'const R boost::_mfi::dmR, T::operator()(const T) const
[with R = int; T = A]':
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/bind/mem_fn.hpp:362:15:
error: invalid types in nop conversion
R const operator()(T const t) const
^
sizetype
Unknown tree: offset_type
D.66000 = (sizetype) D.65999;
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/bind/mem_fn.hpp:362:15:
internal compiler error: verify_gimple failed
[Bug regression/52383] [4.6 Regression] miscompiles Perl on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 --- Comment #6 from Thorsten Glaser tg at mirbsd dot org 2012-05-22 12:17:36 UTC --- Hm, I was pretty sure I tracked it down to aranym. But anyway, it’s gone.
[Bug tree-optimization/53426] [4.8 Regression] ICE:create_variable_info_for at ../../gcc-trunk/gcc/tree-ssa-structalias.c:5581
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz 2012-05-22 12:19:55 UTC --- by changing it to if (!vnode || DECL_INITIAL (vnode) == error_mark_node || !varpool_all_refs_explicit_p (vnode)) make_copy_constraint (vi, nonlocal_id); also noting the special error_mark_node DECL_INITIAL (what's that coming from!?) DECL_INITIAL is replaced by error mark when the variable is removed from varpool (so we know it is no longer going to be referenced or emit in some way) to conserve memory. Other case is the partitioning, when the variable is in the other partition and thus there is no need to sream the DECL_INITIAL (we stream DECL_INITIAL for variables from other partitions only when we think it may be useful for constant folding: that is variables passes const_value_known_p). This is probably the case here. If you only need to collect all things that escape, you can safely ignore DECL_INITIAL of DECLs with in_ohter_partition set: all vars that are in current partition referenced by the constructor from other partition used_from_other_partition set anyway, so they won't pass varpool_all_refs_explicit_p. You only need to worry about local constructors. Honza
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22
11:07:15 UTC ---
I think the following should fix it:
Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c (revision 187767)
+++ gcc/tree-sra.c (working copy)
@@ -1001,9 +1001,10 @@ build_access_from_expr_1 (tree expr, gim
@@ -2096,9 +2097,12 @@ analyze_access_subtree (struct access *r
(TREE_CODE (root-type) != INTEGER_TYPE
|| TYPE_PRECISION (root-type) != root-size)
/* But leave bitfield accesses alone. */
- (root-offset % BITS_PER_UNIT) == 0)
+ (TREE_CODE (root-expr) != COMPONENT_REF
+ || !DECL_BIT_FIELD (TREE_OPERAND (root-expr, 1
{
tree rt = root-type;
+ gcc_assert ((root-offset % BITS_PER_UNIT) == 0
+ (root-size % BITS_PER_UNIT) == 0);
root-type = build_nonstandard_integer_type (root-size,
TYPE_UNSIGNED (rt));
root-expr = build_ref_for_offset (UNKNOWN_LOCATION,
can you verify that, thus give it a bootstrap regtest run?
[Bug middle-end/53408] [4.6 Regression] ICE in get_initial_def_for_induction, at tree-vect-loop.c:3222
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53408 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.1 Summary|[4.6/4.7 Regression] ICE in |[4.6 Regression] ICE in |get_initial_def_for_inducti |get_initial_def_for_inducti |on, at |on, at |tree-vect-loop.c:3222 |tree-vect-loop.c:3222 Known to fail||4.7.0 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 12:01:48 UTC --- And for 4.7.1.
[Bug tree-optimization/53426] [4.8 Regression] ICE:create_variable_info_for at ../../gcc-trunk/gcc/tree-ssa-structalias.c:5581
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 12:47:04 UTC --- (In reply to comment #6) by changing it to if (!vnode || DECL_INITIAL (vnode) == error_mark_node || !varpool_all_refs_explicit_p (vnode)) make_copy_constraint (vi, nonlocal_id); also noting the special error_mark_node DECL_INITIAL (what's that coming from!?) DECL_INITIAL is replaced by error mark when the variable is removed from varpool (so we know it is no longer going to be referenced or emit in some way) to conserve memory. Other case is the partitioning, when the variable is in the other partition and thus there is no need to sream the DECL_INITIAL (we stream DECL_INITIAL for variables from other partitions only when we think it may be useful for constant folding: that is variables passes const_value_known_p). This is probably the case here. If you only need to collect all things that escape, you can safely ignore DECL_INITIAL of DECLs with in_ohter_partition set: all vars that are in current partition referenced by the constructor from other partition used_from_other_partition set anyway, so they won't pass varpool_all_refs_explicit_p. You only need to worry about local constructors. But I have a variable that fulfills varpool_all_refs_explicit_p but still its DECL_INITIAL contains X where I have no varpool node for X for. So if I constant fold from it I can get an explicit reference to a global variable X that has no varpool node assigned. How can that be ok?
[Bug c++/53451] [4.8 regression] ICE verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53451 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 12:47:37 UTC --- I think I fixed that with 2012-05-22 Richard Guenther rguent...@suse.de * tree-cfg.c (verify_gimple_assign_unary): Fix typo in previous commit.
[Bug middle-end/53450] [4.8 Regression] ICE in compiling libiberty/cp-demangle.c with -O2 in int_mode_for_mode, at stor-layout.c:424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53450 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-22 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 12:50:17 UTC --- You have -ftree-vectorize enabled ... quickly trying with -O2 -ftree-vectrize on cp-demangle.c works for me (and ISTR the int_mode_for_mode ICE ...). Can you attach preprocessed source? Or try again?
[Bug middle-end/53450] [4.8 Regression] ICE in compiling libiberty/cp-demangle.c with -O2 in int_mode_for_mode, at stor-layout.c:424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53450 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-05-22 12:53:40 UTC --- Most likely a dup of Bug 53433.
[Bug tree-optimization/53426] [4.8 Regression] ICE:create_variable_info_for at ../../gcc-trunk/gcc/tree-ssa-structalias.c:5581
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426 --- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2012-05-22 12:53:43 UTC --- But I have a variable that fulfills varpool_all_refs_explicit_p but still its DECL_INITIAL contains X where I have no varpool node for X for. So if I constant fold from it I can get an explicit reference to a global variable X that has no varpool node assigned. How can that be ok? We bring the references only for vars that pass const_value_known_p, but from what you quote it looks like it should pass the check. I am now tracking memory corruption in other PR, so i will look into this next.
[Bug c++/53380] .ehframe could be smaller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 12:55:30 UTC --- Adding default handling if there is no FDE is an ABI change, so can't be done on existing architectures (except those that have that in their ABI already). Why do you care about the .eh_frame size so much? If you don't use the unwind info, it often won't be even paged in, or can be discarded from RAM if needed. And if you need it, it better be accurrate.
[Bug libstdc++/53429] libstdc++ should guarantee not to expose complex::{imag,real} so it supports both C++98 and C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53429
Jeffrey Yasskin jyasskin at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed||2012-05-22
CC||gdr at gcc dot gnu.org
Resolution|INVALID |
Summary|complex::{imag,real} should |libstdc++ should guarantee
|be marked alwaysinline to |not to expose
|guarantee libstdc++ binary |complex::{imag,real} so it
|compatibility between C++98 |supports both C++98 and
|and C++11 |C++11
Ever Confirmed|0 |1
--- Comment #5 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-05-22
12:58:14 UTC ---
Specializing operator sounds fine too. Adding Gaby for his opinion, and
reopening since I'm not sure Richard understood the request.
[Bug c/53452] New: large array problem x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53452
Bug #: 53452
Summary: large array problem x86_64
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: peter.faa...@nlr.nl
Created attachment 27475
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27475
per-request, the .i file, command-line file will follow
The following very simple program:
int main(int argc, char *argv[])
{
//
int ttt[1073741824];// fails -- segmentation fault
//int ttt[1048576];// ok
//
return 0;
//
}
segfaults when an array of 1Gig ints is declared.
In gdb that shows up as:
(gdb) b main
Breakpoint 1 at 0x4004d0: file test.c, line 7.
(gdb) r
Starting program: /home/prf/z08/ALL/DSC/test/test
Program received signal SIGSEGV, Segmentation fault.
0x004004bc in main (argc=Cannot access memory at address 0xfffec99c
) at test.c:2
2 {
[Bug c/53452] large array problem x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53452 --- Comment #1 from Peter Faasse peter.faasse at nlr dot nl 2012-05-22 13:03:59 UTC --- Created attachment 27476 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27476 gcc -v etcetera version of gcc Distribution is Slackware-64 13.37
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #6 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-22 13:06:58 UTC --- *** Bug 53450 has been marked as a duplicate of this bug. ***
[Bug middle-end/53450] [4.8 Regression] ICE in compiling libiberty/cp-demangle.c with -O2 in int_mode_for_mode, at stor-layout.c:424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53450 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #3 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-22 13:06:58 UTC --- *** This bug has been marked as a duplicate of bug 53433 ***
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438 --- Comment #7 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-05-22 13:13:04 UTC --- Yep, I'll check it out. Thanks, Richard!
[Bug c++/53451] [4.8 regression] ICE verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53451 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-22 13:18:32 UTC --- indeed. ok with trunk revision 187772
[Bug middle-end/53161] [4.8 Regression] ICE with weakref function and a function which takes vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-22 13:20:19 UTC --- OK, this problem is caused by C++ FE corrupting symbol table by creating new symbol from DECL_ASSEMBLER_NAME langhook while creating another symbol. There has to be better ways to produce those aliases than from here... I am testing fix. Honza
[Bug debug/53453] New: darwin linker expects both AT_name and AT_comp_dir debug notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453 Bug #: 53453 Summary: darwin linker expects both AT_name and AT_comp_dir debug notes Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu Future versions of dsymutil on darwin will emit warnings of the form... warning: no debug symbols in executable (-arch x86_64) warning: no debug symbols in executable (-arch i386) when the debug note for AT_comp_dir is missing from linked object files. Upstream had the following comments... The issue is not directly dsymutil. The way it works on darwin, is that the linker does not copy dwarf debug info. Instead, the linker leaves the debug info in the .o files and then puts debug notes into the final linked image. If you run the program under gdb, the debugger sees the notes and opens the .of files and reads the dwarf. If instead you run dysmtuil, it reads the debug notes which tells it where to find the .o files from which to read the dwarf and merge all the dwarf into the .dSYM. The dsymtuil warning is that no dwarf was found. In this case that is because there were no debug notes recorded by the linker which was because of the lack of AT_comp_dir. In some of the cases you've set up, there was no warning because there was some dwarf found but not all dwarf was found, so the .dSYM is less than ideal. The format of the debug notes requires a pair of dir/file. Because it always just worked before, the linker just copied the dir from AT_comp_dir and the file from AT_name. It does not look like the dwarf spec requires the AT_comp_dir, but it has always been there before and the linker has come to depend on it. - This issue can be demonstrated with Xcode 4.2 under 10.7.4 using gcc trunk... howarth% gcc-fsf-4.8 /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120520/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120520/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120520/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -fno-diagnostics-show-caret --save-temps -w -O3 -g -lm -m64 -o 20010124-1.x4 howarth% dwarfdump --debug-info main.o | grep -A3 AT_language AT_language( DW_LANG_C89 ) AT_name( /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120520/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c ) AT_stmt_list( 0x ) whereas if you copy or symlink the source files into a local directory and compile with... howarth% gcc-fsf-4.8 20010124-1.c 20010124-1-lib.c main.c -fno-diagnostics-show-caret --save-temps -w -O3 -g -lm -m64 -o 20010124-1.x4 ...both the AT_name and AT_comp_dir debug notes are present... howarth% dwarfdump --debug-info main.o | grep -A3 AT_language AT_language( DW_LANG_C89 ) AT_name( main.c ) AT_comp_dir( /Users/howarth/xcode44_bugv2/good_binary ) AT_stmt_list( 0x ) and future dsymutil releases won't emit the warning.
[Bug c/53452] large array problem x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53452 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22 13:27:16 UTC --- Increase your stack limit - 'ulimit -s unlimited' is your friend.
[Bug tree-optimization/53426] [4.8 Regression] ICE:create_variable_info_for at ../../gcc-trunk/gcc/tree-ssa-structalias.c:5581
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426
--- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-22
13:31:28 UTC ---
OK,
I see the following:
6882 FOR_EACH_VARIABLE (var)
6883{
6884 if (var-alias)
6885continue;
6886
6887 get_vi_for_tree (var-symbol.decl);
6888}
(gdb) p dump_varpool_node (stderr, var)
_ZTVN5boost16exception_detail19error_info_injectorISt13runtime_errorEE.local.230/1658
(_ZTVN5boost16exception_detail19error_info_injectorISt13runtime_errorEE)
@0x775f1e88
Type: variable
Visibility: in_other_partition used_from_other_partition
prevailing_def_ironly external public visibility_specified visibility:hidden
virtual artificial
References:
Referring:
_ZNK5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEE5cloneEv.local.151/2414
(addr)_ZNK5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEE5cloneEv.local.151/2414
(addr)
Availability: overwritable
Varpool flags: initialized finalized
this var won't pass varpool_all_refs_explicit: it is from other partition and
used from elsewhere.
Partitioning should have put the variables referred by this constructor into a
boundary and it is not doing it - I will fix that.
(it gets that right at my internal symbol table tree)
On the other hand, is ipa-pta able to take advantage of fact that the variable
is readonly? I would propose:
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 187695)
+++ tree-ssa-structalias.c (working copy)
@@ -5583,7 +5583,8 @@ create_variable_info_for (tree decl, con
/* If this is a global variable with an initializer and we are in
IPA mode generate constraints for it. */
- if (DECL_INITIAL (decl))
+ if (DECL_INITIAL (decl)
+ vnode-analyzed)
{
VEC (ce_s, heap) *rhsc = NULL;
struct constraint_expr lhs, *rhsp;
I.e. to care only about constructors of vars from current partition.
This function does not check varpool_all_refs_explicit as you suggested in
previous comment.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-22 13:42:17 UTC --- mine is a one-year-old libc GNU C Library stable release version 2.13, by Roland McGrath et al. …. Compiled by GNU CC version 4.6.1 20110520 (prerelease). Compiled on a Linux 2.6.32 system on 2011-05-30.
[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2012-05-22 13:33:01 UTC --- It looks like the lines... if (!IS_ABSOLUTE_PATH (filename) filename[0] != '') add_comp_dir_attribute (die); in gen_compile_unit_die() of dwarf2out.c need adjusted for darwin to insure that add_comp_dir_attribute (die) is always called.
[Bug debug/49167] dwarf marker for function return instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49167 --- Comment #3 from Frank Ch. Eigler fche at redhat dot com 2012-05-22 14:30:35 UTC --- test comment
[Bug tree-optimization/53426] [4.8 Regression] ICE:create_variable_info_for at ../../gcc-trunk/gcc/tree-ssa-structalias.c:5581
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-22
13:52:49 UTC ---
(In reply to comment #9)
OK,
I see the following:
6882 FOR_EACH_VARIABLE (var)
6883{
6884 if (var-alias)
6885continue;
6886
6887 get_vi_for_tree (var-symbol.decl);
6888}
(gdb) p dump_varpool_node (stderr, var)
_ZTVN5boost16exception_detail19error_info_injectorISt13runtime_errorEE.local.230/1658
(_ZTVN5boost16exception_detail19error_info_injectorISt13runtime_errorEE)
@0x775f1e88
Type: variable
Visibility: in_other_partition used_from_other_partition
prevailing_def_ironly external public visibility_specified visibility:hidden
virtual artificial
References:
Referring:
_ZNK5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEE5cloneEv.local.151/2414
(addr)_ZNK5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEE5cloneEv.local.151/2414
(addr)
Availability: overwritable
Varpool flags: initialized finalized
this var won't pass varpool_all_refs_explicit: it is from other partition and
used from elsewhere.
Partitioning should have put the variables referred by this constructor into a
boundary and it is not doing it - I will fix that.
(it gets that right at my internal symbol table tree)
On the other hand, is ipa-pta able to take advantage of fact that the variable
is readonly? I would propose:
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 187695)
+++ tree-ssa-structalias.c (working copy)
@@ -5583,7 +5583,8 @@ create_variable_info_for (tree decl, con
/* If this is a global variable with an initializer and we are in
IPA mode generate constraints for it. */
- if (DECL_INITIAL (decl))
+ if (DECL_INITIAL (decl)
+ vnode-analyzed)
{
VEC (ce_s, heap) *rhsc = NULL;
struct constraint_expr lhs, *rhsp;
I.e. to care only about constructors of vars from current partition.
This function does not check varpool_all_refs_explicit as you suggested in
previous comment.
Ok, this fixes it. You explained DECL_INITIAL of a !vnode-analyzed can
never refer to a varpool_all_refs_explicit_p () decl.
[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-22 14:39:29 UTC --- There is no point to emit DW_AT_comp_dir if all filenames in the file/directory table referenced by DW_AT_stmt_list are absolute. Seems to be a request to work around broken vendor tools again.
[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453
--- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2012-05-22
13:58:13 UTC ---
(In reply to comment #1)
It looks like the lines...
if (!IS_ABSOLUTE_PATH (filename) filename[0] != '')
add_comp_dir_attribute (die);
in gen_compile_unit_die() of dwarf2out.c need adjusted for darwin to
insure that add_comp_dir_attribute (die) is always called.
I notice later in dwarf2out_finish() of dwarf2out.c that we have...
if (!IS_ABSOLUTE_PATH (filename))
add_comp_dir_attribute (comp_unit_die ());
else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
{
bool p = false;
htab_traverse (file_table, file_table_relative_p, p);
if (p)
add_comp_dir_attribute (comp_unit_die ());
}
perhaps gen_compile_unit_die() needs a similar else statement?
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-22 14:16:34 UTC --- There are still a few vmov's between Vector registers but I suspect that is because of the vcombine at the end for which RichardE might have something in flight. This is probably not true and needs some more investigation.
[Bug c++/53446] Template function incorrectly rejected when convertible argument is provided for a parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53446 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #6 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-05-22 13:57:07 UTC --- (In reply to comment #5) I think this is just a dup of bug 52072. I agree.
