[Bug plugins/62252] a callback to event PLUGIN_FINISH_TYPE segfaults

[klemen.jan.enova at gmail dot com]

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

klemen.jan.enova at gmail dot com changed:

   What|Removed |Added

 CC||klemen.jan.enova at gmail dot 
com

--- Comment #4 from klemen.jan.enova at gmail dot com ---
Created attachment 33391
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33391&action=edit
cp-parser-patch

Fixes the bug. If I use debug_tree(type) in handle_struct(), it prints a
RECORD_TYPE only once, because the type declaration and definition happens only
once, other uses of the identifier "struct S" are variable declarations.

[Bug c++/34938] ICE with function pointers and attribute noreturn

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

  Known to work||4.8.3, 4.9.1, 5.0

--- Comment #3 from Paolo Carlini  ---
Thus I'm closing the bug as fixed.

Before that I'm committing to mainline a tweak to the diagnostic, ensuring that
we actually print __attribute((noreturn)) instead of volatile.

[Bug c++/34938] ICE with function pointers and attribute noreturn

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Aug 25 08:32:04 2014
New Revision: 214415

URL: https://gcc.gnu.org/viewcvs?rev=214415&root=gcc&view=rev
Log:
/cp
2014-08-25  Paolo Carlini  

PR c++/34938
* cp-tree.h (TFF_POINTER): Add.
* cxx-pretty-print.h (pp_cxx_cv_qualifiers): Forward the third
argument too.
* error.c (dump_type_suffix): Actually print the const and noreturn
attribute when appropriate.

/testsuite
2014-08-25  Paolo Carlini  

PR c++/34938
* g++.dg/template/pr34938-1.C: New.
* g++.dg/template/pr34938-2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/template/pr34938-1.C
trunk/gcc/testsuite/g++.dg/template/pr34938-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cxx-pretty-print.h
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/34938] ICE with function pointers and attribute noreturn

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Paolo Carlini  ---
Done.

[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept

[tony.wang at arm dot com]

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

wangzheyu  changed:

   What|Removed |Added

 CC||tony.wang at arm dot com

--- Comment #6 from wangzheyu  ---
Confirmed on arm tagret, and there's an old discussion on this:
http://gcc.gnu.org/ml/gcc/2007-08/msg00235.html. I'm working on a patch to fix
this.

[Bug c++/61825] [5 regression] g++.dg/cpp0x/static_assert9.C FAILs

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from amker at gcc dot gnu.org ---
Also on aarch64/arm, both linux and elf tool-chains.

[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept

[tony.wang at arm dot com]

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

--- Comment #7 from wangzheyu  ---
Another test case doesn't involve noexcept key workd.

Cmd line: arm-none-eabi-g++ -mthumb -mcpu=cortex-m3 -O0 -g -std=c++11
-specs=rdimon.specs main.c -o main.exe

#include 
#include 
_Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg) {
  void *ip = (void *)_Unwind_GetIP(context);
  printf("Address: %p\n", ip);
  return _URC_NO_REASON;
}
void bar()
{
puts("This is in bar");
_Unwind_Backtrace((_Unwind_Trace_Fn)&trace_func, 0);
}
void foo()
{
  try
  {
bar();
  }
  catch (...)
  {
puts("Exception");
  }
}

[Bug target/62254] New: gcc-4.9 miscompiles linux kernel zlib for armv3

[kugan at gcc dot gnu.org]

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

Bug ID: 62254
   Summary: gcc-4.9 miscompiles linux kernel zlib for armv3
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org

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

rm-none-linux-gnueabi-gcc -O -march=armv3 inffast.i 
inffast.i: In function ‘inflate_fast’:
inffast.i:385:1: internal compiler error: Segmentation fault
 }
 ^
0x9b878f crash_signal
/home/kugan/work/sources/gcc-fsf/trunk/gcc/toplev.c:337
0xc90cf6 arm_reload_in_hi(rtx_def**)
/home/kugan/work/sources/gcc-fsf/trunk/gcc/config/arm/arm.c:15279
0xd025cc gen_reload_inhi(rtx_def*, rtx_def*, rtx_def*)
/home/kugan/work/sources/gcc-fsf/trunk/gcc/config/arm/arm.md:6346
0x89ca2b insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*) const
/home/kugan/work/sources/gcc-fsf/trunk/gcc/recog.h:309
0x89ca2b check_and_process_move
/home/kugan/work/sources/gcc-fsf/trunk/gcc/lra-constraints.c:1163
0x89ca2b curr_insn_transform
/home/kugan/work/sources/gcc-fsf/trunk/gcc/lra-constraints.c:3270
0x89d5ac lra_constraints(bool)
/home/kugan/work/sources/gcc-fsf/trunk/gcc/lra-constraints.c:4200
0x88a59f lra(_IO_FILE*)
/home/kugan/work/sources/gcc-fsf/trunk/gcc/lra.c:2189
0x848da6 do_reload
/home/kugan/work/sources/gcc-fsf/trunk/gcc/ira.c:5306
0x848da6 execute
/home/kugan/work/sources/gcc-fsf/trunk/gcc/ira.c:5465
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/kugan/work/builds/gcc-fsf-trunk/tools/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/kugan/work/builds/gcc-fsf-trunk/tools/libexec/gcc/arm-none-linux-gnueabi/5.0.0/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with: /home/kugan/work/sources/gcc-fsf/trunk/configure
--target=arm-none-linux-gnueabi
--prefix=/home/kugan/work/builds/gcc-fsf-trunk/tools
--with-sysroot=/home/kugan/work/builds/gcc-fsf-trunk/sysroot-arm-none-linux-gnueabi
--disable-libssp --disable-libgomp --disable-libmudflap --disable-libatomic
--disable-libquadmath --without-libquadmath --enable-languages=c
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-thumb
Thread model: posix
gcc version 5.0.0 20140820 (experimental) (GCC)

