[Bug middle-end/56185] [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite

[daniel.f.starke at freenet dot de]

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



--- Comment #5 from Daniel Starke  
2013-02-07 06:43:35 UTC ---

The arithmetic exception is caught by gcc, thus not triggered in gdb. I tried a

couple of things with gdb but could not find the point at which it happens. I

will try to create a gcc variant with checking enabled. Maybe this will give

some hints about the origin of this bug.

[Bug c++/56238] New: [4.8 regression] ICE in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2515

[ppluzhnikov at google dot com]

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

 Bug #: 56238
   Summary: [4.8 regression] ICE in tree check: expected
record_type or union_type or qual_union_type, have
template_type_parm in lookup_conversions, at
cp/search.c:2515
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


Test case:

class A
{
template < typename T > T& get ();
template < typename T > class B
{
void RemovePoint (A& value)
{
static_cast < double >(value.get < T > ());
}
};
};

Compiles fine with 4.7.x, with 4.8 without -std=c++11.
ICE's with -std=c++11 using
g++ (GCC) 4.8.0 20130205 (experimental)

g++ -c t.ii -std=c++11 
t.ii: In member function ‘void A::B::RemovePoint(A&)’:
t.ii:8:55: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2515
 static_cast < double >(value.get < T > ());
   ^
0xc6159a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:8946
0x66c962 tree_check3
../../gcc/tree.h:3709
...

Google ref: b/8153313

[Bug fortran/55469] memory leak on read with istat.ne.0

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #9 from Joost VandeVondele  
2013-02-07 05:57:43 UTC ---

This 



http://gcc.gnu.org/ml/gcc/2013-02/msg00068.html



seems the same/similar issue. Was there consensus about the patch ?

[Bug c++/56237] [4.8 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924

[ppluzhnikov at google dot com]

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



Paul Pluzhnikov  changed:



   What|Removed |Added



   Keywords||ice-on-valid-code



--- Comment #1 from Paul Pluzhnikov  2013-02-07 
05:49:29 UTC ---

Google ref: b/8152937

[Bug c++/56237] New: [4.8 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924

[ppluzhnikov at google dot com]

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

 Bug #: 56237
   Summary: [4.8 regression] ICE in lang_* check: failed in
push_local_name, at cp/decl.c:924
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


Test case reduced from jscoverage/jscpucfg.cpp

int main () {
  static union { } u;
  { static union { } u; }
}

Compiles fine with 4.7. Fails with g++ (GCC) 4.8.0 20130205 (experimental) in
C++11 mode:

g++ -c t.cc  # ok
g++ -c -std=c++11 t.ii
t.ii: In function ‘int main()’:
t.ii:3:22: internal compiler error: lang_* check: failed in push_local_name, at
cp/decl.c:924
   { static union { } u; }
  ^
0x697eb3 lang_check_failed(char const*, int, char const*)
../../gcc/cp/tree.c:3946
0x53e29b push_local_name
../../gcc/cp/decl.c:924
0x53e29b cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6286
...

[Bug debug/56236] New: incorrect debug info for decltype(nullptr)

[chihin.ko at oracle dot com]

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



 Bug #: 56236

   Summary: incorrect debug info for decltype(nullptr)

Classification: Unclassified

   Product: gcc

   Version: 4.6.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

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

ReportedBy: chihin...@oracle.com





g++ does not resolve decltype(nullptr) to base type nullptr_t, instead it

generate following: 



  < 1><0x05d3>DW_TAG_unspecified_type

  DW_AT_name  "decltype(nullptr)"



g++ should generate something like this:



< 1><0x05d3>DW_TAG_base_type

  DW_AT_name  "nullptr_t"

  DW_AT_encoding  DW_ATE_boolean

  DW_AT_byte_size 0x0004



main() {

int i;

decltype(nullptr) np;



np = 0;

i = sizeof(np);

}

[Bug c++/56235] New: [4.8 regression] Bogus "error: invalid conversion from ‘unsigned char’ to ‘B::Mode’ [-fpermissive]"

[ppluzhnikov at google dot com]

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

 Bug #: 56235
   Summary: [4.8 regression] Bogus "error: invalid conversion from
‘unsigned char’ to ‘B::Mode’ [-fpermissive]"
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


Test case:

struct A
{
A (const A &);
};

struct B
{
A a;
enum Mode { };
Mode m:8;
};

struct C
{
C();
B b;
};

C fn()
{
return C();
}


The test compiles fine with 4.7, fails with 4.8 (20130205 (experimental)) but
only in C++11 mode:

g++ -c -std=c++11 t.ii
t.ii: In constructor ‘B::B(B&&)’:
t.ii:6:8: error: invalid conversion from ‘unsigned char’ to ‘B::Mode’
[-fpermissive]
 struct B
^
t.ii: In constructor ‘C::C(C&&)’:
t.ii:13:8: note: synthesized method ‘B::B(B&&)’ first required here 
 struct C
^
t.ii: In function ‘C fn()’:
t.ii:21:14: note: synthesized method ‘C::C(C&&)’ first required here 
 return C();
  ^


Google ref: b/8152830

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[kcc at gcc dot gnu.org]

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



--- Comment #23 from Kostya Serebryany  2013-02-07 
05:01:53 UTC ---

with the patch from comment 22 (all benchmarks, ref data): 

   orig  patched

   400.perlbench,-1.00,  1244.00, -1244.00

   401.bzip2,  1189.00,  1137.00, 0.96

 403.gcc,   754.00,   750.00, 0.99

 429.mcf,   611.00,   610.00, 1.00

   445.gobmk,  1211.00,  1167.00, 0.96

   456.hmmer,  1834.00,  1501.00, 0.82

   458.sjeng,  1353.00,  1288.00, 0.95

  462.libquantum,   478.00,   480.00, 1.00

 464.h264ref,  1880.00,  1836.00, 0.98

 471.omnetpp,   621.00,   621.00, 1.00

   473.astar,   766.00,   763.00, 1.00

   483.xalancbmk,   515.00,   517.00, 1.00

433.milc,   631.00,   625.00, 0.99

444.namd,   538.00,   538.00, 1.00

  447.dealII,   716.00,   719.00, 1.00

  450.soplex,   421.00,   415.00, 0.99

  453.povray,   433.00,   429.00, 0.99

 470.lbm,   415.00,   411.00, 0.99

 482.sphinx3,  1377.00,  1343.00, 0.98



The average speedup is similar to what we saw with equivalent optimization in

clang. Strangely, 400.perlbench fails with a warning when built with trunk but

passes with this patch. I did not investigate this further yet.



If we are looking for greater speedup we need to perform more comprehensive 

research. I have two wild guesses (not supported by any data). 



#1 afaict, the asan pass happens in the middle of the gcc optimization flow.

imho it should happen as late as possible so that the instrumentation 

happens on fully optimized code. 

#2 asan speed is very sensitive to quality of regalloc. It would be interesting

(and useful anyway) to implement zero-offset-shadow

(https://code.google.com/p/address-sanitizer/wiki/ZeroBasedShadow)

and see how much it helps with performance. 

If more than clang's 5% -- we have issues with regalloc, otherwise see #1

[Bug debug/56234] Get "internal compiler error in dwarf2out_finish, at dwarf2out.c:18906" with -g option

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



  Component|c   |debug

   Severity|major   |normal

[Bug web/56233] Bugzilla: files (*.c, *.diff, etc.) wrongly recognized as application/octet-stream

[d.g.gorbachev at gmail dot com]

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



--- Comment #4 from Dmitry Gorbachev  
2013-02-07 03:37:53 UTC ---

Created attachment 29381

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

"Enter Bug" form (w/o javascript)

[Bug web/56233] Bugzilla: files (*.c, *.diff, etc.) wrongly recognized as application/octet-stream

[d.g.gorbachev at gmail dot com]

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



--- Comment #3 from Dmitry Gorbachev  
2013-02-07 03:34:21 UTC ---

> There is not much bugzilla can do.



It could either ignore mime type as sent by the browser, or show the "Content

Type" section.

[Bug c/56234] Get "internal compiler error in dwarf2out_finish, at dwarf2out.c:18906" with -g option

[jianjun.he at spreadtrum dot com]

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



--- Comment #1 from Jianjun He  2013-02-07 
03:28:41 UTC ---

Created attachment 29380

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

the preprocessed file that triggers the bug



the preprocessed file is tar'ed 'cause the size is out of attachment limit.

[Bug c/56234] New: Get "internal compiler error in dwarf2out_finish, at dwarf2out.c:18906" with -g option

[jianjun.he at spreadtrum dot com]

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



 Bug #: 56234

   Summary: Get "internal compiler error in dwarf2out_finish, at

dwarf2out.c:18906" with -g option

Classification: Unclassified

   Product: gcc

   Version: 4.4.3

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c

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

ReportedBy: jianjun...@spreadtrum.com





the exact version of GCC & the options given when GCC was configured/built:



$ ./arm-eabi-gcc -v

Using built-in specs.

Target: arm-eabi

Configured with:

/home/jingyu/projects/gcc/android-toolchainsrc/build/../gcc/gcc-4.4.3/configure

--prefix=/usr/local --target=arm-eabi --host=x86_64-linux-gnu

--build=x86_64-linux-gnu --with-gnu-as --with-gnu-ld --enable-languages=c,c++

--with-gmp=/home/jingyu/projects/gcc/toolchain_build/obj/temp-install

--with-mpfr=/home/jingyu/projects/gcc/toolchain_build/obj/temp-install

--disable-libssp --enable-threads --disable-nls --disable-libmudflap

--disable-libgomp --disable-libstdc__-v3 --disable-sjlj-exceptions

--disable-shared --disable-tls --with-float=soft --with-fpu=vfp

--with-arch=armv5te --enable-target-optspace --with-abi=aapcs

--with-gcc-version=4.4.3 --with-binutils-version=2.19 --with-gmp-version=4.2.4

--with-mpfr-version=2.4.1 --with-gdb-version=7.1.x --with-arch=armv5te

--with-multilib-list=mandroid

--with-sysroot=/usr/local/google/home/android/cupcake_rel_root

--program-transform-name='s&^&arm-eabi-&'

Thread model: single

gcc version 4.4.3 (GCC) 





the system type:



$ uname -a

Linux spreadtrum 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 17:58:38 UTC 2012

x86_64 x86_64 x86_64 GNU/Linux





the complete command line that triggers the bug:

$ arm-eabi-gcc -Wp,-MD,drivers/usb/gadget/.android.o.d  -nostdinc -isystem

/home/apuser/code/sprdroid4.1_3.4/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/../lib/gcc/arm-eabi/4.6.x-google/include

-I/home/apuser/code/sprdroid4.1_3.4/kernel/arch/arm/include

-Iarch/arm/include/generated -Iinclude 

-I/home/apuser/code/sprdroid4.1_3.4/kernel/include -include

/home/apuser/code/sprdroid4.1_3.4/kernel/include/linux/kconfig.h 

-I/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget

-Idrivers/usb/gadget -D__KERNEL__ -mlittle-endian  

-I/home/apuser/code/sprdroid4.1_3.4/kernel/arch/arm/mach-sc/include -Wall

-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common

-Werror-implicit-function-declaration -Wno-format-security

-fno-delete-null-pointer-checks -Os -marm -fno-dwarf2-cfi-asm

-fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux

-mno-thumb-interwork -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm

-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable

-fno-omit-frame-pointer -fno-optimize-sibling-calls -g

-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow

-fconserve-stack-D"KBUILD_STR(s)=\#s"

-D"KBUILD_BASENAME=KBUILD_STR(android)" 

-D"KBUILD_MODNAME=KBUILD_STR(g_android)" -c -o

drivers/usb/gadget/.tmp_android.o

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c





the compiler output (error messages, warnings, etc.):



  CC  drivers/usb/gadget/android.o

In file included from

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c:49:

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/u_serial.c:141:1:

warning: "pr_vdebug" redefined

In file included from

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c:46:

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/f_fs.c:40:1:

warning: this is the location of the previous definition

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c: In

function 'mass_storage_support_luns_store':

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c:905:

warning: comparison between pointer and integer

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c: At top

level:

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c:1311:

warning: function declaration isn't a prototype

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c:545:

warning: 'acm_function' defined but not used

/home/apuser/code/sprdroid4.1_3.4/kernel/drivers/usb/gadget/android.c:1684:

internal compiler error: in dwarf2out_finish, at dwarf2out.c:18906

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug web/56233] Bugzilla: files (*.c, *.diff, etc.) wrongly recognized as application/octet-stream

[pinskia at gcc dot gnu.org]

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



--- Comment #2 from Andrew Pinski  2013-02-07 
02:53:28 UTC ---

>bugzilla treats attached files as binary 

No what is happening is your browser is sending this mime type when it did the

upload.  There is not much bugzilla can do.

[Bug web/56233] Bugzilla: files (*.c, *.diff, etc.) wrongly recognized as application/octet-stream

[d.g.gorbachev at gmail dot com]

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



--- Comment #1 from Dmitry Gorbachev  
2013-02-07 02:49:14 UTC ---

Created attachment 29379

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

"Create New Attachment" form

[Bug web/56233] New: Bugzilla: files (*.c, *.diff, etc.) wrongly recognized as application/octet-stream

[d.g.gorbachev at gmail dot com]

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



 Bug #: 56233

   Summary: Bugzilla: files (*.c, *.diff, etc.) wrongly recognized

as application/octet-stream

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: web

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

ReportedBy: d.g.gorbac...@gmail.com





Created attachment 29378

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

"Enter Bug" form



When filing a new bug report, bugzilla treats attached files as binary rather

then text/plain (making them more difficult to view). Unfortunately, it doesn't

allow to choose the content type manually (it only works when javascript

support is turned off in a browser, or when adding an attachment to already

existing bug report).

[Bug target/54009] incorrect code generated for DFmode lo_sum mem

[amodra at gmail dot com]

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



Alan Modra  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Alan Modra  2013-02-07 02:46:30 
UTC ---

Fixed.

[Bug target/54009] incorrect code generated for DFmode lo_sum mem

[amodra at gcc dot gnu.org]

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



--- Comment #5 from Alan Modra  2013-02-07 02:37:49 
UTC ---

Author: amodra

Date: Thu Feb  7 02:37:37 2013

New Revision: 195836



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

Log:

gcc/

PR target/54009

* config/rs6000/rs6000.c (mem_operand_gpr): Check that LO_SUM

addresses won't wrap when offsetting.

(rs6000_secondary_reload): Provide secondary reloads needed for

wrapping LO_SUM addresses.



gcc/testsuite/

PR target/54009

* gcc.target/powerpc/pr54009.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/powerpc/pr54009.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/rs6000/rs6000.c

trunk/gcc/testsuite/ChangeLog

[Bug target/54131] [4.8 Regression] ICE building 416.gamess, reload_cse_simplify_operands

[amodra at gcc dot gnu.org]

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



--- Comment #5 from Alan Modra  2013-02-07 02:27:06 
UTC ---

Author: amodra

Date: Thu Feb  7 02:26:53 2013

New Revision: 195835



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

Log:

PR target/54131

* gfortran.dg/pr54131.f: New test.





Added:

trunk/gcc/testsuite/gfortran.dg/pr54131.f

Modified:

trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[joseph at codesourcery dot com]

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



--- Comment #8 from joseph at codesourcery dot com  2013-02-07 01:48:56 UTC ---

On Wed, 6 Feb 2013, ubizjak at gmail dot com wrote:



> > The full line is,

> > internal_error ("resolution sub id " HOST_WIDE_INT_PRINT_HEX_PURE

> > " not in object file", id);

> > 

> > Given that it's an internal error, I'm going to do a workaround so it will

> > still build for me.

> 

> I don't see anything wrong with the above HOST_WIDE_INT_PRINT_HEX_PURE

> definition. Does this hints and some MinGW specific problem in type checking?



internal_error takes GCC formats, not printf formats.  

HOST_WIDE_INT_PRINT_HEX_PURE is a printf format and may not be valid for 

direct use in GCC diagnostic functions.  You need to use a GCC format such 

as %wx here.

[Bug target/44364] Wrong code with e500 double floating point

[amodra at gmail dot com]

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



Alan Modra  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #50 from Alan Modra  2013-02-07 01:44:07 
UTC ---

Fixed all currently active branches.

[Bug c/47409] volatile struct member bug

[joseph at codesourcery dot com]

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



--- Comment #15 from joseph at codesourcery dot com  2013-02-07 01:42:21 UTC ---

I think the most obvious way to handle volatile and unions for C would be 

to follow the handling of const (set C_TYPE_FIELDS_VOLATILE in the same 

way as C_TYPE_FIELDS_READONLY - that is, checking for fields whose types 

have C_TYPE_FIELDS_VOLATILE rather than just fields that are directly 

volatile - and use it to determine whether the struct or union is at 

least in part volatile for assignment).  Though for unions the best you 

can do might be a copying loop; without knowing the active union member 

you can hardly respect access sizes for individual members, even if you 

wanted to.

[Bug target/53040] nested functions may trash floating point registers

[amodra at gcc dot gnu.org]

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



--- Comment #9 from Alan Modra  2013-02-07 01:39:29 
UTC ---

Author: amodra

Date: Thu Feb  7 01:39:21 2013

New Revision: 195834



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

Log:

PR target/53040

* config/rs6000/rs6000.c (rs6000_savres_strategy): When using

static chain, set REST_INLINE_FPRS too.





Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/rs6000/rs6000.c

[Bug lto/47936] [4.6 Regression] Missed optimization with LTO due to strict aliasing issues

[d.g.gorbachev at gmail dot com]

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



Dmitry Gorbachev  changed:



   What|Removed |Added



  Known to work|4.7.0   |4.7.3, 4.8.0

Summary|[4.6/4.7/4.8 Regression]|[4.6 Regression] Missed

   |Missed optimization with|optimization with LTO due

   |LTO due to strict aliasing  |to strict aliasing issues

   |issues  |

  Known to fail|4.6.0   |4.6.4



--- Comment #9 from Dmitry Gorbachev  
2013-02-07 00:40:06 UTC ---

I can't reproduce it with GCC 4.7.3 and 4.8.0.

[Bug lto/56232] New: Missed optimization with LTO

[d.g.gorbachev at gmail dot com]

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



 Bug #: 56232

   Summary: Missed optimization with LTO

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: lto

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

ReportedBy: d.g.gorbac...@gmail.com





Created attachment 29377

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

Compile with -flto -O2



/tmp/cce3xw28.ltrans0.ltrans.o:cce3xw28.ltrans0.o:function main: error:

undefined reference to 'bar'

[Bug lto/47900] Missed optimization with LTO

[d.g.gorbachev at gmail dot com]

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



Dmitry Gorbachev  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||WORKSFORME



--- Comment #4 from Dmitry Gorbachev  
2013-02-07 00:13:03 UTC ---

I can't reproduce it with GCC 4.6.4, 4.7.3, 4.8.0.

[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158

[mikpe at it dot uu.se]

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



--- Comment #17 from Mikael Pettersson  2013-02-06 
23:23:58 UTC ---

Created attachment 29376

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

reduced test case



Please disregard my last two comments, I misread the insn dump and mistook a

note for the invalid concurrent modification of a register.



Thorsten's initial xslt test case, attachment 27325, ICEs 4.6 and 4.7 -with -O2

-fPIC, and 4.8 with just -O2.  This new test case is substantially reduced from

the initial one, but it only ICEs 4.8.  The ICE occurs when cselib processes

insn 67.



IRA produced



(insn 67 66 69 10 (set (reg/f:SI 52 [ D.1521 ])

(mem/f:SI (post_inc:SI (reg:SI 59 [ ivtmp.11 ])) [3 MEM[base: 0B,

index: ivtmp.11_66, offset: 0B]+0 S4 A16])) pr52306-4.c:44 38 {*movsi_m68k2}

 (expr_list:REG_INC (reg:SI 59 [ ivtmp.11 ])

(nil)))



with, if I read the dump correctly, reg 52 mapped to %a1 and reg 59 spilled.



Reload then sees fit to reload reg 59 into %a1, resulting in



(insn 67 253 69 10 (set (reg:SI 9 %a1)

(mem/f:SI (post_inc:SI (reg:SI 9 %a1)) [3 MEM[base: 0B, index:

ivtmp.11_66, offset: 0B]+0 S4 A16])) pr52306-4.c:44 38 {*movsi_m68k2}

 (expr_list:REG_INC (reg:SI 9 %a1)

(nil)))



which uses %a1 both as an auto-inc source pointer and as the dest of the load,

causing the assertion failure in cselib.



The post_inc of reg 59 (%a1) is actually dead, reload added insns to load %a1

from reg 59's spill slot and to increment that memory cell directly.  I'm

guessing either reload should not have coalesced reg 59 with reg 52 (due to the

post_inc on reg 59), or it should have cancelled the post_inc when it added the

new insn to increment the spill slot directly.

[Bug c++/56230] gcc aborts with "uninitialized const member" error even though an initializer is present

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #2 from Jonathan Wakely  2013-02-06 
22:48:21 UTC ---

Yes, fails with 4.5, 4.5 and 4.6 but already fixed.

[Bug go/56172] net FAILs on Solaris

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Ian Lance Taylor  2013-02-06 22:41:54 
UTC ---

The patch to mheap.c should fix this segmentation violation.



As expected, there was another underlying problem, which should be fixed by the

patch to the net package.

[Bug go/56172] net FAILs on Solaris

[ian at gcc dot gnu.org]

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



--- Comment #4 from ian at gcc dot gnu.org  2013-02-06 
22:40:26 UTC ---

Author: ian

Date: Wed Feb  6 22:40:18 2013

New Revision: 195823



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

Log:

PR go/56172

net: Fixes for select based pollster.



Make Close work properly, mainly for testing.  Restart the

select if a descriptor is closed.



Modified:

trunk/libgo/go/net/fd_bsd.go

trunk/libgo/go/net/fd_linux.go

trunk/libgo/go/net/fd_select.go

trunk/libgo/go/net/fd_unix.go

[Bug target/53040] nested functions may trash floating point registers

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 CC||dje at gcc dot gnu.org



--- Comment #8 from David Edelsohn  2013-02-06 22:25:21 
UTC ---

Go ahead and backport it to 4.7 branch.

[Bug middle-end/56231] New: warning traces have bogus line information when using LTO

[matt at use dot net]

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



 Bug #: 56231

   Summary: warning traces have bogus line information when using

LTO

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: middle-end

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

ReportedBy: m...@use.net





>From bootstrapping GCC itself, one gets warnings that have bogus line entries,

like the ":61:" line below:

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add':

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used

uninitialized in this function [-Werror=maybe-uninitialized]





On large LTO compilation units, the final link can include some of these kinds

of warnings that contain literally hundreds of ":0:" and ":N:" entries per

warning.



To reproduce the above issue, bootstrap trunk like so:

../gcc-trunk/configure --program-suffix=-4.8 --enable-languages=c,c++,lto

--prefix=/u/mhargett --with-build-config=bootstrap-lto --enable-lto

--with-fpmath=sse --disable-isl-version-check --disable-libmudflap

--disable-libssp --enable-gold=yes --disable-multilib --disable-nls

BOOT_CFLAGS="-O3 -floop-block -floop-interchange -floop-strip-mine

-march=nocona =mtune=core2" CFLAGS_FOR_BUILD="-O3 -floop-block

-floop-strip-mine -floop-interchange -march=nocona -mtune=core2"

CXXFLAGS_FOR_BUILD="-O3 -floop-block -floop-interchange -floop-strip-mine

-march=nocona -mtune=core2"



make



more complete output from the bootstrap that illustrates this bug:

/work/mhargett/gcc-trunk-obj/./prev-gcc/xg++

-B/work/mhargett/gcc-trunk-obj/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange

-floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions

-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings

-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov.o libcommon.a

../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -o gcov

/work/mhargett/gcc-trunk-obj/./prev-gcc/xg++

-B/work/mhargett/gcc-trunk-obj/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange

-floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions

-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings

-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov-dump.o \

libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -o gcov-dump

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add':

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

  ^

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared

here

   struct backtrace_view ehdr_view;

 ^

In file i

[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[vmakarov at gcc dot gnu.org]

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



--- Comment #27 from Vladimir Makarov  2013-02-06 
21:36:59 UTC ---

(In reply to comment #26)

> You are right, your suggestions is what I sketched in comment #21 as choices 1

> or 2.  Sorry for my unclear expalanation of what was actually happening.

> 

> I don't have a problem with making sel-sched have extra checks when renaming

> registers before reload, which will make us notice a not obvious extra

> dependence and avoid renaming properly, as now we've figured out these

> dependences don't follow immediately from the RTL.  I just want an extra

> opinion on whether such unexpected dependencies arising when a target (hard)

> register is replaced by a pseudo register should be normal within GCC, or do 
> we

> attribute such dependencies only to the register pressure scheduling mode. 

> FWIW, I would rather agree with the latter than with the former.



I guess you can not fully assume that dependencies are created only from RTL

data flow.  There are cases (besides pressure sensitive scheduling case

mentioned here) when dependencies are still created for other reasons different

from RTL data flow.  I'd look at the dependencies as constraints resulting in

correct and *desirable* insn schedule.  Although overwhelming majority of them

are created from RTL data flow analysis.

[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 CC||matz at gcc dot gnu.org,

   ||sebpop at gmail dot com



--- Comment #10 from Aldy Hernandez  2013-02-06 
21:08:02 UTC ---

This regression started when we moved graphite from using PPL over to ISL.  The

patch submission started here:



http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html



2012-07-02  Richard Guenther  

Michael Matz  

Tobias Grosser 

Sebastian Pop 



and the revision is trunk@189156.



Provided this test gets further reduced as I have mentioned in comment 9, can

any of you gentlemen look at this?

[Bug fortran/56224] [4.8 Regression] gfortran -fopenmp cannot find omp_lib.h

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-02-06 
20:58:07 UTC ---

omp_lib.h is either being included through

INCLUDE 'omp_lib.h"

or

#include "omp_lib.h"

As it is a Fortran source, not a C/C++ header, putting it into include/ looks

wrong.

[Bug fortran/56224] [4.8 Regression] gfortran -fopenmp cannot find omp_lib.h

[tkoenig at gcc dot gnu.org]

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



--- Comment #2 from Thomas Koenig  2013-02-06 
20:55:13 UTC ---

I think the file should go into an include directory.

[Bug c++/56217] ICE: OpenMP: when combining shared() and a move constructor

[radford at blackbean dot org]

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



--- Comment #4 from Jim Radford  2013-02-06 
20:46:42 UTC ---

(In reply to comment #3)

> Should be fixed on the trunk



Thanks!



> Note your testcase is invalid, without

> the taskwait I've added, it relies on NRV and even with NRV, by the time the

> task can run the temporary result of f() can be destructed already.



I had the taskwait in my original.  Still, thanks for the explanation; it adds

to my nascent mental model of openmp.  Maybe one day I'll get something to

compile so I can try it out, but first I'm off to compile gcc!

[Bug fortran/55789] [4.6/4.7 Regression] Needless realloc with array constructor.

[pault at gcc dot gnu.org]

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



Paul Thomas  changed:



   What|Removed |Added



Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression]

   |Needless realloc with array |Needless realloc with array

   |constructor.|constructor.



--- Comment #10 from Paul Thomas  2013-02-06 20:29:13 
UTC ---

Fixed on trunk.



I will have to do a bit more work to determine if the same fix works correctly

for 4.6 and 4.7.



Paul

[Bug fortran/55789] [4.6/4.7/4.8 Regression] Needless realloc with array constructor.

[pault at gcc dot gnu.org]

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



--- Comment #9 from Paul Thomas  2013-02-06 20:20:24 
UTC ---

Author: pault

Date: Wed Feb  6 20:20:08 2013

New Revision: 195815



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

Log:

2013-02-06 Paul Thomas  



PR fortran/55789

* trans-array.c (trans_array_constructor): Remove condition

'dynamic' = true if the loop ubound is a VAR_DECL.



2013-02-06 Paul Thomas  



PR fortran/55789

* gfortran.dg/array_constructor_41.f90: New test.



Added:

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

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/trans-array.c

trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[craig.powers at gmail dot com]

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



--- Comment #7 from Craig Powers  2013-02-06 
20:19:15 UTC ---

(In reply to comment #6)

> (In reply to comment #5)

> > ../../gcc-4.8-20130203/gcc/lto/lto.c: In function 'void

> > lto_resolution_read(spla

> > y_tree, FILE*, lto_file*)':

> > ../../gcc-4.8-20130203/gcc/lto/lto.c:2229:33: error: unknown conversion type

> > cha

> > racter 'I' in format [-Werror=format=]

> > " not in object file", id);

> >  ^

> > 

> > The full line is,

> > internal_error ("resolution sub id " HOST_WIDE_INT_PRINT_HEX_PURE

> > " not in object file", id);

> > 

> > Given that it's an internal error, I'm going to do a workaround so it will

> > still build for me.

> 

> I don't see anything wrong with the above HOST_WIDE_INT_PRINT_HEX_PURE

> definition. Does this hints and some MinGW specific problem in type checking?

> 

> (I don't have access to MinGW platform, someone else should look a this

> problem.)



I have no idea, personally.  I'm willing to try out proposed fixes for any

issues, as long as I can run it in the background and not eat up time I should

be spending getting other work done.

[Bug fortran/55978] class_optional_2.f90 -Os fails

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|NEW

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

   ||gnu.org

Summary|[4.8 Regression]|class_optional_2.f90 -Os

   |class_optional_2.f90 -Os|fails

   |fails   |



--- Comment #24 from janus at gcc dot gnu.org 2013-02-06 19:51:08 UTC ---

The failures of class_optional_2.f90 should be fixed with r195814.



I'm removing the regression tag, but will leave open the PR, in order to track

the remaining issues:

 * check the things mentioned in comment 15

 * the NULL case in comment 16 is rejected

 * comment 17

 * comment 19

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[ubizjak at gmail dot com]

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



--- Comment #6 from Uros Bizjak  2013-02-06 19:40:33 
UTC ---

(In reply to comment #5)

> ../../gcc-4.8-20130203/gcc/lto/lto.c: In function 'void

> lto_resolution_read(spla

> y_tree, FILE*, lto_file*)':

> ../../gcc-4.8-20130203/gcc/lto/lto.c:2229:33: error: unknown conversion type

> cha

> racter 'I' in format [-Werror=format=]

> " not in object file", id);

>  ^

> 

> The full line is,

> internal_error ("resolution sub id " HOST_WIDE_INT_PRINT_HEX_PURE

> " not in object file", id);

> 

> Given that it's an internal error, I'm going to do a workaround so it will

> still build for me.



I don't see anything wrong with the above HOST_WIDE_INT_PRINT_HEX_PURE

definition. Does this hints and some MinGW specific problem in type checking?



(I don't have access to MinGW platform, someone else should look a this

problem.)

[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2

[uweigand at gcc dot gnu.org]

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



Ulrich Weigand  changed:



   What|Removed |Added



 CC||vmakarov at gcc dot gnu.org



--- Comment #6 from Ulrich Weigand  2013-02-06 
19:40:30 UTC ---

The problem occurs with the following insn:



(insn 539 383 384 46

 (set (reg:DI 355 [313]) (const_int 256 [0x100]))

 test.ii:128 643 {*movdi_vfp}

 (expr_list:REG_EQUIV (const_int 256 [0x100])

 (nil)))



Register 355 is recognized as always-equal to the constant 256, and insn 539 is

the insn that originally sets up the equivalence.  If the register doesn't get

a hard reg, what ought to happen is that users of reg 355 get replaced by the

constant, and the insn setting the equivalence ought to be deleted.  Because

the insn will get deleted anyway, it also ought to be skipped for find_reloads.



To achieve that, reg_equiv_constant(355) should hold the constant, and

reg_equiv_init(355) should point to the above insn.  However, what actually

happens in this test case is that reg_equiv_init(355) is NULL.  Therefore, the

insn is *not* skipped for find_reloads, which then aborts since it tries to

push an output reload for an always-constant register, which is not supposed to

happen.



Now the register is somewhat special in that it was created by IRA via live

range splitting.  The original register was reg 313; and this still has

reg_equiv_init(313) pointing to the above insn.  However, reg_equiv_init(355)

is NULL.  There is a routine fix_reg_equiv_init in ira.c which appears to be

intended to fix the reg_equiv_init settings of new registers created by live

range splitting.  However, this doesn't seem to have worked in this case ...



Unfortunately I'm not really familiar with the live range splitting code; maybe

Vladimir can help with this?

[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails

[janus at gcc dot gnu.org]

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



--- Comment #23 from janus at gcc dot gnu.org 2013-02-06 19:39:43 UTC ---

Author: janus

Date: Wed Feb  6 19:39:35 2013

New Revision: 195814



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

Log:

2013-02-06  Janus Weil  



PR fortran/55978

* runtime/in_pack_generic.c (internal_pack): Return if base_addr is

NULL.



2013-02-06  Janus Weil  



PR fortran/55978

* gfortran.dg/class_optional_2.f90: Uncomment some cases which work now.



Modified:

trunk/gcc/testsuite/ChangeLog

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

trunk/libgfortran/ChangeLog

trunk/libgfortran/runtime/in_pack_generic.c

[Bug c++/56230] gcc aborts with "uninitialized const member" error even though an initializer is present

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  
2013-02-06 19:35:15 UTC ---
The problem seems to be fixed in 4.7.2 and in 4.8.0 trunk.

[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2

[uweigand at gcc dot gnu.org]

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



--- Comment #5 from Ulrich Weigand  2013-02-06 
19:27:31 UTC ---

Depending on configure tests of the installed (cross-)assembler, the ICE may

not occur.  In those cases, I'm now able to reliably reproduce the ICE by using

-fno-section-anchors (in addition to the flags given above).

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[craig.powers at gmail dot com]

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



--- Comment #5 from Craig Powers  2013-02-06 
19:03:10 UTC ---

../../gcc-4.8-20130203/gcc/lto/lto.c: In function 'void

lto_resolution_read(spla

y_tree, FILE*, lto_file*)':

../../gcc-4.8-20130203/gcc/lto/lto.c:2229:33: error: unknown conversion type

cha

racter 'I' in format [-Werror=format=]

" not in object file", id);

 ^



The full line is,

internal_error ("resolution sub id " HOST_WIDE_INT_PRINT_HEX_PURE

" not in object file", id);



Given that it's an internal error, I'm going to do a workaround so it will

still build for me.

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

[dominiq at lps dot ens.fr]

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



--- Comment #77 from Dominique d'Humieres  
2013-02-06 19:02:27 UTC ---

> Created attachment 29361 [details]

> Patch to suppress register swap on Darwin >= 12, v2



With this patch applied on top of r195808 for



Target: x86_64-apple-darwin10.8.0



Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.8p-195808p1

--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp

--with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto

--enable-plugin --enable-build-with-cxx



make -k check-ada RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"

gives



=== acats Summary ===

# of expected passes2320

# of unexpected failures0



=== gnat Summary for unix/-m64 ===



# of expected passes1159

# of expected failures17

# of unsupported tests4



=== gnat Summary ===



# of expected passes2318

# of expected failures34

# of unsupported tests8

[Bug c++/56230] New: gcc aborts with "uninitialized const member" error even though an initializer is present

[pavelo at conky dot be]

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



 Bug #: 56230

   Summary: gcc aborts with "uninitialized const member" error

even though an initializer is present

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: pav...@conky.be





Created attachment 29375

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

the bug



while compiling the attached file I get the following error:

$ g++ -std=c++0x a.cc

a.cc: In constructor 'A::A(Keys ...) [with Keys = {}]':

a.cc:25:9:   instantiated from here

a.cc:15:5: error: uninitialized member 'A<>::tuple' with 'const' type 'const

Tuple {aka const atuple<>}' [-fpermissive]



In my opinion, this is wrong, since I class A explicitly calls the tuple

constructor, which should be synthesized by the compiler.



I have several observations about this code:

- the error does not occur if I remove the atuple<> specialization, or I

provide a hand written default constructor.

- it does, however, occur if I specify the constructor as "= default;"

- it does not occur if I call atuple<> constructor directly (see class B).

There has to be another template somewhere.

- I noticed this bug because I had this error when using std::tuple, which

provides an explicit specialization for the empty tuple and this specialization

has no explicit constructors.



$ gcc -v

Using built-in specs.

COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper

Target: x86_64-pc-linux-gnu

Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure

--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3

--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include

--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3

--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man

--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info

--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4

--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec

--disable-fixed-point --without-ppl --without-cloog --enable-lto --disable-nls

--with-system-zlib --enable-obsolete --disable-werror --enable-secureplt

--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp

--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python

--enable-checking=release --enable-java-awt=gtk --enable-libstdcxx-time

--enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix

--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all

--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.11,

pie-0.5.2'

Thread model: posix

gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2) 





If you need any further information, I will be happy to provide it.

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[craig.powers at gmail dot com]

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



--- Comment #4 from Craig Powers  2013-02-06 
18:54:39 UTC ---

(In reply to comment #3)

> There's another one on line 14622 of gcc/config/i386/i386.c.



Doing the same substitution as in ggc-page.c fixes it.

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[craig.powers at gmail dot com]

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



--- Comment #3 from Craig Powers  2013-02-06 
18:50:34 UTC ---

There's another one on line 14622 of gcc/config/i386/i386.c.

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[dcb314 at hotmail dot com]

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



--- Comment #11 from David Binderman  2013-02-06 
18:47:37 UTC ---

>It isn't that easy.  For %'s you really have to parse all the characters after

>% and figure out where the format specifier ends.



Agreed. But it doesn't have to be perfect, it just has to be

better than the previous solution. This is only a warning we are discussing.

It can be ignored. 



The Werror folks are, IMHO, far too keen for their own good.



I wrote:

>All the numeric specifiers (%d, %u etc) all produce at least one 

>character, so gcc could take account of this in checking buffer lengths.



In computing a lower bound, all % specifiers could be assumed to 

produce at least one byte of output.



Parsing the % specifier doesn't have to be perfect, it just has

to understand the common cases (%s, %d, %u etc) and punt on the rest.



More understanding can be added in later versions.

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[craig.powers at gmail dot com]

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



--- Comment #2 from Craig Powers  2013-02-06 
18:42:58 UTC ---

(In reply to comment #1)

> Created attachment 29374 [details]

> proposed patch to use HOST_LONG_LONG_FORMAT

> 

> Please try to bootstrap with the attached patch.



That fixes the error I had, thanks!



It's still going right now, I'll add another update when it's done.

[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs

[jason at gcc dot gnu.org]

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



--- Comment #6 from Jason Merrill  2013-02-06 
18:26:37 UTC ---

OK.

[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|NEW |WAITING



--- Comment #9 from Aldy Hernandez  2013-02-06 
18:18:54 UTC ---

I'm sorry, but the reporter is going to have to reduce this significantly

before we can debug this.  This is a huge mess of spaghetti code with tons of

global and common variables scattered throughout, as well as state being passed

around in files.



Dominique, please reduce this to the smallest amount of reproducible code, so

we can attack this.  Avoid reading and writing to files (as I see, these have

only a minimal amount of data anyhow), and global variables if at all possible.



Please only keep the code that is relevant to reproduce the problem.

[Bug target/56228] [4.8 Regression] Indirect call fails to assemble

[dje at gcc dot gnu.org]

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



--- Comment #2 from David Edelsohn  2013-02-06 18:15:17 
UTC ---

The proposed patch LGTM.

[Bug fortran/56224] [4.8 Regression] gfortran -fopenmp cannot find omp_lib.h

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
   Last reconfirmed||2013-02-06
 CC||burnus at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|gfortran -fopenmp cannot|[4.8 Regression] gfortran
   |find omp_lib.h  |-fopenmp cannot find
   ||omp_lib.h
   Target Milestone|--- |4.8.0

--- Comment #1 from Tobias Burnus  2013-02-06 
18:01:36 UTC ---
Seems to be caused by the following patch:

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

+2012-08-02  Thomas König  
+
+PR fortran/54033
...
+* optinons.c (gfc_handle_option):  Do not add directory
+for intrinsic modules to normal include path.

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2013-02-06 
17:42:04 UTC ---

I don't think that the implementation of UNION/MAP will happen soon, given that

it is not a simple feature and most effort concentrates on supporting the

Fortran standard. However, if someone volunteers to work on this, it might

happen sooner.



For documentation, see:

-

http://publib.boulder.ibm.com/infocenter/comphelp/v101v121/topic/com.ibm.xlf121.aix.doc/language_ref/unionmap.html

-

http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/fortran-mac/GUID-1CC04793-AF79-4E0F-AC78-DD4CF985C23F.htm

[Bug rtl-optimization/56178] [4.8 Regression] Miscompilation of Ada front-end with profiled bootstrap

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



  Component|ada |rtl-optimization



--- Comment #5 from Eric Botcazou  2013-02-06 
17:24:45 UTC ---

I confirm that fixing the ureal.adb miscompilation fixes the ACATS failures.

[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target

[rai...@emrich-ebersheim.de]

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



--- Comment #10 from Rainer Emrich  2013-02-06 
17:20:53 UTC ---

-BEGIN PGP SIGNED MESSAGE-

Hash: SHA1



Am 06.02.2013 18:04, schrieb daniel.f.starke at freenet dot de:

> 

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

> 

> --- Comment #9 from Daniel Starke 

> 2013-02-06 17:04:21 UTC --- This will probably not fix all problems with

> ada on mingw.

Ah, I see. I missed this one because I only test for x86_64 and this one is in

the i386 path.



That's a problem in trunk and 4.7.3. I will prepare an additional patch for

trunk. Afterwards I will backport the whole mess to 4.7.3.

If you are able to test on 32 bit mingw system, I would like to send you the

patch for testing.





> My last tests with 4.7.2 made me also need to patch this:

> 

> diff -uart gcc-4.7.2-original/gcc/ada/tracebak.c

> gcc-4.7.2/gcc/ada/tracebak.c --- gcc-4.7.2-original/gcc/ada/tracebak.c

> 2011-10-24 10:31:30 + +++ gcc-4.7.2/gcc/ada/tracebak.c2012-09-23

> 15:26:50 + @@ -326,7 +326,7 @@

> 

> #if defined (__WIN32) #include  -#define IS_BAD_PTR(ptr)

> (IsBadCodePtr((void *)ptr)) +#define IS_BAD_PTR(ptr)

> (IsBadCodePtr((FARPROC)ptr)) #elif defined (sun) #define IS_BAD_PTR(ptr)

> ((unsigned long)ptr == -1UL) #else

> 



-BEGIN PGP SIGNATURE-

Version: GnuPG v1.4.10 (MingW32)

Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/



iQEcBAEBAgAGBQJREpDZAAoJEB3HOsWs+KJbFpMH/3soc7VszmDTzIMILkxSQARC

5kP/1clKrAmWjlIRSdt6CUjTDEmKrPGiWtmxqA9cuLq2AWkT1d2qycLNMq7cIeV5

4KNsMtqIKLfpFj7rw7n8gK8rCxMgUfXi+vBqFJtsGO1pBXtTZDgNsTlg5jqqUeeT

3744GGduKB702YbCsQYyiqjWffJeWcCYfMqHjZdu2xQNHhL69EX8GzAcZp1cHQJj

kPjfwPU2aaNYKD9H2DdhJ8S6Y8YWNg7UrYCUNY1ySKMeIx9OFamCHSUzZDC8e4kq

L4XKqIpZFz6Ys9qJDfv5o47lIoWmERy1aGH54fG2sX/xDdpHOv6q60vdGFCSDU4=

=W5RJ

-END PGP SIGNATURE-

[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target

[daniel.f.starke at freenet dot de]

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



--- Comment #9 from Daniel Starke  
2013-02-06 17:04:21 UTC ---

This will probably not fix all problems with ada on mingw.

My last tests with 4.7.2 made me also need to patch this:



diff -uart gcc-4.7.2-original/gcc/ada/tracebak.c gcc-4.7.2/gcc/ada/tracebak.c

--- gcc-4.7.2-original/gcc/ada/tracebak.c2011-10-24 10:31:30 +

+++ gcc-4.7.2/gcc/ada/tracebak.c2012-09-23 15:26:50 +

@@ -326,7 +326,7 @@



 #if defined (__WIN32)

 #include 

-#define IS_BAD_PTR(ptr) (IsBadCodePtr((void *)ptr))

+#define IS_BAD_PTR(ptr) (IsBadCodePtr((FARPROC)ptr))

 #elif defined (sun)

 #define IS_BAD_PTR(ptr) ((unsigned long)ptr == -1UL)

 #else

[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c

[ubizjak at gmail dot com]

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



--- Comment #1 from Uros Bizjak  2013-02-06 16:54:49 
UTC ---

Created attachment 29374

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

proposed patch to use HOST_LONG_LONG_FORMAT



Please try to bootstrap with the attached patch.

[Bug target/56228] [4.8 Regression] Indirect call fails to assemble

[jakub at gcc dot gnu.org]

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



--- Comment #1 from Jakub Jelinek  2013-02-06 
16:52:56 UTC ---

Created attachment 29373

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

gcc48-pr56228.patch



Untested fix.

[Bug target/56228] [4.8 Regression] Indirect call fails to assemble

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-06

 CC||dje at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1

[Bug target/53040] nested functions may trash floating point registers

[ebotcazou at gcc dot gnu.org]

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



--- Comment #7 from Eric Botcazou  2013-02-06 
16:45:44 UTC ---

> This one is hardly an annoying bug.  You need

> a) nested functions,

> b) using floating point,

> c) with an unusual set of callee saved fprs,

> d) and -Os.



a) + b) + d) is pretty much standard e.g. for embedded Ada on PowerPC/VxWorks.



> OTOH, the patch is quite obvious and completely safe..



Then I think it's a good candidate for a backport onto the 4.7 branch.

[Bug target/56228] New: [4.8 Regression] Indirect call fails to assemble

[jakub at gcc dot gnu.org]

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



 Bug #: 56228

   Summary: [4.8 Regression] Indirect call fails to assemble

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: ja...@gcc.gnu.org

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

Target: powerpc64-linux





short a[14] = { 1, 2 };

short b[15] = { 3, 4 };



int

foo ()

{

  void (*fna) (void) = (void (*) (void)) a;

  void (*fnb) (void) = (void (*) (void)) b;

  fna ();

  fnb ();

  return a[1] == b[1];

}



fails on ppc64, because call_indirect_aix64bit pattern uses "m" constraint for

64-bit loads instead of "Y" constraint.

[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h

[paolo.carlini at oracle dot com]

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



--- Comment #6 from Paolo Carlini  2013-02-06 
16:40:09 UTC ---

Oh, I was missing that, thanks. Now, I don't know if we should really try to

fix this now after so many years. I'm tempted to just leave it alone until we

break the ABI, unless we are really sure that the value returned by the amended

operator can intetoperate with old code and viceversa. Do you jnow in practice

which values the current operator is returning for GCC?

[Bug target/56214] [4.8 Regression] FAIL: gcc.c-torture/execute/20050121-1.c compilation, ICE

[danglin at gcc dot gnu.org]

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



John David Anglin  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-06

  Component|middle-end  |target

 Ever Confirmed|0   |1



--- Comment #1 from John David Anglin  2013-02-06 
16:40:02 UTC ---

Testing fix.

[Bug bootstrap/56227] New: Bootstrap failure on MinGW building ggc-page.c

[craig.powers at gmail dot com]

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



 Bug #: 56227

   Summary: Bootstrap failure on MinGW building ggc-page.c

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

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

ReportedBy: craig.pow...@gmail.com





Bootstrap is failing in stage 3 with the following error:

../../gcc-4.8-20130203/gcc/ggc-page.c: In function 'void

ggc_print_statistics()'

:

../../gcc-4.8-20130203/gcc/ggc-page.c:2174:31: error: unknown conversion type

ch

aracter 'l' in format [-Werror=format=]

 G.stats.total_overhead);

   ^

../../gcc-4.8-20130203/gcc/ggc-page.c:2174:31: error: too many arguments for

for

mat [-Werror=format-extra-args]



(and several more identical errors on the subsequent lines)





File was attempted to compile as:

/mingw/src/gcc-build/./prev-gcc/xg++ -B/mingw/src/gcc-build/./prev-gcc/

-B/usr/l

ocal/i686-pc-mingw32/bin/ -nostdinc++

-B/mingw/src/gcc-build/prev-i686-pc-mingw3

2/libstdc++-v3/src/.libs

-B/mingw/src/gcc-build/prev-i686-pc-mingw32/libstdc++-v

3/libsupc++/.libs

-I/mingw/src/gcc-build/prev-i686-pc-mingw32/libstdc++-v3/inclu

de/i686-pc-mingw32

-I/mingw/src/gcc-build/prev-i686-pc-mingw32/libstdc++-v3/incl

ude -I/mingw/src/gcc-4.8-20130203/libstdc++-v3/libsupc++

-L/mingw/src/gcc-build/

prev-i686-pc-mingw32/libstdc++-v3/src/.libs

-L/mingw/src/gcc-build/prev-i686-pc-

mingw32/libstdc++-v3/libsupc++/.libs -c   -g -O2 -D__USE_MINGW_ACCESS

-Wno-pedan

tic-ms-format -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti

-fasynchronous-unwin

d-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual

-Wmissing-format-at

tribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings

-W

error   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.8-20130203/gcc

-I../../gcc-4.8-201

30203/gcc/. -I../../gcc-4.8-20130203/gcc/../include

-I../../gcc-4.8-20130203/gcc

/../libcpp/include -I/mingw/src/gcc-build/./gmp

-I/mingw/src/gcc-4.8-20130203/gm

p -I/mingw/src/gcc-build/./mpfr -I/mingw/src/gcc-4.8-20130203/mpfr

-I/mingw/src/

gcc-4.8-20130203/mpc/src  -I../../gcc-4.8-20130203/gcc/../libdecnumber

-I../../g

cc-4.8-20130203/gcc/../libdecnumber/bid -I../libdecnumber

-I../../gcc-4.8-201302

03/gcc/../libbacktrace../../gcc-4.8-20130203/gcc/ggc-page.c -o ggc-page.o



Operating system is Windows 7 / x64.  System compiler is gcc 4.7.2, target

mingw32.



prev-gcc/xg++ version is,

$ ./prev-gcc/xg++ -v

Using built-in specs.

COLLECT_GCC=C:\MinGW\src\gcc-build\prev-gcc\xg++.exe

Target: i686-pc-mingw32

Configured with: ../gcc-4.8-20130203/configure --enable-languages=c,fortran,c++

--enable-checking=release

Thread model: win32

gcc version 4.8.0 20130203 (experimental) (GCC)

[Bug fortran/56226] New: Add support for DEC UNION and MAP extensions

[russelljbrennan at gmail dot com]

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



 Bug #: 56226

   Summary: Add support for DEC UNION and MAP extensions

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: fortran

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

ReportedBy: russelljbren...@gmail.com





Porting old f77 code for use with gfortran is fairly straightforward, even for

most extensions.  The UNION and MAP extensions thusfar prove impossible to port

without modifying the UDT interface.  Existing compilers can candle these

extensions (intel ifort and portland group) but there is no open source

alternative available afaik.  UNIONs and MAPs are widely lamented exclusions of

the later fortran standards.  Addition of support for these extensions would

facilitate automated conversion of much existing code to gfortran-compatible

code.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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



--- Comment #12 from Richard Biener  2013-02-06 
16:00:02 UTC ---

(In reply to comment #11)

> Created attachment 29371 [details]

> final patch

> 

> This is what I am considering seriously.  It adds the dumping (but we don't

> have info on the BB index of removed loops - bah), and also moves loop removal

> to fix_loop_structure again.

> 

> It doesn't fix IRAs (pre-existing) ugliness.

> 

> The previous patch passed bootstrap, I'm giving this one full testing

> (it co-incidentially fixes the bug as well).



Fixes it as part of fix_loop_structure as called from VRPs TODO_cleanup_cfg.

This is where a former irreducible region (loop with multiple entries) is

turned into a regular loop.  It's a loop having both loop 2 and loop 3 as

siblings and having loop 1 as parent.

[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2013-02-06 
15:59:51 UTC ---

[dcl.enum]/7 "For an enumeration whose underlying type is fixed, the values of

the enumeration are the values of the underlying type."



Because the underlying type in 17.5.2.1.3 is fixed those operations cannot

create a value outside the range of the enumeration type. See "The underlying

type should be fixed" in

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Attachment #29369|0   |1

is obsolete||



--- Comment #11 from Richard Biener  2013-02-06 
15:54:43 UTC ---

Created attachment 29371

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

final patch



This is what I am considering seriously.  It adds the dumping (but we don't

have info on the BB index of removed loops - bah), and also moves loop removal

to fix_loop_structure again.



It doesn't fix IRAs (pre-existing) ugliness.



The previous patch passed bootstrap, I'm giving this one full testing

(it co-incidentially fixes the bug as well).

[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h

[paolo.carlini at oracle dot com]

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



--- Comment #4 from Paolo Carlini  2013-02-06 
15:29:38 UTC ---

I'm wondering: before doing anything in v3, is this a C++11 issue? Because in

17.5.2.1.3 I see a fixed underlying type but otherwise I see exactly

~static_cast(X) like in v3?!?

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



  Attachment #29366|0   |1

is obsolete||



--- Comment #22 from Dodji Seketeli  2013-02-06 
15:02:44 UTC ---

Created attachment 29370

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

Candidate patch to avoid duplicated intra bb instrumentation



> Trying this patch: 

> % cat inc.cc

> void foo(int *a) {

>   (*a)++;

> }

> % gcc -fsanitize=address -O2 inc.cc -S -o - | grep __asan_report

> call__asan_report_load4

> call__asan_report_store4

> % clang -fsanitize=address -O2 inc.cc -S -o - | grep __asan_report 

> callq   __asan_report_load4

> % 

> 

> Is this test expected to work (have one __asan_error call) with this patch?



The patch indeed (naively) considers read and write accesses as being

different, you are right.  I am attaching a patch that does not, and

that generates just one __asan_report call here.



I'd be nice to know if that makes any change to ...



> First results with the patch (c-only tests, train data):

>  orig  patched

>401.bzip2,89.60,90.10, 1.01

>  429.mcf,23.50,23.90, 1.02

>456.hmmer,   181.00,   145.00, 0.80

>   462.libquantum, 1.64, 1.64, 1.00

>  464.h264ref,   249.00,   249.00, 1.00

> 433.milc,20.10,20.00, 1.00

>  470.lbm,37.20,37.20, 1.00

>  482.sphinx3,17.50,17.50, 1.00

> 

> significant speedup on 456.hmmer, no difference elsewhere. 



... this.  Hopefully, if subsequent intrumentations on same BB on

read/write are considered redundant now, we should see some speed

difference on more tests.



> 3 benchmarks fail to build: 



> Error: 1x403.gcc 1x445.gobmk 1x458.sjeng

> resource.c:431:1: internal compiler error: in

> update_mem_ref_hash_table, at

> asan.c:460



The updated patch hopefully addresses that too.



Thank you for doing this!

[Bug c/47409] volatile struct member bug

[jason at gcc dot gnu.org]

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



--- Comment #14 from Jason Merrill  2013-02-06 
14:59:57 UTC ---

(In reply to comment #13)

> But, what to do about unions?  The standard says that only one union member is

> active, but which one it is?  I think the compiler generally can't know.  So,

> do we just ignore unions and expand them always as we used to?  Pick up the

> first union member (or randomly or preferably one with volatile)?



C++ defines copy of a (trivially copyable) union to copy the object

representation, which is not volatile unless the whole union is volatile.  I

can't find anything relevant in C11.



There is also C++ DR 496:

http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#496



It seems the effect of this change will be to make assignment of a union with a

volatile field ill-formed in C++ unless the union has a user-provided

assignment operator.



I think we just ignore unions, at least in the middle end.



> What about bitfields?  Does it have to be per bitfield assignment, or can we

> e.g. assign the whole representative field at a time?



I think we should follow the memory model data race rules here; volatile

accesses are done per memory location, rather than per field.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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



--- Comment #10 from Richard Biener  2013-02-06 
14:55:25 UTC ---

(In reply to comment #9)

> Created attachment 29369 [details]

> updated patch

> 

> This works better.  Probably flow_loops_find should not handle loop removal

> though, and the IRA use is plain ugly (but it was before).



What I like about this idea is consolidating of fix_loop_structure and

flow_loops_find (and possibly parts of loop_optimizer_init).  What I like

less is that we allow even more leeway to passes to fixup after them.

That is, at least we should ICE when a loop marked for removal by a pass

is then re-discovered with exactly the same header.  And we should probably

dump info somewhere when we incrementally discover new loops.



Separately fixing the IRA oddness would be nice (use

loop_optimizer_init (AVOID_CFG_MANIPULATIONS) and current_loops instead of

ira_loops).

[Bug rtl-optimization/56225] [4.8 Regression] ICE in lra-constraints.c when executing the testsuite with -m32 -march=pentium3

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2013-02-06 
14:43:33 UTC ---

Reduced testcase for -O2 -m32 -march=pentium3 -mtune=generic:

void bar (int);



void

foo (int x, int y)

{

  __attribute__ ((vector_size (8 * sizeof (short short s0 = { x };

  bar ((short) (long) &s0 + y);

}

[Bug rtl-optimization/56225] [4.8 Regression] ICE in lra-constraints.c when executing the testsuite with -m32 -march=pentium3

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||ra

   Target Milestone|--- |4.8.0

Summary|ICE in lra-constraints.c|[4.8 Regression] ICE in

   |when executing the  |lra-constraints.c when

   |testsuite with -m32 |executing the testsuite

   |-march=pentium3 |with -m32 -march=pentium3

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Attachment #29368|0   |1

is obsolete||



--- Comment #9 from Richard Biener  2013-02-06 
14:31:52 UTC ---

Created attachment 29369

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

updated patch



This works better.  Probably flow_loops_find should not handle loop removal

though, and the IRA use is plain ugly (but it was before).

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[fweimer at redhat dot com]

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



Florian Weimer  changed:



   What|Removed |Added



 CC||fweimer at redhat dot com



--- Comment #10 from Florian Weimer  2013-02-06 
14:28:35 UTC ---

(In reply to comment #9)

> 1) this is -D_FORTIFY_SOURCE warning, you can invent other warnings elsewhere

> 2) with -D_FORTIFY_SOURCE, e.g. sprintf is an inline function, so the FE sees

> it as a call to an inline function with some argument, you need to inline it,

> figure out what the inline does, then fold the builtins used in the inline.

> Also consider

>   char buf[2];

>   char *p;

>   p = buf;

>   sprintf(buf, "ab%d", n);



I think you mean sprintf(p, ...).



> Unless you move the optimization passes into the FE, you aren't going to warn

> about this properly in the FE.  Insisting on a FE warning in this case is just

> dumb.



We could duplicate optimizations in the front end (like others do).



More seriously, I think this is a case where a layering violation makes perfect

sense.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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



--- Comment #8 from Richard Biener  2013-02-06 
14:20:30 UTC ---

Created attachment 29368

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

patch to make flow_loops_find work in-place



One idea is, as in the attached patch, to unify flow_loops_find and

fix_loop_structure.  Basically re-discover loops, but in-place.



Doesn't work as-is - loop size is off for some reason.



This way fix_loop_structure would also discover new loops (and eventually

we'd simply run it at loop_optimizer_init time - which of course will hide

pass bugs).

[Bug target/56200] queens benchmark is faster with -O0 than with any other optimization level

[ysrumyan at gmail dot com]

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



Yuri Rumyantsev  changed:



   What|Removed |Added



 CC||ysrumyan at gmail dot com



--- Comment #7 from Yuri Rumyantsev  2013-02-06 
14:04:36 UTC ---

Here is my 2 cents.



I assume that we must not put 2 branches to the same target into the same fetch

line since x86 branch predictor uses IP without last 4 bits as hash function.

It means that 2 consequtive branches to the same targets have the same

prediction history, i.e. they both either taken or not-taken but we can suppose

that for

   if (cond1 || cond2)

 goto L;



one of condition can be true with more than 50% probability. If we are at the

2nd branch (i.e. 1st branch was not-taken) we must assume that it will be taken

and it must be put to another fetch line.

[Bug rtl-optimization/56225] New: ICE in lra-constraints.c when executing the testsuite with -m32 -march=pentium3

[dnovillo at gcc dot gnu.org]

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



 Bug #: 56225

   Summary: ICE in lra-constraints.c when executing the testsuite

with -m32 -march=pentium3

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: dnovi...@gcc.gnu.org

CC: vmaka...@redhat.com

Target: x86_64-unknown-linux-gnu





I'm getting several failures when running the testsuite with -m32

-march=pentium3.  They all seem related.  I've taken this one from

gcc.c-torture/execute/scal-to-vec2.c



$ cat scal-to-vec2.i

long __attribute__ ((noinline)) vlng () { return (long)42; }

int __attribute__ ((noinline)) vint () { return (int) 43; }

short __attribute__ ((noinline)) vsrt () { return (short)42; }

char __attribute__ ((noinline)) vchr () { return (char)42; }





int main (int argc, char *argv[]) {

__attribute__((vector_size((16)*sizeof(char char c0 = {argc,

1,2,3,4,5,6,7, argc, 1,2,3,4,5,6,7};

__attribute__((vector_size((16)*sizeof(char char c1;



__attribute__((vector_size((8)*sizeof(short short s0 = {argc,

1,2,3,4,5,6,7};

__attribute__((vector_size((8)*sizeof(short short s1;



__attribute__((vector_size((4)*sizeof(int int i0 = {argc, 1, 2, 3};

__attribute__((vector_size((4)*sizeof(int int i1;



__attribute__((vector_size((2)*sizeof(long long l0 = {argc, 1};

__attribute__((vector_size((2)*sizeof(long long l1;



c1 = vchr() + c0; do { int __i; for (__i = 0; __i < 16; __i++) { if

((*((char *) &(c1) + __i)) != (vchr() + (*((char *) &(c0) + __i

__builtin_abort (); }} while (0);



s1 = vsrt() + s0; do { int __i; for (__i = 0; __i < 8; __i++) { if

((*((short *) &(s1) + __i)) != (vsrt() + (*((short *) &(s0) + __i

__builtin_abort (); }} while (0);

s1 = vchr() + s0; do { int __i; for (__i = 0; __i < 8; __i++) { if

((*((short *) &(s1) + __i)) != (vchr() + (*((short *) &(s0) + __i

__builtin_abort (); }} while (0);



i1 = vint() * i0; do { int __i; for (__i = 0; __i < 4; __i++) { if ((*((int

*) &(i1) + __i)) != (vint() * (*((int *) &(i0) + __i __builtin_abort (); }}

while (0);

i1 = vsrt() * i0; do { int __i; for (__i = 0; __i < 4; __i++) { if ((*((int

*) &(i1) + __i)) != (vsrt() * (*((int *) &(i0) + __i __builtin_abort (); }}

while (0);

i1 = vchr() * i0; do { int __i; for (__i = 0; __i < 4; __i++) { if ((*((int

*) &(i1) + __i)) != (vchr() * (*((int *) &(i0) + __i __builtin_abort (); }}

while (0);



l1 = vlng() * l0; do { int __i; for (__i = 0; __i < 2; __i++) { if

((*((long *) &(l1) + __i)) != (vlng() * (*((long *) &(l0) + __i

__builtin_abort (); }} while (0);

l1 = vint() * l0; do { int __i; for (__i = 0; __i < 2; __i++) { if

((*((long *) &(l1) + __i)) != (vint() * (*((long *) &(l0) + __i

__builtin_abort (); }} while (0);

l1 = vsrt() * l0; do { int __i; for (__i = 0; __i < 2; __i++) { if

((*((long *) &(l1) + __i)) != (vsrt() * (*((long *) &(l0) + __i

__builtin_abort (); }} while (0);

l1 = vchr() * l0; do { int __i; for (__i = 0; __i < 2; __i++) { if

((*((long *) &(l1) + __i)) != (vchr() * (*((long *) &(l0) + __i

__builtin_abort (); }} while (0);



return 0;

}



When compiled with -m32, it works fine:

$ ../cc1 -fpreprocessed scal-to-vec2.i -quiet -dumpbase scal-to-vec2.c

-mtune=generic -auxbase scal-to-vec2 -O1 -w -version

-fno-diagnostics-show-caret -o scal-to-vec2.s -quiet -m32

GNU C (GCC) version 4.8.x-google-integration 20130201 (experimental)

(x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.x-google-integration 20130201

(experimental), GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU C (GCC) version 4.8.x-google-integration 20130201 (experimental)

(x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.x-google-integration 20130201

(experimental), GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Compiler executable checksum: 261028b85770ed5f451425c66cb11710



But when compiled with -m32 -march=pentium3, it fails with:

$ ../cc1 -fpreprocessed scal-to-vec2.i -quiet -dumpbase scal-to-vec2.c

-mtune=generic -auxbase scal-to-vec2 -O1 -w -version

-fno-diagnostics-show-caret -o scal-to-vec2.s -quiet -m32 -march=pentium3

GNU C (GCC) version 4.8.x-google-integration 20130201 (experimental)

(x86_64-unknown-linux-gnu)

compiled by GNU C version 4.8.x-google-integration 20130201

(experimental), GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

GNU C (GCC) version 4.8.x-google-inte

[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails

[janus at gcc dot gnu.org]

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



--- Comment #22 from janus at gcc dot gnu.org 2013-02-06 13:56:02 UTC ---

(In reply to comment #21)

> It seems to work just as well as the patch in comment #18 and is much simpler.

> Also it could catch this sort of thing in other situations as well. So I would

> say that it is preferable over the previous patches.

> 

> Will test for regressions (but don't expect any).



The patch in comment 21, like the previous ones in comment 14 and 18, is free

of testsuite regressions.

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[jakub at gcc dot gnu.org]

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



--- Comment #9 from Jakub Jelinek  2013-02-06 
13:46:05 UTC ---

1) this is -D_FORTIFY_SOURCE warning, you can invent other warnings elsewhere

2) with -D_FORTIFY_SOURCE, e.g. sprintf is an inline function, so the FE sees

it as a call to an inline function with some argument, you need to inline it,

figure out what the inline does, then fold the builtins used in the inline.

Also consider

  char buf[2];

  char *p;

  p = buf;

  sprintf(buf, "ab%d", n);

Unless you move the optimization passes into the FE, you aren't going to warn

about this properly in the FE.  Insisting on a FE warning in this case is just

dumb.

[Bug c++/54122] [4.7/4.8 Regression] segfault comparing enum class in lambda inside constructor of a templated class

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED

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

   |gnu.org |



--- Comment #10 from Jason Merrill  2013-02-06 
13:43:54 UTC ---

Fixed.

[Bug c++/54122] [4.7/4.8 Regression] segfault comparing enum class in lambda inside constructor of a templated class

[jason at gcc dot gnu.org]

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



--- Comment #9 from Jason Merrill  2013-02-06 
13:42:19 UTC ---

Author: jason

Date: Wed Feb  6 13:42:06 2013

New Revision: 195806



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

Log:

PR c++/54122

* tree.c (lvalue_kind) [INDIRECT_REF]: Don't check for

METHOD_TYPE.



Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this7.C

Modified:

branches/gcc-4_7-branch/gcc/cp/ChangeLog

branches/gcc-4_7-branch/gcc/cp/tree.c

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  2013-02-06 
13:39:32 UTC ---
(In reply to comment #7)
> Because object sizes are finalized only during the objsz pass, after lots of
> optimization passes.  Note, as I said earlier, what matters most is that the
> check is performed at runtime in that case and thus the source code bug can't
> be exploited.  The warning is just to let the user know earlier than at
> runtime, when easily possible.

Maybe we are talking about different things. cppcheck seems to be able to give
the warning without any optimizations. The FE doesn't know that buf[2] is
length 2 and "ab" is length 3?

[Bug target/53040] nested functions may trash floating point registers

[amodra at gmail dot com]

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



--- Comment #6 from Alan Modra  2013-02-06 13:31:45 
UTC ---

This one is hardly an annoying bug.  You need

a) nested functions,

b) using floating point,

c) with an unusual set of callee saved fprs,

d) and -Os.



I found the bug only because I wrote a fairly complete test for

prologue/epilogue code.



OTOH, the patch is quite obvious and completely safe..

[Bug fortran/56224] New: gfortran -fopenmp cannot find omp_lib.h

[dnovillo at gcc dot gnu.org]

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

 Bug #: 56224
   Summary: gfortran -fopenmp cannot find omp_lib.h
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dnovi...@gcc.gnu.org
CC: ja...@redhat.com


$ cat ~/a.f
include "omp_lib.h"
end

Compiled with trunk as of 2013-02-04:

$ gcc48/bin/gfortran -c a.f
a.f:1: Error: Can't open included file 'omp_lib.h'

Compiled with GCC 4.7:

$ gcc47/bin/gfortran -c a.f
$

Jakub and I discussed this on IRC:

07:58:20 dnovillo: jakub: i see the file in …./finclude/omp_lib.h, but when i
run the libgomp testsuite with the installed compiler, the #include directives
in the libgomp fortran tests can't find that file.
07:58:22 jakub: dnovillo: it is; omp_lib.h generally should be #included, so
what matters is the standard preprocessor search path, and omp_lib.h should be
there
07:58:41 richi: maybe I should code up a "discover undetected loops" routine
07:58:51 jakub: dnovillo: omp_lib without .h should be USEd
07:59:18 dnovillo: jakub: this is being included by
libgomp.fortran/appendix-a/a.18.1.f90
08:00:08 dnovillo: the problem is that when i run the testsuite standalone, I
don't see a -I to the .../finclude directory.  This works when executed from
the build directory, so I may be missing some settings in my dejagnusetup.
08:00:17 jakub: dnovillo: finclude/ is for modules I thought
08:00:41 dnovillo: well, that's where the file ends up in the installed image.
08:00:54 dnovillo: fortran modules have a different search path?
08:02:22 jakub:   include "omp_lib.h"
08:02:22 jakub:   end
08:02:33 jakub: gfortran -fopenmp -o /tmp/a /tmp/a.f
08:02:46 jakub: works just fine for me with installed compiler (Fedora 17 one)
08:04:10 dnovillo: hmm, there may be another wrinkle here then.  i'm getting
08:04:26 dnovillo: $ bin/gfortran -fopenmp -o /tmp/a.o ~/a.f
/home/dnovillo/a.f:1: Error: Can't open included file 'omp_lib.h'
08:04:50 dnovillo: with gfortran from trunk as of 4/Feb.
08:05:02 jakub: even
08:05:08 jakub: #include "omp_lib.h"
08:05:11 jakub:   end
08:05:21 jakub: gfortran -fopenmp -o /tmp/a /tmp/a.F works for me
08:05:32 dnovillo: with trunk gfortran, i suppose?
08:05:51 jakub: dnovillo> 4.7, but there weren't any changes I'm aware of
08:06:00 jakub: dnovillo: let me try 4.8-RH gfortran
08:06:01 dnovillo: ah, 4.7 works fine for me.
08:06:15 dnovillo: it's 4.8 that i can't get to work.
08:09:01 jakub: dnovillo: ok, I can reproduce the problem with 4.8
08:09:35 dnovillo: i think using USE might work. I see -fintrinsic-modules-path
gcc/x86/bin/../lib/gcc/x86_64-grtev3-linux-gnu/4.8.x-google-integration/finclude
in the -v output
08:09:39 jakub: dnovillo: can you file a bug against fortran component?  The
files are installed the same way as before, so it is the FE that changed in
some weirdo way
08:09:48 dnovillo: jakub: will do.
08:09:56 jakub: dnovillo: use should be used together with omp_lib, not
omp_lib.h
08:10:23 dnovillo: ah, so the test would have to change.  ok.  i'll file the
bug and mark these failures as expected for now in our builds.  thanks.
08:10:38 jakub: dnovillo: perhaps the end of dicsussion will be that omp_lib.h
should be installed into include/ instead of finclude/, where it would
supposedly work
08:11:05 jakub: dnovillo: even in 4.7, gfortran -E with #include "omp_lib.h"
didn't work, but -c worked
08:11:30 dnovillo: heh.  but we'd need it in both places, right?  finclude/ is
used for USE commands?
08:11:38 jakub: dnovillo: having omp_lib.h in include/ on the other side means
that people using C/C++ might try to #include "omp_lib.h" and be very surprised
08:12:15 jakub: dnovillo: omp_lib.h isn't a module, it is a header file, it
should be used in pre-F90 Fortran only
08:12:30 dnovillo: ah
08:12:38 jakub: dnovillo: USE is F90+, needs omp_lib.f90/omp_lib.mod etc. -
i.e. a module

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[jakub at gcc dot gnu.org]

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



--- Comment #7 from Jakub Jelinek  2013-02-06 
13:25:29 UTC ---

Because object sizes are finalized only during the objsz pass, after lots of

optimization passes.  Note, as I said earlier, what matters most is that the

check is performed at runtime in that case and thus the source code bug can't

be exploited.  The warning is just to let the user know earlier than at

runtime, when easily possible.



-D_FORTIFY_SOURCE{,=2} is done using inline functions, so the FE pretty much

never knows the object size, you need inlining and various propagations (plus

for many cases also the objsz pass that propagates the object size properties

through the IL).  In the FE you could do it only if all the fortification

functions were preprocessor macros, and handle only the most simple cases.

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  2013-02-06 
13:13:52 UTC ---
(In reply to comment #5)
> So, if we are going to do something about this, either we could do something
> very simple, like strchr (str, '%') - str as low bound guess, or reuse the
> c-format tables somehow (but they are in the FE, while this is in middle-end),

And why is this check in the middle-end?

[Bug target/56219] avr-gcc-4.7.2 missing __uint24 loop optimisation

[demiurg_spb at freemail dot ru]

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



--- Comment #2 from demiurg_spb at freemail dot ru 2013-02-06 13:06:01 UTC ---

oops r0 - is call-clobbered:(

[Bug target/54009] incorrect code generated for DFmode lo_sum mem

[amodra at gmail dot com]

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



--- Comment #4 from Alan Modra  2013-02-06 13:04:43 
UTC ---

Regressed due to pr54131 fix.

[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #21 from janus at gcc dot gnu.org 2013-02-06 13:00:52 UTC ---

(In reply to comment #18)

> Btw, as an alternative: Wouldn't it be more reasonable to move the above check

> into _gfortran_internal_pack?



Here is the very simple patch which does this:





Index: libgfortran/runtime/in_pack_generic.c

===

--- libgfortran/runtime/in_pack_generic.c(revision 195800)

+++ libgfortran/runtime/in_pack_generic.c(working copy)

@@ -48,6 +48,9 @@ internal_pack (gfc_array_char * source)

   index_type size;

   index_type type_size;



+  if (source->base_addr == NULL)

+return NULL;

+

   type_size = GFC_DTYPE_TYPE_SIZE(source);

   size = GFC_DESCRIPTOR_SIZE (source);

   switch (type_size)





It seems to work just as well as the patch in comment #18 and is much simpler.

Also it could catch this sort of thing in other situations as well. So I would

say that it is preferable over the previous patches.



Will test for regressions (but don't expect any).

[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails

[janus at gcc dot gnu.org]

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



--- Comment #20 from janus at gcc dot gnu.org 2013-02-06 12:54:41 UTC ---

(In reply to comment #19)

> That generates the code:

> D.1896 = x != 0B

>  ? (struct array1_integer(kind=4) *) _gfortran_internal_pack (x)

>  : 0B;

> two (D.1896);

> if (x != 0B

> && (integer(kind=4)[0:] *) x->data != (integer(kind=4)[0:] *) D.1896)

> 

> I think it should be "x != 0B && x->data != 0B" in the first condition.



I don't see how this would help (if x is anyway OB, as it is the case for your

second call).



Moreover, it seems to fail only *after* the call to 'two', probably in the if

statement you show. The failure only happens at -O0 for me.

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[jakub at gcc dot gnu.org]

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



--- Comment #21 from Jakub Jelinek  2013-02-06 
12:48:39 UTC ---

As the shadow memory doesn't have information about what locations are

read-only, it only has info whether the relevant bytes are valid, or invalid

(or some invalid, some valid), and for all invalid a few magic values for more

detailed reporting.  So, if you have a RMW statement, without any asan

optimization it will first check the read, and already fail on the read, so

even with the optimization if you just check the read and not the write, the

user visible behavior will be exactly the same.

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[kcc at gcc dot gnu.org]

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



--- Comment #20 from Kostya Serebryany  2013-02-06 
12:43:09 UTC ---

> The clang variant looks incorrect to me - if asan distinguishes between

> loads and stores

It doesn't.

The only reason why we have two callbacks is that asan 

prints a message containing "READ" or "WRITE"

In this case we can report a bad read or a bad write -- doesn't matter.

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #5 from Jakub Jelinek  2013-02-06 
12:41:09 UTC ---

It isn't that easy.  For %'s you really have to parse all the characters after

% and figure out where the format specifier ends.  Users can have printf hooks

installed, so it certainly needs to give up any time it sees something it

doesn't fully understand.  In that case I guess it could safely just assume the

lower bound as if the string ended on the % after which it doesn't understand

the letters.  Note, that this is just about the compile time warning, the code

will fail at runtime the same way in the first as in the second case.



So, if we are going to do something about this, either we could do something

very simple, like strchr (str, '%') - str as low bound guess, or reuse the

c-format tables somehow (but they are in the FE, while this is in middle-end),

or write a simple parse of few most common formatting specifiers and give up on

anything else.