[Bug other/61391] [5 Regression] ICE in execute_one_pass at -O3 and above

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61391

Arseny Solokha  changed:

   What|Removed |Added

  Known to work||5.0
  Known to fail|4.10.0  |

--- Comment #5 from Arseny Solokha  ---
Yuri, you probably forgot to close the bug…

[Bug c++/63657] [4.9 regression] -Wunused-variable: warning supressed by virtual dtor

[petschy at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657

--- Comment #1 from petschy at gmail dot com ---
Bisected the regression:

commit a8b52ce38f3056e464457ba1e95efa25a8f08d07
Author: paolo 
Date:   Wed Jun 12 21:36:36 2013 +

/cp
2013-06-12  Paolo Carlini  

PR c++/38958
* decl.c (poplevel): For the benefit of -Wunused-variable see
through references.

/testsuite
2013-06-12  Paolo Carlini  

PR c++/38958
* g++.dg/warn/Wunused-var-20.C: New.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@200042
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/62305] throw segfaults on 64bit Cygwin

[dominik.stras...@onespin-solutions.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62305

dominik.stras...@onespin-solutions.com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from dominik.stras...@onespin-solutions.com ---
Problem has disappeared both due to code changes and cygwin/mingw updates.

[Bug go/60406] recover.go: test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406

--- Comment #29 from Dominik Vogt  ---
Thanks!

> It's necessary to handle all cases correctly.  But there is nothing wrong
> with using an efficient mechanism when it works, as long as we can correctly
> fall back to a more expensive mechanism when it fails.  I believe that my
> patch does that.

I'm fine with that.  But couldn't this also happen when copying multiple
arguments to the stack?  E.g. if you have an array A and call the function with
something like

  defer(foo(A[0], A[1], ... A[N])

gcc could turn that into a loop for a sufficiently large N?  This may be also
an unlikely case, but a test for this wouldn't hurt either.

> If you like, we can incorporate your patch too, as long as it is only an
> addition to the existing code.  Before calling runtime_callers, we can call
> _Unwind_FindEnclosingFunction.  Then we need only go on to the
> runtime_callers code if _Unwind_FindEnclosingFunction returns NULL, or in the
> cases where d->__makefunc_can_recover is true.

Given that my patch fails to work with indirect function pointers (Power) that
does not seem to be very helpful.

[Bug ipa/63664] New: ipa-icf pass fails with segfault

[enkovich.gnu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63664

Bug ID: 63664
   Summary: ipa-icf pass fails with segfault
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enkovich.gnu at gmail dot com

Created attachment 33825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33825&action=edit
Reproducer

There is a segfault in ipa-icf pass.

>g++ test.cpp -O2 -c

test.cpp:40:1: internal compiler error: Segmentation fault
 }
 ^
0xe87262 crash_signal
../../gcc-pl-ref/gcc/toplev.c:349
0x17000ad ipa_icf_gimple::func_checker::compatible_types_p(tree_node*,
tree_node*, bool, bool)
../../gcc-pl-ref/gcc/ipa-icf-gimple.c:172
0x170035c ipa_icf_gimple::func_checker::compare_operand(tree_node*, tree_node*)
../../gcc-pl-ref/gcc/ipa-icf-gimple.c:220
0x17020a2 ipa_icf_gimple::func_checker::compare_tree_ssa_label(tree_node*,
tree_node*)
../../gcc-pl-ref/gcc/ipa-icf-gimple.c:737
0x1702187
ipa_icf_gimple::func_checker::compare_gimple_label(gimple_statement_base*,
gimple_statement_base*)
../../gcc-pl-ref/gcc/ipa-icf-gimple.c:755
0x1701c29 ipa_icf_gimple::func_checker::compare_bb(ipa_icf_gimple::sem_bb*,
ipa_icf_gimple::sem_bb*)
../../gcc-pl-ref/gcc/ipa-icf-gimple.c:604
0x16f463b ipa_icf::sem_function::equals_private(ipa_icf::sem_item*,
hash_map&)
../../gcc-pl-ref/gcc/ipa-icf.c:455
0x16f3e74 ipa_icf::sem_function::equals(ipa_icf::sem_item*,
hash_map&)
../../gcc-pl-ref/gcc/ipa-icf.c:355
0x16f8687 ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool)
../../gcc-pl-ref/gcc/ipa-icf.c:1771
0x16f7d93 ipa_icf::sem_item_optimizer::execute()
../../gcc-pl-ref/gcc/ipa-icf.c:1590
0x16fa221 ipa_icf_driver
../../gcc-pl-ref/gcc/ipa-icf.c:2320
0x16fa736 ipa_icf::pass_ipa_icf::execute(function*)
../../gcc-pl-ref/gcc/ipa-icf.c:2368
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

>g++ -v
Using built-in specs.
COLLECT_GCC=../../../gcc-ref-build/bin/g++
COLLECT_LTO_WRAPPER=/export/users/ienkovic/gcc-ref-build/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-ref/configure
--prefix=/export/users/ienkovic/gcc-ref-build --enable-languages=c,c++,fortran
--disable-bootstrap
Thread model: posix
gcc version 5.0.0 20141024 (experimental) (GCC)


The problem is that compared labels have null types and
ipa_icf_gimple::func_checker::compatible_types_p doesn't check for null types. 
Possible patch:

diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index 1369b74..afc0eeb 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -169,6 +169,11 @@ bool func_checker::compatible_types_p (tree t1, tree t2,
   bool compare_polymorphic,
   bool first_argument)
 {
+  if (!t1 && !t2)
+return true;
+  else if (!t1 || !t2)
+return false;
+
   if (TREE_CODE (t1) != TREE_CODE (t2))
 return return_false_with_msg ("different tree types");



If we don't want labels to have null type then start_preparsed_function
(decl.c:13607) has to be fixed.

[Bug preprocessor/63662] __has_include is not implemented but it is defined, so "#ifdef __has_include" guards are ineffective in blocking usage of __has_include

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Richard Biener  ---
> gcc-4.9 -c tst.c
>

works for me.  Also works on trunk for me.

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-10-28
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
What function from the libm library ends up getting used for you?  (none is
used on x86_64-linux for me)

[Bug tree-optimization/63665] New: [5 Regression] wrong code with signed overflow even with -fwrapv

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63665

Bug ID: 63665
   Summary: [5 Regression] wrong code with signed overflow even
with -fwrapv
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 33826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33826&action=edit
reduced testcase (from gcc.c-torture/execute/20040409-1.c)

Output:
$ gcc -O -fno-tree-ccp -fno-tree-fre -fwrapv testcase.c
$ ./a.out 
Aborted

In the assembly output, main() unconditionally calls abort().

The original testcase, gcc.c-torture/execute/20040409-1.c, fails with:
$ gcc -O2 -flto -fno-tree-ccp -fno-tree-copy-prop -fno-tree-fre 20040409-1.i
$ ./a.out 
Aborted

Tested revisions:
r216724 - FAIL
4_9 r216431 - OK
4_8 r216430 - OK

[Bug c++/63658] [4.9/5 Regression] Using class reference as template parameter causes compilation to fail

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.2

[Bug tree-optimization/63660] -Wmaybe-uninitialized false positive with -O1 and more

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63660

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-28
  Component|driver  |tree-optimization
Summary|[4.8-4.9+]  |-Wmaybe-uninitialized false
   |-Wmaybe-uninitialized false |positive with -O1 and more
   |positive with -O1 and more  |
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.2, 5.0

--- Comment #1 from Richard Biener  ---
I think you hit one of the limits to avoid excessive compile-time for the
uninit analysis:

#define MAX_NUM_CHAINS 8
#define MAX_CHAIN_LEN 5
#define MAX_POSTDOM_CHECK 8

I suppose it's the MAX_POSTDOM_CHECK value.  Sadly those are not parameters
controllable by any --param.

There is --param uninit-control-dep-attempts though (but its default is 1000
which the testcase probably doesn't hit).

Confirmed with 4.8, 4.9 and 5.

[Bug c++/63657] [4.9/5 regression] -Wunused-variable: warning supressed by virtual dtor

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||paolo.carlini at oracle dot com
   Target Milestone|--- |4.9.2
Summary|[4.9 regression]|[4.9/5 regression]
   |-Wunused-variable: warning  |-Wunused-variable: warning
   |supressed by virtual dtor   |supressed by virtual dtor

[Bug tree-optimization/63665] [5 Regression] wrong code with signed overflow even with -fwrapv

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63665

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-10-28
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, I'll have a look.

[Bug tree-optimization/63665] [5 Regression] wrong code with signed overflow even with -fwrapv

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63665

--- Comment #2 from Richard Biener  ---
To better bisect this also use -fno-tree-copy-prop (which otherwise hides
this on the 4.9 branch for example).

It's forwprop that does the bogus transform on

  y_5 = -2147483648;
  _6 = y_5 + -2147483648;

which ends up calling fold_binary (NE_EXPR, y_5 + -2147483648, 0) which
computes it as 1.

8769  tree new_const = int_const_binop (reverse_op, const2, const1);

results in -2147483648(OVF) even though we have -fwrapv in effect which
the triggers

  /* If the constant operation overflowed this can be
 simplified as a comparison against INT_MAX/INT_MIN.  */
  if (TREE_OVERFLOW (new_const))
{

without changing how we compute TREE_OVERFLOW it seems that this test needs
to be guarded with !TYPE_OVERFLOW_WRAPS ().

[Bug target/63424] Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237

[renlin.li at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424

--- Comment #3 from Renlin Li  ---
I am working on this issue, and a patch is more or less done for it.

[Bug c/63645] Incorrect code generation

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645

--- Comment #25 from Mikael Pettersson  ---
So, is there a way to under-allocate a union (just allocate enough for the
member you want) and access it via the union pointer that is valid C?

[Bug tree-optimization/63666] New: [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666

Bug ID: 63666
   Summary: [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal
compiler error)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: rguenther at suse dot de
Target: ia64-*-*

Broken by r216728.

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/vect/pr45752.c -ftree-vectorize
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o
./pr45752.exe
../gcc/testsuite/gcc.dg/vect/pr45752.c: In function ‘foo’:
../gcc/testsuite/gcc.dg/vect/pr45752.c:38:6: internal compiler error: in
ia64_vectorize_vec_perm_const_ok, at config/ia64/ia64.c:11728
 void foo (unsigned int *__restrict__ pInput,
  ^
0x41069d9f ia64_vectorize_vec_perm_const_ok
../../gcc/config/ia64/ia64.c:11728
0x4090272f can_vec_perm_p(machine_mode, bool, unsigned char const*)
../../gcc/optabs.c:6611
0x40f387df vect_transform_slp_perm_load(_slp_tree*, vec, gimple_stmt_iterator*, int, _slp_instance*, bool)
../../gcc/tree-vect-slp.c:3049
0x40f3c99f vect_supported_load_permutation_p
../../gcc/tree-vect-slp.c:1349
0x40f3c99f vect_analyze_slp_instance
../../gcc/tree-vect-slp.c:1677
0x40f3d28f vect_analyze_slp(_loop_vec_info*, _bb_vec_info*, unsigned
int)
../../gcc/tree-vect-slp.c:1747
0x40f1674f vect_analyze_loop_2
../../gcc/tree-vect-loop.c:1762
0x40f1674f vect_analyze_loop(loop*)
../../gcc/tree-vect-loop.c:1875
0x40f4659f vectorize_loops()
../../gcc/tree-vectorizer.c:442
0x40d77abf execute
../../gcc/tree-ssa-loop.c:290

[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #1 from Jiong Wang  ---
I noticed this on aarch64 platform also and I suspect it's caused by

commit f619ecaed41d1487091098a0f4fdf4d6ed1fa379
Author: rguenth 
Date:   Mon Oct 27 11:30:23 2014 +

2014-10-27  Richard Biener  

* tree-ssa-forwprop.c: Include tree-cfgcleanup.h and tree-into-ssa.h.
(lattice): New global.
(fwprop_ssa_val): New function.
(fold_all_stmts): Likewise.
(pass_forwprop::execute): Finally fold all stmts.

* gcc.dg/tree-ssa/forwprop-6.c: Scan ccp1 dump instead.
* gcc.dg/strlenopt-8.c: Adjust and XFAIL for non_strict_align
target due to memcpy inline-expansion.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216728
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[vbraun.name at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

--- Comment #4 from Volker Braun  ---
Good point, -lm is not necessary. It was necessary in the original GSL
testsuite case, but I removed that part.

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #11 from Ramana Radhakrishnan  ---
Resolved then ?

[Bug target/61997] cc1plus ICE with aarch64 target using PCH and builtin functions

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61997

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |5.0
  Known to fail|4.10.0  |5.0

[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64 - Improve Generic register_move_cost and memory_move_cost

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915

Ramana Radhakrishnan  changed:

   What|Removed |Added

Summary|[AArch64] High amounts of   |[AArch64] High amounts of
   |GP to FP register moves |GP to FP register moves
   |using LRA on AArch64|using LRA on AArch64 -
   ||Improve Generic
   ||register_move_cost and
   ||memory_move_cost

--- Comment #19 from Ramana Radhakrishnan  ---
To my mind it seems like 407 fmoves is just a bit too berserk and regardless of
how efficient your core is, there is no point in having so many moves back and
forth.

[Bug target/61749] arm_neon.h "_lane" and "_n" intrinsics can cause ICEs

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail|4.10.0  |5.0

--- Comment #6 from Ramana Radhakrishnan  ---
Fixed on trunk.

[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-28
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #14 from Ramana Radhakrishnan  ---
This appears to have now morphed into a standards issue and possibly affects
all targets that have a weak memory model. Anyway confirming this.

[Bug target/61714] configure --with-arch and --with-cpu are ignored on aarch64

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61714

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #2 from Ramana Radhakrishnan  ---
Fixed on trunk unless you intend to backport the fix.

[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

--- Comment #2 from Andreas Schwab  ---
Also breaks gcc.dg/vect/vect-strided-a-u8-i2-gap.c

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c
-ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details
-lm -o ./vect-strided-a-u8-i2-gap.exe
../gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c: In function ‘main1’:
../gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c:34:16: internal
compiler error: in expand_expr_real_2, at expr.c:9156
   res[i].b = ptr->a;
^
0x4059052f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9156
0x40579c1f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9463
0x4058b71f store_expr(tree_node*, rtx_def*, int, bool)
../../gcc/expr.c:5344
0x4059701f expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5130
0x40381b7f expand_gimple_stmt_1
../../gcc/cfgexpand.c:3285
0x40381b7f expand_gimple_stmt
../../gcc/cfgexpand.c:3381
0x4038d89f expand_gimple_basic_block
../../gcc/cfgexpand.c:5216
0x403916ef execute
../../gcc/cfgexpand.c:5822

[Bug target/63173] performance problem with simd intrinsics vld2_dup_* on aarch64-none-elf

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63173

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #9 from Ramana Radhakrishnan  ---
Fixed on trunk.

[Bug target/63293] [AArch64] can read from deallocated stack

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64 - Improve Generic register_move_cost and memory_move_cost

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|ramana at gcc dot gnu.org  |wdijkstr at arm dot com
   Target Milestone|--- |5.0

[Bug target/63293] [AArch64] can read from deallocated stack

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293

--- Comment #3 from Jiong Wang  ---
patch pending review here

https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02292.html

[Bug middle-end/62178] [5.0 regression] [AArch64] Performance regression on matrix matrix multiply due to r211211

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-28
 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|[AArch64] Performance   |[5.0 regression] [AArch64]
   |regression on matrix matrix |Performance regression on
   |multiply due to r211211 |matrix matrix multiply due
   ||to r211211
 Ever confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  ---
Patch pending for review here 

https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02620.html

[Bug target/62173] [5.0 regression] [AArch64] Performance regression due to r213488

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173

--- Comment #4 from Jiong Wang  ---
interesting.

r213488 was doing something right, and I guess it exposed some other hidding
issues which need our investigations.

[Bug c/63663] [NEON] wrong value when computing the leading zero of int16x4_t type at O2

[spf_zju at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63663

--- Comment #1 from wind  ---
I find this issue is related to the definition of a MACRO.

/* The arm5 clz instruction returns 32.  */
#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE)  ((VALUE) = 32, 1).

I am confused that in the armv7 NEON, the mode is HI ,it is also equal 32. Is
it right ? anyone can give me some explanation .

I should post a patch to fix this bug soon.

[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-10-28
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
I will have a look.  Can you attach preprocessed source so I can investigate
with a cross?  Thx.

[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666

--- Comment #4 from Jiong Wang  ---
Created attachment 33827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33827&action=edit
./cc1 -O3 pr45752.i

upload testcase.

./cc1 (generated by--target=aarch64-elf) -O3 pr45752.i

[Bug tree-optimization/63666] [5.0 regression] FAIL: gcc.dg/vect/pr45752.c (internal compiler error)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666

--- Comment #5 from Richard Biener  ---
Ok, reproduced with a ia64 cross and a cut-down testcase w/o includes.

[Bug tree-optimization/63665] [5 Regression] wrong code with signed overflow even with -fwrapv

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63665

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 28 11:42:43 2014
New Revision: 216781

URL: https://gcc.gnu.org/viewcvs?rev=216781&root=gcc&view=rev
Log:
2014-10-28  Richard Biener  

PR middle-end/63665
* fold-const.c (fold_comparison): Properly guard simplifying
against INT_MAX/INT_MIN with !TYPE_OVERFLOW_WRAPS.

* gcc.dg/pr63665.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr63665.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/63665] [4.8/4.9 Regression] wrong code with signed overflow even with -fwrapv

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63665

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.0
   Target Milestone|5.0 |4.8.4
Summary|[5 Regression] wrong code   |[4.8/4.9 Regression] wrong
   |with signed overflow even   |code with signed overflow
   |with -fwrapv|even with -fwrapv
  Known to fail|5.0 |

--- Comment #4 from Richard Biener  ---
Fixed on trunk.  Leaving open for a backport to 4.9/4.8.  Regression marker
so I don't miss it when doing the next batch of backports.

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #5 from howarth at bromo dot med.uc.edu ---
Interestingly, I find on Yosemite that the system gcc produces...

% gcc -O0 -g -o test_mathieu test_mathieu.c -lm && ./test_mathieu
loop -2.35802
loop 2
loop 2
loop 2
loop 2

for -O0/-O1/-O2 when -g is used.

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

--- Comment #6 from howarth at bromo dot med.uc.edu ---
My mistake, I assumed the first output line was an error.

loop -2.35802

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

--- Comment #7 from howarth at bromo dot med.uc.edu ---
Created attachment 33828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33828&action=edit
assembly at -O2 from test_mathieu.c using clang as gcc in Xcode 6

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

--- Comment #8 from howarth at bromo dot med.uc.edu ---
Created attachment 33829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33829&action=edit
assembly at -O2 from test_mathieu.c using gcc 4.9.1-RC

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

--- Comment #9 from howarth at bromo dot med.uc.edu ---
Created attachment 33830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33830&action=edit
assembly at -O1 from test_mathieu.c using gcc 4.9.1-RC

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

--- Comment #10 from howarth at bromo dot med.uc.edu ---
for the testcase compiled with clang as gcc at -O2 on Yosemite

% setenv DYLD_PRINT_BINDINGS
% ./test_mathieu
dyld: bind: libgcc_s.1.dylib:0x1098E = libdyld.dylib:dyld_stub_binder,
*0x1098E = 0x7FFF9B4612A0
dyld: bind: test_mathieu:0x1098C8000 = libdyld.dylib:dyld_stub_binder,
*0x1098C8000 = 0x7FFF9B4612A0
dyld: resolver at 0x7fff9002924f returned 0x7FFF90029160
dyld: lazy bind: libsystem_c.dylib:0x7FFF7D8BB710 =
libsystem_platform.dylib:__platform_strchr, *0x7FFF7D8BB710 = 0x7FFF90029160
dyld: resolver at 0x7fff9002927a returned 0x7FFF9002D240
dyld: lazy bind: libsystem_c.dylib:0x7FFF7D8BB6E8 =
libsystem_platform.dylib:__platform_memmove, *0x7FFF7D8BB6E8 = 0x7FFF9002D240
dyld: resolver at 0x7fff9002927a returned 0x7FFF9002D240
dyld: lazy bind: libsystem_c.dylib:0x7FFF7D8BB6F0 =
libsystem_platform.dylib:__platform_memmove, *0x7FFF7D8BB6F0 = 0x7FFF9002D240
dyld: lazy bind: test_mathieu:0x1098C8010 = libsystem_c.dylib:_printf,
*0x1098C8010 = 0x7FFF8DA9C930
dyld: resolver at 0x7fff90028cad returned 0x7FFF90028B20
dyld: lazy bind: libsystem_c.dylib:0x7FFF7D8BB6D8 =
libsystem_platform.dylib:__platform_memchr, *0x7FFF7D8BB6D8 = 0x7FFF90028B20
loop -2.35802
loop 2.35802
loop 2.35802
loop 2.35802
loop 2.35802

for the testcase compiled with gcc 4.9.2-RC at -O2 on Yosemite

% setenv DYLD_PRINT_BINDINGS
% ./test_mathieu
dyld: bind: test_mathieu:0x103E32010 = libsystem_c.dylib:___stack_chk_guard,
*0x103E32010 = 0x7FFF7D8BF070
dyld: bind: test_mathieu:0x103E32000 = libdyld.dylib:dyld_stub_binder,
*0x103E32000 = 0x7FFF9B4612A0
dyld: resolver at 0x7fff9002924f returned 0x7FFF90029160
dyld: lazy bind: libsystem_c.dylib:0x7FFF7D8BB710 =
libsystem_platform.dylib:__platform_strchr, *0x7FFF7D8BB710 = 0x7FFF90029160
dyld: resolver at 0x7fff9002927a returned 0x7FFF9002D240
dyld: lazy bind: libsystem_c.dylib:0x7FFF7D8BB6E8 =
libsystem_platform.dylib:__platform_memmove, *0x7FFF7D8BB6E8 = 0x7FFF9002D240
dyld: resolver at 0x7fff9002927a returned 0x7FFF9002D240
dyld: lazy bind: libsystem_c.dylib:0x7FFF7D8BB6F0 =
libsystem_platform.dylib:__platform_memmove, *0x7FFF7D8BB6F0 = 0x7FFF9002D240
dyld: lazy bind: test_mathieu:0x103E32028 = libsystem_c.dylib:_printf,
*0x103E32028 = 0x7FFF8DA9C930
dyld: resolver at 0x7fff90028cad returned 0x7FFF90028B20
dyld: lazy bind: libsystem_c.dylib:0x7FFF7D8BB6D8 =
libsystem_platform.dylib:__platform_memchr, *0x7FFF7D8BB6D8 = 0x7FFF90028B20
loop -2.35802
loop 2
loop 2
loop 2
loop 2
dyld: resolver at 0x7fff90028e1a returned 0x7FFF9002DD10
dyld: lazy bind: test_mathieu:0x103E32018 = libsystem_platform.dylib:___bzero,
*0x103E32018 = 0x7FFF9002DD10

[Bug fortran/63667] New: ICE with DEFERRED procedure

[valeryweber at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63667

Bug ID: 63667
   Summary: ICE with DEFERRED procedure
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com

Hi All

the following (wrong) piece of code is producing an ICE with gcc 4.9.1

v

cat cuba_types.F90
MODULE cubature_types
  IMPLICIT NONE
  PRIVATE
  TYPE, ABSTRACT :: cu_user_function_type
   CONTAINS
 PROCEDURE( cu_user_function_interface ), DEFERRED :: evaluate
  END TYPE cu_user_function_type

  ABSTRACT INTERFACE
 FUNCTION cu_user_function_interface ( this, r ) RESULT( reslt )
   IMPORT :: cu_user_function_type
   CLASS( cu_user_function_type ), INTENT( INOUT ) :: this
   REAL, DIMENSION( : ), INTENT( IN ) :: r
   REAL :: reslt
 END FUNCTION cu_user_function_interface
  END INTERFACE

  TYPE, PUBLIC :: cu_type
 PRIVATE
 LOGICAL :: init = .FALSE.
 CLASS( cu_user_function_type ) :: user_func
   CONTAINS
 PROCEDURE, PASS :: integrate => cu_integrate
  END TYPE cu_type

CONTAINS

  SUBROUTINE cu_integrate ( this )
CLASS(cu_type), INTENT(INOUT):: this
REAL, DIMENSION(3) :: r
r = 1.0
write(*,*) this%user_func%evaluate ( r )
  END SUBROUTINE cu_integrate

END MODULE cubature_types

gfortran-4.9.1 cuba_types.F90
cuba_types.F90:21.48:

 CLASS( cu_user_function_type ) :: user_func
1
Error: Component 'user_func' with CLASS at (1) must be allocatable or pointer
f951: internal compiler error: in check_typebound_baseobject, at
fortran/resolve.c:5369
0x5bb9a8 check_typebound_baseobject
../../gcc-4.9.1/gcc/fortran/resolve.c:5369
0x5be5ce resolve_compcall
../../gcc-4.9.1/gcc/fortran/resolve.c:5656
0x5b4de2 resolve_typebound_function
../../gcc-4.9.1/gcc/fortran/resolve.c:5798
0x5b4de2 gfc_resolve_expr(gfc_expr*)
../../gcc-4.9.1/gcc/fortran/resolve.c:6107
0x5bf9ee gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-4.9.1/gcc/fortran/resolve.c:9804
0x5c124b gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-4.9.1/gcc/fortran/resolve.c:9021
0x5beac7 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-4.9.1/gcc/fortran/resolve.c:9794
0x5c140e resolve_codes
../../gcc-4.9.1/gcc/fortran/resolve.c:14719
0x5c1317 resolve_codes
../../gcc-4.9.1/gcc/fortran/resolve.c:14705
0x5b2385 gfc_resolve
../../gcc-4.9.1/gcc/fortran/resolve.c:14747
0x5b2385 gfc_resolve(gfc_namespace*)
../../gcc-4.9.1/gcc/fortran/resolve.c:14733
0x5a76ea gfc_parse_file()
../../gcc-4.9.1/gcc/fortran/parse.c:5089
0x5e4ca5 gfc_be_parse_file
../../gcc-4.9.1/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

gfortran-4.9.1 --version
GNU Fortran (GCC) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

--- Comment #11 from howarth at bromo dot med.uc.edu ---
This issue isn't specific to Yosemite. I also see the failure at -O2 with
gcc-4.9.1 on darwin13.4.0 using the cctools (as and ld) from Xcode 6.

[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

--- Comment #15 from Andrew Macleod  ---
Created attachment 33831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33831&action=edit
promote memory order consume to acquire

So have we concluded that we should promote memory_order_consume to
memory_order_acquire for now?  

That change should be fairly trivial. builtins.c::get_memmodel would simply
change any consumes to acquire.  All consumes would then be promoted to
acquire.

I don't know if libatomic does much with consume, but once compiled with this
patch in the compiler, it will also generate acquire code for consumes.

Here's an untested patch provided if someone wants to experiment.

[Bug target/63663] [NEON] wrong value when computing the leading zero of int16x4_t type at O2

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63663

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target|armeb-linux-gnueabi |armeb-linux-gnueabi,
   ||arm-none-linux-gnueabihf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-28
 CC||michael.collison at linaro dot 
org
   ||, ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Patch being discussed here.

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00731.html

[Bug tree-optimization/63574] [5 Regression] ICE building libjava (segfault) on arm-linux-gnueabihf

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63574

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target|arm-linxux-gnueabihf|arm-linux-gnueabihf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-28
 CC||ramana at gcc dot gnu.org
  Component|bootstrap   |tree-optimization
 Ever confirmed|0   |1

[Bug tree-optimization/63530] GCC generates incorrect aligned store on ARM after the loop is unrolled.

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
Version|5.0 |4.9.0
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.2
  Known to fail||4.9.0, 4.9.1, 5.0

--- Comment #6 from Ramana Radhakrishnan  ---
Fixed then ?

[Bug tree-optimization/63665] [4.8/4.9 Regression] wrong code with signed overflow even with -fwrapv

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63665

--- Comment #5 from Richard Biener  ---
Latent issue.

pr45752.c:40:3: note: Load permutation 2 2 2 2 2 3 3 3 3 3 0 0 0 0 0 1 1 1 1 1
4 4 4 4 4

We have a SLP group size of 5 and computed an unroll factor of 2 (ok).  It
looks
to me that

Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 216771)
+++ gcc/tree-vect-slp.c (working copy)

@@ -3041,6 +3041,7 @@ vect_transform_slp_perm_load (slp_tree n
  &number_of_mask_fixes, &mask_fixed,
  &needs_first_vector))
return false;
+ gcc_assert (current_mask_element < 2 * nunits);
  mask[index++] = current_mask_element;

   if (index == nunits)

makes x86_64 ICE as well.  The issue is that we suddenly need to skip _two_
vectors in vect_get_mask_element which isn't implemented so we get
out-of-bound indexes.  Seems we need to iterate instead in which case
we will reject vectorization correctly with

pr45752.c:40:3: note: Load permutation 2 2 2 2 2 3 3 3 3 3 0 0 0 0 0 1 1 1 1 1
4 4 4 4 4
pr45752.c:40:3: note: permutation requires at least three vectors c_71 =
MEM[(unsigned int *)pInput2_135 + 8B];

pr45752.c:40:3: note: Build SLP failed: unsupported load permutation
*pOutput2_136 = _83;

[Bug testsuite/62286] [ARM] 4.9 Regression fails for cortex-m3 for vfp-1.c: fmacs, fmscs, fnmacs, fnmscs

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62286

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-28
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Because the Cortex-M3 doesn't have those instructions ? It's a testism probably
fixed by an appropriate dg-options values.

[Bug rtl-optimization/63210] ira does not select the best register compared with gcc 4.8 for ARM THUMB1

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
  Known to work||4.8.3
  Known to fail||5.0

--- Comment #3 from Ramana Radhakrishnan  ---
Fixed is it? And does it fail in GCC 4.9 ?

[Bug target/60882] [ARM] Execution fail on spec2K/197.parser

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60882

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  ---
A reduced testcase will be useful 

[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

--- Comment #16 from joseph at codesourcery dot com  ---
My view is promote consume to acquire until the standards committees and 
formal model people have sorted out what to do with it.

[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[jan.kratochvil at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880

Jan Kratochvil  changed:

   What|Removed |Added

 CC||jan.kratochvil at redhat dot 
com

--- Comment #5 from Jan Kratochvil  ---
It causes GDB go testsuite regression:
https://sourceware.org/bugzilla/show_bug.cgi?id=17517

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug target/63668] New: -mstd-struct-return fails for non-leaf functions

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63668

Bug ID: 63668
   Summary: -mstd-struct-return fails for non-leaf functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org

With optimization, the return address adjustment that's
applied for -mstd-struct-return is deleted as dead code,
resulting in a return directly to the unimp insn.

struct S { int x, y, z; };

void bar(void);
struct S foo(void)
{
  struct S s = { 1, 2, 3 };
  bar();
  return s;
}

-O0:
save%sp, -128, %sp
ld  [%i7+8], %g1
add %i7, 4, %i7
cmp %g1, 12
be  .L2
 nop
sub %i7, 4, %i7
add %fp, -20, %g1
st  %g1, [%fp+64]
.L2:


-O2:
foo:
save%sp, -112, %sp
ld  [%i7+8], %g1
cmp %g1, 12
be  .L2
 add%fp, -4, %g1
st  %g1, [%fp+64]
.L2:

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[izamyatin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534

--- Comment #50 from Igor Zamyatin  ---
> In addition r216154 breaks a lot of asan tests with -m32: see
> 
> https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html

Could you please try following patch?

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 5580ea8..508db5d 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1715,6 +1715,9 @@ expand_used_vars (void)
-
   init_vars_expansion ();
-
+  if (targetm.use_pseudo_pic_reg ())
+pic_offset_table_rtx = gen_reg_rtx (Pmode);
+
   hash_map ssa_name_decls;
   for (i = 0; i < SA.map->num_partitions; i++)
 {
diff --git a/gcc/function.c b/gcc/function.c
index ee229ad..dab691d 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -3464,11 +3464,6 @@ assign_parms (tree fndecl)
-
   fnargs.release ();
-
-  /* Initialize pic_offset_table_rtx with a pseudo register
- if required.  */
-  if (targetm.use_pseudo_pic_reg ())
-pic_offset_table_rtx = gen_reg_rtx (Pmode);
-
   /* Output all parameter conversion instructions (possibly including calls)
  now that all parameters have been copied out of hard registers.  */
   emit_insn (all.first_conversion_insn);

[Bug target/61153] [ARM] vbic vorn tests fail

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #10 from Ramana Radhakrishnan  ---
(In reply to Bernd Edlinger from comment #9)
> Hi, these tests are still failing.
> what are we gonna do about it?


I am happy for a patch to delete them.


Ramana

[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|WAITING |NEW

--- Comment #12 from Richard Biener  ---
Reproduces with -O2 -fPIC -mtune=nehalem on x86_64-linux for me.

[Bug target/63661] [4.9/5 Regression] -O2 miscompiles on OSX 10.10 Yosemite

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.8.3
   Target Milestone|--- |4.9.2
Summary|-O2 miscompiles on OSX  |[4.9/5 Regression] -O2
   |10.10 Yosemite  |miscompiles on OSX 10.10
   ||Yosemite
  Known to fail||4.9.1, 5.0

--- Comment #13 from Richard Biener  ---
4.8 doesn't know nehalem but works with -mtune=native (where 4.9 and 5 break).

[Bug target/61153] [ARM] vbic vorn tests fail

[christophe.lyon at st dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #11 from christophe.lyon at st dot com ---
(In reply to Ramana Radhakrishnan from comment #10)
> (In reply to Bernd Edlinger from comment #9)
> > Hi, these tests are still failing.
> > what are we gonna do about it?
>  
> 
> I am happy for a patch to delete them.
> 
> 
> Ramana

What about modifying the tests to use -O2 instead of -O0?

At least, this would enable checking that the expected instruction is
generated.

[Bug target/61153] [ARM] vbic vorn tests fail

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #12 from Ramana Radhakrishnan  ---
(In reply to christophe.lyon from comment #11)
> (In reply to Ramana Radhakrishnan from comment #10)
> > (In reply to Bernd Edlinger from comment #9)
> > > Hi, these tests are still failing.
> > > what are we gonna do about it?
> >  
> > 
> > I am happy for a patch to delete them.
> > 
> > 
> > Ramana
> 
> What about modifying the tests to use -O2 instead of -O0?
> 
> At least, this would enable checking that the expected instruction is
> generated.

Sure - patches welcome :)

[Bug preprocessor/42014] Inconsistent column number display for "In file incuded from"

[vreeland.justin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42014

Justin Vreeland  changed:

   What|Removed |Added

 CC||vreeland.justin at gmail dot 
com

--- Comment #4 from Justin Vreeland  ---
Created attachment 33832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33832&action=edit
adds column to output

The currently attached patch doesn't apply cleanly I'm uploading another that
does, it's essentially the same patch.

Without patch:

In file included from /usr/include/c++/4.9.1/iostream:39:0,
 from test.cxx:1:

With patch:

In file included from
/extra/gcc/bug42014/patched/gcc/pkg/gcc/usr/include/c++/4.9.1/iostream:39:0,
 from test.cxx:1,0:

Which matches the error location.

[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953

[renlin.li at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529

--- Comment #9 from Renlin Li  ---
r215830 fixes this ICE

[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #10 from Jiong Wang  ---
(In reply to Renlin Li from comment #9)
> r215830 fixes this ICE

Maybe it's a partial fix. Because I verified the testcase in comment #2 still
ICE on aarch64-none-elf.

[Bug middle-end/63669] New: [AArch64] gcc.dg/torture/asm-subreg-1.c ICE in reload.c on 4.8 branch or on 4.9 and 5.0 with -mno-lra

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63669

Bug ID: 63669
   Summary: [AArch64] gcc.dg/torture/asm-subreg-1.c ICE in
reload.c on 4.8 branch or on 4.9 and 5.0 with -mno-lra
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org

gcc.dg/torture/asm-subreg-1.c ICEs with:

$ aarch64-none-elf-gcc $TOP/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c
-fno-diagnostics-show-caret -O1 -S  -o asm-subreg-1.s
$TOP/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c: In function
'evas_common_convert_yuv_420p_601_rgba':
$TOP/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:14:1: internal compiler error:
Segmentation fault
0x9ec985 crash_signal
$TOP/gcc/toplev.c:349
0x972555 find_reloads_address_part
$TOP/gcc/reload.c:6106
0x972134 find_reloads_address
$TOP/gcc/reload.c:5273
0x974936 find_reloads(rtx_insn*, int, int, int, short*)
$TOP/gcc/reload.c:2895
0x984e92 calculate_needs_all_insns
$TOP/gcc/reload1.c:1519
0x98679b reload(rtx_insn*, int)
$TOP/gcc/reload1.c:1007
0x87eaa2 do_reload
$TOP/gcc/ira.c:5386
0x87eaa2 execute
$TOP/gcc/ira.c:5536
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Since this happens reload it needs an -mno-lra to reproduce on trunk and 4.9

[Bug middle-end/63669] [AArch64] gcc.dg/torture/asm-subreg-1.c ICE in reload.c on 4.8 branch or on 4.9 and 5.0 with -mno-lra

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63669

--- Comment #1 from Andrew Pinski  ---
it also fails with -fPIC on aarch64 even without -mno-lra.

[Bug middle-end/63669] [AArch64] gcc.dg/torture/asm-subreg-1.c ICE in reload.c on 4.8 branch or on 4.9 and 5.0 with -fPIC

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63669

--- Comment #3 from Andrew Pinski  ---
We (Cavium) had worked on trying to this bug earlier:
https://gcc.gnu.org/ml/gcc-patches/2012-11/msg02286.html

Richard S. also worked on it too:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00826.html

[Bug middle-end/63669] [AArch64] gcc.dg/torture/asm-subreg-1.c ICE in reload.c on 4.8 branch or on 4.9 and 5.0 with -fPIC

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63669

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||aarch64-none-elf
Summary|[AArch64]   |[AArch64]
   |gcc.dg/torture/asm-subreg-1 |gcc.dg/torture/asm-subreg-1
   |.c ICE in reload.c on 4.8   |.c ICE in reload.c on 4.8
   |branch or on 4.9 and 5.0|branch or on 4.9 and 5.0
   |with -mno-lra   |with -fPIC
  Known to fail||4.8.4, 4.9.2, 5.0
   Severity|minor   |normal

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> it also fails with -fPIC on aarch64 even without -mno-lra.

Indeed, with the backtrace:
$TOP/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:14:1: internal compiler error:
in lra_set_insn_recog_data, at lra.c:945
0x8bb49b lra_set_insn_recog_data(rtx_insn*)
$TOP/gcc/lra.c:943
0x8bc425 lra_get_insn_recog_data
$TOP/gcc/lra-int.h:475
0x8bc425 lra_update_insn_regno_info(rtx_insn*)
$TOP/gcc/lra.c:1584
0x8bc670 lra_push_insn_1
$TOP/gcc/lra.c:1637
0x8bc670 lra_push_insn(rtx_insn*)
$TOP/gcc/lra.c:1645
0x8bc829 push_insns
$TOP/gcc/lra.c:1688
0x8bcd0c lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
$TOP/gcc/lra.c:1734
0x8ccede curr_insn_transform
$TOP/gcc/lra-constraints.c:3741
0x8cdede lra_constraints(bool)
$TOP/gcc/lra-constraints.c:4237
0x8bd96c lra(_IO_FILE*)
$TOP/gcc/lra.c:2178
0x87e00a do_reload
$TOP/gcc/ira.c:5374
0x87e00a execute
$TOP/gcc/ira.c:5536
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/63669] [AArch64] gcc.dg/torture/asm-subreg-1.c ICE in reload.c on 4.8 branch or on 4.9 and 5.0 with -fPIC

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63669

Andrew Pinski  changed:

   What|Removed |Added

 Target|aarch64-none-elf|aarch64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-28
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
.

[Bug tree-optimization/63530] GCC generates incorrect aligned store on ARM after the loop is unrolled.

[carrot at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530

--- Comment #7 from Carrot  ---
(In reply to Ramana Radhakrishnan from comment #6)
> Fixed then ?

Yes, thanks for closing it.

[Bug inline-asm/62144] "Frame pointer required, but reserved" error with -fomit-frame-pointer but only with -m32 -O2

[luk32 at o2 dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144

Łukasz Kucharski  changed:

   What|Removed |Added

 CC||luk32 at o2 dot pl

--- Comment #5 from Łukasz Kucharski  ---
Created attachment 33833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33833&action=edit
Example program that fails compilation with optimization enabled.

[Bug preprocessor/63670] New: Ending C_INCLUDE_PATH with a trailing colon broken

[nightstrike at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63670

Bug ID: 63670
   Summary: Ending C_INCLUDE_PATH with a trailing colon broken
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com

If the C_INCLUDE_PATH environment variable ends with a colon, which can happen
with typical "prepend" scripts of the form:

C_INCLUDE_PATH=/path:$C_INCLUDE_PATH

then gcc will treat every file included with <> instead of "" as being a system
header, and will not generate any warnings.  The following is a test case that
I have been using, as I got burned on a bug from not seeing the warning that
set me back several days:

a.c:
int f() {}

b.c:
#include 



Expected output:
$ gcc b.c -Wall
./a.c: In function ‘f’:
./a.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
 int f() {}
 ^


However:
$ export C_INCLUDE_PATH=:
$ gcc b.c -Wall


** No output **

[Bug inline-asm/62144] "Frame pointer required, but reserved" error with -fomit-frame-pointer but only with -m32 -O2

[luk32 at o2 dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144

--- Comment #6 from Łukasz Kucharski  ---
Comment on attachment 33833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33833
Example program that fails compilation with optimization enabled.

Hello, 

I believe we run into the same problem, however we extracted example that
doesn't need `-m32`. Just `-O2` breaks the build. gcc-4.8 passed with no
problems.

With regards,
luk32.

[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

[torvald at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

--- Comment #17 from torvald at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #15)
> So have we concluded that we should promote memory_order_consume to
> memory_order_acquire for now?  

I also think that this is the best way forward.  I believe everyone in ISO C++
SG1 agreed that this is basically a defect in the standard.

What I haven't thought through is how to deal with with carries_dependency
(7.6.4 in C++11): For GCC code generated after we promote consume to acquire,
it can safely be ignored; but should GCC code be linked to code generated by
another compiler that does not promote and expects the code to preserve
dependencies, this won't work.

I am not aware of any shipping compiler that would actually try to preserve
dependencies, and nobody else mentioned any during the discussion of this topic
in ISO C++ SG1.  Thus, we could assume that there are no such other compilers,
and make it part of the ABI (assumptions) that consume is promoted to acquire
in a correct compiler.

Alternatively, we could try to be conservative and add an acquire barrier
before the function body if any parameter of the function has
carries_dependency; and, likewise, add an acquire barrier after every call to a
function which has carries_dependency.

I don't have more input from the ISO C side, but I would guess that the
situation there is similar.

Thoughts?

[Bug preprocessor/63670] Ending C_INCLUDE_PATH with a trailing colon broken

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63670

--- Comment #1 from Andreas Schwab  ---
Since C_INCLUDE_PATH defines the path for system headers, this doesn't look
like a bug.

[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

[t.p.northover at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

--- Comment #18 from Tim Northover  ---
> I am not aware of any shipping compiler that would actually try to preserve 
> dependencies, and nobody else mentioned any during the discussion of this 
> topic in ISO C++ SG1.

In case the data point is useful, Clang promotes consume to acquire at the
moment (though I wouldn't rule out bugs even in that choice).

[Bug preprocessor/63670] Ending C_INCLUDE_PATH with a trailing colon broken

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63670

--- Comment #2 from Jonathan Wakely  ---
I think this is the correct behaviour, and this is basically a dup of PR30439

[Bug preprocessor/63670] Ending C_INCLUDE_PATH with a trailing colon broken

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63670

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
C_INCLUDE_PATH is exactly like PATH and that an empty part is considered the
current working directory.

[Bug ipa/63671] New: [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671

Bug ID: 63671
   Summary: [5 Regression] 21% tramp3d-v4 performance hit due to
-fdevirtualize
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org

On my AMD machine I get:

markus@x4 ~ % time g++ -Ofast tramp3d-v4.cpp
23.540 total
markus@x4 ~ % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20
...
Time spent in iteration: 3.79717

markus@x4 ~ % time g++ -Ofast -fno-devirtualize tramp3d-v4.cpp
22.163 total
markus@x4 ~ % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20
...
Time spent in iteration: 2.97514

For gcc-4.9 -fno-devirtualize makes no difference and I get on both cases:
Time spent in iteration: 3.02253

[Bug ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671

--- Comment #1 from Markus Trippelsdorf  ---
It gets worse with -flto:

markus@x4 ~ % g++ -w -Ofast -flto=4 tramp3d-v4.cpp
markus@x4 ~ % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20
...
Time spent in iteration: 4.6181

For "-fno-devirtualize -flto=4" the result is the same as without -flto.

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503

--- Comment #21 from Evandro  ---
(In reply to ramana.radhakrish...@arm.com from comment #20)
> What's the kind of performance delta you see if you managed to unroll 
> the loop just a wee bit ? Probably not much looking at the code produced 
> here.

Comparing the cycle counts on Juno when running the program from the matrix
multiplication test above built with -Ofast and unrolling:

-fno-unroll-loops: 592000
-funroll-loops --param max-unroll-times=2: 594000
-funroll-loops --param max-unroll-times=4: 592000
-funroll-loops: 59 (implies --param max-unroll-times=8)
-funroll-loops --param max-unroll-times=16: 581000

It seems to me that without effective iv-opt in place, loops have to be
unrolled too aggressively to make any difference in this case, greatly
sacrificing code size.

[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)

[paul.richard.thomas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205

paul.richard.thomas at gmail dot com  
changed:

   What|Removed |Added

 CC||paul.richard.thomas at gmail 
dot c
   ||om

--- Comment #3 from paul.richard.thomas at gmail dot com  ---
Created attachment 33834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33834&action=edit
Very deficient, first order patch

The attached is deficient in a number of ways:
(i) It will not work with a dynamic type result != declared type
(ii) The block in trans-array.c:2549-2560 needs to be moved to somewhere more
appropriate
(iii) Find out why info->delta[] is not set
(iv) dynamic types with allocatable components will have to have those
components deallocated (use _copy with default_init?)

Apart from that, it's a start :-)

Paul

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

--- Comment #17 from Manuel López-Ibáñez  ---
Author: manu
Date: Tue Oct 28 21:56:24 2014
New Revision: 216812

URL: https://gcc.gnu.org/viewcvs?rev=216812&root=gcc&view=rev
Log:
2014-10-28  Manuel López-Ibáñez  

PR fortran/44054
* gfortran.h (gfc_warning_cmdline): Rename as gfc_warning_now_2.
(gfc_error_cmdline): Rename as gfc_error_now_2.
* error.c (gfc_diagnostic_build_locus_prefix): Remove trailing space.
(gfc_diagnostic_starter): Add space between locus and prefix.
(gfc_warning_now_2): Renamed from gfc_warning_cmdline.
(gfc_error_now_2): Renamed from gfc_error_cmdline.
* scanner.c (add_path_to_list): Use gfc_warning_now_2.
(load_line): Likewise.
(load_file): Likewise.
* options.c (gfc_post_options): Update all renamed functions.



Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/options.c
trunk/gcc/fortran/scanner.c

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[wdijkstr at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503

--- Comment #22 from Wilco  ---
(In reply to Evandro from comment #21)
> (In reply to ramana.radhakrish...@arm.com from comment #20)
> > What's the kind of performance delta you see if you managed to unroll 
> > the loop just a wee bit ? Probably not much looking at the code produced 
> > here.
> 
> Comparing the cycle counts on Juno when running the program from the matrix
> multiplication test above built with -Ofast and unrolling:
> 
> -fno-unroll-loops: 592000
> -funroll-loops --param max-unroll-times=2: 594000
> -funroll-loops --param max-unroll-times=4: 592000
> -funroll-loops: 59 (implies --param max-unroll-times=8)
> -funroll-loops --param max-unroll-times=16: 581000
> 
> It seems to me that without effective iv-opt in place, loops have to be
> unrolled too aggressively to make any difference in this case, greatly
> sacrificing code size.

Unrolling alone isn't good enough in sum reductions. As I mentioned before, GCC
doesn't enable any of the useful loop optimizations by default. So add
-fvariable-expansion-in-unroller to get a good speedup with unrolling. Again
these are all generic GCC issues.

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503

--- Comment #23 from Evandro  ---
(In reply to Wilco from comment #22)
> Unrolling alone isn't good enough in sum reductions. As I mentioned before,
> GCC doesn't enable any of the useful loop optimizations by default. So add
> -fvariable-expansion-in-unroller to get a good speedup with unrolling. Again
> these are all generic GCC issues.

Adding -fvariable-expansion-in-unroller when using -funroll-loops results in
practically the same code being emitted.

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[wdijkstr at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503

--- Comment #24 from Wilco  ---
(In reply to Evandro from comment #23)
> (In reply to Wilco from comment #22)
> > Unrolling alone isn't good enough in sum reductions. As I mentioned before,
> > GCC doesn't enable any of the useful loop optimizations by default. So add
> > -fvariable-expansion-in-unroller to get a good speedup with unrolling. Again
> > these are all generic GCC issues.
> 
> Adding -fvariable-expansion-in-unroller when using -funroll-loops results in
> practically the same code being emitted.

Correct, all it does is cut the dependency chain of the accumulates. But that's
enough to get the speedup.

[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

--- Comment #19 from joseph at codesourcery dot com  ---
On Tue, 28 Oct 2014, torvald at gcc dot gnu.org wrote:

> Alternatively, we could try to be conservative and add an acquire barrier
> before the function body if any parameter of the function has
> carries_dependency; and, likewise, add an acquire barrier after every call to 
> a
> function which has carries_dependency.
> 
> I don't have more input from the ISO C side, but I would guess that the
> situation there is similar.

As previously noted:

* ISO C does not have carries_dependency (or attributes at all).

* carries_dependency is about increasing optimization, not decreasing it.  
If it affects when barriers are added, it does so by allowing some 
barriers to be omitted that would otherwise be required.

[Bug target/62308] A bug with aarch64 big-endian

[fei.yang0953 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308

Fei Yang  changed:

   What|Removed |Added

 CC||fei.yang0953 at gmail dot com

--- Comment #9 from Fei Yang  ---
(In reply to Vladimir Makarov from comment #8)
> (In reply to Venkataramanan from comment #7)

> Where reload gets 
> 
> (set
> (reg:DI 0 x0 [76]) (reg:DI 1 x1 [ args+8 ]))
> (set (reg:TI 0 x0 [74])
> (reg:TI -1 [+-8 ])
> 
> Looks same issue to me. 
> 
> Vladimir can you
> please confirm.

Now as I am less busy with the rematerialization pass, I'll
> look at this problem on this week.  Thanks.

Hello Vladimir,
  Any progress on this issue? This bug bothers me too. Thanks

[Bug rtl-optimization/63210] ira does not select the best register compared with gcc 4.8 for ARM THUMB1

[zhenqiang.chen at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210

--- Comment #4 from Zhenqiang Chen  ---
(In reply to Ramana Radhakrishnan from comment #3)
> Fixed is it? And does it fail in GCC 4.9 ?

Fixed on trunk. Same fail in GCC 4.9.

It is a performance issue. Do you think it is OK for 4.9?

[Bug target/63672] New: xbegin/xend/xabort missing memory barriers

[andi-gcc at firstfloor dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63672

Bug ID: 63672
   Summary: xbegin/xend/xabort missing memory barriers
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org

Created attachment 33835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33835&action=edit
proposed patch adding barriers

No test case currently, but we got a report that the builtins for x86 RTM
xbegin/xend/xabort are missing implicit memory barriers. This can cause code to
be moved outside the critical sections, breaking the program.