[Bug target/62254] gcc-4.9 miscompiles linux kernel zlib for armv3

[kugan at gcc dot gnu.org]

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

--- Comment #1 from kugan at gcc dot gnu.org ---
Imported from LP https://bugs.launchpad.net/gcc-linaro/+bug/1307197

[Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-25
 Ever confirmed|0   |1

--- Comment #2 from Andreas Krebbel  ---
The bash crash comes from using a miscompiled libgcc_s.so during gcc build.
There are "la r15,0(r15)" instructions everywhere in the code used for
decrementing the stack pointer where 0 is wrongly used as displacement. This in
turn is the result of being compiled by a miscompiled cc1plus. The following
negation of  the frame size value in s390_emit_prologue function is wrongly
split by the negdi2_31 splitter.

...
  if (cfun_frame_layout.frame_size > 0)
{
  rtx frame_off = GEN_INT (-cfun_frame_layout.frame_size);
...

[Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
(In reply to jgreenhalgh from comment #1)
> I'm happy to take a look at this, but I have no access to an s390 ESA mode
> environment, so will struggle to make much progress.
> 
> If it is the case that s390 relies on PUSH_ARGS_REVERSED == 0, then r209897
> will need to be reverted as it is clearly erroneous.

s390 indeed uses PUSH_ARGS_REVERSED == 0 but the code correctness does not
actually depend on this since every argument has a dedicated slot either in a
register or a stack slot.  In the case described above your patch just revealed
a backend problem:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02313.html

On the other hand I think the asm code looks more obvious on S/390 with
PUSH_ARGS_REVERSED=0 since the operands then are assigned in the expected
order. There is simply no reason for doing it the other way around on S/390.
While I don't have a strong opinion about this I would prefer to go back to the
old behavior.

Also there seem to be other code (gimplify.c) which still depends on
PUSH_ARGS_REVERSED?!

I'm also not sure about the performance impact of this. On S/390 the generated
code changes a lot with your patch.

> 
> Otherwise, any reduced testcase you can find where we do the wrong thing
> preparing stack arguments will be of great help hunting the bug.

[Bug c/62024] __atomic_always_lock_free is not a constant expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #7 from Marek Polacek  ---
I posted a patch.  Let's see what happens.

[Bug plugins/62252] a callback to event PLUGIN_FINISH_TYPE segfaults

[klemen.jan.enova at gmail dot com]

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

--- Comment #5 from klemen.jan.enova at gmail dot com ---
The build passed make check, but I said invoke_plugin_callback() should be
before cp_parser_set_decl_spec_type(), so I will try that way too.

[Bug other/62210] download_prerequisites does not download into current directory

[richard_sharman at mitel dot com]

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

--- Comment #2 from Richard Sharman  ---
wget was installed by Centos 6.5.  I did a yum reinstall [it installed ersion
1.12-1.11.el6_5] but when I ran it it still created the directory structure.

[Bug c++/62129] [4.9/5 Regression] internal compiler error: in output_constant, at varasm.c:4755

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Aug 25 13:13:41 2014
New Revision: 214424

URL: https://gcc.gnu.org/viewcvs?rev=214424&root=gcc&view=rev
Log:
PR c++/62129
* class.c (outermost_open_class): New.
* cp-tree.h: Declare it.
* decl.c (maybe_register_incomplete_var): Use it.
(complete_vars): Handle any constant variable.
* expr.c (cplus_expand_constant): Handle CONSTRUCTOR.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrmem3.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/class.c
branches/gcc-4_9-branch/gcc/cp/cp-tree.h
branches/gcc-4_9-branch/gcc/cp/decl.c
branches/gcc-4_9-branch/gcc/cp/expr.c

[Bug c++/62255] New: Introducing an unrelated template parameter causes failed compilation

[m at maxgerlach dot de]

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

Bug ID: 62255
   Summary: Introducing an unrelated template parameter causes
failed compilation
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m at maxgerlach dot de

Created attachment 33393
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33393&action=edit
Archive containing output.txt, arma_template_test.ii and
arma_no_template_test.ii

Adding a template parameter to a class causes compilation to fail, even though
no further use of this parameter is made.


This problem shows up by using any recent release of the Armadillo C++ library
(header only, http://arma.sourceforge.net/) with gcc 4.8.2 (my system) and
4.8.3 (another system).  On g++ 4.6.3, the Intel compiler 13.1 or clang 3.4 the
problem does not appear.

This is the version information from my system:

$ g++ --version
g++ (Ubuntu 4.8.2-19ubuntu1) 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.



1) Failing compilation 

command line: g++ -c arma_template_test.cpp -Wall -Wextra -std=c++11
-save-temps &> output.txt

Please see attached error messages in output.txt and attached prepocessed file
arma_template_test.ii.  The error messages in output.txt are also repeated
directly in this bug report below.

Code arma_template_test.cpp:

#include 
#include 

template
class Test {
public:
void compute() {
arma::mat matrix = arma::randu(10,10);
matrix = matrix + matrix.t();

arma::vec eigval;
arma::mat eigvec;
arma::eig_sym(eigval, eigvec, matrix);
arma::mat exp_matrix = eigvec * arma::diagmat(arma::exp(eigval)) *
arma::trans(eigvec);

exp_matrix.print(std::cout);
}
};

int main() {
Test<1> test;
test.compute();

return 0;  
}



2) Successful compilation without warnings

command line: g++ -c arma_no_template_test.cpp -Wall -Wextra -std=c++11
-save-temps

Please see attached prepocessed file arma_no_template_test.ii

Code arma_no_template_test.cpp:
#include 
#include 

class Test {
public:
void compute() {
arma::mat matrix = arma::randu(10,10);
matrix = matrix + matrix.t();

arma::vec eigval;
arma::mat eigvec;
arma::eig_sym(eigval, eigvec, matrix);
arma::mat exp_matrix = eigvec * arma::diagmat(arma::exp(eigval)) *
arma::trans(eigvec);

exp_matrix.print(std::cout);
}
};

int main() {
Test test;
test.compute();

return 0;  
}




3) Error messages for failing compilation (output.txt):

In file included from /usr/include/armadillo:105:0,
 from arma_template_test.cpp:1:
/usr/include/armadillo_bits/traits.hpp: In instantiation of ‘const bool
arma::is_Mat_fixed, arma::eop_exp> >::value’:
/usr/include/armadillo_bits/diagmat_proxy.hpp:415:7:   required from ‘class
arma::diagmat_proxy_check, arma::eop_exp> >’
/usr/include/armadillo_bits/glue_times_meat.hpp:851:44:   required from ‘static
void arma::glue_times_diag::apply(arma::Mat&, const
arma::Glue&) [with T1 = arma::Mat; T2 =
arma::Op, arma::eop_exp>, arma::op_diagmat>;
typename T1::elem_type = double]’
/usr/include/armadillo_bits/Mat_meat.hpp:4377:28:   required from
‘arma::Mat::Mat(const arma::Glue&) [with T1 =
arma::Mat; T2 = arma::Op, arma::eop_exp>,
arma::op_diagmat>; glue_type = arma::glue_times_diag; eT = double]’
/usr/include/armadillo_bits/glue_times_meat.hpp:82:25:   required from ‘static
void arma::glue_times_redirect2_helper::apply(arma::Mat&, const arma::Glue&) [with T1 =
arma::Glue, arma::Op,
arma::eop_exp>, arma::op_diagmat>, arma::glue_times_diag>; T2 =
arma::Op, arma::op_htrans>; typename T1::elem_type = double]’
/usr/include/armadillo_bits/glue_times_meat.hpp:318:81:   required from ‘static
void arma::glue_times_redirect<2u>::apply(arma::Mat&,
const arma::Glue&) [with T1 =
arma::Glue, arma::Op,
arma::eop_exp>, arma::op_diagmat>, arma::glue_times_diag>; T2 =
arma::Op, arma::op_htrans>; typename T1::elem_type = double]’
/usr/include/armadillo_bits/glue_times_meat.hpp:412:43:   required from ‘static
void arma::glue_times::apply(arma::Mat&, const
arma::Glue&) [with T1 = arma::Glue,
arma::Op, arma::eop_exp>, arma::op_diagmat>,
arma::glue_times_diag>; T2 = arma::Op, arma::op_htrans>;
typename T1::elem_type = double]’
/usr/include/armadillo_bits/Mat_meat.hpp:4377:28:   required from
‘arma::Mat::Mat(const arma::Glue&) [with T1 =
arma::Glue, arma::Op,
arma::eop_exp>, arma::op_diagmat>, arma::glue_times_diag>; T2 =
arma::Op, arma::op_htrans>; glue_type = arma::glue_times; eT
= double]’
arma_template_test.cpp:14:94:   required from ‘void Test::compute()
[with int param = 1]’
arma_template_test.cpp:22:18:   requir

[Bug c++/62255] Introducing an unrelated template parameter causes compilation to fail

[conradsand.arma at gmail dot com]

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

Conrad  changed:

   What|Removed |Added

 CC||conradsand.arma at gmail dot 
com

--- Comment #1 from Conrad  ---
Confirmed on g++ 4.8.3, Fedora 20, 64 bit.
gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)

[Bug c++/62255] Introducing an unrelated template parameter causes compilation to fail

[conradsand.arma at gmail dot com]

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

--- Comment #2 from Conrad  ---
When the irrelevant template parameter is used (arma_template_test.ii), g++
thinks that "value" in the following code can't be determined at compile time:

template
struct is_Col_fixed_only
  {
  typedef char yes[1];
  typedef char no[2];

  template static yes& check(typename X::Col_fixed_type*);
  template   static no&  check(...);

  static const bool value = ( sizeof(check(0)) == sizeof(yes) );
  };

[Bug c/62141] [GCC-4.10.0][ASAN] ICE: Segmentation fault: 11

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
I don't have an access to a darwin box, so I can't even try to reproduce it.

[Bug c++/62256] New: /usr/include/c++/4.8/tr1/random.tcc:792:2: error: no matching function for call to 'min'

[wangn at ca dot ibm.com]

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

Bug ID: 62256
   Summary: /usr/include/c++/4.8/tr1/random.tcc:792:2: error: no
matching function for call to 'min'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangn at ca dot ibm.com

use g++ to compile perennial test case TR19768/P95252.scenario fails. seems
related to header file.

source code:
$ cat t.cpp
#include 

typedef std::tr1::xor_combine< std::tr1::subtract_with_carry, 8, std::tr1::subtract_with_carry, 2 > type01;

/**/
int main(void)
{
type01 cl01;
return 0;
}


how to reproduce:

g++ -c t.cpp

actual output:

In file included from /usr/include/c++/4.8/tr1/random:48:0,
 from t.cpp:1:
/usr/include/c++/4.8/tr1/random.tcc: In instantiation of âvoid
std::tr1::xor_combine<_UniformRandomNumberGenerator1, __s1,
_UniformRandomNumberGenerator2, __s2>::_M_initialize_max() [with
_UniformRandomNumberGenerator1 = std::tr1::subtract_with_carry; int __s1 = 8; _UniformRandomNumberGenerator2 =
std::tr1::subtract_with_carry; int __s2 = 2]â:
/usr/include/c++/4.8/tr1/random.h:1324:27:   required from
âstd::tr1::xor_combine<_UniformRandomNumberGenerator1, __s1,
_UniformRandomNumberGenerator2, __s2>::xor_combine() [with
_UniformRandomNumberGenerator1 = std::tr1::subtract_with_carry; int __s1 = 8; _UniformRandomNumberGenerator2 =
std::tr1::subtract_with_carry; int __s2 = 2]â
t.cpp:8:12:   required from here
/usr/include/c++/4.8/tr1/random.tcc:793:58: error: no matching function for
call to âmin(std::tr1::xor_combine, 8, std::tr1::subtract_with_carry,
2>::result_type, int)â
__detail::_Shift::__value - 1);
  ^
