[Bug c/64417] [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0 (test for excess errors)

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  7 08:19:48 2015
New Revision: 219278

URL: https://gcc.gnu.org/viewcvs?rev=219278&root=gcc&view=rev
Log:
PR c/64417
c/
* c-typeck.c (process_init_element): Disallow initialization of
a flexible array member with a string constant if the structure
is in an array.
testsuite/
* gcc.c-torture/compile/pr28865.c: Add dg-errors.
* gcc.dg/pr64417.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr64417.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/pr28865.c

[Bug c/64440] -Wdiv-by-zero false negative on const variables

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  7 08:21:50 2015
New Revision: 219279

URL: https://gcc.gnu.org/viewcvs?rev=219279&root=gcc&view=rev
Log:
PR c/64440
* c-common.c (c_fully_fold_internal): Warn for division and modulo
if orig_op1 isn't INTEGER_CST, op1 is INTEGER_CST and is zero.

* gcc.dg/pr64440.c: New test.
* c-c++-common/pr56607.c: Don't limit dg-warnings to C++.

Added:
trunk/gcc/testsuite/gcc.dg/pr64440.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr56607.c

[Bug c/64440] -Wdiv-by-zero false negative on const variables

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c/64417] [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0 (test for excess errors)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c/64518] New: Warning about comparison between signed and unsigned can be useless in some cases

[patrick.pelissier at gmail dot com]

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

Bug ID: 64518
   Summary: Warning about comparison between signed and unsigned
can be useless in some cases
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.pelissier at gmail dot com

For the following function:

int f(int x) { return ( x >= 0 && x < sizeof(int)); } 


I get the following warning with gcc -Wsign-compare -c f.c :
f.c: In function 'f':
f.c:1:37: warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
 int f(int x) { return ( x >= 0 && x < sizeof(int)); } 
 ^


However, as x has been checked as positive due to the first comparison, I don't
see how the comparison between x (signed) and sizeof(int) (unsigned) can be
wrong.

The proposed enhancement is to improve the warning to handle this case properly
without adding a (useless) cast in the user code like this:

int f(int x) { return ( x >= 0 && (unsigned int) x < sizeof(int)); }

[Bug c++/64519] New: variadic template as the first argument

[roman.kurc at wp dot pl]

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

Bug ID: 64519
   Summary: variadic template as the first argument
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roman.kurc at wp dot pl

Created attachment 34392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34392&action=edit
sample code

It seems that passing an empty argument to a variadic template results in
assigning void type to the argument.


Such a behavior can be seen in the following cases:

static_assert( std::is_same< decltype(B::test()), B::CharA<3> >::value ==
false, "test( ) should evaluate to fun( )" );

test( TA... args ) is called with no parameters then I::template
sfinae_2(args...,0) and args... gets void type. 

The same happens in calls presented below and it does not matter if template is
instantinated or only its type is deduced.


static_assert( (sizeof(B::test()) == sizeof(B::CharA<1>)), "test( ) should
evaluate to fun ()" );

static_assert( std::is_same< decltype(B::test()), B::CharA<1> >::value, "test()
should evaluate to fun()" );

[Bug target/64338] [5 Regression] ICE in swap_condition, at jump.c:628

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

ix86_expand_int_movcc is called there with (ltgt (reg:CCFPU flags) (const_int
0)) condition, and I see several issues with that:
1) the code assumes that reverse_condition (whatever kind of that) always
succeeds, which is not always true; we shouldn't swap things if we can't
reverse condition
2) for CCFP/CCFPU modes, we should treat them like floating point modes, LTGT
is reversible
3) in the first hunk, there are dead assignments:
compare_code = reverse_condition_maybe_unordered (compare_code);
and
compare_code = reverse_condition (compare_code);
when only a few lines below that there is unconditional:
compare_code = UNKNOWN;
4) (not handled in the patch), diff uses HOST_WIDE_INT variable, signed, and
the
values can be arbitrary, so we can end up with undefined behavior in the
compiler if cf - ct overflows, or if diff is HWI minimum on diff = -diff etc.

[Bug target/64507] SH inlined builtin strncmp doesn't return 0 for 0 length

[chrbr at gcc dot gnu.org]

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

--- Comment #4 from chrbr at gcc dot gnu.org ---
Actually, the code could be slightly better by factorizing the return sequences

;; check length
mov#0,r0
;; goto .l2
;; else init r1,r0
;; goto .l1
.l2:
rtx
nop
.l1:
rts
subr1,r0

into
   ;; check length
   mov r1,r0
   ;; goto l1
   ;; else init r1,r0
.l1:
   rts
   sub   r1,r0

however this creates an unitilized mov (which we don´t care) but the backend
keeps forcing an useless mov #0,r1

[Bug c/64509] _Generic throws error in unselected generic association

[maurits.de.jong at ericsson dot com]

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

