[Bug rtl-optimization/68182] [6 Regression] ICE in reorder_basic_blocks_simple building libitm/beginend.cc

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-02
 CC||trippels at gcc dot gnu.org
Summary|ICE in  |[6 Regression] ICE in
   |reorder_basic_blocks_simple |reorder_basic_blocks_simple
   |building libitm/beginend.cc |building libitm/beginend.cc
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
 % echo "void htm_begin() { __builtin_ia32_xbegin(); }" | g++ -x c++ -mrtm -O
-c -
: In function ‘void htm_begin()’:
:1:45: internal compiler error: in operator[], at vec.h:714

[Bug c++/68180] New: [ICE] at cp/constexpr.c:2768 in initializing __vector in a loop

[vincenzo.innocente at cern dot ch]

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

Bug ID: 68180
   Summary: [ICE]  at cp/constexpr.c:2768 in initializing __vector
in a loop
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

typedef float __attribute__( ( vector_size( 16 ) ) ) float32x4_t;
constexpr float32x4_t fill(float x) {
  float32x4_t v{0};
  constexpr auto vs = sizeof(v)/sizeof(v[0]);
  for (auto i=0U; i

[Bug rtl-optimization/68182] ICE in reorder_basic_blocks_simple building libitm/beginend.cc

[alalaw01 at gcc dot gnu.org]

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

--- Comment #1 from alalaw01 at gcc dot gnu.org ---
Created attachment 36636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36636=edit
Preprocessed source (compressed)

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[EngyCZ at gmail dot com]

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

--- Comment #5 from Jiří Engelthaler  ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Jiří Engelthaler from comment #3)
> > (In reply to Manuel López-Ibáñez from comment #2)
> > > What does -### show for the call to cc1 ? My commit r228094 to 
> > > opts-common.c
> > > should have fixed this.
> > 
> > $ gcc -fdiagnostics-color=never a.c -###
> > cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a -o
> > /tmp/cclEySGP.s
> 
> To be honest, I don't have any clue why this is happening. This output seems
> to happen before calling any code in opts-common.c as a result of the specs.
> But why the specs will be touching -fdiagnostics-color=? I don't know much
> about how the specs work.
> 
> If reverting the patch fixes the problem, please go ahead and just reopen
> the bug fixed by it.

I have tested GCC with reverted r228094 and there is not problem reported by
this bug.
I'm asking someone with rights to reopen the bug 67640 and link it to this one.

[Bug rtl-optimization/68182] New: ICE in reorder_basic_blocks_simple building libitm/beginend.cc

[alalaw01 at gcc dot gnu.org]

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

Bug ID: 68182
   Summary: ICE in reorder_basic_blocks_simple building
libitm/beginend.cc
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64
Target: x86_64

Preprocessed source attached; command-line

$ /work/alalaw01/build/./gcc/xg++ -B/work/alalaw01/build/./gcc/ -mrtm -O1 -g
-m32 -c temp.ii
/work/alalaw01/src/gcc/libitm/beginend.cc: In static member function ‘static
uint32_t GTM::gtm_thread::begin_transaction(uint32_t, const gtm_jmpbuf*)’:
/work/alalaw01/src/gcc/libitm/beginend.cc:400:1: internal compiler error: in
operator[], at vec.h:714
 }
 ^
0x1310783 vec::operator[](unsigned int)
/work/alalaw01/src/gcc/gcc/vec.h:714
0x1310783 reorder_basic_blocks_simple
/work/alalaw01/src/gcc/gcc/bb-reorder.c:2322
0x1310783 reorder_basic_blocks
/work/alalaw01/src/gcc/gcc/bb-reorder.c:2450
0x1310783 execute
/work/alalaw01/src/gcc/gcc/bb-reorder.c:2551

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[EngyCZ at gmail dot com]

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

--- Comment #3 from Jiří Engelthaler  ---
(In reply to Manuel López-Ibáñez from comment #2)
> What does -### show for the call to cc1 ? My commit r228094 to opts-common.c
> should have fixed this.

$ gcc -fdiagnostics-color=never a.c -###
cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a -o
/tmp/cclEySGP.s

---

$ gcc -### -fdiagnostics-color=never a.c
cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a
"-fdiagnostics-color=never" -o /tmp/ccSOGrIR.s

---

$ gcc a.c -fdiagnostics-color=never -###
cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a
"-fdiagnostics-color=never" -o /tmp/ccR4q0g6.s

---

$ gcc -### a.c -fdiagnostics-color=never
cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a
"-fdiagnostics-color=never" -o /tmp/ccc7zgdo.s

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Jambor  ---
OK, so hopefully finally fixed everywhere.

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jiří Engelthaler from comment #3)
> (In reply to Manuel López-Ibáñez from comment #2)
> > What does -### show for the call to cc1 ? My commit r228094 to opts-common.c
> > should have fixed this.
> 
> $ gcc -fdiagnostics-color=never a.c -###
> cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a -o
> /tmp/cclEySGP.s

To be honest, I don't have any clue why this is happening. This output seems to
happen before calling any code in opts-common.c as a result of the specs. But
why the specs will be touching -fdiagnostics-color=? I don't know much about
how the specs work.

If reverting the patch fixes the problem, please go ahead and just reopen the
bug fixed by it.

[Bug driver/68181] New: djgpp: minor linker invocation issues

[felix.von.s at posteo dot de]

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

Bug ID: 68181
   Summary: djgpp: minor linker invocation issues
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.von.s at posteo dot de
  Target Milestone: ---

Created attachment 36635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36635=edit
gcc/config/i386/djgpp.h patch (5.2.0)

0. The gcc frontend unconditionally instructs the linker to use a script
provided by the djgpp libraries package. It contains a few LONG(0) directives
which seem to be needed by the CRT to have some variables/memory regions
properly initialised. I'd like that it be possible to disable that linker
script. (Why? To make GRUB modules buildable with the djgpp compiler the same
way they're buildable on mingw: by building them as COFF files and then
converting them to ELF.)

1. GNU ld has been able to directly output go32 .exe files for quite some time
(before even the repository was converted to git, it seems). Therefore calling
the stubify utility is unnecessary. (However, ld names the output file a.out by
default, which confuses autoconf, so it should be passed -o a.exe unless -o was
given to gcc). Removing this dependency will simplify things a bit. (On the
other hand, the loader stub used by binutils is a bit outdated; it comes from
the 2.02 release of djgpp.)

Both issues can be resolved with the attached trivial patch. The -T option is
not passed to the linker when -nostdlib is passed to gcc (maybe -nodefaultlibs
should also do it; or maybe -dT should be passed to the linker instead). I
think that ultimately it's the djgpp CRT that ought to be fixed, but I'm not
sure how. In the meantime, this should do.

[Bug ada/68183] New: Using Serial communication stream lose packets somtimes, file OK

[nicklas.karlsson17 at gmail dot com]

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

Bug ID: 68183
   Summary: Using Serial communication stream lose packets
somtimes, file OK
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicklas.karlsson17 at gmail dot com
  Target Milestone: ---

Gnat.Serial_Communications.Write(File, D); file work OK.

File : aliased Serial_Port;
  Stream : access Ada.Streams.Root_Stream_Type :=
Ada.Streams.Root_Stream_Type(File)'Access;

Byte'Write(Stream, Byte(n)); sometimes lose packets.


Usinge write function in serial communication package work OK. But then using
the root class and the 'Write(...) function sometimes loses bytes, it does not
seems to totally random instead a byte seems be losed after a few bytes with
some randomness up or down.

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker  ---
FYI a workaround for this and similar bugs, for users who are unable to upgrade
once it's fixed, is to always use -ffunction-sections -fdata-sections. This
inhibits the assembler's "optimization" differences between symbols simply
because cross-section differences are never constant.

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Author: jamborm
Date: Mon Nov  2 14:04:19 2015
New Revision: 229666

URL: https://gcc.gnu.org/viewcvs?rev=229666=gcc=rev
Log:
2015-11-02  Martin Jambor  

PR tree-optimization/67794
* tree-sra.c (replace_removed_params_ssa_names): Do not distinguish
between types of statements but accept original definitions as a
parameter.
(ipa_sra_modify_function_body): Use FOR_EACH_SSA_DEF_OPERAND to
iterate over definitions.

testsuite/
* gcc.dg/ipa/ipa-sra-10.c: New test.
* gcc.dg/torture/pr67794.c: Likewise.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/ipa/ipa-sra-10.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr67794.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-sra.c

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #7)
> This is because check_effective_target_arm_vfp3_ok only checks whether a
> *compilation* with -mfloat-abi=soffp works, and does not check that a link
> actually works.

Following some discussion on gcc-patches I've moved the test to
gcc.c-torture/execute

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[bugdal at aerifal dot cx]

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

--- Comment #11 from Rich Felker  ---
FYI a workaround for this and similar bugs, for users who are unable to
upgrade, is to always use -ffunction-sections -fdata-sections. This inhibits
the assembler's "optimization" differences between symbols simply because
cross-section differences are never constant.

[Bug libstdc++/67922] std::unordered_map::clear should take time linear in the number of elements

[yegor.derevenets at gmail dot com]

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

--- Comment #3 from Yegor Derevenets  ---
A small correction. A colleague of mine bothered to read the source code of
libc++ and noticed that its implementation of clear() method also generally
takes time, linear in the number of buckets. This was not visible in the tests
I already presented, because libc++ has special handling of the empty container
case:

template 
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::clear() _NOEXCEPT
{
if (size() > 0)
{
__deallocate(__p1_.first().__next_);
__p1_.first().__next_ = nullptr;
size_type __bc = bucket_count();
for (size_type __i = 0; __i < __bc; ++__i)
__bucket_list_[__i] = nullptr;
size() = 0;
}
}

If we modify the test example slightly, we get:

$ cat test_clear.cpp
#include 

int main() {
std::unordered_map m;
for (int i = 0; i < 100; ++i) {
m[i] = i;
}
for (int i = 0; i < 1000; ++i) {
m[i] = i;
m.clear();
}
}

$ clang++-3.7 -O2 -std=c++11 -stdlib=libstdc++ test_clear.cpp && time ./a.out

real0m4.054s
user0m4.000s
sys 0m0.036s

$ clang++-3.7 -O2 -std=c++11 -stdlib=libc++ test_clear.cpp && time ./a.out

real0m6.114s
user0m6.000s
sys 0m0.036s

$ cat test_erase.cpp
#include 

int main() {
std::unordered_map m;
for (int i = 0; i < 100; ++i) {
m[i] = i;
}
for (int i = 0; i < 1000; ++i) {
m[i] = i;
m.erase(m.begin(), m.end());
}
}

$ clang++-3.7 -O2 -std=c++11 -stdlib=libstdc++ test_erase.cpp && time ./a.out

real0m0.151s
user0m0.116s
sys 0m0.036s

$ clang++-3.7 -O2 -std=c++11 -stdlib=libc++ test_erase.cpp && time ./a.out

real0m0.187s
user0m0.156s
sys 0m0.028s

I find it strange that both libraries implement clear() less efficiently than
erase(m.begin(), m.end()). Maybe there is a rationale for this which I do not
understand?

[Bug c/68187] New: Poor error message from -Wmisleading-indentation on glibc's ../stdlib/strtol_l.c

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 68187
   Summary: Poor error message from -Wmisleading-indentation on
glibc's ../stdlib/strtol_l.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Building glibc (a9224562cbe9cfb0bd8d9e637a06141141f9e6e3) on x86_64, with gcc
r229364 patched to add -Wmisleading-indentation added to -Wall:

../stdlib/strtol_l.c: In function ‘strtoul_l_internal’:
../stdlib/strtol_l.c:356:9: error: statement is indented as if it were guarded
by... [-Werror=misleading-indentation]
 cnt < thousands_len; })
 ^
../stdlib/strtol_l.c:353:9: note: ...this ‘for’ clause, but it is not
   && ({ for (cnt = 0; cnt < thousands_len; ++cnt)
 ^

The code is question looks like this:

   348for (c = *end; c != L_('\0'); c = *++end)
   349  if (((STRING_TYPE) c < L_('0') || (STRING_TYPE) c >
L_('9'))
   350  # ifdef USE_WIDE_CHAR
   351  && (wchar_t) c != thousands
   352  # else
   353  && ({ for (cnt = 0; cnt < thousands_len; ++cnt)
   354if (thousands[cnt] != end[cnt])
   355  break;
   356cnt < thousands_len; })
   357  # endif
   358  && (!ISALPHA (c)
   359  || (int) (TOUPPER (c) - L_('A') + 10) >= base))
   360break;


It looks like lines 354 and 355 are poorly indented, leading to the warning
from -Wmisleading-indentation at line 356.

It could be argued that the warning is reasonable here, though I don't like the
wording of our warning here: line 356 isn't indented as if guarded by line 353,
it's more that lines 354 and 355 *aren't* indented.

Specifically:

(gdb) call inform (guard_tinfo.location, "guard_tinfo")
../stdlib/strtol_l.c:353:9: note: guard_tinfo
   && ({ for (cnt = 0; cnt < thousands_len; ++cnt)
 ^

(gdb) call inform (body_tinfo.location, "body_tinfo")
../stdlib/strtol_l.c:354:9: note: body_tinfo
 if (thousands[cnt] != end[cnt])
 ^
(gdb) call inform (next_tinfo.location, "next_tinfo")
../stdlib/strtol_l.c:356:9: note: next_tinfo
 cnt < thousands_len; })
 ^

(gdb) p guard_exploc
$11 = {file = 0x1dd40a0 "../stdlib/strtol_l.c", line = 353, column = 9, data =
0x0, sysp = false}
(gdb) p body_exploc
$12 = {file = 0x1dd40a0 "../stdlib/strtol_l.c", line = 354, column = 9, data =
0x0, sysp = false}
(gdb) p next_stmt_exploc
$13 = {file = 0x1dd40a0 "../stdlib/strtol_l.c", line = 356, column = 9, data =
0x0, sysp = false}

(gdb) p guard_vis_column
$14 = 22
(gdb) p body_vis_column 
$15 = 22
(gdb) p next_stmt_vis_column 
$16 = 22

(gdb) p body_type
$17 = CPP_KEYWORD

I believe it's entering this clause:

  /* Don't warn if they are aligned on the same column
 as the guard itself (suggesting autogenerated code that doesn't
 bother indenting at all).  We consider the column of the first


but:

(gdb) p guard_line_first_nws 
$18 = 16
(gdb) p body_vis_column 
$19 = 22

due to the "&& ({ " before the "for" on line 353 and hence it fails the tests,
and reaches:

  /* Otherwise, they are visually aligned: issue a warning.  */
  return true;

[Bug tree-optimization/68189] New: wrong code at -Os and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 68189
   Summary: wrong code at -Os and above on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk mis-compiles the following code on x86_64-linux-gnu at
-Os and above in the 64-bit mode (and at -Os in the 32-bit mode). 

It also affects 4.9.x and later releases, making it a regression from 4.8.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151101 (experimental) [trunk revision 229639] (GCC) 
$ 
$ gcc-trunk -O1 small.c; ./a.out
$ gcc-4.8.4 -Os small.c; ./a.out
$  
$ gcc-trunk -Os small.c  
$ ./a.out
Aborted (core dumped)
$ 


-


int printf (const char *, ...); 

int a, e, f, j;
char c, d = 1;

int
main ()
{
  char g;
  c = 1;
  for (; c >= 0; c--)
{
  e = d;
  for (;;)
{
  if (!a)
break;
  if (j)
printf ("%d", 0);
}
  if (c < 2)
g = c;
  f = g;
  d = 0;
}

  if (e != 0) 
__builtin_abort (); 

  return 0;
}

[Bug c++/68188] New: Ambiguous code gets compiled successfully when class and its namespace have the same name

[ppilar11 at gmail dot com]

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

Bug ID: 68188
   Summary: Ambiguous code gets compiled successfully when class
and its namespace have the same name
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppilar11 at gmail dot com
  Target Milestone: ---

I reported this nearly 2 years ago (#60025), but my bug report was completely
ignored and the problem still persists.

Consider the following code:

namespace Foo
{
int x;

class Foo
{
public:
static int x;
};

int Foo::x;
}

int main()
{
   using namespace Foo;
   Foo::x;
   return 0;
} 

g++ 5.2.0 accepts it even though Foo::x is ambiguous: it could be either a
global variable in namespace Foo or a static member of class Foo. Visual C++
2013 rejects the code with "error C2872: 'Foo' : ambiguous symbol could be
'Foo' or 'Foo::Foo'" while g++ simply resolves Foo::x to the global variable x,
so it apparently fails to find the static member of class Foo. The problem has
been present since at least g++ 4.7.2.

Maybe I'm wrong, but I think there's one more problem with the above code.
If I comment out the global variable x from namespace definition then 
compilation fails with the following error:

"error: 'x' is not a member of 'Foo'"

so g++ fails to find the static member of class Foo unless I qualify it as
Foo::Foo::x which should not be necessary due to "using" directive, am I right?

[Bug libstdc++/68190] New: iterator mix up with set::find and heterogenous lookup

[howard.hinnant at gmail dot com]

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

Bug ID: 68190
   Summary: iterator mix up with set::find and heterogenous lookup
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howard.hinnant at gmail dot com
  Target Milestone: ---

This fails to compile because template  set::find is returning the
wrong iterator type (I think).

#include 

struct Comparator
{
using is_transparent = std::true_type;

bool
operator() (int x, unsigned y) const
{
return x < y;
}


bool
operator() (unsigned x, int y) const
{
return x < y;
}


bool
operator() (int x, int y) const
{
return x < y;
}

};

int
main()
{
std::set s;
s.insert(1);
auto iter = s.find(1u);
iter = s.erase(iter);
}

[Bug c++/68195] New: gcc//ld produces invalid ABI results (cxx11 problem?)

[matthias at goldhoorn dot eu]

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

Bug ID: 68195
   Summary: gcc//ld produces invalid ABI results (cxx11 problem?)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthias at goldhoorn dot eu
  Target Milestone: ---

I already asked on the ML but don't get a reply. I assume my problem is a GCC
bug therefore...

I have created a really simple test-setup which causes a crash of my
component before the execution of main().
The crash happens during dynamic lib loading time.

I have a Library A compiled without -std=c++11  and a executable B with
-std=c++11.
From my understanding the newly introduced ABI compatibility should
prevent the linking if some ABI inconsistencies exist.
I using a fresh ubuntu15.10 in a VirtualBox.
The only thing that the lib does is include a boost header.

The minimal example which failed can be found here:

https://github.com/goldhoorn/sandbox/tree/gcc5.2-issue

The produced binary cannot be started if -O2 is given or the libs are a mixture
between c++11 and regular ones. The clang compiler works normally. GCC versions
before 5.2 work too.

Additional Information:
question on stackoverflow:
http://stackoverflow.com/questions/33475069/gcc5-2-abi-change-compatibility-guaranteed?noredirect=1#comment54740240_33475069

[Bug target/67657] [SH][5/6 Regression]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #17 from John Paul Adrian Glaubitz  ---
I have scheduled a rebuild of libjpeg-turbo now. The package is now waiting for
the next free buildd. Please have a look at the package log here [1] once any
of the buildds has made a build attempt.

Adrian

> [1] https://buildd.debian.org/status/package.php?p=libjpeg-turbo=sid

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #23 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #22)
> I think we can close this as fixed.

Yes, I can confirm libraw now builds fine. Full build log available at [1].

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libraw=sh4=0.17.0-1=1445047219

[Bug libstdc++/68190] iterator mix up with set::find and heterogenous lookup

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
See: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103

[Bug target/68191] New: s390x Linux Split Stacks support

[dje at gcc dot gnu.org]

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

Bug ID: 68191
   Summary: s390x Linux Split Stacks support
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

Enable and implement split-stack support for s390x Linux such that GCC
Testsuite passes with -fsplit-stack option enabled.

[Bug libstdc++/68190] iterator mix up with set::find and heterogenous lookup

[howard.hinnant at gmail dot com]

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

--- Comment #2 from Howard Hinnant  ---
LWG 103 isn't the issue.

http://melpon.org/wandbox/permlink/MzOWaFpvFRtgaa7t

C::iterator is   std::_Rb_tree_const_iterator
C::const_iterator is std::_Rb_tree_const_iterator
C::find(1u) returns  std::_Rb_tree_iterator

s.erase returns a std::_Rb_tree_const_iterator which can not be converted
into a std::_Rb_tree_iterator.

If C::find(1u) returned a C::iterator (as specified in 23.4.6.1) instead of a
std::_Rb_tree_iterator, this bug would be fixed.

[Bug target/68192] AIX libstdc++ TLS symbols not exported

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-02
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

Libtool export_symbols_cmds needs to add "L" to list of recognized symbol
types.

[Bug libstdc++/68190] iterator mix up with set::find and heterogenous lookup

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
(In reply to Markus Trippelsdorf from comment #1)

Markus, could you please elaborate on your reference to LWG 103? At the moment
I see no relation to the code example. With acceptance of

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3657.htm

support for heterogeneous comparison had been added. But this still requires as
of Table 101 — Associative container requirements that

a.find(k)

and

a_tran.find(ke)

return the very same type set<>::iterator for a non-constant set object and the
expression

a.erase(q)

also shall have type set<>::iterator return type. The only option, that LWG 103
allows is that for a given implementation set<>::iterator and
set<>::const_iterator *could* be of the same type, but that is not the problem
here.

There is a different way to point out the problem here by replacing the last
code line containing the erase expression

iter = s.erase(iter);

by the following two lines:

auto iter2 = s.find(1);
static_assert(std::is_same::value, "");

This static assertion fails and just demonstrates that

a.find(k)

and 

a_tran.find(ke)

do have different return types.

[Bug target/68192] AIX libstdc++ TLS symbols not exported

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix*
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |5.3

[Bug target/68192] New: AIX libstdc++ TLS symbols not exported

[dje at gcc dot gnu.org]

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

Bug ID: 68192
   Summary: AIX libstdc++ TLS symbols not exported
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

Libtool does not recognize TLS symbols designated by "L" in AIX nm command
output and does not add them to the export list.

[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
Hmm, the build now failed due to "out of memory" apparently [1]:

[  7%] Building CXX object
libs/network/src/CMakeFiles/cppnetlib-uri.dir/uri/uri.cpp.o
cd /<>/cpp-netlib-0.11.2+dfsg1/obj-sh4-linux-gnu/libs/network/src &&
/usr/bin/c++   -DBOOST_NETWORK_ENABLE_HTTPS -DBOOST_TEST_DYN_LINK
-Dcppnetlib_uri_EXPORTS -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2  -Wall -fPIC
-I/<>/cpp-netlib-0.11.2+dfsg1-o
CMakeFiles/cppnetlib-uri.dir/uri/uri.cpp.o -c
/<>/cpp-netlib-0.11.2+dfsg1/libs/network/src/uri/uri.cpp
virtual memory exhausted: Cannot allocate memory

Any ideas?

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=cpp-netlib=sh4=0.11.2%2Bdfsg1-2=1446307196

[Bug tree-optimization/68189] wrong code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-02
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r217827.

[Bug rtl-optimization/68194] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 68194
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O2
and -O3 in both 32-bit and 64-bit modes. 

This is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151101 (experimental) [trunk revision 229639] (GCC) 
$ 
$ gcc-trunk -Os small.c; ./a.out
0
$ gcc-5.2 -O2 small.c; ./a.out
0
$ 
$ gcc-trunk -O2 small.c
$ ./a.out
-16
$ 





int printf (const char *, ...); 

int a, c, d, e, g, h;
short f;

short
fn1 () 
{
  int j[2];
  for (; e; e++)
if (j[0])
  for (;;)
;
  if (!g)
return f;
}

int
main ()
{
  for (; a < 1; a++)
{
  for (c = 0; c < 2; c++)
{ 
  d && (f = 0); 
  h = fn1 (); 
}
  printf ("%d\n", (char) f);   
   }

 return 0;
}

[Bug c++/68184] New: Exception from a virtual function does not get caught

[philodej at gmail dot com]

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

Bug ID: 68184
   Summary: Exception from a virtual function does not get caught
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philodej at gmail dot com
  Target Milestone: ---

Hi!
The following code terminates on g++ 5.2.1, 4.9.3 and 4.8.4:

namespace {
struct IFoo { virtual void foo() = 0; };
struct IBar { virtual void bar() = 0; };

struct FooBar : private IBar, private IFoo
{
void call_foo()
{
try
{
static_cast(this)->foo();
}
catch( ... ) {}
}
void foo() { throw 1; }
void bar()  {}
};

void test()
{
FooBar foobar;
foobar.call_foo();
}
}
int main()
{
test();
return 0;
}

when compiled with O3 optimization
  g++ -O3 -Wall -Wextra -pedantic main.cpp && ./a.out
with following error:
  terminate called after throwing an instance of 'int'

For the example see:
  http://coliru.stacked-crooked.com/a/2bab7c03ff7c870b

It seems that __cxa_begin_catch, __cxa_end_catch calls do not get generated:

(anonymous namespace)::FooBar::bar():
rep ret
(anonymous namespace)::FooBar::foo():
movl$4, %edi
subq$8, %rsp
call__cxa_allocate_exception
xorl%edx, %edx
movl$1, (%rax)
movltypeinfo for int, %esi
movq%rax, %rdi
call__cxa_throw
non-virtual thunk to (anonymous namespace)::FooBar::foo():
subq$8, %rdi
jmp .LTHUNK0
main:
subq$24, %rsp
leaq8(%rsp), %rdi
movqvtable for (anonymous namespace)::FooBar+16, (%rsp)
movqvtable for (anonymous namespace)::FooBar+48, 8(%rsp)
callnon-virtual thunk to (anonymous namespace)::FooBar::foo()
xorl%eax, %eax
addq$24, %rsp
ret

When I comment-out the IBar::bar() interface method, call the foo() method
without static cast, use an older compiler (<= 4.6.4), or do some other code
experiments then everything works as expected: 

  - terminate:   http://goo.gl/jcgPn6
  - single virtual function: http://goo.gl/cayyoO
  - no static cast:  http://goo.gl/i9N4pD
  - O1 + noinline:   http://goo.gl/PYazij
  - g++ 4.6.4:   http://goo.gl/uWQ6aU

Thanks in advance.

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Richard Earnshaw  ---
This is an assembler bug and it only affects ARM state (thumb2 is OK).

In Thumb2 code we get:

 :
   0:   4770bx  lr
   2:   bf00nop

0004 :
   4:   4801ldr r0, [pc, #4]; (c )
   6:   4478add r0, pc
   8:   4770bx  lr
   a:   bf00nop
   c:   0002.word   0x0002
c: R_ARM_REL32  foo

While in ARM code we get:

 :
   0:   e12fff1ebx  lr

0004 :
   4:   e59f0004ldr r0, [pc, #4]; 10 
   8:   e08fadd r0, pc, r0
   c:   e12fff1ebx  lr
  10:   fff0.word   0xfff0
(no relocation generated).


even though the assembly output is equivalent.

(resolving as invalid because this isn't a GCC problem but a GAS problem).

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Jiří Engelthaler from comment #5)
> I have tested GCC with reverted r228094 and there is not problem reported by
> this bug.
> I'm asking someone with rights to reopen the bug 67640 and link it to this
> one.

I think the bug should be reopened after the patch is reverted.

With the patch reverted, do you still see the behavior reported in the
description of bug 67640?

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[rearnsha at gcc dot gnu.org]

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

--- Comment #6 from Richard Earnshaw  ---
Oh, and another point; since this is a function symbol, not a data symbol, it
can't be subject to a copy relocation at run time, so even protected symbols
should be acceptable here.

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[bugdal at aerifal dot cx]

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

--- Comment #7 from Rich Felker  ---
I agree that the PC-relative relocation in the literal pool is acceptable and
what the compiler should be doing. However, the form of the expression the
compiler puts in the assembly output does not actually generate a relocation;
instead it generates a 'fixup' that the assembler resolves before generating
the output object file.

I claim it's wrong for the assembler to do this, but Alan Modra claims it's
right in comment 8 on binutils bug 18561. I believe a variant of Nick Clifton's
patch (from comment 6) that applies to all targets should be applied,
eliminating consideration of the 'strict' option to S_FORCE_RELOC for weak
definitions since this 'optimization' is always wrong for weak defs. Possibly
the whole 'strict' argument should be removed; the other cases where it's used
may be wrong too.

[Bug tree-optimization/68185] New: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 68185
   Summary: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in the 64-bit mode (but not in the 32-bit mode). 

This is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151101 (experimental) [trunk revision 229639] (GCC) 
$ 
$ gcc-trunk -m64 -O2 small.c; ./a.out
$ gcc-trunk -m32 -O3 small.c; ./a.out
$ gcc-5.2 -m64 -O3 small.c; ./a.out
$ 
$ gcc-trunk -m64 -O3 small.c
$ ./a.out
Aborted (core dumped)
$ 


---


int a, b, d = 1, e, f, o, u, w = 1, z;
short c, q, t; 

int
main ()
{
  char g;
  for (; d; d--)
{
  while (o)
for (; e;)
  {
c = b;
int h = o = z;
for (; u;)
  for (; a;)
;
  }
  if (t < 1)
g = w;
  f = g;
  g && (q = 1);
}

  if (q != 1) 
__builtin_abort (); 

  return 0;
}

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[bugdal at aerifal dot cx]

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

--- Comment #4 from Rich Felker  ---
Well the binutils side seems to think it's a GCC bug to generate relative
address expressions like this; at least that's the response I got when I
reported it for sh. See the binutils bug linked in the original report above:

https://sourceware.org/bugzilla/show_bug.cgi?id=18561

[Bug tree-optimization/68185] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-02
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|wrong code at -O3 on|[6 Regression] wrong code
   |x86_64-linux-gnu (in 64-bit |at -O3 on x86_64-linux-gnu
   |mode)   |(in 64-bit mode)
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r223113.

[Bug c++/68186] New: Using public base member function privately prevents derived classes using base member function

[jwyatt at feralinteractive dot com]

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

Bug ID: 68186
   Summary: Using public base member function privately prevents
derived classes using base member function
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwyatt at feralinteractive dot com
  Target Milestone: ---

Created attachment 36637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36637=edit
Minimal example

The following setup (compiled with g++ -Wall -Wextra) causes the error:

‘int Base::Method()’ is inaccessible

within the Derived2 context. This doesn't happen if the using statement within
the class Derived is removed, or if it is made public.

class Base
{
public:
int Method();
};

class Derived : public Base
{
using Base::Method;
};

class Derived2 : public Derived
{
using Base::Method;
};

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
This particular case is a very specific situation.

A definition of foo is guaranteed to exist (you've provided one); but it can be
overridden.

The definition (due to the use of hidden) has to exist in this share library.

Given the above, we can never get to the situation where the symbol could
resolve to null, nor could we ever get to the situation where the offset to the
definition can't be calculated when linking the shared library.  That makes it
perfectly reasonable to use a pc-relative relocation from within the literal
pool to hold the offset.

It's quite possible that with a subtle change to the conditions you could end
up requiring the compiler to generate another code sequence, but not in this
case.

[Bug libstdc++/68190] iterator mix up with set::find and heterogenous lookup

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
710 { return _M_t._M_find_tr(__x); }

[Bug libstdc++/68190] iterator mix up with set::find and heterogenous lookup

[nikb at bougalis dot net]

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

--- Comment #6 from Nik Bougalis  ---
I don't follow why an auto return is used, instead of simply
iterator/const_iterator which is the required return value per the
documentation I've read.

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

[sje at gcc dot gnu.org]

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

--- Comment #6 from Steve Ellcey  ---
Author: sje
Date: Mon Nov  2 21:04:33 2015
New Revision: 229677

URL: https://gcc.gnu.org/viewcvs?rev=229677=gcc=rev
Log:
2015-11-02  Steve Ellcey  

Backport from mainline
2015-10-23  Steve Ellcey  
Andrew Pinski  

PR rtl-optimization/67736
* combine.c (simplify_comparison): Use gen_lowpart_or_truncate instead
of gen_lowpart.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/combine.c

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||pault at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #8 from Dominique d'Humieres  ---
Revision r229621 changes the wrong code to an ICE

[Book15] f90/bug% /opt/gcc/gcc6p-229621p2/bin/gfortran pr67779.f90
pr67779.f90:76:0:

 allocate( v,   source = array(1) )
1
internal compiler error: in gfc_advance_chain, at fortran/trans.c:61

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

[sje at gcc dot gnu.org]

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

--- Comment #7 from Steve Ellcey  ---
Author: sje
Date: Mon Nov  2 21:08:02 2015
New Revision: 229678

URL: https://gcc.gnu.org/viewcvs?rev=229678=gcc=rev
Log:
2015-11-02  Steve Ellcey  

2015-10-23  Steve Ellcey  
Andrew Pinski  

PR rtl-optimization/67736
* gcc.dg/torture/pr67736.c: New test.
* gcc.dg/combine-subregs.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/combine-subregs.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr67736.c
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/68190] iterator mix up with set::find and heterogenous lookup

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-02
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
Started with r219888, which implements N3657.

The bug depends on LWG 103 only insofar as it wouldn't happen
if const_iterator and iterator were different in the set and
multiset case.

The problem is that the auto return type of find doesn't know that 
const_iterator and iterator are the same in this case and returns
std::_Rb_tree_iterator instead of std::_Rb_tree_const_iterator

693   iterator  
694   find(const key_type& __x) 
695   { return _M_t.find(__x); }
696 
697   const_iterator
698   find(const key_type& __x) const   
699   { return _M_t.find(__x); }
700 
701 #if __cplusplus > 201103L   
702   template
703 auto
704 find(const _Kt& __x) -> decltype(_M_t._M_find_tr(__x))  
705 { return _M_t._M_find_tr(__x); }
706 
707   template
708 auto
709 find(const _Kt& __x) const -> decltype(_M_t._M_find_tr(__x))
710 
711 #endif

[Bug c++/68164] Destructor side effect unexpectedly elided

[webrown.cpp at gmail dot com]

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

W E Brown  changed:

   What|Removed |Added

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

--- Comment #4 from W E Brown  ---
(In reply to Casey Carter from comment #3)
...
> The access to bp[i].data in the for loop inside the catch clause is the
> access to which I was referring.
...

Sorry, that hadn't been clear to me from the original response; I'd thought it
was discussing use of the this pointer.

I'm told that the original test program was earlier today adapted to avoid the
reported behavior.  I haven't yet tried the revised version, but am closing
this report.

[Bug ada/68179] New: No warning when specifying a Default_Component_Value on derived type, resulting in unexpected behavior

[gcc at gyw dot com]

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

Bug ID: 68179
   Summary: No warning when specifying a Default_Component_Value
on derived type, resulting in unexpected behavior
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at gyw dot com
  Target Milestone: ---

Created attachment 36634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36634=edit
Sample code to demonstrate dangerous behavior

The 'Default_Component_Value' aspect is not allowed on derived types, yet there
is no warning from the compiler when it is used. The aspect is just silently
ignored.

As it stands, one can declare a type derived from String or another array type,
and specify a 'Default_Component_Value' for it. However, the default value
isn't applied to the components, and there is no warning.

It is inconsistent that one can specify a 'Default_Value' on a derived type,
but not a 'Default_Component_Value' on a derived array type. 

I found a mention that allowing default values for components could be risky
because of potentially different sizes for the components. It isn't clear to me
how this could occur, but the rule is there.

I find that silently ignoring the 'Default_Component_Value' aspect is
potentially dangerous, as the program's behavior thus differs from what is the
intent of the programmer. Subsequent code review is also bound to miss an error
of this nature.

[Bug tree-optimization/68157] [5/6 Regression] internal compiler error: in reassoc_stmt_dominates_stmt_p, at tree-ssa-reassoc.c:1287

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Seems to have started with r217669.

[Bug tree-optimization/68165] Not constant-folding setting vector element

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-02
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  Note that with the existing way of doing this (BIT_FIELD_REF on the
LHS) it's especially hard to get this combined.

Introducing BIT_FIELD_EXPR would help here (google for old patches).  We'd have

  vec_1 = { 0.0, 0.0 };
  vec_2 = BIT_FIELD_EXPR ;
  vec_3 = BIT_FIELD_EXPR ;

which we can easily constant fold.  Of course this would continue the
(ab-)use of BIT_FIELD_* for vectors.  Enhancing VEC_PERM to allow the
2nd input (vector) to be of different size (or scalar) would make

 vec_2 = VEC_PERM 

possible (which is also only ternary instead of quaternary).  Expansion
can go the vec_insert route or fallback to splat + perm_const.

VEC_PERM would become more of the RTL pattern

  (vec_select
 (vec_concat ...) ...)

Modeling element extraction with VEC_PERM would be a bit awkward (you'd
have a stale operand).  So if we end up with a vector extract tree code
(not using BIT_FIELD_EXPR anymore for that) then an explicit vector insert
would make sense as well.

The only reason BIT_FIELD_EXPR isn't in trunk yet is that it has four
operands (a "first" if done properly tuplish, we'd not want it as a 
"single" RHS).  Though the size operand is somewhat redundant if we
require (as for BIT_FIELD_REF) matching bitsize with the operand to insert.

That said, the fix is to fix the representation, not somehow make the
existing one optimized.

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|[4.8/4.9 Regression] all|[4.9/5/6 Regression] all
   |pch tests fail on eglibc|pch tests fail on eglibc
   |systems (with   |systems (with
   |bits/predefs.h) |bits/predefs.h)

--- Comment #2 from Richard Biener  ---
I suppose it doesn't work with GCC 5 or trunk either.

[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.

[y.gribov at samsung dot com]

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

--- Comment #10 from Yury Gribov  ---
> This happens because in LLVM case ASan changes symbols size
> ('f' in our case) and just breaks ABI for the library.

I've filed an upstream bug about this
https://github.com/google/sanitizers/issues/619

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||arm*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  ---
The regression (ICE) is caused by revision r188692 (pr53642). If I apply the
following patch

--- ../_clean/gcc/fortran/trans-expr.c  2015-10-29 17:11:18.0 +0100
+++ gcc/fortran/trans-expr.c2015-11-02 23:44:18.0 +0100
@@ -9288,7 +9354,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1
  otherwise the character length of the result is not known.
  NOTE: This relies on having the exact dependence of the length type
  parameter available to the caller; gfortran saves it in the .mod files. 
*/
-  if (flag_realloc_lhs && expr2->ts.type == BT_CHARACTER &&
expr1->ts.deferred)
+  if (flag_realloc_lhs && expr2->ts.type == BT_CHARACTER && expr1->ts.deferred
&& expr2->expr_type != EXPR_VARIABLE)
 gfc_add_block_to_block (, );

   /* Nullify the allocatable components corresponding to those of the lhs

the ICEs are gone (it does not mean that the generated code is correct!) but
the test

gfortran.dg/deferred_type_param_8.f90

aborts at run time.

[Bug rtl-optimization/68182] [6 Regression] ICE in reorder_basic_blocks_simple building libitm/beginend.cc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Mine.  And Markus wins the prize for "most reduced testcase" ;-)

[Bug c/68193] New: _Generic -Woverflow false alarm

[eggert at gnu dot org]

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

Bug ID: 68193
   Summary: _Generic -Woverflow false alarm
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

I ran into this problem when developing Gnulib code.  This is with GCC 5.2.0 on
x86-64.  Compile the following program t.c with 'gcc -Wall t.c':

int
main (void)
{
  int i = 0;
  int j = _Generic (i,
int: 0,
long int: (i = (long int) 9223372036854775808UL));
  return i + j;
}

GCC generates the bogus warning:

t.c: In function 'main':
t.c:7:22: warning: overflow in implicit constant conversion [-Woverflow]
   long int: (i = (long int) 9223372036854775808UL));
  ^

The warning is bogus because the corresponding expression is not evaluated, as
per the semantics of _Generic.

Add 1 to that big constant, changing it to 9223372036854775809UL, and the bogus
warning goes away.  So it's possible that there are two bugs here, one having
to do with bogus warnings in unevaluated _Generic subexpressions, the other
having to do with (unsigned long) LONG_MIN.

[Bug ipa/68175] g++ 5.2.1 produces broken executables with devirtualization enabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Richard Biener  ---
Dup.

*** This bug has been marked as a duplicate of bug 67056 ***

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Honza, can you work on this please?  It blocks backporting the devirt
wrong-code fix.

[Bug ipa/67056] [5 regression] Wrong code generated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||bnagaev at gmail dot com

--- Comment #19 from Richard Biener  ---
*** Bug 68175 has been marked as a duplicate of this bug. ***

[Bug c/68173] gcc does not terminate with -O0 on source file with a very large expression

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
I wonder what difference

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 229574)
+++ gcc/gimplify.c  (working copy)
@@ -499,7 +499,7 @@ lookup_tmp_var (tree val, bool is_formal
  block, which means it will go into memory, causing much extra
  work in reload and final and poorer code generation, outweighing
  the extra memory allocation here.  */
-  if (!optimize || !is_formal || TREE_SIDE_EFFECTS (val))
+  if (!is_formal || TREE_SIDE_EFFECTS (val))
 ret = create_tmp_from_val (val);
   else
 {

makes to this (at -O0).  The comment is clearly very outdated but
generated code quality at -O0 might still be worse?

[Bug target/68172] [6 Regression] LTO/PGO bootstrapped compiler is miscompiled (looping in sched_rgn_init)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug rtl-optimization/68173] gcc does not terminate with -O0 on source file with a very large expression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
 CC||vmakarov at gcc dot gnu.org
  Component|c   |rtl-optimization

--- Comment #6 from Richard Biener  ---
Btw, peak memory occurs during RA (as expected, DF ...).

p x_rtl.emit.x_reg_rtx_no
$3 = 5328459

that's a lot of pseudos (at -O0 probably still all used).  The BB is also
very large thus peak occurs within BB-local DF routines like
df_lr_bb_local_compute (which also end up very slow).

The suggested patch has no effect on the above number.

[Bug ada/68179] No warning when specifying a Default_Component_Value on derived type, resulting in unexpected behavior

[gcc at gyw dot com]

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

--- Comment #1 from Troy  ---
Command line to build sample code:

gnatmake -gnat12 -gnatE -gnatf -gnatn -gnato -gnatX -gnatwa -gnatVa ada2012bug2

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
From the dup:

Confirmed.  Note that with the existing way of doing this (BIT_FIELD_REF on the
LHS) it's especially hard to get this combined.

Introducing BIT_FIELD_EXPR would help here (google for old patches).  We'd have

  vec_1 = { 0.0, 0.0 };
  vec_2 = BIT_FIELD_EXPR ;
  vec_3 = BIT_FIELD_EXPR ;

which we can easily constant fold.  Of course this would continue the
(ab-)use of BIT_FIELD_* for vectors.  Enhancing VEC_PERM to allow the
2nd input (vector) to be of different size (or scalar) would make

 vec_2 = VEC_PERM 

possible (which is also only ternary instead of quaternary).  Expansion
can go the vec_insert route or fallback to splat + perm_const.

VEC_PERM would become more of the RTL pattern

  (vec_select
 (vec_concat ...) ...)

Modeling element extraction with VEC_PERM would be a bit awkward (you'd
have a stale operand).  So if we end up with a vector extract tree code
(not using BIT_FIELD_EXPR anymore for that) then an explicit vector insert
would make sense as well.

The only reason BIT_FIELD_EXPR isn't in trunk yet is that it has four
operands (a "first" if done properly tuplish, we'd not want it as a 
"single" RHS).  Though the size operand is somewhat redundant if we
require (as for BIT_FIELD_REF) matching bitsize with the operand to insert.

That said, the fix is to fix the representation, not somehow make the
existing one optimized.

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Marc Glisse from comment #4)
> #include 
> __m128d f(){
>   __m128d r;
>   r[0]=1;
>   r[1]=2;
>   return r;
> }
> 
> Currently, SLP vectorizes it with -fvect-cost-model=unlimited, but not by
> default because:
> 
>   Vector inside of basic block cost: 1
>   Vector prologue cost: 1
>   Vector epilogue cost: 0
>   Scalar cost of basic block: 2
> r.c:4:9: note: not vectorized: vectorization is not profitable.
> 
> And if r is initialized to {3,4} as in the initial testcase, we don't
> vectorize either:
> 
> r.c:3:17: note: not vectorized: no vectype for stmt: # .MEM_2 = VDEF
> <.MEM_1(D)>
> rD.15637 = { 3.0e+0, 4.0e+0 };
>  scalar_type: __m128dD.4386
> r.c:3:17: note: not vectorized: not enough data-refs in basic block.

If we fix that (trivial) we run into

t.c:3:15: note: === vect_slp_analyze_data_ref_dependences ===
t.c:3:15: note: can't determine dependence between r and BIT_FIELD_REF 

because we end up with a write-write dependence we can't analyze.  Of course
in the end we do not need all dependences but only those for the code motion
we are going to perform.

[Bug ipa/67056] [5 regression] Wrong code generated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2015-08-04 00:00:00 |2015-11-02
 Ever confirmed|0   |1

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #5 from alalaw01 at gcc dot gnu.org ---
*** Bug 68165 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68165] Not constant-folding setting vector element

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Seems like a duplicate of 56118 to me.

*** This bug has been marked as a duplicate of bug 56118 ***

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

--- Comment #24 from Dominique d'Humieres  ---
The test in comment 23 looks like a duplicate of pr50221.

[Bug tree-optimization/68083] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #8 from Alexandre Oliva  ---
Fixed

[Bug tree-optimization/68083] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  ---
Author: aoliva
Date: Tue Nov  3 00:30:07 2015
New Revision: 229690

URL: https://gcc.gnu.org/viewcvs?rev=229690=gcc=rev
Log:
[PR68083] don't introduce undefined behavior in ifcombine

The ifcombine pass may move a conditional access to an uninitialized
value before the condition that ensures it is always well-defined,
thus introducing undefined behavior.  Stop it from doing so.

for  gcc/ChangeLog

PR tree-optimization/68083
* tree-ssa-ifcombine.c: Include tree-ssa.h.
(bb_no_side_effects_p): Test for undefined uses too.
* tree-ssa.c (gimple_uses_undefined_value_p): New.
* tree-ssa.h (gimple_uses_undefined_value_p): Declare.

for  gcc/testsuite/ChangeLog

PR tree-optimization/68083
* gcc.dg/torture/pr68083.c: New.  From Zhendong Su.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr68083.c
Modified:
trunk/ChangeLog
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ifcombine.c
trunk/gcc/tree-ssa.c
trunk/gcc/tree-ssa.h

[Bug rtl-optimization/49429] [4.7 Regression] dse.c change (r175063) causes execution failures

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #19 from Alexandre Oliva  ---
Would you guys with access to the affected platforms please let me know in case
revision 229696, just installed in the trunk, regresses this?

[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva  ---
Would you guys with access to the affected platforms please let me know in case
revision 229696, just installed in the trunk, regresses this?

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

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

--- Comment #3 from Nix  ---
I haven't tested that yet, so I wasn't willing to commit to it. It seems very
likely though.

(I wasn't sure of protocol, or I'd have put you in the Cc list as the author of
the fix for bug 65550, but I was afraid that might seem spammy... glad to see
you spotted the bug going by anyway.)

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov  2 12:23:36 2015
New Revision: 229657

URL: https://gcc.gnu.org/viewcvs?rev=229657=gcc=rev
Log:
Move gcc.target/arm/pr67929_1.c test to execute.exp

PR target/67929
* gcc.target/arm/pr67929_1.c: Move to...
* gcc.c-torture/execute/pr67929_1.c: ... Here.
Remove arm-specific directives.  Add noclone, noinline
attributes.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr67929_1.c
Removed:
trunk/gcc/testsuite/gcc.target/arm/pr67929_1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov  2 12:26:39 2015
New Revision: 229658

URL: https://gcc.gnu.org/viewcvs?rev=229658=gcc=rev
Log:
Move gcc.target/arm/pr67929_1.c test to execute.exp

PR target/67929
* gcc.target/arm/pr67929_1.c: Move to...
* gcc.c-torture/execute/pr67929_1.c: ... Here.
Remove arm-specific directives.  Add noclone, noinline
attributes.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr67929_1.c
Removed:
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr67929_1.c
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov  2 12:29:31 2015
New Revision: 229659

URL: https://gcc.gnu.org/viewcvs?rev=229659=gcc=rev
Log:
Move gcc.target/arm/pr67929_1.c test to execute.exp

PR target/67929
* gcc.target/arm/pr67929_1.c: Move to...
* gcc.c-torture/execute/pr67929_1.c: ... Here.
Remove arm-specific directives.  Add noclone, noinline
attributes.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr67929_1.c
Removed:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr67929_1.c
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog