[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Still present at r206648.

[Bug other/58712] [4.9 Regression] issues found by --enable-checking=valgrind

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Markus Trippelsdorf  ---
All issues are fixed. Closing.

[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
  Known to work||4.6.4
Summary|Wrong outputs with rounding |[4.7/4.8/4.9 Regression]
   |formats for some values.|Wrong outputs with rounding
   ||formats for some values.
 Ever confirmed|0   |1
  Known to fail||4.7.3, 4.8.2, 4.9.0

--- Comment #2 from Dominique d'Humieres  ---
Gfortran 4.6.4 gives the right answer for both codes. So it is a regression.

[Bug c/59801] GCC does not warn on unused global variable

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801

--- Comment #7 from Jakub Jelinek  ---
Those two cases are different, the other PR was about automatic volatile
variables, where if they are unused it is really hard to come up with a way how
they could be modified behind compiler's back.  While for this case, variable
in .data/.bss etc. section it is not so hard, the variable has a name through
which it can be referenced, eventhough only from within the same assembly file.
 User could inject some assembly which will access it, the var can use section
attribute that places it into some magic section that is e.g. IO mapped, etc.

[Bug libstdc++/59830] std::packaged_task throws exception

[b17c0de at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59830

--- Comment #2 from b17c0de at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
>  relies on mutexes and condition variables so you need to compile
> and link with -pthread

Thanks! That was indeed the problem. Whats with the strange error though?

[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775

--- Comment #13 from David Kredba  ---
I have to keep LTO still off for Libreoffice. (And for many of simple programs
that do the test for endian type the way not counting with LTO and for some
that linker is not happy with relocation(s) and a few more different case. But
the main part is fine, icluding qtwebkit-4.8.5 (with only one fine tune in one
header file) which is great!)
I think there is standalone bug for Libreoffice LTO, am I wrong? I can append
the first error seen to it.

[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507

--- Comment #9 from rguenther at suse dot de  ---
On Thu, 16 Jan 2014, hubicka at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
> 
> --- Comment #8 from Jan Hubicka  ---

void arg_tuple_test(const std::pair&) (const struct pair & t)
{
  int (*__vtbl_ptr_type) () * _3;
  int (*__vtbl_ptr_type) () _4;
  const struct A & _6;

  :
  _6 = &t_1(D)->first;
  _3 = MEM[(const struct type *)t_1(D)]._vptr.A;
  _4 = *_3;
  OBJ_TYPE_REF(_4;(const struct A)_6->0) (_6); [tail call]
  return;

}
Here we look all the way to figuring out that the object comes as 
parameter
of
arg_tuple_test and give up on this point.
I think GIMPLE typing rules does not really allow us to take the type from
COMPONENT_REF in statement defining _6, so it seems we completely lose 
track
of
the type info here. (and it indeed looks like a common case)

Richard?

That is correct.  &t_1(D)->first is merely pointer offsetting and
we may not forward it to form t_1(D)->first._vptr.A for example
(there were wrong-code bugs because of such forwarding in the past).

In GIMPLE you don't have type information on pointed to types, you only
have type info for values.

> Hmm, also if there is anything in standard that prevents user to pass 
> object of type A by reference to type B (where A is not derived from B) 
> then we can get the type info from type of parameter t.

"Standards" do not apply to GIMPLE so you have to be very careful
in this area (one reason why I am not exactly comfortable about
all this devirt and ODR stuff done in the middle-end as opposed
to in a frontend).

Richard.

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.7.3
Summary|[Regression] Inconsistent   |[4.8/4.9 Regression]
   |rounding between -m32 and   |Inconsistent rounding
   |-m64|between -m32 and -m64
  Known to fail||4.8.2, 4.9.0

--- Comment #12 from Dominique d'Humieres  ---
The first test in comment 1 gives the same outputs when compiled with 4.8.2 for
-m32/-m64, but not with current trunk (4.9.0). The second test gives the same
output when compiled with 4.7.3 for -m32/-m64, but not with 4.8.2 and current
trunk (4.9.0). So I am marking this PR as a 4.8/4.9 regression.

[Bug fortran/58992] Bogus error "Entity with assumed character length at (1) must be a dummy argument or a PARAMETER" with associate and character string

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58992

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
 Ever confirmed|0   |1
  Known to fail||4.6.4, 4.7.3, 4.8.2, 4.9.0

[Bug target/59839] New: i686 AVX2 gather intrinsic not compiling with -O0

[dejan.crnila at dewesoft dot si]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59839

Bug ID: 59839
   Summary: i686 AVX2 gather intrinsic not compiling with -O0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dejan.crnila at dewesoft dot si

Created attachment 31850
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31850&action=edit
preprocesed source

the following source does

#include 

void test(const float* data)
{
__m256i i = _mm256_set1_epi32(1);
__m256 d = _mm256_i32gather_ps(data, i, 1);
}

does not compile with

gcc -mavx2 -O0 -c test.c

note: it does compile with -O1 or above

error:

test.c: In function 'test':
test.c:7:1: error: unrecognizable insn:
 }
 ^
(insn 28 27 0 2 (parallel [
(set (mem/c:V8SF (plus:SI (reg/f:SI 54 virtual-stack-vars
(const_int -64 [0xffc0])) [0 d+0
(unspec:V8SF [
(reg:V8SF 61 [ D.7004 ])
(mem:SF (unspec:SI [
(reg/f:SI 71)
(reg:V8SI 60 [ D.7005 ])
(const_int 1 [0x1])
] UNSPEC_VSIBADDR) [0 S4 A8])
(mem:BLK (scratch) [0 A8])
(reg:V8SF 59 [ D.7004 ])
] UNSPEC_GATHER))
(clobber (scratch:V8SF))
]) test.c:6 -1
 (nil))
test.c:7:1: internal compiler error: in extract_insn, at recog.c:2150
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


gcc -v:

Using built-in specs.
COLLECT_GCC=c:\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.8.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-4.8.0/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32
--with-sysroot=/t
emp/x32-480-win32-sjlj-r2/mingw32 --enable-shared --enable-static
--enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto
--enable-libstdcxx
-time=yes --enable-threads=win32 --enable-libgomp --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specif
ic-runtime-libs --enable-sjlj-exceptions --disable-isl-version-check
--disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug
--disable-b
ootstrap --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-gnu-as --with-gnu-ld
--with-arch-32=i686 --with-arch-6
4=nocona --with-tune-32=generic --with-tune-64=core2
--with-host-libstdcxx='-static -lstdc++' --with-libiconv --with-system-zlib
--with-gmp=/temp/mingw-prereq/i
686-w64-mingw32-static --with-mpfr=/temp/mingw-prereq/i686-w64-mingw32-static
--with-mpc=/temp/mingw-prereq/i686-w64-mingw32-static
--with-isl=/temp/mingw-prere
q/i686-w64-mingw32-static
--with-cloog=/temp/mingw-prereq/i686-w64-mingw32-static
--enable-cloog-backend=isl --with-pkgversion='rev2, Built by MinGW-builds proj
ect' --with-bugurl=http://sourceforge.net/projects/mingwbuilds/ CFLAGS='-O2
-pipe -I/temp/x32-480-win32-sjlj-r2/libs/include
-I/temp/mingw-prereq/x32-zlib/inclu
de -I/temp/mingw-prereq/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe
-I/temp/x32-480-win32-sjlj-r2/libs/include
-I/temp/mingw-prereq/x32-zlib/include -I
/temp/mingw-prereq/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe
-L/temp/x32-480-win32-sjlj-r2/libs/lib -L/temp/mingw-prereq/x32-zlib/lib
-L/temp/mi
ngw-prereq/i686-w64-mingw32-static/lib
-L/temp/x32-480-win32-sjlj-r2/mingw32/opt/lib'
Thread model: win32
gcc version 4.8.0 (rev2, Built by MinGW-builds project)

[Bug c++/59838] ICE with an enum using an incomplete type

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.7.4
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  Even GCC 4.6 ICEs, g++34 says:
ee.C:1: error: invalid use of undefined type `enum E'
ee.C:1: error: forward declaration of `enum E'
ee.C:1: error: a comma operator cannot appear in a constant-expression
ee.C:1: error: enumerator value for `b' not integer constant

[Bug gcov-profile/58602] .gcno files not truncated at gcov_close

[laurent.alfonsi at st dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602

--- Comment #5 from Laurent Aflonsi  ---
Ping ?
Is this ok for trunk ?

[Bug gcov-profile/58602] .gcno files not truncated at gcov_close

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
Please ping the patch on the gcc-patches mailing list.

[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Markus Trippelsdorf  ---
markus@x4 lto % /var/tmp/gcc_valgrind/usr/local/bin/g++ -fPIC -flto -r
-nostdlib 20081118_0.C 20081118_1.C
==12420== Conditional jump or move depends on uninitialised value(s)
==12420==at 0x535652: lto_balanced_map() (lto-partition.c:705)
==12420==by 0x531B0D: lto_main() (lto.c:3161)
==12420==by 0x8033F5: compile_file() (toplev.c:548)
==12420==by 0x805097: toplev_main(int, char**) (toplev.c:1914)
==12420==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so)
==12420==  Uninitialised value was created by a client request
==12420==at 0x53736B: ggc_internal_alloc_stat(unsigned long)
(ggc-page.c:1339)
==12420==by 0x674E6F: ggc_realloc_stat(void*, unsigned long)
(ggc-common.c:192)
==12420==by 0x6B38B2: inline_summary_alloc() (vec.h:384)
==12420==by 0x6BF365: inline_read_summary() (ipa-inline-analysis.c:3996)
==12420==by 0x767701: ipa_read_summaries_1(opt_pass*) (passes.c:2519)
==12420==by 0x5303A7: lto_main() (lto.c:2963)
==12420==by 0x8033F5: compile_file() (toplev.c:548)
==12420==by 0x805097: toplev_main(int, char**) (toplev.c:1914)
==12420==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so)
==12420== 
==12420== Conditional jump or move depends on uninitialised value(s)
==12420==at 0x535734: lto_balanced_map() (lto-partition.c:726)
==12420==by 0x531B0D: lto_main() (lto.c:3161)
==12420==by 0x8033F5: compile_file() (toplev.c:548)
==12420==by 0x805097: toplev_main(int, char**) (toplev.c:1914)
==12420==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so)
==12420==  Uninitialised value was created by a client request
==12420==at 0x53736B: ggc_internal_alloc_stat(unsigned long)
(ggc-page.c:1339)
==12420==by 0x674E6F: ggc_realloc_stat(void*, unsigned long)
(ggc-common.c:192)
==12420==by 0x6B38B2: inline_summary_alloc() (vec.h:384)
==12420==by 0x6BF365: inline_read_summary() (ipa-inline-analysis.c:3996)
==12420==by 0x767701: ipa_read_summaries_1(opt_pass*) (passes.c:2519)
==12420==by 0x5303A7: lto_main() (lto.c:2963)
==12420==by 0x8033F5: compile_file() (toplev.c:548)
==12420==by 0x805097: toplev_main(int, char**) (toplev.c:1914)
==12420==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so)
==12420==

[Bug middle-end/59827] [4.7/4.8/4.9 Regression] ICE on array with incomplete element type

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59827

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jan 16 11:42:56 2014
New Revision: 206660

URL: http://gcc.gnu.org/viewcvs?rev=206660&root=gcc&view=rev
Log:
PR middle-end/59827
* cgraph.c (gimple_check_call_args): Don't use DECL_ARG_TYPE if
it is error_mark_node.
testsuite/
* gcc.dg/pr59827.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr59827.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543

Markus Trippelsdorf  changed:

   What|Removed |Added

  Attachment #31527|0   |1
is obsolete||

--- Comment #5 from Markus Trippelsdorf  ---
Created attachment 31851
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31851&action=edit
smaller testcase

Here's a smaller testcase, that just needs two input files
(but uniset.ii still needs its gcda file):

markus@x4 lto_pgo_testcase % cat unorm.ii
namespace icu_50 {
class UnicodeString {
 public:
  UnicodeString();
  void extractBetween(int, int, unsigned short *, int = 0) const;
  void doExtract(int, unsigned short *, int) const;
  void pinIndex(int &) const;
};
inline void UnicodeString::extractBetween(int p1, int p2, unsigned short *p3,
  int p4) const {
  pinIndex(p1);
  doExtract(p2 - p1, p3, p4);
}
UnicodeString::UnicodeString() { extractBetween(0, 0, 0); }
UnicodeString a;
}

markus@x4 lto_pgo_testcase % g++ -g -fPIC -flto -fno-exceptions -O2 -std=c++11
-c unorm.ii
markus@x4 lto_pgo_testcase % g++ -w -g -fprofile-use -fPIC -flto
-fno-exceptions -O2 -std=c++11 -c uniset.ii
markus@x4 lto_pgo_testcase % g++ -flto -O2 uniset.o unorm.o
In member function ‘extractBetween’:
lto1: fatal error: Cgraph edge statement index out of range 28 < 46
compilation terminated.

[Bug libstdc++/59830] std::packaged_task throws exception

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59830

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
It should print the error code returned by the underlying pthread_once() call,
which is -1

I don't know why it's printing (unsigned long)-1 instead.

[Bug libstdc++/59712] unordered_map : clang fails with "member access into incomplete type"

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59712

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |4.9.0
   Target Milestone|--- |4.9.0

[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763

--- Comment #18 from Jakub Jelinek  ---
Created attachment 31852
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31852&action=edit
gcc49-pr57763.patch

Untested fix.

So, from what I can understand, the really computed jumps are just fine, the
problem is that on some targets (well, most of them except for a few exceptions
that define HAS_LONG_UNCOND_BRANCH to non-zero)
fix_crossing_unconditional_branches turns the unconditional normal crossing
jumps into indirect jumps.  Those then satisfy computed_jump_p predicate, and
if current function has forced_labels, then make_edge later on wants to see
edges from those jumps to all the forced_labels.
But, while those crossing jumps are indirect jumps, they actually can't jump to
arbitrary labels, they will only jump to the single label they load a few insns
before the indirect jump into register, so there is no point in having edges
from them to all the forced_labels, the insns are indirect just because normal
uncondjumps aren't guaranteed to be able to jump to arbitrary code distances.

Attached is an attempt to fix this just by setting JUMP_LABEL on the indirect
jump, then computed_jump_p predicate will be false and the various places in
RTL optimizers will be told where it jumps to.  Not 100% how adding the
JUMP_LABEL plays with e.g. LABEL_NUSES, should it increment it or not, or do
only LABEL_REFs count for that?  In any case, the patch fixes the bug in the
cross compiler, can't test it on Alpha though, perhaps could test say on ppc64
and s390x which also don't define HAS_LONG_UNCOND_BRANCH to non-zero.  But, our
testsuite coverage for -freorder-blocks-and-partition is very limited anyway.

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[nickc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865

--- Comment #26 from Nick Clifton  ---
Author: nickc
Date: Thu Jan 16 12:17:48 2014
New Revision: 206661

URL: http://gcc.gnu.org/viewcvs?rev=206661&root=gcc&view=rev
Log:
PR middle-end/28865

* varasm.c (output_constant): Return the number of bytes actually
emitted.
(output_constructor_array_range): Update the field size with the
number of bytes emitted by output_constant.
(output_constructor_regular_field): Likewise.  Also do not
 complain if the total number of bytes emitted is now greater
than the expected fieldpos.
* output.h (output_constant): Update prototype and descriptive
comment.

* gcc.c-torture/compile/pr28865.c: New.
* gcc.c-torture/execute/pr28865.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr28865.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr28865.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/output.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug c/57180] Structures with a flexible arrray member have wrong size

[nickc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180

Bug 57180 depends on bug 28865, which changed state.

Bug 28865 Summary: Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865

   What|Removed |Added

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

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[nickc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #27 from Nick Clifton  ---
The patch has now been approved and checked in:

http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00812.html

[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763

--- Comment #19 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #18)

> Attached is an attempt to fix this just by setting JUMP_LABEL on the
> indirect jump, then computed_jump_p predicate will be false and the various
> places in RTL optimizers will be told where it jumps to.  Not 100% how
> adding the JUMP_LABEL plays with e.g. LABEL_NUSES, should it increment it or
> not, or do only LABEL_REFs count for that?  In any case, the patch fixes the
> bug in the cross compiler, can't test it on Alpha though, perhaps could test
> say on ppc64 and s390x which also don't define HAS_LONG_UNCOND_BRANCH to
> non-zero.  But, our testsuite coverage for -freorder-blocks-and-partition is
> very limited anyway.

I have started bootstrap on Alpha.

[Bug c++/59840] New: -Wconversion produces incorrect warning when value is shifted by 0

[rafal at rawicki dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59840

Bug ID: 59840
   Summary: -Wconversion produces incorrect warning when value is
shifted by 0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafal at rawicki dot org

Consider following code:

$ cat foo.cpp 
#include 

uint16_t foo(uint8_t * x)
{
return (uint16_t)(x[0] << 0) | (uint16_t)(x[1] << 8);
}

It generates a false warning when there is a shift by 0 and no warning when
x[0] is shifted by other value:

$ g++ -c -Wconversion -Wall -Wextra foo.cpp 
foo.cpp: In function ‘uint16_t foo(uint8_t*)’:
foo.cpp:5:31: warning: conversion to ‘uint16_t {aka short unsigned int}’ from
‘int’ may alter its value [-Wconversion]
  return (uint16_t)(x[0] << 0) | (uint16_t)(x[1] << 8);

$ g++ --version 
g++ (Ubuntu/Linaro 4.8.2-8) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug middle-end/59841] New: [4.9 Regression] internal compiler error: verify_ssa failed

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59841

Bug ID: 59841
   Summary: [4.9 Regression] internal compiler error: verify_ssa
failed
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

On Linux/x86-64, revision 206628 gave

statpt.fppized.f: In function 'sigx':
statpt.fppized.f:5269:0: error: definition in block 210 does not dominate use
in block 552
   SUBROUTINE SIGX(LNR)
 ^
for SSA_NAME: _1225 in statement:
# VUSE <.MEM_2866>
_2767 = MEM[(double[0:D.10235] *)_1087][_1225];
statpt.fppized.f:5269:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [/tmp/ccT1tRiz.ltrans13.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake: *** [gamess] Error 1

when compiling 416.gamess in SPEC CPU 2006 with:

gfortran  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64aldeci.fppized.o algnci.fppized.o
basecp.fppized.o basext.o bashuz.o bashz2.o basn21.fppized.o basn31.o
bassto.fppized.o blas.fppized.o ccaux.o ccsdt.fppized.o chgpen.fppized.o
cisgrd.fppized.o cosmo.fppized.o cphf.fppized.o cpmchf.o cprohf.fppized.o
ddi.fppized.o delocl.fppized.o dft.fppized.o dftaux.fppized.o dftexc.fppized.o
dftfun.o dftgrd.fppized.o dftint.fppized.o dgeev.o dmulti.fppized.o
drc.fppized.o dummygetenv.fppized.o ecp.fppized.o ecpder.fppized.o
ecplib.fppized.o ecppot.o efdrvr.fppized.o efelec.o efgrd2.fppized.o
efgrda.fppized.o efgrdb.fppized.o efgrdc.fppized.o efinp.fppized.o
efinta.fppized.o efintb.fppized.o efpaul.fppized.o efpcm.fppized.o
efpcov.fppized.o eigen.fppized.o eomcc.fppized.o ffield.fppized.o
frfmt.fppized.o fsodci.fppized.o gamess.fppized.o globop.fppized.o
gradex.fppized.o grd1.fppized.o grd2a.fppized.o grd2b.o grd2c.fppized.o
guess.fppized.o gugdga.fppized.o gugdgb.fppized.o gugdm.fppized.o
gugdm2.fppized.o gugdrt.fppized.o gugem.fppized.o gugsrt.fppized.o
gvb.fppized.o hess.fppized.o hss1a.fppized.o hss1b.fppized.o hss2a.fppized.o
hss2b.fppized.o inputa.fppized.o inputb.fppized.o inputc.fppized.o
int1.fppized.o int2a.fppized.o int2b.o iolib.fppized.o lagran.fppized.o
local.fppized.o loccd.fppized.o locpol.fppized.o mccas.fppized.o mcjac.o
mcpinp.fppized.o mcpint.fppized.o mcplib.o mcqdpt.fppized.o mcqdwt.o
mcqud.fppized.o mcscf.fppized.o mctwo.fppized.o morokm.fppized.o mp2.fppized.o
mp2ddi.fppized.o mp2grd.fppized.o mpcdat.o mpcgrd.fppized.o mpcint.fppized.o
mpcmol.fppized.o mpcmsc.fppized.o mthlib.fppized.o nameio.fppized.o
nmr.fppized.o olix.o ordint.fppized.o ormas1.fppized.o parley.fppized.o
pcm.fppized.o pcmcav.o pcmcv2.fppized.o pcmder.fppized.o pcmdis.fppized.o
pcmief.fppized.o pcmpol.fppized.o pcmvch.fppized.o prpel.fppized.o
prplib.fppized.o prppop.fppized.o qeigen.fppized.o qfmm.fppized.o
qmfm.fppized.o qmmm.fppized.o qrel.fppized.o raman.fppized.o rhfuhf.fppized.o
rxncrd.fppized.o ryspol.o scflib.fppized.o scfmi.fppized.o scrf.fppized.o
sobrt.fppized.o soffac.fppized.o solib.fppized.o sozeff.fppized.o
statpt.fppized.o surf.fppized.o symorb.fppized.o symslc.fppized.o
tdhf.fppized.o trans.fppized.o trfdm2.fppized.o trnstn.fppized.o
trudge.fppized.o umpddi.fppized.o unport.fppized.o vibanl.fppized.o
vscf.fppized.o zheev.fppized.o zmatrx.fppized.o -lm-o
gamess

[Bug middle-end/59827] [4.7/4.8 Regression] ICE on array with incomplete element type

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59827

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jan 16 12:59:36 2014
New Revision: 206662

URL: http://gcc.gnu.org/viewcvs?rev=206662&root=gcc&view=rev
Log:
PR middle-end/59827
* gimple-low.c (gimple_check_call_args): Don't use DECL_ARG_TYPE if
it is error_mark_node.
testsuite/
* gcc.dg/pr59827.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr59827.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/gimple-low.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/59839] i686 AVX2 gather intrinsic not compiling with -O0 on mingw w64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59839

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.8.3
 Ever confirmed|0   |1

[Bug target/59839] i686 AVX2 gather intrinsic not compiling with -O0 on mingw w64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59839

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 31853
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31853&action=edit
gcc49-pr59839.patch

Untested fix.

[Bug tree-optimization/46590] long compile time with -O2 and many loops

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590

--- Comment #39 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 16 13:48:51 2014
New Revision: 206663

URL: http://gcc.gnu.org/viewcvs?rev=206663&root=gcc&view=rev
Log:
2014-01-16  Richard Biener  

PR rtl-optimization/46590
* lcm.c (compute_antinout_edge): Use postorder iteration.
(compute_laterin): Use inverted postorder iteration.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lcm.c

[Bug other/58996] [4.9 regression] build failure in libcilkrts

[barry.m.tannenbaum at intel dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996

--- Comment #14 from Barry Tannenbaum  ---
The original author of the code is no longer working on the Cilk project, so I
can't say why it's using sched_getaffinity + gettid instead the pthread
routine.  But I'll modify it to use the pthread routine and investigate support
for >1024 cores.

Is there a machine we can use to test that?

   - Barry

[Bug other/58996] [4.9 regression] build failure in libcilkrts

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996

--- Comment #15 from Jakub Jelinek  ---
The reporter of PR57298 supposedly has or had, I don't.

[Bug middle-end/59841] [4.9 Regression] internal compiler error: verify_ssa failed

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59841

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
 CC||rguenther at suse dot de
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It is caused by r206599.

[Bug middle-end/58344] [4.9 Regression] ICE with segfault at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58344

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 31854
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31854&action=edit
gcc49-pr58344.patch

Untested fix.

[Bug middle-end/59841] [4.9 Regression] internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59841

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Should be fixed by

2014-01-15  Richard Biener  

PR tree-optimization/59822
* tree-vect-stmts.c (hoist_defs_of_uses): New function.
(vectorizable_load): Use it to hoist defs of uses of invariant
loads out of the loop.

[Bug ipa/59831] [4.9 Regression] ice in cgraph_speculative_call_info with -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59831

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug other/59834] [4.9 Regression] g++.dg/cilk-plus/CK/catch_exc.cc

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59834

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug target/59828] Broken assembly on ppc* with two -mcpu= options

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59828

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-16
 CC||amodra at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

[Bug target/59842] New: `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…

[tg at mirbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842

Bug ID: 59842
   Summary: `__x86.get_pc_thunk.bx' referenced in section `.text':
defined in discarded section…
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tg at mirbsd dot org

Created attachment 31855
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31855&action=edit
test runner

Hi *,

I originally filed this as Debian #735564 but a user informed me they are also
seeing this on other GNU/Linux distributions, and with GCC 4.7.1 on Slackware.

Since a while, I’m getting errors like these:

`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o

I used to be able to avoid them (although, back then, the symbol
was named “__i686.get_pc_thunk.bx”) by adding -march=i486, but
this no longer helps.

Screen log (the files x.sh, x.i and x.sym are attached):

tglase@tglase:~ $ mksh x.sh
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
`__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in
discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o
collect2: error: ld returned 1 exit status

IMHO, GCC may not mark symbols as discardable that it uses by itself. Adding
this to the symbol file is no solution either, as this becomes highly platform-
and compiler-dependent.

[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…

[tg at mirbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842

--- Comment #2 from Thorsten Glaser  ---
Created attachment 31857
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31857&action=edit
symbols file

[Bug target/59843] New: ICE with return of generic vector on aarch64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843

Bug ID: 59843
   Summary: ICE with return of generic vector on aarch64
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org

typedef double V __attribute__ ((vector_size (8)));
V
foo (void)
{
  V r = { 3.5 };
  return r;
}

ICEs at all optimization levels on aarch64-linux, trying to return BLKmode
using a PARALLEL isn't going to work.  Seen both on the trunk and 4.8 branch.

[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…

[tg at mirbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842

--- Comment #1 from Thorsten Glaser  ---
Created attachment 31856
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31856&action=edit
preprocessed source code

[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…

[tg at mirbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842

Thorsten Glaser  changed:

   What|Removed |Added

 Target||i486-linux-gnu
URL||http://bugs.debian.org/cgi-
   ||bin/bugreport.cgi?bug=73556
   ||4
  Known to work||4.6.4
   Host||i486-linux-gnu
  Known to fail||4.7.1, 4.8.2
  Build||i486-linux-gnu

--- Comment #3 from Thorsten Glaser  ---
Adding extra info. GCC 4.6 (Debian sid) works iff you add -march=i486 but
exhibits the same problem (with different symbol) otherwise. GCC 3.4.6 (MirBSD)
works.

[Bug middle-end/59827] [4.7 Regression] ICE on array with incomplete element type

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59827

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed on all active branches.

[Bug middle-end/59827] [4.7 Regression] ICE on array with incomplete element type

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59827

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jan 16 14:59:46 2014
New Revision: 206665

URL: http://gcc.gnu.org/viewcvs?rev=206665&root=gcc&view=rev
Log:
PR middle-end/59827
* gimple-low.c (gimple_check_call_args): Don't use DECL_ARG_TYPE if
it is error_mark_node.
testsuite/
* gcc.dg/pr59827.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr59827.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/gimple-low.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #12 from Peter Bergner  ---
Author: bergner
Date: Thu Jan 16 14:57:00 2014
New Revision: 206664

URL: http://gcc.gnu.org/viewcvs?rev=206664&root=gcc&view=rev
Log:
Backport from mainline
2014-01-15  Uros Bizjak  

* config/i386/i386.c (ix86_hard_regno_mode_ok): Use
VALID_AVX256_REG_OR_OI_MODE.

2013-09-05  Peter Bergner  

PR target/58139
* reginfo.c (choose_hard_reg_mode): Scan through all mode classes
looking for widest mode.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/reginfo.c

[Bug other/58996] [4.9 regression] build failure in libcilkrts

[bviyer at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996

--- Comment #16 from Balaji V. Iyer  ---
Hi Jakub,
Honestly, I don't know why the changes were done in aclocal.m4. I added the
change to configure.ac and then did the following commands:

autoreconf --force --verbose
automake --add-missing --verbose


Is there anything else (or any other flags) that I should do (or add)?

Thanks,

Balaji V. Iyer.

[Bug target/59844] New: Powerpc64le cannot bootstrap with -O3/-mcpu=power8

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844

Bug ID: 59844
   Summary: Powerpc64le cannot bootstrap with -O3/-mcpu=power8
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org

Several of the direct move insns (added in ISA 2.07/power8) are guarded by
tests for WORDS_BIG_ENDIAN, which generates errors when the compiler is
bootstrapped with -O3 and -mcpu=power8.  In addition, the direct-move vector
tests will fail.

These guards were added to make sure when the little endian work was done, that
we used the correct word order for little endian as compared to big endian. 
Since gen_highpart/gen_lowpart is used for creating the SUBREG's, it is safe to
remove the big endian guard test.

[Bug rtl-optimization/59835] [4.9 Regression] gcc.target/i386/sse-2[34].c timeout

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This boils down to -O2 -mavx512f
typedef int V __attribute__ ((vector_size (8)));

V
foo (char x)
{
  return (V) __builtin_ia32_vec_init_v8qi (x, x, x, x, x, x, x, x);
}

I think, except that for some weird reasons in this shorter testcase
we get:
pr59835.c: In function ‘foo’:
pr59835.c:7:1: internal compiler error: Max. number of generated reload insns
per insn is achieved (90)
ICE and with the larger one LRA just keeps iterating forever.

[Bug rtl-optimization/59835] [4.9 Regression] gcc.target/i386/sse-2[34].c timeout

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835

--- Comment #3 from Jakub Jelinek  ---
Ah, with -O2 -mavx512f -march=k8 it actually hangs.  So the short testcase is
enough to reproduce it.

[Bug target/59844] Powerpc64le cannot bootstrap with -O3/-mcpu=power8

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844

--- Comment #1 from Michael Meissner  ---
Created attachment 31858
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31858&action=edit
Proposed patch to fix the problem

Patch tested by Bill Schmitd, and passes the regression testing.

[Bug target/59844] Powerpc64le cannot bootstrap with -O3/-mcpu=power8

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844

Michael Meissner  changed:

   What|Removed |Added

 Target||powerpc64le-linux
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-16
   Host||powerpc64le-linux
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Build||powerpc64le-linux

[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694

--- Comment #19 from Richard Henderson  ---
Author: rth
Date: Thu Jan 16 16:23:54 2014
New Revision: 20

URL: http://gcc.gnu.org/viewcvs?rev=20&root=gcc&view=rev
Log:
PR debug/54694

Diagnose frame_pointer_required vs fixed hfp

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr54694.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/ira.c
branches/gcc-4_8-branch/gcc/reginfo.c
branches/gcc-4_8-branch/gcc/rtl.h

[Bug other/58996] [4.9 regression] build failure in libcilkrts

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996

--- Comment #17 from Jeffrey A. Law  ---
If there's an interest, I could probably create a kickstart for a RHL8 VM
suitable for building GCC 4.9.   But it's a 10+ year old platform of marginal
value at best.

I'd be much more concerned about using cpu_set_t instead of the dynamically
sizing variants.  As Jakub noted cpu_set_t doesn't work with > 1024 processors
and it's been the source of some cross-distro problems as well.  If at all
possible we need to be moving away from using cpu_set_t to the newer APIs.

My recommendation would be to address the RHL8 problem (no cpu_set_t at all) as
efficiently as possible without burning huge amount of time on it.   Then a
separate BZ to track issues around moving away from cpu_set_t to the more
modern interfaces.

[Bug target/59843] ICE with return of generic vector on aarch64

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-16
 CC||pinskia at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694

--- Comment #20 from Richard Henderson  ---
Author: rth
Date: Thu Jan 16 16:33:30 2014
New Revision: 206667

URL: http://gcc.gnu.org/viewcvs?rev=206667&root=gcc&view=rev
Log:
PR debug/54694

Diagnose frame_pointer_required vs fixed hfp

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr54694.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/ira.c
branches/gcc-4_7-branch/gcc/reginfo.c
branches/gcc-4_7-branch/gcc/rtl.h

[Bug c/59820] alpha: incorrect optimisation with -mcpu=ev4 and -O2

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820

--- Comment #3 from Richard Henderson  ---
I think you're right.  I'm preparing a patch for glibc.

[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842

Andrew Pinski  changed:

   What|Removed |Added

URL|http://bugs.debian.org/cgi- |
   |bin/bugreport.cgi?bug=73556 |
   |4   |
   See Also||http://bugs.debian.org/7355
   ||64

--- Comment #4 from Andrew Pinski  ---
I don't think this is a GCC bug but rather a bug using objcopy and thinking
that will not get rid of hidden global symbols.

The .text.__x86.get_pc_thunk.[bc]x symbols are defined as:
.section   
.text.__x86.get_pc_thunk.cx,"axG",@progbits,__x86.get_pc_thunk.cx,comdat
.globl  __x86.get_pc_thunk.cx
.hidden __x86.get_pc_thunk.cx
.type   __x86.get_pc_thunk.cx, @function
__x86.get_pc_thunk.cx:
.LFB15:
.cfi_startproc
movl(%esp), %ecx
ret
.cfi_endproc
.LFE15:
.section   
.text.__x86.get_pc_thunk.bx,"axG",@progbits,__x86.get_pc_thunk.bx,comdat
.globl  __x86.get_pc_thunk.bx
.hidden __x86.get_pc_thunk.bx
.type   __x86.get_pc_thunk.bx, @function
__x86.get_pc_thunk.bx:
.LFB16:
.cfi_startproc
movl(%esp), %ebx
ret

So they are already hidden so when doing the final link they will not show up
in the shared library.  The objcopy is removing the symbol names for these
section which is invalid as they are comdat and cannot be removed.


Really the code should move over to a versioning script instead of using
objcopy and that would work much better and be slightly more portable.

[Bug rtl-optimization/59835] [4.9 Regression] gcc.target/i386/sse-2[34].c timeout

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835

Jakub Jelinek  changed:

   What|Removed |Added

 CC||kyukhin at gcc dot gnu.org,
   ||rth at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Regardless if there is a LRA bug or not, I'd say the *k, maybe
kortestzhi, kortestchi, and definitely kunpckhi look problematic to me.
As shown on the testcase, kunpckhi can be very well matched by the combiner,
but the pattern doesn't have any GPR constraints, and if as in this testcase
the result isn't used as mask of any AVX512F vector insn, nor say input loaded
from memory and result immediately stored into memory, I'd say reloading it
into mask registers and back can't be cheap.  Can't the kunpckhi constraints be
"=Yk,Q", "Yk,Q", "Yk,0" and just emit "mov{b}\t{%1, %h0|%h0, %1}" in that case
(could be of course just limited to TARGET_AVX512F as is now).
As for kortest[cz]hi, dunno if the combiner can actually match them.  And for
*k, my issue with that pattern is that it doesn't have (clobber
CC)
and in theory could be matched pre-RA by something and then would force RA to
choose the mask registers over something perhaps cheaper.
I wonder if the pattern can't be limited to reload_completed and perhaps there
can be a splitter that will split post-reload the any_logic SWI12 operation
with
(clobber CC) into the non-(clobber CC) variant if the operands are Yk.

[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org

--- Comment #21 from Richard Henderson  ---
Fixed.

[Bug tree-optimization/46590] long compile time with -O2 and many loops

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590

--- Comment #40 from Richard Biener  ---
On the full testcase tree LIM uses too much memory (I didn't merge some of
the patches that only benefit this kind of testcase ... bah).  Without LIM
we use around 1GB of memory at -O2 and

 df reaching defs:  19.42 (14%) usr  35.49 (82%) sys  55.13 (30%) wall 
 0 kB ( 0%) ggc
 alias stmt walking  :  34.25 (25%) usr   0.47 ( 1%) sys  34.76 (19%) wall 
  1451 kB ( 0%) ggc
 tree CFG cleanup:   7.75 ( 6%) usr   0.04 ( 0%) sys   7.73 ( 4%) wall 
  5002 kB ( 1%) ggc
 tree PTA:  22.32 (16%) usr   0.10 ( 0%) sys  22.43 (12%) wall 
  7882 kB ( 1%) ggc
 TOTAL : 137.5943.38   180.98
866898 kB

-O3 is similar.

I have a patch for the memory usage issue.

[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821

Jason Merrill  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
I think gimplify_arg clobbering a valid EXPR_LOCATION is wrong; both cases
should give the location of the default argument definition.

Aldy, what was the rationale for that change (r140917)?

[Bug target/59844] Powerpc64le cannot bootstrap with -O3/-mcpu=power8

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Thu Jan 16 17:08:52 2014
New Revision: 206668

URL: http://gcc.gnu.org/viewcvs?rev=206668&root=gcc&view=rev
Log:
2014-01-16  Michael Meissner  

PR target/59844
* config/rs6000/rs6000.md (reload_vsx_from_gprsf): Add little
endian support, remove tests for WORDS_BIG_ENDIAN.
(p8_mfvsrd_3_): Likewise.
(reload_gpr_from_vsx): Likewise.
(reload_gpr_from_vsxsf): Likewise.
(p8_mfvsrd_4_disf): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md

[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821

--- Comment #4 from Jakub Jelinek  ---
While I agree with that, for _builtin_{LINE,FILE,FUNCTION} (), those were added
specifically for the use in default arguments and were I think from the start
meant to give you the location of the call, not of the token where it appears,
otherwise those builtins don't make much sense (you could use __LINE__,
__FILE__
or __FUNCTION__ instead).

[Bug rtl-optimization/59835] [4.9 Regression] gcc.target/i386/sse-2[34].c timeout

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835

--- Comment #5 from Jakub Jelinek  ---
Untested patch for kunpckhi:
2014-01-16  Jakub Jelinek  

* config/i386/i386.md (kunpckhi): Add GPR alternative.

--- gcc/config/i386/i386.md.jj2014-01-09 21:07:23.0 +0100
+++ gcc/config/i386/i386.md2014-01-16 17:53:54.983352747 +0100
@@ -8486,14 +8486,16 @@ (define_insn "kortestchi"
(set_attr "prefix" "vex")])

 (define_insn "kunpckhi"
-  [(set (match_operand:HI 0 "register_operand" "=Yk")
+  [(set (match_operand:HI 0 "register_operand" "=Yk,Q")
 (ior:HI
   (ashift:HI
-(match_operand:HI 1 "register_operand" "Yk")
+(match_operand:HI 1 "register_operand" "Yk,Q")
 (const_int 8))
-  (zero_extend:HI (match_operand:QI 2 "register_operand" "Yk"]
+  (zero_extend:HI (match_operand:QI 2 "register_operand" "Yk,0"]
   "TARGET_AVX512F"
-  "kunpckbw\t{%2, %1, %0|%0, %1, %2}"
+  "@
+   kunpckbw\t{%2, %1, %0|%0, %1, %2}
+   mov{b}\t{%b1, %h0|%h0, %b1}"
   [(set_attr "mode" "HI")
(set_attr "type" "msklog")
(set_attr "prefix" "vex")])

Of course, no real performance testing has been performed, perhaps there should
be one ? or more for the =Q, Q, 0 alternative.  Without any ?, we don't ICE or
endlessly consume memory anymore, with one ? we do again.

With -O2 -march=k8 -mavx512f the patch changes (from before r206638 to trunk +
patch):
-kmovw%edi, %k1
-kunpckbw%k1, %k1, %k0
-kmovw%k0, -8(%rsp)
-movd-8(%rsp), %mm0
+movl%edi, %eax
+movb%al, %ah
+movd%eax, %mm0
Dunno of course how that compares performance wise, but at least it is shorter.
For -O2 -mavx512f:
-kmovw%edi, %k1
-kunpckbw%k1, %k1, %k0
-kmovw%k0, -8(%rsp)
+movl%edi, %eax
+movl%edi, %edx
+movb%al, %dh
+movw%dx, -8(%rsp)
so in this case perhaps using mask registers is better, as we store the result
into memory anyway.

[Bug gcov-profile/58602] .gcno files not truncated at gcov_close

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  ---
It seems like all we've done in the last 10 years is rotate through a set of
bugs in this code.

The whole point of the Richard's original removal of ftruncate was to make
things easier for folks on windows & using simulators (newlib).   That patch
introduced a race  which led to Jakub's change form Feb 2004 to close the race
condition, but which can leave the file untruncated.

So the question is does this introduce a race similar to what Jakub was trying
to fix back in Feb 2004?  What testing has been done to see if there's a race. 
Testing similar to Jakub's but scaled up for modern hardware would raise the
confidence level of this patch significantly.

http://marc.info/?l=gcc-patches&m=107747608611324&w=2

[ Oddly enough, the gcc.gnu.org archives seem to be missing for this thread and
much of Feb2004. ]

[Bug target/59843] ICE with return of generic vector on aarch64

[yufeng at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843

Yufeng Zhang  changed:

   What|Removed |Added

 Target|aarch64-linux   |aarch64-linux aarch64-elf
 Status|NEW |ASSIGNED
 CC||yufeng at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |yufeng at gcc dot 
gnu.org

--- Comment #2 from Yufeng Zhang  ---
Confirmed and assigned to myself.

test.c: In function 'foo':
test.c:6:3: internal compiler error: in emit_move_insn, at expr.c:3610
   return r;
   ^
0x63bbb0 emit_move_insn(rtx_def*, rtx_def*)
gcc/gcc/expr.c:3610
0x63e1a2 emit_group_load_1
gcc/gcc/expr.c:1750
0x63e5e9 emit_group_load(rtx_def*, rtx_def*, tree_node*, int)
gcc/gcc/expr.c:1846
0x587c27 expand_value_return
gcc/gcc/cfgexpand.c:3036
0x58ade6 expand_return
gcc/gcc/cfgexpand.c:3114
0x58ade6 expand_gimple_stmt_1
gcc/gcc/cfgexpand.c:3187
0x58ade6 expand_gimple_stmt
gcc/gcc/cfgexpand.c:3309
0x58c024 expand_gimple_basic_block
gcc/gcc/cfgexpand.c:5149
0x590536 gimple_expand_cfg
gcc/gcc/cfgexpand.c:5715
0x590536 execute
gcc/gcc/cfgexpand.c:5935
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/59844] Powerpc64le cannot bootstrap with -O3/-mcpu=power8

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
Committed as subversion revision 206668.

[Bug target/59844] Powerpc64le cannot bootstrap with -O3/-mcpu=power8

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Thu Jan 16 17:35:41 2014
New Revision: 206670

URL: http://gcc.gnu.org/viewcvs?rev=206670&root=gcc&view=rev
Log:
2014-01-16  Michael Meissner  

Back port from mainline
2014-01-16  Michael Meissner  

PR target/59844
* config/rs6000/rs6000.md (reload_vsx_from_gprsf): Add little
endian support, remove tests for WORDS_BIG_ENDIAN.
(p8_mfvsrd_3_): Likewise.
(reload_gpr_from_vsx): Likewise.
(reload_gpr_from_vsxsf): Likewise.
(p8_mfvsrd_4_disf): Likewise.


Modified:
branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.md

[Bug target/59780] ICE in aarch64_split_128bit_move

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59780

--- Comment #3 from Richard Earnshaw  ---
Author: rearnsha
Date: Thu Jan 16 17:35:50 2014
New Revision: 206671

URL: http://gcc.gnu.org/viewcvs?rev=206671&root=gcc&view=rev
Log:
PR target/59780
* aarch64.c (aarch64_split_128bit_move): Don't lookup REGNO on
non-register objects.  Use gen_(high/low)part more consistently.
Fix assertions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug target/59780] ICE in aarch64_split_128bit_move

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59780

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Earnshaw  ---
Fixed.

[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…

[tg at mirbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842

--- Comment #5 from Thorsten Glaser  ---
Hm, unsure. These versioning scripts are pretty much recent GNU stuff. But if
you have input…

cvs -d _anon...@anoncvs.mirbsd.org:/cvs co -PA -d xchat-randex
contrib/hosted/tg/code/xchat-randex

[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821

--- Comment #5 from Aldy Hernandez  ---
(In reply to Jason Merrill from comment #3)
> I think gimplify_arg clobbering a valid EXPR_LOCATION is wrong; both cases
> should give the location of the default argument definition.
> 
> Aldy, what was the rationale for that change (r140917)?

Unfortunately this was by design to make multi-line non-trivial arguments play
nice with the debugger.  Perhaps it's time to revisit the ``is_stmt'' DWARF
flag for this?

More details here:

http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00191.html

[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507

--- Comment #10 from Jan Hubicka  ---
I agree we want to do as much as possible in FE.

ODR decisions are basically done in frontend now - we basically use mangling of
virtual tables given to us by C++ FE.  Eventually we will want to get ODR
information on all types, not only polymorphic ones.  Then I plan to go with
Jason's suggested way of calling decl_assembler name on types to get mangling
from C++ FE rather than my initial attempt to actually compare types for
equivalence by their high level names that hits interesting issues with
templates. It is left in code mostly as backup if the other solution blows up
our memory footprint.

I do not think we can do type inheritance analysis + devirtualization purely by
frotnend, since it is naturally an inter-procuedural problem that needs to be
handled by LTO. We already have sane way to represent the type inheritance tree
by binfos.  What we  need to work on is a sane and safe way representing the
relevant type information that is given to you by C++ standard but thrown away
on way to GIMPLE so the propagation can work.

I was thinking of type assert expressions that can be inserted by FE on places
where dynamic type is known for non-trivial reasons. Those can be used as
starting points for the propagation of type information and removed after IPA.
This would allow us to preserve information while inlining and also make it
easier to deal with dynamic type changes. For simple operations, like in this
testcase, this approach may be however impractical producing too many new
gimple statements.

I am slowly getting to stage where current devirt infrastructure seems to work
as expected and seems to use most of information already there in gimple that
seems to be safe to assume.

My plan was to basically wait for this release cycle, see how many bugs shows
up so I am sure I do not miss something obvious (well, like the virtual
inheritance fun).

I think only parts we miss now is to
 - move ipa-cp to new infrastructure
 - move dynamic type change code to ipa-devirt and make it work with contextes
 - understand ctors/dtors calls, since we already ave flag marking them
specially.

I also collected testcases we need to handle. I will try to sit down and
prepare some proposal about what we need to preserve in gimple.
I think we also want central place (probably in ipa-devirt toplevel comment)
documenting all the information we take into account and assumptions we make.
So far they are mostly trivial (i.e. static vars/automatic vars/values passed
by invisible references are known to have their type and not derived type)
except for Martin's dynamic changing code.

[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842

--- Comment #6 from Andrew Pinski  ---
(In reply to Thorsten Glaser from comment #5)
> Hm, unsure. These versioning scripts are pretty much recent GNU stuff. 

Recent as in the last 10 years maybe.  But not in the last 5 years.  Also they
are supported in Solaris and even Darwin too.

[Bug c++/59845] New: loop optimization problem when profiling

[arshamidi at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59845

Bug ID: 59845
   Summary: loop optimization problem when profiling
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arshamidi at gmail dot com

I'm using g++ with GCC 4.8.1; when I use fprofile-generate too optimize my
code, it actually slows down the process time: (constant folding problem within
loop?)

int main(){

int n;
int i;
//int n2;
printf("Enter a number: ");
scanf("%d", &n);
//n2 = n/2;
printf("divisors are:\n\n");

for (i=1; i <= /*n2*/ n/2; i++)
if (n%i == 0)
printf("\n%d", i);

printf("\n\n end.\n");

return 0;
}

Here I must use the constant 'n2' (commented out) too actually get the desired
speed -in combination with -fprofile-generate. 
I'm using the following switches:
-Ofast;-fomit-frame-pointer;-march=core2; -mfpmath=sse; -fprofile-generate;
-Wall

no problem without -fprofile-generate and -fprofile-use

[Bug c/59846] New: Imprecise column number for -Wtype-limits

[chengniansun at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59846

Bug ID: 59846
   Summary: Imprecise column number for -Wtype-limits
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

GCC outputs a wrong column number of a type-limit (comparison between 0 and
unsigned) warning. 

$ gcc-trunk -Wall -Wextra -c -std=c11 -pedantic s.c
s.c: In function ‘fn1’:
s.c:33:3: warning: comparison is always false due to limited range of data type
[-Wtype-limits]
   return b ^= (   b<(0UL > p));
   ^

$ clang-trunk -Wall -Wextra -c -std=c11 -pedantic s.c
s.c:33:38: warning: comparison of 0 > unsigned expression is always false
[-Wtautological-compare]
  return b ^= (   b<(0UL > p));
 ~~~ ^ ~
1 warning generated.

$ cat s.c
int fn1(unsigned p) {
  int b = 99;
  return b ^= (   b<(0UL > p));
}

[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821

--- Comment #6 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #4)
> While I agree with that, for _builtin_{LINE,FILE,FUNCTION} (), those were
> added specifically for the use in default arguments and were I think from
> the start meant to give you the location of the call, not of the token where
> it appears, otherwise those builtins don't make much sense (you could use 
> __LINE__, __FILE__ or __FUNCTION__ instead).

Ah, I see.  In that case, I agree that adjusting their locations in
break_out_target_exprs is the way to go.

[Bug ipa/59831] [4.9 Regression] ice in cgraph_speculative_call_info with -O3

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59831

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
Here inliner turns virtual call to direct call while versioning. This
devirtualization is missed by ipa-cp, but anticipated by ipa-devirt's
speculative code.  The ICE happens since inliner is done with copying edges but
not with references while it attempts to resolve the indirect call.
I am looking into fix.

[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/59847] New: cast to long makes compiler crash if using option pdp-11/10

[mattis at mattisborgen dot se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59847

Bug ID: 59847
   Summary: cast to long makes compiler crash if using option
pdp-11/10
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattis at mattisborgen dot se

mattis@mattis-VirtualBox:~$ pdp11-aout-gcc   -m10 -S  longtest.c
longtest.c: In function 'test':
longtest.c:5:1: error: unrecognizable insn:
 }
 ^
(insn 7 6 10 2 (set (mem/c:SI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -4 [0xfffc])) [0 a+0 S4 A16])
(sign_extend:SI (mem/c:HI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -6 [0xfffa])) [0 b+0 S2 A16]))) longtest.c:4
-1
 (nil))
longtest.c:5:1: internal compiler error: in extract_insn, at recog.c:2154
0x837d527 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../src/gcc/rtl-error.c:109
0x837d571 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../src/gcc/rtl-error.c:117
0x8355394 extract_insn(rtx_def*)
../src/gcc/recog.c:2154
0x825d34e instantiate_virtual_regs_in_insn
../src/gcc/function.c:1561
0x825d34e instantiate_virtual_regs
../src/gcc/function.c:1928
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mattis@mattis-VirtualBox:~$ pdp11-aout-gcc  -v
Using built-in specs.
COLLECT_GCC=pdp11-aout-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/pdp11-aout/4.8.2/lto-wrapper
Target: pdp11-aout
Configured with: src/configure --target=pdp11-aout --disable-nls
--without-headers --enable-languages=c
Thread model: single
gcc version 4.8.2 (GCC) 


Linux mattis-VirtualBox 3.8.0-34-generic #49~precise1-Ubuntu SMP Wed Nov 13
18:08:04 UTC 2013 i686 i686 i386 GNU/Linux

Please note that if using -m40 or -m45 instead this problem goes away:

mattis@mattis-VirtualBox:~$ pdp11-aout-gcc   -m40 -S  longtest.c
mattis@mattis-VirtualBox:~$ cat longtest.s
.text

.even
.globl _test
_test:
mov r5, -(sp)
mov sp, r5
add $-06, sp
clr -04(r5)
mov $012,-02(r5)
mov $012, -06(r5)
mov -06(r5), -02(r5)
sxt -04(r5)
mov r5, sp
mov (sp)+, r5
rts pc
mattis@mattis-VirtualBox:~$ 

mattis@mattis-VirtualBox:~$ cat longtest.c
test () {
  long a=10;
  short b=10;
  a = (long) b;
}


It appears that the cast is causing the problem since removing it makes it
compile.

[Bug rtl-optimization/59835] [4.9 Regression] gcc.target/i386/sse-2[34].c timeout

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835

--- Comment #6 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Jan 16 19:04:08 2014
New Revision: 206676

URL: http://gcc.gnu.org/viewcvs?rev=206676&root=gcc&view=rev
Log:
2014-01-16  Vladimir Makarov  

PR rtl-optimization/59835
* ira.c (ira_init_register_move_cost): Increase cost for
impossible modes.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c

[Bug c++/59845] loop optimization problem when profiling

[arshamidi at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59845

--- Comment #1 from ArshaGCC  ---
I found that only when I use very high vales for input the problem persists.
for example when using 123456 as input for profiling it generates incorrect
code but when using 12345 as input the correct code will be generated.

Input is an integer and I can specify very long values for input like:
123456789.

[Bug tree-optimization/59387] [4.9 Regression] wrong code (hangs) at -Os on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59387

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 16 19:14:49 2014
New Revision: 206678

URL: http://gcc.gnu.org/viewcvs?rev=206678&root=gcc&view=rev
Log:
PR tree-optimization/59387
* gcc.c-torture/execute/pr59387.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr59387.c

[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694

--- Comment #22 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 16 19:15:46 2014
New Revision: 206679

URL: http://gcc.gnu.org/viewcvs?rev=206679&root=gcc&view=rev
Log:
PR debug/54694
* gcc.target/i386/pr9771-1.c (main): Rename to...
(real_main): ... this.  Add __asm name "main".
(ASMNAME, ASMNAME2, STRING): Define.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr9771-1.c

[Bug c++/59845] loop optimization problem when profiling

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59845

--- Comment #2 from Andrew Pinski  ---
>(constant folding problem within loop?)

No it is doing the following:

if (n>=1)
{
  i = 1;
  while (true)
{
  if (n%i == 0)
{
  printf("\n%d", i);
  i++;
  if (n/2 < i) break;
}
  else
{
  i++;
  if (n/2 < i) break;
}
}

}


Notice the load from n is not pulled out of the loop and that is because the
compiler thinks n escapes via scanf.

[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694

--- Comment #23 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 16 19:20:50 2014
New Revision: 206680

URL: http://gcc.gnu.org/viewcvs?rev=206680&root=gcc&view=rev
Log:
PR debug/54694
* gcc.target/i386/pr9771-1.c (main): Rename to...
(real_main): ... this.  Add __asm name "main".
(ASMNAME, ASMNAME2, STRING): Define.

Modified:
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr9771-1.c

[Bug middle-end/59609] [4.9 Regression] LRA generates bad code for libgcc function udivmoddi4 on thumb1 target

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Jan 16 19:13:54 2014
New Revision: 206677

URL: http://gcc.gnu.org/viewcvs?rev=206677&root=gcc&view=rev
Log:
2014-01-16  Vladimir Makarov  

PR middle-end/59609
* lra-constraints.c (process_alt_operands): Add printing debug
info.  Check absence of input/output reloads for matched operands
too.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694

--- Comment #24 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 16 19:22:08 2014
New Revision: 206681

URL: http://gcc.gnu.org/viewcvs?rev=206681&root=gcc&view=rev
Log:
PR debug/54694
* gcc.target/i386/pr9771-1.c (main): Rename to...
(real_main): ... this.  Add __asm name "main".
(ASMNAME, ASMNAME2, STRING): Define.

Modified:
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr9771-1.c

[Bug target/59839] i686 AVX2 gather intrinsic not compiling with -O0 on mingw w64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59839

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 16 19:24:07 2014
New Revision: 206682

URL: http://gcc.gnu.org/viewcvs?rev=206682&root=gcc&view=rev
Log:
PR target/59839
* config/i386/i386.c (ix86_expand_builtin): If target doesn't
satisfy operand 0 predicate for gathers, use a new pseudo as
subtarget.

* gcc.target/i386/pr59839.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr59839.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/59839] i686 AVX2 gather intrinsic not compiling with -O0 on mingw w64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59839

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 16 19:26:08 2014
New Revision: 206683

URL: http://gcc.gnu.org/viewcvs?rev=206683&root=gcc&view=rev
Log:
PR target/59839
* config/i386/i386.c (ix86_expand_builtin): If target doesn't
satisfy operand 0 predicate for gathers, use a new pseudo as
subtarget.

* gcc.target/i386/pr59839.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59839.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/59839] i686 AVX2 gather intrinsic not compiling with -O0 on mingw w64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59839

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 16 19:27:28 2014
New Revision: 206684

URL: http://gcc.gnu.org/viewcvs?rev=206684&root=gcc&view=rev
Log:
PR target/59839
* config/i386/i386.c (ix86_expand_builtin): If target doesn't
satisfy operand 0 predicate for gathers, use a new pseudo as
subtarget.

* gcc.target/i386/pr59839.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr59839.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/i386.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug target/59839] i686 AVX2 gather intrinsic not compiling with -O0 on mingw w64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59839

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug rtl-optimization/59835] [4.9 Regression] gcc.target/i386/sse-2[34].c timeout

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)

> Of course, no real performance testing has been performed, perhaps there
> should be one ? or more for the =Q, Q, 0 alternative.  Without any ?, we
> don't ICE or endlessly consume memory anymore, with one ? we do again.

IMO, handling of mask registers can be improved overall. However, we have to
start somewhere, and for 4.9 the implementation is "good enough" to move things
forward. On the condition that nothing regresses, of course.

The perfection will be reached incrementally in later revisions. Your patch is
in the right direction, but probably requires various cost function
improvements and some fine tuning of constraints. I believe that compiler
should be able to choose correct instructions on its own, without crippling the
move pattern with UNSPEC.

[Bug rtl-optimization/59835] [4.9 Regression] gcc.target/i386/sse-2[34].c timeout

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed with Vladimir's patch.

[Bug middle-end/59609] [4.9 Regression] LRA generates bad code for libgcc function udivmoddi4 on thumb1 target

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Hopefully fixed.

[Bug c/59825] Many cilkplus test failures

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59825

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |bviyer at gmail dot com
Summary|[4.9 Regression] Many   |Many cilkplus test failures
   |cilkplus test failures  |

--- Comment #3 from Jeffrey A. Law  ---
Given Cilk+ is new in 4.9 the test failures are not a regression.

[Bug other/59490] cilk-plus failure

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59490

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |bviyer at gmail dot com
Summary|[4.9 Regression] cilk-plus  |cilk-plus failure
   |failure |

--- Comment #4 from Jeffrey A. Law  ---
Cilk is new for 4.9, thus these failures are not a regression.

[Bug middle-end/58344] [4.9 Regression] ICE with segfault at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58344

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 16 19:54:23 2014
New Revision: 206685

URL: http://gcc.gnu.org/viewcvs?rev=206685&root=gcc&view=rev
Log:
PR middle-end/58344
* expr.c (expand_expr_real_1): Handle init == NULL_TREE.

* gcc.c-torture/compile/pr58344.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr58344.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Thu Jan 16 19:55:12 2014
New Revision: 206686

URL: http://gcc.gnu.org/viewcvs?rev=206686&root=gcc&view=rev
Log:
PR c++/59821
* tree.c (bot_manip): Update the location of builtin_LINE and
builtin_FILE calls.

Added:
trunk/gcc/testsuite/g++.dg/ext/builtin-line1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/doc/extend.texi

[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #8 from Jason Merrill  ---
Fixed for 4.9.