[Bug target/60818] New: ICE in validate_condition_mode on powerpc-e500v2-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818
Bug ID: 60818
Summary: ICE in validate_condition_mode on
powerpc-e500v2-linux-gnuspe
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
gcc 4.9.0-alpha20140406 segfaults when compiling the following code for target
powerpc-e500v2-linux-gnuspe w/ optimization levels -O1 and above:
int d7;
static int
ca(int l3)
{
for (d7 = 0; d7 1; ++d7)
;
return l3;
}
int
c9(void)
{
int yj;
return ca(((yj != 1) 65535U) d7);
}
% powerpc-e500v2-linux-gnuspe-gcc -O1 -c 62931f03.c
62931f03.c: In function 'c9':
62931f03.c:16:1: internal compiler error: in validate_condition_mode, at
config/rs6000/rs6000.c:15657
[Bug rtl-optimization/60769] [4.8 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60769 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Are you going to commit the testcase to the trunk too?
[Bug debug/60812] gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60812 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Severity|critical|normal --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- You haven't said which target it is, and we need preprocessed source as well. Couldn't reproduce this on x86_64-linux.
[Bug other/60816] Optimzed arm code generates infinite loop via branch instruction branching to current program counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60816 --- Comment #2 from Andrew Parker andrew.j.c.parker at gmail dot com --- Ach, my bad. This snippet came from some old code that started failing with 4.8. I whittled it down for the example but didn't vet it closely enough. Looks like a bug in our code! Thanks for poiting out the obvious. Apols for the waste of time.
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase:
int bar (void);
int
foo ()
{
if (_Cilk_spawn bar ())
return 5;
return 0;
}
Whether this is valid Cilk+ or not, no idea.
[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 --- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Patch posted at http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00537.html
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- According to http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-win/index.htm as well as http://www.cilkplus.org/sites/default/files/open_specifications/cilk_plus_language_specification_0_9.pdf this isn't valid (but we should then diagnose it), but whether these two (and which one of them) are the latest Cilk+ spec is unclear to me.
[Bug rtl-optimization/60769] [4.8 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60769 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- Thanks! (not closing because of Jakub's comment, but it is working fine now)
[Bug target/60818] ICE in validate_condition_mode on powerpc-e500v2-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818
--- Comment #1 from Arseny Solokha asolokha at gmx dot com ---
Another one:
int
kf(int a2, unsigned int dc)
{
int t3;
int b1[2];
for (t3 = 0; t3 2; ++t3)
b1[t3] = 2;
return ((t3 a2) = b1[0]) dc;
}
[Bug target/60818] ICE in validate_condition_mode on powerpc-e500v2-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818
--- Comment #2 from Arseny Solokha asolokha at gmx dot com ---
(In reply to Arseny Solokha from comment #1)
Another one:
int
kf(int a2, unsigned int dc)
{
int t3;
int b1[2];
for (t3 = 0; t3 2; ++t3)
b1[t3] = 2;
return ((t3 a2) = b1[0]) dc;
}
Interestingly enough, it fails only w/ -O1.
[Bug c/60722] __builtin_choose_expr() does not allow 'CONST_EXP' using const variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60722
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||mpolacek at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
So this is basically:
void
foo (void)
{
const int ci = 12;
int i;
i = __builtin_choose_expr (ci, 1, 23);
}
but as ci is not an integer constant expression, we don't want to allow this
one in C, and C++ doesn't support __builtin_choose_expr since it has templates.
(Yes, there's decl_constant_value that would work for this particular example,
but I'm afraid it can't work e.g. for PARM_DECLs.)
So, closing.
[Bug c++/60815] Inconsistent prologue line table location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-debug
Component|debug |c++
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Probably cfun-function_start_locus is inconsistent for them (or not set, in
which case we use DECL_SOURCE_LOCATION).
Sounds like a C++ frontend issue to me:
static tree
cp_parser_init_declarator (cp_parser* parser,
cp_decl_specifier_seq *decl_specifiers,
vecdeferred_access_check, va_gc *checks,
bool function_definition_allowed_p,
bool member_p,
int declares_class_or_enum,
bool* function_definition_p,
tree* maybe_range_for_decl)
{
...
if (decl != error_mark_node DECL_STRUCT_FUNCTION (decl))
{
/* This is where the prologue starts... */
DECL_STRUCT_FUNCTION (decl)-function_start_locus
= func_brace_location;
but for templates we likely don't have DECL_STRUCT_FUNCTION allocated at this
point.
[Bug debug/60812] gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60812 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-11 Ever confirmed|0 |1
[Bug fortran/60810] [4.9 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Known to work||4.8.2 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-11 Ever confirmed|0 |1
[Bug middle-end/60797] [4.9 Regression] gcc hangs with error: only weak aliases are supported in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60797 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-darwin CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|gcc hangs with error: only |[4.9 Regression] gcc hangs |weak aliases are supported |with error: only weak |in this configuration |aliases are supported in ||this configuration
[Bug fortran/60810] [4.7/4.8/4.9 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.9 Regression] list |[4.7/4.8/4.9 Regression] |directed io from array |list directed io from array |results in end of file |results in end of file --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- The libgfortran change is in all of 4.7/4.8 branches and the trunk now I believe.
[Bug fortran/60810] [4.7/4.8/4.9 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.0 |4.7.4
[Bug fortran/60795] [4.7/4.8/4.9 Regression] Wrong length when allocating character array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60795 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.7.4
[Bug middle-end/60797] [4.9 Regression] gcc hangs with error: only weak aliases are supported in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60797
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
0x00615b12 in c_write_global_declarations_1 (
globals=type_decl 0x76c4d170 int)
at /space/rguenther/src/svn/trunk/gcc/c/c-decl.c:10276
10272 do
10273 {
10274 reconsider = false;
10275 for (decl = globals; decl; decl = DECL_CHAIN (decl))
10276 reconsider |= wrapup_global_declaration_2 (decl);
10277 }
10278 while (reconsider);
which basically endlessly loops because nothing sets TREE_ASM_WRITTEN on
the alias.
Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 209292)
+++ gcc/varasm.c(working copy)
@@ -5675,6 +5675,7 @@ assemble_alias (tree decl, tree target)
else
error_at (DECL_SOURCE_LOCATION (decl),
only weak aliases are supported in this configuration);
+ TREE_ASM_WRITTEN (decl) = 1;
return;
}
# endif
fixes it. Probably also needed above for targets without any alias support.
I wonder why weakref errors just fall through and don't return though.
Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 209292)
+++ gcc/varasm.c(working copy)
@@ -5665,6 +5665,7 @@ assemble_alias (tree decl, tree target)
# if !defined(ASM_OUTPUT_WEAK_ALIAS) !defined (ASM_WEAKEN_DECL)
error_at (DECL_SOURCE_LOCATION (decl),
alias definitions not supported in this configuration);
+ TREE_ASM_WRITTEN (decl) = 1;
return;
# else
if (!DECL_WEAK (decl))
@@ -5675,6 +5676,7 @@ assemble_alias (tree decl, tree target)
else
error_at (DECL_SOURCE_LOCATION (decl),
only weak aliases are supported in this configuration);
+ TREE_ASM_WRITTEN (decl) = 1;
return;
}
# endif
[Bug tree-optimization/59817] ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817
--- Comment #3 from Arseny Solokha asolokha at gmx dot com ---
void
xl(void)
{
static int j3;
for (j3 = 0; j3 1; ++j3) {
static int f2;
static int w7;
short int b5;
int ok;
f2 = (b5 += ok) ? (w7 = 0): (w7 ? 0 : (f2 = ok));
}
}
4.7.3 doesn't fail, so this is surely a regression.
[Bug middle-end/60797] [4.9 Regression] gcc hangs with error: only weak aliases are supported in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60797
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Testcase:
/* { dg-do compile } */
/* { dg-skip-if { alias } } */
extern int foo __attribute__((alias(bar))); /* { dg-error supported } */
int main()
{
return 0;
}
[Bug c/60100] warning disappears when preprocessed source is compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- I guess also a dup of PR57201.
[Bug rtl-optimization/60663] [4.9 Regression] Errors out on valid inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Apr 11 10:11:01 2014 New Revision: 209293 URL: http://gcc.gnu.org/viewcvs?rev=209293root=gccview=rev Log: PR rtl-optimization/60663 * cse.c (cse_insn): Set src_volatile on ASM_OPERANDS in PARALLEL. * gcc.target/arm/pr60663.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr60663.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/60663] [4.9 Regression] Errors out on valid inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug tree-optimization/59817] ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
The ICE tells us that the parameter isn't recorded as parameter in the SESE
region:
(gdb) p debug_scop_params (s, 2)
# parameters (
# Parameter names are provided
1
# Parameter names
_10 pretmp_30 offset.3_15
#)
$28 = void
(gdb) p debug_scop_params (s, 5)
# parameters (
# Parameter names are provided
1
# Parameter names
_10 pretmp_30 offset.3_15
#)
$29 = void
(gdb) p debug_scop (s, 1)
SCoP 1
#(
# Language
Gimple
# Context (
#eq p0 p1 p2cst
XXX isl
# )
# Parameter names are provided
1
# Parameter names
_10 pretmp_30 offset.3_15
# Number of statements
2
# Iteration domain of bb_8 (
#eq i0 p0 p1 p2cst
XXX isl
#)
# Access informations are provided
1
# Read access informations
0
# Write access informations
1
# data accesses (
# eq alias sub0 i0 p0 p1 p2cst
#)
# Statement body is not provided
0
# Iteration domain of bb_10 (
#eq i0 i1 p0 p1 p2cst
XXX isl
#)
# Access informations are not provided
0
# Statement body is not provided
0
#)
$32 = void
not sure if I interpret the above correctly but bb8 and bb10 seem to be in
that scop. The parameter is refered from bb 8.
Ah, scan_tree_for_params does
scan_tree_for_params (sese s, tree e)
{
if (e == chrec_dont_know)
return;
switch (TREE_CODE (e))
{
case POLYNOMIAL_CHREC:
scan_tree_for_params (s, CHREC_LEFT (e));
break;
thus it misses to scan CHREC_RIGHT. The MULT_EXPR handling is also suspicious.
Fixing the above shifts the ICE to
#1 0x0132e1ae in extract_affine_chrec (s=0x1f89e10, e=
polynomial_chrec 0x76d91ae0, space=0x1f8b910)
at /space/rguenther/src/svn/trunk/gcc/graphite-sese-to-poly.c:619
619 gcc_assert (isl_pw_aff_is_cst (rhs)
(gdb) l
614 isl_aff *loop = isl_aff_set_coefficient_si
615 (isl_aff_zero_on_domain (ls), isl_dim_in, pos, 1);
616 isl_pw_aff *l = isl_pw_aff_from_aff (loop);
617
618 /* Before multiplying, make sure that the result is affine. */
619 gcc_assert (isl_pw_aff_is_cst (rhs)
620 || isl_pw_aff_is_cst (l));
621
622 return isl_pw_aff_add (lhs, isl_pw_aff_mul (rhs, l));
623 }
so maybe it simply doesn't handle CHRECs with variable stride but fails to
disregard those.
It indeed fails to as scev_is_linear_expression doesn't have the
same restriction on CHRECs as graphite_can_represent_scev asserts.
Thus completing that one as well is required.
Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c (revision 209292)
+++ gcc/graphite-scop-detection.c (working copy)
@@ -219,7 +219,14 @@ graphite_can_represent_scev (tree scev)
switch (TREE_CODE (scev))
{
+case NEGATE_EXPR:
+case BIT_NOT_EXPR:
+CASE_CONVERT:
+case NON_LVALUE_EXPR:
+ return graphite_can_represent_scev (TREE_OPERAND (scev, 0));
+
case PLUS_EXPR:
+case POINTER_PLUS_EXPR:
case MINUS_EXPR:
return graphite_can_represent_scev (TREE_OPERAND (scev, 0))
graphite_can_represent_scev (TREE_OPERAND (scev, 1));
@@ -247,7 +254,8 @@ graphite_can_represent_scev (tree scev)
}
/* Only affine functions can be represented. */
- if (!scev_is_linear_expression (scev))
+ if (tree_contains_chrecs (scev, NULL)
+ || !scev_is_linear_expression (scev))
return false;
return true;
[Bug tree-optimization/59817] ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug tree-optimization/59817] [4.8/4.9 Regression] ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.7.3 Target Milestone|--- |4.8.3 Summary|ICE in extract_affine_chrec |[4.8/4.9 Regression] ICE in |with -O2 -ftree-loop-linear |extract_affine_chrec with ||-O2 -ftree-loop-linear
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org --- Another issue for Fortran arrays is that when using array descriptors all accesses will have symbolical (non-INTEGER_CST) stride. And graphite doesn't support parameters in CHREC_RIGHT.
[Bug tree-optimization/55022] [4.8/4.9 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Mircea Namolaru from comment #17) Vladimir Kargov, Tobias Grosser and me found that the problem is caused by incorrect folding of the floord operator. As a result Cloog translates the expression -4294967296*floord(_19-i_17,4294967296) to the tree-SSA expression 4294967296*floord(_19-i_17,-4294967296) This is wrong, in the first case floord is 0 and in the second is -1. Not sure where that folding happens or what floord is, but if you are refering to negate_expr () negating a /[fl] CST as a /[fl] -CST then yes, that looks suspicious. OTOH the division variant tree codes don't appear in the IL very often so it's hard to notice these mistakes. Testing Index: gcc/fold-const.c === *** gcc/fold-const.c(revision 209292) --- gcc/fold-const.c(working copy) *** negate_expr_p (tree t) *** 484,491 case TRUNC_DIV_EXPR: case ROUND_DIV_EXPR: - case FLOOR_DIV_EXPR: - case CEIL_DIV_EXPR: case EXACT_DIV_EXPR: /* In general we can't negate A / B, because if A is INT_MIN and B is 1, we may turn this into INT_MIN / -1 which is undefined --- 484,489 *** fold_negate_expr (location_t loc, tree t *** 682,689 case TRUNC_DIV_EXPR: case ROUND_DIV_EXPR: - case FLOOR_DIV_EXPR: - case CEIL_DIV_EXPR: case EXACT_DIV_EXPR: /* In general we can't negate A / B, because if A is INT_MIN and B is 1, we may turn this into INT_MIN / -1 which is undefined --- 680,685
[Bug tree-optimization/55022] [4.8/4.9 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022
--- Comment #21 from Vladimir Kargov kargov at gmail dot com ---
(In reply to rguent...@suse.de from comment #20)
I can't seem to observe the above with the testcase or sth like
the following suitable for the testsuite
Can you please check the following:
#include stdio.h
void __attribute__ ((noinline))
BZ2_hbCreateDecodeTables(int *limit, int minLen, int maxLen)
{
int i;
for (i = minLen; i = maxLen; i++) {
limit[i] = i;
}
}
void main()
{
int limit[2] = {0, 0};
int pos;
BZ2_hbCreateDecodeTables (limit, 0, 1);
printf(%d\n, limit[1]);
}
When compiled with -fgraphite-identity -O3 on trunk it will give 0 which is
incorrect.
The patched version should give the correct 1.
[Bug tree-optimization/55022] [4.8/4.9 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #22 from Richard Biener rguenth at gcc dot gnu.org --- Ah, bogus fix for another bug in my tree.
[Bug rtl-optimization/60819] New: dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
Bug ID: 60819
Summary: dse1 removing not-dead insn (aliasing issue?)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
#include mmintrin.h
int f (__m64 const __A, int const __N)
{ return ((__v4hi)__A)[__N]; }
compiler with -O2, produces:
movslq%edi, %rdi
movswl-8(%rsp,%rdi,2), %eax
ret
dse1 removed the instruction that copies xmm0 to the stack!
Could be related to PR 56965, I didn't try the patch in that PR.
Already broken in gcc-4.6, not a (recent) regression.
[Bug tree-optimization/55022] [4.8/4.9 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #23 from Vladimir Kargov kargov at gmail dot com --- (In reply to rguent...@suse.de from comment #20) Your test also exploits this bug for me on trunk rev. 208043.
[Bug middle-end/60797] [4.9 Regression] gcc hangs with error: only weak aliases are supported in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60797 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/60797] [4.9 Regression] gcc hangs with error: only weak aliases are supported in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60797 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Apr 11 11:45:44 2014 New Revision: 209299 URL: http://gcc.gnu.org/viewcvs?rev=209299root=gccview=rev Log: 2014-04-11 Richard Biener rguent...@suse.de PR middle-end/60797 * varasm.c (assemble_alias): Avoid endless error reporting recursion by setting TREE_ASM_WRITTEN. * gcc.dg/pr60797.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr60797.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug middle-end/60556] tip of tree crash with mips compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60556 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Apr 11 11:52:14 2014 New Revision: 209300 URL: http://gcc.gnu.org/viewcvs?rev=209300root=gccview=rev Log: PR middle-end/60556 * expr.c (convert_move): Use emit_store_flag_force instead of emit_store_flag. Pass lowpart_mode instead of VOIDmode as 5th argument to it. * gcc.c-torture/compile/pr60556.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr60556.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/60556] tip of tree crash with mips compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60556 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- Hopefully fixed now.
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-11 Component|rtl-optimization|c Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I think you are violating aliasing in your testcase: typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__)); typedef short __v4hi __attribute__ ((__vector_size__ (8))); you access __m64 with a __v4hi (__may_alias__ doesn't make the __m64 parameter have alias-set zero!). Now, we lower this to return (int) *((short int *) VIEW_CONVERT_EXPRvector(4) short int(__A) + (sizetype) ((long unsigned int) __N * 2)); because of the variable indexing which makes this a memory access. So eventually that lowering should make sure no TBAA issues appear or we should reject variable indexes here. That is, variable indexing should use a MEM_REF with alias-set zero (if we are sure that non-variable indexing will never result in a memory access, it seems that the FE lowers constant indexes the same and only later during gimplification we fold that to use a BIT_FIELD_REF). Confirmed as a Frontend bug sofar, just in case the testcase is valid.
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Btw, eventually better representation:
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 209298)
+++ gcc/c-family/c-common.c (working copy)
@@ -11760,20 +11760,18 @@ convert_vector_to_pointer_for_subscript
{
if (TREE_CODE (TREE_TYPE (*vecp)) == VECTOR_TYPE)
{
- tree type = TREE_TYPE (*vecp);
- tree type1;
+ tree vtype = TREE_TYPE (*vecp);
+ tree type;
if (TREE_CODE (index) == INTEGER_CST)
if (!tree_fits_uhwi_p (index)
-|| tree_to_uhwi (index) = TYPE_VECTOR_SUBPARTS (type))
+|| tree_to_uhwi (index) = TYPE_VECTOR_SUBPARTS (vtype))
warning_at (loc, OPT_Warray_bounds, index value is out of bound);
c_common_mark_addressable_vec (*vecp);
- type = build_qualified_type (TREE_TYPE (type), TYPE_QUALS (type));
- type = build_pointer_type (type);
- type1 = build_pointer_type (TREE_TYPE (*vecp));
- *vecp = build1 (ADDR_EXPR, type1, *vecp);
- *vecp = convert (type, *vecp);
+ type = build_qualified_type (TREE_TYPE (vtype), TYPE_QUALS (vtype));
+ type = build_array_type_nelts (type, TYPE_VECTOR_SUBPARTS (vtype));
+ *vecp = build1 (VIEW_CONVERT_EXPR, type, *vecp);
}
}
which defers the issue to RTL expansion, expanding from
_3 = VIEW_CONVERT_EXPRshort int[4](__A_5(D))[__N_2(D)];
_4 = (int) _3;
return _4;
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Btw, we don't simplify _2 = VIEW_CONVERT_EXPRshort int[4](__A_4(D))[2]; to a BIT_FIELD_REF.
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- But it shows that expansion when falling back to the stack doesn't properly consider TBAA.
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
typedef int v2si __attribute__((vector_size (8),may_alias));
typedef short v4hi __attribute__((vector_size (8),may_alias));
int f (v2si __A, int __N)
{ return (*(v4hi*)__A)[__N]; }
also fails.
Reading the documentation of may_alias, I have the impression that this example
is doing exactly what may_alias is supposed to allow, no?
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
--- Comment #6 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 11 Apr 2014, glisse at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
typedef int v2si __attribute__((vector_size (8),may_alias));
typedef short v4hi __attribute__((vector_size (8),may_alias));
int f (v2si __A, int __N)
{ return (*(v4hi*)__A)[__N]; }
also fails.
Reading the documentation of may_alias, I have the impression that this
example
is doing exactly what may_alias is supposed to allow, no?
Not exactly - it's again the wrapping that will fail.
typedef int aint __attribute__((may_alias));
return ((aint*)__A)[__N];
would make it valid.
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- I like the VCE using an array-type representation more because that won't make the thing addressable early on (or force it to be alias-set zero). We still have to fix expansion, of course.
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #6) Not exactly - it's again the wrapping that will fail. That seems strange to me. From the doc of may_alias: Accesses through pointers to types with this attribute are not subject to type-based alias analysis, but are instead assumed to be able to alias any other type of objects. This extension exists to support some vector APIs, in which pointers to one vector type are permitted to alias pointers to a different vector type. and indeed the x86 *intrin.h files cast between __m128i and __v4si (and many other combinations) all the time.
[Bug other/59055] gcc.texinfo warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59055 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Apr 11 12:47:20 2014 New Revision: 209303 URL: http://gcc.gnu.org/viewcvs?rev=209303root=gccview=rev Log: PR other/59055 * doc/bugreport.texi (Bugs): Remove nodes pointing to the nirvana. * doc/gcc.texi (Service): Update description in the @menu * doc/invoke.texi (Option Summary): Remove misplaced and duplicated @menu. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/bugreport.texi trunk/gcc/doc/gcc.texi trunk/gcc/doc/invoke.texi
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 11 Apr 2014, glisse at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #6) Not exactly - it's again the wrapping that will fail. That seems strange to me. From the doc of may_alias: Accesses through pointers to types with this attribute are not subject to type-based alias analysis, but are instead assumed to be able to alias any other type of objects. This extension exists to support some vector APIs, in which pointers to one vector type are permitted to alias pointers to a different vector type. and indeed the x86 *intrin.h files cast between __m128i and __v4si (and many other combinations) all the time. But the actual access will be that generated by the frontend via a pointer to a scalar (that doesn't have the ref-all flag set). Patch that should make your 2nd testcase work as expected: Index: gcc/c-family/c-common.c === --- gcc/c-family/c-common.c (revision 209298) +++ gcc/c-family/c-common.c (working copy) @@ -11770,8 +11770,9 @@ convert_vector_to_pointer_for_subscript c_common_mark_addressable_vec (*vecp); type = build_qualified_type (TREE_TYPE (type), TYPE_QUALS (type)); - type = build_pointer_type (type); type1 = build_pointer_type (TREE_TYPE (*vecp)); + type = build_pointer_type_for_mode (type, ptr_mode, + TYPE_REF_CAN_ALIAS_ALL (type1)); *vecp = build1 (ADDR_EXPR, type1, *vecp); *vecp = convert (type, *vecp); }
[Bug tree-optimization/55022] [4.8/4.9 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #24 from Vladimir Kargov kargov at gmail dot com --- (In reply to Vladimir Kargov from comment #19) For the sake of correctness, I had an obvious typo in my comment: ((signed long) maxLen_5(D) - (signed long) minLen_3(D)) /[fl] -4294967296 (i.e. -4294967296). ((signed long) maxLen_5(D) - (signed long) minLen_3(D)) /[fl] -4294967296 = -1, not -4294967296.
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 Stupachenko Evgeny evstupac at gmail dot com changed: What|Removed |Added CC||evstupac at gmail dot com --- Comment #5 from Stupachenko Evgeny evstupac at gmail dot com --- Yes it is not valid. Please find latest spec at: https://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm
[Bug c++/60820] New: ice in ctor_for_folding, at varpool.c:291
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820 Bug ID: 60820 Summary: ice in ctor_for_folding, at varpool.c:291 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mliska at suse dot cz I test gcc 4.9 on my x86_64 gentoo machine and ICE is encountered in 'net-misc/nx' package: lto1: internal compiler error: in ctor_for_folding, at varpool.c:305 0xb4b0b6 ctor_for_folding(tree_node*) ../../gcc/varpool.c:292 0xb4b448 dump_varpool_node(_IO_FILE*, varpool_node*) ../../gcc/varpool.c:211 0x5bba6a dump_symtab(_IO_FILE*) ../../gcc/symtab.c:707 0x546084 do_whole_program_analysis ../../gcc/lto/lto.c:3248 0x546084 lto_main() ../../gcc/lto/lto.c:3422 decl: var_decl 0x7f574898be40 in6addr_any type record_type 0x7f57488e4690 in6_addr readonly TI size integer_cst 0x7f5748fc60a0 constant 128 unit size integer_cst 0x7f5748fc60c0 constant 16 align 32 symtab 0 alias set 0 canonical type 0x7f57488e4dc8 fields field_decl 0x7f57488ed980 __in6_u type union_type 0x7f57488e4d20 TI file /usr/include/netinet/in.h line 206 col 9 size integer_cst 0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0 16 align 32 offset_align 128 offset integer_cst 0x7f5748fc6060 constant 0 bit offset integer_cst 0x7f5748fc60e0 constant 0 context record_type 0x7f57488e4dc8 in6_addr context translation_unit_decl 0x7f57488ebb80 D.33269 pointer_to_this pointer_type 0x7f57488e4738 readonly public static weak TI file /usr/include/netinet/in.h line 214 col 30 size integer_cst 0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0 16 align 32 context translation_unit_decl 0x7f5748977ac8 D.36198 attributes tree_list 0x7f5748993190 initial constructor 0x7f5748974798 DECL_INITIAL(decl): constructor 0x7f5748974798 type record_type 0x7f57488e4690 in6_addr readonly TI size integer_cst 0x7f5748fc60a0 constant 128 unit size integer_cst 0x7f5748fc60c0 constant 16 align 32 symtab 0 alias set 0 canonical type 0x7f57488e4dc8 fields field_decl 0x7f57488ed980 __in6_u type union_type 0x7f57488e4d20 TI file /usr/include/netinet/in.h line 206 col 9 size integer_cst 0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0 16 align 32 offset_align 128 offset integer_cst 0x7f5748fc6060 constant 0 bit offset integer_cst 0x7f5748fc60e0 constant 0 context record_type 0x7f57488e4dc8 in6_addr context translation_unit_decl 0x7f57488ebb80 D.33269 pointer_to_this pointer_type 0x7f57488e4738 constant static lngt 1 idx field_decl 0x7f57488ed980 __in6_u val constructor 0x7f5748974768 type union_type 0x7f57488e4d20 TI size integer_cst 0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0 16 align 32 symtab 0 alias set 0 canonical type 0x7f57488e4d20 fields field_decl 0x7f57488ed7b8 __u6_addr8 context translation_unit_decl 0x7f57488ebb80 D.33269 chain type_decl 0x7f57488e2cf0 D.33550 constant static lngt 1 idx field_decl 0x7f57488ed7b8 __u6_addr8 type array_type 0x7f57488e4b28 TI file /usr/include/netinet/in.h line 201 col 10 size integer_cst 0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0 16 align 8 offset_align 128 offset integer_cst 0x7f5748fc6060 0 bit offset integer_cst 0x7f5748fc60e0 0 context union_type 0x7f57488e4d20 chain field_decl 0x7f57488ed850 __u6_addr16 val constructor 0x7f5748974750 type array_type 0x7f57488e4b28 constant static lngt 16 idx integer_cst 0x7f5748fc60e0 0 val integer_cst 0x7f5748fc6220 constant 0 idx integer_cst 0x7f5748fc6680 constant 1 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f57490695c0 constant 2 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f5749139040 constant 3 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f57490695a0 constant 4 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f5749139180 constant 5 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f5749139240 constant 6 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f57491392e0 constant 7 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f5748fc61e0 constant 8 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f5749139400 constant 9 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f57491394a0 constant 10 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f5749139520 constant 11 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f57491395a0 constant 12 val integer_cst 0x7f5748fc6220 0 idx integer_cst 0x7f5749139640 constant 13 val integer_cst 0x7f5748fc6220 0 idx
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- The following should disallow this in the C FE. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 5653e49..cbbb272 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -5153,6 +5153,9 @@ c_parser_if_statement (c_parser *parser) /* If the if statement contains array notations, then we expand them. */ if (flag_cilkplus contains_array_notation_expr (if_stmt)) if_stmt = fix_conditional_array_notations (if_stmt); + /* But Cilk_spawn in controlling expression is invalid. */ + if (flag_cilkplus contains_cilk_spawn_stmt (cond)) +error_at (loc, %_Cilk_spawn% in if statement is not permitted); add_stmt (if_stmt); }
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #10 from Marc Glisse glisse at gcc dot gnu.org --- Ah. So, from a user's POV, it should be valid. But internally, we convert v2si*-v4hi* (ok), v4hi*-short* (ok), we forget the intermediate step, and we end up with v2si*-short*, which is not ok since the type through which the access will happen (short) doesn't have may_alias. The safety of the cast is not transitive... Maybe the patch from comment #9 could be restricted to the case where the vector type has may_alias? That would still break my original testcase, but it seems illegal anyway (may_alias only works in one direction, the opposite one, and I think the x86 *intrin.h files are wrong).
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #11 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Marc Glisse from comment #10) Maybe the patch from comment #9 could be restricted to the case where the vector type has may_alias? Oups, that's already the case, sorry for misreading.
[Bug target/60817] gcc configure script misdetects TLS support on x86_64-pc-solaris* with gnu as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60817 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- I'll have a look. The patch is completely bogus, though: it seems to have been hand-edited to the point where it doesn't even apply. That said, we need to make sure that several different configurations correctly detect native TLS support, both for i386-*-solaris2* and x86_64-*-solaris2* configurations: 32-bit gas (not necessarily in x86_64 case) 64-bit gas /bin/as I'm pretty sure this won't make 4.9.0, though. Rainer
[Bug c/60821] New: gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821
Bug ID: 60821
Summary: gcc 4.8 on MacOS fails depending on -arch order
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: a.h.jaffe at gmail dot com
I am trying to get a recent version of gcc 4.8.2 up on my machine (OSX 10.9.2).
I have tried installs that come from MacPorts as well as the one that gets
installed alongside a binary install of gfortran.
For a minimal source file, I get errors depending on the order of the -arch
flags.
Specifically, `-arch x86_64 -arch i386` (or either of them alone) works:
% /opt/local/bin/gcc-mp-4.8 -arch x86_64 -arch i386 conftest.c
% /opt/local/bin/gcc-mp-4.8 -arch x86_64 -arch i386 -O3 conftest.c
But `-arch i386 -arch x86_64` fails:
% /opt/local/bin/gcc-mp-4.8 -arch i386 -arch x86_64 conftest.c
/var/folders/6l/7gzvw1zs42sbhj7_hlrpykfmgv/T//cc6JCBdP.s:5:bad register
name `%rbp'
/var/folders/6l/7gzvw1zs42sbhj7_hlrpykfmgv/T//cc6JCBdP.s:7:bad register
name `%rsp'
/var/folders/6l/7gzvw1zs42sbhj7_hlrpykfmgv/T//cc6JCBdP.s:10:bad
register name `%rbp'
% /opt/local/bin/gcc-mp-4.8 -arch i386 -arch x86_64 -O3 conftest.c
/var/folders/6l/7gzvw1zs42sbhj7_hlrpykfmgv/T//ccs67E0q.s:34:FATAL:Bad
fx_size (0x8) in fix_to_relocation_info()
Help!
The minimal source:
int main ()
{
return 0;
}
For info:
% /opt/local/bin/gcc-mp-4.8 --version
gcc-mp-4.8 (MacPorts gcc48 4.8.2_0+universal) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c/60821] gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Of course the order of the -arch flags depends, that is not a bug. Order does matter when you use several options of the same kind, same with -O -O3 vs. -O3 -O.
[Bug c++/60820] ice in ctor_for_folding, at varpool.c:291
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820
--- Comment #1 from Martin Liška mliska at suse dot cz ---
testcase:
cat a.c:
#include netinet/in.h
#include stdio.h
static const struct in6_addr local_in6addr_any = IN6ADDR_ANY_INIT;
#pragma weak in6addr_any = local_in6addr_any
__attribute__ ((used))
void foo()
{
fprintf (stderr, v1: %p, v2: %p\n, local_in6addr_any, in6addr_any);
}
gcc -flto -O2 -c a.c -o a.o
gcc -flto -O2 -c a.c -o b.o
gcc -flto -O2 a.o b.o
[Bug c/60100] warning disappears when preprocessed source is compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100 --- Comment #10 from lavr at ncbi dot nlm.nih.gov --- I guess also a dup of PR57201. While I can agree these cases (and the one mentioned within PR57201) look similar, the gravity of the disappearing warning in case of a mismatched type is more severe than an unused variable or no-effect code...
[Bug c/60821] gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821 a.h.jaffe at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from a.h.jaffe at gmail dot com --- @Marek I don't think that's right, or at least the behaviour doesn't make sense: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Darwin-Options.html#Darwin-Options Apple's GCC on Darwin does create “fat” files if multiple -arch options are used; it does so by running the compiler or linker multiple times and joining the results together with lipo. And in any event, note that either -arch i386 or -arch x86_64 work *separately*!
[Bug libstdc++/60594] [4.8/4.9 Regression] std::function of a type with a declared (but not defined) return type fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60594 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to work||4.7.3 Keywords||rejects-valid Last reconfirmed||2014-04-11 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Summary|std::function of a type |[4.8/4.9 Regression] |with a declared (but not|std::function of a type |defined) return type fails |with a declared (but not |to compile |defined) return type fails ||to compile Target Milestone|--- |4.8.3 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- We only need to prevent instantiation of is_convertiblebar, bar when evaluating the overloads for the copy constructor, the patch is simple.
[Bug target/60822] New: Index register overwritten on m68k/coldfire
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60822
Bug ID: 60822
Summary: Index register overwritten on m68k/coldfire
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pint at tlink dot de
I have a newlib based gcc-4.8.2 crosscompiler on a mingw host with this
configuration:
../gcc/configure --target=m68k-elf --prefix=/opt/gcc-4.8.2-m68k
--enable-threads --with-newlib --enable-static --with-gnu-as --with-gnu-ld
--enable-languages=c++
--with-headers=/src/gcc-4.8.2/build-gcc/../newlib/newlib/libc/include
--with-arch=cf
invoked with:
m68k-elf-gcc -mcpu=54455 -g0 -O2 -Wall -Wextra -S test.cpp -otest.s
This test program:
struct X {
char fill0[80];
int a;
char fill1[90];
int b;
int Avg(int s) const {return (s * (long long)(a + b)) 17;}
};
int f=1;
int o;
extern X x;
int main()
{
o = x.Avg(f);
return 0;
}
Produces this output:
lea x,%a0
move.l #174,%d0
move.l #80,%d1
move.l %d3,-(%sp)
.cfi_offset 3, -12
moveq #15,%d3
move.l (%a0,%d0.l),%d1
add.l (%a0,%d1.l),%d1
Where the value #80 is overwritten before used in the last statement.
[Bug ada/60730] 'Round of a fixed point type incorrectly truncates its operand instead of rounding it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60730 --- Comment #3 from Georg georggcc at googlemail dot com --- I have used the new simplified bug reporting form, hence no triple. Several platforms are affected; the GCC 4.9 used with this report was built on Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64. See -v below. According to the first public mention, these are also affected (quoting the USENET message): gnat 4.6.3 (debian stable kfreebsd), gnat-aux 4.7.3 (from FreeBSD ports). I also just checked the gcc build for dotnet-GNAT (GNAT GPL (20130314)), same result. $ gcc -v COLLECT_GCC=/Volumes/Macintosh HD/Users/bauhaus/4.9/bin/gcc COLLECT_LTO_WRAPPER=/Volumes/Macintosh\ HD/Users/bauhaus/4.9/bin/../libexec/gcc/x86_64-apple-darwin13.1.0/4.9.0/lto-wrapper Target: x86_64-apple-darwin13.1.0 Configured with: /Macintosh_HD/Users/bauhaus/src/GCC-trunk/configure --prefix=/Macintosh_HD/Users/bauhaus/4.9 --disable-nls --enable-languages=c,ada,c++ CC=gcc Thread model: posix gcc version 4.9.0 20140331 (experimental) (GCC)
[Bug c/60821] gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Whoops, sorry. I better let Darwin folks look at it.
[Bug tree-optimization/60823] New: ICE in gimple_expand_cfg, at cfgexpand.c:5644
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60823 Bug ID: 60823 Summary: ICE in gimple_expand_cfg, at cfgexpand.c:5644 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com We noticed that adding 'const' qualifier to function arguments marked with simd declare pragma leads to issue ICE on attached test-case. Test is compiled successfully if 'const' was deleted. To reproduce failure the following command line options are needed: -O1 -m64 test.cpp -c -fopenmp.
[Bug tree-optimization/60823] ICE in gimple_expand_cfg, at cfgexpand.c:5644
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60823 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 32585 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32585action=edit C++ test-case to reproduce Need to be compiled with -O1 -m64 test.cpp -c -fopenmp options to reproduce ICE.
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- But then it is not valid in many other places (for/while/do condition, etc.). Perhaps if _Cilk_spawn is allowed in the grammer only in 3 specific cases it might be better to disallow it everywhere and check for it only in the 3 listed cases (whole statement, var initializer and rhs of assignment (but for the last one it has to be only toplevel assignment I guess, a = b = _Cilk_spawn foo (); is presumably also invalid, ditto a + (b = _Cilk_spawn foo ()); etc.
[Bug other/60824] New: meta-bug: issues waiting for gcc 4.10 phase 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60824 Bug ID: 60824 Summary: meta-bug: issues waiting for gcc 4.10 phase 1 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: amylaar at gcc dot gnu.org
[Bug target/60825] New: [AArch64] int64x1_t, uint64x1_t and float64x1_t are not treated as vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825
Bug ID: 60825
Summary: [AArch64] int64x1_t, uint64x1_t and float64x1_t are
not treated as vector types
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yufeng at gcc dot gnu.org
int64x1_t, uint64x1_t and float64x1_t in AArch64 arm_neon.h shall be vector
types. However currently they are treated as different names for the
corresponding C/C++ types: int64_t, uint64_t and double in the GCC AArch64
backend.
Function parameters of such types shall be passed in NEON SIMD registers and
the names of C++ functions with parameters of any of those types shall be
mangled properly.
The following test cases demonstrate the issue:
test.c
/* Parameter passing issue */
#include arm_neon.h
int64x1_t ;
uint64x1_t ;
float64x1_t ;
void (int64x1_t);
void (uint64x1_t);
void (float64x1_t);
void test (void)
{
();
();
();
}
CUT
'', '' and '' shall be passed in register 'd0', however '' and
'' are currently passed in 'x0' instead. '' is correctly passed in
'd0', but only by chance, as parameters of double are passed in FP registers
which overlay with SIMD registers.
test.cpp
/* C++ name mangling issue */
#include arm_neon.h
void (int64x1_t )
{}
void (uint64x1_t )
{}
void (float64x1_t )
{}
CUT
Instead of the following expected mangled names:
_Z411__Int64x1_t
_Z412__Uint64x1_t
_Z413__Float64x1_t
the function names are currently mangled to
_Z4l
_Z4m
_Z4d
[Bug target/60825] [AArch64] int64x1_t, uint64x1_t and float64x1_t are not treated as vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825 Yufeng Zhang yufeng at gcc dot gnu.org changed: What|Removed |Added Target||aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-11 Target Milestone|--- |4.9.1 Ever confirmed|0 |1
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 --- Comment #5 from Martin Husemann martin at netbsd dot org --- Thomas and I compared environments and found the difference: it is gcc compiled by clang that misbehaves. I could reproduce and verify it - but past bootstrapping it is something that will never happen to native FSF gcc in the wild, I suppose.
[Bug target/60825] [AArch64] int64x1_t, uint64x1_t and float64x1_t are not treated as vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825 Yufeng Zhang yufeng at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Version|4.9.0 |4.8.0 Assignee|unassigned at gcc dot gnu.org |yufeng at gcc dot gnu.org
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Closing.
[Bug rtl-optimization/60651] Mode switching instructions are sometimes emitted in the wrong order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651 --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- This patch: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00091.html has been approved for gcc4.10, modulo one spelling fix: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00263.html
[Bug lto/60820] [4.9 Regression] ice in ctor_for_folding, at varpool.c:291
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.7.3, 4.8.3 Last reconfirmed||2014-04-11 Component|c++ |lto CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 Summary|ice in ctor_for_folding, at |[4.9 Regression] ice in |varpool.c:291 |ctor_for_folding, at ||varpool.c:291 Target Milestone|--- |4.9.0 Known to fail||4.9.0 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- copying a.c to b.c and renaming foo() to bar() makes the testcase valid I guess.
[Bug target/60811] arc/arc.c:2135: possible bad argument to abs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60811 --- Comment #2 from David Binderman dcb314 at hotmail dot com --- (In reply to Jorn Wolfgang Rennecke from comment #1) Though it seems too insignificant to make a change that late in phase 3, so I think this should wait for 4.10. Seems reasonable to me, but at worst, it's only going to break one architecture and I think I'm right in saying arc isn't a primary or secondary architecture. Although such a small straightforward bug-fix can hardly considered Copyrightable, I suppose you are technically the author of a patch, so it would be SOP to name you in the ChangeLog - unless you don't want that. But I haven't written a patch, I've only reported a bug with a suggested solution. I think who fixes it gets to put their name on the record, not me.
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Problem has been fixed for 4.9 with the commit shown in comment #9.
[Bug target/60817] gcc configure script misdetects TLS support on x86_64-pc-solaris* with gnu as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60817 --- Comment #2 from Ruud Koolen redlizard at redlizard dot nl --- I generated the patch cleanly against trunk. What's wrong with it?
[Bug target/60825] [AArch64] int64x1_t, uint64x1_t and float64x1_t are not treated as vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed. The problem is: typedef int64_t int64x1_t; typedef int32_t int32x1_t; typedef int16_t int16x1_t; typedef int8_t int8x1_t; typedef double float64x1_t; typedef uint64_t uint64x1_t; typedef uint32_t uint32x1_t; typedef uint16_t uint16x1_t; typedef uint8_t uint8x1_t; Those all should add __attribute__((vector_size(sizeof(type) )) to them to make them a vector of one element.
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #23 from John Marino gnugcc at marino dot st --- (In reply to John Marino from comment #17) In the end, there were 6 failures. C52103x C52104x C52104y c74004a (hung) cb1010c cb1010d To follow up, I reworked the testsuite handler to reduce the test times from 6 hours to about 15 minutes, so I've since re-run ACATS several times. There are only 5 failures. I can't reproduce the hung c74004a test, it's executing fine now. So it's only the stack-check related tests that are failing.
[Bug ada/60730] 'Round of a fixed point type incorrectly truncates its operand instead of rounding it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60730 --- Comment #4 from John Marino gnugcc at marino dot st --- FreeBSD GNAT 4.9.0 is the same 4.7.3 (allegedly broken): FreeBSD draco.synsport.com 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@draco:/home/marino/test/rounding # /usr/local/gcc-aux/bin/ada --version ada (GCC) 4.9.0 20140406 (prerelease) -= GNAT AUX [FreeBSD64] Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. root@draco:/home/marino/test/rounding # ./round_decimal raised PROGRAM_ERROR : round_decimal.adb:34 explicit raise
[Bug c/59169] TLS definition in xxxtal.so section .tbss mismatches non-TLS definition in libclntsh.so .bss section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59169 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-11 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Without self-contained testcase there's nothing to do; see http://gcc.gnu.org/bugs/.
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Apr 11 17:08:47 2014 New Revision: 209309 URL: http://gcc.gnu.org/viewcvs?rev=209309root=gccview=rev Log: DR 1030 PR c++/51253 * cp-tree.h (CALL_EXPR_LIST_INIT_P): New. * call.c (struct z_candidate): Add flags field. (add_candidate): Add flags parm. (add_function_candidate, add_conv_candidate, build_builtin_candidate) (add_template_candidate_real): Pass it. (build_over_call): Set CALL_EXPR_LIST_INIT_P. * tree.c (build_aggr_init_expr): Copy it. * semantics.c (simplify_aggr_init_expr): Preevaluate args if it's set. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c
[Bug c/50466] Compiled code behaves differently with -O2 -fPIC flag combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50466 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- No feedback.
[Bug c/58309] spurious parameter set but not used warning in cilk plus array code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58309 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-11 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c++/58600] [c++11] ICE on wrong usage of alignas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58600 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/58601] [meta-bug] alignas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58601 Bug 58601 depends on bug 58600, which changed state. Bug 58600 Summary: [c++11] ICE on wrong usage of alignas http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58600 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58600] [c++11] ICE on wrong usage of alignas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58600 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Apr 11 17:36:44 2014 New Revision: 209310 URL: http://gcc.gnu.org/viewcvs?rev=209310root=gccview=rev Log: /cp 2014-04-11 Paolo Carlini paolo.carl...@oracle.com PR c++/58600 * name-lookup.c (parse_using_directive): Return early if the attribs argument is error_mark_node; use get_attribute_name. /testsuite 2014-04-11 Paolo Carlini paolo.carl...@oracle.com PR c++/58600 * g++.dg/cpp0x/gen-attrs-58.C: New. * g++.dg/cpp0x/gen-attrs-59.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-58.C trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-59.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug lto/60820] [4.9/4.10 Regression] ice in ctor_for_folding, at varpool.c:291
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- mine.
[Bug target/60811] arc/arc.c:2135: possible bad argument to abs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60811 --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Author: amylaar Date: Fri Apr 11 18:04:43 2014 New Revision: 209311 URL: http://gcc.gnu.org/viewcvs?rev=209311root=gccview=rev Log: PR target/60811 * config/arc/arc.c (arc_save_restore): Fix assert typo. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arc/arc.c
[Bug target/60826] New: inefficient code for vector xor on SSE2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60826
Bug ID: 60826
Summary: inefficient code for vector xor on SSE2
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sunfish at mozilla dot com
On the following C testcase:
#include stdint.h
typedef double v2f64 __attribute__((__vector_size__(16), may_alias));
typedef int64_t v2i64 __attribute__((__vector_size__(16), may_alias));
static inline v2f64 f_and (v2f64 l, v2f64 r) { return (v2f64)((v2i64)l
(v2i64)r); }
static inline v2f64 f_xor (v2f64 l, v2f64 r) { return (v2f64)((v2i64)l ^
(v2i64)r); }
static inline double vector_to_scalar(v2f64 v) { return v[0]; }
double test(v2f64 w, v2f64 x, v2f64 z)
{
v2f64 y = f_and(w, x);
return vector_to_scalar(f_xor(z, y));
}
GCC emits this code:
andpd%xmm1, %xmm0
movdqa%xmm0, %xmm3
pxor%xmm2, %xmm3
movdqa%xmm3, -24(%rsp)
movsd-24(%rsp), %xmm0
ret
GCC should move the result of the xor to the return register directly instead
of spilling it. Also, it should avoid the first movdqa, which is an unnecessary
copy.
Also, this should ideally use xorpd instead of pxor, to avoid a domain-crossing
penalty on Nehalem and other micro-architectures (or xorps if domain-crossing
doesn't matter, since its smaller).
[Bug rtl-optimization/60651] Mode switching instructions are sometimes emitted in the wrong order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651 --- Comment #4 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Author: amylaar Date: Fri Apr 11 18:12:53 2014 New Revision: 209312 URL: http://gcc.gnu.org/viewcvs?rev=209312root=gccview=rev Log: gcc: PR rtl-optimization/60651 * mode-switching.c (optimize_mode_switching): Make sure to emit sets of a lower numbered entity before sets of a higher numbered entity to a mode of the same or lower priority. When creating a seginfo for a basic block that starts with a code label, move the insertion point past the code label. (new_seginfo): Document and enforce requirement that NOTE_INSN_BASIC_BLOCK only appears for empty blocks. * doc/tm.texi.in: Document ordering constraint for emitted mode sets. * doc/tm.texi: Regenerate. gcc/testsuite: PR rtl-optimization/60651 * gcc.target/epiphany/mode-switch.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/mode-switching.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Apr 11 18:25:02 2014 New Revision: 209314 URL: http://gcc.gnu.org/viewcvs?rev=209314root=gccview=rev Log: DR 1467 PR c++/51747 * decl.c (reshape_init_r): Handle a single element of class type. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist83.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/g++.dg/init/aggr4.C
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #17 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Apr 11 18:25:13 2014 New Revision: 209316 URL: http://gcc.gnu.org/viewcvs?rev=209316root=gccview=rev Log: PR c++/57926 * c-common.c (sync_resolve_size, get_atomic_generic_size): Call default_conversion for an array argument. Added: trunk/gcc/testsuite/g++.dg/ext/atomic-2.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c
[Bug rtl-optimization/60651] Mode switching instructions are sometimes emitted in the wrong order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651 --- Comment #5 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Author: amylaar Date: Fri Apr 11 18:27:45 2014 New Revision: 209318 URL: http://gcc.gnu.org/viewcvs?rev=209318root=gccview=rev Log: gcc/testsuite: PR rtl-optimization/60651 * gcc.target/epiphany/mode-switch.c: New test. Added: trunk/gcc/testsuite/gcc.target/epiphany/mode-switch.c
[Bug other/60824] meta-bug: issues waiting for gcc 4.10 phase 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60824 Bug 60824 depends on bug 60651, which changed state. Bug 60651 Summary: Mode switching instructions are sometimes emitted in the wrong order http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/60651] Mode switching instructions are sometimes emitted in the wrong order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.10.0 Resolution|--- |FIXED Known to fail||4.9.0 --- Comment #6 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Fixed with commits of comment #4/#5.
[Bug target/60811] arc/arc.c:2135: possible bad argument to abs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60811 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Fixed with commit of comment #3.
[Bug other/60824] meta-bug: issues waiting for gcc 4.10 phase 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60824 Bug 60824 depends on bug 60811, which changed state. Bug 60811 Summary: arc/arc.c:2135: possible bad argument to abs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60811 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug other/60824] meta-bug: issues waiting for gcc 4.10 phase 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60824 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- gcc 4.10 phase 1 is now open.
