[Bug other/53889] Gthreads doesn't support destroying recursive mutexes

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely  2012-10-05 
07:35:17 UTC ---

Author: redi

Date: Fri Oct  5 07:35:12 2012

New Revision: 192114



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

Log:

PR other/53889

* config/i386/gthr-win32.h (__gthread_recursive_mutex_destroy):

Fix parameter names.



Modified:

trunk/libgcc/ChangeLog

trunk/libgcc/config/i386/gthr-win32.h

[Bug other/54819] New: Microblaze: When enabling position independent code the linker does not recognize the object file

[qball at sarine dot nl]

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



 Bug #: 54819

   Summary: Microblaze: When enabling position independent code

the linker does not recognize the object file

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: other

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

ReportedBy: qb...@sarine.nl





I hope this is the right place to report it, I'm sorry if it is not:



When compiling C code for the microblaze and you enable position independent

code (-fpic) the tool flow does not recognize the object file.



Example C code:

void main()

{

}



mb-gcc main.c  -v -fpic

Using built-in specs.

COLLECT_GCC=/local_home/mkoedam/GCC3/install/bin/mb-gcc

COLLECT_LTO_WRAPPER=/local_home/mkoedam/GCC3/install/libexec/gcc/microblaze-xilinx-elf/4.7.2/lto-wrapper

Target: microblaze-xilinx-elf

Configured with: ../configure --target=microblaze-xilinx-elf

--prefix=/opt/mb-gcc/ --program-prefix=mb-

--prefix=/local_home/mkoedam/GCC3/install --enable-languages=c,c++

--disable-nls --without-headers --disable-multilib --disable-libssp

--with-newlib

Thread model: single

gcc version 4.7.2 (GCC) 

COLLECT_GCC_OPTIONS='-v' '-fpic'

 /local_home/mkoedam/GCC3/install/libexec/gcc/microblaze-xilinx-elf/4.7.2/cc1

-quiet -v main.c -quiet -dumpbase main.c -auxbase main -version -fpic -o

/tmp/cctiZK3o.s

GNU C (GCC) version 4.7.2 (microblaze-xilinx-elf)

compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version 2.4.2, MPC

version 0.8.1

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

ignoring nonexistent directory

"/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/sys-include"

#include "..." search starts here:

#include <...> search starts here:

 /local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/include



/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/include-fixed



/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/include

End of search list.

GNU C (GCC) version 4.7.2 (microblaze-xilinx-elf)

compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version 2.4.2, MPC

version 0.8.1

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler executable checksum: 1bda14ee29b10396a8e5d1413b1c5be8

COLLECT_GCC_OPTIONS='-v' '-fpic'



/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/bin/as

-o /tmp/ccOegaQG.o /tmp/cctiZK3o.s

COMPILER_PATH=/local_home/mkoedam/GCC3/install/libexec/gcc/microblaze-xilinx-elf/4.7.2/:/local_home/mkoedam/GCC3/install/libexec/gcc/microblaze-xilinx-elf/4.7.2/:/local_home/mkoedam/GCC3/install/libexec/gcc/microblaze-xilinx-elf/:/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/:/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/:/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/bin/

LIBRARY_PATH=/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/:/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/lib/

COLLECT_GCC_OPTIONS='-v' '-fpic'



/local_home/mkoedam/GCC3/install/libexec/gcc/microblaze-xilinx-elf/4.7.2/collect2

-N -relax -G 0 -dT

/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/lib/xilinx.ld

/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/lib/crt0.o

/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/crti.o

/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/crtbegin.o

/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/lib/crtinit.o

-L/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2

-L/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/../../../../microblaze-xilinx-elf/lib

/tmp/ccOegaQG.o -lgcc -start-group -lgloss -lxil -lc -lm -end-group -lgcc

/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/crtend.o

/local_home/mkoedam/GCC3/install/lib/gcc/microblaze-xilinx-elf/4.7.2/crtn.o

/tmp/ccOegaQG.o: could not read symbols: File format not recognized

collect2: error: ld returned 1 exit status



I can trace this back to GCC 4.6.2.   4.1.2 (from xilinx) works.



The compiler is compiled using the following script:

https://github.com/DaveDavenport/CrossCompilerGCCScript/blob/master/gcc_cross_compiler.sh



Please let me know if I need to provide more information.

[Bug other/54819] Microblaze: When enabling position independent code the linker does not recognize the object file

[qball at sarine dot nl]

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



--- Comment #1 from qball at sarine dot nl 2012-10-05 08:30:50 UTC ---

Without -fpic the code compiles and runs correctly.

