date:20120628

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

--- Comment #6 from Alexandre Oliva  2012-06-28 
07:39:33 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:25 2012
New Revision: 189036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189036
Log:
PR debug/53740
PR debug/52983
PR debug/48866
* dce.c (word_dce_process_block): Check whether inserting debug
temps are needed even for needed insns.
(dce_process_block): Likewise.
* df-problems.c (dead_debug_add): Add comment about multi-regs.
(dead_debug_insert_temp): Likewise.  Don't subreg when we're
setting fewer regs than a multi-reg requires.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/df-problems.c

[Bug debug/53740] [4.8 Regression] --enable-checking=yes,rtl bootstrap failure with ada

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

--- Comment #8 from Alexandre Oliva  2012-06-28 
07:39:33 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:25 2012
New Revision: 189036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189036
Log:
PR debug/53740
PR debug/52983
PR debug/48866
* dce.c (word_dce_process_block): Check whether inserting debug
temps are needed even for needed insns.
(dce_process_block): Likewise.
* df-problems.c (dead_debug_add): Add comment about multi-regs.
(dead_debug_insert_temp): Likewise.  Don't subreg when we're
setting fewer regs than a multi-reg requires.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/df-problems.c

[Bug debug/48866] gcc hangs when -g is set

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

--- Comment #14 from Alexandre Oliva  2012-06-28 
07:39:34 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:25 2012
New Revision: 189036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189036
Log:
PR debug/53740
PR debug/52983
PR debug/48866
* dce.c (word_dce_process_block): Check whether inserting debug
temps are needed even for needed insns.
(dce_process_block): Likewise.
* df-problems.c (dead_debug_add): Add comment about multi-regs.
(dead_debug_insert_temp): Likewise.  Don't subreg when we're
setting fewer regs than a multi-reg requires.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/df-problems.c

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

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

--- Comment #10 from Alexandre Oliva  2012-06-28 
07:39:59 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:51 2012
New Revision: 189037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189037
Log:
PR debug/53706
PR debug/47624
* var-tracking.c (vt_emit_notes): Release loc_exp_dep_pool...
(vt_finalize): ... here instead, if needed.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

[Bug debug/53671] [4.8 Regression] Many guality test failures

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

--- Comment #8 from Alexandre Oliva  2012-06-28 
07:41:14 UTC ---
Author: aoliva
Date: Thu Jun 28 07:41:02 2012
New Revision: 189038

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189038
Log:
PR debug/53671
PR debug/49888
* gcc.dg/guality/pr49888.c: Account for the possibility that
the variable is optimized out at the first test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/guality/pr49888.c

[Bug debug/49888] VTA: -O2 -g variable value changes, it does not change in the source

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

--- Comment #9 from Alexandre Oliva  2012-06-28 
07:41:15 UTC ---
Author: aoliva
Date: Thu Jun 28 07:41:02 2012
New Revision: 189038

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189038
Log:
PR debug/53671
PR debug/49888
* gcc.dg/guality/pr49888.c: Account for the possibility that
the variable is optimized out at the first test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/guality/pr49888.c

[Bug debug/53740] [4.8 Regression] --enable-checking=yes,rtl bootstrap failure with ada

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Alexandre Oliva  2012-06-28 
07:39:33 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:25 2012
New Revision: 189036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189036
Log:
PR debug/53740
PR debug/52983
PR debug/48866
* dce.c (word_dce_process_block): Check whether inserting debug
temps are needed even for needed insns.
(dce_process_block): Likewise.
* df-problems.c (dead_debug_add): Add comment about multi-regs.
(dead_debug_insert_temp): Likewise.  Don't subreg when we're
setting fewer regs than a multi-reg requires.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/df-problems.c

--- Comment #9 from Alexandre Oliva  2012-06-28 
07:46:17 UTC ---
Fixed

[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #22 from Alexandre Oliva  2012-06-28 
07:39:59 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:51 2012
New Revision: 189037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189037
Log:
PR debug/53706
PR debug/47624
* var-tracking.c (vt_emit_notes): Release loc_exp_dep_pool...
(vt_finalize): ... here instead, if needed.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

--- Comment #23 from Alexandre Oliva  2012-06-28 
07:45:58 UTC ---
Fixed

[Bug lto/53787] Possible lto improvement

2012-06-28 Thread izamyatin at gmail dot com

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

--- Comment #4 from Igor Zamyatin  2012-06-28 
08:17:13 UTC ---
Created attachment 27714
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27714
gfort assembler

"Init" routine should be inspected here

[Bug lto/53787] Possible lto improvement

2012-06-28 Thread izamyatin at gmail dot com

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

--- Comment #5 from Igor Zamyatin  2012-06-28 
08:22:11 UTC ---
Created attachment 27715
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27715
ifort assembler

"Init" routine looks much better here

[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now

2012-06-28 Thread rguenther at suse dot de

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

--- Comment #11 from rguenther at suse dot de  
2012-06-28 08:26:12 UTC ---
On Wed, 27 Jun 2012, matt at use dot net wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676
> 
> --- Comment #10 from Matt Hargett  2012-06-27 18:26:55 
> UTC ---
> Is there a fix targeted for 4.7.2? I can apply the patch and do some testing,
> if that helps. Let me know what I can do, if anything, so we can make 4.7
> deployable for us.

No, the fix isn't really suitable for backporting (we generally do not
fix but trivial missed-optimization regressions).

[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

2012-06-28 Thread rguenther at suse dot de

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

--- Comment #9 from rguenther at suse dot de  
2012-06-28 08:26:42 UTC ---
On Wed, 27 Jun 2012, pthaugen at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
> 
> Pat Haugen  changed:
> 
>What|Removed |Added
> 
>  CC||pthaugen at gcc dot gnu.org
> 
> --- Comment #8 from Pat Haugen  2012-06-27 
> 19:11:59 UTC ---
> This fails on PowerPC also with just -O3. I'll see what I can do about
> narrowing down to a smaller testcase.

I expect it to be yet another 416.gamess source bug.  Which is why
this did not have high priority for me.

[Bug target/53793] [ARM] Debug info is wrong at optimization level -O1

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

--- Comment #1 from Richard Guenther  2012-06-28 
09:30:55 UTC ---
That's a general issue of the old, deprecated text prologues/epilogues.

[Bug c++/53792] [C++11][constexpr] improving compiler-time constexpr evaluation

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-28
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-06-28 
09:34:20 UTC ---
Does the C++ standard require getIndex to be evaluated to a constant in getV?
Or is 'constexpr' only telling you that it is required in a context where
evaluation to a constant is required (and thus arguments to a constexpr
function are constrained)?

[Bug c++/53794] New: [c++11, accepts invalid] dangling reference accepted in nested structures with initializer lists

2012-06-28 Thread dirkmoermans at gmail dot com

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

 Bug #: 53794
   Summary: [c++11, accepts invalid] dangling reference accepted
in nested structures with initializer lists
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dirkmoerm...@gmail.com


The code below is currently accepted without warning by gcc-4.6.3 and
gcc-4.7.0.

===
struct A
{
   int& i;
};

struct B
{
   A a;
};

int main()
{
   B b1{}; // BUG: accepts invalid
   // B b2; // rejected
};
===

I think it should be rejected, since uninitialized references are not allowed
by the language.

[Bug lto/53777] [lto] lto does not propagate optimization flags from command lines given at "compilation time"

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

--- Comment #3 from Richard Guenther  2012-06-28 
09:44:40 UTC ---
(In reply to comment #2)
> I fully agree that combining code sections to be optimized differently is not
> well defined in particular when optimization works looking at a broader scope.
> In principle one can imagine that an optimization-flag change should be
> considered as an optimization barrier, but that clearly defeats the very
> purpose of optimization itself and may lead to code that is less performant
> that if compiled with the lower of all options...
> 
> Most probably we should go back and understand WHY users choose different
> optimization level for different code sections.
> 
> In some cases is to workaround a compiler or coding problem

Right.  In that case I'd say the specific object should better not participate
in the LTO link (thus do not use -flto at .c -> .o compile time for that
object).

> In our specific case the code to be compiled with -Os is "machine generated"
> and contains mostly streamers not very sensitive to aggressive optimization
> (vectorization helps in some, at best) : we judged that a smaller code (much
> smaller actually!) and faster compilation was more effective.
> It is packaged in the same library with the class they have to stream for
> convenience and dependency management.
> In reality I noticed that with lto the compilation time is fully dominated by
> those files, so it is surely not "fast-developement" friendly. I suspect that
> the final solution will be to segregate them into their own library.
> 
> I also experimented with trying to optimize more aggressively some
> computational-intensive code segments.
> In principle it could make sense, in practice I understand that as soon as
> inter-procedural optimization kicks-in having code fragments with Ofast and
> other with O2 can make little sense even from a pure numerical point of view:
> think of an expression found in both sections that can be factorized out.

A very convenient way of "optimize more aggressively some
computational-intensive code segments" is to use profile-feedback ;)

> I suspect that the only safe way is to to segregate the code requested to be
> compiled with different options, for sure if the option is "lower". Most
> probably this is not what other users expects.

So eventually you want to simply not compile the -Os code with -flto so
that it won't participate in link-time optimization (with using the linker
plugin you can still get most of the effect of whole-program assumptions).
Or if you have several -Os sources, do a partial -flto link with -Os and
link that object in the link-time optimization with -O2.

As what the user expects that is not really clear ;)  A quite extreme
way would be to simply assert that flags on all compiles and the link
are the same and otherwise give up (or warn).  Another idea was that
if at link-time no compile options are specified (might be quite common,
but at least people added -flto somehow) then use the options from
compile-time (but which, if they differed?).  Another idea was to tag
the cgraph with the compile options used and adjust the partitioning
done for the LTRANS stage to be able to have consistent options (that
might differ between LTRANS units) for all functions inside one LTRANS unit.
For all of the different-flags-at-compile-time issues the issue remains
what the flags used at link-time mean?  Do they override or amend flags?
(We specifically thought of libraries shipped with LTO bytecode
compiled at -O0 -g to be used for both debugging and optimized compile
by means of optimizing only at link-time)

[Bug c++/53788] C++11 decltype sfinae static member function check (4.7.1)

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

--- Comment #2 from Jonathan Wakely  2012-06-28 
09:44:50 UTC ---
(In reply to comment #0)
> Greetings all. The following code should *not* compile

I'm not convinced the standard *requires* it to be rejected.

[Bug tree-optimization/53791] Branches not re-ordered using profile-information

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-28
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-06-28 
09:51:48 UTC ---
Confirmed.  tree-ssa-ifcombine.c deals with two-comparison CFG patterns, so
it could handle transforming

  # BLOCK 4 freq:9688 count:93
  # PRED: 3 [96.9%]  count:93 (false,exec)
  if (xD.1241_2(D) == 2)
goto ;
  else
goto ;
  # SUCC: 7 [3.2%]  count:3 (true,exec) 5 [96.8%]  count:90 (false,exec)

  # BLOCK 5 freq:9375 count:90
  # PRED: 4 [96.8%]  count:90 (false,exec)
  if (xD.1241_2(D) == 3)
goto ;
  else
goto ;

at least (and by iterating would then catch the 2nd opportunity).  That's
of course somewhat ad-hoc (but the easiest place to implement).

The other trivially obvious possibility is to pattern-match this open-coded
switch/case and transform it back to switch/case early.

[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion

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

--- Comment #15 from Richard Guenther  2012-06-28 
09:52:43 UTC ---
(In reply to comment #14)
> Ping? Can someone review my last patch? I think it's clean enough to be 
> applied
> (minus the TODO notes) and extra fixes can come separately later.

Did you post it to gcc-patches?  If so, ping there.

[Bug middle-end/53790] [4.6/4.7/4.8 Regression] ICE on dereferencing a extern union in asm statement

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
   Last reconfirmed||2012-06-28
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
Summary|ICE on dereferencing a  |[4.6/4.7/4.8 Regression]
   |extern union in asm |ICE on dereferencing a
   |statement   |extern union in asm
   ||statement
   Target Milestone|--- |4.6.4
  Known to fail||4.8.0

--- Comment #5 from Richard Guenther  2012-06-28 
09:59:40 UTC ---
Confirmed.  There is nothing invalid here, you can take the address of
such variable - you just cannot inspect it.  Of course that is what
inlining exposes here (and via MEM_REF we get to see the external decl).

Hmhm.

I'll look at it.

[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc

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

Richard Guenther  changed:

   What|Removed |Added

 Target||hppa*-*-*
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-06-28
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-06-28 
10:01:26 UTC ---
Please try with a version of GCC that is still maintained.

[Bug ada/53795] New: [4.8 Regression] FAIL: gnat.dg/old_errors.adb

2012-06-28 Thread dominiq at lps dot ens.fr

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

 Bug #: 53795
   Summary: [4.8 Regression] FAIL: gnat.dg/old_errors.adb
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: char...@gcc.gnu.org
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10


On x86_64-apple-darwin10, gnat.dg/old_errors.adb has started to fail between
revisions 188991 (OK) and 189025 (likely r188995):

Executing on host: /opt/gcc/build_w/gcc/gnatclean -c -q -n old_errors  
(timeout = 300)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 7)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 16)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 28)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 34)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 38)
FAIL: gnat.dg/old_errors.adb  (test for warnings, line 40)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 44)
FAIL: gnat.dg/old_errors.adb (test for excess errors)
Excess errors:
old_errors.adb:7:22: "Old" attribute can only appear in postcondition
old_errors.adb:16:25: "Old" attribute can only appear in postcondition
old_errors.adb:22:34: "Old" attribute can only appear in postcondition
old_errors.adb:28:12: "Old" attribute can only appear in postcondition
old_errors.adb:34:19: "Old" attribute can only appear in postcondition
old_errors.adb:35:19: "Old" attribute can only appear in postcondition
old_errors.adb:38:15: "Old" attribute can only appear in postcondition
old_errors.adb:40:12: "Old" attribute can only appear in postcondition
old_errors.adb:41:12: "Old" attribute can only appear in postcondition
old_errors.adb:42:12: "Old" attribute can only appear in postcondition
old_errors.adb:44:22: "Old" attribute can only appear in postcondition

[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||jamborm at gcc dot gnu.org
  Component|lto |tree-optimization
Summary|Possible lto improvement|Possible IPA-SRA / IPA-CP
   ||improvement

--- Comment #6 from Richard Guenther  2012-06-28 
10:08:13 UTC ---
This has nothing to do with LTO - with a single compilation unit you can
use -fwhole-program.  The issue is that Fortran passes parameters by reference
and our interprocedural constant-propagation pass does not know how to deal
with that.  The IPA SRA pass which is supposed to "fix" that decides that
init cannot have its signature changed.  Martin, can you check why?
I think we ought to optimize this with -O3 -fwhole-program -fno-inline.

[Bug ada/53795] [4.8 Regression] FAIL: gnat.dg/old_errors.adb

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-28
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-06-28 
10:16:53 UTC ---
Confirmed.

[Bug fortran/53796] New: I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

2012-06-28 Thread burnus at gcc dot gnu.org

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

Bug #: 53796
Summary: I/O INQUIRE of RECL: If not specified in OPEN, the
default value should be returned (sequential access)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: jvdeli...@gcc.gnu.org
Depends on: 44292

As reported at
http://www.rhinocerus.net/forum/lang-fortran/708936-inquire-get-maximum-record-length-bug-gfortran.html

One has to distinguish three cases:
- Direct access: The RECL= has to be given in OPEN
- Stream access: No RECL= is allowed in OPEN
- Sequential access: RECL= can be given in OPEN, otherwise the default is used.

gfortran handles the case of RECL= given in OPEN correctly by returning that
value and it handles stream access by using -1. (As the argument becomes
undefined, any value would do.)

Additionally, gfortran always returns -1 for sequential access instead of
returning the default value.

The question is only how to handle sequential access. We have two questions:

a) gfortran handles (on most systems) large files, i.e. the default value would
be larger than huge(0). Additionally, (cf. PR 44292) gfortran does not handle
INT64 variables for RECL. Thus, which value should be returned?
HUGE(kind(recl_var))?

b) What should happen if the user exceeds the RECL= specified in OPEN.
(Possibly, that's handled correctly, but I want to add it to the to-do list for
checking.) - That is also related to the question of (a): Handling INQUIRE
RECL=int32_var.

>From the Fortran 2008 standard at "9.10.2.26 RECL= specifier in the INQUIRE
statement":

"The scalar-int-variable in the RECL= specifier is assigned the value of the
record length of a connection for direct access, or the value of the maximum
record length of a connection for sequential access. If the connection is for
formatted input/output, the length is the number of characters for all records
that contain only characters of default kind. If the connection is for
unformatted input/output, the length is measured in file storage units. If
there is no connection, or if the connection is for stream access, the scalar
int-variable becomes undefined."

For OPEN, the following applies:

"The value of the RECL= specifier shall be positive. It specifies the length of
each record in a file being connected for direct access, or specifies the
maximum length of a record in a file being connected for sequential access.
This
specifier shall not appear when a file is being connected for stream access.
This specifier shall appear when a file is being connected for direct access.
If this specifier is omitted when a file is being connected for sequential
access, the default value is processor dependent. If the file is being
connected for formatted input/output, the length is the number of characters
for all records that contain only characters of default kind. When a record
contains any nondefault characters, the effect of the RECL= specifier is
processor dependent. If the file is being connected for unformatted
input/output, the length is measured in file storage units. For an existing
file, the value of the RECL= specifier shall be included in the set of allowed
record lengths for the le. For a new file, the processor creates the file with
a set of allowed record lengths that includes the specified value."

[Bug c++/53788] C++11 decltype sfinae static member function check (4.7.1)

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-28
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2012-06-28 
10:36:29 UTC ---
Here's a C++03 version, which G++ also accepts but Clang and Comeau online
reject:

struct t { char c; };
struct f { char c[2]; };

template struct Int { };

template
struct has_static {
  template
  static t check(X*, Int* = 0);
  static f check(...);

  static const bool value = sizeof(check((T*)(0))) == sizeof(t);
};

struct test { int fun() { return 0; } };

bool b = has_static::value;

G++ does reject it for different invalid expressions, e.g. if fun doesn't exist
at all, so it does seem to be treating the decltype expression as outside the
immediate context during type deduction, but not consistently.

[Bug c++/53792] [C++11][constexpr] improving compiler-time constexpr evaluation

2012-06-28 Thread vincenzo.innocente at cern dot ch

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

--- Comment #2 from vincenzo Innocente  
2012-06-28 11:08:38 UTC ---
On 28 Jun, 2012, at 11:34 AM, rguenth at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53792
> 
> Richard Guenther  changed:
> 
>   What|Removed |Added
> 
> Status|UNCONFIRMED |NEW
>   Last reconfirmed||2012-06-28
> Ever Confirmed|0   |1
> 
> --- Comment #1 from Richard Guenther  2012-06-28 
> 09:34:20 UTC ---
> Does the C++ standard require getIndex to be evaluated to a constant in getV?
No, a constexpr function can be used as a "normal" function. For instance if
getV was not inlined 
the correct behaviour is what we observe 
> Or is 'constexpr' only telling you that it is required ina context where
> evaluation to a constant is required (and thus arguments to a constexpr
> function are constrained)?
I would say yes (a constant needs to be evaluated using a constexpr function.
see page 148-150 (166-168 of my pdf) of the standard (7.1.5 point 3 and
following)
> 
My point is that the compiler does not identify that "getIndex" is a constant
expression in the context of foo
 nor in context of the following foo2 that indeed produce (as it should)
identical code to foo

int foo2() {
  const double a = v[getIndex("a",theMap)];
  const double b = v[getIndex("b",theMap)];

  if (a==b) return 1;
  return 0;

}

[Bug target/53793] [ARM] Debug info is wrong at optimization level -O1

2012-06-28 Thread shafitvm at gmail dot com

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

--- Comment #2 from Mohamed Shafi  2012-06-28 
11:15:18 UTC ---
So this is fixed in 4.7 then. Any plan to back port this?

[Bug c++/53797] New: Not able to print local variable while debugging at -O0

2012-06-28 Thread shafitvm at gmail dot com

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

 Bug #: 53797
   Summary: Not able to print local variable while debugging at
-O0
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shafi...@gmail.com


I tried debugging the following function with arm,i686 and ppc C and C++
compiler.

void func (int);
int main ()
{
func (20);
return 0;
}

void func(int in)
{
 int a;
 in++;
 {
  int k, j;
  k = 10;
  j = k + 44;
  in = j + 1;
  a = in;
 }  <--  Line 1
 a = in;
 a++;
}   <- Line 2


Invocation line :

g++ main.cpp -g3 -gdwarf-2 --save-temps -dA -o main.elf

When i try to print the value of 'a' when the execution reaches "line
2" i get the message "No symbol "a" in current context.". Here is the
gdb output:

(gdb) l
15j = k + 44;
16in = j + 1;
17a = in;
18   }
19   a = in;
20   a++;
21  }
22
23  int main()
24  {
(gdb) s
21  }
(gdb) p a
No symbol "a" in current context.
(gdb) p in
$1 = 55
(gdb)

For the same program i am able to view the value of 'a' if i compile
this as a C program. This happens because DW_TAG_lexical_block which
is generated only for in C++ debug info marks the scope of variable
'a' between prologue and epilogue of the code. Since the epilogue is
not present in the scope, the variable cannot be viewed when the
control reaches the closing brace of the function.

[Bug tree-optimization/53645] Missed optimization for vector integer division lowering

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

--- Comment #6 from Jakub Jelinek  2012-06-28 
11:38:04 UTC ---
Author: jakub
Date: Thu Jun 28 11:38:01 2012
New Revision: 189043

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189043
Log:
PR tree-optimization/53645
* tree-vect-generic.c (add_rshift): New function.
(expand_vector_divmod): New function.
(expand_vector_operation): Use it for vector integer
TRUNC_{DIV,MOD}_EXPR by VECTOR_CST.
* tree-vect-patterns.c (vect_recog_divmod_pattern): Replace
unused lguup variable with dummy_int.

