[Bug libstdc++/60724] std::ostream o; gives protected errors

[jmichae3 at yahoo dot com]

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

Jim Michaels  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Jim Michaels  ---
there is an ugly solution available involving multiple lines of statements and
possibly multiple inheritance depending on needs.
problem is, those solutions seem to be copyrighted and made impossible to use
for commercial purposes.

[Bug c++/60714] comments in template instantiation are interpreted

[jmichae3 at yahoo dot com]

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

--- Comment #2 from Jim Michaels  ---
I looked inside the class to derive that.
maybe I made a mistake.

[Bug fortran/60495] [4.9 Regression] ICE: in fold_convert_loc, at fold-const.c:1994

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
Looks similar to PR60495; the patch there (committed) solved the ICE problem
but the following issue remains (with both PRs): undefined reference to
`__final_a_T2.2437'

[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together

[jmichae3 at yahoo dot com]

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

Jim Michaels  changed:

   What|Removed |Added

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

--- Comment #13 from Jim Michaels  ---
there is an ugly solution that involves using a constructor and possibly
multiple inheritance. and several lines of statements.

[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together

[glisse at gcc dot gnu.org]

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

--- Comment #12 from Marc Glisse  ---
Before saying that there is a problem with libstdc++, did you try other
implementations? clang++ with libc++ gives the same error. That's just not how
streams are supposed to be used (pretend it is a pure virtual base class if
that helps), please invest in a book.

[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together

[jmichae3 at yahoo dot com]

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

Jim Michaels  changed:

   What|Removed |Added

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

--- Comment #11 from Jim Michaels  ---
those "protected" errors also prevent std::regex from working.

std::ostream o;
causes a protected error. something is really wrong here with libstdc++'s
iostreams.

[Bug fortran/60717] Wrong code with recursive procedure with unlimited polymorphic dummy argument

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Created attachment 32509
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32509&action=edit
Patch for the PR

This patch bootstraps and regtests OK. I will tidy it up a bit tonight.

I also wish to check if it can be used to clean up:

trans-expr.c(gfc_trans_alloc_subarray_assign)
trans-expr.c(gfc_trans_pointer_assign)
trans-expr.c(fncall_realloc_result)
trans-array.c(trans_associate_var)

each of which contains calculation of the offset.

Paul

[Bug target/60617] [4.8 Regression] unable to find a register to spill in class 'LO_REGS'

[venkataramanan.kumar at amd dot com]

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

Venkataramanan  changed:

   What|Removed |Added

 CC||venkataramanan.kumar at amd 
dot co
   ||m

--- Comment #2 from Venkataramanan  ---
This bug occurrs with GCC trunk as well with IRA and reload. 
Can be reproduced with -std=c++11 -fno-tree-dce -fno-omit-frame-pointer -O2
-mno-lra.

[Bug libstdc++/60724] std::ostream o; gives protected errors

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fails in GCC 4.4.5 and GCC 4.7.0 with the same error message.

Why don't you use ostringstream or wostringstream instead?

[Bug libstdc++/60724] std::ostream o; gives protected errors

[jmichae3 at yahoo dot com]

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

--- Comment #2 from Jim Michaels  ---
Created attachment 32508
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32508&action=edit
errors in a file

[Bug libstdc++/60724] std::ostream o; gives protected errors

[jmichae3 at yahoo dot com]

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

--- Comment #1 from Jim Michaels  ---
Created attachment 32507
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32507&action=edit
ostream-bug.cpp

source code ostream-bug.cpp

[Bug preprocessor/60723] Line directives with incorrect system header flag

[nicholas.ormrod at hotmail dot com]

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

--- Comment #3 from Nicholas  ---
Created attachment 32505
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32505&action=edit
Repro source

[Bug preprocessor/60723] Line directives with incorrect system header flag

[nicholas.ormrod at hotmail dot com]

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

--- Comment #2 from Nicholas  ---
Created attachment 32504
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32504&action=edit
Repro header

[Bug preprocessor/60723] Line directives with incorrect system header flag

[nicholas.ormrod at hotmail dot com]

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

--- Comment #1 from Nicholas  ---
The preprocessor emits line directives with the system-header flag when using
complicated macros. This causes certain warnings, like -Wswitch and -Wreorder,
to be suppressed.

This report includes a patch as well as a detailed description.


== Reproduction Steps ==

Preprocessing must be done in a separate phase.

There must be a function-like macro which:

  (1) Is called with a newline inside of its arguments list
  (2) Is defined in a system header
  (3) Expands to contain a builtin macro followed by a non-builtin token


A minimal reproduction is attached. Compiling 'src.cpp' produces a div-by-zero
warning when compiled by "g++ -isystem. src.cpp". No warning is emitted when
preprocessing is split, such as with "g++ -isystem. -no-integrated-cpp
src.cpp".

== Cause ==

The preprocessed output of 'src.cpp' shows that a line directive is being
inserted after the __FILE__ macro, and that that directive is flagging
'src.cpp' as a system file (using the flag '3').

In a function-like macro expansion, regular tokens are line-marked as being
expanded at the opening parenthesis, while builtins are line-marked as being
expanded at the closing parenthesis (both of these choices are reasonable,
though the inconsistency is probably a design flaw). When a non-builtin follows
a builtin in a multiline macro call, the line numbers of the tokens are
inconsistent, forcing a line directive to be inserted.


== Details ==

This bug was occurring in our code base. We use ccache (which preprocesses
independently of main compilation) and gflags (which has sufficiently
complicated macros).

Testing was done on 4.9.

Git bisect blames 611f1003dbf4ebb341c2eda0fcc0e058c421eb6b (4.8.0 20120430),
authored by dodji on Mon Apr 30 11:43:43 2012 +. However, that diff does
not seem to be the root cause.

gcc -v

Using built-in specs.
COLLECT_GCC=./igpp
COLLECT_LTO_WRAPPER=/data/users/njormrod/src/gcc/_builds/39706bc97269366073d2eb4cf3ecf7872513627d/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../src/configure
--prefix=/data/users/njormrod/src/gcc/_builds/39706bc97269366073d2eb4cf3ecf7872513627d
--with-gmp=[local gmp-5.0.1] --with-mpfr=[local mpfr-3.0.0] --with-mpc=[local
mpc-0.8.2] --disable-multilib --enable-languages=c,c++ --disable-libgcj
--disable-bootstrap --disable-static
Thread model: posix
gcc version 4.9.0 20140331 (experimental) (GCC)

[Bug preprocessor/60723] New: Line directives with incorrect system header flag

[nicholas.ormrod at hotmail dot com]

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

Bug ID: 60723
   Summary: Line directives with incorrect system header flag
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicholas.ormrod at hotmail dot com

Created attachment 32503
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32503&action=edit
Proposed Patch

[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together

[jmichae3 at yahoo dot com]

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

--- Comment #10 from Jim Michaels  ---
learned about std::streambuf.
when I went to use it (apparently a requirement in some cases and the only
thing that works for std::ostream now), the whole streambuf heirarchy is
protected except for std::filebuf, which is useless for just a plain old
ostream.

so, it seems, std::ostream is protected so I can't use it. stdstringbuf is
protected, making it useless.

at least put some examples in the standard c++ library documentation so mortals
know how to use this seemingly impossible new class heirarchy so I can do what
would seem to be simple things.

in the template defs, I see 
extern ostream cout;

but if I try do
std::ostream o; 
I get protected errors. this used to work. tried it with streambuf, streambuf
and stringbuf is protected now so I can't use them.

is 4.9.0 just buggy because it's hasn't been released yet?

I think the "this is not a bug" messages are bogus. streams are throrouhly
broken in x86_64-4.9.0-snapshot-20140219-rev207854-win32-sjlj-rt_v4 due to
overmuch protection.

f:\x86_64-4.9.0-snapshot-20140219-rev207854-win32-sjlj-rt_v4\mingw64\x86_64-w64-mingw32\include\c++\streambuf:463:7:
error: 'std::basic_streambuf<_CharT, _Traits>::basic_streambuf() [with _CharT =
char; _Traits = std::char_traits]' is protected
grep.cpp:21:16: error: within this context

I am just saying something smells like a compiler bug here.

[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Created attachment 32502
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32502&action=edit
.s file for hppa64-hp-hpux11.11

On hppa64-hp-hpux11.11, I don't see any debug information at all unless
I add "-g" to compile options.

[Bug c++/44859] missed warning: returning reference to temporary

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Tue Apr  1 00:48:33 2014
New Revision: 208970

URL: http://gcc.gnu.org/viewcvs?rev=208970&root=gcc&view=rev
Log:
PR c++/44859
* typeck.c (maybe_warn_about_returning_address_of_local): Unwrap
COMPONENT_REFs and ARRAY_REFs sooner.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wreturn-local-addr-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug target/45263] registers used in __do_global_ctors can get clobbered

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||bobf at mrp3 dot com

--- Comment #18 from Georg-Johann Lay  ---
*** Bug 60247 has been marked as a duplicate of this bug. ***

[Bug target/60247] AVR ATxmega C++ constructor startup in libgcc.S causes boot loop

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Georg-Johann Lay  ---
(In reply to bobf from comment #3)
>> 4.7 is the oldest supported release series.  4.5 is no more supported.
> 
> it's currently being used in the FreeBSD ports system, though.  Thanks.

If you want it in 4.5.1, you must suport your own gcc 4.5 and backport whatever
you like, e.g. for this one: r187058 which is the backport of PR45263 to 4.5.4.
 Thus, you can also upgrade to 4.5.4 (or 4.6.1 or newer).

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

[Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10

[rth at gcc dot gnu.org]

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

--- Comment #2 from Richard Henderson  ---
Created attachment 32501
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32501&action=edit
possible patch

This seems to work for the testcase.
Full testing still in progress.

[Bug target/60247] AVR ATxmega C++ constructor startup in libgcc.S causes boot loop

[bobf at mrp3 dot com]

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

--- Comment #3 from bobf at mrp3 dot com ---
> --- Comment #2 from Georg-Johann Lay  ---
> Are you sure this is not already fixed by PR45263?  Or in version 4.7 and
> newer?

it might be - I saw something in the ubuntu libc package [after filing 
this] that suggests that a fix may have been applied to later versions 
[I think I added a reference to this for the PR, and if not I should 
have after I discovered it].

> 4.7 is the oldest supported release series.  4.5 is no more supported.

it's currently being used in the FreeBSD ports system, though.  Thanks.

[Bug libstdc++/60270] [C++1y] std::quoted is too eager to clear the string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
fixed

[Bug libstdc++/60270] [C++1y] std::quoted is too eager to clear the string

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 31 18:46:23 2014
New Revision: 208966

URL: http://gcc.gnu.org/viewcvs?rev=208966&root=gcc&view=rev
Log:
2014-03-31  Lars Gullik Bjønnes  
Jonathan Wakely  

PR libstdc++/60270
* include/std/iomanip (_Quoted_string operator>>): Do not clear
string if input is not quoted.
* testsuite/27_io/manipulators/standard/char/60270.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/manipulators/standard/char/60270.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/iomanip

[Bug tree-optimization/60707] FAIL: gfortran.dg/pr45636.f90 -O scan-tree-dump-times forwprop2 "memset" 0

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 3/31/2014 4:27 AM, rguenth at gcc dot gnu.org wrote:
> Already xfailed for mips.  You may want to check history to see if it's
> applicable to xfail on hppa as well.
I just noticed that this bug may have been recently fixed.  Test
didn't fail on last hppa2.0w-hp-hpux11.11 build.

Need to check whether it is also fixed on linux.

Looking at history, I didn't get a clear answer as to whether xfail 
should apply to hppa as well.

[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills

[yvan.roux at linaro dot org]

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

--- Comment #9 from Yvan Roux  ---
the new command line is :

cc1 -O2 -fno-omit-frame-pointer -march=armv7-a  xfs_bmap_util.i

[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills

[yvan.roux at linaro dot org]

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

--- Comment #8 from Yvan Roux  ---
Created attachment 32500
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32500&action=edit
2nd reduced testcase

[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||filip.roseen at gmail dot com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 60715 has been marked as a duplicate of this bug. ***

[Bug c++/60715] Narrowing conversions not caught in non-type template parameters

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Yep, thanks!

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

[Bug c++/60715] Narrowing conversions not caught in non-type template parameters

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #1)
> I'm pretty sure there's an existing bug report about this

Agreed. What about bug 57891?

[Bug c++/60709] [C++11]ICE when using a braced-init-list as function argument to initialize a reference to array

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The problem also exists for gcc 4.9.0 trunk.

[Bug target/60247] AVR ATxmega C++ constructor startup in libgcc.S causes boot loop

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target|ATxmega processor   |avr
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-03-31
 CC||gjl at gcc dot gnu.org
  Component|libgcc  |target
 Ever confirmed|0   |1
  Build|avr-gcc port under FreeBSD  |x86_64

--- Comment #2 from Georg-Johann Lay  ---
Are you sure this is not already fixed by PR45263?  Or in version 4.7 and
newer?

4.7 is the oldest supported release series.  4.5 is no more supported.

What do you man by "does not preserve registers before calling constructors"?  

The only registers that must be saved are the call-clobbered registers, because
the ABI requires that the callee (constructor) is saving / restoring the
call-saved registers.

If you clobber an SFR like RAMP* or EIND, you must restore them by hand. EIND
must not be changes after .init1 and RAMP* is only saved / restored in ISRs,
cf.notes in the respective manual section:

http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html


__do_global_dtors uses R16, R17, R28, R29 across constructor calls, all of
which are callee-saved.  And before the constructor is called, RAMPZ is reset
to 0.

I don't see anything that's wrong there.

[Bug c++/60716] gcc cannot detect static recursive function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |c++

--- Comment #2 from Marek Polacek  ---
The C FE warns, but not C++ FE.
u2.C:1:12: warning: ‘f’ defined but not used [-Wunused-function]
 static int f( int n)
^

[Bug c/60654] format warnings don't work with PROGMEM/PSTR

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #3 from Georg-Johann Lay  ---
External links are not helpful, a bug report should be self contained, c.f. the
bug reporting instructions at

http://gcc.gnu.org/bugs/#report




The usual definitions for the above macros are:

#define PROGMEM __attribute__((__progmem__))

#define PGM_P const char *
#define PSTR(s) (__extension__({static const char __c[] PROGMEM = (s);
&__c[0];}))

[Bug target/60700] [4.8 Regression] missing dependency between %ax and %eax when compiling 32bit on 64bit

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed.

[Bug target/60700] [4.8 Regression] missing dependency between %ax and %eax when compiling 32bit on 64bit

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Mar 31 16:24:28 2014
New Revision: 208964

URL: http://gcc.gnu.org/viewcvs?rev=208964&root=gcc&view=rev
Log:
Add a testcase for PR rtl-optimization/60700

PR rtl-optimization/60700
* gcc.target/i386/pr60700.c: New test.

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

[Bug rtl-optimization/57637] [4.9 regression] Miscompare on 178.galgel in SPEC2000 on arm

[hjl at gcc dot gnu.org]

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

--- Comment #11 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Mar 31 16:21:30 2014
New Revision: 208963

URL: http://gcc.gnu.org/viewcvs?rev=208963&root=gcc&view=rev
Log:
Backport revision 201326

gcc/

PR rtl-optimization/60700
2013-07-30  Zhenqiang Chen  

PR rtl-optimization/57637
* function.c (move_insn_for_shrink_wrap): Also check the
GEN set of the LIVE problem for the liveness analysis
if it exists, otherwise give up.

gcc/testsuite/

PR rtl-optimization/60700
2013-07-30  Zhenqiang Chen  

* gcc.target/arm/pr57637.c: New testcase.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/arm/pr57637.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/function.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/60700] [4.8 Regression] missing dependency between %ax and %eax when compiling 32bit on 64bit

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Mar 31 16:21:30 2014
New Revision: 208963

URL: http://gcc.gnu.org/viewcvs?rev=208963&root=gcc&view=rev
Log:
Backport revision 201326

gcc/

PR rtl-optimization/60700
2013-07-30  Zhenqiang Chen  

PR rtl-optimization/57637
* function.c (move_insn_for_shrink_wrap): Also check the
GEN set of the LIVE problem for the liveness analysis
if it exists, otherwise give up.

gcc/testsuite/

PR rtl-optimization/60700
2013-07-30  Zhenqiang Chen  

* gcc.target/arm/pr57637.c: New testcase.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/arm/pr57637.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/function.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

[Bug target/60700] [4.8 Regression] missing dependency between %ax and %eax when compiling 32bit on 64bit

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Mar 31 15:24:56 2014
New Revision: 208962

URL: http://gcc.gnu.org/viewcvs?rev=208962&root=gcc&view=rev
Log:
Add a testcase for PR rtl-optimization/60700

PR rtl-optimization/60700
* gcc.target/i386/pr60700.c: New test.

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

[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills

[yvan.roux at linaro dot org]

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

--- Comment #7 from Yvan Roux  ---
The same kind of issue is reported on the same build, but with a different set
of options. I'm reducing the testcase (still too big...)

[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
Created attachment 32499
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32499&action=edit
Reduced Fortran test case (use .f or .f90 suffix)

Reduced test case attached. Compile on arm-linux-gnueabihf with "gfortran -O1";
works with "gfortran -O0".

[Bug c/60722] New: __builtin_choose_expr() does not allow 'CONST_EXP' using const variable

[yann at droneaud dot fr]

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

Bug ID: 60722
   Summary: __builtin_choose_expr() does not allow 'CONST_EXP'
using const variable
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at droneaud dot fr

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

Hi,

I'm trying to use __builtin_choose_expr() with a test against a const variable:

#define VALUE 123

int
test(void)
{
const int value = VALUE;
int v1, v2;

v1 = __builtin_choose_expr(__builtin_constant_p(VALUE),
   (__builtin_choose_expr(VALUE >= 10,
  2,
  (__builtin_choose_expr(VALUE >= 0,
 1,
 0,
-1);

v1 = __builtin_choose_expr(__builtin_constant_p(value),
   (__builtin_choose_expr(value >= 10,
  2,
  (__builtin_choose_expr(value >= 0,
 1,
 0,
   -1);

return v1 - v2;
}




The first expression is considering a constant defined as a macro.
And the second expression is considering a constant variable.

With gcc 4.9.0 20140313 (experimental), I'm facing the following error:

$ /opt/gcc/bin/gcc -O2 -c test.c 
test.c: In function ‘test’:
test.c:21:11: erreur: first argument to ‘__builtin_choose_expr’ not a constant
  (__builtin_choose_expr(value >= 0,
   ^
test.c:19:9: erreur: first argument to ‘__builtin_choose_expr’ not a constant
(__builtin_choose_expr(value >= 10,
 ^

(Note: with gcc 4.8, I'm also having the issue with _builtin_constant_p(value),
as bug #19449)


It's a pity gcc is not able to consider (value >= 0) as a constant expression
while its obvious
that 'value' is a constant variable (!).

It makes usage of __builtin_choose_expr() not applicable in my case.

[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills

[ramana at gcc dot gnu.org]

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

--- Comment #6 from Ramana Radhakrishnan  ---
Author: ramana
Date: Mon Mar 31 14:21:58 2014
New Revision: 208961

URL: http://gcc.gnu.org/viewcvs?rev=208961&root=gcc&view=rev
Log:
Adjust testcase for softfp cases.


PR target/60650

2014-03-31  Ramana Radhakrishnan  

PR target/60650
* gcc.target/arm/pr60650.c: Adjust command line options.




Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/pr60650.c

[Bug lto/60721] xcoral fails to build with LTO: internal compiler error: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
(gdb) p debug_bb (bb)
:
result_5 = getenv ("SMAC_STACK_SIZE");
if (result_5 != 0B)
  goto ;
else
  goto ;
(gdb) p debug_generic_expr (cfun->decl)
init_smac

in one unit getenv is pulled in via a header leading to

extern char *getenv (const char *__name) __attribute__ ((__nothrow__ ,
__leaf__)) __attribute__ ((__nonnull__ (1))) __attribute__
((__warn_unused_result__));

(note the leaf attribute), and in the other we have

int
main ( argc, argv )
int argc;
char **argv;
{
...
  extern char *getenv ();

this means that if cfun->calls_setjmp as in this case, this can make a
difference.  This is verifying after IPA transforms took place.

It seems that 'leaf' is a decl attribute and thus is not preserved
via gimple_call_fntype streaming (and also cannot be set for indirect calls).

Sth for stmt fixup similar as we handle noreturn?

[Bug lto/60721] New: xcoral fails to build with LTO: internal compiler error: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Bug ID: 60721
   Summary: xcoral fails to build with LTO: internal compiler
error: verify_flow_info failed
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: lto
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

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

> ./xgcc -B. xcoral.i smac.i -fltoxcoral.c: In function 'main':
xcoral.c:216:2: warning: ignoring return value of 'fgets', declared with
attribute warn_unused_result [-Wunused-result]
xcoral.c:238:3: warning: ignoring return value of 'chdir', declared with
attribute warn_unused_result [-Wunused-result]
xcoral.c:273:2: warning: ignoring return value of 'chdir', declared with
attribute warn_unused_result [-Wunused-result]
Smac/smac.c: In function 'init_smac':
Smac/smac.c:176:8: error: control flow in the middle of basic block 2
Smac/smac.c:176:8: error: control flow in the middle of basic block 5
Smac/smac.c:176:8: internal compiler error: verify_flow_info failed
0x69cff9 verify_flow_info()
/space/rguenther/src/svn/trunk/gcc/cfghooks.c:260
0xb2064a cleanup_tree_cfg_noloop
/space/rguenther/src/svn/trunk/gcc/tree-cfgcleanup.c:746
0xb20716 cleanup_tree_cfg()
/space/rguenther/src/svn/trunk/gcc/tree-cfgcleanup.c:801
0x9ed861 execute_function_todo

[Bug tree-optimization/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
Agreed, let's xfail the test on the affected targets for now and look to fix
the missed threading optimization during the next stage1.

[Bug lto/60720] clisp fails to build with -flto: internal compiler error: tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6941

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
We miss to wrap uses of non-automatic vars inside MEM_REFs for global
initializers
(we do that for the IL already).

Doing this raises the question whether we shouldn't simply special-case
global var references and stream a type which each reference, materializing
a MEM_REF only when necessary (not sure if we know that at the point we are
materializing the initializer).

Anyway, short-term fix:

Index: gcc/lto-streamer-out.c
===
--- gcc/lto-streamer-out.c  (revision 208955)
+++ gcc/lto-streamer-out.c  (working copy)
@@ -313,6 +313,27 @@ lto_is_streamable (tree expr)
 }


+/* Wrap symbol references in *TP inside a type-preserving MEM_REF.  */
+
+static tree
+wrap_refs (tree *tp, int *ws, void *)
+{
+  tree t = *tp;
+  if (TREE_CODE (t) == VAR_DECL)
+{
+  tree ptrtype = build_pointer_type (TREE_TYPE (t));
+  *tp = build2 (MEM_REF, TREE_TYPE (t),
+   build1 (ADDR_EXPR, ptrtype, t),
+   build_int_cst (ptrtype, 0));
+  *ws = 0;
+}
+  else if (TREE_CODE (t) == CONSTRUCTOR)
+;
+  else if (!EXPR_P (t))
+*ws = 0;
+  return NULL_TREE;
+}
+
 /* For EXPR lookup and return what we want to stream to OB as DECL_INITIAL. 
*/

 static tree
@@ -340,6 +361,14 @@ get_symbol_initial_value (struct output_
initial = error_mark_node;
 }

+  /* Wrap all symbol references inside the initializer in a MEM_REF
+ to preserve the type at the use even in case the symbol is
+ prevailed by one with a different type.  We can safely skip this
+ during WPA.  */
+  if (!in_lto_p
+  && initial && initial != error_mark_node)
+walk_tree (&initial, wrap_refs, NULL, NULL);
+
   return initial;
 }

[Bug c++/60551] __attribute__((used)) is ignored for 'static' function declarations

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
Clarification: 'a.cc' should be named as 'a.hh' as it's a header included in
many other .cc files.

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
I think, instructions 40 and 44 are transposed between 

select_type_4a.f90.209r.asmcons:

(insn 40 38 43 6 (set (mem/f/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -4 [0xfffc])) [3 MEM[(struct
__class_poly_list_Node_type_p *)&node + 4B]+0 S4 A32])
(reg/f:SI 140)) select_type_4a.f90:36 663 {*arm_movsi_vfp}
 (nil))
(insn 43 40 44 6 (set (reg/f:SI 139)
(plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8]))) select_type_4a.f90:36 5
{*arm_addsi3}
 (nil))
(insn 44 43 45 6 (parallel [
(set (reg:SI 0 r0)
(mem/c:SI (reg/f:SI 139) [8 MEM[(struct
__class_poly_list_Node_type &)&node]+0 S4 A64]))
(set (reg:SI 1 r1)
(mem/c:SI (plus:SI (reg/f:SI 139)
(const_int 4 [0x4])) [8 MEM[(struct
__class_poly_list_Node_type &)&node]+4 S4 A32]))
]) select_type_4a.f90:36 420 {*ldm2_ia}
 (nil))

and select_type_4a.f90.212r.sched1:

(insn 44 38 40 6 (parallel [
(set (reg:SI 0 r0)
(mem/c:SI (reg/f:SI 139) [8 MEM[(struct
__class_poly_list_Node_type &)&node]+0 S4 A64]))
(set (reg:SI 1 r1)
(mem/c:SI (plus:SI (reg/f:SI 139)
(const_int 4 [0x4])) [8 MEM[(struct
__class_poly_list_Node_type &)&node]+4 S4 A32]))
]) select_type_4a.f90:36 420 {*ldm2_ia}
 (nil))
(insn 40 44 45 6 (set (mem/f/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -4 [0xfffc])) [3 MEM[(struct
__class_poly_list_Node_type_p *)&node + 4B]+0 S4 A32])
(reg/f:SI 140)) select_type_4a.f90:36 663 {*arm_movsi_vfp}
 (nil))


but they use an alias to the same memory.

interesting, one names the memory MEM[...&node]+4
and the other names it MEM[...&node+4B]+0.

[Bug c++/60708] [4.8/4.9 Regression] An array temporary causes an ICE in gimplify

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen  ---
So, to clarify, this is not accepts-invalid, nor is it a 4.7->4.9 regression
with regards to whether the function should be accepted. If I change the test
to
be purely C++11, it ICEs on 4.7 and 4.8 as well.

template  struct mypair {
  mypair(T, U) {}
};

template  auto my_make_pair(T t, U u) -> mypair
{
  return mypair(t, u);
}

template struct S {
 mypair get_pair() noexcept { 
   return my_make_pair((T*)nullptr, 0); 
 } 
}; 

static void foo(const mypair (&a)[2]) noexcept { } 

int main()
{ 
  S s; 
  //mypair jones[2]{s.get_pair(), s.get_pair()};
  //foo(jones);
  foo({s.get_pair(), s.get_pair()}); 
}

[Bug lto/60720] clisp fails to build with -flto: internal compiler error: tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6941

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-31
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It's

 module_t modules[] = {
  { "clisp",
...
{ "regexp", &module__regexp__subr_tab.subrs[0], &module__regexp__subr_tab_size,
&module__regexp__object_tab[0], &module__regexp__object_tab_size, 0,
&module__regexp__subr_tab_initdata[0], &module__regexp__object_tab_initdata[0],
&module__regexp__init_function_1, &module__regexp__init_function_2,
&module__regexp__fini_function , ((void *)0) },
...

using &module__regexp__object_tab[0] (an array-ref), and declared as

extern gcv_object_t module__regexp__object_tab[];

but defined in the other module as

struct module__regexp__object_tab_t {
  gcv_object_t _object_Kboolean;
  gcv_object_t _object_Kend;
  gcv_object_t _object_Kextended;
  gcv_object_t _object_Kignore_case;
  gcv_object_t _object_Knewline;
  gcv_object_t _object_Knosub;
  gcv_object_t _object_Knotbol;
  gcv_object_t _object_Knoteol;
  gcv_object_t _object_Kreturn_type;
  gcv_object_t _object_Kstart;
  gcv_object_t _object_regexp__make_match_boa;
  gcv_object_t _object__23_28_29;
} module__regexp__object_tab;

thus no array for the actual decl.

Reduced testcase:

extern int x[];
int *foo[] = { &x[0] };



int x;

[Bug lto/60720] New: clisp fails to build with -flto: internal compiler error: tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6941

[rguenth at gcc dot gnu.org]

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

Bug ID: 60720
   Summary: clisp fails to build with -flto: internal compiler
error: tree check: expected array_type, have
record_type in array_ref_low_bound, at expr.c:6941
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: lto
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

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

compile with -flto:

> ./xgcc -B. regexi.m.i modules.i -flto 
modules.h:4:316: warning: type of 'module__regexp__object_tab_initdata' does
not match original declaration
/home/abuild/rpmbuild/BUILD/clisp-2.49/modules/regexp/regexi.c:59:3: note:
previously declared here
modules.h:4:254: warning: type of 'module__regexp__subr_tab_initdata' does not
match original declaration
/home/abuild/rpmbuild/BUILD/clisp-2.49/modules/regexp/regexi.c:173:3: note:
previously declared here
modules.h:4:154: warning: type of 'module__regexp__object_tab' does not match
original declaration
/home/abuild/rpmbuild/BUILD/clisp-2.49/modules/regexp/regexi.c:42:3: note:
previously declared here
modules.h:4:63: warning: type of 'module__regexp__subr_tab' does not match
original declaration
/home/abuild/rpmbuild/BUILD/clisp-2.49/modules/regexp/regexi.c:153:35: note:
previously declared here
lto1: internal compiler error: tree check: expected array_type, have
record_type in array_ref_low_bound, at expr.c:6941
0xd8ac7f tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/space/rguenther/src/svn/trunk/gcc/tree.c:9192
0x60b229 tree_check(tree_node*, char const*, int, char const*, tree_code)
/space/rguenther/src/svn/trunk/gcc/tree.h:2713
0x79d6ae array_ref_low_bound(tree_node*)
/space/rguenther/src/svn/trunk/gcc/expr.c:6941
0x79cf1e get_inner_reference(tree_node*, long*, long*, tree_node**,
machine_mode*, int*, int*, bool)
/space/rguenther/src/svn/trunk/gcc/expr.c:6791
0x79fe95 expand_expr_addr_expr_1
/space/rguenther/src/svn/trunk/gcc/expr.c:7689
0x7a0550 expand_expr_addr_expr
/space/rguenther/src/svn/trunk/gcc/expr.c:7783
0x7ab686 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/space/rguenther/src/svn/trunk/gcc/expr.c:10562
0x7a09ce expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/space/rguenther/src/svn/trunk/gcc/expr.c:7950
0xdbe930 expand_expr
/space/rguenther/src/svn/trunk/gcc/expr.h:457
0xdcbeb3 output_constant
/space/rguenther/src/svn/trunk/gcc/varasm.c:4706
0xdccd4b output_constructor_regular_field
/space/rguenther/src/svn/trunk/gcc/varasm.c:4952
0xdcd711 output_constructor
/space/rguenther/src/svn/trunk/gcc/varasm.c:5231
0xdcc3fe output_constant
/space/rguenther/src/svn/trunk/gcc/varasm.c:4756
0xdccd4b output_constructor_regular_field
/space/rguenther/src/svn/trunk/gcc/varasm.c:4952
0xdcd711 output_constructor
/space/rguenther/src/svn/trunk/gcc/varasm.c:5231
0xdcc0d5 output_constant
/space/rguenther/src/svn/trunk/gcc/varasm.c:4728
0xdc3b00 assemble_variable_contents
/space/rguenther/src/svn/trunk/gcc/varasm.c:1954
0xdc43e9 assemble_variable(tree_node*, int, int, int)
/space/rguenther/src/svn/trunk/gcc/varasm.c:2139
0xdd5155 varpool_assemble_decl(varpool_node*)
/space/rguenther/src/svn/trunk/gcc/varpool.c:455
0x6cb6fb output_in_order
/space/rguenther/src/svn/trunk/gcc/cgraphunit.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: ./xgcc returned 1 exit status
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug middle-end/60647] [4.9 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/60647] [4.9 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Mon Mar 31 12:28:33 2014
New Revision: 208957

URL: http://gcc.gnu.org/viewcvs?rev=208957&root=gcc&view=rev
Log:
2014-03-31  Martin Jambor  

PR middle-end/60647
* tree-sra.c (callsite_has_enough_arguments_p): Renamed to
callsite_arguments_match_p.  Updated all callers.  Also check types of
corresponding formal parameters and actual arguments.
(not_all_callers_have_enough_arguments_p) Renamed to
some_callers_have_mismatched_arguments_p.

testsuite/
* gcc.dg/pr60647-1.c: New test.
* gcc.dg/pr60647-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/pr60647-1.c
trunk/gcc/testsuite/gcc.dg/pr60647-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug fortran/60717] Wrong code with recursive procedure with unlimited polymorphic dummy argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-31
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Confirmed. You beat me to it by about 30 minutes, Vladimir!

The problem is the recursive call within 'show_generic':

D.3571 = a->_data.dim[0].ubound;
parm.2.dtype = 345;
D.3575 = a->_data.dim[0].stride;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = D.3571 + -1;
parm.2.dim[0].stride = NON_LVALUE_EXPR ;
parm.2.data = a->_data.data + (sizetype) (a->_vptr->_size *
NON_LVALUE_EXPR );
parm.2.offset = 0;
class.3._data = VIEW_CONVERT_EXPR(parm.2);
class.3._vptr = a->_vptr;
show_generic (&class.3);

The offset is 0, whereas it should be -1.

The call to 'show_generic' from the main program is done correctly:

parm.17.dtype = 281;
parm.17.dim[0].lbound = 1;
parm.17.dim[0].ubound = 6;
parm.17.dim[0].stride = 1;
parm.17.data = (void *) &array[0];
parm.17.offset = -1;
class.16._data = parm.17;
show_generic (&class.16);

This tells us exactly where the problem is.

I am taking it.

Paul

[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #10 from Mikael Morin  ---
Related: PR60495

[Bug bootstrap/60719] With --program-prefix=$target_alias --program-suffix=-$version install-driver breaks

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Guarding the two seemingly slightly different cases with
  "$(GCC_INSTALL_NAME)" != "$(target_noncanonical)-gcc-$(version)"
and
  "$(GCC_INSTALL_NAME)" != "$(GCC_TARGET_INSTALL_NAME)"
would work, but this is clearly very much a mess.

[Bug bootstrap/60719] New: With --program-prefix=$target_alias --program-suffix=-$version install-driver breaks

[rguenth at gcc dot gnu.org]

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

Bug ID: 60719
   Summary: With --program-prefix=$target_alias
--program-suffix=-$version install-driver breaks
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

With

--program-suffix=-4.9 --program-prefix=powerpc64le-suse-linux-
--target=powerpc64le-suse-linux

I get the non-sensical

[  263s] rm -f
/home/abuild/rpmbuild/BUILDROOT/cross-ppc64le-gcc49-4.9.0+r208956-0.x86_64/usr/bin/powerpc64le-suse-linux-gcc-4.9
[  263s] /usr/bin/install -c xgcc
/home/abuild/rpmbuild/BUILDROOT/cross-ppc64le-gcc49-4.9.0+r208956-0.x86_64/usr/bin/powerpc64le-suse-linux-gcc-4.9
[  263s] rm -f
/home/abuild/rpmbuild/BUILDROOT/cross-ppc64le-gcc49-4.9.0+r208956-0.x86_64/usr/bin/powerpc64le-suse-linux-gcc-4.9
[  263s] ( cd
/home/abuild/rpmbuild/BUILDROOT/cross-ppc64le-gcc49-4.9.0+r208956-0.x86_64/usr/bin
&& \
[  263s]ln powerpc64le-suse-linux-gcc-4.9 powerpc64le-suse-linux-gcc-4.9 )
[  263s] ln: failed to access 'powerpc64le-suse-linux-gcc-4.9': No such file or
directory
[  263s] Makefile:3270: recipe for target 'install-driver' failed
[  263s] make[1]: [install-driver] Error 1 (ignored)
[  263s] if [ ! -f gcc-cross ] ; then \
[  263s]   rm -f
/home/abuild/rpmbuild/BUILDROOT/cross-ppc64le-gcc49-4.9.0+r208956-0.x86_64/usr/bin/powerpc64le-suse-linux-gcc-tmp;
\
[  263s]   ( cd
/home/abuild/rpmbuild/BUILDROOT/cross-ppc64le-gcc49-4.9.0+r208956-0.x86_64/usr/bin
&& \
[  263s] ln powerpc64le-suse-linux-gcc-4.9 powerpc64le-suse-linux-gcc-tmp
&& \
[  263s] mv -f powerpc64le-suse-linux-gcc-tmp
powerpc64le-suse-linux-powerpc64le-suse-linux-gcc-4.9 ); \
[  263s] fi

not sure who added that GCC_TARGET_INSTALL_NAME special-case, but it's clearly
broken when it matches GCC_INSTALL_NAME.

Side-note, adding --program-suffix only for a cross configury overrides
program_transform_name to not include the $target_alias prefix, thus
specifying both like above.

[Bug fortran/60718] New: Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

Bug ID: 60718
   Summary: Test case gfortran.dg/select_type_4.f90 fails on ARM
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de

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

This test case is failing with this configuration at -O2 and above:

../gcc-4.9-20140323/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=all,ada,go --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 4.9.0 20140323 (experimental) (GCC)

The attached reduced test case compiles code like this to initialize
the list header:


  cmp  r2, #0
  streqip, [sp]
  ldmeqia  sp, {r0, r1}
  streqr4, [sp, #4]
  stmeqia  r3, {r0, r1}


this seems to use two words at sp[0..7] as scratchpad,
but the streq r4,[sp,#4] is not seen as a possible alias to
ldmeqia sp, {r0,r1}

[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
(In reply to Ramana Radhakrishnan from comment #5)
> However if I try the same with csint.f90 that's produced I get a different
> set of error messages but not the same failure. Slightly bizarre. 

> * $Id: cspar.inc,v 1.2 2000/05/30 13:53:58 couet Exp $
>  1

That looks like fixed-form source input. Try to compile with -ffixed-form or
use the .f file extension.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #63 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
On i386-pc-solaris2.9, I get the same PASSes and XFAILs as before:

Unsupported rounding for real(16)
 380   0  52
PASS: gfortran.dg/fmt_en.f90  -Os  execution test
XFAIL: gfortran.dg/fmt_en.f90  -Os   scan-file All kinds rounded to nearest

Rainer

[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
ABI changing option makes it a differen triplet IMHO (but it's always a hard
guess as to exactly what variants/multilibs are supposed to be in this list).

[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P4

--- Comment #21 from Richard Biener  ---
Then it's P4 for x86_64-apple-darwin13.  Please file a separate bug for the
-sparc
case then.

[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Priority|P4  |P3

--- Comment #11 from Andrew Pinski  ---
(In reply to Richard Biener from comment #10)
> no 32bit mips target in the primary/secondary target list -> P4.

But it fails with -mabi=o32 on mips64 so asking to reconsider the priority.

[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #20 from Eric Botcazou  ---
> sparc-sun-solaris2.10 is a primary arch, making P1 for now.  As sparc
> implements
> the hook Joseph mentions is this merely a testsuite issue (sparc being
> "slow")?

Yes, it passes on my machines, except if they are under heavy load, please
downgrade this back to P3.

[Bug ada/60620] missing gnattools dependency causes highly parallel build failure with --disable-bootstrap

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Taking care of it.

[Bug ada/60620] missing gnattools dependency causes highly parallel build failure with --disable-bootstrap

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-31
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> It appears the linking using g++ is intentional as -static-libstdc++ is
> passed, so that means that libstdc++ is required to build gnattools but that
> dependency is not documented.

Yes, the gnattools are also linked with the C++ compiler nowadays:

GCC_LINK=$(CXX) $(GCC_LINK_FLAGS) $(ADA_INCLUDES) $(LDFLAGS)

> The following patches solved the parallel build problems with --disable-
> bootstrap that we were seeing:
> 
> --- Makefile.def.orig 2013-10-29 13:37:47.0 -0500
> +++ Makefile.def
> @@ -336,6 +336,7 @@ dependencies = { module=all-libcpp; on=a
>  dependencies = { module=all-fixincludes; on=all-libiberty; };
>  
>  dependencies = { module=all-gnattools; on=all-target-libada; };
> +dependencies = { module=all-gnattools; on=all-target-libstdc++-v3; };
>  
>  dependencies = { module=all-lto-plugin; on=all-libiberty; };
> 
> 
> --- Makefile.in.orig  2014-03-07 07:58:27.0 -0500
> +++ Makefile.in
> @@ -46730,6 +46730,7 @@ all-stageprofile-libcpp: maybe-all-stage
>  all-stagefeedback-libcpp: maybe-all-stagefeedback-intl
>  all-fixincludes: maybe-all-libiberty
>  all-gnattools: maybe-all-target-libada
> +all-gnattools: maybe-all-target-libstdc++-v3
>  all-lto-plugin: maybe-all-libiberty
>  
>  all-stage1-lto-plugin: maybe-all-stage1-libiberty

Making host tools depend on target libraries always makes me cringe, but it's
the same situation as with libada so I guess it's OK.  Thanks for the patch.

[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken

[aivchenk at gmail dot com]

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

--- Comment #7 from Alexander Ivchenko  ---
The fix in gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01428.html

[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #8 from Richard Biener  ---
(In reply to Ramana Radhakrishnan from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > As discussed yesterday with Ramana on IRC, my suggested fix for this for 4.9
> > is something like:
> > --- gcc/dwarf2out.c 2014-03-03 08:24:14.841895755 +0100
> > +++ gcc/dwarf2out.c 2014-03-26 10:42:32.027508796 +0100
> > @@ -11326,7 +11326,12 @@ const_ok_for_output_1 (rtx *rtlp, void *
> >  }
> >  
> >if (GET_CODE (rtl) != SYMBOL_REF)
> > -return 0;
> > +{
> > +  /* NOT is not handled by output_addr_const.  */
> > +  if (GET_CODE (rtl) == NOT)
> > +   return 1;
> > +  return 0;
> > +}
> >  
> 
> In addition looks like we need to handle 
> 
> (minus (const_int) (sym_ref))  because with the reduced testcase with -g and
> removing the -fdata-sections I get an error with 
> 
> const ( minus (323) (sym_ref)) and gas won't grok that because there is no
> relocation that will deal with this. 

Note that (minus 323 sym_ref) is canonicalized (plus (neg sym_ref) 323)

but it looks like this needs to go through some legitimize hook before
handing it to output_addr_const?

> 
> (note 220 219 221 5 (var_location r2 (plus:SI (plus:SI (reg:SI 3 r3
> [orig:192 ivtmp.37 ] [192])
> (symbol_ref:SI ("*.LANCHOR0") [flags 0x182]))
> (const:SI (minus:SI (const_int 323 [0x143])
> (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
> NOTE_INSN_VAR_LOCATION)
> 
> Uggh this is proving to be more ugly.

[Bug tree-optimization/60656] [4.8/4.9 regression] x86 vectorization produces wrong code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
(In reply to Richard Biener from comment #18)
> sparc-sun-solaris2.10 is a primary arch, making P1 for now.  As sparc
> implements
> the hook Joseph mentions is this merely a testsuite issue (sparc being
> "slow")?

In Darwin's case, I don't believe it is (simply) a test-suite issue;

Rather it is connected with the implementation of pthread-based locking in
libatomic when entities larger than those natively-supported are used.

So, for example, if libatomic is configured to use a machine supporting
cmpxchg16b, then test-time drops from 50mins -> 1min (c.f. configuring without
cmpxchg16b).

Probing the stalled cases, shows that things are stuck in mutex code.

I started looking at the (default) posix implementation of the locking in
libatomic (partly to see if there was a more BSD-esque way to do it).  However,
I'm out of time for the next couple of weeks.

Two things (in the posix libatomic implementation) that might bear more
examination:

1) adjacent entities that happen to fall within one cache line size (which
would apply to two 32byte numbers stored consecutively, for x86) get the same
hash ID.  I wonder if that can introduce a vulnerability.

2) If the alignment of an entity is < its size, AFAICT the entity could span
two hash IDs without this being detected [the evaluation is carried out modulo
size without considering alignment].

===

On darwin it's possible to resolve the issue by replacing the
pthread_mutex_lock()s with
while ((err = pthead_mutex_trylock(…)) != 0)
 if (err == …) abort();

.. which might indicate an underlying issue with the implementation of pthreads
(or it might simply modify the behaviour enough to cause some other
vulnerability to be hidden).

--

I don't know if the same approach (spinning on try lock) would resolve the
issue on Solaris, or (particularly) how to interpret the findings yet.

[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-03-31
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
Waiting for a testcase.

[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i686-pc-linux-android
   Priority|P3  |P4

--- Comment #6 from Richard Biener  ---
i686-pc-linux-android is not primary/secondary.

[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4

--- Comment #10 from Richard Biener  ---
no 32bit mips target in the primary/secondary target list -> P4.

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #11 from Richard Biener  ---
P1 for now.

[Bug fortran/60529] [4.9 Regression] [OOP] ICE with allocatable sub-component

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/60526] [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Priority|P3  |P4

[Bug tree-optimization/60505] [4.8/4.9 Regression] Warning caused by GCC vectorizer.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/60500] [4.7/4.8/4.9 Regression] Spurious warning on derived type initialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|middle-end  |fortran

--- Comment #2 from Richard Biener  ---
The value is used uninitialized on the work1.data == NULL error path:

  work1.data = (void * restrict) __builtin_malloc (MAX_EXPR
);
  if (work1.data == 0B)
{
  stat.0 = 5014;
}
}
  }
  }
if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (stat.0 ==
0), 1, 33))
  {
work1.dtype = 297;
work1.dim[0].lbound = 1;
work1.dim[0].ubound = (integer(kind=8)) *n1;
work1.dim[0].stride = 1;
work1.offset = -1;
  }
if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (stat.0 !=
0), 0, 33)) goto L.1;
L.1:;
*st = stat.0;
{
  struct ntype D.2358;
  struct ntype ntype.3;
  integer(kind=8) D.2356;
  integer(kind=8) D.2355;
  integer(kind=8) D.2354;
  struct ntype[0:] * restrict D.2353;

  D.2353 = (struct ntype[0:] * restrict) work1.data;
  D.2354 = work1.offset;
  D.2355 = work1.dim[0].lbound;
  D.2356 = work1.dim[0].ubound;
  ntype.3.level = 1;
  D.2358 = ntype.3;
  {
integer(kind=8) S.4;

S.4 = D.2355;
while (1)
  {
if (S.4 > D.2356) goto L.3;
(*D.2353)[S.4 + D.2354] = D.2358;
S.4 = S.4 + 1;
  }
L.3:;

possibly the L.1 label is misplaced?  At least the result would crash if
malloc returned NULL.

Frontend wrong-code bug.

[Bug tree-optimization/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

[amker.cheng at gmail dot com]

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

--- Comment #10 from bin.cheng  ---
Patch sent at http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00857.html , but it
need to wait for stage 1.

I will xfail it for now.

[Bug target/60481] [4.9 Regression] Missing diagnostic "ISO C++ forbids declaration of 'foo' with no type"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Richard Biener  ---
Thus "works as designed".

[Bug fortran/60483] [4.7/4.8/4.9 Regression] No IMPLICIT type error with: ASSOCIATE( X => derived_type() ) [i.e. w/ structure constructor]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug preprocessor/60436] [4.8/4.9 Regression] C preprocessor segfaults on assembly file

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/60410] [4.7/4.8/4.9 Regression] -fshort-double ICEs x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Priority|P3  |P2

[Bug tree-optimization/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|cris-axis-elf   |cris-axis-elf,
   ||mipsel-unknown-linux-gnu,
   ||mips-unknown-linux-gnu
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-31
  Component|regression  |tree-optimization
Version|4.7.0   |4.9.0
 Ever confirmed|0   |1

--- Comment #9 from Richard Biener  ---
Fails on mips[el]-unknown-linux-gnu (and thus likely mipsisa64-elf, a primary
target) as well.

Consider fixing it by xfail-ing for logical_op_short_circuit targets if a fix
isn't suitable at this stage.

[Bug rtl-optimization/60162] [4.9 Regression][lra] mlra appears to be using the FP registers for integer values and then moving on to GPR registers.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|NEW |WAITING

--- Comment #5 from Richard Biener  ---
WAITING, as of last comment.

[Bug tree-optimization/59967] [4.8/4.9 Regression] Performance regression from 4.7.x to 4.8.x (loop not unrolled)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-31
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Caused by r193246:

193246hubicka   /* If there is call on a hot path through the loop,
then
193246hubickathere is most probably not much to optimize.  */
193246hubicka   else if (size.num_non_pure_calls_on_hot_path)
138522rguenth   {
138522rguenth if (dump_file && (dump_flags & TDF_DETAILS))
193246hubicka   fprintf (dump_file, "Not unrolling loop %d: "
193246hubicka"contains call and code would grow.\n",
138522rguenthloop->num);
138522rguenth return false;
138522rguenth   }

so we conclude

size: 59-8, last_iteration: 52-5
  Loop size: 59
  Estimated size after unrolling: 269
Not unrolling loop 2: contains call and code would grow.

so it was disabled on purpose.  Not sure if it's worth special-casing
self-recursive calls the same as pure/const ones.

[Bug c++/60692] ICE with template template parameter (invalid code)

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The problem seems to exist in the 4.9.0 trunk as well

[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #18 from Richard Biener  ---
sparc-sun-solaris2.10 is a primary arch, making P1 for now.  As sparc
implements
the hook Joseph mentions is this merely a testsuite issue (sparc being "slow")?

[Bug lto/59925] [4.9 Regression] link failure in python2.7 build with -flto and -fprofile-use -fprofile-correction enabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-03-31
 Ever confirmed|0   |1

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #13 from Mikael Morin  ---
Patch posted at
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01690.html

I have no time to review it now, so I'm just adding a cross-reference to
where the error_mark_node thing comes from:
It comes from http://gcc.gnu.org/r195890 or namely pr54107.

[Bug tree-optimization/57732] [4.8/4.9 Regression] ICE (segfault in libisl) building drizzle on 32bit targets (at least arm-linux and i586-linux)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Blocks||59859

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #8 from Richard Biener  ---
known-to-work version?

[Bug tree-optimization/34723] [4.7/4.8/4.9 Regression] Summing variable should be initialized to the first member before the loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2

[Bug fortran/60526] [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4