[Bug middle-end/58670] asm goto miscompilation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug middle-end/58670] asm goto miscompilation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug ipa/58678] New: [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[markus at trippelsdorf dot de]

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

Bug ID: 58678
   Summary: [4.9 Regression] pykde4-4.11.2 link error
(devirtualization too trigger happy)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus at trippelsdorf dot de

pykde4-4.11.2 fails to build:

CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart5.cpp.o:sipphononpart5.cpp:function
release_Phonon_BackendCapabilities_Notifier: error: undefined reference to
'vtable for Phonon::BackendCapabilities::Notifier'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld:
the vtable symbol may be undefined because the class is missing its key
function
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart5.cpp.o:sipphononpart5.cpp:function
Phonon::BackendCapabilities::Notifier::~Notifier(): error: undefined reference
to 'vtable for Phonon::BackendCapabilities::Notifier'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld:
the vtable symbol may be undefined because the class is missing its key
function
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart5.cpp.o:sipphononpart5.cpp:function
Phonon::BackendCapabilities::Notifier::~Notifier(): error: undefined reference
to 'vtable for Phonon::BackendCapabilities::Notifier'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld:
the vtable symbol may be undefined because the class is missing its key
function
collect2: error: ld returned 1 exit status

Reduced:

markus@x4 tmp % cat test.ii
class A {
public:
  virtual ~A();
};
class B : A {
  virtual int m_fn1();
};
void fn1() {
  delete reinterpret_cast(1);
}

markus@x4 tmp % g++ -O1 -c test.ii
markus@x4 tmp % nm test.o | c++filt
 T fn1()

markus@x4 tmp % g++ -O2 -c test.ii
markus@x4 tmp % nm test.o | c++filt
 T fn1()
 U operator delete(void*)
 U A::~A()
 W B::~B()
 W B::~B()
 W B::~B()
 n B::~B()
 U vtable for B

markus@x4 tmp % clang++ -O2 -c test.ii
markus@x4 tmp % nm test.o | c++filt
 T fn1()
markus@x4 tmp % 

Started with r202145.

[Bug ipa/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
Hmm, what prevents us from devirtualizing here? It seems to be bug to include a
class without linking with its implementation..

[Bug rtl-optimization/58679] New: [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[izamyatin at gmail dot com]

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

Bug ID: 58679
   Summary: [4.9 regression] ICE in create_pre_exit, at
mode-switching.c:421 with -mavx after r202915
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: yvan.roux at linaro dot org
  Host: x86
Target: x86

Happens with gcc.c-torture/execute/pr30185.c with just "-O2 -mavx" options.

Removing all REG_DEAD and REG_UNUSED notes as said in r202915 affected work of
single_set_2 for 

  if (GET_CODE (pat) == PARALLEL)

and hence in mode-switching.c single_set now returns NULL for

  return_copy_pat = single_set (return_copy);


Not sure who is exactly wrong here - create_pre_exit code doesn't look very
clear :(

[Bug sanitizer/58680] New: Spurious warnings from libasan

[y.gribov at samsung dot com]

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

Bug ID: 58680
   Summary: Spurious warnings from libasan
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: y.gribov at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Created attachment 30975
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30975&action=edit
Repro

I've found that Sanitizer will sometimes report a warning about failed
interceptions of libc functions.

 $ ~/install/gcc-master/bin/gcc prog.c -fsanitize=address -DGEN_PLT
 $ LD_LIBRARY_PATH=~/install/gcc-master/lib64:$LD_LIBRARY_PATH
ASAN_OPTIONS=verbosity=1 ./a.out
 ==30654== Parsed ASAN_OPTIONS: verbosity=1
 ==30654== AddressSanitizer: failed to intercept 'memcpy'
 ==30654== AddressSanitizer: libc interceptors initialized
 ...

After small and inspiring investigation I've found out that this warning is
caused by check for successful interception of memcpy in
libsanitizer/asan/asan_interceptors.cc:676:

 ASAN_INTERCEPT_FUNC(memcpy);

Apart from other actions, this macro verifies that memcpy and
__interceptor_memcpy resolve to the same address. Unfortunately this does not
happen if main executable takes address of memcpy. In that case ld.so will
resolve memcpy to the address of corresponding PLT entry in executable. This
won't cause any problem (because PLT entry will eventually call Asan's memcpy)
but will make libsanitizer think that it has failed to override memcpy.

This problem could be worked around by compiling with -static-libasan because
in this case memcpy will be resolved to __interceptor_memcpy at link time (i.e.
statically). AFAIK Clang uses static libsanitizer by default so they probably
never ever faced this problem.

I suggest that we either remove the warning or make the check in
ASAN_INTERCEPT_FUNC more sophisticated so as to support dynamic libsanitizer.

-Y

[Bug rtl-optimization/58681] New: Missed RTL optimization - same insns before unconditional jump as before the jump target

[jakub at gcc dot gnu.org]

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

Bug ID: 58681
   Summary: Missed RTL optimization - same insns before
unconditional jump as before the jump target
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, rth at gcc dot gnu.org

While looking at PR58670 workaround, I've noticed we don't optimize very well:
int
foo (int a, int b)
{
  int c, d, e, f;
  if (a < 9)
{
  c = -3;
  d = -1;
  e = -20;
  f = -5;
}
  else
{
  asm volatile goto ("bts $1, %0; jc %l[lab]" : : "m" (b) : "memory" :
lab);
  asm ("");
  c = 0;
  d = 12;
  e = 26;
  f = 7;
  goto l;
lab:
  c = 0;
  d = 12;
  e = 26;
  f = 7;
l:;
}
  return bar (bar (bar (c, d), e), f);
}

e.g. at -O0, the 4 assignments are the same right above a code label to which
an unconditional jump jumps and above the unconditional jump.  If we detected
that, we could remove the 4 assignments from the second bb and just adjust the
unconditional jump to jump before the 4 assignments instead of after them. 
Perhaps then even cfg cleanup would optimize away the jump (from asm goto) to
just an unconditional jump elsewhere.Note that if a < 9 in the testcase
above is replaced with just a, then the insns are the same only before
postreload, postreload then figures out that the %rdi already contains 0 and
changes it, but apparently just in ebb and not in other bbs.

Could this optimization be perhaps performed before reload (or both before and
after)?

[Bug sanitizer/58680] Spurious warnings from libasan

[kcc at gcc dot gnu.org]

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

Kostya Serebryany  changed:

   What|Removed |Added

 CC||eugeni.stepanov at gmail dot 
com,
   ||glider at google dot com,
   ||samsonov at google dot com

--- Comment #1 from Kostya Serebryany  ---
In clang we indeed support *only* static run-time and have no experience with
dynamic run-time on Linux.
I wonder if this may affect Mac or Android, where the run-time is dynamic?

[Bug target/58668] [arm with hardfp ABI]: internal compiler error: in cond_exec_process_insns, at ifcvt.c:339

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|arm-linux-gnueabihf |arm-linux-gnueabihf,
   ||arm-none-eabi
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-10
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.0

--- Comment #2 from ktkachov at gcc dot gnu.org ---
After trying out some option combinations, I managed to reproduce it on 4.8 and
trunk. For me it ICEs with -O2, but works with -O3 _unless_ I add -fPIC, in
which case it ICEs.

[Bug rtl-optimization/58668] [4.8, 4.9 regression][arm]: internal compiler error: in cond_exec_process_insns, at ifcvt.c:339

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
  Known to work||4.7.4
Summary|[arm with hardfp ABI]:  |[4.8, 4.9 regression][arm]:
   |internal compiler error: in |internal compiler error: in
   |cond_exec_process_insns, at |cond_exec_process_insns, at
   |ifcvt.c:339 |ifcvt.c:339

--- Comment #3 from Richard Earnshaw  ---
cond_exec_process_insns is throwing a wobbly, since it is not expecting to
handle a jump insn (in this case a return).

(jump_insn 62 61 51 4 (parallel [
(return)
(set/f (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 13 sp)
(const_int 16 [0x10])))
(set/f (reg:SI 3 r3)
(mem/c:SI (reg/f:SI 13 sp) [25 S4 A32]))
(set/f (reg:SI 4 r4)
(mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 4 [0x4])) [25 S4 A32]))
(set/f (reg:SI 5 r5)
(mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 8 [0x8])) [25 S4 A32]))
(set/f (reg:SI 15 pc)
(mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 12 [0xc])) [25 S4 A32]))
]) image.c:1709 -1
 (expr_list:REG_UNUSED (reg:SI 15 pc)
(expr_list:REG_UNUSED (reg:SI 3 r3)
(expr_list:REG_CFA_RESTORE (reg:SI 5 r5)
(expr_list:REG_CFA_RESTORE (reg:SI 4 r4)
(expr_list:REG_CFA_RESTORE (reg:SI 3 r3)
(nil))
 -> return)

Seems to work with 4.7, so a regression.

[Bug rtl-optimization/58681] Missed RTL optimization - same insns before unconditional jump as before the jump target

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
(In reply to Richard Biener from comment #1)
> We used to factor
> 
>   # c_1 = PHI <-3(2), 0(4), 0(3)>
>   # d_2 = PHI <-1(2), 12(4), 12(3)>
>   # e_3 = PHI <-20(2), 26(4), 26(3)>
>   # f_4 = PHI <-5(2), 7(4), 7(3)>
> lab:
> 
> into
> 
> 
>   # c_11 = PHI <0(4), 0(3)>
>   # d_21 = PHI <12(4), 12(3)>
>   # e_31 = PHI <26(4), 26(3)>
>   # f_41 = PHI <7(4), 7(3)>

Of course just

c_11 = 0;
d_21 = 12;
e_31 = 26;
f_41 = 7;

>   # c_1 = PHI <-3(2), c_11(42)>
>   # d_2 = PHI <-1(2), d_21(42)>
>   # e_3 = PHI <-20(2), e_31(42)>
>   # f_4 = PHI <-5(2), f_41(42)>
> lab:
> 
> when we really got out-of-SSA.  I suspect this would have fixed the issue?

[Bug rtl-optimization/58681] Missed RTL optimization - same insns before unconditional jump as before the jump target

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
We used to factor

  # c_1 = PHI <-3(2), 0(4), 0(3)>
  # d_2 = PHI <-1(2), 12(4), 12(3)>
  # e_3 = PHI <-20(2), 26(4), 26(3)>
  # f_4 = PHI <-5(2), 7(4), 7(3)>
lab:

into


  # c_11 = PHI <0(4), 0(3)>
  # d_21 = PHI <12(4), 12(3)>
  # e_31 = PHI <26(4), 26(3)>
  # f_41 = PHI <7(4), 7(3)>

  # c_1 = PHI <-3(2), c_11(42)>
  # d_2 = PHI <-1(2), d_21(42)>
  # e_3 = PHI <-20(2), e_31(42)>
  # f_4 = PHI <-5(2), f_41(42)>
lab:

when we really got out-of-SSA.  I suspect this would have fixed the issue?

[Bug rtl-optimization/58681] Missed RTL optimization - same insns before unconditional jump as before the jump target

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> (In reply to Richard Biener from comment #1)
> > We used to factor
> > 
> >   # c_1 = PHI <-3(2), 0(4), 0(3)>
> >   # d_2 = PHI <-1(2), 12(4), 12(3)>
> >   # e_3 = PHI <-20(2), 26(4), 26(3)>
> >   # f_4 = PHI <-5(2), 7(4), 7(3)>
> > lab:
> > 
> > into
> > 
> > 
> >   # c_11 = PHI <0(4), 0(3)>
> >   # d_21 = PHI <12(4), 12(3)>
> >   # e_31 = PHI <26(4), 26(3)>
> >   # f_41 = PHI <7(4), 7(3)>
> 
> Of course just
> 
> c_11 = 0;
> d_21 = 12;
> e_31 = 26;
> f_41 = 7;
> 
> >   # c_1 = PHI <-3(2), c_11(42)>
> >   # d_2 = PHI <-1(2), d_21(42)>
> >   # e_3 = PHI <-20(2), e_31(42)>
> >   # f_4 = PHI <-5(2), f_41(42)>
> > lab:

Eh, or

:


   # c_1 = PHI <-3(2), 0(42)>
   # d_2 = PHI <-1(2), 12(42)>
   # e_3 = PHI <-20(2), 26(42)>
   # f_4 = PHI <-5(2), 41(42)>
lab:

basically un-merge PHIs intelligently.

> > 
> > when we really got out-of-SSA.  I suspect this would have fixed the issue?

[Bug ipa/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[markus at trippelsdorf dot de]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #1)
> Hmm, what prevents us from devirtualizing here? It seems to be bug to
> include a class without linking with its implementation..

In this case the implementation is linked in, but the symbol
is only local.

 # nm /usr/lib64/libphonon.so.4.6.0 | c++filt | grep "vtable for
Phonon::BackendCapabilities::Notifier"
00066380 d vtable for Phonon::BackendCapabilities::Notifier

[Bug ipa/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Adding __attribute__ ((visibility ("default"))) to
Phonon::BackendCapabilities::Notifier fixes the issue.

[Bug ipa/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
Actually ipa-devirt has a code that is supposed to not make devirt happen in
this case - I will check out why it doesn't here.

But I think it is KDE's bug here.  You have library with -fvisibility=hidden
and the class has no visibility attributes attached, so it is fully captured in
the library and you should not include it from file that is not part of the
library.

Not exactly C++ standard, since it does not speak about visibilities, but it is
how we figure out what we can reffer:

static bool
can_refer_decl_in_current_unit_p (tree decl, tree from_decl)

which has clause

  /* We are folding reference from external vtable.  The vtable may reffer
 to a symbol keyed to other compilation unit.  The other compilation
 unit may be in separate DSO and the symbol may be hidden.  */
  if (DECL_VISIBILITY_SPECIFIED (decl)
  && DECL_EXTERNAL (decl)
  && (!(snode = symtab_get_node (decl)) ||
!snode->symbol.in_other_partition))
return false;


that is supposed to catch cases where user specifies visibilities.  It won't
catch
this case because command line option is used.

I am adding Jason into CC, perhaps we need to revisit logic above.
I will also check why the devirtualization survive - it should not since it
seems
useless.

Honza

[Bug ipa/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #5 from Jan Hubicka  ---
Actually one thing I am puzzled about is the fact that ~B() that is being
devirtualized is COMDAT, but it reffers to the vtable that is external:

_ZTV1B/6 (int (* B::_ZTV1B [5])(...)) @0x77036a28
  Type: variable definition analyzed
  Visibility: external public virtual artificial
  Aux: @0x1  References: _ZTI1B/9 (addr)_ZN1BD1Ev/3 (addr)_ZN1BD0Ev/4
(addr)virtual int B::m_fn1()/10 (addr)
  Referring: _ZN1BD2Ev/2 (addr)
  Availability: not-ready
  Varpool flags: initialized read-only const-value-known
_ZN1BD0Ev/4 (virtual B::~B()) @0x770405f0
  Type: function definition analyzed
  Visibility: public weak comdat comdat_group:_ZN1BD0Ev one_only virtual
artificial
  Same comdat group as: _ZN1BD2Ev/2
  Address is taken.
  Aux: @0x1  References:
  Referring: _ZTV1B/6 (addr)
  Function flags: body
  Called by:
  Calls: void operator delete(void*)/5 (1.00 per call) _ZN1BD1Ev/3 (1.00 per
call) (can throw external)

Backend believe that every function with body defined can actually be inlined
(or there is no point to pass it down from FE at first place).
I wonder how C++ ends up with two different visibilities for these - B seems
keyed by the virtual function it defines, but why the destructor is not keyed
then as well?

[Bug tree-optimization/58656] [4.9 Regression] rnflow regressing after r202826

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Keywords||missed-optimization
   Last reconfirmed||2013-10-10
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Blocks||58464
 Ever confirmed|0   |1
Summary|rnflow regressing after |[4.9 Regression] rnflow
   |r202826 |regressing after r202826
   Target Milestone|--- |4.9.0

--- Comment #1 from Richard Biener  ---
I will have a look next week.  The patch was supposed to not have any effect
on code generation.

[Bug c++/58610] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr of class with template constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P5
   Target Milestone|--- |4.7.4

[Bug c++/58609] [4.9 Regression] [c++11] ICE with uninitialized variable in constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c++/58607] [4.9 Regression] [c++11] ICE with undeclared variable in constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug target/58603] [4.9 Regression] hash-table.h:962: error: anachronistic old-style base class initia

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|regression  |target
   Target Milestone|--- |4.9.0

[Bug c++/58606] [4.8/4.9 Regression] [c++11] ICE with specialization in variadic template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug c++/58596] [4.8/4.9 Regression] [c++11] ICE with decltype in non-static data member initializer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug c++/58613] [4.9 Regression] [c++1y] ICE with invalid lambda capture

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c++/58611] [4.7/4.8/4.9 Regression] [c++11] ICE with invalid constexpr constructor used in array initialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P5
   Target Milestone|--- |4.7.4

[Bug c++/58612] [4.8/4.9 Regression] [c++11] ICE calling non-constexpr from constexpr in template class

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug c++/58632] [4.8/4.9 Regression] ICE reusing template parameter name as class name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-10
 CC||hubicka at gcc dot gnu.org
  Component|c++ |middle-end
Summary|gcc internal compiler   |gcc internal compiler
   |error: Segmentaion fault|error: Segmentaion fault in
   ||insert_to_assembler_name_ha
   ||sh
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.  Also happens on trunk.

t.C: In function 'std::unique_ptr >& _ZTWN1AIT_E1sE()':
t.C:10:7: internal compiler error: Segmentation fault
  if (!s) {
   ^
0xc67bdd crash_signal
/space/rguenther/src/svn/gcc-4_8-branch/gcc/toplev.c:332
0x563d74 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/space/rguenther/src/svn/gcc-4_8-branch/gcc/tree.h:3893
0xea90f1 decl_assembler_name_hash(tree_node const*)
/space/rguenther/src/svn/gcc-4_8-branch/gcc/tree.c:601
0x89636a insert_to_assembler_name_hash
/space/rguenther/src/svn/gcc-4_8-branch/gcc/symtab.c:118
0x89661a symtab_register_node(symtab_node_def*)
/space/rguenther/src/svn/gcc-4_8-branch/gcc/symtab.c:199
0xf0c8c5 varpool_node_for_decl(tree_node*)
/space/rguenther/src/svn/gcc-4_8-branch/gcc/varpool.c:52

[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug target/58630] [4.9 Regression] Revision 203171 breaks several MS-ABI tests

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c/58626] [4.9 Regression] possible array wrong code bug

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|possible array wrong code   |[4.9 Regression] possible
   |bug |array wrong code bug

--- Comment #2 from Richard Biener  ---
Mine.

[Bug c++/58636] [4.7/4.8/4.9 Regression] ICE with initializer_list and rvalue references

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P5
   Target Milestone|--- |4.7.4

[Bug c++/58633] [4.7/4.8/4.9 Regression] ICE with decltype of destructor call

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug middle-end/58677] wrong code at -O1 on x86_64-linux-gnu

[mikpelinux at gmail dot com]

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

--- Comment #1 from Mikael Pettersson  ---
Started with r202525 (PR58404 missed-optimization fix), stopped with r203315
(PR58570 wrong-code fix).  The cause of PR58570 was not r202525.

Can you check if the original testcase works on current trunk?

[Bug c++/58649] [4.7/4.8/4.9 Regression] ICE with use of enum before declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P5
   Target Milestone|--- |4.7.4

[Bug c++/58647] [4.7/4.8/4.9 Regression] ICE with function pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug c++/58651] [4.7/4.8/4.9 Regression] ICE with invalid initializer list

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug tree-optimization/58653] [4.7/4.8/4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu in 64-bit mode (affecting gcc 4.6 to trunk)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.3.4
   Target Milestone|--- |4.7.4

[Bug target/58641] [4.9 Regression] FAIL: gcc.target/i386/pr49002-2.c scan-assembler vmovapd[\t ]*%ymm[0-9]+,[^,]*

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/58640] [4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.9.0
Summary|wrong code (segfaults) at   |[4.9 Regression] wrong code
   |-O3 on x86_64-linux-gnu |(segfaults) at -O3 on
   ||x86_64-linux-gnu

[Bug c++/58639] [4.7/4.8/4.9 Regression] ICE on self-referential struct member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4
Summary|ICE on self-referential |[4.7/4.8/4.9 Regression]
   |struct member   |ICE on self-referential
   ||struct member

[Bug target/57377] compiler cannot be built with RTL checking

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Oct 10 12:01:23 2013
New Revision: 203353

URL: http://gcc.gnu.org/viewcvs?rev=203353&root=gcc&view=rev
Log:
2013-10-10  Andreas Krebbel  

PR target/57377
* gensupport.c (gen_mnemonic_attr): Handle (set (attr x) y) and
(set_attr_alternative x ...) when searching for user defined
mnemonic attribute.


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

[Bug c++/58674] [4.8/4.9 Regression] [c++11] ICE with template using declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P5
   Target Milestone|--- |4.8.2

[Bug middle-end/58677] wrong code at -O1 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
(In reply to Mikael Pettersson from comment #1)
> Started with r202525 (PR58404 missed-optimization fix), stopped with r203315
> (PR58570 wrong-code fix).  The cause of PR58570 was not r202525.
> 
> Can you check if the original testcase works on current trunk?

But r202525 will expose more opportunities for the code with the bug
that was fixed by r203315 so it makes sense.

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

[Bug middle-end/58570] [4.9 Regression] wrong code for bitfields at -O2 and above

[rguenth at gcc dot gnu.org]

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

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

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/58654] [4.9 Regression] ICE: abort compiling libstdc++-v3/src/c ++98/sstream-inst.cc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/58662] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I will have a looksee.