* gcc.c-torture/execute/pr53645.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr53645.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c
trunk/gcc/tree-vect-patterns.c

[Bug middle-end/53790] [4.6/4.7/4.8 Regression] ICE on dereferencing a extern union in asm statement

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

--- Comment #6 from Richard Guenther  2012-06-28 
11:45:18 UTC ---
Author: rguenth
Date: Thu Jun 28 11:45:14 2012
New Revision: 189045

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189045
Log:
2012-06-28  Richard Guenther  

PR middle-end/53790
* expr.c (expand_expr_real_1): Verify if the type is complete
before inspecting its size.

* gcc.dg/torture/pr53790.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr53790.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/53790] [4.6/4.7/4.8 Regression] ICE on dereferencing a extern union in asm statement

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

--- Comment #7 from Richard Guenther  2012-06-28 
11:52:54 UTC ---
Author: rguenth
Date: Thu Jun 28 11:52:49 2012
New Revision: 189047

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189047
Log:
2012-06-28  Richard Guenther  

PR middle-end/53790
* expr.c (expand_expr_real_1): Verify if the type is complete
before inspecting its size.

* gcc.dg/torture/pr53790.c: New testcase.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53790.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/expr.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/53797] Not able to print local variable while debugging at -O0

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-28
 Ever Confirmed|0   |1
  Known to fail||4.8.0

--- Comment #1 from Richard Guenther  2012-06-28 
11:58:22 UTC ---
Confirmed.  Works with the C frontend.  The difference is different location
info for the BLOCK:

-func (int in)
-[t.C : 9:1] {
+void func(int) (int in)
+[t.C : 20:6] {
   int a;
...
-  [t.C : 19:5] a = in;
-  [t.C : 20:4] a = a + 1;
+  [t.C : 19:9] a = in;
+  [t.C : 20:6] a = a + 1;
 }

for -C +C++.

[Bug libfortran/51119] MATMUL slow for large matrices

2012-06-28 Thread Joost.VandeVondele at mat dot ethz.ch

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

--- Comment #6 from Joost VandeVondele  
2012-06-28 11:58:20 UTC ---
Janne, have you had a chance to look at this ? For larger matrices MATMMUL is
really slow. Anything that includes even the most basic blocking scheme should
be faster. I think this would be a valuable improvement.

[Bug middle-end/53790] [4.6/4.7/4.8 Regression] ICE on dereferencing a extern union in asm statement

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

--- Comment #8 from Richard Guenther  2012-06-28 
12:01:22 UTC ---
Author: rguenth
Date: Thu Jun 28 12:01:16 2012
New Revision: 189048

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189048
Log:
2012-06-28  Richard Guenther  

PR middle-end/53790
* expr.c (expand_expr_real_1): Verify if the type is complete
before inspecting its size.

* gcc.dg/torture/pr53790.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr53790.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/expr.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/53790] [4.6/4.7/4.8 Regression] ICE on dereferencing a extern union in asm statement

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Richard Guenther  2012-06-28 
12:01:22 UTC ---
Author: rguenth
Date: Thu Jun 28 12:01:16 2012
New Revision: 189048

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189048
Log:
2012-06-28  Richard Guenther  

PR middle-end/53790
* expr.c (expand_expr_real_1): Verify if the type is complete
before inspecting its size.

* gcc.dg/torture/pr53790.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr53790.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/expr.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

--- Comment #9 from Richard Guenther  2012-06-28 
12:01:38 UTC ---
Fixed.

[Bug middle-end/53790] [4.6/4.7/4.8 Regression] ICE on dereferencing a extern union in asm statement

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Richard Guenther  2012-06-28 
12:01:38 UTC ---
Fixed.

[Bug tree-optimization/53791] Branches not re-ordered using profile-information

2012-06-28 Thread steven at gcc dot gnu.org

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

--- Comment #2 from Steven Bosscher  2012-06-28 
12:05:38 UTC ---
(In reply to comment #1)
> The other trivially obvious possibility is to pattern-match this open-coded
> switch/case and transform it back to switch/case early.

The test case is a simplified example. More complex predicates may not be
transformed to a switch. Also, the point is that this kind of code results from
lowering of switches to the series of if-branches.

(What my emit_case_bit_tests patch does, actually, is to output the branch with
the highest count first. But that means I have to lower after reading in the
profile.)

I'm looking at "Efficient and effective branch reordering using profile data"
(2002) to see if this is something that could be implemented for GCC...

[Bug lto/53777] [lto] lto does not propagate optimization flags from command lines given at "compilation time"

2012-06-28 Thread vincenzo.innocente at cern dot ch

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

--- Comment #4 from vincenzo Innocente  
2012-06-28 12:10:44 UTC ---
On 28 Jun, 2012, at 11:44 AM, rguenth at gcc dot gnu.org wrote:

> 
> A very convenient way of "optimize more aggressively some
> computational-intensive code segments" is to use profile-feedback ;)
> 
Indeed, and I'm very pleased that gcc (since 4.6) is able to pgo our
million-lines code!
the use of Ofast is to relax IEEE754 conformance only in specific routines,
mainly to allow "more" vectorization.

>> I suspect that the only safe way is to to segregate the code requested to be
>> compiled with different options, for sure if the option is "lower". Most
>> probably this is not what other users expects.
> 
> So eventually you want to simply not compile the -Os code with -flto so
> that it won't participate in link-time optimization (with using the linker
> plugin you can still get most of the effect of whole-program assumptions).
this is what I'm doing now, as you may have guessed from PR53780...
> Or if you have several -Os sources, do a partial -flto link with -Os and
> link that object in the link-time optimization with -O2.
I've no experience with -Wl,-r (or -Ur?) will try.
> 
> As what the user expects that is not really clear ;)  A quite extreme
> way would be to simply assert that flags on all compiles and the link
> are the same and otherwise give up (or warn).  Another idea was that
> if at link-time no compile options are specified (might be quite common,
> but at least people added -flto somehow) then use the options from
> compile-time (but which, if they differed?).  
Historically we always propagated compiler flags at the linker step.
For sure with lto the meaning of flags at compile vs link time is quite
confusing.
> Another idea was to tag
> the cgraph with the compile options used and adjust the partitioning
> done for the LTRANS stage to be able to have consistent options (that
> might differ between LTRANS units) for all functions inside one LTRANS unit.
This is close to what I would expect to happen.
> For all of the different-flags-at-compile-time issues the issue remains
> what the flags used at link-time mean?  Do they override or amend flags?
I would suggest to issue warning or at least to clarify your choices
> (We specifically thought of libraries shipped with LTO bytecode
> compiled at -O0 -g to be used for both debugging and optimized compile
> by means of optimizing only at link-time)
> 
Clever, a bit confusing though.
I've moved to -fno-fat-lto-objects also to make sure that the plugin is used.

