[Bug c++/46836] reporting locations for names in std namespace could be improved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46836 --- Comment #8 from dodji at seketeli dot org 2012-05-30 07:34:17 UTC --- "manu at gcc dot gnu.org" a écrit: > Well, we already have pragma system_header, we could extend it with an > optional > parameter. > > #pragma GCC system_header "canonical_name" Seconded.
[Bug c++/51927] [C++0x] Cannot access non-static members in initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51927 --- Comment #1 from gccearlyadop...@trash-mail.com 2012-05-30 07:48:35 UTC --- This Bug still exists in the latest GCC 4.7 release.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsupressable enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-30 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez 2012-05-30 07:57:59 UTC --- That input_location is pointing to something so bogus makes me think that something weird is going on. In any case, it would be interesting to know why same_type fails a few lines above, and whether it is true that g++ is not doing the two-phase typing properly. The following also warns, so the type of the enum values does not seem to be the issue: N2 = 0 ? PointerLikeTypeTraits < PT1 >::NumLowBitsAvailable : PointerLikeTypeTraits < PT2 >::NumLowBitsAvailable,
[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #19 from Jonathan Wakely 2012-05-30
08:17:07 UTC ---
(In reply to comment #13)
> Am I interpreting correctly that double braces are /required/ for std::array
> init lists but only when the subtype has has a multivariable initializer too?
>
> ..
Yes. Double braces are always correct and always allowed, but you can omit
them if the result is unambiguous, e.g. array{1,2,3} is equivalent to
array{{1,2,3}}
But if the array's value_type is to be initialized with a
braced-initializer-list then you need a completely-braced initialization so
that the initializer-list for the value_type doesn't get interpreted as an
initializer for the value_type[N] array.
It still shouldn't crash the compiler though :)
[Bug fortran/53521] [4.3/4.4/4.5/4.6/4.7/4.8 Regression] Zero-byte memory leak with zero-sized array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 Tobias Burnus changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Known to work||4.1.2 Keywords||wrong-code Last reconfirmed||2012-05-30 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Memory leak with zero sized |[4.3/4.4/4.5/4.6/4.7/4.8 |array constructor |Regression] Zero-byte ||memory leak with zero-sized ||array constructor Target Milestone|--- |4.6.4 Known to fail||4.3.4, 4.4.0, 4.5.3, 4.6.3, ||4.7.0, 4.8.0 --- Comment #1 from Tobias Burnus 2012-05-30 08:30:39 UTC --- Confirmed. Valgrind shows with GCC 4.1 "no leaks are possible" while for GCC 4.3 to 4.8, it shows: ==25714== HEAP SUMMARY: ==25714== in use at exit: 0 bytes in 1 blocks That's not much memory, but I concur that it clutters the valgrind output. With --leak-check=full: 0 bytes in 1 blocks are definitely lost in loss record 1 of 1 at 0x4C2ABED: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x4C2AD6F: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x400876: __test_MOD_t2 (test.f90:10) by 0x400999: MAIN__ (test.f90:14) by 0x4009CF: main (test.f90:13) >From the dump: atmp.0.data = 0B; D.1888 = __builtin_realloc ((void *) atmp.0.data, D.1887); atmp.0.data = (void * restrict) D.1888; ... D.1883 = (void *) atmp.0.data; if (D.1883 != 0B) __builtin_free (D.1883); One possibility would be to simply remove the "if": First, free also handles the case of "freeing" NULL, secondly, for temporary variables "NULL" is a rare (or nonexisting) special case (i.e. it hampers rather than helps optimization), and, thirdly, this PR shows that also zero-sized NULL-pointers should be freed.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-30 Ever Confirmed|0 |1 --- Comment #11 from Richard Guenther 2012-05-30 08:38:15 UTC --- Confirmed.
[Bug c++/51927] [C++0x] Cannot access non-static members in initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51927 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-30 Ever Confirmed|0 |1 Known to fail||4.7.1, 4.8.0 --- Comment #2 from Jonathan Wakely 2012-05-30 08:38:03 UTC --- 4.7.0 *is* the latest GCC release :) Anyway, confirmed, the example looks valid to me.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #5 from Paolo Carlini 2012-05-30 08:52:09 UTC --- Note that in any case in current mainline the location is exactly the '?' of the conditional expression: maybe the error message doesn't make sense but lately we are making progress on the locations ;)
[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #20 from Paolo Carlini 2012-05-30 08:54:39 UTC --- Good, good, then let me fix the ICE.
[Bug bootstrap/53522] [4.8 Regression] Bootstrap is broken for x86_64-apple-darwin10 at r187977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53522 --- Comment #2 from rguenther at suse dot de 2012-05-30 09:11:53 UTC --- On Tue, 29 May 2012, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53522 > > Dominique d'Humieres changed: > >What|Removed |Added > > Summary|[4.8 Summary] Bootstrap is |[4.8 Regression] Bootstrap >|broken for |is broken for >|x86_64-apple-darwin10 at|x86_64-apple-darwin10 at >|r187977 |r187977 > > --- Comment #1 from Dominique d'Humieres > 2012-05-29 22:34:58 UTC --- > It was too late;-( I'll install Index: gcc/tree-emutls.c === --- gcc/tree-emutls.c (revision 187965) +++ gcc/tree-emutls.c (working copy) @@ -434,7 +434,6 @@ gen_emutls_addr (tree decl, struct lower addr = create_tmp_var (build_pointer_type (TREE_TYPE (decl)), NULL); x = gimple_build_call (d->builtin_decl, 1, build_fold_addr_expr (cdecl)); gimple_set_location (x, d->loc); - add_referenced_var (cdecl); addr = make_ssa_name (addr, x); gimple_call_set_lhs (x, addr); as obvious
[Bug bootstrap/53522] [4.8 Regression] Bootstrap is broken for x86_64-apple-darwin10 at r187977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53522 --- Comment #3 from Richard Guenther 2012-05-30 09:14:35 UTC --- Author: rguenth Date: Wed May 30 09:14:27 2012 New Revision: 188005 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188005 Log: 2012-05-30 Richard Guenther PR middle-end/53522 * tree-emutls.c (gen_emutls_addr): Do not add globals to referenced-vars. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-emutls.c
[Bug bootstrap/53522] [4.8 Regression] Bootstrap is broken for x86_64-apple-darwin10 at r187977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53522 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Richard Guenther 2012-05-30 09:16:21 UTC --- Fixed.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 Richard Guenther changed: What|Removed |Added Keywords||diagnostic Version|unknown |4.7.1 Target Milestone|--- |4.7.1
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte memory leak with zero-sized array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 Richard Guenther changed: What|Removed |Added Summary|[4.3/4.4/4.5/4.6/4.7/4.8|[4.5/4.6/4.7/4.8 |Regression] Zero-byte |Regression] Zero-byte |memory leak with zero-sized |memory leak with zero-sized |array constructor |array constructor --- Comment #2 from Richard Guenther 2012-05-30 09:54:31 UTC --- Well, I think this is a valgrind issue and not a real "leak". Whether you want to "optimize" code for the non-NULL case by omitting the NULL check is another question of course. It's definitely not wrong-code IMHO.
[Bug tree-optimization/53501] [4.5/4.6/4.7/4.8 Regression] scev introduces signed overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53501 Richard Guenther changed: What|Removed |Added Keywords||wrong-code Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.5.4 --- Comment #2 from Richard Guenther 2012-05-30 09:56:21 UTC --- Confirmed, mine.
[Bug fortran/53526] New: [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526 Bug #: 53526 Summary: [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org MOVE_ALLOC needs to be properly handled for coarrays. Cf. F08/0040 at http://j3-fortran.org/doc/year/12/12-006A.txt and http://j3-fortran.org/pipermail/j3/2012-May/005310.html and http://gcc.gnu.org/ml/fortran/2012-05/msg00156.html and http://gcc.gnu.org/ml/fortran/2012-05/msg00166.html TODO: - Check whether an (implied) SYNC ALL has to be inserted -> The main issue is probably the deallocation of TO; probably no extra care is required, except to ensure that the deallocation is properly done. - Check whether the "token" is correctly transferred - Check whether some library action is required. -> Probably not. >From F08/0040: QUESTION: Was it intended that MOVE_ALLOC be applicable to coarrays? ANSWER: Yes. A call to MOVE_ALLOC on coarrays might involve the deallocation of a coarray, therefore MOVE_ALLOC needs to be an image control statement. Also, the corank of FROM and TO needs to be the same.
[Bug fortran/53526] [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-05-30 10:10:34 UTC --- Extra TODO: Check whether the library has/should have a short cut for DEALLOCATE if the memory is NULL. The free() might be still required (to avoid valgrind warnings, cf. PR 53521) as might be the SYNC ALL to ensure code of the following kind works: if (this_image() == 2) & A[1] = 5 call move_alloc(...) if (this_image() == 1) & print *, A
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
Paolo Carlini changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot
|gnu.org |com
--- Comment #6 from Paolo Carlini 2012-05-30
10:22:33 UTC ---
The warnings are an unintended effect of my fix for PR16603.
We warn at the end of the below lines of call.c. At the moment isn't clear to
me *when* it would actually make sense to warn. Hints?
///
/* [expr.cond]
After those conversions, one of the following shall hold:
--The second and third operands have the same type; the result is of
that type. */
if (same_type_p (arg2_type, arg3_type))
result_type = arg2_type;
/* [expr.cond]
--The second and third operands have arithmetic or enumeration
type; the usual arithmetic conversions are performed to bring
them to a common type, and the result is of that type. */
else if ((ARITHMETIC_TYPE_P (arg2_type)
|| UNSCOPED_ENUM_P (arg2_type))
&& (ARITHMETIC_TYPE_P (arg3_type)
|| UNSCOPED_ENUM_P (arg3_type)))
{
/* In this case, there is always a common type. */
result_type = type_after_usual_arithmetic_conversions (arg2_type,
arg3_type);
do_warn_double_promotion (result_type, arg2_type, arg3_type,
"implicit conversion from %qT to %qT to "
"match other result of conditional",
input_location);
if (TREE_CODE (arg2_type) == ENUMERAL_TYPE
&& TREE_CODE (arg3_type) == ENUMERAL_TYPE)
{
if (complain & tf_warning)
warning (0,
"enumeral mismatch in conditional expression: %qT vs %qT",
arg2_type, arg3_type);
}
[Bug tree-optimization/53501] [4.5/4.6/4.7/4.8 Regression] scev introduces signed overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53501
--- Comment #3 from Richard Guenther 2012-05-30
10:34:50 UTC ---
It's my very best friend extract_muldiv that transforms
(int)((unsigned int) n.0_26 + 4294967295) * 2
to (int)(((unsigned int) n.0_26 + 2147483647) * 2)
It is the folding of (int) (((unsigned int) n.0_26 + 2147483647) * 2) + 2
which is wrong and done by fold_plusminus_mult_expr. Patch:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 188004)
+++ gcc/fold-const.c(working copy)
@@ -10045,12 +10045,12 @@ fold_binary_loc (location_t loc,
/* Handle (A1 * C1) + (A2 * C2) with A1, A2 or C1, C2 being the
same or one. Make sure type is not saturating.
fold_plusminus_mult_expr will re-associate. */
- if ((TREE_CODE (arg0) == MULT_EXPR
- || TREE_CODE (arg1) == MULT_EXPR)
+ if ((TREE_CODE (op0) == MULT_EXPR
+ || TREE_CODE (op1) == MULT_EXPR)
&& !TYPE_SATURATING (type)
&& (!FLOAT_TYPE_P (type) || flag_associative_math))
{
- tree tem = fold_plusminus_mult_expr (loc, code, type, arg0, arg1);
+ tree tem = fold_plusminus_mult_expr (loc, code, type, op0, op1);
if (tem)
return tem;
}
that will leave the expression unsimplified.
[Bug java/53527] New: 4.7.0 release can't enable java language
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53527
Bug #: 53527
Summary: 4.7.0 release can't enable java language
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: licheng.1...@gmail.com
[licheng@localhost build]$ ../configure --prefix=${PREFIX} --target=${TARGET}
--with-newlib --with-headers=../../newlib-1.20.0/newlib/libc/include/
--with-ar=${PREFIX}/bin/${TARGET}-ar --with-as=${PREFIX}/bin/${TARGET}-as
--with-ld=${PREFIX}/bin/${TARGET}-ld --with-mpfr=${PREFIX} --with-gmp=${PREFIX}
--with-ppl=${PREFIX} --with-cloog=${PREFIX} --with-mpc=${PREFIX}
--enable-languages=c,c++,java --disable-multilib
--with-gcc-version-trigger=../gcc/version.c --disable-libstdcxx-pch
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... mips-unknown-elf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for libitm support... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gnatbind... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for PWL_handle_timeout in -lpwl... yes
checking for version 0.11 (revision 0 or later) of PPL... yes
checking for installed CLooG PPL Legacy... PPL Legacy
checking for version 0.15.5 (or later revision) of CLooG... yes
configure: error:
The following requested languages could not be built: java
Supported languages are: c,c++,fortran,go,lto,objc,obj-c++
gcc 4.4.2 is OK
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
Paolo Carlini changed:
What|Removed |Added
CC||g...@integrable-solutions.ne
||t
--- Comment #7 from Paolo Carlini 2012-05-30
11:06:20 UTC ---
Let's add in CC Gaby, in the testsuite I see the warning triggering outside
templates for a testcase coming from a bug report of him,
g++.old-deja/g++.other/cond5.C, we have:
enum E1 {e1 = -1};
enum E2 {e2 = -1};
int j;
j = (i ? e1 : e2);// { dg-warning "mismatch" }
Shall we not warn by default? Shall we give the warning a name (which?) and add
it to -Wall? To -Wextra? Neither?
[Bug java/53527] 4.7.0 release can't enable java language
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53527 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther 2012-05-30 11:14:26 UTC --- mips-unknown-elf is not a hosted platform and thus does not support Java.
[Bug tree-optimization/53501] [4.5/4.6/4.7/4.8 Regression] scev introduces signed overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53501 --- Comment #4 from Richard Guenther 2012-05-30 12:29:31 UTC --- Author: rguenth Date: Wed May 30 12:29:26 2012 New Revision: 188009 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188009 Log: 2012-05-30 Richard Guenther PR middle-end/53501 * fold-const.c (fold_binary_loc): Make sure to call fold_plusminus_mult_expr with the original sign of operands. * gcc.dg/torture/pr53501.c: New testcase. * c-c++-common/restrict-2.c: Adjust. Added: trunk/gcc/testsuite/gcc.dg/torture/pr53501.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/restrict-2.c
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte "memory leak" with zero-sized array constructor (valgrind warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 --- Comment #3 from Joost VandeVondele 2012-05-30 12:31:18 UTC --- (In reply to comment #2) > Well, I think this is a valgrind issue and not a real "leak". Whether you > want to "optimize" code for the non-NULL case by omitting the NULL check is > another question of course. It's definitely not wrong-code IMHO. No, definitely a real bug... not a valgrind issue. If you put a loop around 'CALL T2' the process memory usage is a >1Gb in a few seconds. This is a real issue which causes our simulation code to crash after 24h of running.
[Bug tree-optimization/53501] [4.5/4.6/4.7/4.8 Regression] scev introduces signed overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53501 --- Comment #5 from Richard Guenther 2012-05-30 12:32:17 UTC --- Author: rguenth Date: Wed May 30 12:32:10 2012 New Revision: 188010 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188010 Log: 2012-05-30 Richard Guenther PR middle-end/53501 * fold-const.c (fold_binary_loc): Make sure to call fold_plusminus_mult_expr with the original sign of operands. * gcc.dg/torture/pr53501.c: New testcase. * c-c++-common/restrict-2.c: Adjust. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53501.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/fold-const.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/c-c++-common/restrict-2.c
[Bug tree-optimization/53501] [4.5/4.6 Regression] scev introduces signed overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53501 Richard Guenther changed: What|Removed |Added Known to work||4.7.1, 4.8.0 Summary|[4.5/4.6/4.7/4.8|[4.5/4.6 Regression] scev |Regression] scev introduces |introduces signed overflow |signed overflow | Known to fail||4.7.0 --- Comment #6 from Richard Guenther 2012-05-30 12:34:22 UTC --- Fixed on the trunk and the 4.7 branch for now.
[Bug c++/51927] [C++0x] Cannot access non-static members in initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51927 --- Comment #3 from gccearlyadop...@trash-mail.com 2012-05-30 12:34:12 UTC --- My local GCC says "4.7.0_3". :)
[Bug middle-end/48493] [4.6/4.7 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 Richard Guenther changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ice in |ice in |expand_expr_addr_expr_1 |expand_expr_addr_expr_1 |with complex types and |with complex types and |mem_ref |mem_ref | --- Comment #11 from Richard Guenther 2012-05-30 12:42:28 UTC --- Can somebody test Index: gcc/expr.c === --- gcc/expr.c (revision 188009) +++ gcc/expr.c (working copy) @@ -4593,6 +4593,7 @@ expand_assignment (tree to, tree from, b if ((TREE_CODE (to) == MEM_REF || TREE_CODE (to) == TARGET_MEM_REF) && mode != BLKmode + && !mem_ref_refers_to_non_mem_p (to) && ((align = get_object_or_type_alignment (to)) < GET_MODE_ALIGNMENT (mode)) && ((icode = optab_handler (movmisalign_optab, mode)) on arm? That's pre-approved if it passes bootstrap & regtest (it works on the testcase with a cross and is an obvious partial backport from trunk r185336). Thus, the testcase works for me on trunk.
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte "memory leak" with zero-sized array constructor (valgrind warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 --- Comment #4 from Richard Guenther 2012-05-30 12:46:53 UTC --- You say not doing free (0) leaks memory? What OS is this on? Note that we fold such calls away: case BUILT_IN_FREE: if (integer_zerop (arg0)) return build_empty_stmt (loc);
[Bug c++/53528] New: Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 Bug #: 53528 Summary: Support C++11 generalized attributes Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: do...@gcc.gnu.org G++ should support the generalized attributes feature presented in the N2761 paper at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf.
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-30 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/53356] [4.7/4.8 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4258
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53356 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug preprocessor/51776] fixincludes hacks around a C++ deficiency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51776 Jonathan Wakely changed: What|Removed |Added Depends on||53528 --- Comment #2 from Jonathan Wakely 2012-05-30 13:33:18 UTC --- adding the "Support C++11 generalized attributes" PR as a dependency so Bruce gets prodded when it changes state
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 --- Comment #1 from joseph at codesourcery dot com 2012-05-30 13:47:38 UTC --- Note that the syntactic binding of C++11 attributes is different from that of GNU attributes in various cases, so the front end will need to track separately what attributes of each syntax have been used in various places.
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte "memory leak" with zero-sized array constructor (valgrind warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek 2012-05-30
13:49:51 UTC ---
That is clearly a bug in the Fortran FE.
D.1888 = (integer(kind=4)[0] * restrict) __builtin_realloc ((void *)
atmp.0.data, D.1887);
if (D.1888 == 0B && D.1887 != 0)
{
_gfortran_os_error (&"Allocation would exceed memory limit"[1]{lb: 1
sz: 1});
}
if (D.1887 == 0)
{
D.1888 = 0B;
}
means that D.1888 isn't freed. POSIX says that realloc (x, 0) acts as free
only if x is not NULL, realloc (NULL, 0) acts as malloc (0), which can either
return NULL, or a unique pointer that needs to be freed.
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte "memory leak" with zero-sized array constructor (valgrind warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 --- Comment #6 from Joost VandeVondele 2012-05-30 14:37:09 UTC --- (In reply to comment #4) > You say not doing free (0) leaks memory? What OS is this on? I'm observing on a Linux box that : MODULE TEST IMPLICIT NONE CONTAINS SUBROUTINE T(n1) INTEGER :: n1(:) END SUBROUTINE T SUBROUTINE T2(n) INTEGER :: n INTEGER :: k CALL T((/(k,k=1,n-1)/)) END SUBROUTINE END MODULE USE TEST DO CALL T2(1) ENDDO END needs 25Gb of memory after a while (notice the endless loop around CALL T2).
[Bug lto/53019] [4.7 regression] ICE (segfault) with -flto=jobserver -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53019 Richard Guenther changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Richard Guenther 2012-05-30 14:38:37 UTC --- Fixed on trunk, no longer reproduces on the 4.7 branch for me (rev. 188004), reproduces with branch rev. 187228. Can you re-check please?
[Bug c++/53356] [4.7/4.8 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4258
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53356 --- Comment #4 from Jason Merrill 2012-05-30 14:50:49 UTC --- Author: jason Date: Wed May 30 14:50:44 2012 New Revision: 188019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188019 Log: PR c++/53356 * tree.c (stabilize_init): Side effects make the init unstable. Added: trunk/gcc/testsuite/g++.dg/init/new33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220 --- Comment #16 from Jason Merrill 2012-05-30 14:51:58 UTC --- Author: jason Date: Wed May 30 14:51:54 2012 New Revision: 188020 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188020 Log: PR c++/53220 gcc/ * c-typeck.c (array_to_pointer_conversion): Give -Wc++-compat warning about array compound literals. gcc/cp/ * call.c (convert_like_real) [ck_list]: Take array address directly. * typeck.c (decay_conversion): Reject decay of an array compound literal. Added: branches/gcc-4_7-branch/gcc/testsuite/c-c++-common/array-lit.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/c-typeck.c branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/cp/typeck.c branches/gcc-4_7-branch/gcc/doc/extend.texi branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/g++.dg/ext/complit12.C
[Bug c++/53356] [4.7/4.8 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4258
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53356 --- Comment #5 from Jason Merrill 2012-05-30 14:52:06 UTC --- Author: jason Date: Wed May 30 14:52:02 2012 New Revision: 188021 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188021 Log: PR c++/53356 * tree.c (stabilize_init): Side effects make the init unstable. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/new33.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/tree.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug lto/53471] [4.7/4.8 Regression] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471
Richard Guenther changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Richard Guenther 2012-05-30
14:59:26 UTC ---
On the 4.7 branch I get this ICE triggered from
#1 0x0070af4f in comptypes (t1=0x72a4c3f0, t2=0x72dfab28,
strict=0) at /space/rguenther/src/svn/gcc-4_7-branch/gcc/cp/typeck.c:1393
1393 ("canonical types differ for identical types %T and %T",
thus another ICE. It happens because we call decl_assembler_name from
dwarf2out_finish, something we shouldn't do with the frontend langhooks
still in place.
#13 0x00a6543f in dwarf2out_finish (filename=0x7fffe379 "t.ii")
at /space/rguenther/src/svn/gcc-4_7-branch/gcc/dwarf2out.c:22585
22585 if (DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
(gdb) l
22580 move_marked_base_types ();
22581
22582 for (node = deferred_asm_name; node; node = node->next)
22583 {
22584 tree decl = node->created_for;
22585 if (DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
22586 {
22587 add_linkage_attr (node->die, decl);
22588 move_linkage_attr (node->die);
22589 }
that's a general issue though. The issue is, this is a FUNCTION_DECL,
it qualifies for need_assembler_name_p but it doesn't have it set. Thus,
in
static void
free_lang_data_in_cgraph (void)
{
...
/* Find decls and types in the body of every function in the callgraph. */
for (n = cgraph_nodes; n; n = n->next)
find_decls_types_in_node (n, &fld);
...
/* Set the assembler name on every decl found. We need to do this
now because free_lang_data_in_decl will invalidate data needed
for mangling. This breaks mangling on interdependent decls. */
FOR_EACH_VEC_ELT (tree, fld.decls, i, t)
assign_assembler_name_if_neeeded (t);
we do not come along this FUNCTION_DECL. dwarf2out.c reaches it via
TYPE_METHODS which we clear. So we do not reach that type in walking
all types in free-lang-data. dwarf2out.c comes along it via
#12 0x00d499d1 in rest_of_type_compilation (type=0x72e001f8,
toplev=1) at /space/rguenther/src/svn/gcc-4_7-branch/gcc/passes.c:238
238 debug_hooks->type_decl (TYPE_STUB_DECL (type), !toplev);
(gdb) l
233 errors. */
234 if (seen_error ())
235 return;
236
237 timevar_push (TV_SYMOUT);
238 debug_hooks->type_decl (TYPE_STUB_DECL (type), !toplev);
(gdb) up
#13 0x0065d4d0 in finish_struct_1 (t=0x72e001f8)
at /space/rguenther/src/svn/gcc-4_7-branch/gcc/cp/class.c:6133
6133 rest_of_type_compilation (t, ! LOCAL_CLASS_P (t));
thus explicitely pushes it.
I suppose rest_of_type_compilation could queue the type in a list later
processed by free-lang-data. Or we should not defer computation of
DECL_ASSEMBLER_NAME in dwarf2out.c here. Which I would like more.
Jason - do you remember why we do that?
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 Richard Guenther changed: What|Removed |Added Attachment #23837|0 |1 is obsolete|| Attachment #26546|0 |1 is obsolete|| --- Comment #21 from Richard Guenther 2012-05-30 15:03:11 UTC --- Created attachment 27525 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27525 backport of patch and followups from trunk Bootstrapped on x86_64-unknown-linux-gnu.
[Bug middle-end/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53518 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-30 CC||hubicka at gcc dot gnu.org Component|libstdc++ |middle-end Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #3 from Rainer Orth 2012-05-30 15:24:03 UTC --- A reghunt identified the following patch as the culprit: 2012-05-18 Jan Hubicka * cgraphbuild.c (record_reference): Update. * lto-cgraph.c (lto_output_varpool_node): External vars are not in other partition even if they are not output in current partition. * gimple-fold.c (can_refer_decl_in_current_unit_p): Take FROM_DECL argument; fix. (canonicalize_constructor_val): Take FROM_DECL argument. (fold_ctor_reference, fold_string_cst_ctor_reference, fold_array_ctor_reference, fold_nonarray_ctor_reference, fold_ctor_reference): Likewise. (fold_const_aggregate_ref_1, gimple_get_virt_method_for_binfo): Update. * gimple.h (gimple_fold_builtin): Likewise. Jan, what additional information do you need to investigate? Thanks. Rainer
[Bug c/53529] New: assembler errors while building a cross compiler if . (dot) is in your PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529 Bug #: 53529 Summary: assembler errors while building a cross compiler if . (dot) is in your PATH Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernard.van.duij...@oracle.com If you have . (current directory) in your PATH in front of the location of the system assembler (typically /usr/bin/as) then while building the cross compiler the wrong assembler is called, resulting in errors about an unrecognized option or bad opcodes. The mixup is with the generated shell script as in the gcc sub directory of the build tree. This shell script points to the target-as and at this stage the host-as is needed. Took me quit a while to diagnose the root cause as this is not so easy to find.
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #22 from Eric Botcazou 2012-05-30 15:28:14 UTC --- > Bootstrapped on x86_64-unknown-linux-gnu. This also needs to be tested on 32-bit and strict-alignment platforms.
[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2012-05-30 15:35:18 UTC --- Don't do it then? Having . in $PATH is a severe security issue anyway.
[Bug c/53530] New: const variables not constant enough to be used as initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53530
Bug #: 53530
Summary: const variables not constant enough to be used as
initializers
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cpy.prefers@gmail.com
Initializations using constant variables generates an error.
When compiling the following source code, GCC gives `error: initializer element
is not constant`, while Clang made it successfully.
/* this is test.c */
/* compile me using `gcc test.c -c` or `clang test.c -c` */
static const int a = 0; /* in GCC I have to initialize it explicitly, to */
/* ensure that it would to be placed into */
/* .rodata section (or maybe .text) */
static int b[] = { [0] = a, };
/* end of test.c */
I'm currently using `gcc (GCC) 4.7.0 20120505 (prerelease)` on a laptop with
GNU/Linux.
[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529 --- Comment #2 from Bernard van Duijnen 2012-05-30 15:49:43 UTC --- (In reply to comment #1) > Don't do it then? Having . in $PATH is a severe security issue anyway. Typically it is unsecure yes, but not always. For instance on my ubuntu laptop where I am the one and only user I do not think that is an issue. Its easy to fix your PATH to solve it, but only once you know that is the issue, just a check to catch the situation and give a warning is a sufficient solution.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 --- Comment #12 from jimis 2012-05-30 15:55:19 UTC --- I should probably explain where the problem is and why I've left a memory leak. In tokens_buff_new() I can't use XOBNEWVEC() instead of XNEWVEC() because it is not guarded from the obstack_mark/release() calls in enter_macro_context() and it messes up previously allocated objects when going back in the recursion. The thing I don't get and so I can't figure out a solution, is where the virt_locs vector allocated inside tokens_buff_new() is freed. For example when it is called from the path cpp_get_token_1->paste_all_tokens->tokens_buff_new(), then when is the virt locs vector actually freed?
[Bug c/53530] const variables not constant enough to be used as initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53530 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andreas Schwab 2012-05-30 16:03:51 UTC --- . *** This bug has been marked as a duplicate of bug 53091 ***
[Bug c/53091] static initializer accepted by clang but not by gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53091 Andreas Schwab changed: What|Removed |Added CC||cpy.prefers.you at gmail ||dot com --- Comment #15 from Andreas Schwab 2012-05-30 16:03:51 UTC --- *** Bug 53530 has been marked as a duplicate of this bug. ***
[Bug c++/53531] New: <,,,,> accepted as template arguments for variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53531 Bug #: 53531 Summary: <> accepted as template arguments for variadic template Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org template struct S; int i = S<>::undefined;
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
--- Comment #8 from Manuel López-Ibáñez 2012-05-30
16:29:08 UTC ---
(In reply to comment #6)
> The warnings are an unintended effect of my fix for PR16603.
So, before your fix, same_type_p was returning true?
enum { e1 = -1 };
enum { e2 = -1 };
int j;
void foo(void) {
j = 0 ? e1 : e2;
}
g++ 4.3.2
tt.cc:6: warning: enumeral mismatch in conditional expression: ‘’ vs ‘’
So, the warning is intended, and the fact that we did not warn before was a
bug. However, it is not clear to me how this code can be dangerous. But the
warning is very very old.
r29056 | nathan | 1999-09-02 11:21:42 +0200 (Thu, 02 Sep 1999) | 4 lines
* call.c (build_conditional_expr): Warn on enum mismatches.
(convert_arg_to_ellipsis): Move non-pod check to after
conversion.
[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502 --- Comment #8 from Tobias Burnus 2012-05-30 16:44:49 UTC --- Author: burnus Date: Wed May 30 16:44:42 2012 New Revision: 188024 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188024 Log: 2012-05-30 Tobias Burnus PR c/53502 * decl.c (match_attr_spec): Remove "typedef". Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c
[Bug c/53532] New: function call ignored when called with argument of incompatible, undefined structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53532
Bug #: 53532
Summary: function call ignored when called with argument of
incompatible, undefined structure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mach...@post.cz
The following code...
struct aaa {};
extern int xxx(struct aaa e);
int main() {
xxx((struct bbb) {});
return 0;
}
... compiles without warnings and the call to xxx is ignored:
# gcc -Wall -Wextra -c foo.c
# objdump -x foo.o
[...]
Disassembly of section .text:
:
0:55 push %rbp
1:48 89 e5 mov%rsp,%rbp
4:b8 00 00 00 00 mov$0x0,%eax
9:5d pop%rbp
a:c3 retq
[...]
The code above seems invalid, and I think that gcc should reject it.
The definition of struct aaa is somehow important. When dropped, GCC realizes
things are wrong, and complains abundantly.
# LANG=C gcc -Wall -Wextra -x c /dev/stdin
extern int xxx(struct aaa e);
int main() {
xxx((struct bbb) {});
return 0;
}
/dev/stdin:1:23: warning: 'struct aaa' declared inside parameter list [enabled
by default]
/dev/stdin:1:23: warning: its scope is only this definition or declaration,
which is probably not what you want [enabled by default]
/dev/stdin: In function 'main':
/dev/stdin:3:15: error: type of formal parameter 1 is incomplete
It also complains about struct bbb being incomplete, which it didn't mind at
all while aaa was there.
[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502 --- Comment #9 from Tobias Burnus 2012-05-30 16:52:17 UTC --- (In reply to comment #8) > New Revision: 188024 That patch removed the typedef from gcc/fortran/decl.c. Hence, --disable-build-poststage1-with-cxx should work now. Whether GCC should warn for the typedef in C or in C++ mode or in both or in neither, I leave to the experts. See comment 6 for observations related to the latter.
[Bug middle-end/48493] [4.6/4.7 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #12 from Andrew Pinski 2012-05-30 17:05:49 UTC --- >on arm? That's pre-approved if it passes bootstrap & regtest I will try it on MIPS since I saw the exact same ICE and the exact same "(concat:SC (reg/v:SF 134 [ s ]) (reg/v:SF 135 [ s+4 ]))" .
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #9 from Paolo Carlini 2012-05-30 17:22:45 UTC --- I think there is a largely linguistic misunderstanding: when I said unintended I meant that I did not *anticipate* that after my patch, which was fixing a real bug, we would end up warning more, in templates too. For sure the testcase I mentioned in my last message pre existed and likewise the code I posted here. In my opinion the warning, by itself, definitely makes sense in general, but it looks like, we may not want it uncinditionally, we may want to control it, otherwise can be annoying in the template contexts mentioned here. Do you agree with my summary? In practice: shall we give the warning a name and a switch?
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
--- Comment #10 from Lawrence Crowl 2012-05-30
17:37:37 UTC ---
(In reply to comment #6)
> The warnings are an unintended effect of my fix for PR16603.
>
> We warn at the end of the below lines of call.c. At the moment isn't clear to
> me *when* it would actually make sense to warn. Hints?
>
> ///
>
> /* [expr.cond]
>
> After those conversions, one of the following shall hold:
>
> --The second and third operands have the same type; the result is of
>that type. */
> if (same_type_p (arg2_type, arg3_type))
> result_type = arg2_type;
> /* [expr.cond]
>
> --The second and third operands have arithmetic or enumeration
>type; the usual arithmetic conversions are performed to bring
>them to a common type, and the result is of that type. */
> else if ((ARITHMETIC_TYPE_P (arg2_type)
> || UNSCOPED_ENUM_P (arg2_type))
>&& (ARITHMETIC_TYPE_P (arg3_type)
>|| UNSCOPED_ENUM_P (arg3_type)))
> {
> /* In this case, there is always a common type. */
> result_type = type_after_usual_arithmetic_conversions (arg2_type,
> arg3_type);
> do_warn_double_promotion (result_type, arg2_type, arg3_type,
> "implicit conversion from %qT to %qT to "
> "match other result of conditional",
> input_location);
>
> if (TREE_CODE (arg2_type) == ENUMERAL_TYPE
> && TREE_CODE (arg3_type) == ENUMERAL_TYPE)
> {
> if (complain & tf_warning)
> warning (0,
> "enumeral mismatch in conditional expression: %qT vs
> %qT",
> arg2_type, arg3_type);
> }
In order to get this error, both arg2 and arg3 must be interpreted as enum
types. However, in the testcase, we are still in the enum definition, and
we are referring to enumerators in that definition, so at that point the
types of the arguments should be some form of int. That is, the compiler
should either change the types of the enumerators at the closing brace, or
look through the enumerator's enum type to its underlying type while in
the definition that encloses the enumerator.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
--- Comment #11 from Lawrence Crowl 2012-05-30
17:42:14 UTC ---
(In reply to comment #7)
> Let's add in CC Gaby, in the testsuite I see the warning triggering outside
> templates for a testcase coming from a bug report of him,
> g++.old-deja/g++.other/cond5.C, we have:
>
> enum E1 {e1 = -1};
> enum E2 {e2 = -1};
>
> int j;
>
> j = (i ? e1 : e2);// { dg-warning "mismatch" }
>
> Shall we not warn by default? Shall we give the warning a name (which?) and
> add
> it to -Wall? To -Wextra? Neither?
I believe this testcase is different and the warning is correct.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
--- Comment #12 from Manuel López-Ibáñez 2012-05-30
17:43:38 UTC ---
(In reply to comment #9)
> I think there is a largely linguistic misunderstanding: when I said unintended
> I meant that I did not *anticipate* that after my patch, which was fixing a
> real bug, we would end up warning more, in templates too. For sure the
> testcase
> I mentioned in my last message pre existed and likewise the code I posted
> here.
> In my opinion the warning, by itself, definitely makes sense in general, but
> it
> looks like, we may not want it uncinditionally, we may want to control it,
> otherwise can be annoying in the template contexts mentioned here. Do you
> agree
> with my summary? In practice: shall we give the warning a name and a switch?
Well, personally I think all warnings should have a switch, -Wenum-mismatch ?
But I don't see why the fact that it is triggered within a template makes a
difference:
enum { e1 };
enum { e2 };
enum {
a1 = e1,
a2 = e2,
a3 = 0 ? a1 : a2,
a4 = 0 ? e1 : e2,
};
int j;
void foo(void) {
j = a3;
}
I think what we don't want to warn for a3 but we want to warn for a4 because we
assume that a1 and a2 have the same type (despite the standard seems to say
that they don't until the closing brace) or we assume that the user does not
care.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #13 from Paolo Carlini 2012-05-30 17:55:07 UTC --- Thanks Manuel and Lawrence. If I understand correctly what L said, the simpler and more urgent thing to do is making the warning code a bit smarter, I'll try to do that.
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 tlknv at yandex dot ru changed: What|Removed |Added CC||tlknv at yandex dot ru --- Comment #42 from tlknv at yandex dot ru 2012-05-30 18:41:15 UTC --- I would like to propose a patch that should solve this problem. How can I propose the patch?
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 --- Comment #15 from Steven Bosscher 2012-05-30 18:52:18 UTC --- This bug results in real warnings being introduced unnoticed, see: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02005.html
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 --- Comment #16 from Manuel López-Ibáñez 2012-05-30 18:58:29 UTC --- (In reply to comment #15) > This bug results in real warnings being introduced unnoticed, see: > http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02005.html I think somebody tried to add -Wmissing-declarations to CXXFLAGS recently, but the patch was rejected. Check the archive of gcc-patches for the details. I think that patch should be accepted for consistency with CFLAGS.
[Bug c/53532] function call ignored when called with argument of incompatible, undefined structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53532 --- Comment #1 from joseph at codesourcery dot com 2012-05-30 19:08:18 UTC --- This looks like another case of bug 51034.
[Bug middle-end/48493] [4.6/4.7 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #13 from Andrew Pinski 2012-05-30 19:08:58 UTC --- (In reply to comment #12) > >on arm? That's pre-approved if it passes bootstrap & regtest > > I will try it on MIPS since I saw the exact same ICE and the exact same > "(concat:SC (reg/v:SF 134 [ s ]) > (reg/v:SF 135 [ s+4 ]))" . It fixes the bug and I saw no regressions on mips. Thanks, Andrew
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841
--- Comment #15 from Paul Pluzhnikov 2012-05-30
19:13:02 UTC ---
I've got another small reproducer, that shows up as a slightly different
failure, but very likely is the same problem:
namespace util { } // comment out => problem disappears
namespace foo {
namespace util {
struct Printer {
struct Convert {
};
};
class XPrinter: Printer {
// using ::foo::util::Printer::Convert; // ok
// using Printer::Convert; // ok
using foo::util::Printer::Convert; // error
};
}
}
g++ --version
g++ (GCC) 4.8.0 20120515 (experimental)
g++ -c pp.ii -std=c++11
pp.ii:13:24: error: ‘util::Printer’ has not been declared
using foo::util::Printer::Convert; // error
g++ -c pp.ii -std=c++98 && echo ok
ok
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #43 from Marc Glisse 2012-05-30 19:38:12 UTC --- (In reply to comment #42) > I would like to propose a patch that should solve this problem. Note that there are plans to ditch the current implementation of basic_string in the future (4.9?), replacing it with the code in ext/vstring.h. > How can I propose the patch? http://gcc.gnu.org/contribute.html (in short: * sign the contributor agreement if your patch is more than a couple lines * post your patch to the gcc-patches *and* libstdc++ mailing lists)
[Bug lto/53019] [4.7 regression] ICE (segfault) with -flto=jobserver -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53019 --- Comment #5 from Adam Borowski 2012-05-30 21:56:36 UTC --- The changelog for Debian upload which included the fix is: * Update to SVN 20120509 (r187339) from the gcc-4_7-branch. - Fix PR libstdc++/53193, PR target/53272, PR tree-optimization/53239, PR tree-optimization/53195, PR target/52999, PR target/53228, PR tree-optimization/52633, PR tree-optimization/52870, PR target/48496, PR target/53199, PR target/52684, PR lto/52605, PR plugins/53126, PR debug/53174, PR target/53187, PR tree-optimization/53144, PR c++/53186, PR fortran/53255, PR fortran/53111, PR fortran/52864. Previous one was SVN 20120502 (r187039). I'll try trunk, although with its complex build system and me being quite busy, I sadly don't promise to finish it by tonight.
[Bug c++/53356] [4.7/4.8 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4258
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53356 --- Comment #6 from Jason Merrill 2012-05-30 22:07:28 UTC --- Author: jason Date: Wed May 30 22:07:23 2012 New Revision: 188029 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188029 Log: PR c++/53356 * tree.c (stabilize_init): Handle stabilizing a TARGET_EXPR representing a bitwise copy of a glvalue. Added: trunk/gcc/testsuite/g++.dg/init/new34.C trunk/gcc/testsuite/g++.dg/tree-ssa/stabilize1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008 --- Comment #11 from Aldy Hernandez 2012-05-30 22:13:48 UTC --- Author: aldyh Date: Wed May 30 22:13:43 2012 New Revision: 188030 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188030 Log: Backport from mainline 2012-05-25 Aldy Hernandez PR middle-end/53008 * trans-mem.c (ipa_tm_create_version_alias): Output new_node if accessed indirectly. (ipa_tm_create_version): Same. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/tm/pr53008.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/trans-mem.c
[Bug middle-end/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Aldy Hernandez 2012-05-30 22:15:23 UTC --- fixed on both mainline and 4.7 branch.
[Bug c++/53356] [4.7/4.8 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4258
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53356 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jason Merrill 2012-05-30 22:24:21 UTC --- Fixed for 4.7.1.
[Bug target/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999 --- Comment #15 from John David Anglin 2012-05-30 22:54:24 UTC --- Author: danglin Date: Wed May 30 22:54:20 2012 New Revision: 188031 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188031 Log: 2012-05-30 John David Anglin PR target/52999 * config/pa/pa.c (TARGET_SECTION_TYPE_FLAGS): Define. (pa_section_type_flags): New. (pa_legitimate_constant_p): Revert previous change. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c
[Bug target/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999 --- Comment #16 from John David Anglin 2012-05-30 23:04:04 UTC --- Author: danglin Date: Wed May 30 23:03:59 2012 New Revision: 188032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188032 Log: PR target/52999 * config/pa/pa.c (TARGET_SECTION_TYPE_FLAGS): Define. (pa_section_type_flags): New. (pa_legitimate_constant_p): Revert previous change. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/pa/pa.c
[Bug target/48308] [4.6/4.7/4.8 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Matt Heck changed: What|Removed |Added CC||breakpoint at runbox dot ||com --- Comment #22 from Matt Heck 2012-05-30 23:59:46 UTC --- A quick comment for folks trying to work around Buildroot problems related to this: As of this date, this problem still occurs using current Buildroot materials and attempt to build for, for instance, the AT91SAM9M10-G45-EK. The failure occurs in the SSL library (presumably a stress point due to how heavily optimized it is). For the moment, the workaround is to set the GCC compiler version to 4.5.x, instead of 4.6.x. This seems to work. FWIW, I would recommend testing a fairly thorough (lots of packages, including SSL and Xorg) Buildroot test for an ARM9 target as a good way to check whether or not this bug has been resolved. I'd be happy to try that myself when there's a fix.
[Bug middle-end/53533] New: [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 Bug #: 53533 Summary: [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Comparing GCC versions, branches, and optimization levels on Adobe's C++Benchmark suite, I discovered that 4.7 has a major regression with their loop unrolling tests. I have captures the data here: https://docs.google.com/spreadsheet/ccc?key=0Amu19eOay72HdE1xYVRPUTFYWU1TSld3Y2FEOEt5LXc All compilers were fresh checkouts by me from their trunk revisions as of a few days ago. My configure command line: /u/mhargett/src/gcc-4_7-branch/configure --program-suffix=-4.7 --prefix=/u/mhargett --enable-languages=c,c++,lto --enable-lto --with-build-config=bootstrap-lto --with-fpmath=sse --disable-libmudflap --disable-libssp --enable-build-with-cxx --enable-gold=yes --with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/ --with-gmp=/u/mhargett/ --with-mpfr=/u/mhargett/ --enable-cloog-backend=isl --disable-cloog-version-check CC=gcc-4.7 CXX=g++-4.7 The 4.6 and 4.7 versions were both build against the same Cloog, ppl, mpfr, etc. Going from "-O3 -floop-block -floop-strip-mine -floop-interchange -mtune=amdfam10" to "-Ofast -funsafe-loop-optimizations -funroll-loops -floop-block -floop-strip-mine -floop-interchange" didn't help. Attached is a tar ball of the 4.6 and 4.7 -O3 optimized builds. 'make report' re-runs the tests, 'make clean && make' rebuilds.
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #1 from Matt Hargett 2012-05-31 00:55:36 UTC --- Created attachment 27526 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27526 tarball containing buildable sources and binaries that demonstrate the severe performance regression on amdfam10
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #14 from Paolo Carlini 2012-05-31 00:58:14 UTC --- I'm reviewing the whole thing. To summarize my understanding: When we emit the warning, arg2_type and arg3_type are the types of arg2 and arg3, thus, post PR16603, exactly the types of the two initializing expressions, because we are still defining the enumerator NumLowBitsAvailable of the same enum and the enum is not complete. And indeed, those types are *different* as the warning says. Thus, it seems to me, the warning is behaving as designed, just, post PR16603, it triggers also while we are defining individual enumerators basing on other enumerators of the same enum. Of course this didn't happen before PR16603 because we weren't honoring the two-phase typing mechanism. Then it seems to me that we have nothing to strictly-speaking "fix", but only to agree on how we want to put the warning under control. I'm tempted to propose again just to add a -Wenum-mismatch, I note that the EDG front-end doesn't warn with -Wall for the reference very simple case discussed in Comments #7 and #8. I *do* understand that ideally we would like to tell the code in build_conditional_expr_1: "hey we are comparing the types of the initializing expressions of two enumerators of the same enum, which are different, but the difference will go away at the end of the enum when we'll have a single underlying type, thus please don't warn now" but I don't see a simple way to do this: if, for example, we just compare underlying types, we suppress a lot of other warnings, like the one in Comment #7. Given what I see for EDG (what about CLANG?), I'm not sure we should spend a lot of time right now tuning the mechanism of the warning itself.
[Bug java/53527] 4.7.0 release can't enable java language
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53527 --- Comment #2 from licheng.1212 at gmail dot com 2012-05-31 03:01:01 UTC --- (In reply to comment #1) > mips-unknown-elf is not a hosted platform and thus does not support Java. But why the GCC 4.4.2 is OK,and I want to build a corss compiler that support java for embedded system.
[Bug gcov-profile/53534] New: gcov erroneously reporting opening brace of constructor is never executed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53534
Bug #: 53534
Summary: gcov erroneously reporting opening brace of
constructor is never executed.
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: spammymat...@yahoo.com
Created attachment 27527
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27527
bug.ii
PROBLEM:
-: 21:template
1: 22:inline A::A()
#: 23:{
1: 24:}
How can lines 22 and 24 of this simple no-arg constructor be executed once,
without line 23 also being executed once? Isn't that impossible?
SOURCE:
This is the simplest test case I could come up with that exhibits the problem.
In particular, if I do ANY of the following, the problem magically goes away.
- Eliminate the unused templatization parameter from class A.
- Eliminate data member _b (and eliminate class B altogether).
- Eliminate the string data members _s from either class A or class B.
- Change either string data member to a simpler type (e.g., an int).
- Move the inlined no-arg constructor inside class A's definition block.
- Move the opening brace of the no-arg constructor up to the previous line.
bug.cpp:
#include
using namespace std;
class B
{
public:
string _s;
};
template
class A
{
public:
B _b;
string _s;
A();
};
template
inline A::A()
{
}
int main()
{
A a;
return 0;
}
PLATFORM:
I think I'm running the standard gcc/g++ stuff that comes with ubuntu lucid:
> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 10.04.4 LTS
Release:10.04
Codename: lucid
COMPILE LINE:
> g++ -v -Wall -Wextra --cover --save-temps -o bug -g -lstdc++ bug.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-coverage' '-save-temps' '-o' 'bug'
'-g' '-shared-libgcc' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE bug.cpp
-D_FORTIFY_SOURCE=2 -mtune=generic -march=i486 -Wall -Wextra -g
-fworking-directory -fpch-preprocess -fstack-protector -o bug.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/i486-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-coverage' '-save-temps' '-o' 'bug'
'-g' '-shared-libgcc' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -fpreprocessed bug.ii -quiet
-dumpbase bug.cpp -mtune=generic -march=i486 -auxbase bug -g -Wall -Wextra
-version -fprofile-arcs -ftest-coverage -fstack-protector -o bug.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5.1) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.4.3-4ubuntu5.1) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 96a18a11c5c7ae143163545923e7167b
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-coverage' '-save-temps' '-o' 'bug'
'-g' '-shared-libgcc' '-mtune=generic' '-march=i486'
as -V -Qy -o bug.o bug.s
GNU assembler version 2.20.1 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.20.1-system.20100303
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/g
[Bug c++/53534] gcov erroneously reporting opening brace of constructor is never executed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53534 Andrew Pinski changed: What|Removed |Added Component|gcov-profile|c++ --- Comment #1 from Andrew Pinski 2012-05-31 03:27:34 UTC --- This is due to in-charge vs out-of-charge constructors.
[Bug middle-end/53535] New: non-aligned memset on non-strict-alignment targets not optimized where aligned memset is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53535 Bug #: 53535 Summary: non-aligned memset on non-strict-alignment targets not optimized where aligned memset is Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org Target: x86_64-linux The attached code is a modified gcc.dg/pr46647.c, which shows that memset isn't optimized on unaligned short (int-sized) data as it is for aligned data, even for non-strict-alignment targets, such as cris-* and x86_64-linux. Observe the emitted assembly code, which uses the same instructions for aligned and unaligned code as later optimizations cover up (for both cris-* and x86_64-linux). Hence, I guess this bug isn't really that important when it comes to just the generated code, just an annoying middle-end miss and annoyingly failing test-case. (Whether the over-alignment-checks misses other optimization opportunities is another issue.) Background: I stumbled upon this when changing the CRIS port to align global data by default. This made the always-before-failing gcc.dg/pr46647.c pass, for no good reason: alignment of data should not make a difference for emitted code (except for atomic support, WIP for CRIS). This may be related to PR 52861.
[Bug middle-end/53535] non-aligned memset on non-strict-alignment targets not optimized where aligned memset is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53535 --- Comment #1 from Hans-Peter Nilsson 2012-05-31 04:30:08 UTC --- Created attachment 27528 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27528 Modified gcc.dg/pr46647.c
[Bug middle-end/53535] non-aligned memset on non-strict-alignment targets not optimized where aligned memset is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53535 --- Comment #2 from Andrew Pinski 2012-05-31 04:32:00 UTC --- >alignment of data should not make a difference for emitted code Unless the loading of unalignment makes it much slower. I thinking where two aligned half loads are better than one unaligned word load. I think there are targets like that.
[Bug middle-end/53535] non-aligned memset on non-strict-alignment targets not optimized where aligned memset is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53535 --- Comment #3 from Hans-Peter Nilsson 2012-05-31 04:37:37 UTC --- (In reply to comment #0) > Observe the > emitted assembly code, which uses the same instructions for aligned and > unaligned code ...(compare with the code from gcc.dg/pr46647.c here)... SVN revision 188039.
[Bug middle-end/53535] non-aligned memset on non-strict-alignment !SLOW_UNALIGNED_ACCESS targets not optimized where aligned memset is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53535 Hans-Peter Nilsson changed: What|Removed |Added Summary|non-aligned memset on |non-aligned memset on |non-strict-alignment|non-strict-alignment |targets not optimized where |!SLOW_UNALIGNED_ACCESS |aligned memset is |targets not optimized where ||aligned memset is --- Comment #4 from Hans-Peter Nilsson 2012-05-31 04:40:12 UTC --- (In reply to comment #2) > Unless the loading of unalignment makes it much slower. Well, yes, I missed adding !SLOW_UNALIGNED_ACCESS in the title. :)
[Bug middle-end/53535] non-aligned memset on non-strict-alignment targets not optimized where aligned memset is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53535 Hans-Peter Nilsson changed: What|Removed |Added Summary|non-aligned memset on |non-aligned memset on |non-strict-alignment|non-strict-alignment |!SLOW_UNALIGNED_ACCESS |targets not optimized where |targets not optimized where |aligned memset is |aligned memset is | --- Comment #5 from Hans-Peter Nilsson 2012-05-31 04:43:12 UTC --- (In reply to comment #4) > Well, yes, I missed adding !SLOW_UNALIGNED_ACCESS in the title. :) Never mind, SLOW_UNALIGNED_ACCESS != 0 is much more severe than the cost of single insns. Bah. Maybe this is an issue of missing cost metric.