[Bug c++/31671] Non-type template of type const ref accepted as a non-const ref

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|gcc-bugs at gcc dot gnu.org|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0
  Known to fail||

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug c++/58525] __cxa_throw_bad_array_new_length is generated with -fno-exceptions

[aivchenk at gmail dot com]

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

--- Comment #3 from Alexander Ivchenko  ---
thanks. I have sent it to gcc-paches:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00402.html

[Bug tree-optimization/58656] [4.9 Regression] rnflow regressing after r202826

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
cptrf2 shows

   :
-  pretmp_278 = (integer(kind=8)) ival2_72;
-  pretmp_279 = pretmp_278 + -1;
-  pretmp_280 = *xxtrt_23(D)[pretmp_279];

   :
   # ival2_130 = PHI 
   # ival2_134 = PHI 
-  # prephitmp_281 = PHI 
   _131 = (integer(kind=8)) ival2_130;
   _132 = _131 + -1;
   _133 = *xxtrt_23(D)[_132];
   _135 = (integer(kind=8)) ival2_134;
   _136 = _135 + -1;
-  _137 = prephitmp_281;
+  _137 = *xxtrt_23(D)[_136];
   if (_133 < _137)
 goto ;
   else

gentrs has a difference as well.  It's partial-PRE results differing
(we don't have many partial-PRE testcases).

The reason for the difference is likely "failed" translations which are
cached over insert iterations.  I have a patch.

[Bug fortran/58676] Intrinsic functions not considered pure actual arguments

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-10
 CC||burnus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
Actually, another PR related to this issue is PR58099, which has a patch:
PR58099 comment 18.

That matches the obvious patch which I also just came up with. (I wonder
whether we have to take care whether a specific function exists or not; but
that might be already handled.)

[Bug tree-optimization/58662] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
It looks like changing the testcase line

  d = foo (a == 0, (0, 35536)); 

to

  d = foo (a == 0, -3);  

fixes it.  _No_ IL difference in 065t.mergephi2, but then 066t.vrp1 has

 main ()
 {
   char e;
@@ -39,6 +35,7 @@
   _Bool _4;
   int _5;
   int _7;
+  int c.4_9;
   int b.5_11;
   int _12;

@@ -46,22 +43,37 @@
   a.0_3 = a;
   _4 = a.0_3 == 0;
   _5 = (int) _4;
-  _12 = 0;
-  d = 0;
-  _7 = 0;
-  e_8 = 0;
-  iftmp.3_1 = 0;
-  b ={v} 0;
-  b.5_11 ={v} b;
-  if (b.5_11 != 0)
+  _12 = _5 / -3;
+  d = _12;
+  _7 = _12 % 14;
+  e_8 = (char) _7;
+  if (_7 != 0)
 goto ;
   else
 goto ;

   :
-  abort ();
+  c.4_9 = c;
+  if (c.4_9 != 0)
+goto ;
+  else
+goto ;

   :
+
+  :
+  # iftmp.3_1 = PHI <1(3), 0(4)>
+  b ={v} iftmp.3_1;
+  b.5_11 ={v} b;
+  if (b.5_11 != 0)
+goto ;
+  else
+goto ;
+
+  :
+  abort ();
+
+  :
   return 0;

 }

what?!

Reduced testcase:

extern void abort (void);

int a, c, d;
volatile int b;

static int
foo (int p1, short p2)
{
  return p1 / p2;
}

int
main ()
{
  char e;
  d = foo (a == 0, (0, 35536)); 
  e = d % 14;
  b = e && c;
  if (b != 0)
abort ();
  return 0;
}

[Bug gcov-profile/58682] New: Profiling directed optimization doesn't play well with indirect inlining

[pa...@matos-sorge.com]

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

Bug ID: 58682
   Summary: Profiling directed optimization doesn't play well with
indirect inlining
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pa...@matos-sorge.com

Created attachment 30976
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30976&action=edit
Profiling files and preprocessed file resulting in ICE

Unzip the attachment and running cc1 from head of 4_8 branch I get:
(5) $ /home/pmatos/work/tmp/GCC/builds/gcc-4_8/gcc/cc1 -fpreprocessed
core_list_join.i -quiet -dumpbase core_list_join.c -auxbase core_list_join -g3
-O2 -version -fprofile-use=profile_all.fpexe -o core_list_join.s
GNU C (GCC) version 4.8.2 20131010 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 4.3.0, MPFR version 2.4.1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.8.2 20131010 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 4.3.0, MPFR version 2.4.1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 76572ada0801d80f2ac370ed86237f71
core_list_join.c:525:1: internal compiler error: in edge_badness, at
ipa-inline.c:895
0xc7c61f edge_badness
../../../gcc-4_8/gcc/ipa-inline.c:895
0xc7e82d add_new_edges_to_heap
../../../gcc-4_8/gcc/ipa-inline.c:1385
0xc7fcb3 inline_small_functions
../../../gcc-4_8/gcc/ipa-inline.c:1615
0xc7fcb3 ipa_inline
../../../gcc-4_8/gcc/ipa-inline.c:1794
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

This was obtained while running a few coremark tests.

[Bug rtl-optimization/58662] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|tree-optimization   |rtl-optimization
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
Summary|wrong code at -O2 and -O3   |[4.9 Regression] wrong code
   |on x86_64-linux-gnu (in |at -O2 and -O3 on
   |64-bit mode)|x86_64-linux-gnu (in 64-bit
   ||mode)

--- Comment #6 from Richard Biener  ---
Doesn't fail with -O2 -fno-tree-vrp.

The uncprop transform is correct.

  _7 = _12 % 14;
  if (_7 != 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  c.4_9 = c;
  _8 = c.4_9 != 0;
  _13 = (int) _8;

  :
  iftmp.3_1 = PHI <_7(7), _13(3)>

we know that _7 is zero on the edge from BB 7.

What we now do is coalesce iftmp.3_1 with both _7 and _13 with also seems
correct.  The initial RTL generated looks ok as well:

(insn 25 24 26 2 (parallel [
(set (reg:SI 83 [ D.1762 ])
(minus:SI (reg:SI 90 [ D.1762 ])
(reg:SI 106)))
(clobber (reg:CC 17 flags))
]) t.c:17 296 {*subsi_1}
 (nil))
(insn 26 25 27 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 83 [ D.1762 ])
(const_int 0 [0]))) t.c:18 3 {*cmpsi_ccno_1}
 (nil))
