[Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 Bug #: 52428 Summary: [RFC] I/O: READING of "-huge()-1": Integer overflow Classification: Unclassified Product: gcc Version: unknown URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65825 1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org As reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658251 For I/O, reading an integer with value -huge()-1 gives an overflow error. While that is acceptable based on the Fortran numerical model (cf. Fortran 2008, "13.4 Numeric models"), where the valid integer numbers stretch from -huge() to huge(), it is rather irritating that one can write (WRITE, PRINT) those numbers but not READ them back in. Except for Fortran's numerical model, the number looks valid to me as the sign belongs to the number and is not an unary operator applied afterwards. For integer I/O, one reads a "signed-digit-string" (R409). For the source code, something similar applies: Also there, one does *not* have an unary minus operator applied to the positive string literal but: R406 signed-int-literal-constant is [ sign ] int-literal-constant Only Fortran's numerical model is violated. Contrary to I/O, a error is printed, which can be overruled using -fno-range-check (and that flag is often but not always mentioned). EXPECTED: Be more generous at run time and allow this number for integer input.
[Bug fortran/52386] [4.6/4.7 Regression] ICE in gfc_conv_descriptor_dtyp (realloc LHS related)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52386 --- Comment #2 from Paul Thomas 2012-02-29 07:21:43 UTC --- Author: pault Date: Wed Feb 29 07:21:38 2012 New Revision: 184651 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184651 Log: 2012-02-29 Paul Thomas PR fortran/52386 * trans-expr.c (fcncall_realloc_result): Dereference the descriptor if needed. 2012-02-29 Paul Thomas PR fortran/52386 * gfortran.dg/realloc_on_assign_13.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52427] New: problem with default copy constructor and -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52427 Bug #: 52427 Summary: problem with default copy constructor and -O Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: architect...@hotmail.com Created attachment 26777 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26777 program with unexpected output The attached program prints > 181 > 181 as expected when compiled with "g++-4.6.2 --std=c++0x -o bin/main src/main.cc" (or g++-4.5.3) but > 121 > 181 with any -O option, and even > 17 > 181 with 4.5.3 with -O. Replacing the default copy constructor of foo_iterator with a user-defined constructor that should do the same thing (as in comment in source) fixes the problem, as does compiling with -fno-elide-constructors. Also, as the testcase shows, the problem arises with > sum += *fi++; but not with > sum += *fi; > ++fi; even though the postfix increment is defined in the usual way; therefore, the problem seems to lie in the temporary produced by operator++(int). A GDB session suggested that the optimized-away default copy constructor may be setting k to 0; that is, k=0 when operator*() is called on the temporary at '*fi++'; this is consistent with the output. (And moving the "dereference" inside operator++(int) so that it returns ulong does the same thing.)
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #28 from Jack Howarth 2012-02-29 03:53:50 UTC --- Fixed at r184555.
[Bug tree-optimization/52424] dom prematurely pops entries from const_and_copies stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52424 --- Comment #2 from Jiangning Liu 2012-02-29 03:42:17 UTC --- > Jiangning Liu reported that the following C code has recently experienced > degraded performance on trunk. (Jiangning, please fill in the > Host/Target/Build fields for your configuration, or tell me what they are if > you don't have access. The problem is not related to specific targets in any > event.) > Seems I don't have access. Host: arm*-*-* Target: arm*-*-* Build: arm*-*-*
[Bug tree-optimization/52424] dom prematurely pops entries from const_and_copies stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52424 --- Comment #1 from Jiangning Liu 2012-02-29 03:23:46 UTC --- > I've attached a proposed fix. Jiangning, can you please apply this and see if > your performance problem is resolved? Bill, Confirmed, I think your patch works for my big case and I do see the redundant copies are removed from final binary code. Benchmark performance boosts accordingly as well, although there still might be other potential problems. Thanks a lot for your quick patch. And are you going to check-in to trunk soon for 4.7? It would be also better if you can add a test case. -Jiangning
[Bug target/52408] Incorrect assembler generated for zvdep_imm64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52408 --- Comment #1 from dave.anglin at bell dot net 2012-02-29 01:44:09 UTC --- Attached is patch which I am testing. -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/52298] ICE: verify_ssa failed: definition in block follows use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52298 --- Comment #8 from Ulrich Weigand 2012-02-28 23:40:37 UTC --- Author: uweigand Date: Tue Feb 28 23:40:32 2012 New Revision: 184645 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184645 Log: Partially revert: 2012-02-20 Richard Guenther PR tree-optimization/52298 * tree-vect-stmts.c (vectorizable_load): Properly use STMT_VINFO_DR_STEP instead of DR_STEP when vectorizing outer loops. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug c++/52422] [C++11][SFINAE] Hard errors with void or arithmetic expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52422 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 --- Comment #2 from Paolo Carlini 2012-02-28 23:18:42 UTC --- As expected pretty straightforward, essentially matter of propagating complain to decay_conversion and build_m_component_ref.
[Bug fortran/52426] ICE for c_loc with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52426
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus 2012-02-28
23:13:40 UTC ---
(In reply to comment #0)
> Reported at comp.lang.fortran at
at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4bc3966b9ca9dbae
by glen herrmannsfeldt
From Fortran 2008 regarding C_LOC:
"Argument. X shall have either the POINTER or TARGET attribute. It shall not be
a coindexed object. It shall either be a variable with interoperable type and
kind type parameters, or be a scalar, nonpolymorphic variable with no length
type parameters. If it is allocatable, it shall be allocated. If it is a
pointer, it shall be associated. If it is an array, it shall be contiguous and
have nonzero size. It shall not be a zero-length string."
TS 29113 just deleted:
{In 15.2.3.6 C LOC(X), paragraph 3}
Delete “scalar,”.
[Bug fortran/52426] New: ICE for c_loc with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52426 Bug #: 52426 Summary: ICE for c_loc with array constructor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported at comp.lang.fortran at The following program ICEs with a segfault. ==22541== Invalid read of size 8 ==22541==at 0x57480B: gfc_resolve_expr(gfc_expr*) (resolve.c:2742) ==22541==by 0x57CC8C: resolve_code(gfc_code*, gfc_namespace*) (resolve.c:9334) That's in gfc_iso_c_func_interface the line: args_sym = args->expr->symtree->n.sym; I haven't checked Fortran 2008 plus TS 29113 whether it is allowed or not, but I think it isn't. (Note: F2008 and TS extend what is allowed for c_loc.) use iso_c_binding print *, c_loc([1]) end
[Bug c/52425] New: ICE when compiling file from audacious on debian sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52425
Bug #: 52425
Summary: ICE when compiling file from audacious on debian sparc
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: plugw...@p10link.net
Building
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=ui_fileopener.preprocessed;att=1;bug=659793
(preprocessed output from a file that formed part of audacious) with the
following command
gcc -fPIC -DPIC -g -O2 -std=gnu99 -pipe -pthread -c -xcpp-output
ui_fileopener.preprocessed
on debian sparc sid (debian gcc version 4.6.2-15, triplet sparc-linux-gnu)
produces.
root@netra:/audacious-3.2/src/libaudgui# gcc -fPIC -DPIC -g -O2 -std=gnu99
-pipe -pthread -c -xcpp-output ui_fileopener.preprocessed
ui_fileopener.c:200:1: internal compiler error: output_operand: invalid
expression as operand
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
{standard input}: Assembler messages:
{standard input}:6791: Warning: partial line at end of file ignored
Preprocessed source stored into /tmp/ccxHh7Af.out file, please attach this to
your bugreport.
root@netra:/audacious-3.2/src/libaudgui#
If the optimisation level is dropped to -O1 or -fPIC is removed from the
command line the file builds successfully.
gcc-4.5 (debian gcc version 4.5.3-12) does not exhibit the bug.
gcc-snapshot ((Debian 20120128-1) 4.7.0 20120128 (experimental) [trunk revision
183664]) also does not exibit the bug.
This bug is reported in debian as
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659793
[Bug tree-optimization/52424] New: dom prematurely pops entries from const_and_copies stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52424
Bug #: 52424
Summary: dom prematurely pops entries from const_and_copies
stack
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: wschm...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: berg...@vnet.ibm.com, jiangning@arm.com,
rguent...@suse.de
Created attachment 26775
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26775
Proposed patch of tree-ssa-dom.c
Jiangning Liu reported that the following C code has recently experienced
degraded performance on trunk. (Jiangning, please fill in the
Host/Target/Build fields for your configuration, or tell me what they are if
you don't have access. The problem is not related to specific targets in any
event.)
int *l, *r, *g;
void test_func(int n)
{
int i;
static int j;
static int pos, direction, direction_pre;
pos = 0;
direction = 1;
for ( i = 0; i < n; i++ )
{
direction_pre = direction;
for ( j = 0; j <= 400; j++ )
{
if ( g[pos] == 200 )
break;
if ( direction == 0 )
pos = l[pos];
else
pos = r[pos];
if ( pos == -1 )
{
if ( direction_pre != direction )
break;
pos = 0;
direction = !direction;
}
}
f(g[pos]);
}
}
When compiled with -O2, the dom2 details dump shows that a redundant phi is
detected in block 12:
:
# prephitmp.28_89 = PHI
# pos_lsm.33_53 = PHI
LKUP STMT prephitmp.28_89 = PHI
prephitmp.28_89 = PHI
2>>> STMT prephitmp.28_89 = PHI
prephitmp.28_89 = PHI
LKUP STMT pos_lsm.33_53 = PHI
pos_lsm.33_53 = PHI
FIND: prephitmp.28_89
0>>> COPY pos_lsm.33_53 = prephitmp.28_89
However, the COPY is incorrectly removed from the const_and_copy stack after
block 13 is processed. It should not be removed until after the last block
dominated by bb12 (bb18) is processed. As a result, the copy is not propagated
into a PHI in block 15:
# pos_lsm.33_123 = PHI
As a result, an extra copy is eventually introduced that degrades performance.
I tracked down the extra removal of const_and_copy stack entries to
tree-ssa-threadedge.c:remove_temporary_equivalences. This removes pairs of
entries that were introduced by thread_across_edge, and also removes a NULL
marker entry beneath those entries. Thus calls to thread_across_edge must be
preceded by a push of such a marker entry.
thread_across_edge is called from tree-ssa-dom.c:dom_thread_across_edge, which
is called in three places within dom_opt_leave_block. In two of those places,
the push of a marker entry is present. In the third, it isn't. Adding the
marker push appears to correct the problem.
I've attached a proposed fix. Jiangning, can you please apply this and see if
your performance problem is resolved?
Thanks,
Bill
[Bug libfortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Harald Anlauf 2012-02-28 20:43:00 UTC --- (In reply to comment #1) > Confirmed. This fails on all versions of gfortran 4.2 and up. > I don't have a 4.1 version for testing. FWIW, it also fails on 4.1.2 (tested on SLES10).
[Bug c++/52422] [C++11][SFINAE] Hard errors with void or arithmetic expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52422 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-28 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2012-02-28 20:38:06 UTC --- Ok. Likely simple to fix, I'll have a look.
[Bug libitm/52042] libitm.c/clone-1.c (all darwin) and libitm.c/stackundo.c (darwin 11) execution tests fail with -fpie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52042 m...@gcc.gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from mrs at gcc dot gnu.org 2012-02-28 20:27:47 UTC --- Fixed.
[Bug regression/52423] New: [4.6 Regression] ICE in build_unary_op, at c-typeck.c:3786
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52423
Bug #: 52423
Summary: [4.6 Regression] ICE in build_unary_op, at
c-typeck.c:3786
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org
works with 4.5 branch, and trunk, fails on 4.6 branch on x86_64-linux-gnu
$ gcc-4.6 -Wall .c
.c: In function 'main':
.c:13:2: warning: implicit declaration of function 'printf'
[-Wimplicit-function-declaration]
.c:13:2: warning: incompatible implicit declaration of built-in function
'printf' [enabled by default]
.c:13:2: internal compiler error: in build_unary_op, at c-typeck.c:3786
Please submit a full bug report,
with preprocessed source if appropriate.
//#include
struct p_t {
volatile unsigned int ref:3;
};
struct p_t p;
int main(void)
{
printf("%p", &p.ref);
return 0;
}
[Bug libstdc++/52191] abi_check should flag additions to released versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52191 --- Comment #4 from Benjamin Kosnik 2012-02-28 20:25:53 UTC --- Author: bkoz Date: Tue Feb 28 20:25:48 2012 New Revision: 184639 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184639 Log: 2012-02-21 Benjamin Kosnik PR libstdc++/52191 * testsuite/util/testsuite_abi.cc (compare_symbols): Check new symbols added into the latest version. Mark tls entities as undesignated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
[Bug libstdc++/52191] abi_check should flag additions to released versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52191 Benjamin Kosnik changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Benjamin Kosnik 2012-02-28 20:23:50 UTC --- Hey Ranier. This is as you requested. I expect you'll notice the new symbols now on solaris. I believe the new symbols should be conditionalized such that they are added in linux in the older version names, and on solaris in the new symbol names. Working on that now but prompt testresults from solaris with this patch (and the new fail) will be appreciated. -benjamin
[Bug libstdc++/52191] abi_check should flag additions to released versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52191 --- Comment #2 from Benjamin Kosnik 2012-02-28 20:21:13 UTC --- Created attachment 26774 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26774 patch to check new symbols are in new version names
[Bug c++/51214] [4.7 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214
fabien at gcc dot gnu.org changed:
What|Removed |Added
Summary|[C++11] name lookup issue |[4.7 Regression] [C++11]
|with c++11 enums|name lookup issue with
||c++11 enums
--- Comment #2 from fabien at gcc dot gnu.org 2012-02-28 20:19:23 UTC ---
We can manage to mark this bug as a 4.7 Regression, evidence below (to be
compiled with -std=c++11 obviously).
struct Base
{
int b1, b2, b3;
};
struct T : Base
{
int t1, t2, t3;
using Base::b1;
using Base::b2;
using Base::b3;
enum E2 : int;
};
enum T::E2 : int { A1 = 23 };
int i = T::A1;
I have a patch for it.
[Bug target/50946] ICE on armhf with webkitgtk+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 Matthias Klose changed: What|Removed |Added Status|WAITING |NEW CC||doko at gcc dot gnu.org Known to work||4.5.3 Known to fail||4.6.3, 4.7.0 --- Comment #5 from Matthias Klose 2012-02-28 20:07:20 UTC --- works with 4.5 branch and trunk, still ftbfs with 4.6.
[Bug middle-end/51752] trans-mem: publication safety violated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752 --- Comment #7 from Aldy Hernandez 2012-02-28 20:08:44 UTC --- Author: aldyh Date: Tue Feb 28 20:08:39 2012 New Revision: 184638 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184638 Log: PR middle-end/51752 * gimple.h (gimple_in_transaction): New. (gimple_set_in_transaction): New. (struct gimple_statement_base): Add in_transaction field. * tree-ssa-loop-im.c: (movement_possibility): Restrict movement of transaction loads. (tree_ssa_lim_initialize): Compute transaction bits. * tree.h (compute_transaction_bits): Protoize. * trans-mem.c (tm_region_init): Use the heap to store BB auxilliary data. (compute_transaction_bits): New. Added: trunk/gcc/testsuite/gcc.dg/tm/pub-safety-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.h trunk/gcc/trans-mem.c trunk/gcc/tree-ssa-loop-im.c
[Bug c++/52422] New: [C++11][SFINAE] Hard errors with void or arithmetic expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52422
Bug #: 52422
Summary: [C++11][SFINAE] Hard errors with void or arithmetic
expressions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.7.0 20120225 (experimental) in C++11 mode produces a hard compiler error
during a sfinae-conforming situation involving function-like or pointer-like
expressions:
//---
template
struct add_rval_ref
{
typedef T&& type;
};
template<>
struct add_rval_ref
{
typedef void type;
};
template
typename add_rval_ref::type create();
template()()) // line 17
>
auto f(int) -> char(&)[1];
template
auto f(...) -> char(&)[2];
static_assert(sizeof(f(0)) != 1, "");
//---
"16|error: void value not ignored as it ought to be"
Here some further variations of the theme:
a) Replace line 17 by
class = decltype(*create()) // line 17
b) Replace above test by
//---
template
struct add_rval_ref
{
typedef T&& type;
};
template<>
struct add_rval_ref
{
typedef void type;
};
template
typename add_rval_ref::type create();
template().*create())() ) // line 17
>
auto f(int) -> char(&)[1];
template
auto f(...) -> char(&)[2];
static_assert(sizeof(f(0)) != 1, ""); // line 24
//---
"17|error: 'create()' cannot be used as a member pointer, since it is of
type 'add_rval_ref::type {aka void}'"
c) Replace in the test (b) line 24 by the following line:
static_assert(sizeof(f(0)) != 1, ""); // line 24
"17|error: 'create()' cannot be used as a member pointer, since it is of
type 'int'"
d) Replace line 17 in the test (b) by the following line and use either of
"void, void" or "int, int" as template arguments in line 24:
class = decltype( create().*create() )
"17|error: 'create()' cannot be used as a member pointer, since it is of
type 'add_rval_ref::type {aka void}'"
or
"17|error: 'create()' cannot be used as a member pointer, since it is of
type 'int'"
respectively.
[Bug target/52421] New: SH Target: -fnon-call-exceptions prevents delay slot filling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52421
Bug #: 52421
Summary: SH Target: -fnon-call-exceptions prevents delay slot
filling
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
When the -fnon-call-exceptions option is used delay slots might not be filled,
although they could.
int test (int x, int y)
{
return x == y;
}
compiled with -Os:
cmp/eqr5,r4! 7cmpeqsi_t/3[length = 2]
rts! 22*return_i[length = 2]
movtr0! 13movsi_i/8[length = 2]
compiled with -Os -fnon-call-exceptions
cmp/eqr5,r4! 7cmpeqsi_t/3[length = 2]
movtr0! 14movsi_i/8[length = 2]
rts
nop! 24*return_i[length = 4]
It seems this happens for all SH variants.
When compiled for SH2A the no-delay-slot-rts insn is picked:
cmp/eqr5,r4! 7cmpeqsi_t/3[length = 2]
movtr0! 14movsi_ie/10[length = 2]
rts/n! 28*return_i[length = 4]
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20120227 (experimental) (GCC)
[Bug ada/52420] New: ada build failure with -gdwarf-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52420 Bug #: 52420 Summary: ada build failure with -gdwarf-4 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: p...@mandriva.com.br Recently in mandriva it was added -gdwarf-4 as well as some other options, to rpm optflags, but to successfully build gcc 4.7.0 it is required to remove it from CFLAGS to avoid this build failure: [...] ../../xgcc -B../../ -c -g -O2 -Wa,--compress-debug-sections -gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2 -fPIC -W -Wall -gnatpg -gnata -I- -I../rts -I. -I/home/pcpa/rpmbuild/BUILD/gcc-4.7-20120225/gcc/ada /home/pcpa/rpmbuild/BUILD/gcc-4.7-20120225/gcc/ada/mlib-prj.adb -o mlib-prj.o [...] ../../xgcc -B../../ -static-libgcc -I- -I../rts -I. -I/home/pcpa/rpmbuild/BUILD/gcc-4.7-20120225/gcc/ada -DIN_GCC -g -O2 -Wa,--compress-debug-sections -gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2 -fPIC -W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-tgt-specific.o mlib-utl.o namet.o nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o prj-dect.o prj-env.o prj-conf.o prj-pp.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o urealp.o usage.o widechar.o \ targext.o link.o ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a ../../../libiberty/libiberty.a mlib-prj.o:(.debug_types[wt.d60ca0c82bc70253]+0x8a): undefined reference to `.LLST479' mlib-prj.o:(.debug_types[wt.41905a5a6a523ee9]+0x8f): undefined reference to `.LLST479' mlib-prj.o:(.debug_types[wt.0a43032d5d4a580b]+0x8a): undefined reference to `.LLST473' mlib-prj.o:(.debug_types[wt.36d40966de25ea99]+0x8f): undefined reference to `.LLST473' mlib-prj.o:(.debug_types[wt.5347ec71460dc53e]+0x8a): undefined reference to `.LLST455' mlib-prj.o:(.debug_types[wt.3096742ee216922d]+0x8f): undefined reference to `.LLST455' mlib-prj.o:(.debug_types[wt.d1642ddc76250466]+0x8a): undefined reference to `.LLST449' mlib-prj.o:(.debug_types[wt.0976701503715b70]+0x8f): undefined reference to `.LLST449' collect2: error: ld returned 1 exit status
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #18 from Paolo Carlini 2012-02-28 18:25:54 UTC --- Ah, thanks Joseph. Thus, to repeat, anything we do in terms of macros has to be for *2.16* and later.
[Bug middle-end/52419] Wrong expansion of misaligned vector store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52419 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Martin Jambor 2012-02-28 18:09:48 UTC --- Jakub pointed out on IRC that the problem was elsewhere. *** This bug has been marked as a duplicate of bug 52407 ***
[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 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #8 from Martin Jambor 2012-02-28 18:09:48 UTC --- *** Bug 52419 has been marked as a duplicate of this bug. ***
[Bug middle-end/52419] New: Wrong expansion of misaligned vector store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52419
Bug #: 52419
Summary: Wrong expansion of misaligned vector store
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamb...@gcc.gnu.org
CC: rgue...@gcc.gnu.org
Host: x86_64linux-gnu
Target: x86_64linux-gnu
Created attachment 26773
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26773
Testcase
When I compile the attached testcase, even at -O0, the resulting
binary aborts because the vector value is {5,3} instead of expected
{3,5}. When I remove the aligned and packed attributes, the testcase
works as expected.
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #17 from joseph at codesourcery dot com 2012-02-28 17:05:50 UTC --- 2.15 has the gets prototype. It's 2.16 where it has been removed (but the version in the headers only changes from 2.15 to 2.16 when the final 2.16 release is made so you can't distinguish 2.15 from 2.16 development versions simply by examining preprocessor macros).
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #16 from Paolo Carlini 2012-02-28 16:42:55 UTC --- I suppose that post 4.7.0 we have to revisit this issue anyway, because C++11 definitely wants to declare std::gets, irrespective of C11. I'm wondering if it would be possible to just take this into account in , I seem to remember that the glibc headers in a few places already use __cplusplus, right? We also have the __CORRECT_ISO_CPP_STRING_H_PROTO story as an example of interaction between glibc and C++. That said, for 4.7.0, I think that in any case we want: 1- To fully run the testsuite on a GNU/Linux system using glibc2.15; 2- Convince ourselves that whatever we do in the C++ library is not going to interact badly with further tweaks at the glibc level..
[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 --- Comment #10 from Eric Botcazou 2012-02-28 16:41:04 UTC --- > Untested fix. Not sure if that is the way we want to solve this though. You might want to adjust the comment in df.h because it will be totally off.
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 --- Comment #6 from Robert Hayward 2012-02-28 16:36:52 UTC --- 48058(In reply to comment #4) > Created attachment 26770 [details] > test program to reproduce bug Sorry about that, attached to the wrong bug. It was meant for 52151.
[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 --- Comment #9 from Eric Botcazou 2012-02-28 16:33:42 UTC --- > I wonder if df_reg_chain_unlink/df_install_ref shouldn't just ignore > DEBUG_INSN > refs when updating df->hard_regs_live_count array, do we care at all when > testing regs_ever_live if something is live in debug insns? Probably not. Moreover, hard_regs_live_count isn't used outside of df-scan.c as both df_hard_reg_used_p and df_hard_reg_used_count are only used there (in fact the latter isn't used at all and could be eliminated altogether).
[Bug fortran/52418] (unnecessary) automatic reallocation of lhs causes segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52418 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Tobias Burnus 2012-02-28 16:25:26 UTC --- Aha, that's the bug report to the spurious attachment at PR 48058 comment 4. Thanks for the bug report and sorry for the breakage! As written there, that's a known bug affecting both GCC 4.6 and GCC 4.7. It has been reported on 2012-01-26 and fixed on 2012-01-31 for GCC 4.7 and on 2012-02-03 for GCC 4.7 [See PR 52151 for details.] A follow up fix (for RESHAPE when a reallocation is required) has been committed on 2012-02-08 for both GCC's 4.6 branch and the 4.7 trunk, cf. PR 52151. (For some reasons, no one has reported the bug for one year, but now there were two reports within a week and this one a month after the first report.) As written in PR 52117, you have the following options: > Unless you provide me with a time machine [...] > The only solutions, I see, which do not require code changes are: > > - Use any GCC version before GCC 4.6.0; for instance GCC 4.5.x > - Use GCC 4.6 older than 2010-11-28 > - Use a GCC (any version) newer than 2012-02-03 > - Use -fno-realloc-lhs (caveat: Flag not supported before GCC 4.6) > - Use -std=f95 (caveat: Requires that the code compiles without error with > -std=f95) > For completeness, also the following code changes are possible; except for > the first one, they are not recommended: > > - Use an array spec for allocatable LHS, e.g. "B(:,:,:) = " [And some more nonseriously meant variants] *** This bug has been marked as a duplicate of bug 52151 ***
[Bug fortran/52151] Segfault with realloc on assignment and RESHAPE to unallocated LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52151 Tobias Burnus changed: What|Removed |Added CC||therobbot at gmail dot com --- Comment #7 from Tobias Burnus 2012-02-28 16:25:26 UTC --- *** Bug 52418 has been marked as a duplicate of this bug. ***
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #15 from Jakub Jelinek 2012-02-28 16:18:30 UTC --- Ideally, when using #define _GNU_SOURCE #include in a C++ program ::gets wouldn't be available (the _GNU_SOURCE requests GNU namespace rather than standard C++ one), but when using #include #include it would provide it (with deprecated attribute), because then the user didn't request _GNU_SOURCE. But for that we'd need some new macro to request additional prototype for STL needs.
[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534 --- Comment #4 from mgretton at gcc dot gnu.org 2012-02-28 16:17:44 UTC --- Author: mgretton Date: Tue Feb 28 16:17:36 2012 New Revision: 184630 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184630 Log: PR target/51534 Add testcase forgotten in last commit, ChangeLog entry already present. Added: trunk/gcc/testsuite/gcc.target/arm/neon/pr51534.c
[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-28 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #8 from Jakub Jelinek 2012-02-28 16:14:52 UTC --- Created attachment 26772 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26772 gcc47-pr52397.patch Untested fix. Not sure if that is the way we want to solve this though.
[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534 --- Comment #3 from mgretton at gcc dot gnu.org 2012-02-28 16:14:03 UTC --- Author: mgretton Date: Tue Feb 28 16:13:52 2012 New Revision: 184629 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184629 Log: PR target/51534 * gcc/config/arm/arm.c (neon_builtin_data): Add entries for vcgeu and vcgtu. * gcc/config/arm/arm_neon.h: Regenerate. * gcc/config/arm/neon.md (unspec): Add UNSPEC_VCGEU, and UNSPEC_VCGTU. (neon_vcgeu): New insn. (neon_vcgtu): Likewise. * gcc/config/arm/neon.ml (s_8_32, u_8_32): New lists. (ops): Unsigned comparison intrinsics call a different builtin. * gcc/testsuite/gcc.target/arm/neon/pr51534.c: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/neon.md trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785
--- Comment #14 from Ramana Radhakrishnan
2012-02-28 16:09:52 UTC ---
I can confirm that a build for arm-linux-gnueabi completes and do some
cross-testing on qemu if that's deemed to be enough.
Any other ideas for testing.
Ramana
Here's a suggestion for the comments in this patch.
diff --git a/libstdc++-v3/include/c_global/cstdio
b/libstdc++-v3/include/c_global/cstdio
index 049704d..76755ac 100644
--- a/libstdc++-v3/include/c_global/cstdio
+++ b/libstdc++-v3/include/c_global/cstdio
@@ -89,6 +89,17 @@
#undef vprintf
#undef vsprintf
+/* glibc 2.15 and later do not declare gets anymore for
+ ISO C11 mode and if __GNU_SOURCE is defined. See
+ http://gcc.gnu.org/PR51785 for more on this topic. If
+ this is being changed an equivalent change has to be made
+ in include/c_std/c_stdio. */
+#if __GLIBC_PREREQ (2,15)
+extern "C" {
+ extern char *gets (char *__s) __attribute__((deprecated));
+}
+#endif
+
namespace std
{
using ::FILE;
diff --git a/libstdc++-v3/include/c_std/cstdio
b/libstdc++-v3/include/c_std/cstdio
index 510f599..29142bb 100644
--- a/libstdc++-v3/include/c_std/cstdio
+++ b/libstdc++-v3/include/c_std/cstdio
@@ -88,6 +88,17 @@
#undef vprintf
#undef vsprintf
+/* glibc 2.15 and later do not declare gets anymore for
+ ISO C11 mode and if __GNU_SOURCE is defined. See
+ http://gcc.gnu.org/PR51785 for more on this topic. If
+ this hunk below is being changed please also investigate
+ the change for include/c_global/cstdio. */
+#if __GLIBC_PREREQ (2,15)
+extern "C" {
+ extern char *gets (char *__s) __attribute__((deprecated));
+}
+#endif
+
namespace std
{
using ::FILE;
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||therobbot at gmail dot com --- Comment #5 from Tobias Burnus 2012-02-28 16:11:08 UTC --- Robert Hayward wrote in comment #4: > Created attachment 26770 [details] > test program to reproduce bug Please do not attach test cases to random bugreports! But create a new bug report and put more information in the report. -- Except that both issues are related to Fortran 2003's (re)allocation on intrinsic assignment, they do not have anything in common. The issue of comment 4 / Robert Hayward's issue is a bug in gfortran 4.6/4.7, which has been been reported in PR 52012 and fixed around 2012-01-31. Please try a newer version of GCC 4.6/4.7 - or use -fno-realloc-lhs as work around. (The issue in comment 0 is a bug in the original reporter's program for Fortran 90/95: The shape on the right and on the left have to be the same. The proper assignment should have been one of the following: ivec(1:2) = [1,2] ivec(2:3) = [1,2] ivec(1:2:2) = [1,2] ! or ivec([1,3]) = [1,2] With Fortran 2003, the program became valid - as the compiler reallocated "ivec" with the shape of the right side. With -std=f95 or if the left-hand side weren't allocatable, -fcheck=bounds had given a run-time error.)
[Bug libfortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-02-28
CC||kargl at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |kargl at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
Known to fail||4.2.5, 4.3.6, 4.4.7, 4.5.4,
||4.6.3, 4.7.0
--- Comment #1 from kargl at gcc dot gnu.org 2012-02-28 16:11:10 UTC ---
Confirmed. This fails on all versions of gfortran 4.2 and up.
I don't have a 4.1 version for testing. I have a patch, but
as this is not a regression, I will not apply it until after
4.7.0 is released.
Tentative patch. Not regression tested, yet.
Index: simplify.c
===
--- simplify.c (revision 184485)
+++ simplify.c (working copy)
@@ -2331,35 +2331,16 @@ gfc_expr *
gfc_simplify_fraction (gfc_expr *x)
{
gfc_expr *result;
- mpfr_t absv, exp, pow2;
+ mpfr_exp_t e;
if (x->expr_type != EXPR_CONSTANT)
return NULL;
result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);
- if (mpfr_sgn (x->value.real) == 0)
-{
- mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
- return result;
-}
-
gfc_set_model_kind (x->ts.kind);
- mpfr_init (exp);
- mpfr_init (absv);
- mpfr_init (pow2);
-
- mpfr_abs (absv, x->value.real, GFC_RND_MODE);
- mpfr_log2 (exp, absv, GFC_RND_MODE);
-
- mpfr_trunc (exp, exp);
- mpfr_add_ui (exp, exp, 1, GFC_RND_MODE);
-
- mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
-
- mpfr_div (result->value.real, absv, pow2, GFC_RND_MODE);
- mpfr_clears (exp, absv, pow2, NULL);
+ mpfr_frexp (&e, result->value.real, x->value.real, GFC_RND_MODE);
return range_check (result, "FRACTION");
}
[Bug fortran/52418] New: (unnecessary) automatic reallocation of lhs causes segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52418 Bug #: 52418 Summary: (unnecessary) automatic reallocation of lhs causes segfault Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: therob...@gmail.com Created attachment 26771 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26771 program to reproduce bug The following program causes a segfault: PROGRAM reshape_test IMPLICIT NONE REAL, DIMENSION(:,:), ALLOCATABLE :: m2 REAL, DIMENSION(:,:,:), ALLOCATABLE :: m3 ALLOCATE( m2( 6, 1 ), m3( 2, 3, 1 ) ) m2 = -1 m3 = RESHAPE( m2, SHAPE(m3) ) m3 = 2 WRITE(*,*) 'm3(1,1,1) = ', m3(1,1,1) END PROGRAM reshape_test If compiled with -fno-realloc-lhs, the code runs as expected. There really shouldn't be any reallocation here, so this shouldn't make a difference. Either way it should not cause a segfault. Side note: I love all of the work on f2003/2008! The OO features make fortran fun again. Thanks!
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 --- Comment #4 from Robert Hayward 2012-02-28 15:53:05 UTC --- Created attachment 26770 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26770 test program to reproduce bug
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #13 from Jakub Jelinek 2012-02-28 15:49:26 UTC --- I'm ok with #c3 patch + comment if it works, using special configure macro instead of __GLIBC_PREREQ is IMHO undesirable, because then if you build gcc against glibc 2.14 and afterwards upgrade glibc to 2.15, it will suddenly break.
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #12 from Marc Glisse 2012-02-28 15:47:04 UTC --- (In reply to comment #10) > If the libstdc++ people are going to do something for 4.7, it really needs > to be done very soon. The question is: what do the glibc people want? By removing the gets prototype, they are explicitly going against the C++ standard. Seems to me that libstdc++ should respect that choice (add a test in configure to see if gets is provided, and protect "using ::gets;" with #ifdef) and not provide gets. The alternative is to disagree with the glibc developers and fixinclude stdio.h.
[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 --- Comment #7 from Jakub Jelinek 2012-02-28 15:40:40 UTC --- Ok, with additional -fno-inline -gnatpg I can reproduce even with the commands I tried. The dead_debug* stuff doesn't handle this probably because the hard reg isn't ever becoming REG_DEAD or REG_UNUSED etc. in the IL, it is just unused altogether plus set on entry. I wonder if df_reg_chain_unlink/df_install_ref shouldn't just ignore DEBUG_INSN refs when updating df->hard_regs_live_count array, do we care at all when testing regs_ever_live if something is live in debug insns?
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #22 from pmarlier at gcc dot gnu.org 2012-02-28 15:37:57 UTC --- Author: pmarlier Date: Tue Feb 28 15:37:41 2012 New Revision: 184628 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184628 Log: 2012-02-27 Jack Howarth Patrick Marlier PR boehm-gc/48299 testsuite/boehm-gc.c/thread_leak_test.c: Merge upstream changes. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #11 from Paolo Carlini 2012-02-28 15:35:59 UTC --- If the release managers agree, I would be in favor of a quick fix per Comment 3, with a huge comment in the code explaining the issue. But I can't test it right now.
[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 changed: What|Removed |Added Known to work||4.7.0 Target Milestone|4.7.0 |4.6.4 Summary|[4.7 Regression] sse2 simd |[4.6 Regression] sse2 simd |uint32_t and int64_t and|uint32_t and int64_t and |stack variable |stack variable |initialization |initialization --- Comment #7 from Richard Guenther 2012-02-28 15:29:53 UTC --- Fixed on trunk. I'll backport it for 4.6.4 as it is latent on the branches.
[Bug target/52407] [4.7 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 --- Comment #6 from Richard Guenther 2012-02-28 15:28:39 UTC --- Author: rguenth Date: Tue Feb 28 15:28:32 2012 New Revision: 184627 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184627 Log: 2012-02-28 Richard Guenther 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: trunk/gcc/testsuite/gcc.dg/torture/pr52407.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/49448] arm-tab-linux-gnu-eabi enableds big endian when it should not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49448 --- Comment #3 from Richard Earnshaw 2012-02-28 15:26:13 UTC --- Author: rearnsha Date: Tue Feb 28 15:26:02 2012 New Revision: 184626 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184626 Log: PR target/49448 * config.gcc (arm*-*-linux*): Use an unambiguous pattern for detecting big-endian triplets. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #10 from joseph at codesourcery dot com 2012-02-28 15:23:38 UTC --- If the libstdc++ people are going to do something for 4.7, it really needs to be done very soon. Let's assume glibc should at least get a further change for the sake of older GCC versions - changing !defined __USE_GNU to (!defined __USE_GNU || (defined __GNUC__ && !__GNUC_PREREQ (4, 7))). But if this isn't fixed for 4.7, that conditional in stdio.h would need to use __GNUC_PREREQ (4, 8) instead.
[Bug target/50181] insn does not satisfy constraints for 481.wrf when generating profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50181
--- Comment #1 from Peter Bergner 2012-02-28
14:53:57 UTC ---
Created attachment 26769
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26769
Smaller C test case
Here is a smaller C test case that doesn't require -fprofile-generate to ICE:
bergner@igoo:~/gcc/BUGS/pr50181>
/home/bergner/gcc/build/gcc-fsf-4_6-base/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-4_6-base/gcc -O3 -mcpu=power7 -S pr50181.c
pr50181.c: In function ‘testcase’:
pr50181.c:29:1: error: insn does not satisfy its constraints:
(insn 69 7 68 2 (set (reg:V4SI 10 10)
(const_vector:V4SI [
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
])) pr50181.c:17 789 {*vsx_movv4si}
(nil))
pr50181.c:29:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus 2012-02-28 14:46:10 UTC --- For assumed type, see early draft patch at http://gcc.gnu.org/ml/fortran/2012-02/msg00111.html (and, in the thread, for a MPIv3-related discussion) Latest TS29113 draft: http://j3-fortran.org/doc/meeting/197/12-119r1.pdf
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org --- Comment #9 from Ramana Radhakrishnan 2012-02-28 14:41:56 UTC --- I ran into this failure today when upgrading my copy of (e)glibc in my cross-environment. What's the best way of progressing this further ? Doesn't this mean that trunk is broken for building with anything later than glibc-2.15 ? Ramana
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #6 from Richard Guenther 2012-02-28 14:41:29 UTC --- (In reply to comment #4) > (gdb) r -vvvc > Starting program: > /home/nikolns/bld/aster/gcc-4.7/asterisk-1.8.9.2/main/asterisk -vvvc > [Thread debugging using libthread_db enabled] > [New Thread 0x77fd9700 (LWP 15132)] > > Program received signal SIGILL, Illegal instruction. > 0x0053e80f in tzload (name=, sp=0x82bd40, > doextend=1) at stdtime/localtime.c:657 > 657 static int tzload(const char *name, struct state * const sp, const int > doextend) That does not show the instuction. Do (gdb) disassemble 0x0053e800,+32 (assuming the crash is still at 0x0053e80f when you re-try)
[Bug lto/52405] undefined references in shared library when linking the shared library with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405 Richard Guenther changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Richard Guenther 2012-02-28 14:36:47 UTC --- We do have known issues with linker options not being reflected correctly in the resolution file. As it is inlines and you use -fvisibility=hidden I expect that the -Xlinker --version-script=mapfile_reorder is not re-applied after final link optimization but only to the (fat) object file result from compile. So some functions may not be catched by the version script globbing (or they are renamed as comdats are brought local, and thus may no longer match any of the globs)? Please help reducing this on your side.
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 Richard Guenther changed: What|Removed |Added Blocks||50067 --- Comment #6 from Richard Guenther 2012-02-28 14:32:58 UTC --- The issue is that we want to disambiguate a[i].f1 and a[i].f2, so for the "base object" we zero out all known indices, resulting in a[0].f1 and a[0].f2 which we then disambiguate (and conclude that for all i there cannot be a dependence). Now, when we mix pointer accesses with array accesses most of the index analysis falls apart (which is what the fix for PR50067 tries to make work more reliably - see its comment #13 on the dr_may_alias_p issue ...) So, it's really wrong to try to fixup DR_BASE_OBJECT to make dr_may_alias_p work, and it is equally wrong to use DR_BASE_OBJECT in dr_may_alias_p. Using DR_REF (a safe bet) falls foul of failing a load of testcases, for example gcc.dg/vect/pr37027.c which is no longer vectorized because (compute_affine_dependence stmt_a: D.1722_7 = a[i_24].f1; stmt_b: D.1725_11 = a[i_24].f2; ) -> dependence analysis failed previously we'd have used a[0].f1 and a[0].f2 in the disambiguation in dr_may_alias_p and disambiguated the accesses. We can try a similar trick as with REALPART/IMAGPART_EXPR to recover this. Add a constant access function for outer COMPONENT_REFs (those we can strip off the base object).
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #5 from evrinoma at gmail dot com 2012-02-28 13:45:16 UTC --- cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Celeron(R) CPU 3.06GHz stepping: 9 cpu MHz : 3066.590 cache size : 256 KB fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc up pebs bts pni dtes64 monitor ds_cpl tm2 cid cx16 xtpr lahf_lm bogomips: 6118.58 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: uname -a Linux IT0917 2.6.32-220.4.2.el6.x86_64 #1 SMP Tue Feb 14 04:00:16 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux free total used free sharedbuffers cached Mem: 20444161971600 72816 0 606361615176 -/+ buffers/cache: 2957881748628 Swap: 252 0252
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #4 from evrinoma at gmail dot com 2012-02-28 13:38:29 UTC --- (gdb) r -vvvc Starting program: /home/nikolns/bld/aster/gcc-4.7/asterisk-1.8.9.2/main/asterisk -vvvc [Thread debugging using libthread_db enabled] [New Thread 0x77fd9700 (LWP 15132)] Program received signal SIGILL, Illegal instruction. 0x0053e80f in tzload (name=, sp=0x82bd40, doextend=1) at stdtime/localtime.c:657 657 static int tzload(const char *name, struct state * const sp, const int doextend)
[Bug lto/52405] undefined references in shared library when linking the shared library with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405 Matthias Klose changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Matthias Klose 2012-02-28 13:35:17 UTC --- binutils from the 2.22 release branch is used. yes, using the linker plugin. options to build the shared library (see build.sh) -m64 -fpic -fno-rtti -fno-exceptions -fcheck-new -fvisibility=hidden -m64 -flto -flto-partition=none -g -O3 -fno-strict-aliasing -fno-omit-frame-pointer -Xlinker -O1 -Wl,-Bsymbolic-functions -Xlinker -z -Xlinker noexecstack -shared -Xlinker --version-script=mapfile_reorder -Xlinker -soname=libjvm.so -o libjvm.so reducing these to -m64 -fpic -fno-rtti -fno-exceptions -fcheck-new -fvisibility=hidden -flto -flto-partition=none -g -O3 -fno-strict-aliasing -fno-omit-frame-pointer -Wl,-Bsymbolic-functions -Xlinker -z -shared -Xlinker -soname=libjvm.so -o libjvm.so doesn't change things. -fno-use-linker-plugin doesn't change things. -flto-partition=none doesn't change things.
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #3 from evrinoma at gmail dot com 2012-02-28 13:07:14 UTC --- gcc-4.7-20120225/configure --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux posix gcc 4.7.0 20120225 (experimental) (GCC) similar problem
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 --- Comment #5 from Jay Foad 2012-02-28 13:03:50 UTC --- > But to answer your question, how you can assert it is properly aligned, in gcc > 4.7.0 you can write: > __builtin_memcpy (&i, __builtin_assume_aligned (p, sizeof *p), sizeof i); Thanks! Better: __builtin_assume_aligned (p, __alignof__ *p)
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-28 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-02-28 12:57:30 UTC --- Please look at what the illegal instruction is and make sure your CPU has all features required by your compile. Also nobody is going to download tarballs, so you need to provide us with a testcase.
[Bug c/52410] BUG gcc 4.6.2 Illegal Instruction (core dumped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52410 --- Comment #2 from evrinoma at gmail dot com 2012-02-28 12:51:05 UTC --- gcc-4.7-20120225/configure --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux posix gcc 4.7.0 20120225 (experimental) (GCC) similar problem
[Bug rtl-optimization/52417] [4.7 Regression] Infinite recursion in DSE/alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52417 Georg-Johann Lay changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay 2012-02-28 12:48:10 UTC --- CCing Alexandre, presumably this is caused by the last changes for PR52001.
[Bug rtl-optimization/52417] [4.7 Regression] Infinite recursion in DSE/alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52417 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-28 CC||eric.weddington at atmel ||dot com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug rtl-optimization/52417] New: [4.7 Regression] Infinite recursion in DSE/alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52417 Bug #: 52417 Summary: [4.7 Regression] Infinite recursion in DSE/alias.c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr alias.c enters an infinite recurson for the following testcases from GCC testsuite: gcc.c-torture/compile/pr37669-2.c for any compilation with -O* and without -fno-dse Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2 --enable-checking=yes,rtl target_alias=avr --enable-languages=c,c++ Thread model: single gcc version 4.7.0 20120228 (experimental) (GCC) GNU C (GCC) version 4.7.0 20120228 (experimental) (avr) compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek 2012-02-28
12:29:14 UTC ---
But to answer your question, how you can assert it is properly aligned, in gcc
4.7.0 you can write:
__builtin_memcpy (&i, __builtin_assume_aligned (p, sizeof *p), sizeof i);
which will assert that p is sizeof (float) bytes aligned and then you get code
without the stack frame. Or you can use a union instead of memcpy:
union U { float f; int i; } u;
u.f = *p;
return u.i;
[Bug gcov-profile/52416] New: Branch coverage differences between 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52416
Bug #: 52416
Summary: Branch coverage differences between 4.4 and 4.5
Classification: Unclassified
Product: gcc
Version: 4.5.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: chateau.frede...@gmail.com
Hello,
I am using g++ versions coming with Ubuntu 11.10 and I am trying to use g++ and
lcov to analyse the line and branch coverage of my unit tests.
I discovered some significant differences in the number of branches reported
between version 4.4 (4.4.6) and 4.5 (4.5.4) (or 4.6 (4.6.1)).
I was trying to figure out which compilation flags were best in order to have
branch coverage information match more closely what I see in the source code
and avoid hidden branches (triggered by under the hood code) or suppressed
branches (because of optimizations).
Finally, it seems that -O0 -fno-inline -fno-default-inline
-fno-elide-constructors works best, at least with g++-4.4
Because, when I use g++-4.5 or g++-4.6, there are many additionnal branches
that do not directly come from the control flow in the source.
In the project I was analysis, the number of branches jumped from ~1950 to
~6600 !
In my point of view, the output of 4.4 is more meaningful than the output of
4.5/4.6.
I tried to make a little example program and tried to figure out if there was a
flags that could disable the generetion of these branches.
And indeed, with -fno-exceptions, I get the same exact result in 4.5/4.6 than
in 4.4. At least with my example program, because my whole project requires
exception handling to be activated.
Here is the example code:
#include
int main(int argc, char* argv[])
{
std::string val;
if(argc > 1)
{
val = argv[1];
}
if(argc == 2)
{
std::cout << val << std::endl;
}
else
{
std::cout << "Need one argument!" << std::endl;
}
}
With g++ 4.4, there are 8 branches.
With g++ 4.5, there are 16 branches !
Here is gcov output:
g++-4.5:
-:0:Source:myprog.cpp
-:0:Graph:myprog.gcno
-:0:Data:myprog.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:
function main called 1 returned 100% blocks executed 58%
1:3:int main(int argc, char* argv[])
-:4:{
2:5:std::string val;
call0 returned 100%
call1 returned 100%
call2 never executed
call3 never executed
1:6:if(argc > 1)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
-:7:{
#:8:val = argv[1];
branch 0 never executed
branch 1 never executed
call2 never executed
-:9:}
1: 10:if(argc == 2)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
-: 11:{
#: 12:std::cout << val << std::endl;
branch 0 never executed
branch 1 never executed
call2 never executed
branch 3 never executed
branch 4 never executed
call5 never executed
-: 13:}
-: 14:else
-: 15:{
1: 16:std::cout << "Need one argument!" << std::endl;
branch 0 taken 100% (fallthrough)
branch 1 taken 0%
call2 returned 100%
branch 3 taken 100% (fallthrough)
branch 4 taken 0%
call5 returned 100%
-: 17:}
function _Z41__static_initialization_and_destruction_0ii called 1 returned 100%
blocks executed 100%
function _GLOBAL__I_main called 1 returned 100% blocks executed 100%
3: 18:}
branch 0 taken 100% (fallthrough)
branch 1 taken 0%
branch 2 taken 100% (fallthrough)
branch 3 taken 0%
call4 returned 100%
-: 19:
With g++-4.4:
-:0:Source:myprog.cpp
-:0:Graph:myprog.gcno
-:0:Data:myprog.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:
function main called 1 returned 100% blocks executed 54%
1:3:int main(int argc, char* argv[])
-:4:{
1:5:std::string val;
call0 returned 100%
1:6:if(argc > 1)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
-:7:{
#:8:val = argv[1];
call0 never executed
-:9:}
1: 10:if(argc == 2)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
-: 11:{
#: 12:std::cout << val << std::endl;
call0 never executed
call1 never executed
-: 13:}
-: 14:else
-: 15:{
1: 16:std::cout << "Need one argument!" << std::endl;
call0 returned 100%
call1 returned 100%
#: 17:}
call0 never executed
call1
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
--- Comment #3 from Richard Guenther 2012-02-28
12:15:53 UTC ---
(In reply to comment #2)
> > On the tree level nothing guarantees that 'p' is properly aligned.
>
> This is a digression, but what about C99 (Committee Draft -- April 12, 2011)
> 6.3.2.3p7:
>
> "A pointer to an object type may be converted to a pointer to a different
> object type. If the resulting pointer is not correctly aligned for the
> referenced type, the behavior is undefined."
>
> Doesn't that guarantee that p is properly aligned? If not, how can I assert
> that p *is* properly aligned, so the compiler can turn the memcpy into an
> aligned load? Thanks.
Well, not exactly. The GIMPLE IL does not map 1:1 to the C99 spec (after
all it has to support other languages besides C). There is no convenient
way for a frontend to tell the middle-end that 'p' is properly aligned
for a float. Note that the situation is complicated by the fact that,
as GCC extension, you can create a misaligned variant
typedef float my_float __attribute__((aligned(1)));
int f(my_float *p) {
int i;
__builtin_memcpy(&i, p, sizeof i);
return i;
}
which needs to be handled correctly as well (we don't on STRICT_ALIGNMENT
targets). The my_float * case is of course not covered by C99.
[Bug target/52407] [4.7 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407
--- Comment #5 from Jakub Jelinek 2012-02-28
12:02:18 UTC ---
Triggered by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184435
Testcase:
/* PR target/52407 */
extern void abort (void);
typedef long long V __attribute__ ((vector_size (16)));
V ul[4], vl[4] = { {1, 2}, {3, 4}, {5, 6}, {7, 8} };
static void
foo (V *u, V *v, long long x, int m)
{
V w;
long long *p = (long long *) &w;
p[0] = p[1] = x;
while (m--)
*u++ = *v++ * w;
}
int
main ()
{
int i;
long long *pl;
pl = (long long *) &ul;
foo (ul, vl, 2, 4);
for (i = 0; i < 8; i++)
if (pl[i] != 2 * (i + 1))
abort ();
return 0;
}
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 --- Comment #2 from Jay Foad 2012-02-28 11:51:00 UTC --- > On the tree level nothing guarantees that 'p' is properly aligned. This is a digression, but what about C99 (Committee Draft -- April 12, 2011) 6.3.2.3p7: "A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined." Doesn't that guarantee that p is properly aligned? If not, how can I assert that p *is* properly aligned, so the compiler can turn the memcpy into an aligned load? Thanks.
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-28 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-02-28 11:45:04 UTC --- This is I believe because ARM is a STRICT_ALIGNMENT target and we thus do not transform the memcpy on the tree level. On the tree level nothing guarantees that 'p' is properly aligned.
[Bug target/52407] [4.7 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Known to work||4.6.2 Target Milestone|--- |4.7.0 Summary|sse2 simd uint32_t and |[4.7 Regression] sse2 simd |int64_t and stack variable |uint32_t and int64_t and |initialization |stack variable ||initialization
[Bug target/52407] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther 2012-02-28 11:34:36 UTC --- I'm testing a patch. The V2DF/SImode case is also bogus.
[Bug target/52407] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Target||x86_64-*-* --- Comment #3 from Richard Guenther 2012-02-28 11:32:34 UTC --- Hmm, ix86_expand_vector_set has for the V2DI case ix86_expand_vector_extract (false, tmp, target, 1 - elt); if (elt == 0) tmp = gen_rtx_VEC_CONCAT (mode, tmp, val); else tmp = gen_rtx_VEC_CONCAT (mode, val, tmp); vs. for the V2DF case: tmp = gen_rtx_VEC_SELECT (inner_mode, target, tmp); if (elt == 0) op0 = val, op1 = tmp; else op0 = tmp, op1 = val; tmp = gen_rtx_VEC_CONCAT (mode, op0, op1); looks the V2DI case has swapped operands.
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 --- Comment #5 from Richard Guenther 2012-02-28 11:06:16 UTC --- We have Creating dr for MEM[(int *)&a + 4B] base_address: &a offset from base address: 0 constant offset from base address: 4 step: 0 aligned to: 128 base_object: MEM[(int *)&a + 4B] Creating dr for a[1].f1 base_address: &a offset from base address: 0 constant offset from base address: 4 step: 0 aligned to: 128 base_object: a[0].f1 Access function 0: 1 thus we have an access function for a[1].f1 but no access function for MEM[(int *)&a + 4B]. That should cause it to conflict. (compute_affine_dependence (stmt_a = MEM[(int *)&a + 4B] = 1; ) (stmt_b = D.1724_6 = a[1].f1; ) (Data Dep: #(Data Ref: # bb: 5 # stmt: MEM[(int *)&a + 4B] = 1; # ref: MEM[(int *)&a + 4B]; # base_object: MEM[(int *)&a + 4B]; #) #(Data Ref: # bb: 5 # stmt: D.1724_6 = a[1].f1; # ref: a[1].f1; # base_object: a[0].f1; # Access function 0: 1 #) (no dependence) ) hmpf. dr_may_alias_p returns false because it feeds the oracle with the base objects!
[Bug target/52404] internal compiler error: in setup_min_max_allocno_live_range_point, at ira-build.c:2425
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52404 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther 2012-02-28 10:45:42 UTC --- Fixed. I can reproduce it on older trunk.
[Bug lto/52405] undefined references in shared library when linking the shared library with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-28 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-02-28 10:44:20 UTC --- Please specify how you build/link your shared library. Which binutils version are you using? Are you using the linker plugin? Does it work with -fno-use-linker-plugin? Does it work with -flto-partition=none?
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther 2012-02-28 10:42:47 UTC --- Mine.
[Bug target/52407] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-28 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-02-28 10:39:53 UTC --- It looks like a bug in the way we expand the vector init: ;; MEM[(int64_t *)&w + 8B] = 2; (insn 39 38 40 (set (reg:DI 102) (const_int 2 [0x2])) t.c:19 -1 (nil)) (insn 40 39 41 (set (reg:DI 103) (vec_select:DI (reg/v:V2DI 98 [ w ]) (parallel [ (const_int 0 [0]) ]))) t.c:19 -1 (nil)) (insn 41 40 0 (set (reg/v:V2DI 98 [ w ]) (vec_concat:V2DI (reg:DI 102) (reg:DI 103))) t.c:19 -1 (nil)) ^^^ should be vec_concat 103 102 ;; MEM[(int64_t *)&w] = 2; (insn 42 41 43 (set (reg:DI 104) (const_int 2 [0x2])) t.c:19 -1 (nil)) (insn 43 42 44 (set (reg:DI 105) (vec_select:DI (reg/v:V2DI 98 [ w ]) (parallel [ (const_int 1 [0x1]) ]))) t.c:19 -1 (nil)) (insn 44 43 0 (set (reg/v:V2DI 98 [ w ]) (vec_concat:V2DI (reg:DI 105) (reg:DI 104))) t.c:19 -1 (nil)) ^^^ should be vec_concat 104 105 no?
[Bug target/52415] New: memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
Bug #: 52415
Summary: memcpy to local variable generates unnecessary stack
frame for armv7
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.f...@gmail.com
This test case uses memcpy to load the bytes of a float into an int:
$ cat m.c
int f(float *p) {
int i;
__builtin_memcpy(&i, p, sizeof i);
return i;
}
When compiled for armv7 I get:
$ cc1 -o - -O3 m.c -quiet -march=armv7 -mthumb
...
f:
@ args = 0, pretend = 0, frame = 4
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrr0, [r0, #0]@ unaligned
subsp, sp, #4
strr0, [sp, #0]@ unaligned
ldrr0, [sp, #0]
addsp, sp, #4
bxlr
...
The stack frame is unnecessary; it could compile to just:
ldrr0, [r0, #0]
bxlr
I'm using trunk rev 184597, configured with --target=arm-elf.
[Bug rtl-optimization/52250] [4.7 Regression] ICE: in sel_remove_bb, at sel-sched-ir.c:5213 with -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fselective-scheduling2 and other flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250 --- Comment #8 from Alexander Monakov 2012-02-28 10:20:58 UTC --- Like Andrey said, we verify that x86_64-linux bootstraps with sel-sched when submitting patches, but I do not remember any specific figures from the times when I did benchmarking. It's a good suggestion do to it again in the next stage 1.
[Bug bootstrap/52414] [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 --- Comment #3 from Jakub Jelinek 2012-02-28 10:21:10 UTC --- Author: jakub Date: Tue Feb 28 10:21:03 2012 New Revision: 184624 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184624 Log: PR bootstrap/52414 * src/Makefile.am (libstdc++-symbols.ver): Only remove comment lines if they are at the beginning of lines (with optional whitespace before #). * src/Makefile.in: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 --- Comment #3 from Jakub Jelinek 2012-02-28 10:14:57 UTC --- Indeed, it is pcom that breaks it. Before pcom we have: MEM[(int *)&a + 4B] = 1; D.1723_6 = a[1].f1; but pcom doesn't consider the first store to be possibly affecting the load: a_I_f1_lsm0.14_26 = a[1].f1; : # d_lsm0.12_12 = PHI MEM[(int *)&a + 4B] = 1; D.1723_6 = a_I_f1_lsm0.14_26;
[Bug fortran/52387] I/O output of write after nonadvancing read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52387 Tobias Burnus changed: What|Removed |Added Summary|I/O wrong output with |I/O output of write after |nonadvancing output |nonadvancing read --- Comment #5 from Tobias Burnus 2012-02-28 09:58:37 UTC --- >From the J3 discussion: While Bob thinks that the standard is obvious, Van disagrees, cf. http://j3-fortran.org/pipermail/j3/2012-February/005067.html I wrote a draft IR, which is available at http://j3-fortran.org/pipermail/j3/2012-February/005069.html I intent to submit the IR for the next meeting (presumably J3 #198 jointly with WG5 at Toronto in June).
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406
--- Comment #2 from Jakub Jelinek 2012-02-28
09:54:01 UTC ---
Strangely,
/* PR tree-optimization/52406 */
extern void abort (void);
struct { int f1; } a[2];
int *b, *const k = &a[1].f1;
static int **c = &b;
int e, f, d;
int
main ()
{
int **l = &b;
*l = k;
for (; d <= 0; d++)
{
int *j = &e;
**c = 1;
*l = k;
*k ^= 0;
f = **l;
*j = f;
}
if (e != 1)
abort ();
return 0;
}
fails, but with
--- pr52406.c 2012-02-28 10:47:45.663204390 +0100
+++ pr52406.c 2012-02-28 10:47:56.695143490 +0100
@@ -1,9 +1,9 @@
/* PR tree-optimization/52406 */
extern void abort (void);
-struct { int f1; } a[2];
+int a[2];
-int *b, *const k = &a[1].f1;
+int *b, *const k = &a[1];
static int **c = &b;
int e, f, d;
it works (IL starts to differ during pcom), beyond the &a[1] vs. &a[1].f1
changes. So even if there isn't a wrong code, there would be at least
missed-optimization.
[Bug bootstrap/52414] [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Jakub Jelinek 2012-02-28 09:46:50 UTC --- Should be fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184621
[Bug bootstrap/52414] [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 Thomas Koenig changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Thomas Koenig 2012-02-28 09:45:40 UTC --- Adding release maintainer to CC.
[Bug bootstrap/52414] [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/52414] New: [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 Bug #: 52414 Summary: [4.7 Regression] syntax error in VERSION script Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org Target: powerpc64-unknown-linux-gnu Just found, booting on gcc110 with rev. 184613. Configuration was with ../trunk/configure --prefix=$HOME --enable-languages=c,fortran --with-ppl --with-cloog Last output: Checking multilib configuration for libgomp... Checking multilib configuration for libstdc++-v3... make[3]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3' make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/home/tkoenig/trunk-bin/./gcc/xgcc -B/home/tkoenig/trunk-bin/./gcc/" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2 -D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/home/tkoenig" "infodir=/home/tkoenig/share/info" "libdir=/home/tkoenig/lib" "includedir=/home/tkoenig/include" "prefix=/home/tkoenig" "tooldir=/home/tkoenig/powerpc64-unknown-linux-gnu" "gxx_include_dir=/home/tkoenig/include/c++/4.7.0" "AR=ar" "AS=/home/tkoenig/trunk-bin/./gcc/as" "LD=/home/tkoenig/trunk-bin/./gcc/collect-ld" "RANLIB=ranlib" "NM=/home/tkoenig/trunk-bin/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive make[4]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3' Making all in include make[5]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/include' make[5]: Für das Ziel »all« ist nichts zu tun. make[5]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/include' Making all in libsupc++ make[5]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++' make[5]: Für das Ziel »all« ist nichts zu tun. make[5]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++' Making all in src make[5]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src' Making all in c++98 make[6]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++98' make[6]: Für das Ziel »all« ist nichts zu tun. make[6]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++98' Making all in c++11 make[6]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++11' make[6]: Für das Ziel »all« ist nichts zu tun. make[6]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++11' make[6]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src' /bin/sh ../libtool --tag CXX --mode=link /home/tkoenig/trunk-bin/./gcc/xgcc -shared-libgcc -B/home/tkoenig/trunk-bin/./gcc -nostdin++ -L/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstc++-v3/src/.libs -B/home/tkoenig/powerpc64-unknown-linux-gnu/bin/ -B/home/tkoenig/powerpc64-unknown-linux-gnu/lib/ -isystem /home/tkonig/powerpc64-unknown-linux-gnu/include -isystem /home/tkoenig/powerpc64-unknown-linux-gnu/sys-include-Wl,-O1 -Wl,-z,relro -Wl,--c-sections -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:17:0 -Wl,--version-script=libstdc++-symbols.ver -lm -rpath /home/tkoenig/ib/../lib64 ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la libtool: link: /home/tkoenig/trunk-bin/./gcc/xgcc -shared-libgcc -B/home/tkoenig/trunk-bin/./gcc -nostdinc++ -L/home/tkoenig/trunk-bn/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/toenig/powerpc64-unknown-linux-gnu/bin/ -B/home/tkoenig/powerpc64-unknown-linux-gnu/lib/ -isystem /home/tkoenig/powerpc64-unknown-linu-gnu/include -isystem /home/tkoenig/powerpc64-unkno
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #1 from Jonathan Wakely 2012-02-28 09:39:21 UTC --- *** Bug 52410 has been marked as a duplicate of this bug. ***
[Bug c/52410] BUG gcc 4.6.2 Illegal Instruction (core dumped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52410 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely 2012-02-28 09:39:21 UTC --- submitted twice *** This bug has been marked as a duplicate of bug 52411 ***
[Bug libfortran/52413] New: Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 Bug #: 52413 Summary: Incorrect behavior of FRACTION when applied to a constant Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fro...@enseeiht.fr Hi, I have a problem when applying "fraction" to a numerical constant, e.g. fraction(-2.0); a minimal example says it all: program test_frac real::x,y x=-2.0 x=fraction(x) write(*,*)x y=fraction(-2.0) write(*,*)y end program test_frac The output is -0.5000 0.5000 while one would expect -0.5000 -0.5000 I experienced this with gfortran 4.4, 4.5 and 4.6 on Ubuntu systems. On ifort 12, the result is correct. Regards, FHR
[Bug tree-optimization/52395] [4.7 Regression] Too conservative alignment info from SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52395 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Richard Guenther 2012-02-28 09:19:27 UTC --- Fixed.
[Bug tree-optimization/52395] [4.7 Regression] Too conservative alignment info from SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52395 --- Comment #13 from Richard Guenther 2012-02-28 09:18:38 UTC --- Author: rguenth Date: Tue Feb 28 09:18:35 2012 New Revision: 184620 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184620 Log: 2012-02-28 Richard Guenther PR tree-optimization/52395 * tree-sra.c (build_ref_for_offset): Also look at the base TYPE_ALIGN when figuring out the alignment of the replacement. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
