[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  2011-10-18 
07:23:10 UTC ---
>From the standard:
"C568 (R536) A data-i-do-object or a variable that appears as a
 data-stmt-object shall not be an object designator in which a
 pointer appears other than as the entire rightmost part-ref."

"C567 (R536) A variable whose designator appears as a
 data-stmt-object or a data-i-do-object shall not be a dummy
 argument, accessed by use or host association, in a named
 common block unless the DATA statement is in a block data
 program unit, in blank common, a function name, a function
 result name, an automatic object, or an allocatable variable."

To be fixed beyond the patch of attachment 25534
* ICE below (1) for init of DT with default init
* ICE below (2) with structure constructor, which initializes a pointer
(plus: test cases, revised error message wording)
* (3) Pointer init in DATA: Also "initial-data-target" is allowed

For the pointer init, see also PR 45290.

! === (1) ===
module m
type t
  integer :: a  = 7
end type t
type t2
  integer :: b
end type t2
end module m

use m
implicit type(t)(x), type(t2)(y)
! ICE in trans:
! Invalid as "nonpointer object has default initialization"
DATA x%a/8/

! OK:
!DATA y%b/5/
!type(t2) :: y = t2(7) ! { dg-error "initializer already appears in a DATA
statement" }
end
! = (2) =
module m
  type t
integer :: a
integer, pointer :: bar
  end type t
end module m

subroutine test()
  use m
  type(t) :: x ! = t(4, null()) ! OK
 DATA x/t(4, null())/ ! ICE in the middle end
end subroutine test
! = (3) =
type t
  integer, pointer :: ptr
end type t
integer, target, save :: tgt

! Version A:
!type(t) :: x = t(tgt)
! Rejected with "has not been declared or is a variable,
! which does not reduce to a constant expression"

! Version 2
type(t) :: x
DATA x%ptr /tgt/ ! error "must be a PARAMETER in DATA statement"

tgt = 7
print *, ptr
end

[Bug fortran/45290] [F08] pointer initialization

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #14 from Tobias Burnus  2011-10-18 
07:23:36 UTC ---
See also PR 50410 comment 9

[Bug target/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #6 from Popielewicz  2011-10-18 07:25:24 
UTC ---
OK.
Because I suspected, that IRA could help I have decided to port 4.4.6, the last
with coff.
Another motivation was tree-vectorizer.

I have discovered immediately , that purge-dead-edges bug appears. I have found
in one bug description for higher releases the solution for something similar
and it solved the problem for a while . Namely I have copied the function
sel_bb_empty_or_nop_p from release 4.6 , added a line of code(EDGE_COUNT etc) ,
and then commented out one gcc_assert in basic_block.h. The problem seems to be
related with single succesors etc.

As a result the optimizition flag -O2/-O3 etc works, at least for simpler
programs. What is more important even ftree-vectorize(enabled also by -O3)
works(shown by ftree-vectorizer-verbose=n) , but for small programs.
For bigger programs remove-insn at emit-rtl.c bug appears.

usable solution is to compile small functions with tree loops with gcc-4.4.6
and the rest of the programs with stable gcc-3.2.3.

[Bug middle-end/50706] Fold check failed (expected tree that contains 'typed' structure, have 'block' in fold_checksum_tree, at fold-const.c:13921)

[Paulo.Matos at csr dot com]

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

Paulo J. Matos  changed:

   What|Removed |Added

 CC||Paulo.Matos at csr dot com

--- Comment #3 from Paulo J. Matos  2011-10-18 
07:50:36 UTC ---
I also stumbled upon this. Reproduced with 4.6 and 4.7.
I attach yet another testcase.

[Bug middle-end/50706] Fold check failed (expected tree that contains 'typed' structure, have 'block' in fold_checksum_tree, at fold-const.c:13921)

[Paulo.Matos at csr dot com]

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

--- Comment #4 from Paulo J. Matos  2011-10-18 
07:51:28 UTC ---
Created attachment 25537
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25537
Another testcase.

[Bug inline-asm/50772] New: Inline assembler "A" constrain works non-expectedly on 64-bits target

[vagran.ast at gmail dot com]

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

 Bug #: 50772
   Summary: Inline assembler "A" constrain works non-expectedly on
64-bits target
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vagran@gmail.com


As per documentation "A" constrain of inline assembler should accept/return
64-bits value in eax:edx registers pair. However it doesn't work on 64-bits
target, the value of just %rdx register is used instead.
Use case example:
rdmsr and wrmsr x86 instruction use eax:edx pair in both 32 and 64 bits mode.
The following code will not work on 64-bits target:

static inline u64
rdmsr(u32 msr)
{
u64 rc;
ASM (
"rdmsr"
: "=A"(rc)
: "c"(msr)
);
return rc;
}
Value in %rdx will be used as the result, %rax value will be discarded. The
same situation when "A" constrain is used as input. It is not a major problem,
it can be easily worked around by additional instructions in inline assembler
block. But IMHO it should be fixed either in the compiler code (preferably) or
in documentation (mention that it is not supported on 64-bits target).

[Bug middle-end/48087] [4.5/4.6/4.7 Regression] -Wall -Werror adds warnings over and above those generated by -Wall

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  
2011-10-18 08:26:04 UTC ---
On Tue, 18 Oct 2011, paolo.carlini at oracle dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48087
> 
> Paolo Carlini  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2011-10-18
>  CC||paolo.carlini at oracle dot
>||com
>  Ever Confirmed|0   |1
> 
> --- Comment #2 from Paolo Carlini  
> 2011-10-18 01:18:24 UTC ---
> Well, this does, it (fixes both) but I don't know if we are aiming for
> something better, no good including the whole "diagnostic.h"?!?
> 
> Index: tree-cfg.c
> ===
> --- tree-cfg.c(revision 180119)
> +++ tree-cfg.c(working copy)
> @@ -37,7 +37,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "timevar.h"
>  #include "tree-dump.h"
>  #include "tree-pass.h"
> -#include "diagnostic-core.h"
> +#include "diagnostic.h"
>  #include "except.h"
>  #include "cfgloop.h"
>  #include "cfglayout.h"
> @@ -7380,7 +7380,8 @@ execute_warn_function_return (void)
>else if (warn_return_type
> && !TREE_NO_WARNING (cfun->decl)
> && EDGE_COUNT (EXIT_BLOCK_PTR->preds) > 0
> -   && !VOID_TYPE_P (TREE_TYPE (TREE_TYPE (cfun->decl
> +   && !VOID_TYPE_P (TREE_TYPE (TREE_TYPE (cfun->decl)))
> +   && !errorcount)
>  {
>FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR->preds)
>  {

I don't think that's good.  You'll miss the warning for subsequent
functions that do not have errors for example.

Either we want to generally supress all warnings once we emitted
an error (then this should be done in generic diagnostic machinery),
or we shouldn't bother with this.  We can make the generic machinery
track errors per function if we like to.

[Bug middle-end/50716] Segmentation fault caused by misaligned vector access

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-10-18 
08:46:06 UTC ---
Author: rguenth
Date: Tue Oct 18 08:46:00 2011
New Revision: 180125

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180125
Log:
2011-10-18  Richard Guenther  

PR middle-end/50716
* expr.c (get_object_or_type_alignment): New function.
(expand_assignment): Use it.
(expand_expr_real_1): Likewise.

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

[Bug tree-optimization/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org 2011-10-18 08:57:43 UTC ---
Author: vries
Date: Tue Oct 18 08:57:39 2011
New Revision: 180126

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180126
Log:
2011-10-18  Tom de Vries  

PR tree-optimization/50672
* tree-ssa-dce.c (mark_virtual_operand_for_renaming): New function,
factored out of ...
(mark_virtual_phi_result_for_renaming): Use
mark_virtual_operand_for_renaming.
* tree-flow.h (mark_virtual_operand_for_renaming): Declare.
* tree-ssa-tail-merge.c (release_last_vdef): New function.
(purge_bbs): Add update_vops parameter.  Call release_last_vdef for each
deleted basic block.
(tail_merge_optimize): Add argument to call to purge_bbs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-flow.h
trunk/gcc/tree-ssa-dce.c
trunk/gcc/tree-ssa-tail-merge.c

[Bug middle-end/50741] [4.7 Regression] remove_unused_locals causes seg fault

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-10-18 
09:17:55 UTC ---
(In reply to comment #5)
> And of course, it's the ctor cloning:
> 
> DECL_CONTEXT of _rL_53 is ,
> but current_function_decl is .
> 
> So it's similar to PR50640, in that the initializers of statics declared
> in different functions aren't walked.  That's reasonable assuming that
> such initializers are walked when the declaring function is handled (which
> is reasonable to expect, as otherwise the initializer couldn't have been
> known).  But here the cloning and rewriting gets into our way.

So maybe we should, in remove_unused_locals, not walk initializers of
non-locals either (their elements will never be in a BLOCK local to
our function).  Even the decl itself I suppose.  So,

Index: gcc/tree-ssa-live.c
===
--- gcc/tree-ssa-live.c (revision 180126)
+++ gcc/tree-ssa-live.c (working copy)
@@ -372,7 +372,8 @@ mark_all_vars_used_1 (tree *tp, int *wal

   /* Only need to mark VAR_DECLS; parameters and return results are not
  eliminated as unused.  */
-  if (TREE_CODE (t) == VAR_DECL)
+  if (TREE_CODE (t) == VAR_DECL
+  && decl_function_context (t) == current_function_decl)
 {
   if (data != NULL && bitmap_clear_bit ((bitmap) data, DECL_UID (t)))
mark_all_vars_used (&DECL_INITIAL (t), data);

?  At least I can't see how this would break any of its functionality,
and it fixes the ICE.  Bootstrapping/testing now.

[Bug target/50350] [4.6 Regression] ICE (segfault) in canonicalize_float_value

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-10-18 
09:19:08 UTC ---
Created attachment 25538
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25538
gcc46-pr50350.patch

I couldn't reproduce it with a x86_64-linux -> ia64-linux cross, that said, the
patch was easy to backport.
Could you please quickly verify if it fixes it?
So far I've bootstrapped/regtested it on x86_64-linux and i686-linux.

I'd like to roll gcc-4.6.2-rc1 later today or tomorrow, so the sooner you could
verify it the better.

[Bug inline-asm/50772] Inline assembler "A" constrain works non-expectedly on 64-bits target

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-10-18 
09:27:34 UTC ---
Documentation says:

@item A
The @code{a} and @code{d} registers.  This class is used for instructions
that return double word results in the @code{ax:dx} register pair.  Single
word values will be allocated either in @code{ax} or @code{dx}.
For example on i386 the following implements @code{rdtsc}:

@smallexample
unsigned long long rdtsc (void)
@{
  unsigned long long tick;
  __asm__ __volatile__("rdtsc":"=A"(tick));
  return tick;
@}
@end smallexample

This is not correct on x86_64 as it would allocate tick in either @code{ax}
or @code{dx}.  You have to use the following variant instead:

@smallexample
unsigned long long rdtsc (void)
@{
  unsigned int tickl, tickh;
  __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh));
  return ((unsigned long long)tickh << 32)|tickl;
@}
@end smallexample

[Bug c++/50771] redundant argument passing code (x64) + inefficient use of stack space

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-10-18
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-10-18 
09:28:59 UTC ---
Because the ABI says so.

But you didn't provide information on what target architecture or OS you
are running on.

[Bug tree-optimization/50769] [4.7 Regression] ICE: in phi_alternatives_equal, at tree-cfgcleanup.c:355 with -O2 -fno-delete-null-pointer-checks -fno-guess-branch-probability -fipa-pta

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-18
 CC||tom at codesourcery dot com
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-10-18 
09:32:05 UTC ---
Happens after PRE, -fno-tree-tail-merge fixes it.

[Bug c/50773] New: float values are printed with greater precision than the float data type has when given as an argument to printf()

[momchil at xaxo dot eu]

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

 Bug #: 50773
   Summary: float values are printed with greater precision than
the float data type has when given as an argument to
printf()
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: momc...@xaxo.eu


test case:

#include 

int
main(int argc, char *argv[])
{
float a = 268517138.f;
printf(" 268517138.f = %f\t%f\n", 268517138.f, a);

return 0;
}

output when compiling with -fexcess-precision=standard:
 268517138.f = 268517138.00268517152.00

output when compiling with -fexcess-precision=fast:
 268517138.f = 268517152.00268517152.00

reference thread: http://gcc.gnu.org/ml/gcc-help/2011-10/msg00120.html

gcc versions tested:

Using built-in specs.
COLLECT_GCC=gcc46
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd8.1/4.6.0/lto-wrapper
Target: i386-portbld-freebsd8.1
Configured with: ./../gcc-4.6-20110101/configure --enable-lto=no --disable-nls
--libdir=/usr/local/lib/gcc46 --libexecdir=/usr/local/libexec/gcc46
--program-suffix=46 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-system-zlib --disable-rpath --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc46 --build=i386-portbld-freebsd8.1
Thread model: posix
gcc version 4.6.0 20110101 (experimental) (GCC) 

Using built-in specs.
COLLECT_GCC=gcc45
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd8.2/4.5.3/lto-wrapper
Target: i386-portbld-freebsd8.2
Configured with: ./../gcc-4.5-20110310/configure --enable-lto=yes
--with-libelf=/usr/local --disable-nls --libdir=/usr/local/lib/gcc45
--libexecdir=/usr/local/libexec/gcc45 --program-suffix=45
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc45/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-system-zlib --disable-rpath --enable-libgcj --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc45
--build=i386-portbld-freebsd8.2
Thread model: posix
gcc version 4.5.3 20110310 (prerelease) (GCC)

[Bug tree-optimization/50768] [4.7 Regression] ICE: in execute_todo, at passes.c:1731 with -O2 -ftracer

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-10-18
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-10-18 
09:35:29 UTC ---
Hmm, looks similar to the issue I fixed recently (memcpy is folded by
cfgcleaup propagating a single-arg PHI).  I'll have a looksee.

[Bug tree-optimization/50767] [4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1004 with -O2 -fno-tree-copy-prop -fno-tree-dominator-opts

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-10-18
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-10-18 
09:39:16 UTC ---
Confirmed.  For

# VUSE <.MEM_4(D)>
ss.1_8 = 0B;

we ask

648   if (gimple_vuse (def_stmt)
649   && gimple_assign_single_p (def_stmt)
650   && refs_may_alias_p (gimple_assign_lhs (stmt),
651gimple_assign_rhs1
(def_stmt)))

but the stmt should not have a VUSE, calling update_stmt on it removes the
VUSE.  Probably caused by the patch for PR50389, related to PR50768.  Mine.

[Bug middle-end/48087] [4.5/4.6/4.7 Regression] -Wall -Werror adds warnings over and above those generated by -Wall

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2011-10-18 
09:41:11 UTC ---
Indeed, after a day of work I should not even try sending drafts. Anyway, the
substantive point I was missing is *per function*.

Is there a simple explanation for why the problem didn't show up in 4.4.x?

[Bug middle-end/50724] cmath's floating-point classification implementations inconsistent with math.h

[redi at gcc dot gnu.org]

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

--- Comment #33 from Jonathan Wakely  2011-10-18 
09:41:50 UTC ---
(In reply to comment #31)
> I can't add an attribute to the system isnan from my user code, or can I?  
> I've
> never been quite sure what Paolo was referring to, can someone clue me in?  It
> sounded like he was saying the builtins could be given an attribute to specify
> -fno-finite-math-only which would only affect their specific usage?  Maybe he
> just meant I could apply different flags in different translation units of my
> own code, in which case I've misunderstood.  Basically, what's the "new
> optimization attribute and pragma"?

Read the frabjous manual:
http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007boptimize_007d-function-attribute-2496

You shouldn't need to put code in separate translation units, you can specify
different optimizations per function (though I haven't checked if that works
for -fno-finite-math-only)

[Bug tree-optimization/50767] [4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1004 with -O2 -fno-tree-copy-prop -fno-tree-dominator-opts

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-10-18 
09:51:17 UTC ---
PRE produces

:
  # VUSE <.MEM_4(D)>
  pretmp.5_8 = 0B;

:
  # .MEM_3 = PHI <.MEM_4(D)(2), .MEM_6(4)>
  # VUSE <.MEM_3>
  s.0_1 = s;
  ss.1_2 = pretmp.5_8;
  # .MEM_5 = VDEF <.MEM_3>
  s.0_1->s = ss.1_2;
  # .MEM_6 = VDEF <.MEM_5>
  bar ();

:
  goto ;

which happens to fold ss->s for the first time, to the above but it misses
to call update_stmt.

[Bug rtl-optimization/50765] [4.7 Regression] ICE: in expand_insn, at optabs.c:7681 with -ftree-vectorize -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug fortran/50774] New: Internal Compiler Error when march=bdver1

[ibethune at epcc dot ed.ac.uk]

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

 Bug #: 50774
   Summary: Internal Compiler Error when march=bdver1
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ibeth...@epcc.ed.ac.uk


Created attachment 25539
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25539
Source file which triggers the ICE

In the attached simple code, compilation fails when using the -march=bdver1
flag:


ibethune@login3:~/gcc46_test> gfortran -c -O3 -ffast-math -g -march=bdver1 
helium_interactions.f90
gfortran: internal compiler error: Segmentation fault (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Without the -march file compilation completes successfully.

Gfortran version infromation below:

ibethune@login3:~/gcc46_test> gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/4.6.1/bin/../snos/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc/4.6.1/snos/libexec/gcc/x86_64-suse-linux/4.6.1/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../xt-gcc-4.6.1/configure --prefix=/opt/gcc/4.6.1/snos
--disable-nls --libdir=/opt/gcc/4.6.1/snos/lib --enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/4.6.1/snos/include/g++
--with-slibdir=/opt/gcc/4.6.1/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit x86_64-suse-linux --with-mpc=/opt/gcc/mpc/0.8.1
--with-mpfr=/opt/gcc/mpfr/2.4.2 --with-gmp=/opt/gcc/gmp/4.3.2 --with-sysroot=
Thread model: posix
gcc version 4.6.1 20110627 (Cray Inc.) (GCC)

Cheers

- Iain

[Bug tree-optimization/10980] vararg functions are not inlined

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2011-10-18 
09:54:03 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > I bet it just ignores the attribute that is not how the attribute is
> > supposed to work.
> > 
> > We output error in this case intentionally (and warning in at the same
> > spot if function is declared inline and -Winline is given).
> > Functions marked always_inlined really ought to be always inlined and
> > attribute is supposed to be useable in the cases where compilation would
> > fail otherwise (such as SSE buitins).
> > 
> > Our documentation is however not particularly clear here, perhaps it should
> > be updated...
> > 
> > Honza
> 
> Seeing that documentation is unclear (no mention of when errors or warnings 
> are
> produced), and Qt Creator devs want to know what version of GCC started
> errorring on this, could you please let me know what GCC version started
> producing errors? Thanks!

GCC always errored out on this (previously by sorry(), now with error()).

We can possibly inline varargs functions when we delay lowering the
vararg builtins to the stdarg pass (which would clean up its implementation
a lot ...).

[Bug tree-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-18
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-10-18 
09:54:33 UTC ---
Confirmed.

[Bug tree-optimization/50763] [4.7 Regression] ICE: verify_gimple failed: missing PHI def with -ftree-tail-merge

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

--- Comment #3 from Richard Guenther  2011-10-18 
09:54:47 UTC ---
Confirmed.

[Bug middle-end/50724] cmath's floating-point classification implementations inconsistent with math.h

[rguenth at gcc dot gnu.org]

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

--- Comment #34 from Richard Guenther  2011-10-18 
10:03:53 UTC ---
(In reply to comment #32)
> To be honest, this bug report is not under any discussion anymore.  I tried to
> get any sort of sanity, but in the end it's all about egos; you won't
> get what you want, it's really useless to reopen this particular report.
> The libstdc++ maintainers aren't as sensible as the Apple maintainers, the
> middle-end maintainers aren't as useful as they should be (hiding behind less
> than useful "but that's how it's documented" arguments).  And just generally
> the
> responses to understandable requests are more than lacking in defense of not
> implementing it.
> 
> (I think it's hopeless to include even more justifications for your use cases,
> it'll just be food for the reverse-trolls)
> 
> He's not a troll.  The bug-closers _are_, and the answers to closing are
> severely lacking in any sort of justification.  And yes, I'm aware of past
> discussions.  And no, I don't think any of it has much merit for the 
> discussion
> at hand.  They are either exaggerating (but, OMG, what to do with the
> RTL "<>" -> "!=" transformation???) (answer, "nothing"), and "it's all quite
> difficult", or "but currently we do builtin_isnan to 'x!=x', and we can't
> recover from that" or they're not capturing the problem at all.  Many of the
> justifications even just turn back to "but that's how it's documented since
> ", and that's even more sorry than any other sort of 
> "justification".
> Just because a past mistake was documented as such doesn't mean it's right.
> 
> So, reporter, please go away, GCC won't fix your problem, even though it would
> be reasonable to change.  Instead I'd advise you to some other more reasonable
> compiler, LLVM, or maybe a commercial one.  GCC is all about defending past
> mistakes in order not to change anything, not at all about being helpful to
> the user.
> 
> From the proponents of the current state of affairs I would appreciate at 
> least
> a hint of where this was "discussed to death" already, the three PRs from
> Andrew certainly are not a case.  I'd speculate most of them were argued from
> the point of "let's not change anything but rather argue that current 
> behaviour
> is the right one (because that's less work, although I won't say that)".

Feel free to provide a patch that splits -ffinite-math-only into two pieces,
excempting optimizing the classification builtins from -ffast-math.  Please
make sure that with that code generation quality is not worse comparing
the new -ffast-math to the old -ffast-math -fno-finite-math-only (thus
make sure the classification macros are still expanded inline).  For that
to work you probably have to change RTL optimizers to not do comparison
code folding based on flag_finite_math_only (so you can expand isnan
to !(x==x) even with -ffinite-math-only).  Tree optimizers should have
already converted all these codes (so you still need to make sure to
not fold the classification builtins to comparisons at the tree level).

I would approve a patch along the above lines but I won't spend any time
on producing such patch.

I will also approve a patch that amends the current documentation
of -ffinite-math-only to say that it includes optimizing FP classification
macros.

[Bug c/50773] float values are printed with greater precision than the float data type has when given as an argument to printf()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-10-18 
10:05:56 UTC ---
%f prints doubles, float arguments to variadic argument functions are promoted
to double (thus, you can't print a "float" value with printf)

[Bug c++/44648] missing -Wunused warning on a const variable in if statement

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |rguenth at gcc dot gnu.org
  Known to fail||

--- Comment #2 from Paolo Carlini  2011-10-18 
10:14:57 UTC ---
Is this also a middle-end issue? Or the C++ front end is failing to do
something important when it sees 'if (const bool b = 1)' ?

[Bug c/50773] float values are printed with greater precision than the float data type has when given as an argument to printf()

[aph at gcc dot gnu.org]

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

Andrew Haley  changed:

   What|Removed |Added

 CC||aph at gcc dot gnu.org

--- Comment #2 from Andrew Haley  2011-10-18 10:20:40 
UTC ---
This is definitely a C front-end bug.  If you look at the gimple dump, you can
see that the literal 268517138.f isn't being correctly truncated, but instead
the constant 2.68517138e+8 is being used instead:

main (int argc, char * * argv)
{
  double D.2549;
  const char * restrict D.2550;
  double D.2551;
  const char * restrict D.2552;
  int D.2553;
  float a;

  a = 2.68517152e+8;
  D.2549 = (double) a;
  D.2550 = (const char * restrict) &" 268517138.f = %f\t%f\n"[0];
  printf (D.2550, 2.68517138e+8, D.2549);

C++ FE does it correctly:

int main(int, char**) (int argc, char * * argv)
{
  double D.2226;
  double D.2227;
  double D.2228;
  double D.2229;
  int D.2230;

  {
float a;

a = 2.68517152e+8;
D.2226 = (double) a;
D.2227 = (double) 2.68517152e+8;
printf (&" 268517138.f = %f\t%f\n"[0], D.2227, D.2226);

[Bug c/50773] float values are printed with greater precision than the float data type has when given as an argument to printf()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|RESOLVED|REOPENED
   Last reconfirmed||2011-10-18
 CC||jsm28 at gcc dot gnu.org
 Resolution|INVALID |
 Ever Confirmed|0   |1
  Known to fail||4.7.0

--- Comment #3 from Richard Guenther  2011-10-18 
10:43:08 UTC ---
(In reply to comment #2)
> This is definitely a C front-end bug.  If you look at the gimple dump, you can
> see that the literal 268517138.f isn't being correctly truncated, but instead
> the constant 2.68517138e+8 is being used instead:
> 
> main (int argc, char * * argv)
> {
>   double D.2549;
>   const char * restrict D.2550;
>   double D.2551;
>   const char * restrict D.2552;
>   int D.2553;
>   float a;
> 
>   a = 2.68517152e+8;
>   D.2549 = (double) a;
>   D.2550 = (const char * restrict) &" 268517138.f = %f\t%f\n"[0];
>   printf (D.2550, 2.68517138e+8, D.2549);
> 
> C++ FE does it correctly:
> 
> int main(int, char**) (int argc, char * * argv)
> {
>   double D.2226;
>   double D.2227;
>   double D.2228;
>   double D.2229;
>   int D.2230;
> 
>   {
> float a;
> 
> a = 2.68517152e+8;
> D.2226 = (double) a;
> D.2227 = (double) 2.68517152e+8;
> printf (&" 268517138.f = %f\t%f\n"[0], D.2227, D.2226);

Needs -fexcess-precision=standard -m32 to trigger.  libcpp does the
parsing of FP constants IIRC, and the C++ frontend does not implement
-fexcess-precision.

CCing Joseph.

Testcase that fails with -fexcess-precision=standard -m32:

extern void abort (void);
int
main()
{
  float a = 268517138.f;
  if (a != 268517138.f)
abort ();
  return 0;
}

[Bug c++/44648] missing -Wunused warning on a const variable in if statement

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  
2011-10-18 10:46:18 UTC ---
On Tue, 18 Oct 2011, paolo.carlini at oracle dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44648
> 
> Paolo Carlini  changed:
> 
>What|Removed |Added
> 
>  CC|gcc-bugs at gcc dot gnu.org |rguenth at gcc dot gnu.org
>   Known to fail||
> 
> --- Comment #2 from Paolo Carlini  
> 2011-10-18 10:14:57 UTC ---
> Is this also a middle-end issue? Or the C++ front end is failing to do
> something important when it sees 'if (const bool b = 1)' ?

C++ FE

[Bug fortran/47023] C_Sizeof: Rejects valid code

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org 2011-10-18 10:48:15 UTC ---
Author: janus
Date: Tue Oct 18 10:48:12 2011
New Revision: 180130

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180130
Log:
2011-10-18  Janus Weil  

PR fortran/47023
* decl.c (verify_c_interop_param): Renamed to
'gfc_verify_c_interop_param'. Add error message for polymorphic
arguments.
(verify_c_interop): Renamed to 'gfc_verify_c_interop'. Reject
polymorphic variables.
(verify_bind_c_sym): Renamed 'verify_c_interop'.
* gfortran.h (verify_c_interop,verify_c_interop_param): Renamed.
* check.c (gfc_check_sizeof): Ditto.
* resolve.c (gfc_iso_c_func_interface,resolve_fl_procedure): Ditto.
* symbol.c (verify_bind_c_derived_type): Ditto.


2011-10-18  Janus Weil  

PR fortran/47023
* gfortran.dg/iso_c_binding_class.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_class.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/44648] missing -Wunused warning on a const variable in if statement

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|rguenth at gcc dot gnu.org  |

--- Comment #4 from Paolo Carlini  2011-10-18 
10:52:42 UTC ---
Ok, thanks.

[Bug middle-end/50741] [4.7 Regression] remove_unused_locals causes seg fault

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Guenther  2011-10-18 
11:00:49 UTC ---
Bootstraps and tests ok.  But I suppose with BLOCK_NONLOCAL_VARS we could
refer to an inlined functions static vars, and their initializer could refer
to static vars from the inlined function that are otherwise unused.

int foo()
{
  static volatile int i;
  static volatile int * volatile p = &i;
  return *p;
}

int bar()
{
  return foo();
}

when foo is inlined into bar.  And indeed with the patch we get

{ Scope block 0x75b3ac30#0

  { Scope block 0x75b950a0#2 t.c:10 Originating from :  static intD.6
fooD.1604 ();

{ Scope block 0x75b950f0#3 Originating from : 0x75b3ab90#0
  static volatile intD.6 i.1606D.1606; (nonlocalized)
  static volatile intD.6 * volatile p.1607D.1607 = &i.1606D.1606;
(nonlocalized)

}

  }

}
bar ()
{
  volatile intD.6 * volatile p.0D.2736;
  intD.6 D.2735;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # VUSE <.MEMD.2734_2(D)>
  # PT = nonlocal escaped
  p.0D.2736_4 ={v} p.1607D.1607;
  # VUSE <.MEMD.2734_2(D)>
  D.2735_5 ={v} *p.0D.2736_4;
  # VUSE <.MEMD.2734_2(D)>
  return D.2735_5;

while without we get

Scope blocks after cleanups:

{ Scope block 0x75b3ac30#0

  { Scope block 0x75b950a0#2 t.c:10 Originating from :  static intD.6
fooD.1604 ();

{ Scope block 0x75b950f0#3 Originating from : 0x75b3ab90#0
  static volatile intD.6 i.1606D.1606; (nonlocalized)
  static volatile intD.6 * volatile p.1607D.1607 = &i.1606D.1606;
(nonlocalized)

}

  }

bar ()
{
  volatile intD.6 * volatile p.0D.2736;
  static volatile intD.6 iD.1606;
  static volatile intD.6 * volatile p.1607D.1607 = &iD.1606;
  intD.6 D.2735;
  static volatile intD.6 * volatile p.1607D.1607 = &iD.1606;
  static volatile intD.6 iD.1606;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # VUSE <.MEMD.2734_2(D)>
  # PT = nonlocal escaped
  p.0D.2736_4 ={v} p.1607D.1607;
  # VUSE <.MEMD.2734_2(D)>
  D.2735_5 ={v} *p.0D.2736_4;
  # VUSE <.MEMD.2734_2(D)>
  return D.2735_5;
  # SUCC: EXIT [100.0%]

so there is a difference in what local_decls contains.  Not sure if that
is important though.

[Bug fortran/47023] C_Sizeof: Rejects valid code

[janus at gcc dot gnu.org]

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

--- Comment #18 from janus at gcc dot gnu.org 2011-10-18 11:06:12 UTC ---
(In reply to comment #14)
>  * treat BT_CLASS in decl.c (comment #1)

Fixed with r180130.

Left to do:

>  * the error in comment #0 could be downgraded to a warning (which one gets in
> other cases similar to this)
>  * reject proc-pointers for SIZEOF (comment #7)

(proc-pointers in C_SIZEOF are being rejected already)

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #25520|0   |1
is obsolete||

--- Comment #43 from Iain Sandoe  2011-10-18 11:05:38 
UTC ---
Created attachment 25540
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25540
demonstration of the fault using c++/vendor's tools

after Eric solved my inverted-logic thinko ... 
.. I reproduced using g++-4.2
bug filed as radar #10302855.

I think we'll need to apply the patch in the short/medium term and then figure
out how to control it - which will depend on which system(s) a fix is released
for.

[Bug tree-optimization/50763] [4.7 Regression] ICE: verify_gimple failed: missing PHI def with -ftree-tail-merge

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org 2011-10-18 11:12:32 UTC ---
Created attachment 25541
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25541
patch, handles case that either vuse1 or vuse2 is NULL_TREE in update_vuses.

Currently testing on x86_64.

2011-10-18  Tom de Vries  

PR tree-optimization/50763
* tree-ssa-tail-merge.c (update_vuses): Add and use vuse1_phi_args
argument.  Set var to SSA_NAME_VAR of vuse1 or vuse2, and use var.
Handle case that def_stmt2 is NULL.  Use phi result as phi arg in case
vuse1 or vuse2 is NULL_TREE.  Replace uses of vuse1 if vuse2 is
NULL_TREE.  Remove code to limit replacement of uses.
(replace_block_by): Update vops if phi_vuse1 or phi_vuse2 is NULL_TREE.
Set vuse1_phi_args if vuse1 is a phi defined in bb1. Add vuse1_phi_args
as argument to call to update_vuses.

* gcc.dg/pr50763.c: New test.

[Bug tree-optimization/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from vries at gcc dot gnu.org 2011-10-18 11:14:35 UTC ---
patch checked in, marking fixed.

[Bug c++/50097] Private base class enumeration

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Paolo Carlini  2011-10-18 
11:31:06 UTC ---
Let's close as duplicate of PR47346, and let's ask Dodji to double check that
his ongoing work fixes this one too.

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

[Bug c++/47346] access control for nested type is ignored in class template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||wolfgang.roe...@gi-de.com

--- Comment #9 from Paolo Carlini  2011-10-18 
11:31:06 UTC ---
*** Bug 50097 has been marked as a duplicate of this bug. ***

[Bug objc/50743] [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap

[nicola at gcc dot gnu.org]

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

--- Comment #4 from Nicola Pero  2011-10-18 11:31:49 
UTC ---
Author: nicola
Date: Tue Oct 18 11:31:45 2011
New Revision: 180132

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180132
Log:
In gcc/objc/:
2011-10-18  Mikael Pettersson  

PR objc/50743
* objc-act.c (check_duplicates): Cast TREE_VEC_LENGTH result to
size_t to avoid signed/unsigned
comparison.
(insert_method_into_method_map): Likewise.

Modified:
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c

[Bug c++/45690] broken debuginfo with dwarf4?

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |tromey at gcc dot gnu.org

--- Comment #5 from Paolo Carlini  2011-10-18 
11:36:19 UTC ---
Maybe Tom can have a look, see if something (still) makes sense here.

[Bug objc/50743] [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap

[nicola at gcc dot gnu.org]

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

--- Comment #5 from Nicola Pero  2011-10-18 11:39:55 
UTC ---
Can you confirm that trunk is now OK ?

Thanks

[Bug other/50775] New: Register allocator sets up frame and frame pointer with low register pressure

[gjl at gcc dot gnu.org]

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

 Bug #: 50775
   Summary: Register allocator sets up frame and frame pointer
with low register pressure
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr


In the function below, IRA/reload generates a frame/frame pointer and spills
one pointer variable to the frame.

This is bad code because there are many hard registers free and there is no
need for a frame and taking away the frame pointer register Y. Notice that on
the hardware, it is not possible to address the frame via the stack pointer.

== Background ==

The issue is that AVR has only 3 pointer registers X, Y, and Z with the
following addressing capabilities:

 *X, *X++, *--X (R27:R26, call-clobbered)
 *Y, *Y++, *--Y, *(Y+const) (R28:R29, call-saved, frame pointer)
 *Z, *Z++, *--Z, *(Z+const) (R30:R31, call-clobbered)

Older version of the compiler prior to 4.7 trunk r179993 allowed an addressing
mode *(X+const) and emulated it by emitting appropriate instructions sequence
as

  X = X + const
  r = *X
  X = X - const

which was only a rare corner case in the old register allocator, but in the new
allocator this sequence is seen very often leading to code bloat of +50% for
some real-world functions.

This is the reason why -mstrict-X has been added to the AVR backend, see
PR46278. This option denies fake *(X+const) addressing but leads to the
mentioned spills from register allocator and to code even worse as compared to
without setting -mstrict-X.

== Source ==

typedef struct
{
unsigned char a, b, c, d;
} s_t;

unsigned char func1 (s_t *x, s_t *y, s_t *z)
{
unsigned char s = 0;
s += x->a;
s += y->a;
s += z->a;

s += x->b;
s += y->b;
s += z->b;

s += x->c;
s += y->c;
s += z->c;

return s;
}

== Assembler output ==

Besides the bad code of upappropriate setting up a frame, note that the frame
is 4 bytes but only 2 bytes (Y+1,Y+2) are actually used.

func1:
push r28 ;  45pushqi1/1[length = 1]
push r29 ;  46pushqi1/1[length = 1]
 ; SP -= 4 ;  50*addhi3_sp_R[length = 2]
rcall .
rcall .
in r28,__SP_L__ ;  51*movhi/8[length = 2]
in r29,__SP_H__
/* prologue: function */
/* frame size = 4 */
/* stack size = 6 */
.L__stack_usage = 6
std Y+2,r25 ;  2*movhi/4[length = 2]
std Y+1,r24
movw r26,r22 ;  37*movhi/1[length = 1]
ld r25,X ;  8movqi_insn/4[length = 1]
ldd r30,Y+1 ;  38*movhi/3[length = 2]
ldd r31,Y+2
ld r24,Z ;  9movqi_insn/4[length = 1]
add r25,r24 ;  10addqi3/1[length = 1]
movw r26,r20 ;  39*movhi/1[length = 1]
ld r24,X ;  11movqi_insn/4[length = 1]
add r25,r24 ;  12addqi3/1[length = 1]
ldd r24,Z+1 ;  13movqi_insn/4[length = 1]
add r25,r24 ;  14addqi3/1[length = 1]
movw r30,r22 ;  40*movhi/1[length = 1]
ldd r24,Z+1 ;  15movqi_insn/4[length = 1]
add r25,r24 ;  16addqi3/1[length = 1]
movw r30,r20 ;  41*movhi/1[length = 1]
ldd r24,Z+1 ;  17movqi_insn/4[length = 1]
add r25,r24 ;  18addqi3/1[length = 1]
ldd r30,Y+1 ;  42*movhi/3[length = 2]
ldd r31,Y+2
ldd r24,Z+2 ;  19movqi_insn/4[length = 1]
add r25,r24 ;  20addqi3/1[length = 1]
movw r30,r22 ;  43*movhi/1[length = 1]
ldd r24,Z+2 ;  21movqi_insn/4[length = 1]
add r25,r24 ;  22addqi3/1[length = 1]
movw r30,r20 ;  44*movhi/1[length = 1]
ldd r24,Z+2 ;  23movqi_insn/4[length = 1]
add r24,r25 ;  29addqi3/1[length = 1]
/* epilogue start */
 ; SP += 4 ;  56*addhi3_sp_R[length = 4]
pop __tmp_reg__
pop __tmp_reg__
pop __tmp_reg__
pop __tmp_reg__
pop r29 ;  57popqi[length = 1]
pop r28 ;  58popqi[length = 1]
ret ;  59return_from_epilogue[length = 1]
.sizefunc1, .-func1
.ident"GCC: (GNU) 4.7.0 20111017 (experimental)"

== Command line ==

$ avr-gcc in.c -c -save-temps -dp -Os -mmcu=avr4 -mstrict-X -v

Same happens with -O2, -O3 or with -fira-algorithm=priority.

Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
--enable-languages=c,c++ --with-dwarf2 --disable-lto --enable-checking=yes,rtl

Thread model: single

gcc version 4.7.0 20111017 (experimental) (GCC)
GNU C (GCC) version 4.

[Bug tree-optimization/50767] [4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1004 with -O2 -fno-tree-copy-prop -fno-tree-dominator-opts

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-10-18 
11:44:22 UTC ---
Author: rguenth
Date: Tue Oct 18 11:44:15 2011
New Revision: 180134

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180134
Log:
2011-10-18  Richard Guenther  

PR tree-optimization/50767
* tree-ssa-pre.c (create_expression_by_pieces): Update the
folded statement.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr50767.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug target/50350] [4.6 Regression] ICE (segfault) in canonicalize_float_value

[doko at gcc dot gnu.org]

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

--- Comment #6 from Matthias Klose  2011-10-18 
11:44:57 UTC ---
the proposed patch lets the build succeed

[Bug middle-end/50716] Segmentation fault caused by misaligned vector access

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Richard Guenther  2011-10-18 
11:45:53 UTC ---
"Fixed."

[Bug tree-optimization/50767] [4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1004 with -O2 -fno-tree-copy-prop -fno-tree-dominator-opts

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2011-10-18 
11:45:21 UTC ---
Fixed.

[Bug fortran/47023] C_Sizeof: Rejects valid code

[janus at gcc dot gnu.org]

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

--- Comment #19 from janus at gcc dot gnu.org 2011-10-18 12:03:58 UTC ---
(In reply to comment #18)
> >  * reject proc-pointers for SIZEOF (comment #7)

Example:

use iso_c_binding
procedure(real), pointer :: pp
procedure(real) :: proc
pp => sin
print *,sizeof(proc)! (1)
print *,sizeof(pp)  ! (2)
print *,sizeof(pp(0.))  ! (3)
end

Currently this gives the output:

1
1
4

The last one is correct, giving the size of the return value of the called
function. The first one should eventually be rejected. For the second one, it's
not completely clear where the '1' comes from, but it's certainly wrong (in any
possible interpretation).

[Bug other/50775] Register allocator sets up frame and frame pointer with low register pressure

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2011-10-18 
12:07:28 UTC ---
Created attachment 25542
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25542
in.c

Source code from comment #c0 as attachment for conveniance.

[Bug fortran/47023] C_Sizeof: Rejects valid code

[janus at gcc dot gnu.org]

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

--- Comment #20 from janus at gcc dot gnu.org 2011-10-18 12:17:42 UTC ---
(In reply to comment #19)
> > >  * reject proc-pointers for SIZEOF (comment #7)

I think one could also allow them, but then the implementation of SIZEOF needs
to be fixed to give the size of the pointer.

Draft patch:


Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c(revision 180129)
+++ gcc/fortran/trans-intrinsic.c(working copy)
@@ -5088,8 +5088,11 @@ gfc_conv_intrinsic_sizeof (gfc_se *se, gfc_expr *e

   gfc_conv_expr_reference (&argse, arg);

-  type = TREE_TYPE (build_fold_indirect_ref_loc (input_location,
- argse.expr));
+  if (arg->ts.type == BT_PROCEDURE)
+type = TREE_TYPE (argse.expr);
+  else
+type = TREE_TYPE (build_fold_indirect_ref_loc (input_location,
+   argse.expr));

   /* Obtain the source word length.  */
   if (arg->ts.type == BT_CHARACTER)


With this the test case in comment #19 gives:

8
8
4

which is ok, apart from the fact that sizeof(proc) should be rejected.

[Bug fortran/47023] C_Sizeof: Rejects valid code

[janus at gcc dot gnu.org]

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

--- Comment #21 from janus at gcc dot gnu.org 2011-10-18 12:19:54 UTC ---
The question is also how SIZEOF should act on data pointers:

use iso_c_binding
integer(2) :: i
integer(2), pointer :: p
print *,sizeof(i)
print *,sizeof(p)
end

Output:
2
2


Should it give the size of the pointer itself, or the size of the object it
points to?

[Bug rtl-optimization/50205] [4.6/4.7 Regression] ICE: in code_motion_path_driver, at sel-sched.c:6581 with -fselective-scheduling2 and custom flags

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  2011-10-18 
12:36:20 UTC ---
Author: amonakov
Date: Tue Oct 18 12:36:16 2011
New Revision: 180135

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180135
Log:
PR rtl-optimization/50205
* sel-sched.c (count_occurrences_1): Simplify on the assumption that
p->x is a register.  Forbid substitution when the same register is
found in a different mode.
(count_occurrences_equiv): Assert that 'what' is a register.

* gcc.dg/pr50205.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr50205.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/50205] [4.6/4.7 Regression] ICE: in code_motion_path_driver, at sel-sched.c:6581 with -fselective-scheduling2 and custom flags

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

   Priority|P2  |P3
  Known to work||4.7.0
  Known to fail|4.7.0   |

--- Comment #3 from Alexander Monakov  2011-10-18 
12:45:14 UTC ---
Fixed on the trunk, needs backport to 4.6

[Bug fortran/47023] C_Sizeof: Rejects valid code

[burnus at gcc dot gnu.org]

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

--- Comment #22 from Tobias Burnus  2011-10-18 
12:48:31 UTC ---
(In reply to comment #21)
> The question is also how SIZEOF should act on data pointers:
> Output:
> 2
> 2
> Should it give the size of the pointer itself, or the size of the object it
> points to?

The target/pointee. Reasoning: For your example, g95, gfortran, ifort and
pathf95 all print "2". That's also what gfortran claims to do at 
http://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html

Regarding (comment 19, comment 20):
  print *,sizeof(proc)! (1) -- prints 1
  print *,sizeof(pp)  ! (2) -- prints 1
  print *,sizeof(pp(0.))  ! (3) -- prints 4

ifort rejects (1) and (2) and returns "4" for (3). I think gfortran should do
likewise. Returning the pointee size for scalar variables but the pointer size
of functions is also a bit odd.

 * * *

For Cray pointers/pointees:
  use iso_c_binding, only: c_sizeof
  implicit none
  integer(2) :: a
  pointer (aptr, a)
  print *,sizeof (a)   ! , c_sizeof (a)
  print *,sizeof (aptr)! , c_sizeof (aptr)
  end

This program fails to compile for c_sizeof while the sizeof version prints "2"
and "8", which I think is OK.

[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?

[uros at gcc dot gnu.org]

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

--- Comment #14 from uros at gcc dot gnu.org 2011-10-18 12:55:12 UTC ---
Author: uros
Date: Tue Oct 18 12:55:06 2011
New Revision: 180137

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180137
Log:
2011-10-18  Uros Bizjak  
Eric Botcazou  

PR target/50737
* config/alpha/linux-unwind.h (alpha_fallback_frame_state): Set
fs->signal_frame to 1.

libjava/ChangeLog:

2011-10-18  Uros Bizjak  
Eric Botcazou  

PR target/50737
* include/dwarf2-signal.h [__alpha__]: Remove MAKE_THROW_FRAME
definition.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/alpha/linux-unwind.h
branches/gcc-4_6-branch/libjava/ChangeLog
branches/gcc-4_6-branch/libjava/include/dwarf2-signal.h

[Bug libfortran/50016] [4.6/4.7 Regression] Drastic I/O performance regression on Windows

[burnus at gcc dot gnu.org]

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

--- Comment #14 from Tobias Burnus  2011-10-18 
12:58:46 UTC ---
Author: burnus
Date: Tue Oct 18 12:58:42 2011
New Revision: 180138

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180138
Log:
2011-10-18  Tobias Burnus  
Janne Blomqvist  

PR fortran/50016
* io/file_pos.c (st_flush): Call _commit on MinGW(-w64).
* io/intrinsics.c (flush_i4, flush_i8): Ditto.
* io/unix.c (flush_all_units_1, flush_all_units): Ditto.
(buf_flush): Remove _commit call.
* io/inquire.c (inquire_via_unit): Flush internal buffer
and call file_length instead of invoking stat via file_size.


Modified:
branches/gcc-4_6-branch/libgfortran/ChangeLog
branches/gcc-4_6-branch/libgfortran/io/file_pos.c
branches/gcc-4_6-branch/libgfortran/io/inquire.c
branches/gcc-4_6-branch/libgfortran/io/intrinsics.c
branches/gcc-4_6-branch/libgfortran/io/unix.c

[Bug bootstrap/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #12 from Mikael Pettersson  2011-10-18 
13:04:09 UTC ---
(In reply to comment #11)
> The bad commit listed in comment #4 was back ported to the 4.6 branch so the
> check in from comment #9 should be ported over to the 4.6 branch as well.  I 
> am
> reopening the bug for that reason.

The "bad" PR49911 commit was backported to 4.5 branch too, in r178701.  I
haven't checked yet if it caused any regressions there or not.

[Bug libfortran/50016] [4.7 Regression] Drastic I/O performance regression on Windows

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-18
   Target Milestone|4.6.2   |4.7.0
Summary|[4.6/4.7 Regression]|[4.7 Regression] Drastic
   |Drastic I/O performance |I/O performance regression
   |regression on Windows   |on Windows
 Ever Confirmed|0   |1

--- Comment #15 from Tobias Burnus  2011-10-18 
13:08:22 UTC ---
[4.6] FIXED (comment 14) or at least mitigated the issue on the 4.6 branch - in
time for the 4.6.2 release. See also
http://gcc.gnu.org/ml/fortran/2011-10/msg00132.html

 * * *

For the 4.7 trunk, we are still discussion, when to call _commit.
MinGW/MinGW-w64 users of GCC 4.7 could consider using that patch in the
meanwhile.

Start of the discussion:
  http://gcc.gnu.org/ml/fortran/2011-10/threads.html#00079

Patch version 1: Keep _commit only for FLUSH() subroutine/statement
  http://gcc.gnu.org/ml/fortran/2011-10/msg00132.html

Patch version 2: Remove _commit completely, use internal file-size when
inquiring open files. (The latter is an independent separate issue, but was the
reason for adding _commit at the first place; cf. PR 44698.)
  http://gcc.gnu.org/ml/fortran/2011-10/msg00094.html

 * * *

Xunxun: Thanks for the report and sorry for making the Windows version that
slow and for the two-months delay in fixing it.

[Bug libfortran/50016] [4.7 Regression] Drastic I/O performance regression on Windows

[xunxun1982 at gmail dot com]

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

--- Comment #16 from xunxun  2011-10-18 13:20:27 
UTC ---
Good job. I will extract the patch to 4.6.1 release.
( I don't use gcc4.6 latest branch temporarily because PR 50664 )
Thanks.

[Bug middle-end/50754] [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  2011-10-18 
13:28:48 UTC ---
This is due to revision 180047

Author:rth
Date:Sat Oct 15 19:36:50 2011 UTC (2 days, 17 hours ago)
Changed paths:5
Log Message:
Use VEC_PERM_EXPR in the vectorizer.

* tree-vect-slp.c: Include langhooks.h.
(vect_create_mask_and_perm): Emit VEC_PERM_EXPR, not a builtin.
(vect_transform_slp_perm_load): Use can_vec_perm_expr_p.  Simplify
mask creation for VEC_PERM_EXPR.
* tree-vect-stmts.c (perm_mask_for_reverse): Return the mask,
not the builtin.
(reverse_vec_elements): Emit VEC_PERM_EXPR not a builtin.
* Makefile.in (tree-vect-slp.o): Update dependency.
* optabs.c (can_vec_perm_expr_p): Allow NULL as unknown constant.

Note that the fix in revision 80100

Author:rth
Date:Mon Oct 17 17:02:05 2011 UTC (20 hours, 24 minutes ago)
Changed paths:2
Log Message:
PR 50746
* optabs.c (expand_vec_perm_expr): Fix indexing error.

does solve the problem.

[Bug fortran/47023] C_Sizeof: Rejects valid code

[janus at gcc dot gnu.org]

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

--- Comment #23 from janus at gcc dot gnu.org 2011-10-18 13:45:32 UTC ---
(In reply to comment #22)
> (In reply to comment #21)
> > The question is also how SIZEOF should act on data pointers:
> > Should it give the size of the pointer itself, or the size of the object it
> > points to?
> 
> The target/pointee. Reasoning: For your example, g95, gfortran, ifort and
> pathf95 all print "2". That's also what gfortran claims to do at 
> http://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html

Well, ok. "Wer lesen kann ist klar im Vorteil" ;)

Then this is obviously a feature and not a bug.



> Regarding (comment 19, comment 20):
>   print *,sizeof(proc)! (1) -- prints 1
>   print *,sizeof(pp)  ! (2) -- prints 1
>   print *,sizeof(pp(0.))  ! (3) -- prints 4
> 
> ifort rejects (1) and (2) and returns "4" for (3). I think gfortran should do
> likewise. Returning the pointee size for scalar variables but the pointer size
> of functions is also a bit odd.

Ok, I agree that it's better to reject it under these circumstances. How about
the following patch?


Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c(revision 180134)
+++ gcc/fortran/check.c(working copy)
@@ -3446,8 +3446,15 @@ gfc_check_size (gfc_expr *array, gfc_expr *dim, gf


 gfc_try
-gfc_check_sizeof (gfc_expr *arg ATTRIBUTE_UNUSED)
+gfc_check_sizeof (gfc_expr *arg)
 {
+  if (arg->ts.type == BT_PROCEDURE)
+{
+  gfc_error ("'%s' argument of '%s' intrinsic at %L may not be a
procedure",
+ gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
+ &arg->where);
+  return FAILURE;
+}
   return SUCCESS;
 }

[Bug fortran/50552] type name cannot be statement function dummy argument (r178939)

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  2011-10-18 
13:55:31 UTC ---
I am traveling in Korea, and I cannot look at the standard now.
If you believe this is a non-issue then please close it.

[Bug c++/50776] New: unused object optimized out, despite having constructor

[nyh at math dot technion.ac.il]

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

 Bug #: 50776
   Summary: unused object optimized out, despite having
constructor
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@math.technion.ac.il


Consider the following simple program:

#include 
class Ident {
public:
Ident(const char *ident){
// This constructor prints a message!
printf("yo\n");
}
};

static Ident id("$Id: hello $");

main(){
printf("hello\n");
}

When you compile it with g++ without additional parameters, its output rightly
looks like:

yo
hello

I.e., the object "id" gets instantiated, and its constructor prints the message
"yo".
However, if you compile it with optimization enabled - g++ -O2 - the output is
DIFFERENT: the "id" object is optimized out (because it is static, but nobody
uses it in this source file), and therefore its constructor no longer runs.

I think it is a bug for optimization to change the behavior (not just the
performance) of a program. I think that if an object has a non-trivial
constructor with any side effects beside setting class fields, then we cannot
optimize its construction out because this would change the program behavior.

[Bug tree-optimization/50769] [4.7 Regression] ICE: in phi_alternatives_equal, at tree-cfgcleanup.c:355 with -O2 -fno-delete-null-pointer-checks -fno-guess-branch-probability -fipa-pta

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||vries at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |vries at gcc dot gnu.org
   |gnu.org |

[Bug c++/50776] unused object optimized out, despite having constructor

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-10-18 
14:18:49 UTC ---
I can't reproduce this with any version.

What platform are you using? (You failed to provide that, as requested by the
http://gcc.gnu.org/bugs/ page)

[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os

[sebastian.hu...@embedded-brains.de]

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

--- Comment #6 from Sebastian Huber  
2011-10-18 14:19:55 UTC ---
Created attachment 25543
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25543
arm-eabi-g++ -march=armv5t -mthumb -Os -S compiler1.test.ii -o
compiler1.test.eabi.GCC-4.5.4.Os.s

[Bug target/50719] segmentation fault when attempting to build libav with gcc trunk

[gseanmcg at gmail dot com]

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

--- Comment #3 from Sean McGovern  2011-10-18 
14:25:20 UTC ---
Have not been successful building trunk on i386-pc-solaris2.10 yet. Will answer
these questions when I have a working build again.

[Bug c++/45690] broken debuginfo with dwarf4?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  2011-10-18 
14:28:51 UTC ---
The problem is that the DWARF4 standard says that .debug_pubtypes resp.
.debug_pubnames refer to .debug_info section offsets and this hasn't been
updated for the (optional) .debug_types section addition.  If a type (resp.
name) DIE is instead in .debug_types section, it is unclear what should be
done.
Either such a type shouldn't be added into .debug_pubtypes at all, or we'd need
to refer to something.  I don't see anything to refer to in .debug_info section
though, usually it just contains DW_AT_type with DW_FORM_sig8 containing the
.debug_types hash with the type.  And it isn't possible to refer to
.debug_types section offsets, because the consumers would need a way to
differentiate between what is a .debug_info offset in the header (relative to
start of .debug_info) and what is a .debug_types offset (relative to start of
.debug_types).
I think currently what you see is gcc emitting offsets within containing
.debug_types section in .debug_pubtypes chunks corresponding to .debug_info.

[Bug tree-optimization/50769] [4.7 Regression] ICE: in phi_alternatives_equal, at tree-cfgcleanup.c:355 with -O2 -fno-delete-null-pointer-checks -fno-guess-branch-probability -fipa-pta

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org 2011-10-18 14:32:11 UTC ---
Created attachment 25544
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25544
tentative patch

This PR is similar to PR50672.

We discover that blocks 6 and 7 are equal and remove block 7, and redirect the
outgoing edge of it's predecessor block 11 to block 6. Block 6 contains a phi,
which after redirection looks like this:
...
.MEM_54 = PHI <.MEM_27(18), .MEM_26(17), (11)>
...

Since update_vops is false, we know TODO_update_ssa_only_virtuals will be run
and we don't update the phi. But we need to make the phi argument valid, just
like in PR50672.

The patch sets the empty phi argument to .MEM.

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #3 from Mikael Morin  2011-10-18 
14:42:24 UTC ---
Author: mikael
Date: Tue Oct 18 14:42:21 2011
New Revision: 180142

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180142
Log:
PR fortran/50420
* trans-array.c (gfc_conv_expr_descriptor): Count codimensions starting
from zero, and add then the relevant offset (either ndim or loop.dimen)
depending on context.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin  2011-10-18 
14:45:49 UTC ---
Author: mikael
Date: Tue Oct 18 14:45:46 2011
New Revision: 180143

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180143
Log:
PR fortran/50420
* trans-array.c (gfc_conv_expr_descriptor): Use loop.dimen instead of
ndim for the descriptor's rank.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c

[Bug c/50773] float values are printed with greater precision than the float data type has when given as an argument to printf()

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2011-10-18 14:49:28 UTC ---
On Tue, 18 Oct 2011, rguenth at gcc dot gnu.org wrote:

> Needs -fexcess-precision=standard -m32 to trigger.  libcpp does the
> parsing of FP constants IIRC, and the C++ frontend does not implement
> -fexcess-precision.
> 
> CCing Joseph.
> 
> Testcase that fails with -fexcess-precision=standard -m32:
> 
> extern void abort (void);
> int
> main()
> {
>   float a = 268517138.f;
>   if (a != 268517138.f)
> abort ();
>   return 0;
> }

I don't see any bug there.  With -fexcess-precision=standard, 
FLT_EVAL_METHOD is 2, "evaluate all operations and constants to the range 
and precision of the long double type".  Thus 268517138.f has type float 
but a value represented to the precision of long double - and the 
conversion to the precision of float takes place for the initialization 
but not for the comparison.  (Without -fexcess-precision=standard - 
outside any conformance mode - FLT_EVAL_METHOD is still 2, but exactly 
what happens is unpredictable.)

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin  2011-10-18 
14:55:54 UTC ---
Author: mikael
Date: Tue Oct 18 14:55:48 2011
New Revision: 180145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180145
Log:
PR fortran/50420
* trans-array.c (gfc_walk_array_ref): Allow zero rank arrays
if they are coarrays.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c

[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |ramana at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Ramana Radhakrishnan  2011-10-18 
14:58:13 UTC ---
I finished testing this with some other patches and backports that I had.
Should commit in the next day or two. 

Ramana

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin  2011-10-18 
14:59:11 UTC ---
Author: mikael
Date: Tue Oct 18 14:59:07 2011
New Revision: 180146

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180146
Log:
PR fortran/50420
* trans-intrinsic.c (walk_coarray): Allow subreferences after a
coarray object reference.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #7 from Mikael Morin  2011-10-18 
15:02:46 UTC ---
Author: mikael
Date: Tue Oct 18 15:02:38 2011
New Revision: 180147

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180147
Log:
PR fortran/50420
* trans-intrinsic.c (walk_coarray): Change AR_ELEMENT to AR_SECTION.

PR fortran/50420
* trans-intrinsic.c (walk_coarray): Use gfc_walk_array_ref for
the scalarization chain initialization. 


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin  2011-10-18 
15:05:34 UTC ---
Author: mikael
Date: Tue Oct 18 15:05:30 2011
New Revision: 180148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180148
Log:
PR fortran/50420
* check.c (dim_corank_check): Use gfc_get_corank to get corank.


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

[Bug other/50759] [4.7 Regression] @table ended by @end quotation at line 595

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #1 from Joseph S. Myers  2011-10-18 
15:07:33 UTC ---
This appears to be coming from the -fdebug-cpp documentation in cppopts.texi. 
It looks like support for @quotation/@end quotation pairs needs adding to
texi2pod.pl.

[Bug c++/44236] Output initializers in .text.init section

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Jan Hubicka  2011-10-18 
15:10:40 UTC ---
This is solved on GCC side. Still gold needs updating to sort the sections
accordingly.

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #9 from Mikael Morin  2011-10-18 
15:11:27 UTC ---
Author: mikael
Date: Tue Oct 18 15:11:21 2011
New Revision: 180150

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180150
Log:
PR fortran/50420
* simplify.c (simplify_cobound): Accept non-last-in-ref-chain coarrays.
Don't set already set array ref.


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

[Bug c/21659] [4.4/4.5 Regression] [unit-at-a-time] "weak declaration must precede definition" error missing at >= O1

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #14 from Jan Hubicka  2011-10-18 
15:13:11 UTC ---
This restriction is long gone with unit-at-a-time changes.

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #10 from Mikael Morin  2011-10-18 
15:13:58 UTC ---
Author: mikael
Date: Tue Oct 18 15:13:45 2011
New Revision: 180151

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180151
Log:
PR fortran/50420
* trans-types.c (gfc_build_array_type): Don't force lower bound to one
in the deferred case.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c

[Bug bootstrap/50777] New: [4.7 regression] bootstrap fails on Solaris 10

[gseanmcg at gmail dot com]

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

 Bug #: 50777
   Summary: [4.7 regression] bootstrap fails on Solaris 10
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gsean...@gmail.com


Bootstrap is failing on i386-pc-solaris2.10 after revision 180093 with
madvise() being undeclared.

According to Oracle this function requires sys/types.h and sys/mman.h on
Solaris -- are they included elsewhere?

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #11 from Mikael Morin  2011-10-18 
15:17:34 UTC ---
Author: mikael
Date: Tue Oct 18 15:17:29 2011
New Revision: 180152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180152
Log:
PR fortran/50420
* trans.c (gfc_build_array_ref): If type is not an array, check that
there is nothing to do, and do nothing.


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

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[ebotcazou at gcc dot gnu.org]

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

--- Comment #44 from Eric Botcazou  2011-10-18 
15:22:14 UTC ---
> Created attachment 25540 [details]
> demonstration of the fault using c++/vendor's tools
> 
> after Eric solved my inverted-logic thinko ... 
> .. I reproduced using g++-4.2
> bug filed as radar #10302855.

Thanks!

> I think we'll need to apply the patch in the short/medium term and then figure
> out how to control it - which will depend on which system(s) a fix is released
> for.

One approach could be to scan the unwind info of _sigtramp live and check for
the problematic pattern.  You call __builtin_return_address from the handler to
get the PC of _sigtramp, then _Unwind_Find_FDE on this PC and you scan starting
from the address you get (the length of the FDE of _sigtramp is 0xc0
currently).

The problematic pattern are the lines:

0x7fff85ccff61: 0x100x010x050x730x300x060x230x18

and

0x7fff85ccff71: 0x100x030x050x730x300x060x230x28

The register number is the second field (1 or 3) and the offset in the context
is the 8th and last field (0x18 or 0x28).  The problem is here if they are in
the same relative order (the likely fix will be to swap 0x18 and 0x28 in the
unwind info).

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

--- Comment #12 from Mikael Morin  2011-10-18 
15:23:10 UTC ---
Author: mikael
Date: Tue Oct 18 15:23:04 2011
New Revision: 180153

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180153
Log:
PR fortran/50420
* gfortran.dg/coarray_subobject_1.f90: New test.
* gfortran.dg/coarray/subobject_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray/subobject_1.f90
trunk/gcc/testsuite/gfortran.dg/coarray_subobject_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/50777] [4.7 regression] bootstrap fails on Solaris 10

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-10-18 
15:26:08 UTC ---
My guess would not be a missing header, but missing feature test macro

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #45 from Iain Sandoe  2011-10-18 15:32:33 
UTC ---
(In reply to comment #44)
> > I think we'll need to apply the patch in the short/medium term and then 
> > figure
> > out how to control it - which will depend on which system(s) a fix is 
> > released
> > for.
> 
> One approach could be to scan the unwind info of _sigtramp live and check for
> the problematic pattern.  You call __builtin_return_address from the handler 
> to
> get the PC of _sigtramp, then _Unwind_Find_FDE on this PC and you scan 
> starting
> from the address you get (the length of the FDE of _sigtramp is 0xc0
> currently).
> 
> The problematic pattern are the lines:
> 
> 0x7fff85ccff61: 0x100x010x050x730x300x060x230x18
> 
> and
> 
> 0x7fff85ccff71: 0x100x030x050x730x300x060x230x28
> 
> The register number is the second field (1 or 3) and the offset in the context
> is the 8th and last field (0x18 or 0x28).  The problem is here if they are in
> the same relative order (the likely fix will be to swap 0x18 and 0x28 in the
> unwind info).

that seems reasonable if the result can be cached - otherwise it's potentially
a big hit.
... or it could be done from a crt (I have in mind a new crt to try and solve
some other unwind issues).

[Bug tree-optimization/50735] [4.7 Regression] gcc.dg/torture/vector-2.c:52:1: ICE: verify_ssa failed at -O1 and above

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-10-18 
15:33:16 UTC ---
Author: jakub
Date: Tue Oct 18 15:33:12 2011
New Revision: 180154

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180154
Log:
PR tree-optimization/50735
* function.c (gimplify_parameters): Use create_tmp_var instead of
create_tmp_reg.  If parm is not TREE_ADDRESSABLE and type is complex
or vector type, set DECL_GIMPLE_REG_P.

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

[Bug fortran/50420] [Coarray] lcobound doesn't accept coarray subcomponents

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #13 from Mikael Morin  2011-10-18 
15:37:20 UTC ---
Should be fixed now.
Thank you for the rep... Hem, I was the reporter.

[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-10-18 15:37:49 UTC ---
> --- Comment #16 from Bernd Schmidt  2011-10-17 
> 17:37:11 UTC ---
> Sorry, I was being imprecise - only the instances where we generate notes 374
> and 375 are interesting. Can you identify these two?

Sorry for being dense :-)  I could using conditional breakpoints once I
had unraveled how to identify the note number from an rtx.  Here's what
I found:

note 374:

(note 229 161 230 NOTE_INSN_EPILOGUE_BEG)
(code_label 243 324 162 31 "" [1 uses])
.cfi_def_cfa 29, 80
.cfi_offset 16, -72
.cfi_offset 17, -64
.cfi_offset 18, -56
.cfi_offset 19, -48
.cfi_offset 20, -40
.cfi_offset 21, -32
.cfi_offset 22, -24
.cfi_offset 28, -16
.cfi_offset 64, -8

note 375:

(note 229 161 230 NOTE_INSN_EPILOGUE_BEG)
(code_label 243 324 375 31 "" [1 uses])
.cfi_def_cfa 29, 80
.cfi_offset 16, -72
.cfi_offset 17, -64
.cfi_offset 18, -56
.cfi_offset 19, -48
.cfi_offset 20, -40
.cfi_offset 21, -32
.cfi_offset 22, -24
.cfi_offset 28, -16
.cfi_offset 64, -8

Rainer

[Bug middle-end/48087] [4.5/4.6/4.7 Regression] -Wall -Werror adds warnings over and above those generated by -Wall

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #7 from Manuel López-Ibáñez  2011-10-18 
15:42:42 UTC ---
> Is there a simple explanation for why the problem didn't show up in 4.4.x?

The question is why control does not reach the warning() when -Werror is not
given. Are the warnings appropriate or bogus?

If the warnings are bogus (because they refer to the same function), then I
guess that the code path for warnings_as_error does not set TREE_NO_WARNING()
at some point.

[Bug c++/50776] unused object optimized out, despite having constructor

[nyh at math dot technion.ac.il]

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

Nadav Har'El  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #2 from Nadav Har'El  2011-10-18 
15:46:37 UTC ---
I'm really sorry, I don't know what happened - now I don't see this bug myself!
I must have done something wrong earlier (!?). Closing, and If I ever can
replicate this again, I'll reopen. Sorry :(

[Bug middle-end/48087] [4.5/4.6/4.7 Regression] -Wall -Werror adds warnings over and above those generated by -Wall

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2011-10-18 
16:08:02 UTC ---
Note however that the bug I closed as duplicate of this one shows that in some
cases the problem manifests itself as *bogus* warning.. But I'm pretty sure the
issue ultimately  is one and only.

[Bug middle-end/48087] [4.5/4.6/4.7 Regression] -Wall -Werror adds warnings over and above those generated by -Wall

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2011-10-18 
16:02:26 UTC ---
Thanks Manuel: if I understand correctly, this way we could not only avoid the
regression but even do better than 4.4, and again, the fix could be very simple
(is only hiding itself very well ;) I'll see what I can do.

[Bug bootstrap/50777] [4.7 regression] bootstrap fails on Solaris 10

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-18
 CC||bonzini at gnu dot org, ian
   ||at airs dot com
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Rainer Orth  2011-10-18 16:09:06 UTC 
---
They are, via system.h.  The problem is twofold:

* madvise(3) is declared in  conditionally: in the Solaris 10
  version of the header, we have:

#ifdef__STDC__
#if (_POSIX_C_SOURCE > 2) || defined(_XPG4_2)
...
#else/* (_POSIX_C_SOURCE > 2) || defined(_XPG4_2) */
...
extern int madvise(caddr_t, size_t, int)...
...
#endif/* (_POSIX_C_SOURCE > 2)  || defined(_XPG4_2) */

* configure uses the C compiler to detect support for madvise() and finds it,
  while the actual compilation happens with g++, which defines
_XOPEN_SOURCE=600,
  among others, which hides the declaration.

In Solaris 11, there's no issue AFAICS since with __EXTENSIONS__ defined (which
configure takes care of), the madivse() prototype is visible.  I'm currently
running a bootstrap to verify this.

There are two options:

* Actually perform the configure tests with the compiler to be used (g++)
instead
  of gcc.  Everything else is bound to yield bogus results once in a while, or
  at least do so for madvise.

* Hack around this with fixincludes, but in this case I'd consider this a bug
  by itself.

Paolo, Ian, suggestions?

  Rainer

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[ebotcazou at gcc dot gnu.org]

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

--- Comment #46 from Eric Botcazou  2011-10-18 
16:03:20 UTC ---
> that seems reasonable if the result can be cached - otherwise it's potentially
> a big hit.

We don't really care about performances here: a signal has been raised and
we're about to throw a DWARF exception, so everything is already quite costly. 
But saving the result in a static variable should indeed be possible.

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #47 from Iain Sandoe  2011-10-18 16:22:10 
UTC ---
(In reply to comment #46)
> > that seems reasonable if the result can be cached - otherwise it's 
> > potentially
> > a big hit.
> 
> We don't really care about performances here: a signal has been raised and
> we're about to throw a DWARF exception, so everything is already quite 
> costly. 
> But saving the result in a static variable should indeed be possible.

OK, that's fair... mine for now (will try and cook sth up).

[Bug fortran/47485] gfortran -M output is incorrect when -MT option is used

[nightstrike at gmail dot com]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot
   ||com

--- Comment #3 from nightstrike  2011-10-18 
16:29:43 UTC ---
I have just now seen this problem for c and not fortran for GCC 4.1.2.  It
appears fixed in 4.6.0.  I searched the bug database, and found this:

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

It looks like the two bugs are related, although I can confirm that the bug
still exists for gfortran 4.6.0 using the test case provided in this PR:

$ cat > f.f90
program test
print "(a)", "hello world"
end program

$ gfortran -cpp -M f.f90 -MT aaa
f.o aaa: f.f90


So at the very least, can someone set the bug status to NEW (confirmed) and the
See Also to PR12448?

Also, when fixing this, whoever does so, be sure to not run into this snag:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44076

That should be on the See Also, as well.