(jump_insn 27 26 28 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 33)
(pc))) t.c:18 616 {*jcc_1}
 (int_list:REG_BR_PROB 5000 (nil))
 -> 33)

;;  succ:   4 [50.0%]  (FALLTHRU)
;;  5 [50.0%]

;; basic block 4, loop depth 0, count 0, freq 5000
;;  prev block 2, next block 5, flags: (NEW, REACHABLE, RTL)
;;  pred:   2 [50.0%]  (FALLTHRU)
...
(insn 32 31 33 4 (set (reg:SI 83 [ D.1762 ])
(reg:SI 107 [ D.1763 ])) t.c:18 86 {*movsi_internal}
 (nil))
;;  succ:   5 [100.0%]  (FALLTHRU)

;; basic block 5, loop depth 0, count 0, freq 1, maybe hot
;;  prev block 4, next block 6, flags: (NEW, REACHABLE, RTL)
;;  pred:   2 [50.0%]
;;  4 [100.0%]  (FALLTHRU)
(code_label 33 32 34 5 2 "" [1 uses])
(note 34 33 35 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 35 34 36 5 (set (mem/v/c:SI (symbol_ref:DI ("b")  ) [2 b+0 S4 A32])
(reg:SI 83 [ D.1762 ])) t.c:18 86 {*movsi_internal}
 (nil))

