[Bug ada/62117] function taking System.Address wrongly considered pure

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-02
Summary|[4.9 regression] wrong code |function taking
   |for passing small array |System.Address wrongly
   |argument'Address, in|considered pure
   |generic |
 Ever confirmed|0   |1

--- Comment #4 from Eric Botcazou  ---
> Which of those is correct, the document or the behaviour of compiler?

The documentation, this looks like an oversight in the implementation.

[Bug target/64893] [5 Regression] ICE while doing a bootstrap with the latest compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Here is the "unincluded" version of the code:
#include 
int
search_line_fast (uint32x2_t t)
{
  return vget_lane_u32 (t, 0);
}

[Bug target/64893] [5 Regression] ICE while doing a bootstrap with the latest compiler

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-02-02
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
My patch works so I am going to bootstrap/test it.

[Bug target/64893] [5 Regression] ICE while doing a bootstrap with the latest compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 34642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34642&action=edit
The patch which fixes the C++ failure (but does not include a testcase yet)

[Bug target/64897] Floating-point "and" not optimized on x86-64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We expand from

fand1 (double x)
{
  long unsigned int _2;
  long unsigned int ix.1_4;

  :
  _2 = VIEW_CONVERT_EXPR(x_5(D));
  ix.1_4 = _2 & 9223372036854775807;
  x_3 = VIEW_CONVERT_EXPR(ix.1_4);
  return x_3;

so the issue might be as "simple" as that GIMPLE doesn't allow bit operations
on FP operands.

Which makes it a RTL missed optimization (to (and:DF ...)):

(set (reg:DF 90 [  ])
(subreg:DF (and:DI (subreg:DI (reg/v:DF 91 [ x ]) 0)
(const_int 9223372036854775807 [0x7fff])) 0))

unless RTL has the same restriction.

And/or at target missed optimization in case it doesn't provide a AND
instruction
on DFmode (it doesn't as far as I can see).

[Bug ipa/64896] [5 Regression] ICE in get_address_mode, at rtlanal.c:5442

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug rtl-optimization/64756] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug target/64893] [5 Regression] ICE while doing a bootstrap with the latest compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/64884] [5 Regression] FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) on x86_64-apple-darwin*

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug target/64047] [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug c++/64898] New: [5 Regression] qtgui-4.8.6 build error

[trippels at gcc dot gnu.org]

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

Bug ID: 64898
   Summary: [5 Regression] qtgui-4.8.6 build error
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

qtgui-4.8.6 fails to build. During final libQtGui.so.4.8.6 link I get: 

.obj/release-shared/qdrawhelper_sse2.o: In function
`_Z33qt_fetch_radial_gradient_templateI16QRadialFetchSimdI9QSimdSse2EEPKjPjPK8OperatorPK9QSpanDataiii':
qdrawhelper_sse2.cpp:(.text._Z33qt_fetch_radial_gradient_templateI16QRadialFetchSimdI9QSimdSse2EEPKjPjPK8OperatorPK9QSpanDataiii[_Z33qt_fetch_radial_gradient_templateI16QRadialFetchSimdI9QSimdSse2EEPKjPjPK8OperatorPK9QSpanDataiii]+0x273):
undefined reference to `_Z12qt_memfill32'

markus@x4 test % cat qdrawhelper_sse2.ii
template 
void
qt_fetch_radial_gradient_template (int)
{
  extern void (*qt_memfill32)(int, int, int);
  qt_memfill32 (0, 0, 0);
}

void
qt_fetch_radial_gradient_sse2 ()
{
  qt_fetch_radial_gradient_template (0);
}

gcc-5 mangles the extern function to _Z12qt_memfill32.
All other compilers mangle it to qt_memfill32.

markus@x4 test % g++ -O2 -c qdrawhelper_sse2.ii
markus@x4 test % nm qdrawhelper_sse2.o | grep qt_memfill32
 U _Z12qt_memfill32
markus@x4 test % clang++ -O2 -c qdrawhelper_sse2.ii
markus@x4 test % nm qdrawhelper_sse2.o | grep qt_memfill32
 U qt_memfill32
markus@x4 test % icpc -O2 -c qdrawhelper_sse2.ii
markus@x4 test % nm qdrawhelper_sse2.o | grep qt_memfill32
 U qt_memfill32
markus@x4 test % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2/g++ -O2 -c
qdrawhelper_sse2.ii
markus@x4 test % nm qdrawhelper_sse2.o | grep qt_memfill32
 U qt_memfill32

[Bug c++/64898] [5 Regression] qtgui-4.8.6 build error

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
s/extern function/extern function pointer/

This is a variable of a function pointer type.

[Bug c++/64898] [5 Regression] qtgui-4.8.6 build error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |5.0

[Bug rtl-optimization/64756] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
No idea what this has to do with wide_int, I don't see any relation
(unfortunately my r210112 and r210113 copies are without debug info at this
point).
But, it really seems to be a CSE bug to me (during cse2).
The thing is, in insn 29 tmp is stored to using volatile store:
(insn 29 27 30 7 (set (mem/v/f/c:SI (symbol_ref:SI ("tmp")  ) [1 MEM[(int * volatile *)&tmp]+0 S4 A32])
(const_int 0 [0])) pr64756.c:19 90 {*movsi_internal}
 (nil))
but when the hash of dest is computed, we actually use:
  if (MEM_P (dest))
{
#ifdef PUSH_ROUNDING
  /* Stack pushes invalidate the stack pointer.  */
  rtx addr = XEXP (dest, 0);
  if (GET_RTX_CLASS (GET_CODE (addr)) == RTX_AUTOINC
  && XEXP (addr, 0) == stack_pointer_rtx)
invalidate (stack_pointer_rtx, VOIDmode);
#endif
  dest = fold_rtx (dest, insn);
}

  /* Compute the hash code of the destination now,
 before the effects of this instruction are recorded,
 since the register values used in the address computation
 are those before this instruction.  */
  sets[i].dest_hash = HASH (dest, mode);
and so dest is folded first into symbol_ref ("a").  That means when computing
hash we do not get do_not_record flag set, which we would otherwise get because
the memory is volatile, nor we do get the hash_arg_in_memory flag set.
Next we recompute the hash, but do not look at do_not_record anymore:
  if (sets[i].rtl != 0 && dest != SET_DEST (sets[i].rtl))
sets[i].dest_hash = HASH (SET_DEST (sets[i].rtl), mode);
Later on we insert this mem/v/f/c into the hash table and set the in_memory
flag (correctly):
elt->in_memory = (MEM_P (sets[i].inner_dest)
  && !MEM_READONLY_P (sets[i].inner_dest));
Later on merge_equiv_classes is called, and that one obviously doesn't count
with the option that do_not_record might be true, and when we set
do_not_record, we don't set hash_arg_in_memory, so we end up with a new elt
that for the MEM
at this time doesn't even have in_memory flag set, so when we later in insn 36
store into memory that aliases with this, we do not even invalidate it.

[Bug rtl-optimization/64756] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 34643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34643&action=edit
gcc5-pr64756.patch

I'd say we just should never record volatile MEMs into the hash table, this
patch attempts to ensure that.

[Bug c++/64898] [5 Regression] qtgui-4.8.6 build error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/64898] [5 Regression] qtgui-4.8.6 build error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r214396.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres  ---
In 17_intro/headers/c++*/all_attributes.cc, c++* stands for c++1998, c++200x,
and c++2014. The first instance is "fixed" now, the two other ones are still
failing.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #22 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #21)
> In 17_intro/headers/c++*/all_attributes.cc, c++* stands for c++1998,
> c++200x, and c++2014. The first instance is "fixed" now, the two other ones
> are still failing.

does my incremental patch fix that on Darwin14 - I can send it to you if cut &
paste mangled.

[Bug ipa/64896] [5 Regression] ICE in get_address_mode, at rtlanal.c:5442

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 34644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34644&action=edit
unreduced testcase

I'm having a hard time reducing the testcase.
Unreduced testcase attached.

[Bug libgcc/64885] libstdc++ all_attributes failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Note the UNUSED macro (whether function-like or not) certainly doesn't belong
to headers included from STL headers either.
It should have been __gthr_unused or something similar.

[Bug c++/64899] New: Illegal dynamic initialization

[wolfgang.roe...@gi-de.com]

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

Bug ID: 64899
   Summary: Illegal dynamic initialization
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wolfgang.roe...@gi-de.com

Hi,
I would like to post a bug report for the GNU C/C++ compiler 4.8.3.
We use the compiler to generate code for a PowerPC processor.

Invokation line for the GNU C++ compiler:

ccppc -c -x c++ -std=c++11 -Wall -Werror -g -mcpu=8540 -meabi
  -ftls-model=local-exec -msdata=sysv -fno-common -mspe -mabi=spe
  -mfloat-gprs=double -mbig -mmultiple -mno-string -misel -mstrict-align
  -fverbose-asm -fno-exceptions -fno-rtti -fgcse-sm -fno-section-anchors
  -ftemplate-backtrace-limit=20 -G 8 -O3
  -I
  -D
  X.CPP -oX.O


// file X.CPP

struct S
{
constexpr S ()
: m_ptrNext(nullptr)
, m_wait(true)
{}

S* m_ptrNext;
bool m_wait;
};



S s_Obj;
S s_Tab[2];



An inspection of the generated assembler file (see below) shows that only s_Obj
is statically initialized (constant initialization) whereas the array s_Tab[]
is dynamically initialized. (The dynamic initialization can be disastreous if
s_Tab[] is used for thread synchronisation.)

I think that both s_Obj and s_Tab[] should also be statically initialized since
S::S() is a constexpr constructor (C++11 standard, 3.6.2/2).


Following is the generated assembler file:

.section .text.startup,"ax",@progbits
.align 2
.type_GLOBAL__sub_I_s_Obj, @function
_GLOBAL__sub_I_s_Obj:<--- dynamic initialization of s_Tab[]
lis 10,s_Tab@ha   # tmp121,
li 7,0# tmp122,
la 9,s_Tab@l(10)  # tmp120,, tmp121
li 8,1# tmp125,
stw 7,s_Tab@l(10) # MEM[(struct S *)&s_Tab].m_ptrNext, tmp122
stb 8,4(9)# MEM[(struct S *)&s_Tab].m_wait, tmp125
stw 7,8(9)# MEM[(struct S *)&s_Tab + 8B].m_ptrNext, tmp122
stb 8,12(9)   # MEM[(struct S *)&s_Tab + 8B].m_wait, tmp125
blr
.size _GLOBAL__sub_I_s_Obj, .-_GLOBAL__sub_I_s_Obj

.section  .ctors,"aw",@progbits
.align 2
.long _GLOBAL__sub_I_s_Obj

.globls_Tab
.lcomms_Tab,16,8
.type s_Tab, @object

.globls_Obj
.section  .sdata,"aw",@progbits
.align 2
.type s_Obj, @object
.size s_Obj, 8
s_Obj:   <--- statically initialized s_Obj
 # m_ptrNext:
.long 0
 # m_wait:
.byte 1
.zero 3


Kind regards
W. Roehrl

[Bug libgcc/64885] libstdc++ all_attributes failure

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Ditto the header guards like
GCC_GTHR_POSIX_H
GCC_GTHR_SINGLE_H
GCC_GTHR_H
and macros like
GTHREAD_USE_WEAK
HIDE_EXPORTS

[Bug c++/64899] Illegal dynamic initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Not sure if the C++ standard gives you any guarantees it won't be initialized
dynamically.

