[Bug tree-optimization/54831] New: [4.8 Regression] ICE: in vt_add_function_parameter, at var-tracking.c:9412 with -O -fno-split-wide-types -g

[zsojka at seznam dot cz]

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



 Bug #: 54831

   Summary: [4.8 Regression] ICE: in vt_add_function_parameter, at

var-tracking.c:9412 with -O -fno-split-wide-types -g

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: zso...@seznam.cz





Created attachment 28368

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28368

reduced testcase



Compiler output:

$ gcc -O -fno-split-wide-types -g testcase.C 

testcase.C: In function 'void foo(mptr)':

testcase.C:16:1: internal compiler error: in vt_add_function_parameter, at

var-tracking.c:9412

 }

 ^

0xd7814a vt_add_function_parameter

/mnt/svn/gcc-trunk/gcc/var-tracking.c:9412

0xd7825f vt_add_function_parameters

/mnt/svn/gcc-trunk/gcc/var-tracking.c:9516

0xd78db7 vt_initialize

/mnt/svn/gcc-trunk/gcc/var-tracking.c:9772

0xd827d6 variable_tracking_main_1

/mnt/svn/gcc-trunk/gcc/var-tracking.c:10016

0xd827d6 variable_tracking_main()

/mnt/svn/gcc-trunk/gcc/var-tracking.c:10069

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Tested revisions:

r192080 - crash

r191586 - crash

4.7 r191640 - OK

[Bug lto/54790] [4.8 Regression] Missing optimization with LTO

[d.g.gorbachev at gmail dot com]

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



--- Comment #4 from Dmitry Gorbachev  
2012-10-06 07:57:12 UTC ---

Created attachment 28369

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28369

Testcase #2



Another (perhaps related) issue.