it is combine where mysteriously all defining instructions for reg:SI 83
vanish.  Not mine.

[Bug gcov-profile/58682] Profiling directed optimization doesn't play well with indirect inlining

[pa...@matos-sorge.com]

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

Paulo J. Matos  changed:

   What|Removed |Added

 CC||pa...@matos-sorge.com

--- Comment #1 from Paulo J. Matos  ---
I am not sure if the bug component is correctly set. Please change otherwise.

[Bug gcov-profile/58682] Profiling directed optimization doesn't play well with indirect inlining

[pa...@matos-sorge.com]

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

--- Comment #2 from Paulo J. Matos  ---
Here's my reading of the problem:

core_bench_list calls core_list_mergesort which indirectly (through a function
pointer) calls cmp_idx. The global max_count variable is updated in the
beginning of inline_small_functions, but later we inline core_list_mergesort
into core_bench_list which adds cmp_idx to the list of callees of
core_list_mergesort generating this cgraph_node:
core_list_mergesort/32 (core_list_mergesort) @0x2b97efed8378
  Type: function
  Visibility: public
  References: 
  Referring: 
  Function core_list_mergesort/32 is inline copy in core_bench_list/4
  Clone of core_list_mergesort/11
  Availability: local
  Function flags: analyzed executed 2x body local finalized
  Called by: core_bench_list/4 (2x) (1.00 per call) (inlined) 
  Calls: cmp_idx/2 (indirect_inlining) (217x) (100.00 per call)