/usr/include/c++/4.8/tr1/random.tcc:793:58: note: candidates are:
In file included from /usr/include/c++/4.8/bits/char_traits.h:39:0,
 from /usr/include/c++/4.8/string:40,
 from /usr/include/c++/4.8/tr1/random:38,
 from t.cpp:1:
/usr/include/c++/4.8/bits/stl_algobase.h:193:5: note: template const
_Tp& std::min(const _Tp&, const _Tp&)
 min(const _Tp& __a, const _Tp& __b)
 ^
/usr/include/c++/4.8/bits/stl_algobase.h:193:5: note:   template argument
deduction/substitution failed:
In file included from /usr/include/c++/4.8/tr1/random:48:0,
 from t.cpp:1:
/usr/include/c++/4.8/tr1/random.tcc:793:58: note:   deduced conflicting types
for parameter âconst _Tpâ (âshort intâ and âintâ)
__detail::_Shift::__value - 1);
  ^
In file included from /usr/include/c++/4.8/bits/char_traits.h:39:0,
 from /usr/include/c++/4.8/string:40,
 from /usr/include/c++/4.8/tr1/random:38,
 from t.cpp:1:
/usr/include/c++/4.8/bits/stl_algobase.h:239:5: note: template const _Tp& std::min(const _Tp&, const _Tp&, _Compare)
 min(const _Tp& __a, const _Tp& __b, _Compare __comp)
 ^