[Bug bootstrap/54820] New: [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002

[jan.kratochvil at redhat dot com]

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



 Bug #: 54820

   Summary: [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0

20121002

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

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

ReportedBy: jan.kratoch...@redhat.com

  Host: x86_64-unknown-linux-gnu

Target: x86_64-unknown-linux-gnu

 Build: x86_64-unknown-linux-gnu





Fedora 18 x86_64



../gcchead/configure --enable-64-bit-bfd --enable-debug --disable-sim

--enable-gold --enable-plugins --disable-werror

--with-separate-debug-dir=/usr/lib/debug

--prefix=/home/jkratoch/redhat/gcchead-root

--enable-languages=c,c++,fortran,java,ada,go

--with-ecj-jar=/usr/share/java/eclipse-ecj.jar

make



make[3]: Entering directory `/home/jkratoch/redhat/gcchead-build/gcc'

g++ -g -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 -fno-common

-DHAVE_CONFIG_H -static-libgcc -static-libstdc++ -lmcheck -o gnat1

ada/adadecode.o ada/adaint.o ada/argv.o ada/cio.o ada/cstreams.o ada/env.o

ada/init.o ada/initialize.o ada/raise.o ada/seh_init.o ada/targext.o

ada/cuintp.o ada/decl.o ada/misc.o ada/utils.o ada/utils2.o ada/trans.o

ada/targtyps.o ada/a-charac.o ada/a-chlat1.o ada/a-elchha.o ada/a-except.o

ada/a-ioexce.o ada/ada.o ada/alfa.o ada/ali.o ada/alloc.o ada/aspects.o

ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o ada/csets.o

ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o ada/err_vars.o

ada/errout.o ada/erroutc.o ada/eval_fat.o ada/exp_aggr.o ada/exp_alfa.o

ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o ada/exp_ch12.o

ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o ada/exp_ch5.o

ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o ada/exp_code.o

ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o ada/exp_imgv.o

ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o ada/exp_smem.o

ada/exp_strm.o ada/exp_tss.o ada/exp_util.o ada/exp_vfpt.o ada/expander.o

ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o ada/frontend.o

ada/g-byorma.o ada/g-hesora.o ada/g-htable.o ada/g-spchge.o ada/g-speche.o

ada/g-u3spch.o ada/get_alfa.o ada/get_targ.o ada/gnat.o ada/gnatvsn.o

ada/hostparm.o ada/impunit.o ada/inline.o ada/interfac.o ada/itypes.o

ada/krunch.o ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-writ.o

ada/lib-xref.o ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o ada/nlists.o

ada/nmake.o ada/opt.o ada/osint-c.o ada/osint.o ada/output.o ada/par.o

ada/par_sco.o ada/prep.o ada/prepcomp.o ada/put_alfa.o ada/put_scos.o

ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o ada/s-addope.o

ada/s-assert.o ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o

ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o

ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-excdeb.o

ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o

ada/s-mastop.o ada/s-memory.o ada/s-os_lib.o ada/s-parame.o ada/s-purexc.o

ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o

ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strcom.o

ada/s-strhas.o ada/s-string.o ada/s-strops.o ada/s-traent.o ada/s-unstyp.o

ada/s-utf_32.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scans.o

ada/scil_ll.o ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o ada/sem.o

ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o ada/sem_case.o ada/sem_cat.o

ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o

ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o

ada/sem_ch8.o ada/sem_ch9.o ada/sem_dim.o ada/sem_disp.o ada/sem_dist.o

ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_mech.o

ada/sem_prag.o ada/sem_res.o ada/sem_scil.o ada/sem_smem.o ada/sem_type.o

ada/sem_util.o ada/sem_vfpt.o ada/sem_warn.o ada/sinfo-cn.o ada/sinfo.o

ada/sinput-d.o ada/sinput-l.o ada/sinput.o ada/snames.o ada/sprint.o

ada/stand.o ada/stringt.o ada/style.o ada/styleg.o ada/stylesw.o ada/switch-c.o

ada/switch.o ada/system.o ada/table.o ada/targparm.o ada/tbuild.o

ada/tree_gen.o ada/tree_in.o ada/tree_io.o ada/treepr.o ada/treeprs.o

ada/ttypes.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o ada/usage.o

ada/validsw.o ada/warnsw.o ada/widechar.o ada/back_end.o ada/gnat1drv.o

ada/b_gnat1.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a

../libcpp/libcpp.a ../libdecnumber/libdecnumber.a attribs.o libcommon-target.a

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

../libiberty/libiberty.a ../libdecnumber/libde

[Bug middle-end/54821] New: Microblaze: Position independent code for byte access is incorrect.

[qball at sarine dot nl]

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



 Bug #: 54821

   Summary: Microblaze: Position independent code for byte access

is incorrect.

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: middle-end

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

ReportedBy: qb...@sarine.nl





When enabling position independent code gcc generates incorrect assembly for

byte access. Works fine when generating word (32bit) loads/writes.



e.g. 

When doing a word load results in the following correct assembly:

 lwi  r3, r20, 20# load the address at .got.plt

+ 20 (address of a variable in the .got section)

 lwi  r4, r3, 0 # load the value of the

variable in r4



However when doing byte load:



imm   4  

lbuir3, r20, 23884 # load the value of the variable in

r3. The address used is r20 + 0x45d4c.



There are 2 things going wrong..  

1.) It tries to load the r20 + the absolute offset of the variable.

2.) It should first load the address (from the got) then load the value from

that address

I would expect something like:

lwi r3, r20, 16

lbuir4, r3, 0



A similar things goes wrong for half word access.





This problem can be reproduced with GCC 4.1.2 (from xilinx) up to 4.7.2 (When

looking in the object files, generating elf files fails as of bug #54819)

A script to build the cross-compiler can be found here:

https://github.com/DaveDavenport/CrossCompilerGCCScript/blob/master/gcc_cross_compiler.sh



C code that shows the issue:

char temp = 3;

int temp2 = 12;

short int temp4 =13;

void main()

{

int a = temp+ temp2+temp4;

}





Output generated for this: (by 4.1.2)

01b0 :

 1b0:3021fff0 addikr1, r1, -16

 1b4:fa610008 swir19, r1, 8

 1b8:fa81000c swir20, r1, 12

 1bc:1261 addkr19, r1, r0

 1c0:e0740444 lbuir3, r20, 1092

 1c4:90630060 sext8r3, r3

 1c8:1083 addkr4, r3, r0

 1cc:b000 imm0

 1d0:e874000c lwir3, r20, 12

 1d4:e863 lwir3, r3, 0

 1d8:10841800 addkr4, r4, r3

 1dc:e474044c lhuir3, r20, 1100

 1e0:90630061 sext16r3, r3

 1e4:10641800 addkr3, r4, r3

 1e8:f8730004 swir3, r19, 4

 1ec:1033 addkr1, r19, r0

 1f0:ea610008 lwir19, r1, 8

 1f4:ea81000c lwir20, r1, 12

 1f8:30210010 addikr1, r1, 16

 1fc:b60f0008 rtsdr15, 8

 200:8000 orr0, r0, r0





Only the load word is done correctly.

[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002

[charlet at gcc dot gnu.org]

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



Arnaud Charlet  changed:



   What|Removed |Added



 CC||charlet at gcc dot gnu.org



--- Comment #1 from Arnaud Charlet  2012-10-05 
08:46:25 UTC ---

What has changed is that now -static-libstdc++ is used, in addition to

-static-libgcc, to fix other builds failures since the switch to g++ by

default.



So I guess this would mean that you do NOT have a static libstdc++ with your

base

C++ compiler?



Arno

[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002

[jan.kratochvil at redhat dot com]

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



Jan Kratochvil  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Jan Kratochvil  
2012-10-05 08:53:59 UTC ---

You are right, thanks, it builds now.

[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-05

Summary|error: type mismatch in |[4.7/4.8 Regression] error:

   |binary expression   |type mismatch in binary

   ||expression

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2012-10-05 
08:55:25 UTC ---

The test compiles with 4.6.3, but not with 4.4.6, 4.5.3, 4.7.2, and trunk.

Revision 171100 (2011-03-17) is OK, revision 171653 (2011-03-29) is not.

[Bug fortran/54822] New: OpenMP - Firstprivate optional dummy arguments crash if not present

[roger.ferrer at bsc dot es]

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

 Bug #: 54822
   Summary: OpenMP - Firstprivate optional dummy arguments crash
if not present
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: roger.fer...@bsc.es


The following program

SUBROUTINE S(X)
IMPLICIT NONE
INTEGER, OPTIONAL :: X

!$OMP TASK FIRSTPRIVATE(X)
IF (PRESENT(X)) THEN
  X = X + 1
END IF
!$OMP END TASK
END SUBROUTINE S

PROGRAM MAIN
IMPLICIT NONE
INTERFACE
SUBROUTINE S(X)
IMPLICIT NONE
INTEGER, OPTIONAL :: X
END SUBROUTINE S
END INTERFACE

CALL S()
END PROGRAM MAIN

crashes at runtime using gfortran 4.7.1

$ gfortran -o bug bug.f90 -fopenmp
$ ./bug 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7FC7C9245667
#1  0x7FC7C9245C34
#2  0x7FC7C83DE4EF
#3  0x4007B2 in s_._omp_cpyfn.1 at bug.f90:0
#4  0x7FC7C8DA2875
#5  0x40074D in s_
#6  0x40075D in MAIN__ at bug.f90:0
Violació de segment

I think that the initialization of the firstprivate X using the non-present
dummy argument X is causing the crash.

[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression

[janus at gcc dot gnu.org]

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



--- Comment #2 from janus at gcc dot gnu.org 2012-10-05 09:09:39 UTC ---

Reduced test case:



implicit none

real :: name = 5.

print *, transfer(name,"a")//"xyz"

end





Fails here with 4.7 and trunk, but works with 4.3. Haven't tried other

versions.

[Bug tree-optimization/54810] VRP doesn't handle comparison of narrowing cast like comparison of BIT_AND_EXPR

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2012-10-05 
09:37:32 UTC ---

Author: jakub

Date: Fri Oct  5 09:37:25 2012

New Revision: 192115



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

Log:

PR tree-optimization/54810

* tree-vrp.c (register_edge_assert_for_2): Handle

NAME = (unsigned) NAME2; if (NAME cmp CST) for

narrowing casts to unsigned integral type like

NAME = NAME2 & CST2; if (NAME cmp CST) where CST2

is the max value of the unsigned integral type.



* gcc.dg/tree-ssa/vrp85.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp85.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vrp.c

[Bug fortran/54822] OpenMP - Firstprivate optional dummy arguments crash if not present

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2012-10-05 
09:47:49 UTC ---

Sure, but why do you think it is a compiler error?



The OpenMP standard says that the firstprivate private copy of the var is

initialized (for non-pointers) using intrinsic assignment, if you do

intrinsic assignment of X into some other var (Y = X), then you'll get exactly

the same segfault.

[Bug fortran/54822] OpenMP - Firstprivate optional dummy arguments crash if not present

[roger.ferrer at bsc dot es]

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



--- Comment #2 from Roger Ferrer Ibanez  2012-10-05 
09:53:36 UTC ---

> The OpenMP standard says that the firstprivate private copy of the var is

> initialized (for non-pointers) using intrinsic assignment, 



Oops. I tried also with Intel Fortran and it worked and I wrongly assumed this

was OK. 



The wording of the standard clearly states that this is a problem in the code.



Sorry for the fuss.

[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



  Known to work||4.6.3

   Target Milestone|--- |4.7.3

[Bug lto/54811] [4.8 regression] tree code '�' is not supported in LTO streams

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Guenther  2012-10-05 
10:11:25 UTC ---

Testing



Index: gcc/tree-ssa-live.c

===

--- gcc/tree-ssa-live.c (revision 192114)

+++ gcc/tree-ssa-live.c (working copy)

@@ -621,6 +621,11 @@ clear_unused_block_pointer_1 (tree *tp,

   if (EXPR_P (*tp) && TREE_BLOCK (*tp)

   && !TREE_USED (TREE_BLOCK (*tp)))

 TREE_SET_BLOCK (*tp, NULL);

+  if (TREE_CODE (*tp) == VAR_DECL && DECL_DEBUG_EXPR_IS_FROM (*tp))

+{

+  tree debug_expr = DECL_DEBUG_EXPR (*tp);

+  walk_tree (&debug_expr, clear_unused_block_pointer_1, NULL, NULL);

+}

   return NULL_TREE;

 }

[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression

[dominiq at lps dot ens.fr]

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



--- Comment #3 from Dominique d'Humieres  2012-10-05 
10:20:49 UTC ---

AFAICT the problem occurs in 64 bit mode, but not in 32 one.

[Bug c++/54808] error: non-trivial conversion at assignment (with bit fields)

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



 Status|ASSIGNED|NEW

  Component|middle-end  |c++

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

   ||gnu.org



--- Comment #2 from Richard Guenther  2012-10-05 
10:46:02 UTC ---

It's a C++ frontend issue, the zero is explicit in the CONSTRUCTOR inside

the INIT_EXPR.  The FE probably simply uses integer_zero_node.

[Bug c/54823] New: string literal characters not constant

[devel at fresse dot org]

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



 Bug #: 54823

   Summary: string literal characters not constant

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: de...@fresse.org





this:



int main(void)

{

  int c = *" ";

  printf("%x\n", c);

  return 0;

}



results in (the constant expression):



 movl$32, %eax



But this:



int main(void)

{

  enum {foo = *" "};

  printf("%x\n", foo);

  return 0;

}



gives

error: enumerator value for 'foo' is not an integer constant.



Whereas icc for instance just accepts the second form as constant integer

expression.

[Bug c/54823] string literal characters not constant

[redi at gcc dot gnu.org]

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



--- Comment #1 from Jonathan Wakely  2012-10-05 
11:29:49 UTC ---

*" " is not a constant expression according to the C standard.



The standard says "An implementation may accept other forms of constant

expressions" so ICC is allowed to accept it, but GCC is not required to.

[Bug c/54823] string literal characters not constant

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2012-10-05 
11:34:09 UTC ---

6.7.2.2 "The expression that defines the value of an enumeration constant shall

be an integer constant expression that has a value representable as an int."



See 6.6 for the valid forms of integer constant expressions.

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[jakub at gcc dot gnu.org]

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



--- Comment #36 from Jakub Jelinek  2012-10-05 
11:43:43 UTC ---

Author: jakub

Date: Fri Oct  5 11:43:38 2012

New Revision: 192119



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

Log:

PR tree-optimization/33763

* tree-inline.c (expand_call_inline): Silently ignore always_inline

attribute for redefined extern inline functions.



* c-c++-common/pr33763.c: New test.



Added:

trunk/gcc/testsuite/c-c++-common/pr33763.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-inline.c

[Bug lto/54824] New: [4.8 Regression] ICE in verify_loop_structure with LTO

[d.g.gorbachev at gmail dot com]

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



 Bug #: 54824

   Summary: [4.8 Regression] ICE in verify_loop_structure with LTO

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

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

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





Created attachment 28361

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

Backtrace



GCC 4.8.0 20120930 (experimental).



Compile the attached files with "gcc -O -flto foo.c bar.c".



In file included from foo.c:1:0,

 from :1:

bar.c: In function 'bar':

bar.c:25:1: error: loop 1's latch does not belong directly to it

 }

 ^

bar.c:25:1: internal compiler error: in verify_loop_structure, at

cfgloop.c:1582

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



No ICE with "gcc -O -flto -fwhole-program foo.c bar.c".

[Bug c/54823] string literal characters not constant

[devel at fresse dot org]

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



--- Comment #3 from Sebastian Freundt  2012-10-05 
11:46:20 UTC ---

I'm more or less referring to the internals, why is it a constant expression in

the first case, but not treated as an integer constant expression.



Also, according to the rules of indirection (6.5.3.2):

If [a string literal X] has type "pointer to TYPE" then *X should have type X.



Now if internally *" " is a integer (or char) internally, and taking the rules

of indirection literally, then



  enum {foo = *" "};



should be (in my eyes) the same as



  enum {foo = (char)32};

[Bug lto/54824] [4.8 Regression] ICE in verify_loop_structure with LTO

[d.g.gorbachev at gmail dot com]

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



--- Comment #1 from Dmitry Gorbachev  
2012-10-05 11:47:19 UTC ---

Created attachment 28362

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

Testcase



GCC 20120923 (r191654) - fails, 20120916 (r191367) - ok.

[Bug lto/54811] [4.8 regression] tree code '�' is not supported in LTO streams

[rguenth at gcc dot gnu.org]

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



--- Comment #7 from Richard Guenther  2012-10-05 
11:48:30 UTC ---

Author: rguenth

Date: Fri Oct  5 11:48:27 2012

New Revision: 192120



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

Log:

2012-10-05  Richard Guenther  



PR middle-end/54811

* tree-ssa-live.c (clear_unused_block_pointer_1): Look at

DECL_DEBUG_EXPR again.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-ssa-live.c

[Bug lto/54811] [4.8 regression] tree code '�' is not supported in LTO streams

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #8 from Richard Guenther  2012-10-05 
11:48:49 UTC ---

Fixed (Ada LTO bootstrap still fails).

[Bug c/54823] string literal characters not constant

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #4 from Jakub Jelinek  2012-10-05 
12:06:58 UTC ---

Whether something is a constant expression or not is one thing, whether you can

fold a non-constant expression from standards POV into a constant is another

thing.  That folding is optional, it is an optimization, while the standard

requires that enum constants are constant expressions and GCC doesn't include

*" " among valid constant expressions.  No idea why you need it, you can use '

'

which is a valid constant expression.

[Bug c/54823] string literal characters not constant

[devel at fresse dot org]

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



--- Comment #5 from Sebastian Freundt  2012-10-05 
12:45:45 UTC ---

Ok, I see.  I assume, there's no plans on widening the allowed expressions for

constant integers?



It's autogenerated code a la:



  #define foo "bar"

  (foo)[1] * 0x55 + (foo)[2] * 0x30



where the indices are calculated.  I was trying to port the generated code to

gcc.



Thanks anyway.

[Bug middle-end/54821] Microblaze: Position independent code for byte access is incorrect.

[qball at sarine dot nl]

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



--- Comment #1 from qball at sarine dot nl 2012-10-05 13:17:17 UTC ---

For 4.6.2 (xilinx) this seems to fix the code generation:

mb_gnu/src/gcc/gcc/config/microblaze/microblaze.c

temp/mb_gnu/src/gcc/gcc/config/microblaze/microblaze.c

@@ -558,7 +558,7 @@

   {

 return !(flag_pic && pic_address_needs_scratch (x));

   }

-else if (flag_pic == 2)

+else if (flag_pic)

   {

 return false;

   }



Generates:

addikr1,r1,-16

swir19,r1,8

swir20,r1,12

addkr19,r1,r0

lwir3,r20,temp@GOT

lbuir3,r3,0

sext8r3,r3

addkr4,r3,r0

lwir3,r20,temp2@GOT

lwir3,r3,0

addkr4,r4,r3

lwir3,r20,temp4@GOT

lhuir3,r3,0

sext16r3,r3

addkr3,r4,r3

swir3,r19,4

addkr1,r19,r0

lwir19,r1,8

lwir20,r1,12

addikr1,r1,16

rtsdr15,8

nop# Unfilled delay slot

[Bug c++/53638] static_assert handling behavior ignores template specializations

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Paolo Carlini  2012-10-05 
13:37:04 UTC ---

Closing.

[Bug c++/43566] Debug information removed on last bracket of function

[paolo.carlini at oracle dot com]

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



--- Comment #2 from Paolo Carlini  2012-10-05 
13:43:12 UTC ---

Jakub?

[Bug c++/43566] Debug information removed on last bracket of function

[paolo.carlini at oracle dot com]

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



--- Comment #3 from Paolo Carlini  2012-10-05 
13:46:27 UTC ---

(as it happens, yesterday I noticed myself this behavior. It seems weird, but

maybe there is a rationale for it)

[Bug c++/45065] -fvisibility-inlines-hidden: Decl order in derived class affects visibility of inlines in base.

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



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



--- Comment #2 from Paolo Carlini  2012-10-05 
13:51:46 UTC ---

I can confirm the behavior with today's mainline. And seems weird indeed. Jason

can you help triaging this?

[Bug c++/54825] New: ICE with vector extension

[drepper.fsp at gmail dot com]

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



 Bug #: 54825

   Summary: ICE with vector extension

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: drepper@gmail.com

  Host: x86_64-linux





While trying to convert some of libstdc++ to use gcc's vector extensions I ran

into this ICE.  The code /should/ be valid.

[Bug c++/54825] ICE with vector extension

[drepper.fsp at gmail dot com]

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



--- Comment #1 from Ulrich Drepper  2012-10-05 
13:58:21 UTC ---

In case the version number isn't making this clear, I tested this with the

current mainline code.  4.7 probably won't work at all since some of the

features used have been added to the C++ frontend after 4.7.

[Bug c++/46147] g++ segfault compiling gnat 0.8.8 on mips-linux n32

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||rdsandiford at googlemail

   ||dot com



--- Comment #1 from Paolo Carlini  2012-10-05 
13:58:59 UTC ---

CC-ing mips maintainers.

[Bug c++/54825] ICE with vector extension

[drepper.fsp at gmail dot com]

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



--- Comment #2 from Ulrich Drepper  2012-10-05 
13:59:26 UTC ---

Created attachment 28363

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

Reproducer



Why didn't BZ add the file?...

[Bug c++/54825] ICE with vector extension

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #3 from Paolo Carlini  2012-10-05 
14:03:03 UTC ---

Maybe Marc is willing to delve a bit into this.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[paolo.carlini at oracle dot com]

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



--- Comment #7 from Paolo Carlini  2012-10-05 
14:10:11 UTC ---

Thanks a lot Daniel for the clarification. Thus I understand that currently GCC

is accepting *all sorts* of reinterpret_cast uses in constexpr functions,

right? That is, also those with unspecified result?

[Bug c++/49976] Cross (Linux->AIX) GCC crashes with Segmentation fault

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #7 from Paolo Carlini  2012-10-05 
14:12:56 UTC ---

Closing as fixed in 4.7.

[Bug c++/54825] ICE with vector extension

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-10-05

 Ever Confirmed|0   |1



--- Comment #4 from Richard Guenther  2012-10-05 
14:15:22 UTC ---

What ICE?  With what options?  The testcase doesn't compile for me at -O0:



/tmp/t.ii:586:36:   required from here

/tmp/t.ii:378:24: error: 'typeof' was not declared in this scope

  __v *= (typeof(__v)) { __mult * __param.stddev(),

^

/tmp/t.ii:397:24: error: 'typeof' was not declared in this scope

  __v *= (typeof(__v)) { __mult, __mult };



ah, -std=gnu++0x required ...



> ./cc1plus  -quiet /tmp/t.ii -msse4 -std=gnu++0x

/tmp/t.ii: In function '__m128i

__gnu_cxx::{anonymous}::__sse2_recursion(__m128i, __m128i, __m128i, __m128i)

[with long unsigned int __sl1 = 18ul; long unsigned int __sl2 = 1ul; long

unsigned int __sr1 = 11ul; long unsigned int __sr2 = 1ul; unsigned int __msk1 =

3758096367u; unsigned int __msk2 = 3724462975u; unsigned int __msk3 =

3220897791u; unsigned int __msk4 = 3221225462u; __m128i = __vector(2) long long

int]':

/tmp/t.ii:17:58: error: the last argument must be an 8-bit immediate

   return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);

  ^

/tmp/t.ii:32:58: error: the last argument must be an 8-bit immediate

   return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);

  ^



still not an ICE.  It's an error.  Compiles ok with optimization.



So - can you be a little more verbose?

[Bug lto/54824] [4.8 Regression] ICE in verify_loop_structure with LTO

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[daniel.kruegler at googlemail dot com]

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

--- Comment #8 from Daniel Krügler  
2012-10-05 14:17:18 UTC ---
(In reply to comment #7)
> Thus I understand that currently GCC is accepting *all sorts* of 
> reinterpret_cast uses in constexpr functions, right? That is, also those with
> unspecified result?

Correct. The introductory example belongs to this family, for example.

[Bug c++/54825] ICE with vector extension

[rguenth at gcc dot gnu.org]

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



Richard Guenther  changed:



   What|Removed |Added



 Status|WAITING |ASSIGNED

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

   |gnu.org |



--- Comment #5 from Paolo Carlini  2012-10-05 
14:19:56 UTC ---

(by the way, the errors reminds me PR54079: I wonder if we can close it or we

want to do something about it?)



--- Comment #6 from Richard Guenther  2012-10-05 
14:19:56 UTC ---

With -O2 it ICEs in PRE.  Mine.

[Bug c++/54825] ICE with vector extension

[paolo.carlini at oracle dot com]

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



Richard Guenther  changed:



   What|Removed |Added



 Status|WAITING |ASSIGNED

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

   |gnu.org |



--- Comment #5 from Paolo Carlini  2012-10-05 
14:19:56 UTC ---

(by the way, the errors reminds me PR54079: I wonder if we can close it or we

want to do something about it?)



--- Comment #6 from Richard Guenther  2012-10-05 
14:19:56 UTC ---

With -O2 it ICEs in PRE.  Mine.

[Bug c++/54825] ICE with vector extension

[rguenth at gcc dot gnu.org]

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



--- Comment #7 from Richard Guenther  2012-10-05 
14:28:25 UTC ---

Created attachment 28364

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

patch



patch I am testing.

[Bug c++/54825] ICE with vector extension

[glisse at gcc dot gnu.org]

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



--- Comment #8 from Marc Glisse  2012-10-05 14:29:07 
UTC ---

Hmm, how should I compile the code?



I tried with g++ bug.cc -std=c++11 but that fails because of typeof (you want

decltype instead). With -std=gnu++11, I get an error that "the last argument

must be an 8-bit immediate" in __builtin_ia32_psrldqi128, which seems like a

bug, but not the ICE reported here. Ah, if I remove the body of

__sse2_recursion (and make it non-inline) and compile with -O2, then I get an

ICE (but not with -O1) in tree-ssa-pre.c. Is that it? I'll look (but will

probably have to defer to more knowledgeable people).

[Bug c++/50893] [C++0x] explicitly defaulted virtual destructor throw specification

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com

   Target Milestone|--- |4.8.0



--- Comment #1 from Paolo Carlini  2012-10-05 
14:31:47 UTC ---

Works in mainline. I'm committing the testcase and closing the PR.

[Bug c++/54825] ICE with vector extension

[glisse at gcc dot gnu.org]

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



--- Comment #9 from Marc Glisse  2012-10-05 14:32:45 
UTC ---

(In reply to comment #8)



Forget my comment, apparently Richard found the bug before I could even read

the report... :-)

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

[howarth at nitro dot med.uc.edu]

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



Jack Howarth  changed:



   What|Removed |Added



 CC||howarth at nitro dot

   ||med.uc.edu



--- Comment #6 from Jack Howarth  2012-10-05 
14:33:13 UTC ---

MacPorts has broken their gcc47 package by adding the patch...



https://trac.macports.org/browser/trunk/dports/lang/gcc47/files/no-runtime-stubs.patch



which prevents FSF gcc 4.7.2 from linking in all of the additional libgcc

symbols from libgcc_ext which is where the ___emutls_v.* symbols reside.

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

[arnez at linux dot vnet.ibm.com]

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



 Bug #: 54826

   Summary: gdb test case failure (bs15503) due to gaps in lexical

block

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: debug

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

ReportedBy: ar...@linux.vnet.ibm.com





Current upstream gcc causes a regression with the gdb test case

bs15503.exp:

FAIL: gdb.cp/bs15503.exp: print s.length()

FAIL: gdb.cp/bs15503.exp: print s[0]

FAIL: gdb.cp/bs15503.exp: print s[s.length()-1]

FAIL: gdb.cp/bs15503.exp: print (const char *) s

FAIL: gdb.cp/bs15503.exp: print (const char *) s.substr(0,4)

FAIL: gdb.cp/bs15503.exp: print (const char *) (s=s.substr(0,4))



What happens is that the DWARF output for bs15503.cc wraps the string

variable "s" from StringTest::testFunction() in a lexical

block with spurious gaps.  The test case happens to set a break point

into one of these gaps and tries to access the variable from there,

which gdb (correctly) refuses.



For reference, here's a link to the source code:

http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/testsuite/gdb.cp/bs15503.cc?rev=1.11&cvsroot=src



I've verified the failure on x86_64 and s390x.  The regression was

introduced by: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191494

[Bug tree-optimization/54825] ICE with vector extension

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



  Component|c++ |tree-optimization



--- Comment #10 from Paolo Carlini  2012-10-05 
14:49:33 UTC ---

Ah great.

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #7 from Jack Howarth  2012-10-05 
14:58:31 UTC ---

Also note from https://trac.macports.org/ticket/36093 that it appears that

MacPorts is playing games with the libstdc++ which FSF gcc uses. This appears

to be instigated by https://trac.macports.org/ticket/36092.

[Bug c++/54775] string error

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Paolo Carlini  2012-10-05 
14:58:48 UTC ---

We started exporting the move assignment operator in GLIBCXX_3.4.14 thus circa

4.5.0 or only a bit earlier: confirmed that really the user has simply to make

sure that the dylib matching the headers is linked.

[Bug c++/50893] [C++0x] explicitly defaulted virtual destructor throw specification

[paolo at gcc dot gnu.org]

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



--- Comment #2 from paolo at gcc dot gnu.org  
2012-10-05 15:00:34 UTC ---

Author: paolo

Date: Fri Oct  5 15:00:26 2012

New Revision: 192131



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

Log:

2012-10-05  Paolo Carlini  



PR c++/50893

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



Added:

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

Modified:

trunk/gcc/testsuite/ChangeLog

[Bug c++/50893] [C++0x] explicitly defaulted virtual destructor throw specification

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Paolo Carlini  2012-10-05 
15:03:20 UTC ---

Done.

[Bug c++/23055] overload resolution does not find templated function (zero -> pointer)

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



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

  Known to fail||



--- Comment #8 from Paolo Carlini  2012-10-05 
15:07:16 UTC ---

This issue is accumulating duplicates. Then I'm wondering if it would be hard

to fix it or not... Likely Jason can guess better than me ;)

[Bug tree-optimization/54825] ICE with vector extension

[drepper.fsp at gmail dot com]

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



--- Comment #11 from Ulrich Drepper  2012-10-05 
15:12:18 UTC ---

(In reply to comment #7)

> Created attachment 28364 [details]

> patch

> 

> patch I am testing.



This seems to fix the problem for me, even with the original code and not the

reduced test case.

[Bug c++/54194] misleading suggestion about arithmetic in operand of '|'

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com



--- Comment #3 from Paolo Carlini  2012-10-05 
15:36:35 UTC ---

Ok, I have the straightforward patch changing the position of the caret to the

'|'. This is certainly suboptimal but totally consistent with the existing

warn_about_parentheses infrastructure which generically mentions the operands

and prints *that* operator. I suppose that for long expressions the change can

make for a good improvement.

[Bug c++/50080] [DR 468] error: 'template' (as a disambiguator) is only allowed within templates

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com



--- Comment #4 from Paolo Carlini  2012-10-05 
16:15:22 UTC ---

Looking at cp_parser_optional_template_keyword, this seems very easy to fix.

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[glisse at gcc dot gnu.org]

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



--- Comment #32 from Marc Glisse  2012-10-05 
16:20:59 UTC ---

Author: glisse

Date: Fri Oct  5 16:20:44 2012

New Revision: 192132



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

Log:

2012-10-05  Marc Glisse  



PR libstdc++/54686

* include/c_std/cstdlib (abs(long long)): Define with

__builtin_llabs when we have long long.

(abs(long)): Use __builtin_labs.

(abs(__int128)): Define when we have __int128.

* testsuite/26_numerics/headers/cstdlib/54686.c: New file.





Added:

trunk/libstdc++-v3/testsuite/26_numerics/headers/cstdlib/54686.c   (with

props)

Modified:

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/include/c_std/cstdlib



Propchange: trunk/libstdc++-v3/testsuite/26_numerics/headers/cstdlib/54686.c

('svn:eol-style' added)



Propchange: trunk/libstdc++-v3/testsuite/26_numerics/headers/cstdlib/54686.c

('svn:keywords' added)

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #33 from Marc Glisse  2012-10-05 
16:24:02 UTC ---

Fixed on trunk. I am not backporting that.

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[paolo.carlini at oracle dot com]

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



--- Comment #34 from Paolo Carlini  2012-10-05 
16:24:57 UTC ---

Looks like you forgot the include/c_global/cstdlib bits?

[Bug c++/54194] misleading suggestion about arithmetic in operand of '|'

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  2012-10-05 
16:26:22 UTC ---
Using warning_at is an improvement, yes.

It still doesn't clarify where the parentheses should go, or why the
parentheses are suggested. This is why clang changed the text of the warning. I
seem to remember this as an example of cryptic diagnostic from GCC in some
Clang presentation. Perhaps the massive takedown by Carruth at GoingNative2012
? Bah, I am not going to watch that again just to check.

I personally, find the "& within |" message quite cryptic. My suggestion would
be something like:

warning: precedence of '&' within '|' may be confusing without parentheses
note: if correct, place parentheses around '&' expression to silence this
warning

The warning could point to '|', the note could point to '&'. Alternatively,
there may be a way to say everything in an even shorter line.

[Bug c++/54194] misleading suggestion about arithmetic in operand of '|'

[paolo.carlini at oracle dot com]

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



--- Comment #5 from Paolo Carlini  2012-10-05 
16:32:02 UTC ---

Sure. Since the patch simply using warning_at is trivial and anyway

warn_about_parentheses is currently shared with the C front end, I propose to

just do that for 4.8.0. I'm attaching what I have regtested. I think it would

be a definite improvement. Tell me what you think. If you disagree, no problem,

I can move to something else and completely delay this issue to a later time.

[Bug c++/54194] misleading suggestion about arithmetic in operand of '|'

[paolo.carlini at oracle dot com]

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



--- Comment #6 from Paolo Carlini  2012-10-05 
16:32:57 UTC ---

Created attachment 28365

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

Tested.

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[glisse at gcc dot gnu.org]

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



--- Comment #35 from Marc Glisse  2012-10-05 
16:33:48 UTC ---

(In reply to comment #34)

> Looks like you forgot the include/c_global/cstdlib bits?



Hmm right, I patched the wrong directory. Maybe c_std/cstdlib should be

removed? It looks like a clone of the file c_global/cstdlib except that it

hasn't been kept up to date...

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[paolo.carlini at oracle dot com]

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



--- Comment #36 from Paolo Carlini  2012-10-05 
16:39:27 UTC ---

What I know is that Linux by default uses c_global. There is configury

selecting the directory, but I didn't write the logic, Benjamin did, frankly I

don't know which specific target use c_std these times. In such case the safe

thing to do in my opinion is changing in a consistent way existing bits in the

headers and not adding or removing anything else.

[Bug c++/54194] misleading suggestion about arithmetic in operand of '|'

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  2012-10-05 
16:41:51 UTC ---
(In reply to comment #5)
> Tell me what you think. If you disagree, no problem,
> I can move to something else and completely delay this issue to a later time.

Me? I am certainly not going to discard something good to wait for something
perfect. Just saying what may improve over what clang has. But if it was up to
me, I would give you a pre-approval to change any warning() to use either
input_location or a better location, if that is possible, and let you decide
which location is better.

[Bug c++/54194] misleading suggestion about arithmetic in operand of '|'

[paolo.carlini at oracle dot com]

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



--- Comment #8 from Paolo Carlini  2012-10-05 
16:47:19 UTC ---

Eh, eh ;) Good, good, I only wanted to make sure we are on the same page on the

issue. For now I'm sending to the mailing list what I have, then we'll see if

we can improve on it.

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[glisse at gcc dot gnu.org]

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



--- Comment #37 from Marc Glisse  2012-10-05 
16:47:33 UTC ---

I see the following in cstdlib:



namespace std

{

#if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC

  // types

  using std::lldiv_t;





Is there a particular reason to import stuff into its own namespace?

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[paolo.carlini at oracle dot com]

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



--- Comment #38 from Paolo Carlini  2012-10-05 
16:57:56 UTC ---

Eh, eh, hard to reconstruct now what happened at the time. Looks like an svn

pasto or a plain pasto. I suppose that entire block can be removed?

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[paolo.carlini at oracle dot com]

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



--- Comment #39 from Paolo Carlini  2012-10-05 
17:02:34 UTC ---

Probably a plain pasto of mine dating back to when was copying stuff from tr1/*

in namespace std::tr1 to std:: protected by __GXX_EXPERIMENTAL_CXX0X__. Looks

like I didn't notice that in this specific case the std version of the

facilities exists in C++98 mode too (as a GNU C99 extension). Eh ;)

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[glisse at gcc dot gnu.org]

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



--- Comment #40 from Marc Glisse  2012-10-05 
17:04:35 UTC ---

(In reply to comment #38)

> Eh, eh, hard to reconstruct now what happened at the time. Looks like an svn

> pasto or a plain pasto. I suppose that entire block can be removed?



Probably, I'll leave that to you. Testing for the patch adding abs is in

progress.



Removing that block would make the c_global and c_std versions even closer...

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[paolo.carlini at oracle dot com]

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



--- Comment #41 from Paolo Carlini  2012-10-05 
17:08:52 UTC ---

Remove it, remove it.

[Bug c++/51412] [c++0x] Broken diagnostic with invalid lambda expressions

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com



--- Comment #1 from Paolo Carlini  2012-10-05 
17:14:38 UTC ---

Seems easy.

[Bug middle-end/54827] New: [4.8 Regression] 70% compile time regression building builtin-sched.c from Linux's perf

[markus at trippelsdorf dot de]

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



 Bug #: 54827

   Summary: [4.8 Regression] 70% compile time regression building

builtin-sched.c from Linux's perf

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: mar...@trippelsdorf.de





With gcc-4.7.2 I get:



 % time gcc -c -O3 -g builtin-sched.i

gcc -c -O3 -g builtin-sched.i  12.63s user 0.02s system 99% cpu 12.690 total



With current trunk:



 % time gcc -c -O3 -g  builtin-sched.i

gcc -c -O3 -g builtin-sched.i  40.54s user 0.03s system 99% cpu 40.703 total



perf report shows:

54.58%  cc1  cc1 [.] find_base_term(rtx_def*)

 8.02%  cc1  cc1 [.]

ix86_find_base_term(rtx_def*)

 3.55%  cc1  cc1 [.]

rtx_equal_for_memref_p(rtx_def const*, rtx_def const*)

 2.91%  cc1  cc1 [.] true_dependence_1(rtx_def

const*, machine_mode, rtx_def*, rtx_def const*, rtx_def*, bool)

 2.79%  cc1  cc1 [.] memrefs_conflict_p(int,

rtx_def*, int, rtx_def*, long)

 2.77%  cc1  cc1 [.] exp_equiv_p(rtx_def

const*, rtx_def const*, int, bool)

 2.01%  cc1  cc1 [.] for_each_rtx_1(rtx_def*,

int, int (*)(rtx_def**, void*), void*)

 1.76%  cc1  cc1 [.] rtx_equal_p(rtx_def

const*, rtx_def const*)



-ftime-report:

Execution times (seconds)

 phase setup :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 

  1101 kB ( 3%) ggc

 phase parsing   :   0.07 ( 0%) usr   0.07 (70%) sys   0.14 ( 0%) wall 

 13463 kB (32%) ggc

 phase opt and generate  :  39.64 (100%) usr   0.03 (30%) sys  39.79 (100%)

wall   26000 kB (62%) ggc

...

 variable tracking   :   1.58 ( 4%) usr   0.00 ( 0%) sys   1.57 ( 4%) wall 

  1210 kB ( 3%) ggc

 var-tracking dataflow   :  13.68 (34%) usr   0.00 ( 0%) sys  13.71 (34%) wall 

   107 kB ( 0%) ggc

 var-tracking emit   :  14.20 (36%) usr   0.00 ( 0%) sys  14.26 (36%) wall 

   435 kB ( 1%) ggc

...

 TOTAL :  39.74 0.1039.96 

41799 kB

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

[jeremyhu at macports dot org]

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



Jeremy Huddleston  changed:



   What|Removed |Added



 CC||jeremyhu at macports dot

   ||org



--- Comment #8 from Jeremy Huddleston  2012-10-05 
17:41:16 UTC ---

I don't know that we're playing "games" with which libstdc++ gcc uses at link

time.  Instead of having multiple copies of libstdc++ lying around, you now

have one, and it's either built from gcc-4.8 (the libstdcxx-devel port) or from

gcc-4.7 (the libstdcxx port).  It lives as ${prefix}/lib/libstdc++.6.dylib, and

is picked up by g++-mp-XX by way of their libstdc++.dylib symlinks.



Additionally, we hope to eventually move this libstdc++ on top of libc++abi

instead of libsupc++, so it can co-exist with the host libc++ and libstdc++ in

the same address space (users seem to do mixing of the C++ runtimes which is

what instigated the libstdcxx port to begin with).



As for the no-runtime-stubs.patch patch, that is *NOT* used to build gcc47. 

That is only used in the process of building libstdc++.6.dylib in the libstdcxx

port, and it is done in order to intentionally not have the resulting

libstdc++.dylib link against the libgcc runtime dynamically.  The gcc

buildsystem is so convoluted that this seemed to be the easiest way to ensure

that the resulting libstdc++.dylib picked up its gcc runtime statically.

[Bug middle-end/54827] [4.8 Regression] 70% compile time regression building builtin-sched.c from Linux's perf

[markus at trippelsdorf dot de]

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



--- Comment #1 from Markus Trippelsdorf  
2012-10-05 17:41:20 UTC ---

Created attachment 28366

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

testcase

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

[jeremyhu at macports dot org]

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



--- Comment #9 from Jeremy Huddleston  2012-10-05 
17:47:02 UTC ---

The one build config change on MP side that accompanied the version bump was

that we now build with --enable-libstdcxx-time for

http://trac.macports.org/ticket/36364

[Bug middle-end/54827] [4.8 Regression] 70% compile time regression building builtin-sched.c from Linux's perf

[markus at trippelsdorf dot de]

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



--- Comment #2 from Markus Trippelsdorf  
2012-10-05 17:54:57 UTC ---

Caused by var-tracking. With-fno-var-tracking everything is fine again:



 % time gcc -fno-var-tracking -w -c -O3 -ggdb3 builtin-sched.i

gcc -fno-var-tracking -w -c -O3 -ggdb3 builtin-sched.i  10.50s user 0.04s

system 99% cpu 10.574 total

[Bug middle-end/54827] [4.8 Regression] 70% compile time regression building builtin-sched.c from Linux's perf

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #3 from Markus Trippelsdorf  
2012-10-05 17:57:08 UTC ---

Dup of 54402



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

[Bug debug/54402] [4.8 Regression] var-tracking does not scale

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #1 from Markus Trippelsdorf  
2012-10-05 17:57:08 UTC ---

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

[Bug fortran/51727] Changing module files

[Joost.VandeVondele at mat dot ethz.ch]

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



Joost VandeVondele  changed:



   What|Removed |Added



 CC||simonb at google dot com



--- Comment #1 from Joost VandeVondele  
2012-10-05 18:16:41 UTC ---

Also reported here:



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



this is the source of recompilation cascades sometimes seen in CP2K as well.



I'm wondering if a very naive hack like sorting .mod content (like in cat

old.mod 1 | sort -s > new.mod) could not paper over this problem sufficiently

well to make it irrelevant in reality.

[Bug go/54507] libgo testsuite does not timeout compilation

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Depends on||54402



--- Comment #2 from Uros Bizjak  2012-10-05 18:19:40 
UTC ---

The var-tracking problem is PR54402.

[Bug debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables

[bkoz at gcc dot gnu.org]

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



Benjamin Kosnik  changed:



   What|Removed |Added



   Severity|normal  |major

[Bug bootstrap/51742] 4.6.2 v. HP-UX 11.11, PA-RISC: "make bootstrap-lean" fails: "internal compiler error: Segmentation fault" (In function '__fixunssfdi')

[spamtlo at gmail dot com]

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



Thomas Lofgren  changed:



   What|Removed |Added



 CC||spamtlo at gmail dot com



--- Comment #5 from Thomas Lofgren  2012-10-05 
18:56:59 UTC ---

I've also hit this bug. I'm attempting to use gcc 4.4.2 to compile gcc 4.7.0

and 4.7.2. Neither works.





/home/trees/p4/sandbox/external/pre-built/src/gcc/4.7.2/objs/./gcc/xgcc

-B/home/trees/p4/sandbox/external/pre-built/src/gcc/4.7.2/objs/./gcc/

-B/usr/local/gcc-4.7.2/hppa2.0w-hp-hpux11.11/bin/

-B/usr/local/gcc-4.7.2/hppa2.0w-hp-hpux11.11/lib/ -isystem

/usr/local/gcc-4.7.2/hppa2.0w-hp-hpux11.11/include -isystem

/usr/local/gcc-4.7.2/hppa2.0w-hp-hpux11.11/sys-include-g -O2 -O2  -g -O2

-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes

-Wmissing-prototypes -Wold-style-definition  -isystem ./include  

-frandom-seed=fixed-seed -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc

-fno-stack-protector   -frandom-seed=fixed-seed -fPIC -I. -I. -I../.././gcc

-I../../../gcc-4.7.2/libgcc -I../../../gcc-4.7.2/libgcc/.

-I../../../gcc-4.7.2/libgcc/../gcc -I../../../gcc-4.7.2/libgcc/../include 

-DHAVE_CC_TLS -DUSE_EMUTLS -o _fixunssfdi.o -MT _fixunssfdi.o -MD -MP -MF

_fixunssfdi.dep -DL_fixunssfdi -c ../../../gcc-4.7.2/libgcc/libgcc2.c 

../../../gcc-4.7.2/libgcc/libgcc2.c: In function '__fixunssfdi':

../../../gcc-4.7.2/libgcc/libgcc2.c:1336:3: internal compiler error:

Segmentation fault

[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent

[glisse at gcc dot gnu.org]

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



--- Comment #42 from Marc Glisse  2012-10-05 
19:10:27 UTC ---

Author: glisse

Date: Fri Oct  5 19:10:22 2012

New Revision: 192138



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

Log:

2012-10-05  Marc Glisse  



PR libstdc++/54686

* include/c_global/cstdlib (abs(long long)): Define with

__builtin_llabs when we have long long.

(abs(long)): Use __builtin_labs.

(abs(__int128)): Define when we have __int128.





Modified:

trunk/libstdc++-v3/ChangeLog

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

[Bug debug/54519] [4.6/4.7/4.8 Regression] Debug info quality regression due to (pointless) partial inlining

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2012-10-05 
19:24:41 UTC ---

Author: jakub

Date: Fri Oct  5 19:24:38 2012

New Revision: 192139



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

Log:

PR debug/54519

* ipa-split.c (split_function): Add debug args and

debug source and normal stmts for args_to_skip which are

gimple regs.

* tree-inline.c (copy_debug_stmt): When inlining, adjust

source debug bind stmts to debug binds of corresponding

DEBUG_EXPR_DECL.



* gcc.dg/guality/pr54519-1.c: New test.

* gcc.dg/guality/pr54519-2.c: New test.

* gcc.dg/guality/pr54519-3.c: New test.

* gcc.dg/guality/pr54519-4.c: New test.

* gcc.dg/guality/pr54519-5.c: New test.

* gcc.dg/guality/pr54519-6.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/guality/pr54519-1.c

trunk/gcc/testsuite/gcc.dg/guality/pr54519-2.c

trunk/gcc/testsuite/gcc.dg/guality/pr54519-3.c

trunk/gcc/testsuite/gcc.dg/guality/pr54519-4.c

trunk/gcc/testsuite/gcc.dg/guality/pr54519-5.c

trunk/gcc/testsuite/gcc.dg/guality/pr54519-6.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/ipa-split.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-inline.c

[Bug c++/51490] [c++11] push_class_level_binding internal error on class scoping within a lambda expression

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

  Known to work||4.7.0, 4.8.0

 Resolution||WORKSFORME



--- Comment #2 from Paolo Carlini  2012-10-05 
19:25:25 UTC ---

Works in mainline and 4.7.

[Bug c++/51556] Bizarre member template access control errors

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

  Known to work||4.7.0, 4.8.0

 Resolution||WORKSFORME



--- Comment #7 from Paolo Carlini  2012-10-05 
19:28:51 UTC ---

Works in mainline and 4.7.

[Bug c++/52174] [DR 1423] Implicit conversion of nullptr to bool

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|SUSPENDED   |NEW

   Severity|trivial |normal



--- Comment #5 from Paolo Carlini  2012-10-05 
19:31:08 UTC ---

Unsuspending then.

[Bug c++/52581] ICE with gcc-4.7 for H8300-elf target.

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||INVALID



--- Comment #3 from Paolo Carlini  2012-10-05 
19:32:17 UTC ---

Feedback not forthcoming.

[Bug fortran/51727] Changing module files

[tobi at gcc dot gnu.org]

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

--- Comment #2 from Tobias Schlüter  2012-10-05 
19:35:36 UTC ---
I'm not in a position to test, but write_generic in module.c makes no effort to
traverse the tree in a left to right order, i.e. the line
  write_generic ((gfc_symtree *)st->right);
should be moved to the bottom of the function.

[Bug c++/52792] this pointer and return pointer are passed in wrong order when ms_abi is used (x86_64)

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||cgf at gcc dot gnu.org,

   ||ktietz at gcc dot gnu.org



--- Comment #1 from Paolo Carlini  2012-10-05 
19:36:33 UTC ---

Not sure if the Christopher and Kai spend time also on the C++ front-end bits,

but CC-ing them anyway.

[Bug c++/52791] structure should always be returned by passing a hidden argument with ms_abi, x86_64

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||cgf at gcc dot gnu.org,

   ||ktietz at gcc dot gnu.org



--- Comment #1 from Paolo Carlini  2012-10-05 
19:38:03 UTC ---

Likewise.

[Bug c++/53845] Another "error reporting routines re-entered" issue

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC|paolo.carlini at oracle dot |

   |com |

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #6 from Paolo Carlini  2012-10-05 
19:39:53 UTC ---

For sure the "error reporting routines re-entered" is gone.

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

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-05

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2012-10-05 
20:53:35 UTC ---

Uhm, this is not trivial to fix. The difference between P1 and P3 is that for

the former from build_delete we call build_dtor_call which eventually also

calls the required perform_or_defer_access_check, whereas for the latter the

function just notices that TYPE_HAS_TRIVIAL_DESTRUCTOR and early returns (via

build_op_delete_call). Arguably, a TYPE_HAS_TRIVIAL_DESTRUCTOR true for a

destructor which actually is private and can't be called sounds a bit strange

but for sure the choice makes sense wrt the rest of the front-end and the

standard... I'll double check soon a few things.



Anyway, here, I only wanted to ask you if this is a show-stopper for your work,

because I don't know how much time it will take.

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

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  
2012-10-05 21:00:31 UTC ---
(In reply to comment #1)
> Anyway, here, I only wanted to ask you if this is a show-stopper for your 
> work,
> because I don't know how much time it will take.

While I think that this should be fixed, it will only prevent that I would
directly convert is_constructible to use the combined 

::delete ::new ((void*) nullptr) T(args) 

expression. Our current implementation is not sensitive to this problem,
because we use is_destructible within. I noticed that there are still a bunches
of opportunities to simplify is_constructible (and friends) because a lot of
previous compiler defects have been fixed. So, really no need to hurry!

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

[paolo.carlini at oracle dot com]

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



--- Comment #3 from Paolo Carlini  2012-10-05 
21:08:04 UTC ---

Of course it should be fixed, it *must* be fixed, actually! And it's really

annoying that this bug affecting private defaulted destructors (which, I bet,

aren't that common for most programs not using SFINAE tricks!?!) is preventing

us from deploying right now the very elegant ::delete ::new pattern which

otherwise finally works pretty well. What can I add? Do your best, and thanks

again!