Now there is an edge (core_list_mergesort -> cmp_idx) whose count is higher
(217) than the max_count global variable. This causes an ICE in edge_badness
which has the assertion (max_count >= edge_count).

[Bug rtl-optimization/58662] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #5)
> It looks like changing the testcase line
> 
>   d = foo (a == 0, (0, 35536)); 
> 
> to
> 
>   d = foo (a == 0, -3);  
> 
> fixes it.  _No_ IL difference in 065t.mergephi2, but then 066t.vrp1 has
> 
>  main ()
>  {
>char e;
> @@ -39,6 +35,7 @@
>_Bool _4;
>int _5;
>int _7;
> +  int c.4_9;
>int b.5_11;
>int _12;
>  
> @@ -46,22 +43,37 @@
>a.0_3 = a;
>_4 = a.0_3 == 0;
>_5 = (int) _4;
> -  _12 = 0;
> -  d = 0;
> -  _7 = 0;
> -  e_8 = 0;
> -  iftmp.3_1 = 0;
> -  b ={v} 0;
> -  b.5_11 ={v} b;
> -  if (b.5_11 != 0)
> +  _12 = _5 / -3;
> +  d = _12;
> +  _7 = _12 % 14;
> +  e_8 = (char) _7;
> +  if (_7 != 0)
>  goto ;
>else
>  goto ;
>  
>:
> -  abort ();
> +  c.4_9 = c;
> +  if (c.4_9 != 0)
> +goto ;
> +  else
> +goto ;
>  
>:
> +
> +  :
> +  # iftmp.3_1 = PHI <1(3), 0(4)>
> +  b ={v} iftmp.3_1;
> +  b.5_11 ={v} b;
> +  if (b.5_11 != 0)
> +goto ;
> +  else
> +goto ;
> +
> +  :
> +  abort ();
> +
> +  :
>return 0;
>  
>  }
> 
> what?!