/usr/include/c++/4.8/bits/stl_algobase.h:239:5: note:   template argument
deduction/substitution failed:
In file included from /usr/include/c++/4.8/tr1/random:48:0,
 from t.cpp:1:
/usr/include/c++/4.8/tr1/random.tcc:793:58: note:   deduced conflicting types
for parameter âconst _Tpâ (âshort intâ and âintâ)
__detail::_Shift::__value - 1);
  ^
/usr/include/c++/4.8/tr1/random.tcc:797:58: error: no matching function for
call to âmin(std::tr1::xor_combine, 8, std::tr1::subtract_with_carry,
2>::result_type, int)â
__detail::_Shift::__value - 1);
  ^
/usr/include/c++/4.8/tr1/random.tcc:797:58: note: candidates are:
In file included from /usr/include/c++/4.8/bits/char_traits.h:39:0,
 from /usr/include/c++/4.8/string:40,
 from /usr/include/c++/4.8/tr1/random:38,
 from t.cpp:1:
/usr/include/c++/4.8/bits/stl_algobase.h:193:5: note: template const
_Tp& std::min(const _Tp&, const _Tp&)
 min(const _Tp& __a, const _Tp& __b)
 ^
/usr/include/c++/4.8/bits/stl_algobase.h:193:5: note:   template argument
deduction/substitution failed:
In file included from /usr/include/c++/4.8/tr1/random:48:0,
 from t.cpp:1:
/usr/include/c++/4.8/tr1/random.tcc:797:58: note:   deduced conflicting types
for parameter âconst _Tpâ (âshort intâ and âintâ)
__detail::_Shift::__value - 1);
  ^
In file included from /usr/include/c++/4.8/bits/char_traits.h:39:0,
 from /usr/include/c++/4.8/string:40,
 from /usr/include/c++/4.8/tr1/random:38,
 from t.cpp:1:
/usr/include/c++/4.8/bits/stl_algobase.h:239:5: note: te

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[jrtc27 at jrtc27 dot com]

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

--- Comment #25 from James Clarke  ---
(In reply to Dominyk Tiller from comment #24)
> It looks like gcc are gonna require someone to submit this patch to their
> mailing list before we see any further activity on this. Could you possibly
> do that? Would massively appreciate it. More details are here:
> https://gcc.gnu.org/contribute.html

Working on it now. Need to clean it up, separate the diffs, add relevant test
cases and check it all still compiles and passes the tests before submitting
though. And of course doing a full bootstrap (a required test) takes quite a
while. Will post an update when I've submitted the patches.

[Bug target/61974] error: ‘ASM_WEAKEN_DECL’ was not declared in this scope

[jbg...@lug-owl.de]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

 CC||jbg...@lug-owl.de

--- Comment #1 from Jan-Benedict Glaw  ---
Though with some warnings with a non-100% recent compiler, my build robot
builds it every now and then:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I.
-I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/.
-I/home/jbglaw/repos/gcc/gcc/../include
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o rs6000.o -MT rs6000.o -MMD
-MP -MF ./.deps/rs6000.TPo /home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c: In function ‘tree_node*
rs6000_handle_longcall_attribute(tree_node**, tree_node*, tree_node*, int,
bool*)’:
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c:28517: warning: unknown
conversion type character ‘E’ in format
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c:28517: warning: too many
arguments for format
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c: In function ‘tree_node*
rs6000_handle_struct_attribute(tree_node**, tree_node*, tree_node*, int,
bool*)’:
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c:28590: warning: unknown
conversion type character ‘E’ in format
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c:28590: warning: too many
arguments for format
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c:28600: warning: unknown
conversion type character ‘E’ in format
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.c:28600: warning: too many
arguments for format


(This is a build started at 2014-08-25 14:56 UTC, cf.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=346652). Maybe
that was only a temporary hiccup?

[Bug c++/62257] New: issue with tr1/functional header

[wangn at ca dot ibm.com]

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

Bug ID: 62257
   Summary: issue with tr1/functional header
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangn at ca dot ibm.com

some of perennial test cases failed because problem on tr1/functional header
file. 

source file:
$ cat t.cpp
#include 
struct T { typedef int result_type; };

std::tr1::result_of::type a;

how to reproduce:

g++ -c t.cpp

actual output:

t.cpp:4:1: error: âtypeâ in âclass std::tr1::result_ofâ does not name a type
 std::tr1::result_of::type a;
 ^
expected output:

compile clean

[Bug libstdc++/62258] New: uncaught_exception() equals to `true' after rethrow_exception()

[dprokoptsev at gmail dot com]

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

Bug ID: 62258
   Summary: uncaught_exception() equals to `true' after
rethrow_exception()
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dprokoptsev at gmail dot com

After using std::rethrow_exception() (and catching the exception), all
subsequent calls to std::uncaught_exception() return `true', which is obviously
not the way it was meant to work.

A simple test case is attached.

[Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()

[dprokoptsev at gmail dot com]

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

--- Comment #1 from Dmitry Prokoptsev  ---
Created attachment 33394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33394&action=edit
A simple test case.

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[jrtc27 at jrtc27 dot com]

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

--- Comment #26 from James Clarke  ---
Patches have been sent to the mailing list -
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02344.html and
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02345.html.

[Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()

[dprokoptsev at gmail dot com]

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

--- Comment #2 from Dmitry Prokoptsev  ---
Created attachment 33395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33395&action=edit
Proposed patch

I believe the problem is that std::rethrow_exception() does not update
`__cxa_eh_globals::uncaughtExceptions' (which remains zero), while
__cxa_begin_catch() decrements it to -1.

A proposed patch is attached.

[Bug c++/62257] issue with tr1/functional header

[wangn at ca dot ibm.com]

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

Nancy Wang  changed:

   What|Removed |Added

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

--- Comment #1 from Nancy Wang  ---
seems result_of must be function type.

[Bug libstdc++/62259] New: atomic class doesn't enforce required alignment on powerpc64

[saugustine at google dot com]

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

Bug ID: 62259
   Summary: atomic class doesn't enforce required alignment on
powerpc64
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saugustine at google dot com

Created attachment 33396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33396&action=edit
small reproducer

The attached short program results in a bus error on powerpc64 top of trunk at
-O0, but I believe is a bug that would be exposed on many targets, going back
at least to 4.9. 

It succeeds--probably by luck--on 4.8.

The key is that the atomic struct is eight-bytes in size, but only four byte
aligned, and gcc takes no care to subsequently align it. GCC chooses an ldarx
instruction, which requires eight-byte alignment.

Although https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy doesn't directly
address this case, a careful reading leads me to believe that this is intended
to work.

My uneducated guess is that the template at :189 should either use
&_M_i in calls to __atomic_is_lock_free (instead of nullptr) or should add
alignment as necessary. Not sure how that is intended to be done. If I fix
 to pass the pointer, then gcc chooses to call out to an atomic library
function, which gcc doesn't provide.

google ref b/17136920

g++ -std=c++11 t.cc -O0

#include 

struct twoints {
int a;
int b;
};

int main() {
  // unalign subsequent variables
  char b0 = 'a';
  twoints one = { 1 };
  twoints two = { 2 };
  std::atomic a(one);
  twoints e = { 0 };

  a.compare_exchange_strong(e, two, std::memory_order_acq_rel);
  return 0;
}

[Bug bootstrap/62260] New: Build inside source tree doesn't work with lto-plugin

[hjl.tools at gmail dot com]

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

Bug ID: 62260
   Summary: Build inside source tree doesn't work with lto-plugin
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

When GCC is configured inside source tree with

./configure --enable-languages=c,c++ --disable-bootstrap

liblto_plugin.la is installed at the wrong place:

ibtool: install: /usr/bin/install -c .libs/liblto_plugin.so.0.0.0
/export/gnu/import/git/gcc/host-x86_64-unknown-linux-gnu/lto-plugin/../host-x86_64-unknown-linux-gnu/gcc/liblto_plugin.so.0.0.0

It should be installed at
/export/gnu/import/git/gcc/host-x86_64-unknown-linux-gnu/lto-plugin/../../host-x86_64-unknown-linux-gnu/gcc/

[Bug c++/62256] /usr/include/c++/4.8/tr1/random.tcc:792:2: error: no matching function for call to 'min'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug bootstrap/62260] Build inside source tree doesn't work with lto-plugin

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-25
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02356.html