[Bug libfortran/51119] MATMUL slow for large matrices

2012-06-28 Thread jb at gcc dot gnu.org

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

--- Comment #7 from Janne Blomqvist  2012-06-28 12:15:05 
UTC ---
(In reply to comment #6)
> Janne, have you had a chance to look at this ? For larger matrices MATMMUL is
> really slow. Anything that includes even the most basic blocking scheme should
> be faster. I think this would be a valuable improvement.

I implemented a block-panel multiplication algorithm similar to GOTO BLAS and
Eigen, but I got side-tracked by other things and never found the time to fix
the corner-case bugs and tune performance. IIRC I reached about 30-40 % of peak
flops which was a bit disappointing.

[Bug tree-optimization/53645] Missed optimization for vector integer division lowering

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2012-06-28 
12:34:10 UTC ---
Fixed.

[Bug lto/53768] [4.7 Regression] Undefined references with boost 1.46/1.48/1.49

2012-06-28 Thread vincenzo.innocente at cern dot ch

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

--- Comment #4 from vincenzo Innocente  
2012-06-28 12:48:13 UTC ---
similar to PR53337 ?
and most probably also to  PR53780

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

2012-06-28 Thread vincenzo.innocente at cern dot ch

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

--- Comment #1 from vincenzo Innocente  
2012-06-28 12:52:42 UTC ---
the failure on vanilla fedora may be related to PR53768

[Bug c++/53794] [c++11] dangling reference accepted in nested structures with initializer lists

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-28
Summary|[c++11, accepts invalid]|[c++11] dangling reference
   |dangling reference accepted |accepted in nested
   |in nested structures with   |structures with initializer
   |initializer lists   |lists
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-06-28 
13:13:13 UTC ---
You get a warning with -Wmissing-field-initializers (or -Wextra) but it should
be rejected.

The implicity-declared default constructor for A should be defined as deleted.

[class.ctor]/5

If there is no user-declared constructor for class X, a constructor having no
parameters is implicitly declared as defaulted (8.4). [...] A defaulted default
constructor for class X is defined as deleted if:
— [...]
— any non-static data member with no brace-or-equal-initializer is of reference
type,

[Bug c++/53794] [c++11] dangling reference accepted in nested structures with initializer lists

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|minor   |normal

[Bug debug/53671] [4.8 Regression] Many guality test failures

2012-06-28 Thread hjl.tools at gmail dot com

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

--- Comment #9 from H.J. Lu  2012-06-28 13:27:02 
UTC ---
As revision 189040, the regression is

FAIL: gcc.dg/guality/pr43051-1.c  -Os  line 39 c == &a[0]

[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot

2012-06-28 Thread gjl at gcc dot gnu.org

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

--- Comment #12 from Georg-Johann Lay  2012-06-28 
13:53:59 UTC ---
Author: gjl
Date: Thu Jun 28 13:53:51 2012
New Revision: 189049

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189049
Log:
PR 53595
* config/avr/avr.c (avr_hard_regno_call_part_clobbered): New.
* config/avr/avr-protos.h (avr_hard_regno_call_part_clobbered): New.
* config/avr/avr.h (HARD_REGNO_CALL_PART_CLOBBERED): Forward to
avr_hard_regno_call_part_clobbered.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr-protos.h
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.h

[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot

2012-06-28 Thread gjl at gcc dot gnu.org

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

--- Comment #13 from Georg-Johann Lay  2012-06-28 
13:58:37 UTC ---
Author: gjl
Date: Thu Jun 28 13:58:32 2012
New Revision: 189050

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189050
Log:
Backport from 2012-06-28 mainline r189049
PR 53595
* config/avr/avr.c (avr_hard_regno_call_part_clobbered): New.
* config/avr/avr-protos.h (avr_hard_regno_call_part_clobbered): New.
* config/avr/avr.h (HARD_REGNO_CALL_PART_CLOBBERED): Forward to
avr_hard_regno_call_part_clobbered.


Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/avr/avr-protos.h
branches/gcc-4_7-branch/gcc/config/avr/avr.c
branches/gcc-4_7-branch/gcc/config/avr/avr.h

[Bug other/53595] Code size increase of +10% between two 4.7.1 snapshot

2012-06-28 Thread gjl at gcc dot gnu.org

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||ra
 Status|NEW |RESOLVED
  Component|rtl-optimization|other
 Resolution||FIXED
   Target Milestone|--- |4.7.2

--- Comment #14 from Georg-Johann Lay  2012-06-28 
14:02:39 UTC ---
Rather worked around than a proper fix of the call site, e.g.
ira-costs.c:ira_tune_allocno_costs

[Bug bootstrap/53798] New: [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem

2012-06-28 Thread windward at gmx dot com

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

 Bug #: 53798
   Summary: [4.7] Bootstrap fails on Linux x86_64 with pre-built
libmpc/mpfr/gmp due to multilib path problem
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: windw...@gmx.com


GCC 4.7.1 fails to bootstrap on Linux x86_64 due to a multilib problem if
pre-built libraries for MPC, MPFR and GMP are used and their installation
directory is set using --with-[mpc|mpfr|gmp] (see output at the end).

Obviously these libraries reside in different paths for 32 bit and 64 bit.
The main configure script (line 5108 and following) evaluates the
--with-[mpc|mpfr|gmp]=PATH parameters and extends $gmplibs with "-LPATH/lib".
The resulting GMPLIBS is used in ./Makefile.in and ./gcc/Makefile.in, and
causes the bootstrapping to fail in either 32 or 64 bit multilib stage
(depending on the parameters). 
Besides the redundancy if all libraries reside in the same path, $gmplibs can
only be correct for either 32 or 64 bit.

Workaround:

Assumption: 32 bit libraries reside in PATH/lib, the 64 bit versions in
PATH/lib64

Use --with-[mpc|mpfr|gmp]=PATH and add --with-gmp-lib=PATH/lib64.

The configure script will generate GMPLIBS with (at least) -LPATH/lib64 and
-LPATH/lib. GNU ld will ignore the incompatible version while searching for
lib[mpc|mpfr|gmp].


/opt/SP/build/gcc/gcc-4.7.1-build/./prev-gcc/g++
-B/opt/SP/build/gcc/gcc-4.7.1-build/./prev-gcc/
-B/opt/SP/gcc/gcc-4.7.1/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/opt/SP/build/gcc/gcc-4.7.1/libstdc++-v3/libsupc++
-L/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/opt/SP/build/gcc/gcc-4.7.1-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc  -o jc1 \
java/class.o java/decl.o java/expr.o java/constants.o java/lang.o
java/typeck.o java/except.o java/verify-glue.o java/verify-impl.o
java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o
java/mangle_name.o java/builtins.o java/resource.o java/jcf-depend.o
java/jcf-path.o java/boehm.o java/java-gimplify.o main.o  libbackend.a
libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a -L../zlib -lz  libcommon.a ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  attribs.o  
-L/opt/SP/gcc/gcc-4.7.1/lib -L/opt/SP/gcc/gcc-4.7.1/lib
-L/opt/SP/gcc/gcc-4.7.1/lib -lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz

/opt/SP/gcc/gcc-4.7.1/bin/ld: __gmpfr_emin: TLS definition in
/opt/SP/gcc/gcc-4.7.1/lib64/libmpfr.so.4 section .tdata mismatches non-TLS
definition in /usr/lib/../lib64/libmpfr.a(exceptions.o) section .data
/opt/SP/gcc/gcc-4.7.1/lib64/libmpfr.so.4: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
gmake[3]: *** [jc1] Error 1
gmake[3]: Leaving directory `/opt/SP/build/gcc/gcc-4.7.1-build/gcc'

[Bug bootstrap/53731] [4.7] Bootstrap fails for libgfortran on Solaris 10 x86 with error "Where has __float128 gone?"

2012-06-28 Thread windward at gmx dot com

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

--- Comment #1 from Martin  2012-06-28 14:14:49 UTC ---
Just realized the diff output is in the wrong order, sorry.

[Bug bootstrap/53555] [4.8 Regression] Bootstrap failure

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  2012-06-28 
14:24:35 UTC ---
Fixed.

[Bug bootstrap/53798] [4.7] Bootstrap fails on Linux x86_64 with pre-built libmpc/mpfr/gmp due to multilib path problem

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

--- Comment #1 from Jonathan Wakely  2012-06-28 
14:30:58 UTC ---
Another, simpler, workaround is to build the support libs by putting the
sources in the gcc source tree.

--with-gmp behaves as designed and as documented. The installation docs for it
clearly say:

The --with-gmp=gmpinstalldir option is shorthand for
--with-gmp-lib=gmpinstalldir/lib and --with-gmp-include=gmpinstalldir/include.
[...] If these shorthand assumptions are not correct, you can use the explicit
include and lib options directly.

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

2012-06-28 Thread burnus at gcc dot gnu.org

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-06-28 
15:42:32 UTC ---
For comparison, for formatted and unformatted sequential, I get the following
result with different compilers:

NAG f95: 1024  / unformatted: 65536
Crayftn: 1024 / -1 (with int64 variable: 9223372036854775807)
g95: 10 / 10
ifort 132 / 510
PGI  -14920 (with int64 variable: 140737488340408) / as formatted
gfortran -1 / -1

When exceeding an explicitly given RECL=:
NAG f95:  Buffer overflow on output
g95:  Writing more data than the record size (RECL)
gfortran: End of record
ifort:no error - but starts new record after recl is exceeded*
crayftn:  as ifort
pgi:  no error - but a single record*
* For formatted; writing a longer string to unformatted will yield a single
record.

 * * * 

gfortran has:

./libgfortran.h:#define DEFAULT_RECL 1073741824

which gets used with

./runtime/environ.c:  {"GFORTRAN_DEFAULT_RECL", DEFAULT_RECL,
&options.default_recl,

and in io/unit.c's init_units for stdin, stdout and stderr. Others get set via
io/open.c's new_unit: u->recl = opp->recl_in;


And in transfer, one finds code like:

  /* For preconnected units with default record length, set bytes left
 to unit record length and proceed, otherwise error.  */
   ...
  && dtp->u.p.current_unit->recl == DEFAULT_RECL))
dtp->u.p.current_unit->bytes_left = dtp->u.p.current_unit->recl;

[Bug ada/53795] [4.8 Regression] FAIL: gnat.dg/old_errors.adb

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2012-06-28 
15:48:04 UTC ---
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189042

[Bug inline-asm/49611] Inline asm should support input/output of flags

2012-06-28 Thread jbemmel at zonnet dot nl

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

Jeroen van Bemmel  changed:

   What|Removed |Added

 CC||jbemmel at zonnet dot nl

--- Comment #4 from Jeroen van Bemmel  2012-06-28 
16:06:18 UTC ---
Ideally, there would be some way to express that a given asm goto block depends
on the flags, to prevent GCC from reordering flags-changing instructions and
breaking the code.

As a compromise, GCC could simply assume by default that asm goto blocks depend
on the flags. Like Ryan, I believe that most people using asm goto would use it
for such a purpose, and any missed optimization opportunities are a small price
to pay for correct code.

[Bug tree-optimization/46556] Code size regression in struct access

2012-06-28 Thread wschmidt at gcc dot gnu.org

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

William J. Schmidt  changed:

   What|Removed |Added

   Keywords|patch   |missed-optimization
 Status|NEW |ASSIGNED
  Component|rtl-optimization|tree-optimization
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.8.0

--- Comment #8 from William J. Schmidt  2012-06-28 
16:10:16 UTC ---
This will be handled as part of GIMPLE strength reduction.

[Bug c++/53788] C++11 decltype sfinae static member function check (4.7.1)

2012-06-28 Thread exa7z at live dot com

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

--- Comment #4 from exa7z at live dot com 2012-06-28 17:37:08 UTC ---
You are correct in noting that even in C++03 g++ behaves like this. I also
tried several other examples yesterday that led me to the same result. And I
think it is because of the way g++ behaves differently for what it concerns its
"vision" of dependent/non-dependent type names in this particular case.

The bug submission code was based on this:

template
static std::true_type check(X*, decltype(T::fun())* = 0);


But it was supposed to be the following which compiles everywhere and is indeed
correct: (was worn out at the time and while testing I let a T in the place of
X by mistake):


template
static std::true_type check(X*, decltype(X::fun())* = 0);


The difference is in using a non - dependent type name within check() for what
check() is concerned when T is used in decltype(T::fun()) while the corrected
version with X uses a dependent type name in decltype(X::fun()) for what
check() is concerned.

When check() gets to instantiation, T has already been substituted  before X
due to it being the dependent type name in has_static<...> and thus the non -
dependent name in check().

As such, a compiler will first have to decide whether the type name involved is
dependent or not, and since T is the non - dependent type for what check() is
concerned. Now, since the static ::fun() is not a valid test{} member, we are
trying to feed to decltype an unresolved symbol related to the *non-dependent*
type name for what check() is concerned.

Therefore, SFINAE cannot even take place because of that, T is the anchor
keeping the ship from sailing *when* a compiler does *not* make a distinction
between dependent and non-dependent type names in this case.

As a note, I believe there is one more source of confusion due to the existance
of .fun() as a symbol. The fact that there is a non - static member fun() makes
so that the error message we get from the other compilers is that of saying to
us that practically we should have used decltype(T().fun()) since they see that
a .fun() (NOT ::fun()) exists and deduce that likely we erred in our call
syntax... And the dependent / non - dependent type name issue is ignored. Since
compilers can make this distinction I do not see why a dependent/non-dependent
type name error should not have been raised in this case by *all*.

In summary, I believe that g++ is most likely behaving the way it does because
it treats both X and T as dependent type names in check() despite they are not
(only X is the actual dependent type name for check()) thus allowing SFINAE to
take place (aka T is not an anchor anymore!).

[Bug c++/53788] C++11 decltype sfinae static member function check (4.7.1)

2012-06-28 Thread exa7z at live dot com

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

--- Comment #5 from exa7z at live dot com 2012-06-28 17:42:48 UTC ---
> 
> Therefore, SFINAE cannot even take place because of that, T is the anchor
> keeping the ship from sailing *when* a compiler does *not* make a distinction
> between dependent and non-dependent type names in this case.
>

[edit]
Therefore, SFINAE cannot even take place because of that, T is the anchor
keeping the ship from sailing *when* a compiler *does* make a *correct*
distinction between dependent and non-dependent type names in this case.
[/edit]

[Bug tree-optimization/53645] Missed optimization for vector integer division lowering

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

--- Comment #8 from Jakub Jelinek  2012-06-28 
17:52:59 UTC ---
Author: jakub
Date: Thu Jun 28 17:52:51 2012
New Revision: 189052

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189052
Log:
PR tree-optimization/53645
* tree-vect-generic.c (expand_vector_divmod): Use MULT_HIGHPART_EXPR
instead of VEC_WIDEN_MULT_{HI,LO}_EXPR followed by VEC_PERM_EXPR
if possible.

* gcc.c-torture/execute/pr53645-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr53645-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug tree-optimization/51581] Integer division by constant is not vectorized