That's because there _is_ a IL difference.  With (0, 35536) the
-3 tree constant has TREE_OVERFLOW set while with literal
-3 in the source it does not.

Due to VRP relying on some fold-const.c overflow detection with
TREE_OVERFLOW this effect is to be expected.

[but in reality GIMPLE should not have any TREE_OVERFLOW constants
in the IL, though that's hard to avoid]

[Bug tree-optimization/58656] [4.9 Regression] rnflow regressing after r202826

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 10 14:07:19 2013
New Revision: 203377

URL: http://gcc.gnu.org/viewcvs?rev=203377&root=gcc&view=rev
Log:
2013-10-10  Richard Biener  

PR tree-optimization/58656
* tree-ssa-pre.c (phi_translate): Do not cache failed
translations.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)

[rguenth at gcc dot gnu.org]

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

Bug 58464 depends on bug 58656, which changed state.

Bug 58656 Summary: [4.9 Regression] rnflow regressing after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58656

   What|Removed |Added

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

[Bug tree-optimization/58656] [4.9 Regression] rnflow regressing after r202826

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/58683] New: Internal compiler error: Segmentation fault compiling Cilk Plus code with -ftree-vectorizer-verbose=1

[neboat16 at gmail dot com]

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

Bug ID: 58683
   Summary: Internal compiler error: Segmentation fault compiling
Cilk Plus code with -ftree-vectorizer-verbose=1
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neboat16 at gmail dot com

Created attachment 30977
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30977&action=edit
Preprocessed file for Cilk Plus matrix multiplication code.

When compiling some matrix-multiplication Cilk Plus code using the cilkplus
branch of GCC (checked out of the git repository on 2013-10-09), I receive the
following internal compiler error.

$ gcc -O3 -ffast-math -std=c99 -W -Wall -Werror -fcilkplus   
mm_dac_coarsen_transpose.c  -lcilkrts -ldl -o mm_dac_coarsen_transpose
-ftree-vectorizer-verbose=1
mm_dac_coarsen_transpose.c: In function ‘mmbase’:
mm_dac_coarsen_transpose.c:27:6: internal compiler error: Segmentation fault
 void mmbase (double *restrict C, double *restrict A, double *restrict B) {
  ^
0x915bbf crash_signal
../../gcc-src/gcc/toplev.c:334
0xacc9a6 vect_analyze_scalar_cycles_1
../../gcc-src/gcc/tree-vect-loop.c:762
0xacf68d vect_analyze_scalar_cycles
../../gcc-src/gcc/tree-vect-loop.c:855
0xacf68d vect_analyze_loop_2
../../gcc-src/gcc/tree-vect-loop.c:1848
0xacf68d vect_analyze_loop(loop*)
../../gcc-src/gcc/tree-vect-loop.c:2006
0xae43dc vectorize_loops()
../../gcc-src/gcc/tree-vectorizer.c:114
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

This compiler error does not occur if I exclude "-ftree-vectorizer-verbose=1"
from the command line.

Attached is the preprocessed file mm_dac_coarsen_transpose.i.  Below is some
system information about GCC.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/neboat/bin/gcc/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-src/configure --prefix=/home/neboat/bin/gcc-obj/../gcc
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.0 20130520 (experimental) (GCC)

[Bug rtl-optimization/58662] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
It even doesn't compile for me:

eric@polaris:~/build/gcc/native> gcc/xgcc -Bgcc -o pr58662 pr58662.c -O2
pr58662.c: In function 'main':
pr58662.c:22:1: internal compiler error: RTL check: expected elt 4 type 'e' or
'u', have '0' (rtx note) in distribute_notes, at combine.c:13422
 }
 ^
0x9c1113 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/home/eric/svn/gcc/gcc/rtl.c:764
0x10f0be1 distribute_notes
/home/eric/svn/gcc/gcc/combine.c:13422
0x1119f9b try_combine
/home/eric/svn/gcc/gcc/combine.c:4131
0x112487e combine_instructions
/home/eric/svn/gcc/gcc/combine.c:1390
0x112487e rest_of_handle_combine
/home/eric/svn/gcc/gcc/combine.c:13841
0x112487e execute
/home/eric/svn/gcc/gcc/combine.c:13884
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug gcov-profile/58682] Profiling directed optimization doesn't play well with indirect inlining

[pa...@matos-sorge.com]

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

--- Comment #3 from Paulo J. Matos  ---
I have now a fix for this. I will prepare a patch for gcc-patches.

[Bug middle-end/58677] wrong code at -O1 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #3 from Zhendong Su  ---
(In reply to Mikael Pettersson from comment #1)
> Started with r202525 (PR58404 missed-optimization fix), stopped with r203315
> (PR58570 wrong-code fix).  The cause of PR58570 was not r202525.
> 
> Can you check if the original testcase works on current trunk?

Just checked; it works. Thanks.

[Bug middle-end/58670] asm goto miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Oct 10 16:29:50 2013
New Revision: 203383

URL: http://gcc.gnu.org/viewcvs?rev=203383&root=gcc&view=rev
Log:
PR middle-end/58670
* stmt.c (expand_asm_operands): Add FALLTHRU_BB argument,
if any labels are in FALLTHRU_BB, use a special label emitted
immediately after the asm goto insn rather than label_rtx
of the LABEL_DECL.
(expand_asm_stmt): Adjust caller.
* cfgrtl.c (commit_one_edge_insertion): Force splitting of
edge if the last insn in predecessor is a jump with single successor,
but it isn't simplejump_p.

* gcc.dg/torture/pr58670.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr58670.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgrtl.c
trunk/gcc/stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/58684] New: powerpc uses only unordered floating-point compares

[jsm28 at gcc dot gnu.org]

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

Bug ID: 58684
   Summary: powerpc uses only unordered floating-point compares
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
Target: powerpc*-*

When compiling for powerpc (classic hard-float), floating-point compares always
use the fcmpu instructions that don't raise exceptions for unordered operands,
never the exception-raising fcmpo variants.  The correct behavior is to raise
exceptions for comparisons such as "x < y", but not for "x == y" or
"__builtin_isless (x, y)".

[Bug middle-end/58670] asm goto miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Oct 10 16:39:52 2013
New Revision: 203384