[Bug target/62261] New: [sh64] ICE for negative shift counts

[kkojima at gcc dot gnu.org]

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

Bug ID: 62261
   Summary: [sh64] ICE for negative shift counts
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
CC: dhowells at redhat dot com, olegendo at gcc dot gnu.org
Target: sh64-*

This was reported originally by dhowells at #c7 of PR62111.

void foo (unsigned long long x)
{
  bar (x << -1);
}

causes an error: unrecognizable insn:

(insn 7 6 8 2 (set (reg:DI 160 [ D.1442 ])
(ashift:DI (reg:DI 161)
(const_int -1 [0x]))) xx.c:3 -1
 (nil))

A possible patch is proposed at #c14 of PR62111.

[Bug target/62111] ICE when building Linux kernel for sh64

[kkojima at gcc dot gnu.org]

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

--- Comment #17 from Kazumoto Kojima  ---
I've filed a new PR62261 for the issue in #c7.

[Bug target/62262] New: aarch64 gcc generates invalid assembler

[carrot at google dot com]

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

Bug ID: 62262
   Summary: aarch64 gcc generates invalid assembler
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carrot at google dot com
Target: aarch64

Compile following source code with options -fprofile-use -O2


static inline int CLZ(int mask) {
   return mask ? __builtin_clz(mask) : 32;
}