[Bug c++/51199] [C++11][DR 547] gcc forms impossible types derived from function types with cv-qualifier-seq

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  
2012-10-06 07:58:56 UTC ---
(In reply to comment #1)
CWG 1417 is now in ready state, which is a good opportunity to implement the
clarification. Meanwhile some traits (like is_copy/move_constructible) should
be prepared for the expected compiler behaviour change, because otherwise the
instantiation of e.g.

std::is_copy_constructible

would lead to an instantiation error during the attempt to form the invalid
type const void(&) const. I would suggest to define an internal
__is_referencable trait for this instead of the currently used is_void
discriminator. I have implemented __is_referencable and successfully tested it
within __is_copy_constructible_impl.

[Bug lto/54790] [4.8 Regression] Missing optimization with LTO

[d.g.gorbachev at gmail dot com]

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



--- Comment #5 from Dmitry Gorbachev  
2012-10-06 08:02:20 UTC ---

Created attachment 28370

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28370

Testcase #3



Undefined reference bug.



With gold:

main.o:main.c:function main: error: undefined reference to 'foo'



With bfd ld:

`foo' referenced in section `.text' of main.o: defined in discarded section

`.text' of /tmp/ccl6J4kW.o (symbol from plugin)

[Bug c++/54828] [4.7 Regression] ICE in based_loc_descr at dwarf2out.c:10560 with -g -O0

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-10-06 08:05:43 UTC ---
Also occurs on gcc 4.8.0 20120930 (experimental), pointing here to

"main.cpp|12|internal compiler error: in based_loc_descr, at dwarf2out.c:10193"

[Bug c++/54812] [C++11] Delete expression doesn't respect access of defaulted destructor

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  
2012-10-06 08:11:48 UTC ---
(In reply to comment #5)
I double-checked whether this might be related to

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1507

from a different perspective, but I'm pretty sure it isn't. 12.4 p11 seems very
clear that the destructor would be called implicitly here and that access
checking happens.

[Bug c++/51199] [C++11][DR 547] gcc forms impossible types derived from function types with cv-qualifier-seq

[paolo.carlini at oracle dot com]

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



--- Comment #3 from Paolo Carlini  2012-10-06 
08:18:36 UTC ---

Excellent, thanks Daniel.

[Bug c++/51199] [C++11][DR 547] gcc forms impossible types derived from function types with cv-qualifier-seq

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-06

 Ever Confirmed|0   |1



--- Comment #4 from Paolo Carlini  2012-10-06 
08:19:54 UTC ---

Unsuspending.

[Bug fortran/54832] New: [4.8 Regression] [OOP] Type-bound operator not picked up with RESULT variable

[janus at gcc dot gnu.org]

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



 Bug #: 54832

   Summary: [4.8 Regression] [OOP] Type-bound operator not picked

up with RESULT variable

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ja...@gcc.gnu.org





Reported by Damian Rouson at:



http://gcc.gnu.org/ml/fortran/2012-10/msg00032.html





Test case:



module integrand_module



  type ,abstract :: integrand

  contains

procedure(t_interface), deferred :: t

procedure(assign_interface), deferred :: assign

procedure(times_interface), deferred :: times

generic :: operator(*) => times

generic :: assignment(=) => assign

  end type



  abstract interface

function t_interface(this) result(dState_dt)

  import :: integrand

  class(integrand) ,intent(in)  :: this

  class(integrand) ,allocatable :: dState_dt

end function

function times_interface(lhs,rhs)

  import :: integrand

  class(integrand) ,intent(in)  :: lhs

  class(integrand) ,allocatable :: times_interface

  real, intent(in)  :: rhs

end function

subroutine assign_interface(lhs,rhs)

  import :: integrand

  class(integrand) ,intent(in):: rhs

  class(integrand) ,intent(inout) :: lhs

end subroutine

  end interface



contains

  subroutine integrate(model,dt)

class(integrand) :: model

real dt

model = model%t()*dt

  end subroutine

end module 





While 4.7 compiles it cleanly, 4.8 gives:



model = model%t()*dt

1

Error: Operands of binary numeric operator '*' at (1) are

CLASS(integrand)/REAL(4)

[Bug fortran/54833] New: Don't wrap __builtin_free(a) in if (a != NULL)

[tkoenig at gcc dot gnu.org]

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



 Bug #: 54833

   Summary: Don't wrap __builtin_free(a) in if (a != NULL)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: fortran

AssignedTo: tkoe...@gcc.gnu.org

ReportedBy: tkoe...@gcc.gnu.org





The Fortran front end at the moment generates many calls

to __builtin_free with



  if (a.data != 0B)

{

  __builtin_free ((void *) a.data);

}

  a.data = 0B;



This is not necessary, because free(NULL) is well-defined no-op.

[Bug bootstrap/54834] New: bootstrap fails when building libbacktrace

[tobi at gcc dot gnu.org]

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



 Bug #: 54834

   Summary: bootstrap fails when building libbacktrace

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: t...@gcc.gnu.org

Target: x86_64-apple-darwin11.4.0





Created attachment 28371

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28371

configure log



The failure mode is copied below.  I attach my libbacktrace/config.log.



make  all-am

/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.

-I../../libbacktrace  -I ../../libbacktrace/../include -I

../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I

../../gcc/include  -funwind-tables -W -Wall -Wwrite-strings -Wstrict-prototypes

-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute

-Wcast-qual -Werror  -g -c -o backtrace.lo ../../libbacktrace/backtrace.c

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I

../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I

../gcc/include -I ../../gcc/include -funwind-tables -W -Wall -Wwrite-strings

-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition

-Wmissing-format-attribute -Wcast-qual -Werror -g -c

../../libbacktrace/backtrace.c -o backtrace.o

In file included from ../../libbacktrace/backtrace.c:35:

../gcc/include/unwind.h:48: error: unknown machine mode 'unwind_word'

../gcc/include/unwind.h:49: error: unknown machine mode 'unwind_word'

In file included from ../../libbacktrace/backtrace.c:35:

../gcc/include/unwind.h:252:4: error: #error "__SIZEOF_LONG__ macro not

defined"

../gcc/include/unwind.h:256:4: error: #error "__SIZEOF_POINTER__ macro not

defined"

make[4]: *** [backtrace.lo] Error 1

make[3]: *** [all] Error 2

make[2]: *** [all-stage1-libbacktrace] Error 2

make[1]: *** [stage1-bubble] Error 2

make: *** [all] Error 2

[Bug middle-end/37150] vectorizer misses some loops

[Joost.VandeVondele at mat dot ethz.ch]

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



Joost VandeVondele  changed:



   What|Removed |Added



   Last reconfirmed|2009-08-06 07:54:57 |2012-10-06 7:54:57



--- Comment #13 from Joost VandeVondele  
2012-10-06 10:38:57 UTC ---

reconfirming this with current trunk 



ifort:1.02s

gfortran 4.8: 2.01s



gfortran -ffast-math -march=native -O3 -v PR37150.f90



-march=corei7 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm

-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx

-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c

-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx

[Bug fortran/54832] [4.8 Regression] [OOP] Type-bound operator not picked up with RESULT variable

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-06

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2012-10-06 
10:42:05 UTC ---

The ICE appeared between revisions 190356, 2012-08-13 (OK) and 190442,

2012-08-16 (ICE), and was replaced by an error between revisions 191969,

2012-10-02 (ICE) and 192074, 2012-10-04 (error).

[Bug fortran/54832] [4.8 Regression] [OOP] Type-bound operator not picked up with RESULT variable

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |UNCONFIRMED

 Ever Confirmed|1   |0



--- Comment #2 from janus at gcc dot gnu.org 2012-10-06 11:10:11 UTC ---

(In reply to comment #1)

> The ICE appeared between revisions 190356, 2012-08-13 (OK) and 190442,

> 2012-08-16 (ICE)



Here I'm not completely sure about which one is the culprit ...





> and was replaced by an error between revisions 191969,

> 2012-10-02 (ICE) and 192074, 2012-10-04 (error).



... but this is probably due to:



http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192005

[Bug fortran/54832] [4.8 Regression] [OOP] Type-bound operator not picked up with RESULT variable

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #3 from janus at gcc dot gnu.org 2012-10-06 11:17:46 UTC ---

The problem was apparently that the 'class_ok' attribute was not propagated

properly. The following patch fixes it for me:



Index: gcc/fortran/resolve.c

===

--- gcc/fortran/resolve.c(revision 192004)

+++ gcc/fortran/resolve.c(working copy)

@@ -12009,6 +12009,7 @@ resolve_fl_derived0 (gfc_symbol *sym)

   c->attr.pointer = ifc->result->attr.pointer;

   c->attr.dimension = ifc->result->attr.dimension;

   c->as = gfc_copy_array_spec (ifc->result->as);

+  c->attr.class_ok = ifc->result->attr.class_ok;

 }

   else

 {   

@@ -12017,6 +12018,7 @@ resolve_fl_derived0 (gfc_symbol *sym)

   c->attr.pointer = ifc->attr.pointer;

   c->attr.dimension = ifc->attr.dimension;

   c->as = gfc_copy_array_spec (ifc->as);

+  c->attr.class_ok = ifc->attr.class_ok;

 }

   c->ts.interface = ifc;

   c->attr.function = ifc->attr.function;

@@ -12028,7 +12030,6 @@ resolve_fl_derived0 (gfc_symbol *sym)

   c->attr.recursive = ifc->attr.recursive;

   c->attr.always_explicit = ifc->attr.always_explicit;

   c->attr.ext_attr |= ifc->attr.ext_attr;

-  c->attr.class_ok = ifc->attr.class_ok;

   /* Replace symbols in array spec.  */

   if (c->as)

 {

[Bug c++/54835] New: [C++11] Explicit default constructors not respected during copy-list-initialization

[daniel.kruegler at googlemail dot com]

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



 Bug #: 54835

   Summary: [C++11] Explicit default constructors not respected

during copy-list-initialization

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: daniel.krueg...@googlemail.com





gcc 4.8.0 20120930 (experimental) with the compiler flags



-Wall -pedantic -std=c++11 



accepts the following copy-list-initialization of a class type with an explicit

default constructor:



//-

struct S {

  explicit S(int = 0) {}

};



S s = {};

//-



This code should be ill-formed, because it is ruled out by [over.match.list],

in particular by the unconditional wording:



"In copy-list-initialization, if an explicit constructor is chosen, the

initialization is ill-formed."

[Bug target/54760] [SH] Add __builtin_thread_pointer, __builtin_set_thread_pointer

[olegendo at gcc dot gnu.org]

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



--- Comment #1 from Oleg Endo  2012-10-06 11:20:18 
UTC ---

Author: olegendo

Date: Sat Oct  6 11:20:11 2012

New Revision: 192155



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192155

Log:

PR target/54760

* config/sh/sh.md (define_constants): Add UNSPECV_GBR.

(get_thread_pointer, set_thread_pointer): New expanders.

(load_gbr): Rename to store_gbr.  Remove GBR_REG use.

(store_gbr): New insn.

* config/sh/sh.c (prepare_move_operands): Use gen_store_gbr instead of

gen_load_gbr in TLS_MODEL_LOCAL_EXEC case.

(sh1_builtin_p): New function.

(signature_args): Add SH_BLTIN_VP.

(bdesc): Add __builtin_thread_pointer and __builtin_set_thread_pointer.



PR target/54760

* gcc.target/sh/pr54760-1.c: New.





Added:

trunk/gcc/testsuite/gcc.target/sh/pr54760-1.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/sh/sh.c

trunk/gcc/config/sh/sh.md

trunk/gcc/testsuite/ChangeLog

[Bug fortran/51727] Changing module files

[tobi at gcc dot gnu.org]

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

--- Comment #3 from Tobias Schlüter  2012-10-06 
11:41:23 UTC ---
Created attachment 28372
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28372
Candidate patch

Here's a patch which fixes one case of module contents not being written in a
defined order.  I cannot test this right now because of bootstrap failures. 
There may be other places in the module writing code, where structures aren't
traversed in a defined order.

2012-10-06  Tobias Schlüter  

PR fortran/51727
* module.c (write_generic): Traverse tree in left-to-right order.

[Bug rtl-optimization/54739] [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"

[schwab at gcc dot gnu.org]

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



--- Comment #9 from Andreas Schwab  2012-10-06 
11:42:18 UTC ---

Author: schwab

Date: Sat Oct  6 11:42:13 2012

New Revision: 192156



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192156

Log:

PR rtl-optimization/54739

* config/m68k/m68k.md (anddi3, iordi3, xordi3, one_cmpldi2):

Remove.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/m68k/m68k.md

[Bug rtl-optimization/54739] [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"

[sch...@linux-m68k.org]

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



Andreas Schwab  changed:



   What|Removed |Added



 CC||eager at eagercon dot com,

   ||nickc at redhat dot com



--- Comment #10 from Andreas Schwab  2012-10-06 11:51:44 
UTC ---

mcore and microblaze are the only targets not yet covered.

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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



--- Comment #14 from janus at gcc dot gnu.org 2012-10-06 12:20:17 UTC ---

Author: janus

Date: Sat Oct  6 12:20:09 2012

New Revision: 192157



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192157

Log:

2012-10-06  Janus Weil  



PR fortran/45521

* interface.c (generic_correspondence): Implement additional

distinguishability criteria of F08.

(compare_actual_formal): Reject data object as actual argument for

procedure formal argument.



2012-10-06  Janus Weil  



PR fortran/45521

* gfortran.dg/generic_25.f90: New.

* gfortran.dg/generic_26.f90: New.

* gfortran.dg/generic_27.f90: New.



Added:

trunk/gcc/testsuite/gfortran.dg/generic_25.f90

trunk/gcc/testsuite/gfortran.dg/generic_26.f90

trunk/gcc/testsuite/gfortran.dg/generic_27.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/interface.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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



--- Comment #15 from janus at gcc dot gnu.org 2012-10-06 12:35:26 UTC ---

(In reply to comment #0)

> Fortran 2008's "12.4.3.4.5 Restrictions on generic declarations" has"

> 

> "Two dummy arguments are distinguishable if

> - one is a procedure and the other is a data object,

> - they are both data objects or known to be functions, and neither is TKR

> compatible with the other,

> - one has the ALLOCATABLE attribute and the other has the POINTER attribute, 
> or

> - one is a function with nonzero rank and the other is not known to be a

> function."



r192157 implements item 3 and contains a bugfix for item 1, so that items 1-3

should be handled correctly.



About item 4 I'm not completely sure, but possibly we still miss that.







> Interpretation request F08/0001 / 10-145 changes this ("EDITS to 10-007")"

> 

> '[286:4] In 12.4.3.4.5p3, after "the other has the POINTER attribute",

> Insert "and not the INTENT(IN) attribute".'

> Cf. http://j3-fortran.org/doc/meeting/193/10-199.txt



Unfortunately this was forgotten in the above commit. To do!

[Bug fortran/51727] Changing module files

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #4 from Joost VandeVondele  
2012-10-06 12:42:13 UTC ---
(In reply to comment #3)

> 
> 2012-10-06  Tobias Schlüter  
> 
> PR fortran/51727
> * module.c (write_generic): Traverse tree in left-to-right order.

If tested that this patch fixes the problem for omp_lib.mod, so would likely
also fix recompilation cascades..

However, testing it on CP2K I'm finding that compilation fails with this patch
(and passes without), so something seems wrong. The difference between the
generated modules is rather large.

[Bug fortran/51727] Changing module files

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #5 from Joost VandeVondele  
2012-10-06 12:46:36 UTC ---

Created attachment 28373

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28373

bad module

[Bug fortran/51727] Changing module files

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #6 from Joost VandeVondele  
2012-10-06 12:47:19 UTC ---

Created attachment 28374

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28374

good module

[Bug fortran/51727] Changing module files

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #7 from Joost VandeVondele  
2012-10-06 12:48:39 UTC ---

The main difference between 'good' and 'bad' seems to be the 'header' lines 



bad:

()



(('arch_topology' 'machine_architecture_types' 2))



()



good:

()



(('arch_topology' 'machine_architecture_types' 2) ('ma_mp_type'

'machine_architecture_types' 3) ('ma_process' 'machine_architecture_types'

4) ('machine_output' 'machine_architecture_types' 5) ('thread_inf'

'machine_architecture_types' 6))



()

[Bug fortran/51727] Changing module files

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #8 from Joost VandeVondele  
2012-10-06 12:52:09 UTC ---

(In reply to comment #3)

> Created attachment 28372 [details]

> Candidate patch



actually... looking at the patch, don't you need to deal with the if statements

that return ?

[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  2012-10-06 
13:04:38 UTC ---
Author: tkoenig
Date: Sat Oct  6 13:04:35 2012
New Revision: 192158

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192158
Log:
2012-10-06  Thomas König  

PR libfortran/54736
* runtime/environ.c (search_unit):  Correct logic
for binary search.
(mark_single):  Fix index errors.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/environ.c

[Bug target/54829] bad optimization: sub followed by cmp w/ zero (ARM)

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



Summary|bad optimization: sub   |bad optimization: sub

   |followed by cmp w/ zero |followed by cmp w/ zero

   |(x86 & ARM) |(ARM)



--- Comment #2 from H.J. Lu  2012-10-06 13:31:00 
UTC ---

i386.md has



(define_insn "*cmp_minus_1"

  [(set (reg FLAGS_REG)

(compare

  (minus:SWI (match_operand:SWI 0 "nonimmediate_operand" "m,")

 (match_operand:SWI 1 "" ",m"))

  (const_int 0)))]

  "ix86_match_ccmode (insn, CCGOCmode)"

  "cmp{}\t{%1, %0|%0, %1}"

  [(set_attr "type" "icmp")

   (set_attr "mode" "")])



Since cmp will also set OF and CF flags, it can't be used for GT and LE

which checks OF.

[Bug lto/54790] [4.8 Regression] Missing optimization with LTO

[hubicka at gcc dot gnu.org]

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



--- Comment #6 from Jan Hubicka  2012-10-06 
13:59:59 UTC ---

Author: hubicka

Date: Sat Oct  6 13:59:55 2012

New Revision: 192159



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192159

Log:



PR lto/54790 

* lto.c (resolution_map): New static var.

(register_resolution): New function.

(lto_register_var_decl_in_symtab): Use it.

(read_cgraph_and_symbols): Copy resolutions into the symtab.

* lto-streamer.h (lto_symtab_register_decl, lto_symtab_get_resolution,

lto_mark_nothrow_fndecl, lto_fixup_nothrow_decls): Remove.

* lto-symtab.c (lto_symtab_register_decl): Remove.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/lto-streamer.h

trunk/gcc/lto-symtab.c

trunk/gcc/lto/ChangeLog

trunk/gcc/lto/lto.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/54832] [4.8 Regression] [OOP] Type-bound operator not picked up with RESULT variable

[janus at gcc dot gnu.org]

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



--- Comment #4 from janus at gcc dot gnu.org 2012-10-06 14:03:14 UTC ---

Author: janus

Date: Sat Oct  6 14:03:08 2012

New Revision: 192160



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192160

Log:

2012-10-06  Janus Weil  



PR fortran/54832

* resolve.c (resolve_fl_derived0): Correctly copy the 'class_ok'

attribute for proc-ptr components with RESULT variable.



2012-10-06  Janus Weil  



PR fortran/54832

* gfortran.dg/typebound_operator_17.f90: New.



Added:

trunk/gcc/testsuite/gfortran.dg/typebound_operator_17.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/resolve.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/54832] [4.8 Regression] [OOP] Type-bound operator not picked up with RESULT variable

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from janus at gcc dot gnu.org 2012-10-06 14:07:37 UTC ---

Fixed with r192160. Closing.

[Bug fortran/40453] [F95] Enhanced (recursive) argument checking

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



Summary|Enhanced argument checking: |[F95] Enhanced (recursive)

   ||argument checking



--- Comment #1 from janus at gcc dot gnu.org 2012-10-06 14:39:48 UTC ---

(In reply to comment #0)

> I think some other checks should still be added, e.g.

> 

> a) PUREness check (see example below); passing/assigning

>a pure to a non-pure dummy/proc-pointer is OK; doing vice versa

>is not.

> 

> [...]

> 

> b) Similarly for ELEMENTAL. For proc-pointer assignments, use the

>first example with PURE changed to ELEMENTAL. That non-intrinsic

>elementals are not allowed as actual argument, is already checked

>for (cf. C1228). Except of the remark in parentheses I could not

>find in F2003/F2008 anything which prohibits ELEMENTAL for the

>dummy argument; however, the parentheses is normative. Maybe one

>should re-check the standard before adding an error check (see

>example below).



Both checks for PURE and ELEMENTAL have been implemented in r179080 for

PR41733.





> c) One needs to go recursively over the arguments as the second

>example below shows.

> 

> [...] 

>

> program RecursiveInterface

>   interface

> subroutine a(x)

>   real :: x

> end subroutine a

> subroutine b(a)

>   integer :: a

> end subroutine b

> subroutine c(f)

>   procedure(a) :: f

> end subroutine c

> subroutine d(f)

>   procedure(b) :: f

> end subroutine d

> subroutine e(f)

>  procedure(c) :: f

> end subroutine e

>   end interface

>   call e(d) ! Argument (dummy subroutine) d has an integer argument

> ! but e's f expects a real argument

> end program RecursiveInterface



In fact this is still accepted without error.

[Bug lto/54790] [4.8 Regression] Missing optimization with LTO

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Jan Hubicka  2012-10-06 
14:42:10 UTC ---

Fixed.

[Bug fortran/40453] [F95] Enhanced (recursive) argument checking

[janus at gcc dot gnu.org]

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



--- Comment #2 from janus at gcc dot gnu.org 2012-10-06 14:44:07 UTC ---

Slightly reworked example, which I hope is a bit easier to grasp:





program RecursiveInterface



  call c(b2) ! b2's argument a2 has an integer argument,

 ! but c expects a routine like b1 with an argument a1

 ! with real argument



 contains



subroutine a1(x)

  real :: x

end subroutine



subroutine a2(i)

  integer :: i

end subroutine



!!!



subroutine b1(f)

  procedure(a1) :: f

end subroutine



subroutine b2(f)

  procedure(a2) :: f

end subroutine



!!!



subroutine c(f)

 procedure(b1) :: f

end subroutine e



end

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at gcc dot gnu.org]

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



--- Comment #25 from Jan Hubicka  2012-10-06 
14:50:27 UTC ---

What you hit here is the V1 linker plugin API hack.  We, for purpose, hide

COMDAT objects when we know we can hide them, because otherwise linker will

assign them PREVAILING and we will be forced to output them even if they are

otherwise unused.  This kills code quality and breaks some C++ apps.



Plugin API is underspecfied as what symbols you can create without being asked

for.  Obviously one need to create ones to get WHOPR work. I would agree with

comment #4 that linker should survive introduction of the COMDAT.



I am not sure if the testcase is invalid - it should include the definition of

the function IMO. But without giving up on V1 API we can not fix that.  I am

going to commit that to 4.8, so that will leave it 4.7 regression (or

non-regression) only.



We discussed it couple times - there is way to get this working with V2 linker

while still supporting hack for V1 API. It requires moving the whole logic into

plugin and I am not sure it is worth the effort for 4.7 alone.

[Bug tree-optimization/54776] [4.8 Regression] tramp3d-v4: 20% performance regression using -O3

[hubicka at gcc dot gnu.org]

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



--- Comment #9 from Jan Hubicka  2012-10-06 
15:07:58 UTC ---

Mainline -O3

  Time spent in iteration: 11.0926

LTO (with today fix for resolution info)

  Time spent in iteration: 10.9666

LTO with V1 API hack disabled

  Time spent in iteration: 9.58262

Whole program

  Time spent in iteration: 9.59799

Mainline -O3 --param early-inlining-insns=13 (default is 11)

  Time spent in iteration: 8.94558



So the LTO problem is solved.  I will try to look at the functions with

estimated cost of 12 and 13 to see if I can reduce it. Otherwise I guess we

could simply bump up the early-inlining-insns.  It was set lower based on

tramp3d and because of accounting inconsistency.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at gcc dot gnu.org]

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



--- Comment #26 from Jan Hubicka  2012-10-06 
15:30:12 UTC ---

Also note that binutils has default search path for plugin. If we installed our

linker plugin there, the ugly gcc-nm/gcc-ar wrappers would not be needed.

[Bug fortran/54836] New: checking whether the GNU Fortran compiler is working... no

[zhou3 at lycos dot com]

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



 Bug #: 54836

   Summary: checking whether the GNU Fortran compiler is

working... no

Classification: Unclassified

   Product: gcc

   Version: 4.4.7

Status: UNCONFIRMED

  Severity: blocker

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: zh...@lycos.com





Created attachment 28375

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28375

configure: error: GNU Fortran is not working; please report a bug in

http://gcc.gnu.org/bugzilla, attaching

/Users/lizhou/Downloads/gcc-4.4.7/x86_64-apple-darwin12.2.0/libgfortran/config.log



checking whether the GNU Fortran compiler is working... no

configure: error: GNU Fortran is not working; please report a bug in

http://gcc.gnu.org/bugzilla, attaching

/Users/lizhou/Downloads/gcc-4.4.7/x86_64-apple-darwin12.2.0/libgfortran/config.log

[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 & ARM)

[daniel.santos at pobox dot com]

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



Daniel Santos  changed:



   What|Removed |Added



Summary|bad optimization: sub   |bad optimization: sub

   |followed by cmp w/ zero |followed by cmp w/ zero

   |(ARM)   |(x86 & ARM)



--- Comment #3 from Daniel Santos  2012-10-06 
15:55:47 UTC ---

Sure it can:



extern print_gt(void);

extern print_lt(void);

extern print_eq(void);



void cmp_and_branch(long a, long b)

{

if (a > b) {

print_gt();

} else if (a < b) {

print_lt();

} else {

print_eq();

}

}



Here's x86_64:



cmp_and_branch:

.LFB0:

.cfi_startproc

cmpq%rsi, %rdi

jg  .L5

jl  .L6

jmp print_eq

.p2align 4,,10

.p2align 3

.L6:

jmp print_lt

.p2align 4,,10

.p2align 3

.L5:

jmp print_gt

.cfi_endproc



And here's i386:



cmp_and_branch:

.LFB0:

.cfi_startproc

movl8(%esp), %eax

cmpl%eax, 4(%esp)

jg  .L5

jl  .L6

jmp print_eq

.p2align 2,,3

.L6:

jmp print_lt

.p2align 2,,3

.L5:

jmp print_gt

.cfi_endproc

[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 & ARM)

[daniel.santos at pobox dot com]

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



--- Comment #4 from Daniel Santos  2012-10-06 
15:57:15 UTC ---

Please help me out here if I am missing something.

[Bug fortran/54836] checking whether the GNU Fortran compiler is working... no

[dominiq at lps dot ens.fr]

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



--- Comment #1 from Dominique d'Humieres  2012-10-06 
16:01:14 UTC ---

It looks like a duplicate of pr45277, i.e., at least one of your GMP, MPFR, or

MPC libraries has a problem (see

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277#c1 ).



Question: why do you want to build 4.4.7? It is no longer supported and it

would be better to build 4.7.2 (latest release).

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[markus at trippelsdorf dot de]

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



--- Comment #27 from Markus Trippelsdorf  
2012-10-06 16:06:03 UTC ---

(In reply to comment #26)

> Also note that binutils has default search path for plugin. If we installed 
> our

> linker plugin there, the ugly gcc-nm/gcc-ar wrappers would not be needed.



There is also H.J.'s proposal to add automatic plugin support, or

mine to add an environment variable. See:

http://sourceware.org/ml/binutils/2012-10/msg00050.html

[Bug debug/54826] gdb test case failure (bs15503) due to gaps in lexical block

[dehao at gcc dot gnu.org]

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



--- Comment #2 from dehao at gcc dot gnu.org 2012-10-06 16:19:43 UTC ---

Author: dehao

Date: Sat Oct  6 16:19:34 2012

New Revision: 192165



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192165

Log:

2012-10-05  Dehao Chen  



PR debug/54826

* gimple-low.c (lower_stmt): Set the block for call args.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/gimple-low.c

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at ucw dot cz]

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



--- Comment #28 from Jan Hubicka  2012-10-06 16:20:57 
UTC ---

> There is also H.J.'s proposal to add automatic plugin support, or

> mine to add an environment variable. See:

> http://sourceware.org/ml/binutils/2012-10/msg00050.html

Interesting, I missed this.



Why nm/ar/ld can't just support multiple plugins and load all plugins from its

default plugin directory (where all installed compilers will drop one) and

choose

the one claiming the file?

I see it would need some work on linker side if one plugin claims one file and

other

plugin other file, but there don't seem to be anything in the plugin API making

this

impossible and we can just error out in this case until mixing LTO from

different

compilers become fashionable.



Honza

[Bug fortran/54836] checking whether the GNU Fortran compiler is working... no

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



   Severity|blocker |normal

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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



--- Comment #14 from Jack Howarth  2012-10-06 
17:00:17 UTC ---

Interestingly Macports' libgomp shows the same expected emutls related symbols

as fink...



% nm libgomp.1.dylib  | grep emutls

 U ___emutls_get_address

b1e0 d ___emutls_v.gomp_tls_data



I suspect the absence of ___emutls_v.* symbols in the MacPorts gcc47's

libstdc++.6.dylib could be due to the fact that clang is used to build it

rather than a proper full bootstrap. Please try restoring the bootstrap and see

if the symbols are restored to libstdc++.6.dylib.

[Bug lto/54790] [4.8 Regression] Missing optimization with LTO

[glisse at gcc dot gnu.org]

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



--- Comment #8 from Marc Glisse  2012-10-06 17:25:48 
UTC ---

(In reply to comment #6)

> trunk/gcc/testsuite/ChangeLog



I don't see the file gcc.dg/lto/resolutions_0.c.

[Bug bootstrap/54837] New: [4.8 Regression] lto bootstrap error: ICE in expand_debug_source_expr, at cfgexpand.c:3538

[markus at trippelsdorf dot de]

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

 Bug #: 54837
   Summary: [4.8 Regression] lto bootstrap error: ICE in
expand_debug_source_expr, at cfgexpand.c:3538
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de


With:
~/gcc/configure --disable-werror --disable-multilib --enable-languages=c,c++
--enable-checking=yes --with-build-config=lto-bootstrap

I get:
In file included from :36:0:
/home/markus/gcc/gcc/vec.h: In member function
‘_ZN5vec_tIcE3popEPKcjS2_.local.27.constprop.53’:
/home/markus/gcc/gcc/vec.h:810:1: internal compiler error: in
expand_debug_source_expr, at cfgexpand.c:3538
 vec_t::pop (ALONE_VEC_CHECK_DECL)
 ^
0x5755a8 expand_debug_source_expr
/home/markus/gcc/gcc/cfgexpand.c:3537
0x575a78 expand_debug_locations
/home/markus/gcc/gcc/cfgexpand.c:3622
0x578496 gimple_expand_cfg
/home/markus/gcc/gcc/cfgexpand.c:4487
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

Reduced:

markus@x4 gcc % cat test.ii
struct A
{
int num_;
};
template < typename T > struct B
{
T & pop (const char *);
A prefix_;
T vec_[];
};
char *a;
B < int >*b;
void fn1 (char *, const char *) __attribute__ ((__noreturn__));
template < typename T > T & B < T >::pop (const char *p1)
{
prefix_.num_ ? : (fn1 (a, p1), 0);
return vec_[-prefix_.num_];
}

int main ()
{
b->pop (__FUNCTION__);
b->pop (__FUNCTION__);
b->pop (__FUNCTION__);
}

markus@x4 gcc % /var/tmp/gcc_build_dir/./prev-gcc/g++
-B/var/tmp/gcc_build_dir/./prev-gcc/ test.ii -nodefaultlibs -g -O2 -flto
In file included from :1:0:
test.ii: In member function ‘_ZN1BIiE3popEPKc.local.0.constprop.1’:
test.ii:14:29: internal compiler error: in expand_debug_source_expr, at
cfgexpand.c:3538
 template < typename T > T & B < T >::pop (const char *p1)
 ^
0x5755a8 expand_debug_source_expr
/home/markus/gcc/gcc/cfgexpand.c:3537
0x575a78 expand_debug_locations
/home/markus/gcc/gcc/cfgexpand.c:3622
0x578496 gimple_expand_cfg
/home/markus/gcc/gcc/cfgexpand.c:4487
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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



--- Comment #15 from Jack Howarth  2012-10-06 
17:26:51 UTC ---

I believe your no-runtime-stubs.patch used during the initial build of

libstdc++ is at fault...



--- gcc/config/darwin.h.orig2012-09-13 20:20:33.0 -0700

+++ gcc/config/darwin.h 2012-09-13 20:23:03.0 -0700

@@ -325,17 +325,8 @@ extern GTY(()) int darwin_ms_struct;

 #undef REAL_LIBGCC_SPEC

 #define REAL_LIBGCC_SPEC  \

"%{static-libgcc|static: -lgcc_eh -lgcc;   \

-  shared-libgcc|fexceptions|fgnu-runtime: \

-   %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)   \

-   %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \

-   %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4) \

-   %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5) \

-   -lgcc ;\

-  :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \

-   %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \

-   %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4) \

-   %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5) \

-   -lgcc }"

+  shared-libgcc|fexceptions|fgnu-runtime: -lgcc;  \

+  : -lgcc }"



 /* We specify crt0.o as -lcrt0.o so that ld will search the library path.



--- libgcc/config/t-slibgcc-darwin.orig 2012-09-13 20:26:11.0 -0700

+++ libgcc/config/t-slibgcc-darwin  2012-09-13 20:27:08.0 -0700

@@ -39,7 +39,7 @@ endif



 LGCC_FILES = libgcc_s.$(SHLIB_SOVERSION)$(SHLIB_EXT)

 LGCC_FILES += $(LGCC_STUBS)

-LEXT_STUBS = libgcc_ext.10.4$(SHLIB_EXT) libgcc_ext.10.5$(SHLIB_EXT)

+LEXT_STUBS =

 LGCC_FILES += $(LEXT_STUBS)

 INSTALL_FILES=$(LGCC_FILES)



These changes will certainly keep config.h in the libstdc++-v3 build directory

from having...



#define HAVE_TLS 



Why is it so critical for MacPorts to eliminate the linkage on 

libgcc_ext.10.4/ libgcc_ext.10.5?

IMHO, the current approach is extremely radical.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at gcc dot gnu.org]

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



--- Comment #29 from Jan Hubicka  2012-10-06 
17:30:51 UTC ---

Author: hubicka

Date: Sat Oct  6 17:30:42 2012

New Revision: 192166



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192166

Log:

PR lto/53831

PR lto/54776

* lto-streamer-out.c (produce_symtab): Cleanup; drop v1 API hack.



Added:

trunk/gcc/testsuite/g++.dg/lto/v1-plugin-api-not-supported_0.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/lto-streamer-out.c

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/54776] [4.8 Regression] tramp3d-v4: 20% performance regression using -O3

[hubicka at gcc dot gnu.org]

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



--- Comment #10 from Jan Hubicka  2012-10-06 
17:30:51 UTC ---

Author: hubicka

Date: Sat Oct  6 17:30:42 2012

New Revision: 192166



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192166

Log:

PR lto/53831

PR lto/54776

* lto-streamer-out.c (produce_symtab): Cleanup; drop v1 API hack.



Added:

trunk/gcc/testsuite/g++.dg/lto/v1-plugin-api-not-supported_0.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/lto-streamer-out.c

trunk/gcc/testsuite/ChangeLog

[Bug lto/54790] [4.8 Regression] Missing optimization with LTO

[hubicka at ucw dot cz]

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



--- Comment #9 from Jan Hubicka  2012-10-06 17:43:29 UTC 
---

> > trunk/gcc/testsuite/ChangeLog

> 

> I don't see the file gcc.dg/lto/resolutions_0.c.

Fixed now, thanks!

Honza

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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



--- Comment #16 from Jeremy Huddleston Sequoia  
2012-10-06 17:47:52 UTC ---

(In reply to comment #14)

> Interestingly Macports' libgomp shows the same expected emutls related symbols

> as fink...

> 

> % nm libgomp.1.dylib  | grep emutls

>  U ___emutls_get_address

> b1e0 d ___emutls_v.gomp_tls_data

> 

> I suspect the absence of ___emutls_v.* symbols in the MacPorts gcc47's

> libstdc++.6.dylib could be due to the fact that clang is used to build it

> rather than a proper full bootstrap. Please try restoring the bootstrap and 
> see

> if the symbols are restored to libstdc++.6.dylib.



We do a full bootstrap first before building libstdc++.  There is an issue with

clang (fixed in llvm-3.2) which prevents us from using clang to build libstdc++



(In reply to comment #15)

> I believe your no-runtime-stubs.patch used during the initial build of

> libstdc++ is at fault...

> ...

> 

> These changes will certainly keep config.h in the libstdc++-v3 build directory

> from having...

> 

> #define HAVE_TLS 



Why?  That seems odd.



> Why is it so critical for MacPorts to eliminate the linkage on 

> libgcc_ext.10.4/ libgcc_ext.10.5?



Because it doesn't exist.

[Bug fortran/54836] checking whether the GNU Fortran compiler is working... no

[pinskia at gcc dot gnu.org]

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



--- Comment #2 from Andrew Pinski  2012-10-06 
17:53:45 UTC ---

configure:14187:

/Users/lizhou/Downloads/gcc-4.4.7/host-x86_64-apple-darwin12.2.0/gcc/gfortran

-B/Users/lizhou/Downloads/gcc-4.4.7/host-x86_64-apple-darwin12.2.0/gcc/

-B/Users/lizhou/x86_64-apple-darwin12.2.0/bin/

-B/Users/lizhou/x86_64-apple-darwin12.2.0/lib/ -isystem

/Users/lizhou/x86_64-apple-darwin12.2.0/include -isystem

/Users/lizhou/x86_64-apple-darwin12.2.0/sys-include -c -g -O2  conftest.f >&5

f951: internal compiler error: Segmentation fault: 11

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug middle-end/54838] New: [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -O2 -ftracer -fno-tree-dce -fno-tree-sra

[zsojka at seznam dot cz]

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



 Bug #: 54838

   Summary: [4.8 Regression] ICE: in merge_latch_edges, at

cfgloop.c:678 with -O2 -ftracer -fno-tree-dce

-fno-tree-sra

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: zso...@seznam.cz





Created attachment 28376

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28376

reduced testcase



Compiler output:

$ gcc -O2 -ftracer -fno-tree-dce -fno-tree-sra testcase.C

testcase.C: In function '_ForwardIterator1 search(_ForwardIterator1,

_ForwardIterator1)':

testcase.C:113:3: internal compiler error: in merge_latch_edges, at

cfgloop.c:678

   }

   ^

0x840a29 merge_latch_edges

/mnt/svn/gcc-trunk/gcc/cfgloop.c:678

0x840a29 disambiguate_multiple_latches

/mnt/svn/gcc-trunk/gcc/cfgloop.c:741

0x840a29 disambiguate_loops_with_multiple_latches()

/mnt/svn/gcc-trunk/gcc/cfgloop.c:755

0xa49ed4 loop_optimizer_init(unsigned int)

/mnt/svn/gcc-trunk/gcc/loop-init.c:78

0x12084de fwprop_init

/mnt/svn/gcc-trunk/gcc/fwprop.c:1412

0x120869a fwprop

/mnt/svn/gcc-trunk/gcc/fwprop.c:1459

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Tested revisions:

r192080 - crash

r191586 - crash

4.7 r191640 - OK

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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



--- Comment #17 from Jack Howarth  2012-10-06 
19:26:49 UTC ---

(In reply to comment #16)

> > These changes will certainly keep config.h in the libstdc++-v3 build 
> > directory

> > from having...

> > 

> > #define HAVE_TLS 

> 

> Why?  That seems odd.



Not really. The use of the no-runtime-stubs.patch patch would keep the tests

in config/tls.m4 for working properly as it breaks the ability of the xgcc

compiler

from accessing the emutls support calls residing in libgcc_ext.10.4/5.



> 

> > Why is it so critical for MacPorts to eliminate the linkage on 

> > libgcc_ext.10.4/ libgcc_ext.10.5?

> 

> Because it doesn't exist.



This is the wrong approach. You shouldn't be trying to gut libgcc_ext from

libstdc++-v3 but

rather creating an additional splitoff for libgcc_s/libgcc_ext.10.4/5 so that

they are kept at

the latest level.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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



--- Comment #18 from Jeremy Huddleston Sequoia  
2012-10-06 19:53:25 UTC ---

(In reply to comment #17)

> (In reply to comment #16)

> > > These changes will certainly keep config.h in the libstdc++-v3 build 
> > > directory

> > > from having...

> > > 

> > > #define HAVE_TLS 

> > 

> > Why?  That seems odd.

> 

> Not really. The use of the no-runtime-stubs.patch patch would keep the tests

> in config/tls.m4 for working properly as it breaks the ability of the xgcc

> compiler

> from accessing the emutls support calls residing in libgcc_ext.10.4/5.



Nothing actually "resides in" libgcc_ext.10.[45].dylib ... those are stub

libraries which result in those symbols resolving to

/opt/local/lib/gccXX/libgcc_s.1.dylib.



> > > Why is it so critical for MacPorts to eliminate the linkage on 

> > > libgcc_ext.10.4/ libgcc_ext.10.5?

> > 

> > Because it doesn't exist.

> 

> This is the wrong approach. You shouldn't be trying to gut libgcc_ext from

> libstdc++-v3 but

> rather creating an additional splitoff for libgcc_s/libgcc_ext.10.4/5 so that

> they are kept at

> the latest level.



Yes, that was what I eventually want to do, but this was the first step of that

approach.  Still, this *should* work.



Note that the libgcc_ext.10.[45] are not actually needed if we're going to be

using the libgcc runtime.  This is the whole reason why I suggest just removing

them entirely in a future release.  The whole point of those stubs is to let

let linker pick up some of the runtime from libSystem and the rest (things

added after gcc-4.2) from the in-tree libgcc_s.dylib.  If we're going to be in

the business of shipping our own compiler runtime, we don't need to let some

parts resolve to libSystem and others resolve to ours.  We should just let it

all resolve to ours.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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



--- Comment #19 from Jack Howarth  2012-10-06 
20:56:44 UTC ---

(In reply to comment #18)

> Note that the libgcc_ext.10.[45] are not actually needed if we're going to be

> using the libgcc runtime.  This is the whole reason why I suggest just 
> removing

> them entirely in a future release.  The whole point of those stubs is to let

> let linker pick up some of the runtime from libSystem and the rest (things

> added after gcc-4.2) from the in-tree libgcc_s.dylib.  If we're going to be in

> the business of shipping our own compiler runtime, we don't need to let some

> parts resolve to libSystem and others resolve to ours.  We should just let it

> all resolve to ours.



My understanding is that the libgcc symbols that have been subsumed into

libSystem as of

darwin10 and will always override those provided by any additional libgcc. The

following messages

from the darwin linker developer on llvm-dev covered this and related issues

with the unwinder.



http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html



Perhaps you are proposing that eventually we gut the duplicate symbols, now in

libSystem, out of FSF libgcc_s but that would have to be done very carefully.

Over

a years work went into the libgcc_ext design and implementation. A similar

effort

would be required to gracefully replace it.

[Bug fortran/40453] [F95] Enhanced (recursive) argument checking

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



   Keywords|diagnostic  |accepts-invalid

 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org

   |gnu.org |



--- Comment #3 from janus at gcc dot gnu.org 2012-10-06 21:04:31 UTC ---

Here is a draft patch:



Index: gcc/fortran/interface.c

===

--- gcc/fortran/interface.c(revision 192159)

+++ gcc/fortran/interface.c(working copy)

@@ -1063,6 +1063,19 @@ check_dummy_characteristics (gfc_symbol *s1, gfc_s

   /* FIXME: Do more comprehensive testing of attributes, like e.g.

 ASYNCHRONOUS, CONTIGUOUS, VALUE, VOLATILE, etc.  */



+  /* Check interface of dummy procedures.  */

+  if (s1->attr.flavor == FL_PROCEDURE)

+{

+  char err[200];

+  if (!gfc_compare_interfaces (s1, s2, s2->name, 0, 1, err, sizeof(err),

+   NULL, NULL))

+{

+  snprintf (errmsg, err_len, "Interface mismatch in dummy procedure "

+"'%s': %s", s1->name, err);

+  return FAILURE;

+}

+}

+

   /* Check string length.  */

   if (s1->ts.type == BT_CHARACTER

   && s1->ts.u.cl && s1->ts.u.cl->length

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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



--- Comment #20 from Jack Howarth  2012-10-06 
21:06:45 UTC ---

Also, you might want to look at

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888 which shows the thought

process and issues that arose during the libgcc_ext development.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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



--- Comment #21 from Jeremy Huddleston Sequoia  
2012-10-06 21:14:30 UTC ---

(In reply to comment #19)

> (In reply to comment #18)

> > Note that the libgcc_ext.10.[45] are not actually needed if we're going to 
> > be

> > using the libgcc runtime.  This is the whole reason why I suggest just 
> > removing

> > them entirely in a future release.  The whole point of those stubs is to let

> > let linker pick up some of the runtime from libSystem and the rest (things

> > added after gcc-4.2) from the in-tree libgcc_s.dylib.  If we're going to be 
> > in

> > the business of shipping our own compiler runtime, we don't need to let some

> > parts resolve to libSystem and others resolve to ours.  We should just let 
> > it

> > all resolve to ours.

> 

> My understanding is that the libgcc symbols that have been subsumed into

> libSystem as of

> darwin10 and will always override those provided by any additional libgcc.



yes



> The

> following messages

> from the darwin linker developer on llvm-dev covered this and related issues

> with the unwinder.

> 

> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html

> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html

> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html

> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html

> 

> Perhaps you are proposing that eventually we gut the duplicate symbols, now in

> libSystem, out of FSF libgcc_s but that would have to be done very carefully.

> Over

> a years work went into the libgcc_ext design and implementation. A similar

> effort

> would be required to gracefully replace it.



Yes ... which is why I simply mentioned it in a comment and haven't started

going down that road except as a brain exercise.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

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



--- Comment #22 from Jeremy Huddleston Sequoia  
2012-10-06 21:15:02 UTC ---

In any event, this is a MacPorts bug for which I have a fix. This upstream bug

should be closed.

[Bug fortran/40850] double free in nested types with allocatable components

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #19 from janus at gcc dot gnu.org 2012-10-06 21:26:30 UTC ---

Finally closing as fixed.

[Bug fortran/40453] [F95] Enhanced (recursive) argument checking

[janus at gcc dot gnu.org]

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



--- Comment #4 from janus at gcc dot gnu.org 2012-10-06 21:49:37 UTC ---

(In reply to comment #3)

> Here is a draft patch:



... which regtests cleanly.

[Bug lto/54839] New: INTEGER_CST is missed by uniuqify_nodes and soaks tons of memory

[hubicka at gcc dot gnu.org]

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



 Bug #: 54839

   Summary: INTEGER_CST is missed by uniuqify_nodes and soaks tons

of memory

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: hubi...@gcc.gnu.org





Created attachment 28377

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28377

patch



Because integer_cst is streamed directly, it bypasses streamer cache. It

however reffers to types and the types needs fixup.

The attached patch provokes the problem by ggc_freeing the obsoletted types and

also fixes it by adding to_fix vector. I wonder what is better option?

Do we need to stream them differently? I guess integer_csts are often 0/1 and

streaming always the whole thing seems wasteful.

[Bug c++/54249] [C++11] No ::nullptr_t in header

[paolo at gcc dot gnu.org]

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



--- Comment #13 from paolo at gcc dot gnu.org  
2012-10-06 22:44:23 UTC ---

Author: paolo

Date: Sat Oct  6 22:44:12 2012

New Revision: 192173



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192173

Log:

2012-10-06  Paolo Carlini  



PR c++/54249

* ginclude/stddef.h: In C++11 mode declare nullptr_t in the global

namespace.



/testsuite

2012-10-06  Paolo Carlini  



PR c++/54249

* g++.dg/cpp0x/stddef.C: New.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/stddef.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/ginclude/stddef.h

trunk/gcc/testsuite/ChangeLog

[Bug c++/54249] [C++11] No ::nullptr_t in header

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #14 from Paolo Carlini  2012-10-06 
22:46:39 UTC ---

Fixed.

[Bug fortran/54840] New: ieee_arithmetic intrinsic module

[andy.nelson at lanl dot gov]

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



 Bug #: 54840

   Summary: ieee_arithmetic intrinsic module

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: andy.nel...@lanl.gov





I guess this isn't actually a bug, but an rfe, or something similarly named.

Don't know the right place for putting this into the record, so I'm putting it

into bugzilla in hopes of having it somewhere.



It would be a very nice thing to have available the ieee_arithmetic intrinsic

module, which afaik, does not exist in gfortran yet (see below), at least as of

4.7.0. Probably, for some compiler newbie, it would be a fairly easy task to

implement it. (not me unfortunately...round tuit shortages are a fact of life

in my universe).



In particular the functionality that does things like ieee_is_nan(x) and its

friends would be what I was after most specifically.



Thanks,



Andy Nelson











 gfortran define_kind.f90 

define_kind.f90:17.4:



use ieee_arithmetic

1

Fatal Error: Can't open module file 'ieee_arithmetic.mod' for reading at (1):

No such file or directory

115 ml-fey : gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/usr/aprojects/hpcsoft/moonlight/gcc/4.7.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-4.7.0/configure

--prefix=/usr/projects/hpcsoft/moonlight/gcc/4.7.0 --enable-bootstrap

--enable-shared --enable-threads=posix --enable-checking=release

--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions

--enable-languages=c,c++,fortran --disable-libgcj --disable-multilib

--with-gmp=/tmp/dog/gmp-5.0.4 --with-mpfr=/tmp/dog/mpfr-3.1.0

--with-mpc=/tmp/dog/mpc-0.9 --with-ppl=/tmp/dog/ppl-0.12

--with-cloog=/tmp/dog/cloog-parma-0.16.1 --enable-cloog-backend=ppl

--with-host-libstdcxx='-L/tmp/dog/gcc/lib64 -lstdc++ -lsupc++ -lm'

Thread model: posix

gcc version 4.7.0 (GCC) 





...gives similar errors for various other spellings like:



120 ml-fey : !gfo

gfortran define_kind.f90

define_kind.f90:17.17:



use, intrinsic :: ieee_arithmetic

 1

Fatal Error: Can't find an intrinsic module named 'ieee_arithmetic' at (1)

[Bug c/52991] attribute packed broken on mingw32?

[daniel.c.klauer at web dot de]

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



--- Comment #6 from daniel.c.klauer at web dot de 2012-10-06 23:02:22 UTC ---

Using the ms_struct attribute instead of compiling with -mms-bitfields

reproduces the packing issue, while using the gcc_struct attribute prevents the

issue from showing up even under -mms-bitfields.



These struct examples show the packing issue without nested structs:



struct __attribute__((ms_struct, packed)) A {

int   a;

short b;

};

struct __attribute__((ms_struct, packed)) B {

short a;

int   b;

};



sizeof(struct A) == 6 as expected

sizeof(struct B) == 8 unexpected, expected 6 instead

offsetof(struct B, b) == 4unexpected, expected 2 instead



A message [1] from the mingw-w64-public mailing list indicates this behaviour:

Only the outer struct is packed, causing padding bytes at its end to be removed

as expected, but not the fields: padding bytes in front of a field according to

the field's natural alignment are not removed, despite the packed attribute,

which is unexpected.



Explicitly packing the fields does not help:



struct __attribute__((ms_struct)) C {

int   a __attribute__((packed, aligned(1)));

short b __attribute__((packed, aligned(1)));

};

struct __attribute__((ms_struct)) D {

short a __attribute__((packed, aligned(1)));

int   b __attribute__((packed, aligned(1)));

};



sizeof(struct C) == 6 as expected

sizeof(struct D) == 8 unexpected, expected 6 instead

offsetof(struct D, b) == 4unexpected, expected 2 instead



[1] http://sourceforge.net/mailarchive/message.php?msg_id=29650589

[Bug c++/52764] Including after fails to define limit macros

[paolo at gcc dot gnu.org]

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



--- Comment #8 from paolo at gcc dot gnu.org  
2012-10-06 23:06:09 UTC ---

Author: paolo

Date: Sat Oct  6 23:06:04 2012

New Revision: 192174



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192174

Log:

2012-10-06  Paolo Carlini  



PR c++/52764

* ginclude/stdint-wrap.h: In C++11 if __STDC_HOSTED__ define

__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS.

* ginclude/stdint-gcc.h: In C++11 unconditionally define

limit and constant macros.



/testsuite

2012-10-06  Paolo Carlini  



PR c++/52764

* g++.dg/cpp0x/stdint.C: New.



/libstdc++-v3

2012-10-06  Paolo Carlini  



PR c++/52764

* include/c_global/cstdint: Remove __STDC_LIMIT_MACROS and

__STDC_CONSTANT_MACROS related macros.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/stdint.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/ginclude/stdint-gcc.h

trunk/gcc/ginclude/stdint-wrap.h

trunk/gcc/testsuite/ChangeLog

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/include/c_global/cstdint

[Bug c/52991] attribute packed broken on mingw32?

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||cgf at gcc dot gnu.org,

   ||ktietz at gcc dot gnu.org



--- Comment #7 from Paolo Carlini  2012-10-06 
23:08:12 UTC ---

Let's add in CC target maintainers.

[Bug c++/52764] Including after fails to define limit macros

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #9 from Paolo Carlini  2012-10-06 
23:10:58 UTC ---

Fixed.

[Bug target/54841] New: Bad optimization on stack fill before call on ARM

[vova7890 at mail dot ru]

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



 Bug #: 54841

   Summary: Bad optimization on stack fill before call on ARM

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: vova7...@mail.ru





GCC generating not best asm listing when before calling to function, he needs

to pass into a stack registers already setted before this, and it only needed

to pass it. Gcc passing it by str instruction. For example:



STR R6, [SP, #4]

STR R4, [SP]



It can be faster and smaller with this code:



STMEA   SP, {R4, R6}







---

Thanks

[Bug fortran/54840] ieee_arithmetic intrinsic module

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||kargl at gcc dot gnu.org

 Resolution||DUPLICATE



--- Comment #1 from kargl at gcc dot gnu.org 2012-10-07 00:08:49 UTC ---

> Probably, for some compiler newbie, it would be a fairly easy task to

> implement it.



It much much much harder to implement than you think.



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

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||andy.nelson at lanl dot gov



--- Comment #7 from kargl at gcc dot gnu.org 2012-10-07 00:08:49 UTC ---

*** Bug 54840 has been marked as a duplicate of this bug. ***

[Bug fortran/54842] New: checking whether the GNU Fortran compiler is working... no

[zhou3 at lycos dot com]

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



 Bug #: 54842

   Summary: checking whether the GNU Fortran compiler is

working... no

Classification: Unclassified

   Product: gcc

   Version: 4.5.4

Status: UNCONFIRMED

  Severity: blocker

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: zh...@lycos.com





Created attachment 28378

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28378

configure: error: GNU Fortran is not working; please report a bug in

http://gcc.gnu.org/bugzilla, attaching

/Users/lizhou/Downloads/gcc-4.5.4/x86_64-apple-darwin12.2.0/libgfortran/config.log



checking whether the GNU Fortran compiler is working... no

configure: error: GNU Fortran is not working; please report a bug in

http://gcc.gnu.org/bugzilla, attaching

/Users/lizhou/Downloads/gcc-4.5.4/x86_64-apple-darwin12.2.0/libgfortran/config.log

make[1]: *** [configure-target-libgfortran] Error 1

make: *** [all] Error 2

[Bug fortran/54842] checking whether the GNU Fortran compiler is working... no

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||kargl at gcc dot gnu.org

 Resolution||FIXED



--- Comment #1 from kargl at gcc dot gnu.org 2012-10-07 03:43:05 UTC ---

Gcc 4.5.4 is no longer supported.  Try using 4.6.x or 4.7.x.

[Bug fortran/54836] checking whether the GNU Fortran compiler is working... no

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||kargl at gcc dot gnu.org



--- Comment #3 from kargl at gcc dot gnu.org 2012-10-07 03:45:21 UTC ---

gcc 4.4.7 is no longer supported.  Try using 4.6.x or 4.7.x.



PS: What are the exact set of commands you used to try

to build gcc?

[Bug fortran/54836] checking whether the GNU Fortran compiler is working... no

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||WONTFIX



--- Comment #4 from kargl at gcc dot gnu.org 2012-10-07 03:45:54 UTC ---

Try a newer version.