[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable

[ville.voutilainen at gmail dot com]

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

--- Comment #9 from Ville Voutilainen  ---
I can't see any warnings with my trunk build from today, either.

[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #12 from Jeffrey A. Law  ---
Please leave the bug open until a fix is committed to the trunk.

[Bug c++/64848] G++ internal compiler error with templated lambdas capturing variable

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-02
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.1, 5.0

--- Comment #1 from Ville Voutilainen  ---
Clang accepts the code.

[Bug go/64900] New: gotools don't link on Solaris 11/x86

[ro at gcc dot gnu.org]

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

Bug ID: 64900
   Summary: gotools don't link on Solaris 11/x86
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ro at gcc dot gnu.org
CC: cmang at google dot com
  Host: i?86-*-solaris2.11
Target: i?86-*-solaris2.11
 Build: i?86-*-solaris2.11

Unfortunately, the fix for PR go/64738 (not linking gotools statically) caused
Solaris 11/x86 bootstrap with gas/gld to fail:

/vol/gcc/bin/gld-2.24: gofmt: hidden symbol `_Unwind_GetLanguageSpecificData'
in
/var/gcc/regression/trunk/11-gcc-gas-gld/build/./gcc/libgcc_eh.a(unwind-dw2.o)
is referenced by DSO
/vol/gcc/bin/gld-2.24: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [gofmt] Error 1

Adding -static-libgo back in does restore it.  Strangely, this is neither an
issue on Solaris 10/x86 with gas/gld nor on Solaris 11/SPARC with gas/gld.

  Rainer

[Bug go/64900] gotools don't link on Solaris 11/x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug c++/61229] warn_unused_result fails to work with member functions

[thomas.huxhorn at web dot de]

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

Thomas Huxhorn  changed:

   What|Removed |Added

 CC||thomas.huxhorn at web dot de

--- Comment #3 from Thomas Huxhorn  ---
Here is another one:

class C {
public:
   ~C() {} // comment out to trigger warning at c.noWarning()

  int giveWarning()  __attribute__((warn_unused_result)) { return 0; }
  C noWarning()  __attribute__((warn_unused_result)) { return C(); }
};

int main() {
C c;
c.giveWarning();
c.noWarning();
   return 0;
}


A workaround for me is to delete the empty deconstrcutor. But thats not always
possible :/

[Bug target/62251] [5 Regression] FAIL: gfortran.dg/quad_2.f90 execution test

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
(In reply to John David Anglin from comment #1)
> Test fails at line 58:
>  if (str3 /= "   1.41421356237309504880168872420969798") call abort()
> >1.41421356237309504880168872420969800<

It looks as if there is a difference of 1 ULP.

Thus, one option would be to permit both results ("str /= ... and str /= ...").

[Bug target/62251] [5 Regression] FAIL: gfortran.dg/quad_2.f90 execution test

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Or, alternatively and possible better: to understand why there is now a ULP
difference, which didn't exist in GCC 4.9.

[Bug c++/64842] Implicitly defined constructor isn't constexpr

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ville.voutilainen at gmail dot 
com
 Resolution|--- |INVALID

--- Comment #1 from Ville Voutilainen  ---
The constructors for Point are constexpr, but since p2 is not, passing
it as an argument for scale() means that the invocation of scale() will not
yield a constant expression. If you change the declaration of p2 to
be
constexpr Point p2 {10,10};
the code will work. Clang agrees with gcc.

[Bug c++/64901] New: Overriding final function defined out of line does not lead to an error

[kaballo86 at hotmail dot com]

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

Bug ID: 64901
   Summary: Overriding final function defined out of line does not
lead to an error
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaballo86 at hotmail dot com

It was reported by talin over at ##C++ that the following snippet does not
result in a compilation error as expected:

struct Plant {
  virtual void speak() final;
};

void Plant::speak(){}

struct Flower :  Plant {
  void speak(){}
};

int main() {}

The issue can be reproduced with gcc-4.9.0 and upwards, and it only happens
when `Plant::speak` is defined out-of-line.

[Bug c++/64901] C++11 regression, overriding final function defined out of line does not lead to an error

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.2
   Keywords||accepts-invalid
   Last reconfirmed||2015-02-02
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
Summary|Overriding final function   |C++11 regression,
   |defined out of line does|overriding final function
   |not lead to an error|defined out of line does
   ||not lead to an error
  Known to fail||4.9.1, 5.0

[Bug c++/64901] [4.9/5 Regression] overriding final function defined out of line does not lead to an error

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug ipa/64896] [5 Regression] ICE in get_address_mode, at rtlanal.c:5442

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r220230.  Supposedly some thunk related ICF stuff.

[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
As far as I know we're clean but on the XFAIL of
g++.dg/cpp0x/constexpr-reinterpret1.C which was acked by Jason though.

[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")

[dmalcolm at gcc dot gnu.org]

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

--- Comment #22 from David Malcolm  ---
Author: dmalcolm
Date: Mon Feb  2 15:21:16 2015
New Revision: 220347

URL: https://gcc.gnu.org/viewcvs?rev=220347&root=gcc&view=rev
Log:
PR jit/64810: support DImode on arm

gcc/jit/ChangeLog:
PR jit/64810
* dummy-frontend.c (jit_langhook_type_for_mode): Support
TYPE_MODE (long_long_integer_type_node).


Modified:
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/dummy-frontend.c

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[belagod at gcc dot gnu.org]

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

--- Comment #18 from Tejas Belagod  ---
Author: belagod
Date: Mon Feb  2 15:54:59 2015
New Revision: 220348

URL: https://gcc.gnu.org/viewcvs?rev=220348&root=gcc&view=rev
Log:
2015-02-02  Tejas Belagod  
Andrew Pinski  
Jakub Jelinek  

PR target/64231
* config/aarch64/aarch64.c (aarch64_classify_symbol): Fix large
integer typing for small model. Use IN_RANGE.


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

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[belagod at gcc dot gnu.org]

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

Tejas Belagod  changed:

   What|Removed |Added

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

--- Comment #19 from Tejas Belagod  ---
Fixed as r220348.

[Bug ipa/64896] [5 Regression] ICE in get_address_mode, at rtlanal.c:5442

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
markus@x4 tmp % cat SVGAllInOne.ii
class A
{
  int m_x, m_y;
};
class B
{
  A m_location;
  int m_size;
};
class C
{
public:
  virtual B m_fn1 () const;
};
class D
{
  B m_fn2 () const;
  int m_fn3 () const;
  C *m_fn4 () const;
};
int
D::m_fn3 () const
{
  m_fn4 ()->m_fn1 ();
}
B
D::m_fn2 () const
{
  return B ();
}
class F : C
{
  B
  m_fn1 () const
  {
return B ();
  }
};

markus@x4 tmp % /var/tmp/gcc_test/usr/local/bin/g++ -c -O2 SVGAllInOne.ii
SVGAllInOne.ii: In member function ‘B D::m_fn2() const’:
SVGAllInOne.ii:27:1: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:7735
 D::m_fn2 () const
 ^
0x9c3db7 expand_expr_addr_expr_1
../../gcc/gcc/expr.c:7735
0x9b81b9 expand_expr_addr_expr
../../gcc/gcc/expr.c:7849
0x9b81b9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10723
0x9b8910 expand_expr
../../gcc/gcc/expr.h:254
0x9b8910 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:9903
0x9cbb46 expand_expr
../../gcc/gcc/expr.h:254
0x9cbb46 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5085
0x8cd8fe expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3385
0x8cd8fe expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3481
0x8d4697 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5397
0x8d5eb7 execute
../../gcc/gcc/cfgexpand.c:6006
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #10 from Paolo Carlini  ---
Ok, thanks Ville, let's tentatively close this as fixed for 5.0. I'll monitor
it for a while anyway, probably I will also add something to the testsuite.

[Bug libstdc++/64903] New: is_partitioned should not apply a predicate more than (last - first) times

[kariya_mitsuru at hotmail dot com]

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

Bug ID: 64903
   Summary: is_partitioned should not apply a predicate more than
(last - first) times
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kariya_mitsuru at hotmail dot com

Created attachment 34645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34645&action=edit
g++ -v

Please see the sample code below.

= sample code =
#include 
#include 

int main()
{
int v[] = { 1, 3, 5, 7, 9, 2, 4, 6, 8, 10 };
int c = 0;
std::cout << std::boolalpha
<< std::is_partitioned(v, v + 10, [&c](int x) { return ++c, (x & 1) !=
0; })
<< std::endl;
std::cout << c << " times" << std::endl;
}
= sample code =

= output =
true
11 times
= output =

cf. http://melpon.org/wandbox/permlink/OHXgHtbgmm4Ak8pJ


The C++11 standard 25.3.13[alg.partitions]/p.3 says, "At most last - first
applications of pred."

So the sample code above should output

= output =
true
10 times
= output =

[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")

[dmalcolm at gcc dot gnu.org]

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

--- Comment #23 from David Malcolm  ---
Author: dmalcolm
Date: Mon Feb  2 16:11:15 2015
New Revision: 220351

URL: https://gcc.gnu.org/viewcvs?rev=220351&root=gcc&view=rev
Log:
PR jit/64810: fix for arm_option_override

gcc/ChangeLog:
PR jit/64810
* config/arm/arm.c (arm_option_override): Set
arm_selected_arch/cpu/tune to NULL on entry.


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

[Bug go/64001] gccgo: crash on stack splitting

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
Sorry, I missed that this only happens with 4.9.  Unfortunately, I was also
unable to reproduce it with 4.9.

I have no idea what the problem is.  If you can still reproduce it, run it
under strace to see what values mmap returns and make sure it returns normal
values.

Otherwise, the only thing I can think of is that somehow memory is being
corrupted.  That could be due to changes in the garbage collector.  I haven't
seen any other reports that suggest this, though.

[Bug libstdc++/64903] is_partitioned should not apply a predicate more than (last - first) times

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I notice that libc++ has the same bug.

I think the problem is that we end up testing the partition point twice. Here's
a completely untested patch that avoids that:

--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -583,6 +583,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Predicate __pred)
 {
   __first = std::find_if_not(__first, __last, __pred);
+  if (__first == __last)
+   return true;
+  std::advance(__first, 1);
   return std::none_of(__first, __last, __pred);
 }

[Bug c++/63875] Bogus unused-but-set-parameter warning when expanding a variadic template argument pack

[tejohnson at google dot com]

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

--- Comment #2 from Teresa Johnson  ---
Ping. This is still an issue on trunk (as of today at r220345).

[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Like some of the BSDs, newlib provides a _B bitmask, but that does not
correspond to isblank so can't be used. The _B mask doesn't match the TAB
character, but isblank must match that. The newlib isblank macro handles '\t'
manually, but libstdc++ can't do that and only works with simple bitmasks, not
bitmasks plus extra checks.

https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00059.html just adjusts the test
to account for this.

[Bug libgcc/64885] libstdc++ all_attributes failure

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Yeah, they're a mess.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #23 from Dominique d'Humieres  ---
> does my incremental patch fix that on Darwin14 - I can send it to you if
> cut & paste mangled.

If you mean the patch in comment 19, yes it does (I only applied it for c++200x
and c++2014).

[Bug c++/64899] Illegal dynamic initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #1)
> Not sure if the C++ standard gives you any guarantees it won't be
> initialized dynamically.

It does; 3.6.2 says that it gets constant initialization.

[Bug target/64893] [5 Regression] ICE while doing a bootstrap with the latest compiler

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #7 from alalaw01 at gcc dot gnu.org ---
This feels like we are working around a deficiency in the C++ frontend, which
is a shame, but if we have to, then seems to me like an OK way to do so.

[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  ---
The problem is in the recursion step of
fsm_find_control_statement_thread_paths:


  for (i = 0; i < gimple_phi_num_args (phi); i++)
{
  tree arg = gimple_phi_arg_def (phi, i);
  basic_block bbi = gimple_phi_arg_edge (phi, i)->src;
[...]
  if (TREE_CODE (arg) == SSA_NAME)
{
  vec_safe_push (path, bbi);
  /* Recursively follow SSA_NAMEs looking for a constant definition.  */
  fsm_find_control_statement_thread_paths (arg, visited_phis, path);
  path->pop ();
  continue;
}

We are not supposed to register a jump-thread following only one of the PHI
arguments, as the other arguments may resolve into a non-constant or a
different constant.

In the current case, we have 

  c = x->c1[x->c2];
  switch (a)
{
case 0:
  if (c == ' ')
x->c2++;
  else if (c == '/')
{
  a = 4;   // here is the first argument of the phi node
  j = x->c2++;
}
  else
a = b;// recursive call will follow b and resolve into 15

 // here the phi node looks like
 // a0 = phi (4, b)

  break;
case 1:
  switch (c)
{
case '{':
  a = 0;
  b = 15;
  f = f10 ();
  x->c2++;
  break;

[Bug libstdc++/61601] C++11 regex resource exhaustion

[max at cert dot cx]

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

--- Comment #8 from Maksymilian Arciemowicz  ---
> there's no memory problem, it just takes exponentially long time to run
> (which is expected when using backtracking).

call it cpu resource exhaustion (CWE-400)

> 
> To avoid it, you can use Thompson NFA:
> 
> #define _GLIBCXX_REGEX_USE_THOMPSON_NFA
> #include 
> 
> int main (int argc, char *argv[])
> {
>   std::regex_match("findme", std::regex("(.*{100}{200}findme)",
> std::regex_constants::extended));
> 
>   return 0;
> 
> }
> 
> Notice that for now Thompson NFA doesn't support ECMAScript.

yeap.

try (.*{300}{100}) for _GLIBCXX_REGEX_USE_THOMPSON_NFA. occurs stack exhaustion
like in #61582

[Bug translation/64905] New: unsigned short is loaded with 4-byte load (movl)

[r.ayrapetyan at samsung dot com]

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

Bug ID: 64905
   Summary: unsigned short is loaded with 4-byte load (movl)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r.ayrapetyan at samsung dot com

Created attachment 34646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34646&action=edit
Repro case source

Version, target:
  gcc version 5.0.0 20150128 (experimental)
  x86_64-unknown-linux-gnu

Issue:
  In some cases, uint16_t data element is read with 4-byte load (movl
instruction).

Repro case build string:
  gcc -g -Os \
  -ffixed-rax -ffixed-rbx -ffixed-rcx -ffixed-rdx \
  -ffixed-rdi -ffixed-rsi \
  -ffixed-r8 -ffixed-r9 -ffixed-r10 -ffixed-r11 \
  -ffixed-r12 -ffixed-r13 -ffixed-r14 -ffixed-r15 \
  unaligned_read.c -o unaligned_read

Preliminary analysis:
  In the example, ffixed- options are passed to force pointer allocation on the
%rbp register.
  There is another real-world example without ffixed- options, where pointer
was allocated  on the %rbp register and that caused out-of-boundaries memory
access.
  1. The pointer to uint16_t data element was allocated on the %rbp register
 that is marked as aligned to STACK_BOUNDARY.
  2. get_attr_mode called from movhi_internal returns MODE_SI for the
instruction.

This can lead to the following problems:
  1. unaligned memory access (reduced performance);
  2. segmentation fault due to accessing unmapped page (or page mapped with
PROT_NONE)

 // mapped page with array of uint16_t | unmapped page
 function (&array [index_of_last_element_on_the_mapped_page]);
  3. memory access checkers complain about accessing memory out of allocated
array boundaries.

[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #9 from Jan Hubicka  ---
OK, I will take a look this week.  Though I see no reason why this is still P1.
Not performing local call conventions to aliases is very minor missed
optimization case.

[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #14 from Jan Hubicka  ---
Either that or caling fixup_noreturn_call afterwards.  Not producing return
statement is probably better idea.  I wonder how this worked on earlier trees,
perhaps fixup_cfg pass was luckilly scheduled at a time we produce thunks?

[Bug ipa/64896] [5 Regression] ICE in get_address_mode, at rtlanal.c:5442

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
Hmm, mine I suppose ;)

[Bug sanitizer/64906] New: -fsanitize=integer-divide-by-zero creates false -Wmaybe-uninitialized warning

[sirl at gcc dot gnu.org]

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

Bug ID: 64906
   Summary: -fsanitize=integer-divide-by-zero creates false
-Wmaybe-uninitialized warning
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
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

This testcase produces a false warning when compiled with -O2
-fsanitize=integer-divide-by-zero -Wmaybe-uninitialized:

struct s {
__SIZE_TYPE__ size;
unsigned int flags;
};

int testf(struct s * source)
{
__SIZE_TYPE__ msize = 0;
if ((source->flags & 88) ? (__SIZE_TYPE__) 43 * 8 : 0)
msize = source->size / ((source->flags & 88) ? (__SIZE_TYPE__) 43 * 8:
0);
return msize;
}

test.c: In function 'testf':
test.c:11:8: warning: 'iftmp.1' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  msize = source->size / ((source->flags & 88) ? (__SIZE_TYPE__) 43 * 8: 0);
^

[Bug rtl-optimization/64907] New: Suboptimal code (saving rbx on stack in order to save another reg in rbx)

[vda.linux at googlemail dot com]

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

Bug ID: 64907
   Summary: Suboptimal code (saving rbx on stack in order to save
another reg in rbx)
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vda.linux at googlemail dot com

void put_16bit(unsigned short v);
void put_32bit(unsigned v)
{
put_16bit(v);
put_16bit(v >> 16);
}

With gcc 4.7.2 the above compiles to the following assembly:

put_32bit:
pushq   %rbx
movl%edi, %ebx
andl$65535, %edi
callput_16bit
movl%ebx, %edi
popq%rbx
shrl$16, %edi
jmp put_16bit

Code saves %rbx on stack only in order to save %edi to %ebx.
A simpler alternative is to just save %rdi on stack:

put_32bit:
pushq   %rdi
andl$65535, %edi
callput_16bit
popq%rdi
shrl$16, %edi
jmp put_16bit

[Bug target/64905] unsigned short is loaded with 4-byte load (movl)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-02
 CC||ubizjak at gmail dot com
  Component|translation |target
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
aligned_operand has

  if (MEM_ALIGN (op) >= 32)
return true;

  op = XEXP (op, 0);

  /* Pushes and pops are only valid on the stack pointer.  */
  if (GET_CODE (op) == PRE_DEC
  || GET_CODE (op) == POST_INC)
return true;

  /* Decode the address.  */
  ok = ix86_decompose_address (op, &parts);
  gcc_assert (ok);

  if (parts.base && GET_CODE (parts.base) == SUBREG)
parts.base = SUBREG_REG (parts.base);
  if (parts.index && GET_CODE (parts.index) == SUBREG)
parts.index = SUBREG_REG (parts.index);

  /* Look for some component that isn't known to be aligned.  */
  if (parts.index)
{
  if (REGNO_POINTER_ALIGN (REGNO (parts.index)) * parts.scale < 32)
return false;
}
  if (parts.base)
{
  if (REGNO_POINTER_ALIGN (REGNO (parts.base)) < 32)
return false;
}
  if (parts.disp)
{
  if (!CONST_INT_P (parts.disp)
  || (INTVAL (parts.disp) & 3))
return false;
}

  /* Didn't find one -- this must be an aligned address.  */
  return true;

It returns true for

(mem:HI (reg/f:DI 6 bp [orig:90 *a_p_2(D) ] [90]) [2 *_3+0 S2 A16])

Why do we need to decompose address when we have MEM_ALIGN (op)?

[Bug target/64905] unsigned short is loaded with 4-byte load (movl)

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 34647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34647&action=edit
A patch

Does this patch make any sense?

[Bug rtl-optimization/64907] Suboptimal code (saving rbx on stack in order to save another reg in rbx)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-02
 CC||vmakarov at redhat dot com
Version|4.7.2   |5.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Still happens with 5.0.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[xur at google dot com]

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

--- Comment #23 from xur at google dot com ---
I overlooked that gcov_master was also used in gcov_dump_int.
The bug is exactly as Honza described. I can reproduce with a simple example.
Nathan: did you use dlopen? It seems using dlopen will change
gcov_master behavior and hide the issue.
If you call shared library function directly and use fork, you will reproduce.

On Sun, Feb 1, 2015 at 6:57 AM, nathan at acm dot org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
>
> --- Comment #22 from Nathan Sidwell  ---
> thanks Honza, that was helpful. I'm an idiot.  Your workaround unhiding
> gcov_var is fine for now, while I figure out if there's a better way.  I am
> puzzled as to why I can't observe this failure in the testcase I've
> constructed.

[Bug pch/64908] New: [5 Regression] pch broken

[trippels at gcc dot gnu.org]

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

Bug ID: 64908
   Summary: [5 Regression] pch broken
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

With a checking=release PGO/LTO bootstrapped compiler I get:

arkus@x4 /tmp % touch foo.h
markus@x4 /tmp % g++ -c foo.h
foo.h:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Valgrind shows:

==7155== Syscall param write(buf) points to uninitialised byte(s)
==7155==at 0x4F8A370: __write_nocancel (in /lib64/libc-2.20.90.so)
==7155==by 0x4F2B3EE: _IO_file_write@@GLIBC_2.2.5 (in
/lib64/libc-2.20.90.so)
==7155==by 0x4F2A9F2: new_do_write (in /lib64/libc-2.20.90.so)
==7155==by 0x4F2C2F0: _IO_do_write@@GLIBC_2.2.5 (in /lib64/libc-2.20.90.so)
==7155==by 0x4F2BA66: _IO_file_xsputn@@GLIBC_2.2.5 (in
/lib64/libc-2.20.90.so)
==7155==by 0x4F2167A: fwrite (in /lib64/libc-2.20.90.so)
==7155==by 0x88647C: ggc_pch_write_object(ggc_pch_data*, _IO_FILE*, void*,
void*, unsigned long, bool) (ggc-page.c:2451)
==7155==by 0xA2C1E0: gt_pch_save(_IO_FILE*) (ggc-common.c:566)
==7155==by 0x861FEC: c_common_write_pch() (c-pch.c:197)
==7155==by 0x6E4E8C: cp_write_global_declarations() (decl2.c:4400)
==7155==by 0xC96DD3: compile_file() (toplev.c:608)
==7155==by 0x5F84EE: do_compile (toplev.c:2063)
==7155==by 0x5F84EE: toplev::main(int, char**) (toplev.c:2161)
==7155==  Address 0x40492ad is not stack'd, malloc'd or (recently) free'd
==7155==  Uninitialised value was created by a heap allocation
==7155==at 0x4028C70: malloc (vg_replace_malloc.c:296)
==7155==by 0x135C257: xmalloc (xmalloc.c:147)
==7155==by 0x132DC8A: _cpp_init_tokenrun (lex.c:2008)
==7155==by 0x132C28A: cpp_create_reader(c_lang, ht*, line_maps*)
(init.c:238)
==7155==by 0x85F85C: c_common_init_options(unsigned int,
cl_decoded_option*) (c-opts.c:234)
==7155==by 0x5F7F9D: toplev::main(int, char**) (toplev.c:2136)
==7155==by 0x5F9199: main (main.c:39

[Bug middle-end/22141] [4.8/4.9/5 Regression] Missing optimization when storing structures

[hariharan.gcc at gmail dot com]

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

hariharan.gcc at gmail dot com changed:

   What|Removed |Added

 CC||hariharan.gcc at gmail dot com

--- Comment #30 from hariharan.gcc at gmail dot com ---
I saw a related problem, this time with bitfields

$more bitfieldtest.c

typedef union {
  struct {
unsigned int b1:1;
unsigned int b2:1;
unsigned int b3:1;
unsigned int b4:1;
unsigned int b5:1;
  }fields;
  unsigned int word;
} _t_bitfields;


void _const_populate_bits(_t_bitfields * data)
{
  data->fields.b1 = 1;
  data->fields.b2 = 0;
  data->fields.b3 = 1;
  data->fields.b4 = 1;
  data->fields.b5 = 0;
}

At the end of tree stages, it looks like this

$more bitfieldtest.c.165t.optimized

;; Function _const_populate_bits (_const_populate_bits, funcdef_no=0,
decl_uid=1339, cgraph_uid=0)

_const_populate_bits (union _t_bitfields * data)
{
  :
  data_2(D)->fields.b1 = 1;
  data_2(D)->fields.b2 = 0;
  data_2(D)->fields.b3 = 1;
  data_2(D)->fields.b4 = 1;
  data_2(D)->fields.b5 = 0;
  return;

}

Expand expands each one of the assignments in turn and some get combined later
on into ok-ish code. It would be nice to be able to combine all 5 assignments
into one.

Its kind of related to this PR, but is it sufficiently different to warrant a
separate PR for it?

[Bug pch/64908] [5 Regression] pch broken

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
This is the actual crash:

==15192== Invalid read of size 1
==15192==at 0xCBB825: ggc_get_size(void const*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xBE7A71: gt_pch_note_object(void*, void*, void (*)(void*,
void*, void (*)(void*, void*), void*)) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xBE7D4B: gt_pch_nx_cpp_macro(void*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xC1EDFF: gt_pch_nx_lang_tree_node(void*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xB728E0: gt_pch_nx_string_pool_data(void*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xBE7436: gt_pch_save(_IO_FILE*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xC10BBB: c_common_write_pch() (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0x5C2817: ??? (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xCB561F: compile_file() [clone .lto_priv.2265] (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xC2D8FD: toplev::main(int, char**) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==by 0xC2C8BC: main (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==15192==  Address 0x2e is not stack'd, malloc'd or (recently) free'd

[Bug c++/64867] warning for passing non-POD to varargs function

[tromey at gcc dot gnu.org]

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

--- Comment #13 from Tom Tromey  ---
(In reply to Jonathan Wakely from comment #11)

> That's the wrong thing to assert:

Aha, thank you very much.  I obviously did not realize the difference :)

Unfortunately I think even if I made this change I probably wouldn't
want to enable -Wconditionally-supported here, as it enables some
other warning that IIRC isn't desirable here.

I ended up writing a gcc plugin to find places passing an aggregate
to a varargs function.  But I still think some simpler way to get
a warning here would be nice.

[Bug go/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)

[boger at us dot ibm.com]

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

boger at us dot ibm.com changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org,
   ||amodra at gmail dot com

--- Comment #1 from boger at us dot ibm.com ---
I found some notes I had from Alan on his change related to GO closures for
powerpc and found that all his changes for libffi are in but this gcc patch is
not in gcc trunk:

Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h(revision 217330)
+++ gcc/config/rs6000/linux64.h(working copy)
@@ -115,6 +115,14 @@
   if (dot_symbols)\
 error ("-mcall-aixdesc incompatible with -mabi=elfv2"); \
 }\
+  if (DEFAULT_ABI == ABI_AIX\
+  && strcmp (lang_hooks.name, "GNU Go") == 0)\
+{\
+  if (global_options_set.x_TARGET_POINTERS_TO_NESTED_FUNCTIONS \
+  && TARGET_POINTERS_TO_NESTED_FUNCTIONS)\
+error ("-mpointers-to-nested-functions is incompatible with Go"); \
+  TARGET_POINTERS_TO_NESTED_FUNCTIONS = 0;\
+}\
   if (rs6000_isa_flags & OPTION_MASK_RELOCATABLE)\
 {\
   rs6000_isa_flags &= ~OPTION_MASK_RELOCATABLE;\

After applying this patch and rebuilding the regressions go away.

[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':

[gang.chen.5i5j at gmail dot com]

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

--- Comment #13 from Chen Gang  ---
(In reply to Jeffrey A. Law from comment #12)
> Please leave the bug open until a fix is committed to the trunk.

OK, thanks.

Could any members help to commit the related patch to the trunk? I guess, I am
not the suitable member to do it:

 - I only reported and monitored this issue, but did not analyze it in details,
this issue is fixed by another related members.

 - Either, at present, I have no write right for main branch (I have posted my
assignment paper to FSF in 2015-01-31, I guess, it will reach FSF within
2015-02-28).

Thanks.

[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':

[joern.rennecke at embecosm dot com]

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

--- Comment #14 from joern.rennecke at embecosm dot com ---
On 2 February 2015 at 19:58, gang.chen.5i5j at gmail dot com
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
>
> --- Comment #13 from Chen Gang  ---
> (In reply to Jeffrey A. Law from comment #12)
>> Please leave the bug open until a fix is committed to the trunk.
>
> OK, thanks.
>
> Could any members help to commit the related patch to the trunk? I guess, I am
> not the suitable member to do it:

Has anyone done a full regression test?

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #24 from Nathan Sidwell  ---
xur, can you provide your testcase?  with a regular use of multiple DSOs, I
can't get a failure. (no dlopen used).

[Bug go/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
It seems to me that with the current code that issue should be handled in
libffi.  With the current code it's hard for me to see why checking for "GNU
Go" is correct.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[xur at google dot com]

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

--- Comment #25 from xur at google dot com ---
attached the test case. replace CC in build_cmd with your compiler.

On Mon, Feb 2, 2015 at 12:59 PM, nathan at acm dot org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
>
> --- Comment #24 from Nathan Sidwell  ---
> xur, can you provide your testcase?  with a regular use of multiple DSOs, I
> can't get a failure. (no dlopen used).

[Bug target/64905] unsigned short is loaded with 4-byte load (movl)

[hjl.tools at gmail dot com]

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

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

https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00093.html

[Bug middle-end/64909] New: [4.8/5 regression] Missed vectorization

[hubicka at gcc dot gnu.org]

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

Bug ID: 64909
   Summary: [4.8/5 regression] Missed vectorization
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org

Hi,
the following loop (taken from firefox unicode stuff)
unsigned short a[32];
unsigned int b[32];
t()
{
  int i;
  for (i=0;i<12;i++)
b[i]=a[i];
}

compiles by clang to:
t:  # @t
.cfi_startproc
# BB#0:
vpmovzxwd   a(%rip), %xmm0
vmovdqa .LCPI0_0(%rip), %xmm1   # xmm1 = [65535,65535,65535,65535]
vpand   %xmm1, %xmm0, %xmm0
vmovdqa %xmm0, b(%rip)
vpmovzxwd   a+8(%rip), %xmm0
vpand   %xmm1, %xmm0, %xmm0
vmovdqa %xmm0, b+16(%rip)
vpmovzxwd   a+16(%rip), %xmm0
vpand   %xmm1, %xmm0, %xmm0
vmovdqa %xmm0, b+32(%rip)
retq

GCC 4.7 does:
t:
.LFB0:
.cfi_startproc
movzwl  a+16(%rip), %eax
vmovaps a(%rip), %xmm0
vpmovzxwd   %xmm0, %xmm1
vpsrldq $8, %xmm0, %xmm0
vpmovzxwd   %xmm0, %xmm0
movl%eax, b+32(%rip)
movzwl  a+18(%rip), %eax
vmovaps %xmm1, b(%rip)
vmovaps %xmm0, b+16(%rip)
movl%eax, b+36(%rip)
movzwl  a+20(%rip), %eax
movl%eax, b+40(%rip)
movzwl  a+22(%rip), %eax
movl%eax, b+44(%rip)
ret

while 4.8 and mainline unrolls and keeps it that way:

t:
.LFB0:
.cfi_startproc
movzwl  a(%rip), %eax
movl%eax, b(%rip)
movzwl  a+2(%rip), %eax
movl%eax, b+4(%rip)
movzwl  a+4(%rip), %eax
movl%eax, b+8(%rip)
movzwl  a+6(%rip), %eax
movl%eax, b+12(%rip)
movzwl  a+8(%rip), %eax
movl%eax, b+16(%rip)
movzwl  a+10(%rip), %eax
movl%eax, b+20(%rip)
movzwl  a+12(%rip), %eax
movl%eax, b+24(%rip)
movzwl  a+14(%rip), %eax
movl%eax, b+28(%rip)
movzwl  a+16(%rip), %eax
movl%eax, b+32(%rip)
movzwl  a+18(%rip), %eax
movl%eax, b+36(%rip)
movzwl  a+20(%rip), %eax
movl%eax, b+40(%rip)
movzwl  a+22(%rip), %eax
movl%eax, b+44(%rip)
ret

[Bug middle-end/64909] [4.8/5 regression] Missed vectorization

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||tsaunders at mozilla dot com

--- Comment #1 from Jan Hubicka  ---
Forgot to mention, seen in the disassembly of Firefox's
AssignJSString(JSContext*, nsAutoJSString&, JSString*) :)

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  ---
I'm about to install a patch that changes the costs on SPARC 64-bit to:

Use 1:
  cand  costcompl.  depends on
  0 4   0inv_expr:0
  1 8   0   
  4 6   0inv_expr:1
  5 0   0   
  6 0   0

but this doesn't change the outcome of the test. :-(

[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)

[tbsaunde at gcc dot gnu.org]

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

--- Comment #16 from tbsaunde at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #15)
> I think it is best to modify the remove_unreachable_nodes loop to first
> remove aliases before removing their target...

how is this related? the target isn't removed at all in this case only the
alias.

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Well, can someone overwrite dllimport symbol by different definition?
If not, it is a bug of decl_binds_to_current_def_p to return false here.
If it can be inteprposed, I think the function
symtab_node::noninterposable_alias should remove dllimport attribute on the
alias created and so should symtab_node::make_decl_local

Honza

[Bug middle-end/64909] [4.8/5 regression] Missed vectorization

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Today's mainline generates:

movzwla+16(%rip), %eax
pxor%xmm1, %xmm1
movdqaa(%rip), %xmm0
movdqa%xmm0, %xmm2
movl%eax, b+32(%rip)
movzwla+18(%rip), %eax
punpcklwd%xmm1, %xmm2
punpckhwd%xmm1, %xmm0
movl%eax, b+36(%rip)
movzwla+20(%rip), %eax
movaps%xmm2, b(%rip)
movaps%xmm0, b+16(%rip)
movl%eax, b+40(%rip)
movzwla+22(%rip), %eax
movl%eax, b+44(%rip)
ret

at -O3.

[Bug tree-optimization/64910] New: tree reassociation results in poor code

[law at redhat dot com]

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

Bug ID: 64910
   Summary: tree reassociation results in poor code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com

Tree reassociation seems to be taking expressions of the form
(X & Y) & C

Where X & Y are objects and C is a constant.  And turns them into

(Y & C) & X

The problem with generating that kind of code is it makes it much harder for
the backends to (for example) create bitfield test instructions.

Here's a concrete example:

int v;
int b2b (unsigned char u, unsigned char w)
{
  if ((u & w) & 0x20)
v = 1; 
}

Generates the following .reassoc dump fragment

  :
  _8 = w_3(D) & 32;
  _7 = _8 & u_2(D);
  if (_7 != 0)


To turn that into a bitfield test something is going to have to look at all
three statements to determine that _8 can only have a single bit set and thus
_7 can only have a single bet set.

Contrast to the following after hacking up reassoc a bit:

 _4 = u_2(D) & w_3(D);
  _7 = _4 & 32;
  if (_7 != 0)


Which looks like a canonical bit test instruction.

The ranking of the operands in the array looks correct (X, Y, CONST).  But when
we go to rebuild the expression using the simple 3 operand recursive
rewrite_expr_tree, we pair up the last two operands into an operation (Y &
CONST), then create X & (Y & CONST) thus generating the poor code.

[Bug tree-optimization/64910] tree reassociation results in poor code

[law at redhat dot com]

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

--- Comment #1 from Jeffrey A. Law  ---
Here's the hack that I was playing with which shows the better code sequence:
diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index 995..4515a4d 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -3476,6 +3476,18 @@ swap_ops_for_binary_stmt (vec ops,
   oe1->op = temp.op;
   oe1->rank = temp.rank;
 }
+  else if (TREE_CODE (oe1->op) != INTEGER_CST
+  && TREE_CODE (oe2->op) != INTEGER_CST
+  && TREE_CODE (oe3->op) == INTEGER_CST)
+{
+  struct operand_entry temp = *oe3;
+  oe3->op = oe2->op;
+  oe3->rank = oe2->rank;
+  oe2->op = oe1->op;
+  oe2->rank = oe1->rank;
+  oe1->op = temp.op;
+  oe1->rank = temp.rank;
+}
 }

 /* If definition of RHS1 or RHS2 dominates STMT, return the later of those

[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':

[law at redhat dot com]

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

--- Comment #15 from Jeffrey A. Law  ---
The patch needs to be reviewed.  It's been a long time since I thought about
the _STRICT variants of the REG_OK_ macros and how all that's supposed to work.
 I'll have to read up on their semantics before I can review this patch.

[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0

[asmwarrior at gmail dot com]

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

--- Comment #21 from asmwarrior  ---
I just test the sample code in comment 20 with GCC 4.9.2, and I see this
"jumpy" behaviour still exists, do we need to reopen this bug? Thanks.

[Bug testsuite/64911] New: FAIL: gcc.c-torture/execute/builtins/strchr.c compilation, -O0

[pangbw at gmail dot com]

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

Bug ID: 64911
   Summary: FAIL: gcc.c-torture/execute/builtins/strchr.c
compilation,  -O0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pangbw at gmail dot com

In one of my environment, I will get the multiple definition error for this
test case. In another one of my environment, I will not get the error.

After checking the code in linker I think this is a flaw in linker and this is
a bug in the test case as we should always report multiple definition as an
error when a function(strchr) is defined in two places(libc.a and this test
case).

[Bug testsuite/64911] FAIL: gcc.c-torture/execute/builtins/strchr.c compilation, -O0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-02-03
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
What target is this on?  And what version of GCC?
Also is the failures with LTO?

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994 too.

[Bug rtl-optimization/56590] Replace auto-inc-dec pass with generic address mode selection pass

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #1 from amker at gcc dot gnu.org ---
This surely sounds interesting.  Like I suggested in PR62173, RTL optimizer
might be able to do more in address expression re-association and addressing
mode choosing.
But it's difficult to change base/offset for addresses which are IVOPTed on
GIMPLE.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #24 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #19)
Confirmed that this patch eliminates the regressions for...

make -k check
RUNTESTFLAGS="conformance.exp=17_intro/headers/c++*/all_attributes.cc 
--target_board=unix'{-m32,-m64}'"

on x86_64-apple-darwin14

[Bug c++/64901] [4.9/5 Regression] overriding final function defined out of line does not lead to an error

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Feb  3 02:49:42 2015
New Revision: 220363

URL: https://gcc.gnu.org/viewcvs?rev=220363&root=gcc&view=rev
Log:
PR c++/64901
* decl.c (duplicate_decls): Also duplicate DECL_FINAL_P and
DECL_OVERRIDE_P.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/g++.dg/cpp0x/override1.C

[Bug go/64836] go.test/test/fixedbugs/issue4348.go FAILs

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Feb  3 03:33:21 2015
New Revision: 220364

URL: https://gcc.gnu.org/viewcvs?rev=220364&root=gcc&view=rev
Log:
PR go/64836
PR go/64838

compiler: Use int64_t for backend type size and alignment.

Fixes 32-bit host 64-bit target cross-compilation.

* go-gcc.cc (Gcc_backend::type_size): Change return type to
int64_t.
(Gcc_backend::type_alignment): Likewise.
(Gcc_backend::type_field_alignment): Likewise.
(Gcc_backend::type_field_offset): Likewise.
(Gcc_backend::implicit_variable): Change alignment parameter type
to int64_t.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-gcc.cc
trunk/gcc/go/gofrontend/backend.h
trunk/gcc/go/gofrontend/expressions.cc
trunk/gcc/go/gofrontend/expressions.h
trunk/gcc/go/gofrontend/gogo.cc
trunk/gcc/go/gofrontend/gogo.h
trunk/gcc/go/gofrontend/types.cc
trunk/gcc/go/gofrontend/types.h

[Bug go/64838] ICE in type_size, at go/go-gcc.cc:1110

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Feb  3 03:33:21 2015
New Revision: 220364

URL: https://gcc.gnu.org/viewcvs?rev=220364&root=gcc&view=rev
Log:
PR go/64836
PR go/64838

compiler: Use int64_t for backend type size and alignment.

Fixes 32-bit host 64-bit target cross-compilation.

* go-gcc.cc (Gcc_backend::type_size): Change return type to
int64_t.
(Gcc_backend::type_alignment): Likewise.
(Gcc_backend::type_field_alignment): Likewise.
(Gcc_backend::type_field_offset): Likewise.
(Gcc_backend::implicit_variable): Change alignment parameter type
to int64_t.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-gcc.cc
trunk/gcc/go/gofrontend/backend.h
trunk/gcc/go/gofrontend/expressions.cc
trunk/gcc/go/gofrontend/expressions.h
trunk/gcc/go/gofrontend/gogo.cc
trunk/gcc/go/gofrontend/gogo.h
trunk/gcc/go/gofrontend/types.cc
trunk/gcc/go/gofrontend/types.h

[Bug go/64836] go.test/test/fixedbugs/issue4348.go FAILs

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed.

[Bug go/64838] ICE in type_size, at go/go-gcc.cc:1110

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed.

[Bug testsuite/63256] [5 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
sms-1.c fails with -m32 -mpowerpc64 in a similar way.

[Bug go/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #3 from Alan Modra  ---
Confirmed.  libffi does not appear to be involved here.  If I look at the
escape.go testcase Lynn singles out, the code generated with the patch (or with
-mno-pointers-to-nested-functions) is the following for the call that dies
without the patch.

Breakpoint 2, main.for_escapes3 (y=106, x=105) at
/home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:155
155return f[0](), f[1]()
(gdb) disass $pc,$pc+0x3f
Dump of assembler code from 0x1000267c to 0x100026bb:
=> 0x1000267c :ld  r11,112(r1)
   0x10002680 :ld  r9,0(r11)
   0x10002684 :std r2,40(r1)
   0x10002688 :ld  r10,0(r9)
   0x1000268c :mtctr   r10
   0x10002690 :ld  r2,8(r9)
   0x10002694 :bctrl
   0x10002698 :ld  r2,40(r1)
(gdb) stepi 7
main.$nested0 () at
/home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:152
152f[n] = func() *int { return p }
(gdb) disass
Dump of assembler code for function main.$nested0:
=> 0x10001960 <+0>:ld  r9,8(r11)
   0x10001964 <+4>:ld  r3,0(r9)
   0x10001968 <+8>:blr

Clearly r11 is expected to hold the address of a struct on entry to
main.$nested0.

(gdb) x/2xg $r11
0xc208e0:0x100144700x00c20903c000
(gdb) x 0x00c20903c000
0xc20903c000:0x00c208d8
(gdb) x 0x00c208d8
0xc208d8:0x0069

Yup, there's our 105, so the value returned is as expected.

If I compile the testcase without -mno-pointers-to-nested-functions then the
code for the call in main.for_escapes3 is:

   0x1000267c <+172>:ld  r9,112(r1)
---Type  to continue, or q  to quit---
   0x10002680 <+176>:ld  r9,0(r9)
   0x10002684 <+180>:std r2,40(r1)
   0x10002688 <+184>:ld  r10,0(r9)
   0x1000268c <+188>:ld  r11,16(r9)
   0x10002690 <+192>:mtctr   r10
   0x10002694 <+196>:ld  r2,8(r9)
   0x10002698 <+200>:bctrl
=> 0x1000269c <+204>:ld  r2,40(r1)

So r11 is not loaded with the proper parameter from 112(r1), but instead set up
with a zero from the function descriptor.

[Bug c++/64912] New: no debug info for struct that pass by reference

[chihin.ko at oracle dot com]

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

Bug ID: 64912
   Summary: no debug info for struct that pass by reference
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chihin.ko at oracle dot com

For following t.cc:

extern "C" int printf(const char*, ...);
#include   
using namespace std;

deque gl_li(5,100);  
int main ()
{ 
deque tmp_deque(5,200);
gl_li.assign(tmp_deque.cbegin(),tmp_deque.cend());
gl_li.assign(tmp_deque.begin(),tmp_deque.end());  
for ( auto el: gl_li )
printf("el = %d\n", el);

return 0;   

} 

/gcc/4.8.1/intel-Linux/bin/g++ -m64 -std=c++11 t.cc -Xlinker
-R/gcc/4.8.1/intel-Linux/lib64  

There is no debug info to indicate struct "_Deque_iterator"
is passed type reference:

< 2><0x09be>  DW_TAG_structure_type
DW_AT_name  "_Deque_iterator"
DW_AT_byte_size 0x0020
DW_AT_decl_file 0x0001
/net/dv104/export/tools/gcc/4.8.1/intel-Linux/include/c++/4.8.1/bits/stl_deque.h
DW_AT_decl_line 0x006a
DW_AT_sibling   <0x0c55>
< 3><0x09ca>DW_TAG_member
  DW_AT_name  "_M_cur"

===
Oracle C++ compiler would generate something like this:
< 2><0x1bee>  DW_TAG_structure_type
DW_AT_name  "_Deque_iterator"
DW_AT_SUN_link_name
"_ZSt15_Deque_iteratorIiRiPiE"
DW_AT_decl_file 0x0002
/ws/cia/builds/dodona/latest/inte
l-S2/lib/compilers/CC-gcc/include/c++/4.8.2/bits/stl_deque.h
DW_AT_decl_line 0x0069
DW_AT_VMS_rtnbeg_pd_address <0x1b9f>
DW_AT_byte_size 0x0020
DW_AT_SUN_pass_with_const   yes(1)   <=== passed by
reference
DW_AT_SUN_return_with_const yes(1)   <=== returned by
reference

[Bug target/64205] [5 Regression] powerpc64-linux --with-cpu=G5 bootstrap failure

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
Doesn't happen with -mlra.