int foo(int value)
{
if (value == 0)
return 0;

int bias = CLZ(value);
value >>= bias;
int zeros = CLZ(value << 1);
value <<= zeros;

int packed = (unsigned)(value << 9) >> 9;
return packed;
}

Without any actual profiling data, trunk gcc generates

/tmp/cctLq1F0.s: Assembler messages:
/tmp/cctLq1F0.s:20: Error: immediate value out of range 0 to 31 at operand 3 --
`ubfiz w0,w2,32,23'

The generated assembler code is:

foo:
cbzw0, .L4
clzw1, w0
asrw2, w0, w1
addsw0, w2, w2
beq.L3
clzw3, w0
lslw4, w2, w3
andw0, w4, 8388607
ret
.L3:
ubfizw0, w2, 32, 23   // Wrong code
ret
.L4:
movw0, 0
ret

4.9 gcc generates the same error.

[Bug middle-end/62263] New: Good codegen for bitwise rotate requires code that is technically undefined behavior

[oneill+gccbugs at cs dot hmc.edu]

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

Bug ID: 62263
   Summary: Good codegen for bitwise rotate requires code that is
technically undefined behavior
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oneill+gccbugs at cs dot hmc.edu

LLVM lacks an intrinsic for performing bitwise rotation, relying instead on
spotting the classic C idioms for specifying rotation using two shifts. 
Unfortunately, when the rotation is defined by variable, its ability to spot
rotation code is poor.

Code that supports a variable rotation also needs to handle rotation-by-zero,
which the underlying instruction has no problem with, but when translated into
the classic C idiom, results in an undefined shift (because shifting a 32-bit
integer by 32 bits isn't allowed).

In the following code, only rotate32_undefined1, rotate32_undefined2 and
_rotl32_doubleand1 compiles to a simple rotate instruction.   rotl32_zerocheck
also compiles to a rotate, but it contains a redundant test for zero -- a test
that is necessary in the C code but not necessary for the rotate.

Somewhat annoyingly, Clang 3.5 also has poor rotation detection, and only
detects it for rotl_doubleand2 and rotl_doubleand3, as well as
rotl32_undefined2.  It is filed as http://llvm.org/bugs/show_bug.cgi?id=20750

Thus GCC and Clang differ as to which code they want for a rotate, and neither
is good at recognizing variations of the rotate idiom.

--- C code ---

unsigned int rotl32_undefined1(unsigned int v, unsigned char r)
{
r = r & 31;
return (v << r) | (v >> (32 - r));
}

unsigned int rotl32_undefined2(unsigned int v, unsigned char r)
{
return (v << (r & 31)) | (v >> (32 - (r & 31)));
}

unsigned int rotl32_zerocheck(unsigned int v, unsigned char r)
{
r = r & 31;
return r ? (v << r) | (v >> (32 - r)) : v;
}

unsigned int rotl32_doubleand1(unsigned int v, unsigned char r)
{
r = r & 31;
return (v << r) | (v >> ((32 - r) & 31));
}

unsigned int rotl32_doubleand2(unsigned int v, unsigned char r)
{
return (v << (r & 31)) | (v >> ((32 - (r & 31)) & 31));
}

unsigned int rotl32_doubleand3(unsigned int v, unsigned char r)
{
return (v << (r & 31)) | (v >> ((32 - r) & 31));
}

--- Assembly output, gcc 4.9.0 -O3 -fomit-frame-pointer ---

_rotl32_undefined1:
LFB0:
movl%esi, %ecx
movl%edi, %eax
andl$31, %ecx
roll%cl, %eax
ret
LFE0:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDE0:
.text
LHOTE0:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDB1:
.text
LHOTB1:
.align 4,0x90
.globl _rotl32_undefined2
_rotl32_undefined2:
LFB1:
movl%esi, %ecx
movl%edi, %eax
andl$31, %ecx
roll%cl, %eax
ret
LFE1:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDE1:
.text
LHOTE1:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDB2:
.text
LHOTB2:
.align 4,0x90
.globl _rotl32_zerocheck
_rotl32_zerocheck:
LFB2:
movl%esi, %ecx
movl%edi, %eax
andl$31, %ecx
roll%cl, %eax
testb%cl, %cl
cmove%edi, %eax
ret
LFE2:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDE2:
.text
LHOTE2:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDB3:
.text
LHOTB3:
.align 4,0x90
.globl _rotl32_doubleand1
_rotl32_doubleand1:
LFB3:
movl%esi, %ecx
movl%edi, %eax
andl$31, %ecx
roll%cl, %eax
ret
LFE3:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDE3:
.text
LHOTE3:
.section __TEXT,__text_cold,regular,pure_instructions
LCOLDB4:
.text
LHOTB4:
.align 4,0x90
.globl _rotl32_doubleand2
_rotl32_doubleand2:
LFB4:
movl%esi, %ecx
movl%edi, %eax
negl%ecx
shrl%cl, %eax
movl%esi, %ecx
andl$31, %ecx
sall%cl, %edi
orl%edi, %eax
ret

[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior

[oneill+gccbugs at cs dot hmc.edu]

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

--- Comment #1 from M.E. O'Neill  ---
Possibly this should have been filed as a tree-level bug?  Also, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886 which mostly is about issues
with wider types, but may also cover this bug.

[Bug target/62262] aarch64 gcc generates invalid assembler

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-26
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
(insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
(and:SI (ashift:SI (reg/v:SI 74 [ value ])
(const_int 32 [0x20]))
(const_int 8388607 [0x7f]))) t7.c:13 611 {*andim_ashiftsi_bfiz}
 (expr_list:REG_DEAD (reg/v:SI 74 [ value ])
(nil)))

Confirmed.

  "exact_log2 ((INTVAL (operands[3]) >> INTVAL (operands[2])) + 1) >= 0
   && (INTVAL (operands[3]) & ((1 << INTVAL (operands[2])) - 1)) == 0"


In fact we invoke undefined behavior inside the compiler too due to the shift
there.

[Bug target/62262] aarch64 gcc generates invalid assembler

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> (insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
> (and:SI (ashift:SI (reg/v:SI 74 [ value ])
> (const_int 32 [0x20]))
> (const_int 8388607 [0x7f]))) t7.c:13 611
> {*andim_ashiftsi_bfiz}
>  (expr_list:REG_DEAD (reg/v:SI 74 [ value ])
> (nil)))
> 
> Confirmed.
> 
>   "exact_log2 ((INTVAL (operands[3]) >> INTVAL (operands[2])) + 1) >= 0
>&& (INTVAL (operands[3]) & ((1 << INTVAL (operands[2])) - 1)) == 0"
> 
> 
> In fact we invoke undefined behavior inside the compiler too due to the
> shift there.

Since it's undefined code, how should we handle it in GCC?  Should we give
warning messages as accurate as possible?  But that sounds impractical either,
since "value << 1" and "value <<= zeros" could be undefined too.

[Bug target/62262] aarch64 gcc generates invalid assembler

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to amker from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > (insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
> > (and:SI (ashift:SI (reg/v:SI 74 [ value ])
> > (const_int 32 [0x20]))
> > (const_int 8388607 [0x7f]))) t7.c:13 611
> > {*andim_ashiftsi_bfiz}
> >  (expr_list:REG_DEAD (reg/v:SI 74 [ value ])
> > (nil)))
> > 
> > Confirmed.
> > 
> >   "exact_log2 ((INTVAL (operands[3]) >> INTVAL (operands[2])) + 1) >= 0
> >&& (INTVAL (operands[3]) & ((1 << INTVAL (operands[2])) - 1)) == 0"
> > 
> > 
> > In fact we invoke undefined behavior inside the compiler too due to the
> > shift there.
> 
> Since it's undefined code, how should we handle it in GCC?  Should we give
> warning messages as accurate as possible?  But that sounds impractical
> either, since "value << 1" and "value <<= zeros" could be undefined too.

Look at how other targets handle cases like this they reject patterns like
this. I can fix this but not until next week.

[Bug c++/62129] [4.9/5 Regression] internal compiler error: in output_constant, at varasm.c:4755

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jason Merrill  ---
Fixed for 4.9.2.

[Bug target/62262] aarch64 gcc generates invalid assembler

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
> (In reply to amker from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > (insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
> > > (and:SI (ashift:SI (reg/v:SI 74 [ value ])
> > > (const_int 32 [0x20]))
> > > (const_int 8388607 [0x7f]))) t7.c:13 611
> > > {*andim_ashiftsi_bfiz}
> > >  (expr_list:REG_DEAD (reg/v:SI 74 [ value ])
> > > (nil)))
> > > 
> > > Confirmed.
> > > 
> > >   "exact_log2 ((INTVAL (operands[3]) >> INTVAL (operands[2])) + 1) >= 0
> > >&& (INTVAL (operands[3]) & ((1 << INTVAL (operands[2])) - 1)) == 0"
> > > 
> > > 
> > > In fact we invoke undefined behavior inside the compiler too due to the
> > > shift there.
> > 
> > Since it's undefined code, how should we handle it in GCC?  Should we give
> > warning messages as accurate as possible?  But that sounds impractical
> > either, since "value << 1" and "value <<= zeros" could be undefined too.
> 
> Look at how other targets handle cases like this they reject patterns like
> this. I can fix this but not until next week.

Thanks very much for explaining.

[Bug target/61360] [5 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4

[Ganesh.Gopalasubramanian at amd dot com]

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

--- Comment #9 from GGanesh  ---
Patch that fixes this issue has been submitted 
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02179.html

The idea is to prohibit changes to the "enabled" attribute during lra and
reload pass.