--- Comment #4 from Martien de Jong  ---
I understand. What a shallow and ugly feature it is then. I think it can only
usefully be employed using a preprocessor macro, yet it is part of the 
expression syntax. It is meant to resolve type issues, yet all variants
should be type-sane. You can indeed implement something like tgmath.h with it,
but only if the types can be implictly converted.

BTW, I notice that

./gcc/ginclude/tgmath.h

uses

__builtin_classify_type
__builtin_types_compatible_p
__builtin_choose_expr

Will it move to using _Generic() ?

[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
This bug triggers several times when building binutils.
Ilya?

[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
This really worries me a lot, when -fcheck-pointer-bounds is not enabled, I'd
really hope that the ipa-chkp changes make no difference at all on the
generated code or order of passes.

[Bug ada/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).

[charlet at gcc dot gnu.org]

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

--- Comment #4 from Arnaud Charlet  ---
Author: charlet
Date: Wed Jan  7 10:15:18 2015
New Revision: 219290

URL: https://gcc.gnu.org/viewcvs?rev=219290&root=gcc&view=rev
Log:
2015-01-07  Vincent Celier  

* clean.adb: Minor error message change.

2015-01-07  Tristan Gingold  

PR ada/64349  
* env.c (__gnat_environ): Adjust for darwin9/darwin10.

2015-01-07  Javier Miranda  

* sem_ch10.adb (Analyze_With_Clause): Compiling under -gnatq
protect the frontend against never ending recursion caused by
circularities in the sources.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/clean.adb
trunk/gcc/ada/env.c
trunk/gcc/ada/sem_ch10.adb

[Bug ada/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

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

--- Comment #5 from Arnaud Charlet  ---
Fixed.

[Bug c/64518] Warning about comparison between signed and unsigned can be useless in some cases

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez  ---
Unfortunately, nobody so far has come up with any idea on how to fix this.

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

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||patrick.pelissier at gmail dot 
com

--- Comment #13 from Manuel López-Ibáñez  ---
*** Bug 64518 has been marked as a duplicate of this bug. ***

[Bug c/64515] Segmentation fault during linker operation in gcc for arm-none-eabi

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-01-07
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Preprocessed source is missing, but I think you should report this to your
vendor.  (And it's not a linker error.)

[Bug c++/64520] New: [4.8/4.9/5 Regression] ICE with std::initializer_list

[jakub at gcc dot gnu.org]

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

Bug ID: 64520
   Summary: [4.8/4.9/5 Regression] ICE with std::initializer_list
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org

namespace std {
  template  class initializer_list;
}
struct A {
  template  A(std::initializer_list);
};
A a { 0 };

ICEs with:
./cc1plus -quiet -std=c++0x rh1176446.ii
rh1176446.ii: In substitution of ‘template
A::A(std::initializer_list) [with B = ]’:
rh1176446.ii:7:9:   required from here
rh1176446.ii:7:9: internal compiler error: in unify, at cp/pt.c:18523
 A a { 0 };
 ^

starting with r179436.

[Bug c++/64521] New: [4.9/5 Regression] ICE with -frepo

[jakub at gcc dot gnu.org]

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

Bug ID: 64521
   Summary: [4.9/5 Regression] ICE with -frepo
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org

template  struct J { J(H); };
template  struct K;
template  struct K {};
template 
struct K : K, J {
  K(const H &p1, const T &... p2) : K(p2...), J(p1) {}
};
template  struct C : K<0, E...> {
  C(const E &... p1) : K<0, E...>(p1...) {}
};
template  struct A {
  A() = default;
};
struct M;
template  struct L {
  struct B {
template  static M *__test(...);
typedef A _Del;
typedef decltype(__test<_Del>()) type;
  };
  C> _M_t;
  L(typename B::type) : _M_t(0, A()) {}
};
struct M {};
void foo() { L(new M); }

ICEs starting with r206182 with -frepo -std=c++11.  Doesn't ICE without -frepo
or with r206181 or earlier.

[Bug c++/64520] [4.8/4.9/5 Regression] ICE with std::initializer_list

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.5

[Bug c++/64521] [4.9/5 Regression] ICE with -frepo

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3

[Bug fortran/64522] New: [4.8/4.9/5 Regression] Free-form source code: -Wline-truncation is no longer enabled by default

[burnus at gcc dot gnu.org]

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

Bug ID: 64522
   Summary: [4.8/4.9/5 Regression] Free-form source code:
-Wline-truncation is no longer enabled by default
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

Using GCC 4.4, a free-form source code which exceeds the 132 character limit
showed by default the message:
  "Warning: Line truncated at (1)"

Using GCC 4.8, 4.9 and 5, this message is only shown with -Wline-truncation
(which is implied by -Wall).

As other compilers by default use -ffree-line-length-none (unlimited line
length), it makes sense to show this warning by default - or even to error out.
Currently, it may lead to difficult-to-find bugs.


[GCC 4.4 did not show this warning by default for fixed-form source code, which
makes sense]

[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array

[paul.richard.thomas at gmail dot com]

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

--- Comment #11 from paul.richard.thomas at gmail dot com  ---
Hi Harald,

Happy New Year! I have been away in Claifornia these last few weeks and
just got back last night.

I am working with Andre on pr60255 tonight. Once this is done, we should be
in a position to fix pr55901 and have it do something useful!

Cheers

Paul

On 6 January 2015 at 20:50, anlauf at gmx dot de 
wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
>
> --- Comment #10 from Harald Anlauf  ---
> (In reply to paul.richard.tho...@gmail.com from comment #9)
> > By the way, the patch of comment 8 bootstraps and regtests OK
> >
> > Paul
>
> Hi Paul,
>
> any news on that patch?
>
> Harald
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug target/56025] ARM NEON polynomial types have broken overload resolution

[belagod at gcc dot gnu.org]

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

--- Comment #5 from Tejas Belagod  ---
ACLE states that

"poly8_t and poly16_t are defined as unsigned integer types. It is unspecified
whether these are the same type as uint8_t and  uint16_t for overloading and
mangling purposes"

Presently, poly types are implemented as distinct types in the ARM backend with
default mangling which is wrong. This obviates the need for their own mangling
scheme in the ABI which it does not specify. Therefore, it cannot be modelled
as a distinct type until the ABI says that it is a distinct type. Also, poly8_t
and poly16_t are presently modelled as signed types which is incorrect. When we
change this to an unsigned type, it will be incompatible with legacy anyway wrt
mangling among other things. So, till the time the ABI decides to make poly
types as distinct types, we can model it as an unsigned type or as another type
name for uint8_t or uint16_t. This will disallow overloading of uint8_t and
poly8_t for eg and break current overloads, but correcting poly to unsigned
type is a greater good. This is also future-proof because if the ABI decides to
model poly and unsigned types as distinct types, previously disallowed
overloading will then be allowed which isn't breaking legacy in the broad
sense.

[Bug middle-end/63510] Wrong line number in Wstrict-overflow message

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

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

--- Comment #3 from Chen Gang  ---
It still exists in gcc version 5.0.0 20141109 (experimental) (GCC), I shall try
to solve it.

Hope I can finish within 2 months.

[Bug testsuite/62250] FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single

[hp at gcc dot gnu.org]

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

--- Comment #8 from Hans-Peter Nilsson  ---
Created attachment 34394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34394&action=edit
Patch to add -latomic only when available; -p0 -d path/to/gcc/testsuite

David, could you please check if the attached patch still works for
hppa*-*-hpux*?

I've verified that it fixes the regressions I see (cross to cris-elf; a system
without a -latomic port and where the operations are built-in) and that
-latomic is still added for a native x86_64-unknown-linux-gnu build, with tests
still passing.  Though, as -latomic is redundant on that last system, I haven't
actually tested it on a system where -latomic is *required*; the point if this
PR (and BTW sorry for being lazy and hijacking it - a pointer to a new PR would
have been more appropriate).

[Bug c++/63658] [4.9 Regression] Using class reference as template parameter causes compilation to fail

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Jan  7 15:17:59 2015
New Revision: 219305

URL: https://gcc.gnu.org/viewcvs?rev=219305&root=gcc&view=rev
Log:
PR c++/63658
* pt.c (convert_nontype_argument): Call convert_from_reference.
(check_instantiated_arg): Don't be confused by reference refs.
(unify): Look through reference refs on the arg, too.
* mangle.c (write_template_arg): Look through reference refs.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/template/ref9.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/mangle.c
branches/gcc-4_9-branch/gcc/cp/pt.c

[Bug c++/63657] [4.9 regression] -Wunused-variable: warning supressed by virtual dtor

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Wed Jan  7 15:18:05 2015
New Revision: 219306

URL: https://gcc.gnu.org/viewcvs?rev=219306&root=gcc&view=rev
Log:
PR c++/63657
PR c++/38958
* call.c (set_up_extended_ref_temp): Set TREE_USED on the reference
if the temporary has a non-trivial destructor.
* decl.c (poplevel): Don't look through references.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/warn/Wunused-var-22.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/call.c
branches/gcc-4_9-branch/gcc/cp/decl.c

[Bug c++/38958] 'unused variable' warning emitted when extending the lifetime of a returned RAII type by holding a reference to const despite delayed destructor side-effects. [dtor]

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Wed Jan  7 15:18:05 2015
New Revision: 219306

URL: https://gcc.gnu.org/viewcvs?rev=219306&root=gcc&view=rev
Log:
PR c++/63657
PR c++/38958
* call.c (set_up_extended_ref_temp): Set TREE_USED on the reference
if the temporary has a non-trivial destructor.
* decl.c (poplevel): Don't look through references.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/warn/Wunused-var-22.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/call.c
branches/gcc-4_9-branch/gcc/cp/decl.c

[Bug c++/64029] [4.9 Regression] const int (&in)[]{1,2,3,4,5}; results in internal compiler error: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Jan  7 15:18:16 2015
New Revision: 219307

URL: https://gcc.gnu.org/viewcvs?rev=219307&root=gcc&view=rev
Log:
PR c++/64029
* decl.c (grok_reference_init): Complete array type.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/initlist89.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/decl.c

[Bug c++/64251] [5 Regression] Chromium build error only with --enable-checking=yes

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Jan  7 15:18:27 2015
New Revision: 219309

URL: https://gcc.gnu.org/viewcvs?rev=219309&root=gcc&view=rev
Log:
PR c++/64251
* decl2.c (mark_used): Don't mark if in_template_function.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/template/non-dependent14.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/decl2.c

[Bug c++/64297] [5 Regression] ICE: canonical types differ for identical types

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Jan  7 15:18:21 2015
New Revision: 219308

URL: https://gcc.gnu.org/viewcvs?rev=219308&root=gcc&view=rev
Log:
PR c++/64297
* typeck.c (apply_memfn_quals): Correct wrong TYPE_CANONICAL.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/ref-qual16.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/typeck.c

[Bug c++/64352] [5.0 regression] No SFINAE with deleted function

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Jan  7 15:18:32 2015
New Revision: 219310

URL: https://gcc.gnu.org/viewcvs?rev=219310&root=gcc&view=rev
Log:
PR c++/64352
* pt.c (tsubst_copy_and_build): Pass complain to mark_used.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/deleted9.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/pt.c

[Bug c++/64487] [4.8/4.9 Regression] internal compiler error: in fold_offsetof_1, at c-family/c-common.c:9857

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Jan  7 15:18:39 2015
New Revision: 219311

URL: https://gcc.gnu.org/viewcvs?rev=219311&root=gcc&view=rev
Log:
PR c++/64487
* semantics.c (finish_offsetof): Handle templates here.
* parser.c (cp_parser_builtin_offsetof): Not here.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/template/offsetof3.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/parser.c
branches/gcc-4_9-branch/gcc/cp/semantics.c

[Bug testsuite/62250] FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2015-01-07 10:03 AM, hp at gcc dot gnu.org wrote:
> David, could you please check if the attached patch still works for
> hppa*-*-hpux*?

I've added your patch to my hpux tree for testing.

[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #5 from Marek Polacek  ---
Seems like there's nothing to do for this bug.

[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to Marek Polacek from comment #5)
> Seems like there's nothing to do for this bug.

Suggest there are two cases

1. double to float

2. double or float into any integer type.

The one warning, produced by -Wfloat-conversion, could be
split into two warnings, as per the two cases.

#1 isn't very useful, #2 seems useful to me.

Then put case #1 into -Wall.

[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Reopening then.

[Bug c++/64520] [4.8/4.9/5 Regression] ICE with std::initializer_list

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-07
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Clang rejects the code, so I'm for now marking this ice-on-invalid-code.

[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array

[vehre at gmx dot de]

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

--- Comment #12 from Andre Vehreschild  ---
Hi Paul, hi Tobias,

I am guilty in asking both of you to look at the issue. I would be very happy,
if one of you two can really have a look into the issue and notify the other
one, that he found a reason for the issue and may be already has a solution. I
just want to get the issue resolved but not produce duplicate work.

Regards,
Andre


On Wed, 07 Jan 2015 13:16:25 +
"paul.richard.thomas at gmail dot com"  wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
> 
> --- Comment #11 from paul.richard.thomas at gmail dot com
>  --- Hi Harald,
> 
> Happy New Year! I have been away in Claifornia these last few weeks and
> just got back last night.
> 
> I am working with Andre on pr60255 tonight. Once this is done, we should be
> in a position to fix pr55901 and have it do something useful!
> 
> Cheers
> 
> Paul
> 
> On 6 January 2015 at 20:50, anlauf at gmx dot de 
> wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
> >
> > --- Comment #10 from Harald Anlauf  ---
> > (In reply to paul.richard.tho...@gmail.com from comment #9)
> > > By the way, the patch of comment 8 bootstraps and regtests OK
> > >
> > > Paul
> >
> > Hi Paul,
> >
> > any news on that patch?
> >
> > Harald
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> >
>

[Bug go/61204] gccgo: ICE in in fold_convert_loc [GoSmith]

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Jan  7 16:14:50 2015
New Revision: 219316

URL: https://gcc.gnu.org/viewcvs?rev=219316&root=gcc&view=rev
Log:
PR go/61204
* go-gcc.cc (Gcc_backend::temporary_variable): Don't initialize
zero-sized variable.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-gcc.cc

[Bug c++/64524] New: gcc can't detect same expression in both parts of ternary operator

[dcb314 at hotmail dot com]

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

Bug ID: 64524
   Summary: gcc can't detect same expression in both parts of
ternary operator
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Given this source code

extern void g(int);

void
f( int n)
{
int i = (n >= 10) ? 1 : 1;

g( i - 1);
}

then trunk gcc says nothing:

$ ~/gcc/results/bin/gcc -c -O2 -Wall -Wextra jan6c.cc
$ 

Here is cppcheck detecting the problem:

$ ~/cppcheck/trunk/cppcheck --enable=all jan6c.cc 
Checking jan6c.cc...
[jan6c.cc:9]: (style) Same expression in both branches of ternary operator.
$ 

Fixing this bug would find about a dozen bugs in Linux kernel
and about 100 bugs in Fedora Linux.

[Bug target/64525] New: Duplicate instructions in both paths in conditional code

[kugan at gcc dot gnu.org]

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

Bug ID: 64525
   Summary: Duplicate instructions in both paths in conditional
code
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org

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

gcc is generating the same instructions down both paths of conditional
execution. For exmaple, in the attached test case.

...
cmp r0, #0
movtr2, #:upper16:tree_code_length_0
ldr r0, [r2]
movweq  r2, #:lower16:permanent_obstack
movteq  r2, #:upper16:permanent_obstack
movwne  r2, #:lower16:permanent_obstack
moveq   r3, r2
movtne  r2, #:upper16:permanent_obstack
...

[Bug target/64525] Duplicate instructions in both paths in conditional code

[kugan at gcc dot gnu.org]

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

--- Comment #1 from kugan at gcc dot gnu.org ---
compiler options:
arm-none-linux-gnueabi-gcc -O3 -S test.c


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

[Bug c++/64524] gcc can't detect same expression in both parts of ternary operator

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Should it complain only when the expressions are the same (e.g. token-wise), or
even when just two different expressions have the same value?
I mean, say:
enum X { E = 5, F = 5 };
int i = cond ? E : F;
int j = cond ? x + 3 : x + 2 + 1;
int k = cond ? sizeof (x) : sizeof (y);
etc.

[Bug c++/64524] gcc can't detect same expression in both parts of ternary operator

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
(In reply to Jakub Jelinek from comment #1)
> Should it complain only when the expressions are the same (e.g. token-wise),
> or even when just two different expressions have the same value?
> I mean, say:
> enum X { E = 5, F = 5 };
> int i = cond ? E : F;
> int j = cond ? x + 3 : x + 2 + 1;
> int k = cond ? sizeof (x) : sizeof (y);
> etc.

All would be good ;->

I suspect token-wise comparison would be simple and cheap, so 
suggest do that first. That would cover my example.

I suspect more complex would be making sure two compile time
constants have the same value, so suggest do that second.
That would cover cases i and k above.

Suspect case j would be more difficult, since it involves
expression comparison. Suggest leave till last.

Feel free to adjust the priority order if my guesses are wrong.

[Bug c++/64524] gcc can't detect same expression in both parts of ternary operator

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to David Binderman from comment #2)
Well, tokenwise comparison is difficult, as lots of things are folded early.
So if you don't mind the same value as folding, implementing that wouldn't be
that hard.

[Bug c/64526] New: No warning on function call with excessive arguments

[chengniansun at gmail dot com]

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

Bug ID: 64526
   Summary: No warning on function call with excessive arguments
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

GCC does not warn on the following function call to "fn1". The function "fn1"
is defined with no parameters. Based on the standard, the empty parameter list
in a function declarator that is part of a definition of that function
specifies that the function has no parameters. 


$ cat test.c

void fn1 () {}

void fn2 (int p) {  fn1 (p); }

$ gcc-trunk -Wall -Wextra -pedantic -std=c11 -c test.c

$ clang-trunk -c test.c

test.c:2:27: warning: too many arguments in call to 'fn1'

void fn2 (int p) {  fn1 (p); }

~~~   ^

1 warning generated.

$

[Bug c/64526] No warning on function call with excessive arguments

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rth at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Richard Henderson  ---
Not a bug -- fn1 is not a function with no arguments,
but an unprototyped function.  To get a function with
no arguments you must write

void fn1 (void) {}

This is C, not C++.

[Bug c++/64527] New: Constructor for empty struct not called in some situations

[gcc at swtaarrs dot com]

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

Bug ID: 64527
   Summary: Constructor for empty struct not called in some
situations
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at swtaarrs dot com

Created attachment 34396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34396&action=edit
c++ code exposing the bug

Build ctor.cpp with the following command:

> g++ -std=c++11 -Os -S -o ctor.S ctor.cpp

The optimization level doesn't appear to affect the presence of the bug, I just
used -Os to keep the output more compact.

Expected results: The m() function in ctor.S should contain a call to A::A().

Actual results: m() does nothing but zero out accessor::x. I've found at least
three ways to perturb the bug out of existence which are documented in comments
in the file.

The bug is also present in gcc 4.8.1 (I haven't tried anything older).

Compiling with -Wextra reports "warning: missing initializer for member
‘accessor::a’ [-Wmissing-field-initializers]" but I believe this shouldn't
affect the ouput.


gcc build info:

Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/matthew/gcc-4.9.0-prefix
Thread model: posix
gcc version 4.9.0 (GCC)

[Bug tree-optimization/64528] New: [5 Regression] ICE: in process_constraint, at tree-ssa-structalias.c:3002 with -O -fno-tree-ccp -fno-tree-dce

[zsojka at seznam dot cz]

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

Bug ID: 64528
   Summary: [5 Regression] ICE: in process_constraint, at
tree-ssa-structalias.c:3002 with -O -fno-tree-ccp
-fno-tree-dce
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 34397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34397&action=edit
reduced testcase (from gfortran.dg/value_test.f90)

Compiler output:
$ gcc -O -fno-tree-ccp -fno-tree-dce testcase.f90 
testcase.f90:11:0:

 end program valueTests
 ^
internal compiler error: in process_constraint, at tree-ssa-structalias.c:3002
0xe7907d process_constraint
/mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:3002
0xe793b3 process_all_all_constraints
/mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:3581
0xe84cd3 find_func_aliases
/mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:4748
0xe87c26 compute_points_to_sets
/mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:6825
0xe87c26 compute_may_aliases()
/mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:7161
0xbbd8ec execute_function_todo
/mnt/svn/gcc-trunk/gcc/passes.c:1912
0xbbe563 execute_todo
/mnt/svn/gcc-trunk/gcc/passes.c:1997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r219277 - ICE
r218446 - ICE
r212099 - ICE
4_9 r219040 - OK

[Bug c++/64524] gcc can't detect same expression in both parts of ternary operator

[maltsevm at gmail dot com]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||maltsevm at gmail dot com

--- Comment #4 from Mikhail Maltsev  ---
> int k = cond ? sizeof (x) : sizeof (y);
By the way, this is a good example of probable "false positives". Consider:

constexpr std::size_t max_size = (sizeof(T1) > sizeof(T2)) ? sizeof(T1) :
sizeof(T2);

This is an example of "legal" code, it could be used for allocating a buffer
which could hold either object of type T1 or type T2. These sizes may be
platform-dependent (or they may depend on template parameters), so this code
makes sence, but it will produce a warning when sizes are equal.

So, probably this warning only makes sence, if ASTs' would be compared, not the
values.

[Bug c++/60753] Deleted definition of an explicit function template specialization, following a declaration, incorrectly accepted

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug c++/64029] [4.9 Regression] const int (&in)[]{1,2,3,4,5}; results in internal compiler error: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 4.9.3.

[Bug c++/64529] New: Noexcept New

[olafvdspek at gmail dot com]

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

Bug ID: 64529
   Summary: Noexcept New
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olafvdspek at gmail dot com

Lots of programs abort / terminate when new fails to allocate memory. Would it
be possible to have an option to make new noexcept, possibly allowing more
optimizations as noexcept will have a ripple effect?

[Bug c++/64524] gcc can't detect same expression in both parts of ternary operator

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
This is also a style warning.  And really here is another false positive:
#define a 1
#define b 1

int t = c > d ? a : b;

[Bug middle-end/59354] Unexpected result in g++ when casting int to char from an stl vector to an array

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-07
 CC||ville.voutilainen at gmail dot 
com
  Component|c++ |middle-end
 Ever confirmed|0   |1

--- Comment #2 from Ville Voutilainen  ---
Moving to middle-end.

[Bug c++/64524] gcc can't detect same expression in both parts of ternary operator

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to Andrew Pinski from comment #5)
> And really here is another false positive:
> #define a 1
> #define b 1
> 
> int t = c > d ? a : b;

Assuming you meant

int t = (c > d) ? a : b;

then I'd be interested to find out how that's a false positive.

Just to add some salt into the pot, another interesting case might be

enum E { a, b, c, d };

void f(int val)
{
int n = (val >= 10) ? a : (d - 4);

[Bug c++/64524] gcc can't detect same expression in both parts of ternary operator

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
(In reply to David Binderman from comment #6)

Sorry, typo in my original code. Better code:

enum E { a, b, c, d };

void f(int val)
{
int n = (val >= 10) ? a : (d - 3);
}

[Bug c++/64527] Constructor for empty struct not called in some situations

[gcc at swtaarrs dot com]

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

--- Comment #1 from Brett Simmers  ---
Sorry, the attachment should be named ctor.cpp. I didn't realize it was a
filename and not a text description.

[Bug fortran/64530] New: [4.9 Regression] Incorrect calculation when assigning to array with -O3

[jkaus at ucsd dot edu]

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

Bug ID: 64530
   Summary: [4.9 Regression] Incorrect calculation when assigning
to array with -O3
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jkaus at ucsd dot edu

Created attachment 34398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34398&action=edit
Minimal example illustrating the issue.

With gfortran 4.9 using -O3, the assignment to an array
can occur before the rest of the calculation, giving
an incorrect result. I have attached a minimal example
which shows the bug along with modified code that 
produces the correct results.

With O3 we get the wrong result (0.0):
gfortran -O3 a.F90
./a.out
> buggy   0.0.
> 0. 
> works   3.50003.5000
> 3.5000  

With O2 we get the correct result (3.5):
gfortran -O2 a.F90
./a.out 
> buggy   3.50003.5000
> 3.5000 
> works   3.50003.50003.500

gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-0ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-0ubuntu1~12.04)

[Bug c++/64531] New: `casting between pointer-to-function and pointer-to-object` is still a warning instead of error with `-pedantic -pedantic-errors`

[iamsupermouse at mail dot ru]

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

Bug ID: 64531
   Summary: `casting between pointer-to-function and
pointer-to-object` is still a warning instead of error
with `-pedantic -pedantic-errors`
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamsupermouse at mail dot ru

`-pedantic` causes g++ to emit a warning `ISO C++ forbids casting between
pointer-to-function and pointer-to-object` on this code:

int main()
{
(void (*)()) (void *) 0;
}

I would expect `-pedantic -pedantic-errors` to generate a error with the same
message on this code, but it's still a warning.

[Bug target/37440] [4.8/4.9/5 Regression] GNAT Bug Box a-ngcefu.adb:397

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #17 from Joel Sherrill  ---
This is fixed on at least the 4.9 branch. I successfully built arm-rtems on
that.

Closing.

[Bug fortran/56867] Missing temporary with string array assignment

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Jan  7 22:31:54 2015
New Revision: 219325

URL: https://gcc.gnu.org/viewcvs?rev=219325&root=gcc&view=rev
Log:
2015-01-08  Thomas Koenig  

Backport from trunk
PR fortran/56867
* trans-array.c (gfc_conv_resolve_dependencies):  Also check
dependencies when there may be substrings of character arrays.

2014-01-08  Thomas Koenig  

PR fortran/56867
* gfortran.dg/dependency_45.f90:  New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/dependency_45.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/trans-array.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/64530] [4.9 Regression] Incorrect calculation when assigning to array with -O3

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #1 from Harald Anlauf  ---
(In reply to jkaus from comment #0)
> With O3 we get the wrong result (0.0):
> gfortran -O3 a.F90
> ./a.out
> > buggy   0.0.
> > 0. 
> > works   3.50003.5000
> > 3.5000  

Interesting bug.  I can confirm that it does not occur with 4.8,
but with 4.9 and 5.

Note that if one interchanges in subroutine "buggy" the lines

old(i) = ave(i)
tmp(i) = tmp(i) / scale_factor

to

tmp(i) = tmp(i) / scale_factor
old(i) = ave(i)

I also get the correct result.

With gfortran 4.9 and 5 I also get the correct result with -O3
when e.g. using UBSAN (-fsanitize=undefined); it probably also
reduces the optimization.

Since the dump tree looks the same for 4.8 and 4.9, could it be
a middle-end bug?

[Bug fortran/64530] [4.9 Regression] Incorrect calculation when assigning to array with -O3

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
(1) The problem goes away if the code is compiled with '-O3
-fno-tree-loop-vectorize'.
(2) The bug appeared between r204000 (OK, 2013-10-24) and r204945 (buggy,
2013-11-18).

[Bug c/64526] No warning on function call with excessive arguments

[chengniansun at gmail dot com]

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

Chengnian Sun  changed:

   What|Removed |Added

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

--- Comment #2 from Chengnian Sun  ---
(In reply to Richard Henderson from comment #1)
> Not a bug -- fn1 is not a function with no arguments,
> but an unprototyped function.  To get a function with
> no arguments you must write
> 
> void fn1 (void) {}
> 
> This is C, not C++.


Thanks for your reply. But I am still puzzled by a paragraph in the standard
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):

-- C11 standard, sec 6.7.6.3, page 134 --
14. An identifier list declares only the identifiers of the parameters 
of the function. An empty list in a function declarator that is part of 
a definition of that function specifies that the function has no 
parameters. The empty list in a function declarator that is not part of 
a definition of that function specifies that no information about 
the number or types of the parameters is supplied.
- END ---


So if I understand it correctly, the function "fn1" does not have any
parameters. Please kindly advise. Thanks.

[Bug rtl-optimization/64532] New: [5 regression on ARM]internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[pangbw at gmail dot com]

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

Bug ID: 64532
   Summary: [5 regression on ARM]internal compiler error: Max.
number of generated reload insns per insn is achieved
(90)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pangbw at gmail dot com

I know this ICE has been reported many times, but I still want to report it
again because I am not sure if my case is same as other reported cases.

Steps to reproduce:
1. cat y.i

__attribute__((noinline)) float s32_to_f32_imm1(int x)
{
  float y;
  __asm__ ("vcvt.f32.s32 %0, %1, #1" : "=w"(y) : "0"(x));
  return y;
}

2. ./xgcc y.i -B.  -mfloat-abi=hard  -mfpu=neon -O2
y.i: In function ‘s32_to_f32_imm1’:
y.i:6:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)

 }
 ^
0x973325 lra_constraints(bool)
../../../gcc/gcc/lra-constraints.c:4306
0x95f689 lra(_IO_FILE*)


This is the GCC used by me:
./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-linux-gnueabi
Configured with: ../../gcc/configure --target=arm-linux-gnueabi
Thread model: posix
gcc version 5.0.0 20150107 (experimental) (GCC)

[Bug ada/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Dominique d'Humieres  ---
I still get

ld: warning: can't add line info to anonymous symbol __const@0 from s-arit64.o

for r219318 on x86_64-apple-darwin10 (I have bootstrapped r219067 with Iain's
patch at https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01753.html).

[Bug rtl-optimization/64532] [5 regression on ARM]internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[pangbw at gmail dot com]

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

baoshan  changed:

   What|Removed |Added

 CC||pangbw at gmail dot com

--- Comment #1 from baoshan  ---
One observation is that without "-mfloat-abi=hard  -mfpu=neon", I will get
this:

./xgcc y.i -B.   -O2
y.i: In function ‘s32_to_f32_imm1’:
y.i:4:3: error: inconsistent operand constraints in an ‘asm’
   __asm__ ("vcvt.f32.s32 %0, %1, #1" : "=w"(y) : "0"(x));

[Bug tree-optimization/64530] [4.9 Regression] Incorrect calculation when assigning to array with -O3

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|fortran |tree-optimization
  Known to work||4.8.5
  Known to fail||4.9.2, 5.0

--- Comment #3 from Dominique d'Humieres  ---
> Since the dump tree looks the same for 4.8 and 4.9, could it be
> a middle-end bug?

Indeed! reassigned to tree optimization.

[Bug c/64526] No warning on function call with excessive arguments

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
"has no parameters" does not mean "has a type that includes a prototype 
with no parameters".  See DR#317.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_317.htm

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #6 from Hans-Peter Nilsson  ---
(FWIW, I think Andrew is missing the discussion on gcc@ regarding fixing this
so that it is true to the documentation, as being preferable by e.g. Richi to
removing it from the documentation.)

[Bug target/64533] New: [5 Regression] [SH] alloca generates unsafe code

[kkojima at gcc dot gnu.org]

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

Bug ID: 64533
   Summary: [5 Regression] [SH] alloca generates unsafe code
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
Target: sh*-*-*

The trunk compiler compiles

  void *foo() { return alloca (0x400);}

to

foo:
mov.l   r14,@-r15
mov r15,r1
mov r15,r14
mov.w   .L2,r15(*)
add r1,r15
mov r15,r0
mov r14,r15
rts
mov.l   @r15+,r14
.align 1
.L2:
.short  -1028

with -O2.
r15 has been set -1028 at (*) which isn't always safe.  For example
sh-linux uses the negative stack values for software roll-back and
I've got a few sporadic and unreproducible errors on libjava testsuite
because of this.  I've introduced a splitter which splits rA := rB + N
to rA := N and rA := rA + rB for LRA's register elimination phase.
It should take rA=r15 case into account.  I'm testing the patch below.

--- config/sh/sh.md
+++ config/sh/sh.md
@@ -2061,9 +2061,10 @@
 ;; The problem is that LRA expects something like
 ;;(set rA (plus rB (const_int N)))
 ;; to work.  We can do that, but we have to split out an additional reg-reg
-;; copy before the actual add insn.
+;; copy before the actual add insn.  Use u constraint for that case to avoid
+;; the invalid value in the stack pointer.
 (define_insn_and_split "*addsi3_compact"
-  [(set (match_operand:SI 0 "arith_reg_dest" "=r,&r")
+  [(set (match_operand:SI 0 "arith_reg_dest" "=r,&u")
 (plus:SI (match_operand:SI 1 "arith_operand" "%0,r")
  (match_operand:SI 2 "arith_or_int_operand" "rI08,rn")))]
   "TARGET_SH1

[Bug target/36557] -m32 -mpowerpc64 produces better code than -m64 for a!=0

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Thu Jan  8 03:46:41 2015
New Revision: 219336

URL: https://gcc.gnu.org/viewcvs?rev=219336&root=gcc&view=rev
Log:
PR target/36557
* config/rs6000/rs6000.md (*eqsi3_ext, *nesi3_ext): New.

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

[Bug rtl-optimization/64532] [5 regression on ARM]internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #2 from kugan at gcc dot gnu.org ---
x is an integer "w" floating point constraint. I think you need a cast here as
below.

__attribute__((noinline)) float s32_to_f32_imm1(int x)
{
  float y;
  __asm__ ("vcvt.f32.s32 %0, %1, #1" : "=w"(y) : "0"((float)x));
  return y;
}

[Bug rtl-optimization/64532] [5 regression on ARM]internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to kugan from comment #2)
> x is an integer "w" floating point constraint. I think you need a cast here
> as below.
> 
> __attribute__((noinline)) float s32_to_f32_imm1(int x)
> {
>   float y;
>   __asm__ ("vcvt.f32.s32 %0, %1, #1" : "=w"(y) : "0"((float)x));
>   return y;
> }

Why w means the floating point register.  The instruction vcvt.f32.s32 converts
from signed 32bit int to a 32bit floating point (with an optional shift).  The
inline-asm is correct and 100% valid.