Re: x32 psABI draft version 0.2
On 18.02.11 at 18:53, H.J. Lu hjl.to...@gmail.com wrote: How about only allowing REL relocations in executables and DSOes? That'd be at least part of it, but I'd still prefer not forbidding them altogether, but also not requiring an implementation to support them (just to repeat it - in a long abandoned new OS of ours we had ignored the forbidding, and allowed REL in relocatable objects [which were the only objects used there, the loadable ones distinguished from normal ones by the presence of some OS- specific data structures], with the static linker picking the type depending on the module's needs). Jan
Triplet for ARM Linux HardFP ABI, again
Hi!
This was already discussed in this list some time ago [0]. But it came
up again when restarting the discussion for the proposed new armhf port
for Debian.
[0] http://gcc.gnu.org/ml/gcc/2010-07/msg00179.html
My arguments for why a distinct triplet is needed can be found in [1],
it's a big long though. Most of the points there revolve around the
fact that we rely on the toolchains as configured by _default_ to
produce the expected output targetting a concrete architecture, it
also has implications for the file system paths.
[1] http://lists.debian.org/debian-dpkg/2011/02/msg00039.html
It seems from reading the past discussion on this list that the main
objection was that the triplet should not be used to decide what
floating point ABI to use in gcc. No problem with that!
So, given the arguments put forward in [1], which I think are quite
compelling (but then I guess I'm obviously biased), I was wondering
if you'd consider accepting something ressembling the attached patch
(completely untested, though), which would seem like a compromise we
all might be able to live with, and which would allows us to use a
unique triplet, w/o needing to abuse the vendor field, while gcc would
not need to do anything based on that, our Debian gcc packaging
would choose the floating point ABI depending on the target Debian
architecture, in the same way we do other ABI selections independently
from the triplet.
thanks,
guillem
diff --git a/configure b/configure
index 501c6ff..0bdf69a 100755
--- a/configure
+++ b/configure
@@ -3236,7 +3236,7 @@ case ${target} in
noconfigdirs=$noconfigdirs target-libffi target-qthreads
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-gnueabi*)
noconfigdirs=$noconfigdirs target-qthreads
case ${with_newlib} in
no) noconfigdirs=$noconfigdirs target-newlib target-libgloss
diff --git a/configure.ac b/configure.ac
index 9121d65..89514f5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -682,7 +682,7 @@ case ${target} in
noconfigdirs=$noconfigdirs target-libffi target-qthreads
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-gnueabi*)
noconfigdirs=$noconfigdirs target-qthreads
case ${with_newlib} in
no) noconfigdirs=$noconfigdirs target-newlib target-libgloss
diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index b64ba55..642b317 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -1841,7 +1841,7 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(arch) $(osys))),)
LIBRARY_VERSION := $(LIB_VERSION)
endif
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 4,$(targ,)
+ifeq ($(strip $(filter-out arm% linux-gnueabi%,$(arch) $(osys)-$(word 4,$(targ,)
LIBGNAT_TARGET_PAIRS = \
a-intnam.adsa-intnam-linux.ads \
s-inmaop.adbs-inmaop-posix.adb \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 54b822e..1a47343 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -820,13 +820,13 @@ arm*-*-linux*) # ARM GNU/Linux with ELF
esac
tmake_file=${tmake_file} t-linux arm/t-arm
case ${target} in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h
tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h
tmake_file=$tmake_file arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi t-slibgcc-libgcc
# Define multilib configuration for arm-linux-androideabi.
case ${target} in
- *-androideabi)
+ *-androideabi*)
tmake_file=$tmake_file arm/t-linux-androideabi
;;
esac
@@ -848,7 +848,7 @@ arm*-*-uclinux*) # ARM ucLinux
tm_file=dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h arm/uclinux-elf.h glibc-stdint.h
tmake_file=arm/t-arm arm/t-arm-elf
case ${target} in
- arm*-*-uclinux*eabi)
+ arm*-*-uclinux*eabi*)
tm_file=$tm_file arm/bpabi.h arm/uclinux-eabi.h
tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h
tmake_file=$tmake_file arm/t-bpabi
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 02cb7ac..fbd5e78 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3219,7 +3219,7 @@ proc check_effective_target_sync_int_long { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
- || [istarget arm*-*-linux-gnueabi]
+ || [istarget arm*-*-linux-gnueabi*]
|| [istarget bfin*-*linux*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
@@ -3250,7 +3250,7 @@ proc check_effective_target_sync_char_short { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
- || [istarget arm*-*-linux-gnueabi]
+ || [istarget arm*-*-linux-gnueabi*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
diff --git a/libjava/configure b/libjava/configure
index f79e53b..2084c68
Re: Parma Polyhedra Library 0.11.1
On 02/21/2011 04:42 AM, Jack Howarth wrote:
On Sun, Feb 20, 2011 at 06:32:30PM +0100, Prof. Roberto Bagnara wrote:
We announce the availability of PPL 0.11.1, a new release of the Parma
Polyhedra Library. This release includes several important bug fixes
and performance improvements.
Roberto,
Have you had any reports of installation problems?
Hi Jack.
No, your report was the first one.
After installing
doxygen, texlive for pdflatex and graphviz for dot, I am still running into
installation failures for the documentation. These currently appear as...
Writing index file refman.idx
No file refman.aux.
(/sw/share/texmf-dist/tex/latex/base/ts1cmr.fd)
(/sw/share/texmf-dist/tex/latex/psnfss/t1ptm.fd)
(/sw/share/texmf-dist/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/sw/share/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/sw/share/texmf-dist/tex/latex/oberdiek/grfext.sty)
(/sw/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
(/sw/share/texmf-dist/tex/latex/graphics/color.sty
(/sw/share/texmf-dist/tex/latex/latexconfig/color.cfg))
(/sw/share/texmf-dist/tex/latex/hyperref/nameref.sty
(/sw/share/texmf-dist/tex/latex/oberdiek/refcount.sty)
(/sw/share/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
(/sw/share/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/sw/share/texmf-dist/tex/latex/amsfonts/umsb.fd)
(/sw/share/texmf-dist/tex/latex/stmaryrd/Ustmry.fd) [1{/sw/var/lib/texmf/fonts/
map/pdftex/updmap/pdftex.map}] (/sw/share/texmf-dist/tex/latex/psnfss/ts1ptm.fd
) (/sw/share/texmf-dist/tex/latex/psnfss/t1pcr.fd) (./main.texpdfTeX warning (e
xt4): destination with the same identifier (name{page.1}) has been already used
, duplicate ignored
to be read again
\relax
l.17 ...ry.Parma\_\-Polyhedra\_\-Library}};\item S
tarting from version 0.11,...
[1]
Underfull \hbox (badness 1337) in paragraph at lines 26--26
[]\T1/ptm/m/n/10 boxes which con-sist of Int8_-Box, Int16_-Box, Int32_-Box, Int
64_-Box, Uint8_-Box,
Hmmm... this is very strange. I would like to reproduce the issue:
which version of Doxygen are you using?
) (/sw/src/fink.build/ppl9-0.11.1-0/ppl-0.11.1/build/../doc/GPL.tex
! LaTeX Error: Can be used only in preamble.
See the LaTeX manual or LaTeX Companion for explanation.
Type Hreturn for immediate help.
...
l.1 \documentclass
[a4paper,12pt]{article}
?
This is even stranger: the file name should be `gpl.tex', not `GPL.tex'
Can you please double check in the `doc' subdirectory?
Cheers,
Roberto
--
Prof. Roberto Bagnara CEO CTO
Applied Formal Methods Laboratory BUGSENG srl
Department of Mathematics Parco Area delle Scienze 53/A
University of Parma, ItalyI-43124 Parma, Italy
http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Release 0.9 of mpc
The mpc development team is pleased to announce the release 0.9 of the library, Epilobium montanum. For more information, please see http://mpc.multiprecision.org/ . Andreas
Pretty ipa branch reopened
Hi, I've copied mainline to pretty-ipa branch killing all the changes that was left unmerged there. I intend to use it for IPA and LTO related development to be merged at next stage1, immediately for the inliner related cleanups we seems to be cummulating at the mainling list. I would like the patches to be in form submittable for mainline at stage1, but I expect merging to happen by parts (even when it will make sense to merge i.e. all ipa-inline changes at once if tested correctly). Richi, please commit the cleanup changes, but wait after frescobaldi picks current tree for testing. Old version of branch should be now in old-pretty-ipa for reference, but there is not much useful left. Honza
Re: Find a new maintainer for option handling?
Hi, Any news about this? Regards, Jie On Tue, Jan 25, 2011 at 2:34 AM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 17 Jan 2011, Gerald Pfeifer wrote: On Wed, 12 Jan 2011, Jie Zhang wrote: I agree. I think Joseph is the best candidate for the maintainer of the option handling since he made the most changes of gcc/opts-common.c. He is already the maintainer of the driver. If we unify these two maintainerships, we save one line of MAINTAINERS. :-) I am not so much concerned about that one line in MAINTAINERS, more finding someone who is willing to take on the role. I, too, think Joseph would be a great candidate, but it's his call whether he wants to. ;-) (I'll be happy to raise it on the SC in case.) I am willing to be considered for option handling maintainership or reviewership. -- Joseph S. Myers jos...@codesourcery.com
Re: Find a new maintainer for option handling?
Sorry, I just noticed that Joseph has been listed as the maintainer of option handling. Jie On 02/21/2011 11:56 PM, Jie Zhang wrote: Hi, Any news about this? Regards, Jie On Tue, Jan 25, 2011 at 2:34 AM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 17 Jan 2011, Gerald Pfeifer wrote: On Wed, 12 Jan 2011, Jie Zhang wrote: I agree. I think Joseph is the best candidate for the maintainer of the option handling since he made the most changes of gcc/opts-common.c. He is already the maintainer of the driver. If we unify these two maintainerships, we save one line of MAINTAINERS. :-) I am not so much concerned about that one line in MAINTAINERS, more finding someone who is willing to take on the role. I, too, think Joseph would be a great candidate, but it's his call whether he wants to. ;-) (I'll be happy to raise it on the SC in case.) I am willing to be considered for option handling maintainership or reviewership. -- Joseph S. Myers jos...@codesourcery.com -- Jie Zhang
Re: AIX vs long double
On 01/-10/-28163 08:59 PM, David Edelsohn wrote: AIX provides two versions of long double and declares all of the C99 long double symbols in math.h header file. One implementation aliases long double to IEEE double precision type and the other implementation aliases long double to IBM's paired double format. All of the C99 symbols for IEEE double precision are implemented in libm, but not all of the C99 symbols for the IBM long double format are implemented. IBM's proprietary XL compiler (cc, xlc) defaults to IEEE double precision and provides a special invocation to default to IBM long double (cc128, xlc128). GNU/Linux and GCC on GNU/Linux default to IEEE quad precision long double. Just to make sure I got the type names for the different bitwidths right: IEEE double precision: 64bit IEEE quad precision: 128bit IBM's paired double: 128bit, identical to IEEE quad precision? Because the long double choice is an ABI change, GCC on AIX switched to GNU/Linux compatibility with support for AIX 6.1, before the incomplete implementation was noticed. This mostly worked until Well, even that change still is incomplete within gcc, as it should link against libc128 before libc, because even printf(%Lf) is broken right now when not explicitly adding '-lc128' to the linkline. Reading bug [target/19115], the reason for that switch seems not to have been Linux compatibility at all, but AIX libc providing 128bit math functions frexpl, ldexpl and modfl before they went into C99 standard, and including math.h might have been missing somewhere within libstdc++ to get their correct implementation for the selected long double bitwidth. libgfortran started using additional C99 functions, causing GCC Bugzilla [target/47032] libgfortran references complex long double functions missing on AIX libstdc++-v3 on AIX builds with AIX long double support, IMO, long double bitwidth should be another multilib criterion on AIX, selected by -mlong-double-64 and -mlong-double-128. As there are a bunch of multilib criterions on AIX already: Even on AIX 5.3 I get the impression that there is no need for pthread being a multilib criterion any more, as /usr/lib/threads/libc.a is a symlink to /usr/ccs/lib/libc.a - but I may be wrong here wrt STARTFILE_SPEC. although user programs that try to access the missing functions (copysign, nextafter, etc.) will experience link-time failures. libgfortran on AIX fails to build with AIX long double support because it accesses the missing functions in its implementation. I would like to solicit feedback about how to proceed: Should GCC on AIX revert back to 64 bit long double size, allowing all libraries to build and work, but breaking GCC/G++ ABI on AIX? Or should it continue to utilize 128 bit long double, building libstdc++-v3 that works if the user program does not utilize the missing symbols and fails to build libgfortran? Please remember that even printf is broken on AIX 6.1 now. I doubt people (know to) add '-lc128' when building with gcc on AIX 6.1 at all. And not having the gcc-libraries with long-double-64 support available prevents mixing gcc-built libraries with xlc-built libraries. FWIW: For C++, AIX 6.1 math.h defines public inline functions to rename math functions (except frexpl, ldexpl, modfl) to the __FFl128 variant. This does not work with gcc when building with -O0, as they result in weak symbols, being ignored at linktime due to static symbols from libm.a with original name and using 64bit long double. This is reported to IBM and I got confirmation last week that they're working on how to fix it. Thank you! /haubi/
Re: [Python-Dev] Bug in linking to gomp with python; causes crash in matplotlib.
An associated bug report would be appreciated (mailing list discussions are useful for raising awareness, but are more likely to be forgotten over time than bug reports): http://bugs.python.org Just did that; thanks! -- Hoyt + Hoyt Koepke + University of Washington Department of Statistics + http://www.stat.washington.edu/~hoytak/ + hoy...@gmail.com ++
Re: Triplet for ARM Linux HardFP ABI, again
On Mon, 21 Feb 2011, Guillem Jover wrote: if you'd consider accepting something ressembling the attached patch A pre-existing condition, but in general where the code you're changing hardcodes gnu that's wrong - arm*-*-linux-uclibceabi is also meant to be valid. So if you allow a suffix here, the general form to accept consistently would be arm*-*-linux-*eabi*. -- Joseph S. Myers jos...@codesourcery.com
x32 psABI draft version 0.3
On Mon, Feb 21, 2011 at 12:04 AM, Jan Beulich jbeul...@novell.com wrote: On 18.02.11 at 18:53, H.J. Lu hjl.to...@gmail.com wrote: How about only allowing REL relocations in executables and DSOes? That'd be at least part of it, but I'd still prefer not forbidding them altogether, but also not requiring an implementation to support them (just to repeat it - in a long abandoned new OS of ours we had ignored the forbidding, and allowed REL in relocatable objects [which were the only objects used there, the loadable ones distinguished from normal ones by the presence of some OS- specific data structures], with the static linker picking the type depending on the module's needs). I updated x32 psABI draft to version 0.3 with --- The AMD64 LP64 ABI architecture uses only Elf64_Rela relocation entries with explicit addends. The r_addend member serves as the relocation addend. The AMD64 X32 ABI architecture uses only Elf32_Rela relocation entries in relocatable files. Relocations contained within executable files or shared objects may use either Elf32_Rela relocation or Elf32_Rel relocation. --- which is similar to ia64 psABI where rel relocations are only allowed within executable files or shared objects. H.J.
Re: RFC: A new MIPS64 ABI
David Daney dda...@caviumnetworks.com writes: Background: Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of user virtual memory space. This is due the way MIPS32 memory space is segmented. Only the range from 0..2^31-1 is available. Pointer values are always sign extended. Because there are not already enough MIPS ABIs, I present the ... Proposal: A new ABI to support 4GB of address space with 32-bit pointers. FWIW, I'd be happy to see this go into GCC. Richard
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Min-and-Max.html
Gentlemen, The example of the C preprocessor implementation of MIN is erroneous: #define MIN(X,Y) ((X) (Y) ? : (X) : (Y)) should read: #define MIN(X,Y) ((X) (Y) ? (X) : (Y)) - Bob +--+ | Robert Bob Gezelter E-Mail: gezel...@rlgsc.com | | Robert Gezelter Software Consultant Voice: +1 (718) 463 1079 | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of Americahttp://www.rlgsc.com | +--+
Re: testsuite question
On 19.02.11 23:01, Richard Guenther wrote: On Sat, Feb 19, 2011 at 10:53 PM, Christian Grössler ch...@groessler.org wrote: The failures come from the assembler which complains about the out of range shift counts. Should I disable them or is there any reason unknown to me that these tests make sense? You need to make sure that the tests only invoke undefined behavior at runtime, thus emit valid assembly from your target description. Thanks. So I can simply mask the shift count to be in the supported range, or even generate a nops for the instructions, correct? chris
Re: AIX vs long double
On Mon, Feb 21, 2011 at 12:50 PM, Michael Haubenwallner michael.haubenwall...@salomon.at wrote: On 01/-10/-28163 08:59 PM, David Edelsohn wrote: AIX provides two versions of long double and declares all of the C99 long double symbols in math.h header file. One implementation aliases long double to IEEE double precision type and the other implementation aliases long double to IBM's paired double format. All of the C99 symbols for IEEE double precision are implemented in libm, but not all of the C99 symbols for the IBM long double format are implemented. IBM's proprietary XL compiler (cc, xlc) defaults to IEEE double precision and provides a special invocation to default to IBM long double (cc128, xlc128). GNU/Linux and GCC on GNU/Linux default to IEEE quad precision long double. Just to make sure I got the type names for the different bitwidths right: IEEE double precision: 64bit IEEE quad precision: 128bit IBM's paired double: 128bit, identical to IEEE quad precision? Double precision and quad precision are colloquial names for floating point formats defined by IEEE standard for floating point 754. IBM's 128 bit format does not conform to the IEEE quad precision standard. The IBM format is explained online in a few places and in the GCC sources: it is the sum of two double precision numbers, providing extended precision without extended exponent. IMO, long double bitwidth should be another multilib criterion on AIX, selected by -mlong-double-64 and -mlong-double-128. As there are a bunch of multilib criterions on AIX already: Even on AIX 5.3 I get the impression that there is no need for pthread being a multilib criterion any more, as /usr/lib/threads/libc.a is a symlink to /usr/ccs/lib/libc.a - but I may be wrong here wrt STARTFILE_SPEC. AIX already has too many multilibs and multilibs on AIX already take a tediously long time to build. The AIX support for 128 bit long double is incomplete, so adding a multilib gives the wrong impression. Also, pthread on AIX is needed. Unlike GNU/Linux, AIX does not provide weak symbol definitions of pthread functions. And AIX headers behave differently based on the definition of REENTRANT. - David
Re: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Min-and-Max.html
On 21 February 2011 20:57, Robert Gezelter wrote: Gentlemen, The example of the C preprocessor implementation of MIN is erroneous: #define MIN(X,Y) ((X) (Y) ? : (X) : (Y)) should read: #define MIN(X,Y) ((X) (Y) ? (X) : (Y)) Thanks for the report, but I don't think anyone's going to fix problems in 3.x manuals, 4.3 is the oldest maintained version.
Re: Parma Polyhedra Library 0.11.1
On Mon, Feb 21, 2011 at 12:10:03PM +0100, Roberto Bagnara wrote:
On 02/21/2011 04:42 AM, Jack Howarth wrote:
On Sun, Feb 20, 2011 at 06:32:30PM +0100, Prof. Roberto Bagnara wrote:
We announce the availability of PPL 0.11.1, a new release of the Parma
Polyhedra Library. This release includes several important bug fixes
and performance improvements.
Roberto,
Have you had any reports of installation problems?
Hi Jack.
No, your report was the first one.
Roberto,
The problems seems to stem from the absence of pre-generated files for...
ppl-user-java-interface-0.11.1-html.tar.gz
ppl-user-java-interface-0.11.1.pdf
ppl-user-java-interface-0.11.1.ps.gz
in the doc directory of the source tarball. The fink ppl9 package builds
using --with-java=$JAVA_HOME so that those missing files are autogenerated
by make install. Can you post a new tarball with those missing files added?
Jack
ps Those missing files are present in the ppl-0.11 tarball.
After installing
doxygen, texlive for pdflatex and graphviz for dot, I am still running into
installation failures for the documentation. These currently appear as...
Writing index file refman.idx
No file refman.aux.
(/sw/share/texmf-dist/tex/latex/base/ts1cmr.fd)
(/sw/share/texmf-dist/tex/latex/psnfss/t1ptm.fd)
(/sw/share/texmf-dist/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/sw/share/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/sw/share/texmf-dist/tex/latex/oberdiek/grfext.sty)
(/sw/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
(/sw/share/texmf-dist/tex/latex/graphics/color.sty
(/sw/share/texmf-dist/tex/latex/latexconfig/color.cfg))
(/sw/share/texmf-dist/tex/latex/hyperref/nameref.sty
(/sw/share/texmf-dist/tex/latex/oberdiek/refcount.sty)
(/sw/share/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
(/sw/share/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/sw/share/texmf-dist/tex/latex/amsfonts/umsb.fd)
(/sw/share/texmf-dist/tex/latex/stmaryrd/Ustmry.fd)
[1{/sw/var/lib/texmf/fonts/
map/pdftex/updmap/pdftex.map}]
(/sw/share/texmf-dist/tex/latex/psnfss/ts1ptm.fd
) (/sw/share/texmf-dist/tex/latex/psnfss/t1pcr.fd) (./main.texpdfTeX warning
(e
xt4): destination with the same identifier (name{page.1}) has been already
used
, duplicate ignored
to be read again
\relax
l.17 ...ry.Parma\_\-Polyhedra\_\-Library}};\item S
tarting from version
0.11,...
[1]
Underfull \hbox (badness 1337) in paragraph at lines 26--26
[]\T1/ptm/m/n/10 boxes which con-sist of Int8_-Box, Int16_-Box, Int32_-Box,
Int
64_-Box, Uint8_-Box,
Hmmm... this is very strange. I would like to reproduce the issue:
which version of Doxygen are you using?
) (/sw/src/fink.build/ppl9-0.11.1-0/ppl-0.11.1/build/../doc/GPL.tex
! LaTeX Error: Can be used only in preamble.
See the LaTeX manual or LaTeX Companion for explanation.
Type Hreturn for immediate help.
...
l.1 \documentclass
[a4paper,12pt]{article}
?
This is even stranger: the file name should be `gpl.tex', not `GPL.tex'
Can you please double check in the `doc' subdirectory?
Cheers,
Roberto
--
Prof. Roberto Bagnara CEO CTO
Applied Formal Methods Laboratory BUGSENG srl
Department of Mathematics Parco Area delle Scienze 53/A
University of Parma, ItalyI-43124 Parma, Italy
http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Graduate research - how GCC compiles PTHREAD Mutex routines into x86/Linux Kernel 2.6 assembler
Hi, My name is Edmon Begoli and I am a graduate student in computer science. I am writing a graduate research paper on how are concurrent routines complied in different languages. I want to start with a sort of a base case showing how are Mutexes and thread initiation routines in C compiled by GCC into assembler. I tried to look into a assembly and I did search for several days forums and forums and manuals but I could not find some simple example or a piece of a source code that shows how may piece of code like this: http://www.cs.cf.ac.uk/Dave/C/node31.html#SECTION003117100 be compiled into for example some basic version of Intel x86 assembler on Linux 2.6 kernel. Just a basic idea. I am hoping that you could point me to a code, example or a tutorial that shows how is this done in GCC. I am looking for the most basic and straightforward examples and tutorial. Thank you in advance, Edmon Begoli
Re: Parma Polyhedra Library 0.11.1
On Mon, Feb 21, 2011 at 01:32, Prof. Roberto Bagnara
bagn...@cs.unipr.it wrote:
We announce the availability of PPL 0.11.1, a new release of the Parma
Polyhedra Library. This release includes several important bug fixes
and performance improvements.
The precise list of user-visible changes is available at
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11.1/NEWS
For more information, please come and visit the PPL web site at
http://www.cs.unipr.it/ppl/
On behalf of all the past and present developers listed at
http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,
Abramo Bagnara Roberto Bagnara Patricia M. Hill Enea Zaffanella
--
Prof. Roberto Bagnara CEO CTO
Applied Formal Methods Laboratory BUGSENG srl
Department of Mathematics Parco Area delle Scienze 53/A
University of Parma, Italy I-43124 Parma, Italy
http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
mailto:bagn...@cs.unipr.it mailto:roberto.bagn...@bugseng.com
When I build on i686-w64-mingw32 target:
libtool: compile: i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
-I/home/oracle/src/ppl-0.11.1/src -I.. -I..
-I/home/oracle/src/ppl-0.11.1/src
-I/home/oracle/tmp/gcc-4.5-windows-obj/misc//include -g -O2
-frounding-math -march=x86-64 -O2 -flto -pipe -D_WIN32 -W -Wall -MT
fpu-ia32.lo -MD -MP -MF .deps/fpu-ia32.Tpo -c
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc -DDLL_EXPORT -DPIC -o
.libs/fpu-ia32.o
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc: In function 'void
Parma_Polyhedra_Library::detect_sse_unit()':
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc:52:7: error: 'NULL' was
not declared in this scope
make[3]: *** [fpu-ia32.lo] Error 1
make[3]: Leaving directory `/tmp/x/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/x/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/x'
make: *** [all] Error 2
Here is my patch:
$ git diff src/fpu-ia32.cc
diff --git a/src/fpu-ia32.cc b/src/fpu-ia32.cc
index d361411..8a2a6a2 100644
--- a/src/fpu-ia32.cc
+++ b/src/fpu-ia32.cc
@@ -30,6 +30,7 @@ site: http://www.cs.unipr.it/ppl/ . */
#include fpu.defs.hh
#include csetjmp
#include csignal
+#include cstddef
namespace {
And I'm doubt the assumption GMP does not support exception when cross
compiling:
$ git diff m4/ac_check_gmp.m4
diff --git a/m4/ac_check_gmp.m4 b/m4/ac_check_gmp.m4
index c5dd1c9..8c2af74 100644
--- a/m4/ac_check_gmp.m4
+++ b/m4/ac_check_gmp.m4
@@ -181,8 +181,8 @@ int main() {
ac_cv_gmp_supports_exceptions=yes,
AC_MSG_RESULT(no)
ac_cv_gmp_supports_exceptions=no,
- AC_MSG_RESULT([assuming not])
- ac_cv_gmp_supports_exceptions=no)
+ AC_MSG_RESULT([assuming yes])
+ ac_cv_gmp_supports_exceptions=yes)
gmp_supports_exceptions=${ac_cv_gmp_supports_exceptions}
if test x$gmp_supports_exceptions = xyes
--
Dongsheng
Re: Triplet for ARM Linux HardFP ABI, again
On Mon, 2011-02-21 at 17:59:06 +, Joseph S. Myers wrote:
On Mon, 21 Feb 2011, Guillem Jover wrote:
if you'd consider accepting something ressembling the attached patch
A pre-existing condition, but in general where the code you're changing
hardcodes gnu that's wrong - arm*-*-linux-uclibceabi is also meant to be
valid. So if you allow a suffix here, the general form to accept
consistently would be arm*-*-linux-*eabi*.
Ok, so something like the attached then (again completely untested)?
I've changed the ada part to just match on arm% linux% in the same way
the other targets do, as there didn't seem anything GNU EABI specific
in commit 8f0372dd2b828c0a0ee05dee4496a021da9cee40 (r155808).
And should probably not be touching the uclinux match.
thanks,
guillem
diff --git a/configure b/configure
index 501c6ff..43ff04f 100755
--- a/configure
+++ b/configure
@@ -3236,7 +3236,7 @@ case ${target} in
noconfigdirs=$noconfigdirs target-libffi target-qthreads
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-*eabi*)
noconfigdirs=$noconfigdirs target-qthreads
case ${with_newlib} in
no) noconfigdirs=$noconfigdirs target-newlib target-libgloss
diff --git a/configure.ac b/configure.ac
index 9121d65..e1a42e0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -682,7 +682,7 @@ case ${target} in
noconfigdirs=$noconfigdirs target-libffi target-qthreads
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-*eabi*)
noconfigdirs=$noconfigdirs target-qthreads
case ${with_newlib} in
no) noconfigdirs=$noconfigdirs target-newlib target-libgloss
diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index b64ba55..cbe6b70 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -1841,7 +1841,7 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(arch) $(osys))),)
LIBRARY_VERSION := $(LIB_VERSION)
endif
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 4,$(targ,)
+ifeq ($(strip $(filter-out arm% linux%,$(arch) $(osys))),)
LIBGNAT_TARGET_PAIRS = \
a-intnam.adsa-intnam-linux.ads \
s-inmaop.adbs-inmaop-posix.adb \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 54b822e..1a47343 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -820,13 +820,13 @@ arm*-*-linux*) # ARM GNU/Linux with ELF
esac
tmake_file=${tmake_file} t-linux arm/t-arm
case ${target} in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h
tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h
tmake_file=$tmake_file arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi t-slibgcc-libgcc
# Define multilib configuration for arm-linux-androideabi.
case ${target} in
- *-androideabi)
+ *-androideabi*)
tmake_file=$tmake_file arm/t-linux-androideabi
;;
esac
@@ -848,7 +848,7 @@ arm*-*-uclinux*) # ARM ucLinux
tm_file=dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h arm/uclinux-elf.h glibc-stdint.h
tmake_file=arm/t-arm arm/t-arm-elf
case ${target} in
- arm*-*-uclinux*eabi)
+ arm*-*-uclinux*eabi*)
tm_file=$tm_file arm/bpabi.h arm/uclinux-eabi.h
tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h
tmake_file=$tmake_file arm/t-bpabi
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 02cb7ac..885c0e0 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3219,7 +3219,7 @@ proc check_effective_target_sync_int_long { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
- || [istarget arm*-*-linux-gnueabi]
+ || [istarget arm*-*-linux-*eabi*]
|| [istarget bfin*-*linux*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
@@ -3250,7 +3250,7 @@ proc check_effective_target_sync_char_short { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
- || [istarget arm*-*-linux-gnueabi]
+ || [istarget arm*-*-linux-*eabi*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
diff --git a/libjava/configure b/libjava/configure
index f79e53b..47e3f23 100755
--- a/libjava/configure
+++ b/libjava/configure
@@ -20527,7 +20527,7 @@ case ${host} in
# on Darwin -single_module speeds up loading of the dynamic libraries.
extra_ldflags_libjava=-Wl,-single_module
;;
-arm*linux*eabi)
+arm*-*-linux-*eabi*)
# Some of the ARM unwinder code is actually in libstdc++. We
# could in principle replicate it in libgcj, but it's better to
# have a dependency on libstdc++.
diff --git a/libjava/configure.ac b/libjava/configure.ac
index 8187eec..b59abb3 100644
--- a/libjava/configure.ac
+++ b/libjava/configure.ac
@@ -919,7 +919,7 @@ case ${host} in
# on Darwin -single_module speeds up loading of the dynamic libraries.
gcc 4.5.2 configuration issues
Hi, Is there any standalone gcc 4.5.2 build without the support of gmp, mpfr and mpc. Pls. let me know what features are integrated using gcc 4.5.2 to incorporate for any builds. Regards, Gururaj Build Release Engr
Re: Graduate research - how GCC compiles PTHREAD Mutex routines into x86/Linux Kernel 2.6 assembler
On Mon, 21 Feb 2011 22:26:09 -0500
Edmon Begoli ebeg...@gmail.com wrote:
Hi,
My name is Edmon Begoli and I am a graduate student in computer science.
I am writing a graduate research paper on how are concurrent routines complied
in different languages. I want to start with a sort of a base case showing how
are Mutexes and thread initiation routines in C compiled by GCC into
assembler.
You question very probably belongs more to gcc-help@
I tried to look into a assembly and I did search for several days
forums and forums and manuals
but I could not find some simple example or a piece of a source code
that shows how may
piece of code like this:
http://www.cs.cf.ac.uk/Dave/C/node31.html#SECTION003117100
be compiled into for example some basic version of Intel x86 assembler
on Linux 2.6 kernel.
your example there is
#include pthread.h
pthread_mutex_t count_mutex;
long long count;
void increment_count()
{ pthread_mutex_lock(count_mutex);
count = count + 1;
pthread_mutex_unlock(count_mutex);
}
As far as I know, there is nothing special in GCC to compile such a code. All
the interesting stuff happens in pthread routines (like pthread_mutex_lock). To
understand in detail what GCC is doing, you could save the above code chunk in
a file lockedcount.c -inside an otherwise emptyy directory- and compile that
file with
gcc -phtread -S -O2 -fdump-tree-all -fverbose-asm lockedcount.c
Then you'll see the generated assembly code lockedcount.s and many dump files
which are showing the various internal representations (Gimple, Gimple/SSA,
...) of the code within GCC.
On my computer the function gets compiled to
.p2align 4,,15
.globl increment_count
.type increment_count, @function
increment_count:
.LFB1:
.cfi_startproc
subq$8, %rsp#,
.cfi_def_cfa_offset 16
movl$count_mutex, %edi #,
callpthread_mutex_lock #
addq$1, count(%rip) #, count
movl$count_mutex, %edi #,
addq$8, %rsp#,
.cfi_def_cfa_offset 8
jmp pthread_mutex_unlock#
.cfi_endproc
.LFE1:
As you can see, the synchronisation routines (pthread_mutex_lock...) get called
like any other ordinary routine. All the synchronisation magic happens inside
them (in the libpthread.so library). You'll need to dig the source code of
glibc/NPTL to understand the details.
When your work is done, please publish it (in English) on some publicly
accessible web page. I'm sure that would interest some people.
Regards, good luck.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Does config.h include tm.h for now?
Hi, I notice that the internals document says The header file config.h includes tm.h and most compiler source files include config.h. in Target Description Macros and Functions section. This may need modification since config.h doesn't include tm.h for now, if I'm not wrong. Thanks, Mingjie
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #16 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2011-02-21 08:25:51 UTC --- Dear Mikael, snip Actually none of the gfc_compare_type/gfc_TK_compatible changes are absolutely necessary to fix this bug. It is just I found it odd that gfc_compare_type was calling gfc_type_compatible (compatible types are not necessary equal/equivalent), so I changed it so that gfc_type_compatible calls gfc_compare_type instead. And then the new gfc_TK_compatible function to not upset the testsuite. Maybe I just don't understand what compare types means. :-( snip Hem, yes, who wrote this? ( I hope it's not me ;-) ). There have been a number of contributors over the years. Therein lies the problem. Quick fix has been piled on quick fix and the result is something of a mess. It is just I found it odd that gfc_compare_type was calling gfc_type_compatible (compatible types are not necessary equal/equivalent), so I changed it so that gfc_type_compatible calls gfc_compare_type instead. That was indeed very peculiar. I know who the culprit was but I am not telling :-) If you have time to put this right I, for one, would be very pleased. A Paul
[Bug c/47796] The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 08:29:03 UTC --- Undefined behavior means anything can happen, so wondering why undefined behavior doesn't always behave the same doesn't make any sense. And, both gcc 4.4.5 and 4.5.2 do warn about this with -Wstrict-aliasing=1 -O2: pr47796.c:25: warning: dereferencing type-punned pointer might break strict-aliasing rules pr47796.c:31: warning: dereferencing type-punned pointer might break strict-aliasing rules Please stop reopening this.
[Bug preprocessor/39029] #pragma once is not exported from the precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
--- Comment #3 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21
09:37:03 UTC ---
g++ -o b.h.gch a.h
g++ c.cpp
a.h:
#pragma once // a.h:1:9: warning: #pragma once in main file
c.cpp:
#include b.h
#include b.h // c.cpp:2:15: error: b.h: No such file or directory
int main()
{
}
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 09:37:55 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.3.5, 4.4.5, 4.5.2, 4.6.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-21 09:37:55 UTC --- Confirmed. In Fortran 2003 such a code would be valid ... (In reply to comment #0) There are two errors For those having - like me - problems to spot the second error: static long double prechalf = nexafterl (0.5L, LDBL_MAX); long double prechalf = nextafterl (0.5L, LDBL_MAX);
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 09:44:34 UTC --- (In reply to comment #11) Could you try building with the patch on a ppc box if you have one, without the Fix to tree.c in it, so that it will fail, if the problem isn't really fixed. If you don't, then a second set of hands testing would be nice, if we want to put this into the tree before stage1. Richard, should the darwin fix go in now, or wait til stage1? The patch looks good to me and is fine for stage4.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | --- Comment #6 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21 09:45:21 UTC --- (In reply to comment #5) It is implicitly in the manual as those that are not mentioned as enabled by Wall or Wextra. So The list in the manual already. is false. It would be nice to have a list of options enabled by default and another list of options never enabled by default or by other option. However, I doubt that any of the current GCC devs will ever bother to create such lists, so if you are interested, please send a documentation patch. It is a matter of reading about all warning options mentioned in http://gcc.gnu.org/onlinedocs/gcc/ and creating the lists. I'll have a look. However, I still think an option to really enable (almost) all warnings should be added. I don't agree with the comments in the earlier report.
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #12 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:45:15 UTC --- Created attachment 23418 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23418 Test case (requires msp430 back end) Sorry, I don't speak dejagnu well enough yet to put target test conditionals into the code; this test lives in the gcc.target/msp430 directory in my environment.
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #13 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:45:52 UTC --- Created attachment 23419 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23419 Generated code before patch applied
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #14 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:46:30 UTC --- Created attachment 23420 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23420 Generated code after patch applied
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-21 09:48:08 UTC --- (In reply to comment #9) Yep, that would have worked. Thanks for the clue. Is there any update on this issue? (Cf. also bug 47716 comment 6 and http://www.mailinglistarchive.com/fort...@gcc.gnu.org/msg17593.html )
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #15 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:48:23 UTC --- Created attachment 23421 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23421 Fixes problem
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #16 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:50:00 UTC --- I've now taken over the msp430 back end and created the attached patch and test case. This is relative to the gcc trunk as of a couple weeks ago; still present in all releases up to that point. Sorry it doesn't show up with any other back end, but perhaps an appeal to inspection could work while we get the msp430 target ready for integration: This is the only conditional of four in the same block that does not check for data.reverse before doing its thing. It's definitely wrong.
[Bug middle-end/31469] move_by_pieces in expr.c function bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31469 --- Comment #1 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:51:24 UTC --- Created attachment 23422 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23422 Fixes problem (resubmit, lost due to collision)
[Bug middle-end/31469] move_by_pieces in expr.c function bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31469 Peter A. Bigot bigotp at acm dot org changed: What|Removed |Added CC||bigotp at acm dot org --- Comment #2 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:53:10 UTC --- (In reply to comment #1) Created attachment 23422 [details] Fixes problem (resubmit, lost due to collision) Sorry, bugzilla confused me, this attachment was intended for 42722.
[Bug target/47831] New: avoid if-convertion if the conditional instructions and following conditional branch has the same condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47831
Summary: avoid if-convertion if the conditional instructions
and following conditional branch has the same
condition
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-linux-androideabi
Created attachment 23423
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23423
testcase
Compile the attached source code with options -march=armv7-a -mthumb -Os, GCC
4.6 generates
ras_validate:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
push{r0, r1, r4, r5, r6, lr}
addr4, sp, #4
movsr2, #4
movr1, r4
movr5, r0
blfoo
cmpr0, #0
itge// A
movger6, r0// B
bge.L3 // C
b.L7 // D
.L4:
addsr3, r6, r4
movr0, r5
subsr6, r6, #1
ldrbr1, [r3, #-1]@ zero_extendqisi2
blbar
addsr3, r0, #1
beq.L2
.L3:
cmpr6, #0
bne.L4
movr0, r6
b.L2
.L7:
movr0, #-1
.L2:
pop{r2, r3, r4, r5, r6, pc}
Instruction sequence ABCD can be replaced with
blt.L7
movr6, r0
b .L3
In both cases (lt or ge) the executed instructions is not longer than original
code. So it's shorter and faster.
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-21 10:03:36 UTC --- (In reply to comment #15) Could you try building with the patch on a ppc box if you have one, without the Fix to tree.c in it, so that it will fail, if the problem isn't really fixed. If you don't, then a second set of hands testing would be nice, if we want to put this into the tree before stage1. Richard, should the darwin fix go in now, or wait til stage1? The patch looks good to me and is fine for stage4. Unfortunately it does not fix the problem on ppc.
[Bug objc/47832] New: [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832
Summary: [4.6 Regression] ObjC errors on structures with
flexible data members
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: nic...@gcc.gnu.org, ia...@gcc.gnu.org
struct S
{
int s;
unsigned char *t[];
};
@interface T
{
struct S *u;
};
@end
@implementation T
{
};
@end
used to compile just fine in 4.5, but 4.6 rejects this
rh678928.m:14:1: error: instance variable has unknown size
I don't know ObjC enough to say whether this is intentional or not (and whether
ObjC standard actually talks about flexible array members at all). If flexible
array members should be allowed, then it would just need to make sure the
element type is complete, rather than the array type.
This breaks build of raidem, for original testcase see
http://bugzilla.redhat.com/678928
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #17 from Iain Sandoe iains at gcc dot gnu.org 2011-02-21 10:08:51 UTC --- there was no intention to create a hack (or any other form of expedient work); ... if it is wrong, then it is likely a mistake on my part when importing the original implementation from the 4.3-era branch. -- I have applied the patch @ comment #8 to r170338 on i686-darwin9 and powerpc-darwin9. It works on i686 ... ... but it does not work on powerpc. (both as comment #8 is written and with RS6000_BUILTIN_CFSTRING as the argument to darwin_init_cfstring_builtins) -- checking in gdb for cc1obj and lto1 -- darwin_init_cfstring_builtins () is being called for both (and with the same index value in each case). The routine appears be initializing the built-in correctly in both cases. (the same reported error is also present for a simple CFString c program, so not likely an objc problem). the programs compile and execute correctly without lto. .. any hints as to what additional steps are required for ppc would be appreciated.
[Bug fortran/47348] wrong string length with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47348 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 10:33:10 Ever Confirmed|0 |1 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-21 10:33:10 UTC --- Any plan to backport the fix in revision 170317?
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832
--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 10:37:10
UTC ---
Hi Jakub,
@interface T
{
struct S *u;
};
@end
struct S * is a pointer, right ? So it's always the size of a pointer ?
In that case, I don't see any reason why it shouldn't be possible to use
it as an instance variable - it's a bug in the compiler if this is not
allowed. :-)
I think the new check in GCC 4.6 was supposed to catch the case
struct S
{
int s;
unsigned char *t[];
};
@interface T
{
struct S u;
};
@end
@implementation T
{
};
@end
this shouldn't be allowed. The reason is easy to understand:
* the list of instance variables in a class (inside @interface T { ... } @end)
is compiled into a struct in the end ;-)
* but, if the class is subclassed, the subclass instance variables are added
at the end of the superclass's struct
* so, if the list of instance variables ends with a flexible array member,
you get in trouble when you subclass the class, because the subclass
instance
variable struct will have a flexible array member *inside* (not at the end)
of the struct. ;-)
So, flexible array members should not be allowed as instance variables
anywhere.
This is what GCC 4.6 is trying to prevent.
But, in the testcase you show, the instance variable is not a flexible
array member; it's a pointer to a flexible array member. You can have
pointers to anything you want as instance variables. ;-)
I hope this helps with the Objective-C side.
Looking at the code, the check in encode_array() is not good enough. When the
instance variable type is encoded, the compiler will follow the pointer and
encode a description of the struct. The check in encode_array() will then
abort because the struct contains a flexible array member, without realizing
it is part of the struct pointed to.
I guess the fix should remove the check from encode_array() and move it higher
up when instance variables are added.
I can do the fix myself tonight (ie, in the next 12/24 hours) if you want.
Thanks
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 --- Comment #2 from Kai-Uwe Eckhardt kuehro at gmx dot de 2011-02-21 10:38:16 UTC --- Hi, There are two errors For those having - like me - problems to spot the second error: static long double prechalf = nexafterl (0.5L, LDBL_MAX); long double prechalf = nextafterl (0.5L, LDBL_MAX); well besides the typo nexfaterl declaring a variable static in block scope is evaluated as a const qualifier which cannot be assigned using a function. At least the default compiler on NetBSD gcc-4.1.3 tells me so. I tried to look it up in the C99 standard, if this is a compiler error or not. Mabey it would be cleaner to put the declaration at the beginning of the function roundl. Kai-Uwe Eckhardt
[Bug target/47825] SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
Status|RESOLVED|REOPENED
Last reconfirmed||2011.02.21 10:40:58
CC||hjl at gcc dot gnu.org
Component|c |target
Resolution|INVALID |
Ever Confirmed|0 |1
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21
10:40:58 UTC ---
The issue is that maskarray is initialized as array of ints but then you
load it as array of floats, the scheduler re-orders those so you see
a load from uninitialized stack:
test_setelement:
.LFB546:
subq$40, %rsp
.LCFI0:
movaps 16(%rsp), %xmm0
movl$0, 16(%rsp)
movl$0, 20(%rsp)
movaps %xmm0, %xmm1
andnps .LC1(%rip), %xmm0
movl$0, 24(%rsp)
movl$-1, 28(%rsp)
...
what is a bit inconsistent is that for mm_load_pd we use a type that
allows aliasing:
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
typedef double __m128d __attribute__ ((__vector_size__ (16), __may_alias__));
...
/* Load two DPFP values from P. The address must be 16-byte aligned. */
extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_pd (double const *__P)
{
return *(__m128d *)__P;
}
but for mm_load_ps we don't:
/* Internal data types for implementing the intrinsics. */
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
...
/* Load four SPFP values from P. The address must be 16-byte aligned. */
extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_ps (float const *__P)
{
return (__m128) *(__v4sf *)__P;
}
re-opening to investigate that. HJ, are the SSE1 intrinsics not
aliasing in the Intel API? The above snippets are from trunk.
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 10:42:14 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 10:42:14 UTC --- Yes, confirmed. Good testcase. Thanks
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 10:44:03 UTC --- (In reply to comment #16) (In reply to comment #15) Could you try building with the patch on a ppc box if you have one, without the Fix to tree.c in it, so that it will fail, if the problem isn't really fixed. If you don't, then a second set of hands testing would be nice, if we want to put this into the tree before stage1. Richard, should the darwin fix go in now, or wait til stage1? The patch looks good to me and is fine for stage4. Unfortunately it does not fix the problem on ppc. Of course, the patch doesn't touch rs6000 which has exactly the same problem.
[Bug bootstrap/47827] gcc fails to bootstrap on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47827 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 10:44:59 UTC --- Fixed.
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-21 11:19:33 UTC --- (In reply to comment #2) well besides the typo nexfaterl Well, that was actually the problem I had - my brain magically added the t ;-) (For NetBSD there is also PR 39570, which is about cabsf warnings.)
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21
12:02:58 UTC ---
As I said, I don't know ObjC, so if you could fix it, I'd appreciate it.
That said, ISO C99 allows:
struct A { int a; char b[]; };
struct A a; // Here sizeof (a) will be offsetof (struct A, b[0])
but doesn't allow:
struct B { struct A a; int i; };
So, for ObjC I guess it depends if in @interface there are variables (then
variables with flexible array members in theory could be treated there like ISO
C99 treats variables), or they are treated as struct fields, in which cases
fields with flex array members should be rejected. And you're right that it is
weird to reject there pointers to structs with flexible array members, unless
ObjC somehow encodes all the types each pointer points to, transitively.
[Bug c++/47833] New: ICE during GC in gt_ggc_mx_pending_template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47833
Summary: ICE during GC in gt_ggc_mx_pending_template
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
template int int
foo () throw ()
{
return 0;
}
int
foo ()
{
if (false)
{
#define A(N) fooN ();
#define B(N) A(N##0) A(N##1) A(N##2) A(N##3) A(N##4) A(N##5) A(N##6) A(N##7)
A(N##8) A(N##9)
#define C(N) B(N##0) B(N##1) B(N##2) B(N##3) B(N##4) B(N##5) B(N##6) B(N##7)
B(N##8) B(N##9)
#define D(N) C(N##0) C(N##1) C(N##2) C(N##3) C(N##4) C(N##5) C(N##6) C(N##7)
C(N##8) C(N##9)
#define E(N) D(N##0) D(N##1) D(N##2) D(N##3) D(N##4) D(N##5) D(N##6) D(N##7)
D(N##8) D(N##9)
#define F(N) E(N##0) E(N##1) E(N##2) E(N##3) E(N##4) E(N##5) E(N##6) E(N##7)
E(N##8) E(N##9)
#define G(N) F(N##0) F(N##1) F(N##2) F(N##3) F(N##4) F(N##5) F(N##6) F(N##7)
F(N##8) F(N##9)
G(1)
}
return 0;
}
ICEs in 4.5/4.6, because the pending_templates list is too long and GC recurses
on it.
[Bug fortran/47348] wrong string length with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47348 --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2011-02-21 12:06:42 UTC --- (In reply to comment #7) Any plan to backport the fix in revision 170317? I had not planned so to do but would respond positively to popular pressure how far back would you want to go? Paul
[Bug c++/47833] ICE during GC in gt_ggc_mx_pending_template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47833 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.21 12:07:27 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 12:07:27 UTC --- Created attachment 23424 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23424 gcc46-pr47833.patch Untested fix. The testcase takes over a minute to compile at -O0 on a fast box, so is not suitable for regression testing.
[Bug target/47487] ICE in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782 building 64bit libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47487 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 12:10:03 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #2 from Alan Modra amodra at gmail dot com 2011-02-21 12:10:03 UTC --- This is just a lack of else if (strcmp (language_string, GNU Go) == 0) i = mumble;
[Bug c++/47834] New: Compiler uses unsafe math optimizations even -funsafe-math-optimizations is not given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47834 Summary: Compiler uses unsafe math optimizations even -funsafe-math-optimizations is not given Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: stene...@gmail.com Created attachment 23425 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23425 Complete program needed for the bug triggering Dear Sirs, I have different result of executing program if I compile it with -On (n=1,2,3) optimization flag relative to compilation without optimizations. It seems that -On flag forces -funsafe-math-optimizations and/or -fassociative-math and/or -freciprocal-math without possibility to disable it. It effects in g++ including MinGW. I send you program based on the floating point arithmetic rounding properties in the attachment. The only correct result of the executing this code based on the Shewchuk's summation algorithm is 0. This is realy result of the program compiled by the command line g++ shewchuk.cpp but if I compile it by any of the command lines g++ -O3 shewchuk.cpp g++ -O3 -fno-unsafe-math-optimizations -fno-associative-math -fno-reciprocal-math shewchuk.cpp I obtain the result different than zero. Best regards
[Bug middle-end/35797] Compiler does not recognize faulty warnings starting with -Wno-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35797 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||WORKSFORME --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-02-21 12:22:37 UTC --- This is working as desired.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-02-21 12:30:27 UTC --- (In reply to comment #6) I'll have a look. However, I still think an option to really enable (almost) all warnings should be added. I don't agree with the comments in the earlier report. Feel free to create a patch http://gcc.gnu.org/contribute.html and submit it for review to gcc-patches. I think the general consensus among GCC devs is that such an option is not wanted, but if you still think is good, discussing it without a patch that defines exactly which options should be enabled is pointless. There are literally thousands of bugs that GCC devs would like to see fixed (search for NEW or REOPENED bugs) and several other thousands UNCONFIRMED bugs that need to be reviewed and confirmed. Keeping this one open forever is just distracting and a waste of time and effort! I am not going to close it again. If I have convinced you of the negative impact, please close this as DUPLICATED as Andrew did, or at least put it in WAITING. Otherwise, I guess in a few years you will have forgotten about this, and some GCC dev after stumbling into it for the nth time will close it forever.
[Bug c++/47834] Compiler uses unsafe math optimizations even -funsafe-math-optimizations is not given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47834 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 12:35:53 UTC --- You are running into PR323, use -ffloat-store or -mpc32 or use SSE and -mfpmath=sse. *** This bug has been marked as a duplicate of bug 323 ***
[Bug middle-end/323] optimized code gives strange floating point results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||stenedjo at gmail dot com --- Comment #180 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 12:35:53 UTC --- *** Bug 47834 has been marked as a duplicate of this bug. ***
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-21 12:39:28 UTC --- (In reply to comment #6) (In reply to comment #5) It is implicitly in the manual as those that are not mentioned as enabled by Wall or Wextra. So The list in the manual already. is false. The information is in the manual, even if not as an explicit list. I expect adding an explicit list would soon get out of date as it just increases the burden on contributors when adding new options. It would be nice to have a list of options enabled by default and another list of options never enabled by default or by other option. However, I doubt that any of the current GCC devs will ever bother to create such lists, so if you are interested, please send a documentation patch. It is a matter of reading about all warning options mentioned in http://gcc.gnu.org/onlinedocs/gcc/ and creating the lists. I'll have a look. However, I still think an option to really enable (almost) all warnings should be added. I don't agree with the comments in the earlier report. The fact you don't agree doesn't change the fact this is a duplicate of that report, marking it as such helps keep the discussion in one place. Please don't reopen this report. If you want a new one for the documentation issue please open a new PR.
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #9 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21 12:47:24 UTC --- So The list in the manual already. is false. The information is in the manual, even if not as an explicit list. That's true, but not what was said. I expect adding an explicit list would soon get out of date as it just increases the burden on contributors when adding new options. Adding options that can't be easily enabled / found doesn't seem very useful. The fact you don't agree doesn't change the fact this is a duplicate of that report, marking it as such helps keep the discussion in one place. Please don't reopen this report. How do I reopen the other report? If you want a new one for the documentation issue please open a new PR. Why? Seems easier to use this one for it.
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #23 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-21 12:53:30 UTC --- (In reply to comment #22) What is the performance with 4.3 -O2? 4.3: gfortran -O2 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.373 4.6: gfortran -O2 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.347 so, same performance. Given that vectorization only happens at -O3, it is an important optimization level for numerical codes. Nevertheless, I would propose to remove the regression tag, and instead refocus the bug on the what current trunk does at -O3 vs -O2 -ftree-vectorize as noted in comment #21 gfortran -O2 -march=native -funroll-loops -ffast-math -ftree-vectorize test.f90 ; ./a.out Time for evaluation [s]:2.694 gfortran -O3 -march=native -funroll-loops -ffast-math -ftree-vectorize test.f90 ; ./a.out Time for evaluation [s]:4.536
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 12:55:51 UTC --- Dup. *** This bug has been marked as a duplicate of bug 31573 ***
[Bug c++/31573] -Wall-all to enable all warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 12:55:51 UTC --- *** Bug 47824 has been marked as a duplicate of this bug. ***
[Bug fortran/40850] double free in nested types with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org 2011-02-21 12:57:31 UTC --- (In reply to comment #11) I don't know whether it fixes comment 0 or comment 4 Sorry, I forgot to precise. It fixes neither. More precisely for comments 0 and 4, it does fix a read of freed memory: ==82785== Invalid read of size 8 ==82785==at 0x400F21: __mod_all_MOD_add (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785==by 0x4023D9: MAIN__ (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785==by 0x402703: main (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785== Address 0x14be678 is 8 bytes inside a block of size 112 free'd but doesn't fix a double free affecting comments 0, 4 and 8: ==82785== Invalid free() / delete / delete[] ==82785==at 0x25A37E: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==82785==by 0x402609: MAIN__ (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785==by 0x402703: main (in /usr/home/mik/gfortran/pr40850/comment_0) ==82785== Address 0x14be3d0 is 0 bytes inside a block of size 8 free'd Comment 8 is not affected by the invalid read as the containing entity is not allocatable, hence not explicitly freed at the end. Thus, components release can't happen before containing entity's release. For the remaining double free, the temporary for the array constructor is filled using simple copies, and thus has components pointing to the original array. Those components are freed by the temporary array cleanup, and again during the final release of all allocatables. One could fix it by not freeing the temporary's components (no deep/nested free), but I have the feeling (haven't completely made my mind about it) that the proper fix, in the general case, is to create nested temporaries and do deep copies. And yes, that would be horribly expensive :-(.
[Bug fortran/40850] double free in nested types with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850 --- Comment #13 from Mikael Morin mikael at gcc dot gnu.org 2011-02-21 13:01:23 UTC --- Comment 5 is not affected by the double free as the allocatable components are never allocated during the program, only the containing entity is.
[Bug c/47796] The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796
--- Comment #7 from qihua.dai at intel dot com 2011-02-21 13:02:41 UTC ---
Hi,
I used -Wall -O2. But no warning for this situation.
gcc will print strict-aliasing related warning.
struct tmp1_s tmp;
tmp.a = 0xc; // this code line is removed unexpected after -O2 optimization
tmp.d = 0x1; // this code line is removed unexpected after -O2 optimization
data = *((unsigned int *)pTmp);
But, below code can fix above this warning. But this code might be removed by
gcc �CO2 in the situation of this bug.
struct tmp1_s tmp;
unsigned int *pData;
tmp.a = 0xc; // this code line is removed unexpected after -O2 optimization
tmp.d = 0x1; // this code line is removed unexpected after -O2 optimization
pData = (unsigned int *)pTmp;
data = *pData;
In addition, if cannot access bit field structure using an unsigned int, how to
share different bit field structure? For example,
void func(unsigned int data)
data can be bit field structure tmp1_s, or tmp2_s according to bit[31] (0 is
tmp1_s, 1 is tmp2_s)
struct tmp1_s {
unsigned int a : 12;
unsigned int b : 12;
unsigned int c : 7;
unsigned int d : 1;
}
struct tmp2_s {
unsigned int a : 1;
unsigned int b : 12;
unsigned int c : 12;
unsigned int d : 6;
unsigned int e : 1;
}
- Qihua
-Original Message-
From: jakub at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org]
Sent: 2011年2月21日 16:29
To: Dai, Qihua
Subject: [Bug c/47796] The code to write to a bit_field data strucuture will be
removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution||INVALID
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21
08:29:03 UTC ---
Undefined behavior means anything can happen, so wondering why undefined
behavior doesn't always behave the same doesn't make any sense. And, both gcc
4.4.5 and 4.5.2 do warn about this with -Wstrict-aliasing=1 -O2:
pr47796.c:25: warning: dereferencing type-punned pointer might break
strict-aliasing rules
pr47796.c:31: warning: dereferencing type-punned pointer might break
strict-aliasing rules
Please stop reopening this.
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4
[Bug other/47824] Option to enable all warning (-Wall-real?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #11 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21 13:11:04 UTC --- Dup. No kidding?
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #20 from Thomas Henlich thenlich at users dot sourceforge.net 2011-02-21 13:22:59 UTC --- print (F3.0), -0.0 ! = -0. print (F2.0), -0.0 ! = ** print (F1.0), -0.0 ! = 0 print (F3.1), -0.0 ! = -.0 print (F2.1), -0.0 ! = ** print (F1.1), -0.0 ! = 0 I think it's still wrong: It is not possible for any value to fit into a field of width w, but not into w+1. Either 1) For the special case of a zero, we consider the minus sign and the decimal symbol optional (which I think does not conform to the standard), then the result should be: print (F3.0), -0.0 ! = -0. print (F2.0), -0.0 ! = -0 (or 0. or 0) print (F1.0), -0.0 ! = 0 print (F3.1), -0.0 ! = -.0 print (F2.1), -0.0 ! = -0 (or .0 or 0) print (F1.1), -0.0 ! = 0 or 2) We never consider the minus sign nor the decimal symbol optional (which I think is required by the standard), then the result should be: print (F0.0), -0.0 ! = -0. print (F3.0), -0.0 ! = -0. print (F2.0), -0.0 ! = ** print (F1.0), -0.0 ! = * print (F0.1), -0.0 ! = -.0 print (F3.1), -0.0 ! = -.0 print (F2.1), -0.0 ! = ** print (F1.1), -0.0 ! = *
[Bug bootstrap/47820] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47820 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 13:38:54 UTC --- Author: rguenth Date: Mon Feb 21 13:38:48 2011 New Revision: 170359 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170359 Log: 2011-02-21 Richard Guenther rguent...@suse.de PR lto/47820 * lto-streamer-in.c (lto_input_ts_decl_common_tree_pointers): Do not stream DECL_INITIAL for TRANSLATION_UNIT_DECLs. (lto_input_ts_block_tree_pointers): Hook a BLOCK into the TUs context. * lto-streamer-out.c (lto_output_ts_decl_common_tree_pointers): Do not stream DECL_INITIAL for TRANSLATION_UNIT_DECLs. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c
[Bug bootstrap/47820] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47820 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 13:42:36 UTC --- Fixed.
[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47106 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #16 from John David Anglin danglin at gcc dot gnu.org 2011-02-21 13:44:58 UTC --- Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/ gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/debug /pr47106.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v 3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib stdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc /libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util - fmessage-length=0 -gstabs1 -O -fpartial-inlining -flto -fconserve-stack -fcompar e-debug -S -o pr47106.s(timeout = 300) cc1plus: error: LTO support has not been enabled in this configuration compiler exited with status 1 output is: cc1plus: error: LTO support has not been enabled in this configuration FAIL: g++.dg/debug/pr47106.C -gstabs1 (test for excess errors) Excess errors: cc1plus: error: LTO support has not been enabled in this configuration
[Bug target/47825] SSE bitwise operations on floats work -g, fail -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47825
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com,
||ubizjak at gmail dot com
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2011-02-21 13:53:02
UTC ---
(In reply to comment #5)
/* Load four SPFP values from P. The address must be 16-byte aligned. */
extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_ps (float const *__P)
{
return (__m128) *(__v4sf *)__P;
}
re-opening to investigate that. HJ, are the SSE1 intrinsics not
aliasing in the Intel API? The above snippets are from trunk.
It is a bug and should be fixed.
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #21 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-02-21 14:22:51 UTC --- OK, can you tell I am time slicing this one. ;)
[Bug c++/47199] [4.6 Regression] [C++0x] ICE: expected class 'type', have 'declaration' (function_decl) in same_type_ignoring_top_level_qualifiers_p, at cp/typeck.c:1407 with -fno-elide-constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47199 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-02-21 14:26:06 UTC --- Fixed.
[Bug tree-optimization/47835] New: FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 Summary: FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 Executing on host: /xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/ /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr46909.c -O2 -fdump-tree-ifcombine -S -o pr46909.s(timeout = 300) PASS: gcc.dg/pr46909.c (test for excess errors) FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4 See `!= 6' in tree dump.
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #22 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-02-21 14:32:14 UTC --- On my system I get with: print *, -- print (F0.0), -0.0 ! = -0. print (F3.0), -0.0 ! = -0. print (F2.0), -0.0 ! = ** print (F1.0), -0.0 ! = * print *, -- print (F0.1), -0.0 ! = -.0 print (F3.1), -0.0 ! = -.0 print (F2.1), -0.0 ! = ** print (F1.1), -0.0 ! = * This. The difference being my signature zero. -- -0. -0. ** 0 -- -.0 -.0 ** 0 I confess, it does not look consistent. Next time slice, I will update it. ;)
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 14:33:14 UTC --- for ObjC I guess it depends if in @interface there are variables (then variables with flexible array members in theory could be treated there like ISO C99 treats variables), or they are treated as struct fields, in which cases fields with flex array members should be rejected I see your point. They are struct fields. Thanks
[Bug tree-optimization/42108] [4.4/4.5/4.6 Regression] 50% performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2009-11-19 16:49:51 |2011-02-21 16:49:51 --- Comment #51 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 14:33:16 UTC --- Re-confirmed. The PR42131 fix didn't improve the situation.
[Bug fortran/47778] reading two arrays of structures from namelist fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47778 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-02-21 14:35:20 UTC --- Status update. I have more or less isolated the problem in list-read.c. I do not have an exact solution yet, but I am able to get the test case to work. I just need now to find the right place to make the tweak.
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-02-21 14:37:14 UTC --- Created attachment 23426 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23426 Tree dump.
[Bug regression/47836] New: Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 Summary: Some Cross Compiler can't build target-libiberty or target-zlib Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: th.r.kl...@web.de With upcoming 4.6 building of target-libiberty and target-zlib is enabled (at most platforms) per default. It should be possible to disable this behavior e.g. with switches like: --without-target-libiberty --without-target-zlib Previous versions did not try to build these libraries for cross compilers. Index: configure.ac === --- configure.ac(revision 170359) +++ configure.ac(working copy) @@ -262,6 +262,16 @@ skipdirs= # Noconfigdirs are removed loudly. noconfigdirs= +# Make sure we don't let target-libiberty be added if we didn't want it. +if test x$with_target_libiberty = xno ; then + noconfigdirs=$noconfigdirs target-libiberty +fi + +# Make sure we don't let target-zlib be added if we didn't want it. +if test x$with_target_zlib = xno ; then + noconfigdirs=$noconfigdirs target-zlib +fi + use_gnu_ld= # Make sure we don't let GNU ld be added if we didn't want it. if test x$with_gnu_ld = xno ; then Index: configure === --- configure (revision 170359) +++ configure (working copy) @@ -2801,6 +2801,16 @@ skipdirs= # Noconfigdirs are removed loudly. noconfigdirs= +# Make sure we don't let target-libiberty be added if we didn't want it. +if test x$with_target_libiberty = xno ; then + noconfigdirs=$noconfigdirs target-libiberty +fi + +# Make sure we don't let target-zlib be added if we didn't want it. +if test x$with_target_zlib = xno ; then + noconfigdirs=$noconfigdirs target-zlib +fi + use_gnu_ld= # Make sure we don't let GNU ld be added if we didn't want it. if test x$with_gnu_ld = xno ; then
[Bug c/47837] New: FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47837 Summary: FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 Executing on host: /xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/ /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c -Wuninitialized -O2 -S -o uninit-pred-7_a.s(timeout = 300) /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c: In function 'foo':/xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c:26:11: warning: 'v' may be used uninitialized in this function [-Wuninitialized] /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c: In function 'foo_2': /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c:48:12: warning: 'v' may be used uninitialized in this function [-Wuninitialized] output is: /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c: In function 'foo':/xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c:26:11: warning: 'v' may be used uninitialized in this function [-Wuninitialized] /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c: In function 'foo_2': /xxx/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-pred-7_a.c:48:12: warning: 'v' may be used uninitialized in this function [-Wuninitialized] PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 20) PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 23) FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26) PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 42) PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 45) PASS: gcc.dg/uninit-pred-7_a.c warning (test for warnings, line 48) PASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 51) PASS: gcc.dg/uninit-pred-7_a.c (test for excess errors)
[Bug target/47487] ICE in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782 building 64bit libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47487
--- Comment #3 from Peter Bergner bergner at gcc dot gnu.org 2011-02-21
15:02:40 UTC ---
I don't recall anyone adding GO support for powerpc{,64}-linux, so I'm guessing
such a patch should be added when that is submitted?
[Bug fortran/46321] [OOP] Polymorphic deallocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321 --- Comment #2 from janus at gcc dot gnu.org 2011-02-21 15:06:10 UTC --- (In reply to comment #1) Note: There are four cases where a polymorphic deallocate is needed - though some might end up in the same code path: - explicit DEALLOCATE (cf. comment 0) - implicit deallocate at the end of the scope - implicit deallocate via INTENT(OUT) (cf. PR 47637) - implicit deallocate when doing polymorphic reallocate on assignment (PR 43366) Some more things we need to consider: * explicit deallocation with STAT or ERRMSG * deallocation of allocatable components (explicit/implicit)
[Bug c++/47207] [4.6 Regression] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3563 on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47207 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-02-21 15:11:14 UTC --- Mine.
[Bug tree-optimization/47838] New: FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838 Summary: FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 Executing on host: /xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/ /xxx/ gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/foldconst-2.c -O2 -fdump-tree-optimi zed -S -o foldconst-2.s(timeout = 300) PASS: gcc.dg/tree-ssa/foldconst-2.c (test for excess errors) FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals.0
[Bug tree-optimization/47838] FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-02-21 15:12:18 UTC --- Created attachment 23427 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23427 Tree dump.
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-02-21 15:14:06 UTC --- I see the same pr46909 failure on powerpc64-linux too, with every weekly trunk snapshot since 2010-12-18.
[Bug c++/47207] [4.6 Regression] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3563 on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47207 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-02-21 15:35:52 UTC --- Author: jason Date: Mon Feb 21 15:35:44 2011 New Revision: 170365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170365 Log: PR c++/47207 * decl2.c (decl_constant_var_p): A constexpr var needs an initializer to be constant. * semantics.c (cxx_eval_constant_expression): Complain about constexpr var used in its own initializer. * call.c (set_up_extended_ref_temp): Set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P too. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-diag2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl2.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219 --- Comment #11 from John David Anglin danglin at gcc dot gnu.org 2011-02-21 15:51:59 UTC --- Still fails on hppa1.1-hp-hpux10.20 with 4.6.0 revision 170207.
[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47106 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 15:53:54 UTC --- Author: jakub Date: Mon Feb 21 15:53:49 2011 New Revision: 170366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170366 Log: PR debug/47106 * g++.dg/debug/pr47106.C: Require effective target lto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/pr47106.C
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.0 |4.7.0
[Bug fortran/47839] New: ICE in dwarf2out.c:add_AT_specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839 Summary: ICE in dwarf2out.c:add_AT_specification Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Building 459.GemsFDTD (and 416.gamess) with -O3 -ffast-math -flto -g ICEs because the Fortran frontend seemingly puts imported variables in the BLOCK tree of the imported function and does not mark them external. The variable in question is huy_param from huygens_mod, imported from nft_store SUBROUTINE NFT_Store(Ex,Ey,Ez,Hx,Hy,Hz,t,ts) USE excite_mod, ONLY : excitation USE huygens_mod, ONLY : Huy_param, HuyPulseType and MODULE Huygens_mod ... real(kind=rfp), dimension(excite_max_no_param), PUBLIC :: Huy_param I tried to create a small testcase but failed sofar. It doesn't ICE with -flto-partition=none but it does with -flto-partition=1to1. With partially linking 459.GemsFDTD I get the ICE with /abuild/rguenther/install-trunk/usr/local/bin/gfortran globalvar.f90 PEC.f90 -o GemsFDTD -flto -flto-partition=none -r -nostdlib -O -g which is then obviously related to a different variable. Trying to reduce the sources now.
[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21 16:19:20 UTC --- --- a.f90 MODULE globalvar_mod integer:: xstart, ystart, zstart, xstop, ystop, zstop CONTAINS END MODULE globalvar_mod --- b.f90 MODULE PEC_mod CONTAINS SUBROUTINE PECapply(Ex,Ey,Ez) USE globalvar_mod, ONLY : xstart, ystart, zstart, xstop, ystop, zstop real(kind=8), dimension(xstart:xstop+1,ystart:ystop+1,zstart:zstop+1), intent(inout) :: Ex, Ey, Ez END SUBROUTINE PECapply END MODULE PEC_mod gfortran a.f90 b.f90 -flto -flto-partition=none -r -nostdlib -g lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:7558 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/47772] warnings from -Wmissing-field-initializers contradict documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47772
Jonathan 'Sky' Squirawski webmas...@sky-siteweb.com changed:
What|Removed |Added
CC||webmas...@sky-siteweb.com
--- Comment #2 from Jonathan 'Sky' Squirawski webmas...@sky-siteweb.com
2011-02-21 16:55:39 UTC ---
I've the same problem with gcc 4.5.2.
Here another test case:
/*==*/
typedef struct bar_t {
int a;
int b;
} bar_t;
typedef struct foo_ok_t {
int bar;
bar_t foo;
} foo_ok_t;
typedef struct foo_nok_t {
bar_t bar;
bar_t foo;
} foo_nok_t;
int main(void) {
foo_ok_t foo_ok;
foo_nok_t foo_nok;
foo_ok = (foo_ok_t){
.bar = 32,
};
foo_nok = (foo_nok_t){
.bar = (bar_t){ .a = 32, .b = 42 },
};
return 0;
}
/*==*/
The first assignment doesn't trigger any warning, but the second one gives:
test.c:29:5: warning: missing initializer
test.c:29:5: warning: (near initialization for ‘(anonymous).foo’)
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #6 from Jeffrey A. Law law at redhat dot com 2011-02-21 16:56:18 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/11 13:56, dave at hiauly1 dot hia.nrc.ca wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-02-18 20:56:54 UTC --- Is there no way to get a posix compliant ctime? Alternatively, we'll need autoconf magic to detect the extra arg. I know at one time it was relatively common, so autoconf magic might be around somewhere. Assuming it is you just have to do something like #if defined (oddballctime) *date = ctime_r (now, cbuf, CSZ); #else *date = ctime_r (now, cbuf); #endif Using ctime_r is a bit of a can of worms. The GNU autoconf manual recommends not using ctime_r unless the inputs are known to be within certain limits. Correct. The problem is some implementations can trigger buffer overflows for bad input. Certain implementations pass in a buffer size parameter to deal with that problem, others (glibc) presumably do some checking before dumping results into the user supplied buffer to make sure they don't exceed the 26 bytes or whatever the minimum size of hte buffer is supposed to be. Even for checking versions like glibc, if the wrong sized buffer is passed in, then it'll probably break. I guess the question we need to ask is how important are these routines and should we be issuing warnings when they are used, much like is done with gets. If we don't need them, I'd much prefer to see them go away as they're a rats nest of security issues. Just a quick glance at the code in libgfortran/ctime.c and I'm pretty sure it's vulnerable to a buffer overflow attack. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNYpkoAAoJEBRtltQi2kC7HwcH/3IEgG2sh265kwu9kKQQ87gf um1qKykJo4/Ph3W4UF7q1G26mw5luemVE6ga4+4nEzpivH0hzgsxWADDPXjQzq26 tqUXwh0nKi5665O1rcW88EZpej5J0MDLtUBTQXv1DipQWDBa/YjDqrmO4IRkw+MK QlkgPvCqosS1wvlbVJ9xKpTn2XY8tVTPdLlAMI3iBbbtDcsWMdKxaG5mpnhh8P4i HkVepfpRr5RtpuVN3SJ6AWhqR0PQgS1e2PB2WbbY8bvNy5ev1GggJZj/3j101jza /QseJ16lj3CqOMHCppHOhXGL8bxMFW17AWv/hL74+gTn9rZCH/JUjOQ+YzRgs0A= =SpA9 -END PGP SIGNATURE-
[Bug tree-optimization/47838] FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-02-21 17:03:34 UTC --- I see the foldconst-2 failure also on powerpc64-linux, ever since the 20100904 trunk snapshot.
[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.21 17:04:46
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-21
17:04:46 UTC ---
We merge the decls during symtab merging. The prevailing one looks for example
like
(gdb) call debug_tree (prevailing-decl)
var_decl 0x75b3b0a0 zstart
type integer_type 0x77ee3498 int public SI
size integer_cst 0x77ed36e0 constant 32
unit size integer_cst 0x77ed33e8 constant 4
align 32 symtab 0 alias set -1 canonical type 0x77ee3498 precision
32 min integer_cst 0x77ed3668 -2147483648 max integer_cst 0x77ed3690
2147483647
pointer_to_this pointer_type 0x77ef03f0
used public static SI file mod.f90 line 2 col 0 size integer_cst
0x77ed36e0 32 unit size integer_cst 0x77ed33e8 4
align 32 context namespace_decl 0x75b31678 globalvar_mod
while the non-prevailing one is
var_decl 0x75b3b640 zstart
type integer_type 0x77ee3498 int public SI
size integer_cst 0x77ed36e0 constant 32
unit size integer_cst 0x77ed33e8 constant 4
align 32 symtab 0 alias set -1 canonical type 0x77ee3498 precision
32 min integer_cst 0x77ed3668 -2147483648 max integer_cst 0x77ed3690
2147483647
pointer_to_this pointer_type 0x77ef03f0
used public ignored external SI file t.f90 line 4 col 0 size integer_cst
0x77ed36e0 32 unit size integer_cst 0x77ed33e8 4
align 32
note that it is public and external and has a NULL DECL_CONTEXT.
The C frontend for a local extern declaration has
var_decl 0x75b481e0 i
type integer_type 0x77ee6498 int public SI
size integer_cst 0x77ed36e0 constant 32
unit size integer_cst 0x77ed33e8 constant 4
align 32 symtab 0 alias set -1 canonical type 0x77ee6498 precision
32 min integer_cst 0x77ed3668 -2147483648 max integer_cst 0x77ed3690
2147483647
pointer_to_this pointer_type 0x77ef7540
used public external common SI defer-output file t.c line 8 col 15 size
integer_cst 0x77ed36e0 32 unit size integer_cst 0x77ed33e8 4
align 32 context function_decl 0x75b49000 foo
thus puts it into function context. This decl is solely used for the BLOCK
tree, in the function a public external global var is used (which is
then merged with the static one from the other TU).
void foo (void)
{
extern int i;
i = 0;
}
---
int i;
Simplified Fortran testcase:
MODULE globalvar_mod
integer:: xstop
CONTAINS
END MODULE globalvar_mod
---
MODULE PEC_mod
CONTAINS
SUBROUTINE PECapply(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
END SUBROUTINE PECapply
END MODULE PEC_mod
it's important that PECapply is inside a module.
The decl is built by gfc_get_symbol_decl and put into the function via
gfc_add_decl_to_function - which is I think in general bogus for
imported decls. Its context is later cleared in pushdecl, but the
variable isn't removed from BLOCK_VARS.
I think we want to avoid gfc_add_decl_to_function in the first place.