URL: http://gcc.gnu.org/viewcvs?rev=203384&root=gcc&view=rev
Log:
PR middle-end/58670
* stmt.c (expand_asm_operands): Add FALLTHRU_BB argument,
if any labels are in FALLTHRU_BB, use a special label emitted
immediately after the asm goto insn rather than label_rtx
of the LABEL_DECL.
(expand_asm_stmt): Adjust caller.
* cfgrtl.c (commit_one_edge_insertion): Force splitting of
edge if the last insn in predecessor is a jump with single successor,
but it isn't simplejump_p.

* gcc.dg/torture/pr58670.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58670.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/cfgrtl.c
branches/gcc-4_8-branch/gcc/stmt.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/58680] Spurious warnings from libasan

[tetra2005 at gmail dot com]

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

--- Comment #2 from Yuri Gribov  ---
/* Answering from my personal account */

According to http://marc.info/?t=13645834152 this may not be a problem for
Android. It seems that NDK links shared libs with -Bsymbolic which should
prevent interpositions like this. Haven't verified this though, no Android
device at hand...

-Y

[Bug tree-optimization/58640] [4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-10
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #2 from Jeffrey A. Law  ---
I'm looking at it.  Not sure if the jump threading is wrong or just exposing a
problem elsewhere.  I certainly do see the fault though.

[Bug fortran/58226] negative subscript pos at fortran/options.c:1205

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #6 from Tobias Burnus  ---
FIXED on the trunk (4.9). Thanks for the report!

(In reply to Vittorio Zecca from comment #4)
> I could not reproduce the issue with version 4.8.2 20130920, probably
> it has silently been fixed sometime in the past.

Well, it hasn't but more and more targets do have a by default some compiler
options. And in that case, there is no segfault.

[Bug fortran/58226] negative subscript pos at fortran/options.c:1205

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
Author: burnus
Date: Thu Oct 10 19:32:22 2013
New Revision: 203394

URL: http://gcc.gnu.org/viewcvs?rev=203394&root=gcc&view=rev
Log:
2013-10-09  Tobias Burnus  

PR fortran/58226
* options.c (gfc_get_option_string): Handle zero arg case.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c

[Bug tree-optimization/58640] [4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
May be related to trying to thread through 2 loop headers.  ie,we're starting
the jump thread path outside any loops.  On the jump thread path we find a loop
header, then the loop header for a nested loop.  The updating code knows how to
handle threading through a single loop header in a specific set of conditions,
but I'm pretty sure it's not prepared to handle threading through a nest of
headers.

I'm still investigating.

[Bug c++/10200] Weird clash with same names in different scopes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|gcc-bugs at gcc dot gnu.org|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #23 from Paolo Carlini  ---
Mine.

[Bug tree-optimization/58640] [4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
We're ending up with latches from two different loops going to the same
destination due to the jump thread path passing through multiple loops.  This
ultimately causes the unroller to go nuts.

This should be fairly easy to catch & avoid.  And this brings to the forefront
a question that's been slowly building in the back of my mind.

Specifically, given a jump threading path, we have the ability now to lop off
the tail of the path if threading all the way to the tail would ultimately
force cancellation of the jump thread request.  Lopping off the tail may result
in better code than totally cancelling the request.  This testcase is a good
example.

Anyway, I'll be pondering how we want to deal with that as well.

[Bug tree-optimization/19831] Missing DSE/malloc/free optimization

[glisse at gcc dot gnu.org]

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

--- Comment #15 from Marc Glisse  ---
See the discussion that starts at:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130923/188747.html

(it continues in the following weeks) for optimization 2 of comment #14 in
clang. The key idea is that if, in the function where malloc is called, we can
check that on all paths (including EH) to the exit of the function free is
called on the return value of malloc, then we can replace malloc and all the
corresponding free with a stack allocation (whether we want to, depending on
the size, is a different issue). Of course there are some details like: if we
test whether malloc returned 0, that's one branch where we don't need free,
etc.

Also, the optimization can make a crash happen much earlier:
p=malloc(n);fun(p);free(p);
where fun calls free, would normally fail in the second free (double-free) and
will instead fail in fun (free of a pointer to the stack). I think that's fine,
but people may be surprised if there are a lot of side-effects (I/O for
instance) between the 2 free.

The hardest part here is deciding whether we always reach a free (this is how
we prove that there is no hidden call to realloc/free). There could be an
infinite loop in between. Any function we call might itself have an infinite
loop or call exit. And worst of all, there might be a call to longjmp. That
seems to make it impossible to perform the optimization when there is a
function call, in all but the most contrived cases (a call to setjmp between
malloc and the function call, or in C++ if the EH landing pad for the call
contains a non-inlined call to a non-trivial destructor).

So to make this possible, the first thing to do seems to forbid longjmp:
-fno-longjmp.

But even then it is still hard to know if regular functions always return
(infinite loops, exit). There are *LOOPING_CONST_OR_PURE* flags in gcc (and a
hardcoded list of builtins in call_may_noreturn_p), we could generalize them to
a may_not_return / always_returns flag (and associated attribute), that gcc
could recursively infer on many functions (a similar no_longjmp flag could also
be added to avoid the need for -fno-longjmp). I think this is the most
promising direction.

Assuming that we never do the things that would break the optimization (call
realloc or free in a function that won't return) seems too complicated to
explain properly, so I wouldn't even propose a -fI-promise-it-is-ok.

[Bug tree-optimization/58685] New: wrong code at -Os on x86_64-linux-gnu in 64-bit mode (affecting gcc trunk, 4.8, and 4.7)

[su at cs dot ucdavis.edu]

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

Bug ID: 58685
   Summary: wrong code at -Os on x86_64-linux-gnu in 64-bit mode
(affecting gcc trunk, 4.8, and 4.7)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk (as well as 4.7 and 4.8) miscompiles the following code
on x86_64-linux at -Os in 64-bit mode. 

This is a regression from 4.6.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--enable-checking=release --with-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131010 (experimental) [trunk revision 203390] (GCC) 
$ 
$ gcc-trunk -m64 -O1 small.c; a.out
$ gcc-trunk -m64 -O2 small.c; a.out
$ gcc-trunk -m32 -Os small.c; a.out
$ gcc-4.6 -m64 -Os small.c; a.out
$ 
$ gcc-trunk -m64 -Os small.c; a.out
a.out: :1564818584: H?l$?L?d$?H?-? : Assertion `' failed.
Aborted (core dumped)
$ gcc-4.8 -m64 -Os small.c; a.out
a.out: :2138443464: H?l$?L?d$?H?-? : Assertion `' failed.
Aborted (core dumped)
$ gcc-4.7 -m64 -Os small.c; a.out
a.out: :1796453480: H?l$?L?d$?H?-? : Assertion `' failed.
Aborted (core dumped)
$


-

int a, b, c = 1, d, e;
int *f = &e, *g = &e, *i;

void __assert_fail (char *);

void
fn1 ()
{
  if (a)
i = 0;
}

int
fn2 ()
{
  0 ? (void) 0 : __assert_fail ("");
  for (; d;)
;
  return 0;
}

int
fn3 (int *p1)
{
  for (b = 0; b >= 0; b--)
{
  int *h = &e;
  *h = 0;
  if (*p1)
continue;
  e = 1;
}
  fn1 ();
  c ? (void) 0 : __assert_fail ("");
  return 0;
}

int
main ()
{
  fn3 (g);
  fn3 (g);
  if (*f);
  else
0 ? (void) 0 : __assert_fail ("");
  return 0;
}

[Bug target/58673] ICE in final_scan_insn for movti_ppc64 with base+offset address

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-10-11
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/58673] ICE in final_scan_insn for movti_ppc64 with base+offset address

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 30978
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30978&action=edit
Patch to fix interaction between -mquad-memory and -mno-vsx-timode

The problem is an interaction between -mquad-memory and -mno-vsx-timode.  The
non-VSX case for 64-bit TImode moves did not support load/store quad.  When
TImode in VSX registers was disabled, the instruction emitted thought it needed
to split the load/store, but the instruction splitter would not split the insn
because it could be done by a single instruction.

Some of these changes will be changed eventually when I finish up the secondary
reload changes I am working on.  These patches are a band-aid until the full
secondary reload support is installed.

[Bug tree-optimization/58686] New: [BUG] vect_get_loop_niters() cound not get the correct result for some loops.

[congh at google dot com]

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

Bug ID: 58686
   Summary: [BUG] vect_get_loop_niters() cound not get the correct
result for some loops.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: congh at google dot com

Look at the following loop:


  unsigned int t = ...;
  do {
...
t -= 4;
  } while (t >= 5);


When I tried to get the iteration number of this loop as an expression using
vect_get_loop_niters(), it gave me the result "scev_not_known". If I changed
the type of t into signed int, then I can get the result as below: 


t > 4 ? ((unsigned int) t + 4294967291) / 4 : 0


But even when t is unsigned, we should still get the result as:


t != 4 ? (t + 4294967291) / 4 : 0


I spent some time on tracking the reason why it failed to do so, and then
reached the function assert_loop_rolls_lt(), in which the assumptions are built
to make sure we can get the iteration number from the following formula:


(iv1->base - iv0->base + step - 1) / step


In the example above, iv1->base is t-4, iv0->base is 4 (t>=5 is t>4), and step
is 4. This formula works only if


-step + 1 <= (iv1->base - iv0->base) <= MAX - step + 1

(MAX is the maximum value of the unsigned variant of type of t, and in this
formula we don't have to take care of overflow.)


I think when (iv1->base - iv0->base) < -step + 1, then we can assume the number
of times the back edge is taken is 0, and that is how niter->may_be_zero is
built in this function. And niter->assumptions is built based on (iv1->base -
iv0->base) <= MAX - step + 1. Note that we can only get the iteration number of
the loop if niter->assumptions is always evaluated as true.

However, I found that the build of niter->assumptions does not involve both
iv1->base and iv0->base, but only one of them. I think this is possibly a
potential bug.

Further, the reason why we can get the iteration number if t is of unsigned int
type is that niter->assumptions built here t-4 < MAX-3 is evaluated to true, by
taking advantage of the fact that the overflow on signed int is undefined (so
t-4 < MAX-3 can be converted to t < MAX+1, where MAX+1 is assumed to not
overflow). But this is not working for unsigned int.

One more problem is the way how niter->may_be_zero is built. For the loop
above, niter->may_be_zero I got is 4 > t - 4 - (-4 + 1), but we should make
sure t-4 here does not overflow. Otherwise niter->may_be_zero is invalid. I
think the function assert_loop_rolls_lt() should take care more of unsigned int
types.

With this issue we cannot vectorize this loop as its iteration number is
unknown.


Thank you!

Cong

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[jjcogliati-r1 at yahoo dot com]

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

Joshua Cogliati  changed:

   What|Removed |Added

  Attachment #30899|0   |1
is obsolete||

--- Comment #22 from Joshua Cogliati  ---
Created attachment 30979
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30979&action=edit
Patch to add -Wfloat-conversion option against trunk

This version only does the -Wfloat-conversion.  It does not do the -Wextra or
the changes needed to get -Wextra to bootstrap.  It starts to change the test
cases.  This work is to satisfy the request on the gcc-patch list.

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[jjcogliati-r1 at yahoo dot com]

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

--- Comment #23 from Joshua Cogliati  ---
Created attachment 30980
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30980&action=edit
Patch to fixup gcc float conversions in GCC

This changes the float conversions in gcc so that gcc bootstraps if float
conversions are warned about with -Wextra.  Splitting the patch was requested
on gcc-patches.


(Note to self: patches were created with 
svn diff --diff-cmd diff -x -up
)

[Bug tree-optimization/58640] [4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
Fix going through bootstrap and regression testing.

[Bug preprocessor/58687] New: "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

Bug ID: 58687
   Summary: "#line __LINE__ ..." changes subsequent line numbers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtewoodbury at gmail dot com

A preprocessor directive of the form '#line __LINE__ ..." should NOT change the
line number.  That is '__LINE__' should evaluate to the number of the NEXT line
in this context.

If you read the standards carefully, __LINE__ should have a value equal to the
number of 'new line' characters seen by the phaee 1 translation plus one WHEN
THE SUBSTITUTION OCCURS (unless modified by previous #line directives).

When the subsituyion occurs is controlled by the parsing done in phase 4 of
translation.  Specifically, subsitution in preprocessing directives occure when
the specific form of the directive has been  formally identified AND that form
calls for  aubstitution.  The form in this case is:

'#' 'line' + 

Note that the terminating  token has to have been seen BEFORE the
form is identifiad.  That means __LINE__ will normally have the line number of
the NEXT line in the file when the substitution occurs.  FURTHER NOTE that any
 tokens in comments will also have been counted when the substiturion
occurs.

What is apparently happening instead is that the substitution is being made
BEFORE the particular form of the '#line' directive has been completely and
formally identified.  In other wordds you have folded the translation phases
togeather and botched up the carefully structured procedure with its
intentional delays in substitution set forth in the standard.