[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #3 from malitzke at metronets dot com 2007-06-13 06:06 --- Maybe some people should read __carefully__ both the C standard and the new GPL3 -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug fortran/32315] New: DATA with implied-do: Bounds checks missing
Found at: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/34f509b6b4241c6d/ program chkdata character(len=20), dimension(4) :: string data ( string(i) ,i=1,5 ) / 'A', 'B', 'C', 'D', 'E' / write(*,*) string end program chkdata gfortran gives no warning/error whereas NAG f95 rejects it with: Error line 5: First subscript (5) is greater than upper bound (4) for array STRING and g95 rejects it with: Error: Out of bounds array reference at (1) and sunf95 with: ERROR: The upper bound for dimension 1 of the array STRING is out of range. (ifort does the same as gfortran: It accepts it.) -- Summary: DATA with implied-do: Bounds checks missing Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32315
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 06:26 --- Maybe some people should read __carefully__ both the C standard and the new GPL3 What does that mean? There is a working draft of dfp in the C standards committee See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1137.pdf Also GPLv3 does not apply yet so what do you mean? Again --disiable-decimal-float just disables the C interface and not the support library. Can you give more hints at what you really want from GCC? If you want to disable unused code, you have to do it manually because it is only partly unused in the sense it will not be invoked but if you add a front-end that uses it, you can still use it without recompiling the whole GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #3 from daney at gcc dot gnu dot org 2007-06-13 06:26 --- Created an attachment (id=13696) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13696action=view) Proposed fix. I will try to bootstrap the Proposed fix tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #4 from echristo at apple dot com 2007-06-13 06:36 --- Patch looks reasonable. -- echristo at apple dot com changed: What|Removed |Added CC||echristo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug fortran/32315] DATA with implied-do: Bounds checks missing
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-13 06:46 ---
Dump shows:
static char string[4][1:20] = {A , B ,
C , D , E}
Check should probably be in resolve.c's check_data_variable.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.3 4.2.0 4.3.0
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32315
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #5 from malitzke at metronets dot com 2007-06-13 07:09 --- All I want for gcc is that it meets both the letter __and__ the spirit of applicable contracts and specifications. First, the GPL is a contract, do __not__ take my word for it but consult a lawyer. Second, the C standard can be and should be made part of a contract like a chip manufacturer would sign with a major purchaser like Ford or GM for embedded chips and the included support software like gcc. After working 80 hours with paid overtime) as a highly regarded real-time assembly programmer (before C became available) I tripled my income (no paid overtime) as an international telecommunications consultant (really RFP writer, contract negotiator, acceptance tester), project engineer, co-writer of ITU (International Telecommunications Union) specifications, and US-representative on technical supervisory committees. I caused significant economic harm to contractors (benefiting my employer or organizations I consulted for) by incorporating ITU standards in contracts. Therefore I have some knowledge of these matters. Three; gcc-4.3.0 and gcc-4.2.2 will most likely be released under the GPL3 (which not only is intended to replace GPL2 but also the lesser GPL for libraries) Four: under the C specification compiler writers can furnish extensions. But, these extensions are required to have disablers. Five: Yes, gcc is furnished by gnu.org mithout any warranty, or even being fit for merchantability. However, __hidden__ items like libgcc might constitute borderline cases. In the hands of a skillful lawyer, like Mr Edwards, these hidden items could cause a lot of grief to gnu.org and the maintainers as a group. Microsoft could even file an amicus curieae brief. -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug fortran/32310] Intel-darwin specific ICE on CP2K code
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-13 07:27 --- (In reply to comment #2) I can't reduce that any more, it depends on the module files being huge: if you trim them down to a lower number of symbols, they ICE disapears. And I can't reproduced it either on x86_64-linux. FX, Are there any equivalences in the the sources for the modules and do they have any data statements? Even if they do, I am not sure that I believe that the PR29786 patch is involved - how would the module files be compiled if this were the case? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-13 07:30 ---
The C extensions are disabled with --disable-decimal-float. I never said they
were not, in fact here is a quote from me:
Even if you disable dfp, libdecnumber is still needed to compile gcc as
disable-decimal-float really just disables the C interface
Again --disiable-decimal-float just disables the C interface and not the
support library.
- cut --
What don't you understand about C interface?
Also the library libdecnumber is licensed under GPL+extension and not LGPL.
Please read the header and source files before saying they are under a license
when they are not. This is just like libgcc's license.
GPLv3 is not going to replace GPL+ exception, the exception is still going to
be there, nothing is going to change.
To answer your points:
1) It is a copyright license, it gives you rights which you don't have before
with the code.
2) Use -pedantic-errors if you want full C90 complaint (or -std=c99
-pedantic-errors for C99).
3) see above about GPL+exception.
4) See above about my comments about disabling the C interface with
--disable-decimal-float and about -pedantic-errors in 1).
5) wtf, I really mean WHAT THE FUCK. Come on, this is a joke, right? But
really see my point about GPL+ exception, if you don't understand the
exception, then get a laywer to read it. It is not like we are all lawyers
here.
So again --disable-decimal-float disables the C interface. The version of the
library which is being compiled is really the library that gets linked into
GCC.
The code in c-decl.c shows that -pedantic-errors will disable this extension:
if (!targetm.decimal_float_supported_p ())
error (decimal floating point not supported for this target);
if (pedantic)
pedwarn (ISO C does not support decimal floating point);
And it also shows it will disable it for --disable-decimal-float as the default
(and only one) decimal_float_supported_p does:
bool
default_decimal_float_supported_p (void)
{
return ENABLE_DECIMAL_FLOAT;
}
and ENABLE_DECIMAL_FLOAT is set to 0 by configure:
dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi`
AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp,
[Define to 1 to enable decimal float extension to C.])
Where enable_decimal_float is set:
AC_ARG_ENABLE(decimal-float,
[ --enable-decimal-float={no,yes,bid,dpd}
enable decimal float extension to C. Selecting 'bid'
or 'dpd' choses which decimal floating point format
to use],
[
case $enable_decimal_float in
yes | no | bid | dpd) ;;
*) AC_MSG_ERROR(['$enable_decimal_float' is an invalid value for
--enable-decimal-float.
Valid choices are 'yes', 'bid', 'dpd', and 'no'.]) ;;
esac
],
[
case $target in
powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*)
enable_decimal_float=yes
;;
*)
AC_MSG_WARN(decimal float is not supported for this target, ignored)
enable_decimal_float=no
;;
esac
])
What more do you want to say?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #16 from rob1weld at aol dot com 2007-06-13 07:53 --- I did some testing on the CVS of crlibm, (it needs a few files from crlibm-1.0beta1.tar.gz). The new docs list these interesting features: portable to any system implementing the ISO-C99 and IEEE-754 standards, correctly rounded in the four rounding modes, proven, both theoretically and in the implementation, and reasonably efficient in terms of performance (both average and worst-case) and resource usage, exploit fused multiply-and-add operators for the Itanium and PowerPC platforms. optimized for double precision arithmetic and float the subtleties of subnormal numbers are handled properly Compared with the best libraries crlibm offers a precision improvement of a fraction of a unit in the last place (ulp) in round to nearest mode but in the three other rounding modes (used in interval arithmetic) gains up to one ulp of precision in each computation. Results: GNU C Library 2.6crlibm version 1.0beta1GMP version 4.2.1MPFR version 2.2.1-p5 min time avg time max time -- log -- default libm 65 204 1006 MPFR 15517637 67921 CRLibm35 127 896 -- exp -- default libm 151 154 164 MPFR895111970 24460 CRLibm 215 222 1252 -- sin -- default libm 118 137 174 MPFR918931276 85022 CRLibm77 198 10513 -- cos -- default libm 116 136 177 MPFR406521546 66963 CRLibm69 203 9929 -- tan -- default libm 126 150 188 MPFR 1252536528 93573 CRLibm97 335 24587 -- asin -- default libm 257 270 278 MPFR 31985 104582533268 CRLibm69 319 2442 -- acos -- default libm 266 281 293 MPFR 32585 102440533559 CRLibm99 335 2435 -- atan -- default libm 178 192 197 MPFR 1817235185261762 CRLibm 101 265 11572 -- log10 -- default libm 67 206 1004 MPFR 15739135159891 CRLibm38 326 1691 -- log2 -- default libm 68 212 1021 MPFR 15521607 84683 CRLibm38 327 1695 -- sinpi -- default libm 127 136 153 MPFR 1288420203 70476 CRLibm 324 349 1242 -- cospi -- default libm 127 136 157 MPFR846113748 37559 CRLibm 914 935 961 -- tanpi -- default libm 135 148 169 MPFR 1578423623 59309 CRLibm 2340 2441 2479 The libm library is the least accurate and on average the fastest; though not fastest for every function instance. The most accurate is always CRLibm, sometimes it is fastest. The MPFR library is second most accurate and from 50 to over 300 times slower than CRLibm. Here are a few tests of transcendental functions using normal rounding: # ./crlibm_soaktest acos RN 1 | grep 100 CRLIBM : 0 failures out of 100 (ratio 0.00e+00) LIBM : 275 failures out of 100 (ratio 2.75e-04) # ./crlibm_soaktest acospi RN 1 | grep 100 CRLIBM : 0 failures out of 100 (ratio 0.00e+00) LIBM : 17393 failures out of
[Bug fortran/32310] Intel-darwin specific ICE on CP2K code
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-06-13 08:02 --- (In reply to comment #3) Are there any equivalences in the the sources for the modules and do they have any data statements? Even if they do, I am not sure that I believe that the PR29786 patch is involved - how would the module files be compiled if this were the case? I think you're right, I'm sorry for the red herring. I just am completely puzzled by this ICE. (Just to make sure, I rebuilt a compiler from scratch and it still fails.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #11 from rob1weld at aol dot com 2007-06-13 08:06 --- The configure script should check the headers against the library version. Two people from gcc.gnu.org and I all got nailed by this. It may bite others with less computer knowledge than ourselves. The bug is this: 1): The configure script needs a sanity check since GCC compiles and works reasonably well with the library / header mixup. 2): It is the GCC configure script that is choosing the wrong headers to match the library it chose. 3a): _IF_ GCC wants /usr/lib/libmpfr.so/.a it should use /usr/include/mpfr.h 3b): _IF_ GCC wants /usr/local/lib/libmpfr.so/.a it should use /usr/local/include/mpfr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug target/32274] FAIL: gcc.dg/vect/pr32224.c
--- Comment #1 from dorit at il dot ibm dot com 2007-06-13 08:41 ---
Sorry about the breakage. Does it work for you if you change the testcase as
follows?:
Index: pr32224.c
===
--- pr32224.c (revision 125641)
+++ pr32224.c (working copy)
@@ -10,7 +10,7 @@
for (i = 0; i count; i++)
{
-__asm__ (bswap %q0: =r (*__dst):0 (*(__src)));
+__asm__ (checkme: =r (*__dst):0 (*(__src)));
__src++;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
[Bug target/32274] FAIL: gcc.dg/vect/pr32224.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-13 08:50 --- Sorry about the breakage. Does it work for you if you change the testcase as follows?: Yes it will fix it but note there is still a bug in the ia64 back-end anyways so this bug should not be closed as being fixed after the patch gets applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-13 09:01 --- Dear All, I think that you are probably right - it looks like my patch for PR29786 is to blame, since it is the only thing to touch trans-common.c for a long time. This is incorrect - it goes back at least as far as gcc-4.2 20061221. It has nothing, therefore, to do with my recent patch. If you access to a system, I can give you access to troutmask. Send me your ssh public key, and you can play around on [EMAIL PROTECTED] Yeah, it's trans-atlantic. Thanks but it's not necessary - I am trying to ignore gfortran during the day (unsuccessfully, I might say...) and normally have an x86_ia64/FC5 to play with in the evenings. This latter is unavailable until tomorrow because its mains protection was blown up by one of last weeeks storms:( The error creeps in at any level of optimization. I am trying to reduce the testcase but I am rather sure that this is not in the front end. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-13 09:04 --- PS - It also explains a failure by gfortran to produce a working version of the PROTEUS tokamak equilibrium code. I just tried, for the first time, to compile it with no optimization. It is SLOW but it goes. It is peppered with double precisions and equivalences. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-13 09:30 --- The problem lies with the common block aux32, which is declared in subroutine unpki with 6 integer(4) arrays at the beginning and, elsewhere, is declared with default reals. Apparently, this makes a mess of the laying up of the common block with any level of optimization. There are three workarounds: (i) With -DPP, use -fdefault-integer-8 (ii) Put subroutine unpki later in the source file (iii) Change to subroutine unpki(ixp,nwcon,nmel) #ifdef DP implicit double precision (a-h,o-z)dp implicit integer(8) (i-n) #endif parameter(lnv=VECLEN) c c unpack connection data c Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #12 from rob1weld at aol dot com 2007-06-13 09:32 --- Comment #10 From Andrew Pinski 2007 This is not a bug. Here is the deal, the reporter compiled GCC with the new headers but is using the old library (which is known to be buggy). Comment #6 From Rob warning: MPFR header version 2.2.1-p5 differs from library version 2.2.0. I double checked. Configure is taking it's library from /usr/lib/ and using /usr/local/include/mpfr.h The MPFR docs say: `MPFR_VERSION_STRING' is the version as a string constant, which can be compared to the result of `mpfr_get_version' to check at run time the header file and library used match: if (strcmp (mpfr_get_version (), MPFR_VERSION_STRING)) fprintf (stderr, Error, header and library files do not match\n); So we need something as simple as this added to the main configure script: if (strcmp (mpfr_get_version (), MPFR_VERSION_STRING)) return 1; -- rob1weld at aol dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #13 from rob1weld at aol dot com 2007-06-13 09:38 --- Reopen bug reason: Request we add proposed fix to main configuration script. -- rob1weld at aol dot com changed: What|Removed |Added Status|VERIFIED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #52 from seb at frankengul dot org 2007-06-13 10:12 --- (In reply to comment #51) I believe I'm seeing this bug using a redhat build: gcc4.1.1-1 (shows up all the way through -51). It's only on 64bit FC5, 32bit is okay and am installing FC6 to test. Building XULRunner with --enable-canvas causes the problem, greater description of what I'm seeing is in their bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=367208 Basically a hidden symbol from .o to .a to linking in a .so gives the error listed by the reporter here. I can't tell from the comments which build will carry this patch. It looks like it would be in 4.1, but the last comment re: backporting makes me wonder. Also I wonder if this patch would have been pulled in to the Redhat build; I'm not familiar with the relationship to the main gcc tree. Thanks! Hi, this backport to gcc-4.1-4.1.2-9 on debian breaks the glibc build on hppa. The link of librt.so is missing the declaration of symbol __librt_multiple_threads. By trial and errors, I located the faulty patch (between -8 and -11) and it seems to be that one. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428509 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug c++/32316] New: internal compiler error: Segmentation fault
When compiling with g++ -fprofile-arcs -ftest-coverage ... I got the following segmentation fault: /temp//TypeDictionary.C: In function (static destructors for /temp//TypeDictionary.C): /temp//TypeDictionary.C:315: internal compiler error: Segmentation fault Taking a look at the file shows us that the file has only 313 lines, so this is a little bit confusing. Without the profile and coverage options the build works fine. Also with g++ 3.3.6 this build works fine. -- Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: patrick dot pastoor at onespin-solutions dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32316
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #17 from joseph at codesourcery dot com 2007-06-13 11:30 --- Subject: Re: Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor I previously suggested to the crlibm authors that they consider assigning it to the FSF for contribution to libgcc-math http://sourceware.org/ml/libc-alpha/2007-02/msg00010.html. I don't know if anything has happened on that since then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug target/32274] FAIL: gcc.dg/vect/pr32224.c
--- Comment #3 from ubizjak at gmail dot com 2007-06-13 11:55 --- (In reply to comment #2) Sorry about the breakage. Does it work for you if you change the testcase as follows?: Yes it will fix it but note there is still a bug in the ia64 back-end anyways so this bug should not be closed as being fixed after the patch gets applied. No, it is correct fix. We should avoid % modifiers in target-independant tests. The failure is simply due to the fact that %q is not supported in ia64 (please look in config/ia64/ia64.c, around line 4500). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-13 12:08 --- Can you provide a working patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #8 from pault at gcc dot gnu dot org 2007-06-13 12:26 --- This fixes it but is, as yet unregtested. I'll do the business tonight and will commit as 'obvious', if all is well. Thanks, Dale! Paul Index: gcc/fortran/trans-common.c === --- gcc/fortran/trans-common.c (révision 125645) +++ gcc/fortran/trans-common.c (copie de travail) @@ -366,7 +366,8 @@ build_common_decl (gfc_common_head *com, if (strcmp (com-name, BLANK_COMMON_NAME)) gfc_warning (Named COMMON block '%s' at %L shall be of the same size, com-name, com-where); - DECL_SIZE_UNIT (decl) = size; + /*The declaration must be laid out once more and resized. */ + relayout_decl (decl); } } -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-12 15:03:55 |2007-06-13 12:26:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #5 from pranav dot bhandarkar at gmail dot com 2007-06-13 12:36 --- Which RTL pass should take care of such induction variable optimization in 4.3 ? For e.g In 4.1, It was old-loop that was doing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug gcov-profile/32316] internal compiler error: Segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 13:14 --- Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |gcov-profile http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32316
[Bug target/32274] FAIL: gcc.dg/vect/pr32224.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 13:24 --- Sorry if I was not clear before. This is the correct fix for the testcase but not the bug itself. Users could accidently use the %q0 and then get the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-13 13:28 --- Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* It's my turn to ask: so what information does hppa_can_use_return_p need to make the decision ? We need to know that the return pointer (r2) is not used and that the function is a leaf function (i.e., that the incoming value in r2 is unchanged). Calls clobber r2. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #7 from rask at sygehus dot dk 2007-06-13 13:36 --- Looking at this again, I don't think the transformation I'm making with the splitter is valid, because I'm making up a zero extension which wasn't there to begin with. The upper part could have been non-zero before the instruction. As to the original example, it should be possible to optimize addl%eax, %edx cmpl%edx, %eax ja .L7 into addl%eax, %edx jc .L7 with a CCmode expressing that the carry flag is set if %edx is smaller than %eax. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug fortran/32317] New: No warning on bad arguments with explicit interface
Even when an explicit interface is known, no warnings are generated when array argument bounds (available to the compiler) don't match. Consider the following: module mod implicit none contains subroutine a(n,v) integer,intent(in)::n real,dimension(n),intent(in)::v write(*,*)v end subroutine a subroutine b real,dimension(5)::v v=0 call a(8,v(1:4)) end subroutine b end module mod When b is being compiled the interface to a is known, yet no warnings are generated of the obvious mismatch in the arguments (run.f90 just calls b): $ gfortran -Wall -W -c --std=f2003 --pedantic -fbounds-check -O case.f90 $ gfortran -Wall -W --std=f2003 --pedantic -fbounds-check -O run.f90 case.o $ ./a.out 0.00 0.00 0.00 0.00 0.00 0.00 -1.1411260E-37 1.5604860E-41 -5.1655852E-38 1.5604860E-41 -6.3728095E-38 1.5604860E-41 0.00 0.00 5.8804453E-39 0.00 4.2038954E-45 0.00 5.8809218E-39 0.00 -6.3728095E-38 1.5604860E-41 -8.5373851E-38 1.5604860E-41 5.8801398E-39 While this construct is probably legal as a hang-on from crappy old fortran, I can't think of a situation when giving explicit bounds like this where simply overrunning would be the desired effect. A warning would be nice. (I was going to also complain that -fbouns-check didn't come up with anything, but then I saw PR 27989.) -- Summary: No warning on bad arguments with explicit interface Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: terry at chem dot gu dot se GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #9 from dir at lanl dot gov 2007-06-13 13:39 --- Your Welcome Paul, With a little luck, the fix for this will cure the remaining problems that I have been having with my programs when optimization is turned on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug fortran/32317] No warning on bad arguments with explicit interface
--- Comment #1 from terry at chem dot gu dot se 2007-06-13 13:43 --- (Whoops. Mixed up output in that last post. Only 8 reals are printed in reality. My bad.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
[Bug gcov-profile/32316] internal compiler error: Segmentation fault
--- Comment #2 from patrick dot pastoor at onespin-solutions dot com 2007-06-13 14:26 --- I am really sorry. But I think there is no possiblity to upload a preprocessed source here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32316
[Bug bootstrap/18388] bootstrapping failing on HP-UX 11.23/IA64
--- Comment #2 from ckirshen at gnupower dot net 2007-06-13 14:37 --- This problem definitely exists on both hpux 11v2 and 11v3, even when passing in --with-gnu-as and --with-as. I'm trying this on gcc-3.4.3 and gcc-3.4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18388
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #10 from pault at gcc dot gnu dot org 2007-06-13 15:00 --- I goofed - the previous does not fix it at all. I hope that I am not too late to stop folk from building with this patch. Cheers Paul PS Compiling the subroutines separately or padding out the first aux32 both fix the problem, so I think that the patch is touching the right place. That is, the union type that is joined to the top level has some information missing about its size, when a resize occurs. I just need to figure out what it is:) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #6 from jakub at gcc dot gnu dot org 2007-06-13 15:22 ---
I see that PR25505 caused a bunch of code generation regressions.
On i?86, with -O2 -m32:
_Complex double foo (_Complex double x)
{
return __builtin_cexp (x);
}
generated code got much worse, similarly:
elemental function specific__exp_c8 (parm)
complex (kind=8), intent (in) :: parm
complex (kind=8) :: specific__exp_c8
specific__exp_c8 = exp (parm)
end function
In the above 2 cases, dest_safe_for_nrv_p is called on an SSA_NAME. At least
in
these cases it should be safe to use SSA_NAME_VAR, shouldn't it?
A different testcase that regressed is:
struct P
{
long long l;
int a;
unsigned int b;
P(long long x) : l(x) {}
};
P foo (P);
P bar (P);
P foo (P x)
{
P y = P (-1LL);
y = bar (x);
return y;
}
Here dest_safe_for_nrv_p is passed a RESULT_DECL and is again something
that ought to be optimized out, but is not any longer.
static bool
dest_safe_for_nrv_p (tree dest, location_t *loc)
{
subvar_t subvar;
while (handled_component_p (dest))
dest = TREE_OPERAND (dest, 0);
if (! SSA_VAR_P (dest))
return false;
if (TREE_CODE (dest) == SSA_NAME)
dest = SSA_NAME_VAR (dest);
if (is_call_clobbered (dest))
return false;
for (subvar = get_subvars_for_var (dest); subvar; subvar = subvar-next)
if (is_call_clobbered (subvar-var))
return false;
return true;
}
handles all of these (i.e. doesn't regress on any of them). I have verified
that
it e.g. refuses to NRV optimize:
struct P
{
long long l;
int a;
unsigned int b;
P(long long x) : l(x) {}
};
P foo (P);
P bar (P);
void baz (P *);
P foo (P x)
{
P y = P (-1LL);
baz (y);
y = bar (x);
return y;
}
because the RESULT_DECL escapes.
It regresses on the initial testcase from this bugreport, so it would mean
writing a different bugfix (most probably in calls.c, check that the target
doesn't overlap with the arguments being pushed), but it might very well be
worth it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug ada/32318] New: GNAT.Calendar.Time_IO %c incorrectly claims to be reporting the time zone
The spec file explains that the picture %c stands for locale's date and time (including the time zone). However, the replacement picture doesn't include %z (which isn't supported AFAICS.) from the spec: -- %c locale's date and time (Sat Nov 04 12:02:33 EST 1989) from the body: when 'c' = case Padding is when Zero = Result := Result Image (Date, %a %b %d %T %Y); $ ./testtime Wed Jun 13 17:17:41 2007 (This has lead to a time shift when some application, such as a MTA, interprets the time WRT a different default time zone, such as UTC.) with GNAT.Calendar.Time_IO; with Ada.Calendar; with Ada.Text_IO; procedure testtime is begin Ada.Text_IO.Put_Line (GNAT.Calendar.Time_IO.Image (Ada.Calendar.Clock, %c)); end; The code is present in trunk, Rev 125413 -- Summary: GNAT.Calendar.Time_IO %c incorrectly claims to be reporting the time zone Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bauhaus at futureapps dot de GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32318
[Bug fortran/32319] New: Bad automatic array argument
[EMAIL PROTECTED] cat run.f90 subroutine aa(v) integer,dimension(:),intent(out)::v write(*,*)size(v) v=0 end subroutine aa program ff implicit none integer,dimension(10)::w w=1 write(*,*)w call aa(w(1:5)) write(*,*)w end [EMAIL PROTECTED] gfortran -Wall -W -fbounds-check -O --std=f95 --pedantic -v run.f90 Driving: gfortran -Wall -W -fbounds-check -O -std=f95 -pedantic -v run.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --disable-multilib --enable-languages=fortran Thread model: posix gcc version 4.2.0 20070501 (prerelease) /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 run.f90 -quiet -dumpbase run.f90 -mtune=generic -auxbase run -O -Wall -W -pedantic -std=f95 -version -fbounds-check -I /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/cc6lORdO.s GNU F95 version 4.2.0 20070501 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20070501 (prerelease). GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=112193 as --traditional-format -V -Qy -o /tmp/ccyEdACx.o /tmp/cc6lORdO.s GNU assembler version 2.17.50 (x86_64-linux-gnu) using BFD version 2.17.50 20070103 Ubuntu /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtbegin.o -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../.. /tmp/ccyEdACx.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtend.o /usr/lib/../lib64/crtn.o [EMAIL PROTECTED] ./a.out 1 1 1 1 1 1 1 1 1 1 -1762200976 Segmentation fault This has really surprised me, as I'd swear I've used this construct recently. So much so, I even went and upgraded my gcc just to test it! (In case anyone cares, I was in the process of testing some of the implications of not having PR32317 implemented with array sections and vector subscripts and the like. Clearly, I never got that far!) -- Summary: Bad automatic array argument Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: terry at chem dot gu dot se GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32319
[Bug objc++/32320] New: [4.1 regression] ICE with invalid template parameter
+++ This bug was initially created as a clone of Bug #27668 +++
The following invalid code snippet triggers an ICE since GCC 3.4.0:
==
templatetypename class T, T = T() struct A {};
templateint void foo(Aint);
==
bug.cc:1: error: expected nested-name-specifier before 'class'
bug.cc:1: error: two or more data types in declaration of 'parameter'
bug.cc:1: error: 'struct T' is not a valid type for a template constant
parameter
bug.cc:3: error: type/value mismatch at argument 1 in template parameter list
for 'templateint anonymous, void anonymous struct A'
bug.cc:3: error: expected a constant of type 'int', got 'int'
bug.cc:3: internal compiler error: in value_dependent_expression_p, at
cp/pt.c:12489
Please submit a full bug report, [etc.]
--
Summary: [4.1 regression] ICE with invalid template parameter
Product: gcc
Version: new-ra
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uhle1982 at yahoo dot com
GCC build triplet: same
GCC host triplet: Seize
GCC target triplet: like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32320
[Bug middle-end/32321] New: ICE in df_refs_verify
gcc-4.3 -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --enable-checking --prefix=/opt/gcc --enable-shared --enable-threads --program-suffix=-4.3 --enable-__cxa_atexit --disable-nls --with-mpfr=/usr/local --enable-languages=c,c++,objc,obj-c++,treelang,fortran Thread model: posix gcc version 4.3.0 20070612 (experimental) gcc-4.3 -c -O2 -fgcse-sm bdd_kernel.c bdd_kernel.c: In function 'bdd_noderesize': bdd_kernel.c:27: internal compiler error: in df_refs_verify, at df-scan.c:4092 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in df_refs_verify Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsarkov at cs dot man dot ac dot uk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
[Bug c++/32322] New: pointers to overloaded methods not correctly resolved
In a template-context, pointers to overloaded methods are not correctly
resolved. the following main.cpp does not compile on gcc 4.1.2, however it does
compile on version 3.4.6:
#include boost/multi_index_container.hpp
#include boost/multi_index/member.hpp
#include boost/multi_index/composite_key.hpp
#include boost/multi_index/mem_fun.hpp
namespace mi = boost::multi_index;
struct field_ts
{
int ts() const { return 10; }
void ts(const int arg) { }
};;
template typename T
struct mi_key
{
typedef typename mi::composite_key
field_ts,
mi::const_mem_funfield_ts, int, field_ts::ts
type;
};
mi_keyint::type key;
int main (int argc, char **argv)
{
return 0;
}
I get the following error-message:
main2.cpp: In instantiation of mi_keyint:
main2.cpp:26: instantiated from here
main2.cpp:23: error: invalid use of field_ts::ts to form a
pointer-to-member-function
main2.cpp:23: note: a qualified-id is required
The compiler should do this automatically without you having
to disambiguate the overload, see 14.3.2/5:
For a non-type template-parameter of type pointer to member
function, no conversions apply. If the template-argument represents
a set of overloaded member functions, the matching member
function is selected from the set (13.4).
--
Summary: pointers to overloaded methods not correctly resolved
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mavdzee at yahoo dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32322
[Bug middle-end/32321] ICE in df_refs_verify
--- Comment #1 from tsarkov at cs dot man dot ac dot uk 2007-06-13 15:42 --- Created an attachment (id=13697) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13697action=view) Preprocessed sources Code that triggers ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
[Bug bootstrap/32312] [4.3 regression] bootstrap failure on sparc-sun-solaris2.10
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-06-13 15:45 --- Fixed: http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00615.html by this patch: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00842.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32312
[Bug target/30652] SSE expansion is missing for isinf() and other fpclassify functions
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-06-13 15:57 --- (In reply to comment #2) The generic implementation, including for SSE, is isgreater (abs(f), FLT_MAX) For isfinite, use islessequal instead. For isnan, one can use isunordered(f, f) For isnormal, it'd be isgreaterequal(abs(f), FLT_MIN) islessequal(abs(f), FLT_MAX) which is less likely to be friendly to inline. I'd like to do this, but how does one generate FLT_MAX et al. from the middle-end? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30652
[Bug fortran/32319] Bad automatic array argument
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-13 15:57 --- If you would provide an explicit interface for AA, the binary would not segfault: $ cat pr32319.f90 program ff implicit none integer,dimension(4)::w w=1 write(*,*)w call aa(w(2:3)) write(*,*)w contains subroutine aa(v) integer,dimension(:),intent(out)::v write(*,*)size(v) v=0 end subroutine aa end $ gfortran-svn pr32319.f90 ./a.out 1 1 1 1 2 1 0 0 1 Without explicit interface, the binary produced by ifort crashes the same way as the one generated by gfortran, sunf95 issues this message on the original code: $ sunf95 -w4 pr32319.f90 call aa(w(1:5)) ^ pr32319.f90, Line = 13, Column = 1: ERROR: Procedure AA is defined at line 1 (pr32319.f90). It must have an explicit interface specified. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32319
[Bug fortran/32319] Bad automatic array argument
--- Comment #2 from terry at chem dot gu dot se 2007-06-13 16:10 --- Ah. Of course explicit interfaces are required for automatic array arguments. My Fortran-Fu seems to be deserting me at the moment. :-( -- terry at chem dot gu dot se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32319
[Bug fortran/32317] No warning on bad arguments with explicit interface
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-13 16:17 --- Neither SUN nor Intel fortran compilers issue such a warning. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||spark at gcc dot gnu dot org Keywords||ice-on-valid-code Summary|ICE in df_refs_verify |[4.3 Regression] ICE in ||df_refs_verify with -fgcse- ||sm Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
[Bug fortran/32317] No warning on bad arguments with explicit interface
--- Comment #3 from terry at chem dot gu dot se 2007-06-13 16:23 --- (In reply to comment #2) Neither SUN nor Intel fortran compilers issue such a warning. Indeed. That does not imply that gfortran shouldn't, though. Hence the enhancement request. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
[Bug fortran/32323] New: Accepts invalid vector subscript actual argument for intent(out) dummy argument
[EMAIL PROTECTED] cat run.f90 module mod implicit none contains subroutine aa(v) integer,dimension(:),intent(out)::v write(*,*)size(v) v=0 end subroutine aa end module mod program ff use mod implicit none integer,dimension(10)::w w=1 call aa(w((/3,2,1/))) write(*,*)w end [EMAIL PROTECTED] gfortran -v -Wall -W --std=f95 --pedantic -O -fbounds-check run.f90 Driving: gfortran -v -Wall -W -std=f95 -pedantic -O -fbounds-check run.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --disable-multilib --enable-languages=fortran Thread model: posix gcc version 4.2.0 20070501 (prerelease) /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 run.f90 -quiet -dumpbase run.f90 -mtune=generic -auxbase run -O -Wall -W -pedantic -std=f95 -version -fbounds-check -I /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccFuwYwj.s GNU F95 version 4.2.0 20070501 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20070501 (prerelease). GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=112193 as --traditional-format -V -Qy -o /tmp/ccIcA5Sy.o /tmp/ccFuwYwj.s GNU assembler version 2.17.50 (x86_64-linux-gnu) using BFD version 2.17.50 20070103 Ubuntu /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtbegin.o -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../.. /tmp/ccIcA5Sy.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtend.o /usr/lib/../lib64/crtn.o [EMAIL PROTECTED] ./a.out 3 1 1 1 1 1 1 1 1 1 1 For those that care, both ifort and g95 correctly identify this as invalid code. (Maybe I can get one right today! ;-) -- Summary: Accepts invalid vector subscript actual argument for intent(out) dummy argument Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: terry at chem dot gu dot se GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32323
[Bug c/32324] New: unsigned long long operator and integer literals
The result of the division of 18446744065119617024llu by the result of (131)
is wrong on a 32bit platform.
Reproduce: gcc s.c ./a.out
should have exit code 0 but doesn't.
Expected: gcc -DEXPECTED s.c ./a.out
has exit code 0 as expected.
gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)
[lxbuild021] /afs/cern.ch/user/a/axel/tmp/gccconv
/afs/cern.ch/sw/lcg/contrib/gcc/4.1.2/slc4_ia32_gcc34/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /build/LCG/gcc-4.1.2/configure
--prefix=/afs/cern.ch/sw/lcg/contrib/gcc/4.1.2/slc4_ia32_gcc34
Thread model: posix
gcc version 4.1.2
uname -a
Linux lxbuild021.cern.ch 2.6.9-42.0.10.EL.cernsmp #1 SMP Thu Mar 1 15:11:46 CET
2007 i686 i686 i386 GNU/Linux
I'll give the .c instead of .i because it shows the expected result and has no
#includes:
int main (){
unsigned long long a = 18446744065119617024llu;
/* results expected to be identical */
#ifdef EXPECTED
int b = ((int)(131));
a = a / b;
#else
a = a / ((int)(131));
#endif
return a;
}
--
Summary: unsigned long long operator and integer literals
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at axel-naumann dot de
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32324
[Bug c/32324] unsigned long long operator and integer literals
--- Comment #1 from gcc at axel-naumann dot de 2007-06-13 16:50 --- Created an attachment (id=13699) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13699action=view) Test case as stated in the report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32324
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #7 from jconner at apple dot com 2007-06-13 17:09 --- (In reply to comment #6) I see that PR25505 caused a bunch of code generation regressions. On i?86, with -O2 -m32: ... When you say regressions, I assume you mean size/performance, not correctness, right? If so, that's to be expected, as the previous tree-nrv implementation was being overly permissive, and the new implementation is conservatively pessimistic, as the comments indicate. If I have introduced anything incorrect, please let me know and I'd be glad to take a look. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug c++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #4 from appfault at hotmail dot com 2007-06-13 17:38 --- Yes in addition to the issue of adding a test case, it is quite unsettling to not know what might have fixed it. Reopening pending response to comment 2 and comment 3. -- appfault at hotmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #18 from kargl at gcc dot gnu dot org 2007-06-13 17:52 --- The libm library is the least accurate and on average the fastest; though not fastest for every function instance. The most accurate is always CRLibm, sometimes it is fastest. The MPFR library is second most accurate and from 50 to over 300 times slower than CRLibm. You've shown nothing to validate that crlibm is more accurate than mpfr. So how did you do this measurement? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-13 17:53 --- Look at PR 17108 also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||17108 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug other/32263] Document the required versions of glibc and binutils
--- Comment #5 from appfault at hotmail dot com 2007-06-13 17:56 --- Ok well, I'll take your word on that, since I can't really tell where gcc and ld end and glibc begins. It's perhaps glibc that is in need of better documentation then. However if I file such a zilla I suspect it will quickly be marked duplicate of http://sources.redhat.com/bugzilla/show_bug.cgi?id=333 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32263
[Bug c/32324] unsigned long long operator and integer literals
--- Comment #2 from andrew dot stubbs at st dot com 2007-06-13 18:00
---
As it happens, I encountered your real problem quite recently. :)
(int)(131) is undefined (C99 standard 6.5.7/4).
This modified version gives the same result both ways:
int main (){
unsigned long long a = 18446744065119617024llu;
/* results expected to be identical */
#ifdef EXPECTED
unsigned int b = ((unsigned int)(131));
a = a / b;
#else
a = a / ((unsigned int)(131));
#endif
return a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32324
[Bug fortran/32323] Accepts invalid vector subscript actual argument for intent(out) dummy argument
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-13 18:03 --- Thanks for finding this bug! I think it is the following in the Fortran 2003 standard: 12.4.1.2 Actual arguments associated with dummy data objects If a nonpointer dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall be definable. If the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the INTENT (OUT), INTENT (INOUT), VOLATILE, or ASYNCHRONOUS attributes. Thus we also also need to check for VOLATILE instead of INTENT(IN)/INTENT(INOUT). Note that array sections without vector subscripts such as call aa(w(3:1)) are allowed! -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2007-06-13 18:03:56 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32323
[Bug c++/32325] New: cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info
During a mainline bootstrap on alpha-dec-osf5.1b, the libstdc++ configure
failed:
checking for exception model to use... configure: error: unable to detect
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
config.log reveals:
configure:13794: checking for exception model to use
configure:13838: /vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/./gcc/xgcc
-shared-libgcc -B/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src/.libs
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem
/vol/gcc/alpha-dec-osf5.1b/include -isystem
/vol/gcc/alpha-dec-osf5.1b/sys-include -c -S conftest.cc 5
configure: In function 'void foo()':
configure:13836: error: end insn 27 for block 7 not found in the insn stream
configure:13836: error: head insn 24 for block 7 not found in the insn stream
configure:13836: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
configure:13841: $? = 1
configure:13870: error: unable to detect exception model
This happens with the following conftest.cc:
struct S { ~S(); };
void bar();
void foo()
{
S s;
bar();
}
% ./cc1plus conftest.cc
void foo()
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inlineAssembling functions:
void foo()
conftest.cc: In function 'void foo()':
conftest.cc:7: error: end insn 27 for block 7 not found in the insn stream
conftest.cc:7: error: head insn 24 for block 7 not found in the insn stream
conftest.cc:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Running gdb reveals
Program received signal SIGSEGV, Segmentation fault.
rtl_verify_flow_info () at /vol/gcc/src/gcc-dist/gcc/cfgrtl.c:2005
(gdb) where
#0 rtl_verify_flow_info () at /vol/gcc/src/gcc-dist/gcc/cfgrtl.c:2005
#1 0x000120516638 in verify_flow_info () at
/vol/gcc/src/gcc-dist/gcc/cfghooks.c:245
#2 0x000120618934 in commit_edge_insertions () at
/vol/gcc/src/gcc-dist/gcc/cfgrtl.c:1467
#3 0x000120415bcc in alpha_gp_save_rtx () at
/vol/gcc/src/gcc-dist/gcc/config/alpha/alpha.c:4784
#4 0x0001206406fc in gen_exception_receiver () at
/vol/gcc/src/gcc-dist/gcc/config/alpha/alpha.md:7019
#5 0x000120314dc8 in finish_eh_generation () at
/vol/gcc/src/gcc-dist/gcc/except.c:1633
#6 0x000120314f98 in rest_of_handle_eh () at
/vol/gcc/src/gcc-dist/gcc/except.c:3985
#7 0x000120421978 in execute_one_pass (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1124
#8 0x000120421c48 in execute_pass_list (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1177
#9 0x000120421c5c in execute_pass_list (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1178
#10 0x0001204fef44 in tree_rest_of_compilation (fndecl=0x0) at
/vol/gcc/src/gcc-dist/gcc/tree-optimize.c:406
#11 0x0001202535c8 in c_expand_body (fndecl=0x140137d80) at
/vol/gcc/src/gcc-dist/gcc/c-common.c:4331
#12 0x0001201ea958 in expand_body (fn=0x18de60) at
/vol/gcc/src/gcc-dist/gcc/cp/semantics.c:3136
#13 0x000120423f60 in cgraph_expand_function (node=0x18de60) at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1073
#14 0x000120427400 in cgraph_optimize () at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1142
#15 0x00012015e054 in cp_write_global_declarations () at
/vol/gcc/src/gcc-dist/gcc/cp/decl2.c:3305
#16 0x0001204432e0 in toplev_main (argc=1, argv=0x0) at
/vol/gcc/src/gcc-dist/gcc/toplev.c:1064
#17 0x00012029fe98 in main (argc=1075019136, argv=0x11fffbb30) at
/vol/gcc/src/gcc-dist/gcc/main.c:35
(gdb) p x
$1 = 0x0
I.e. rtl_verify_flow_info dereferences a NULL pointer. This happens only
on alpha-dec-osf5.1b, alpha-dec-osf4.0f is unaffected.
Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha
host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap
How-To-Repeat:
Bootstrap as described above.
--
Summary: cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B:
SEGV in rtl_verify_flow_info
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
GCC build triplet: alpha-dec-osf5.1b
GCC host triplet: alpha-dec-osf5.1b
GCC target triplet:
[Bug target/32325] [4.3 Regression] cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c++ |target Keywords||build, ice-on-valid-code Summary|cc1plus ICE configuring |[4.3 Regression] cc1plus ICE |libstdc++ on Tru64 UNIX |configuring libstdc++ on |V5.1B: SEGV in |Tru64 UNIX V5.1B: SEGV in |rtl_verify_flow_info|rtl_verify_flow_info Target Milestone|--- |4.3.0 Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32325
[Bug c/32326] New: ICE when -g specified
This may be a duplicate of PR 28868
a.c
=
typedef struct a1 {
int x;
} a1_t __attribute__((may_alias));
=
a.c:3: internal compiler error: in splice_child_die, at dwarf2out.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/ccI0138Q.out file, please attach this to
your bugreport.
It does not occur targeting
tic4x-rtems with gcc 3.4.6
avr-rtems with gcc 4.0.3
mingw with gcc 4.1.2
i386-rtems with gcc 4.1.2
i386-rtems with gcc 4.2.0
It occurs with many gcc versions and targets:
gcc 4.1.1 Fedora Core 6 - i686-pc-linux-gnu
gcc 4.1.1 RTEMS - arm, h8300, i386, m68k, mips, powerpc, sh, sparc
gcc 4.1.2 RTEMS - arm, bfin, h8300, m68k, mips, powerpc, sh, sparc
gcc 4.2.0 RTEMS - arm, bfin, h8300, m68k, mips, powerpc, sh, sparc
--
Summary: ICE when -g specified
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: cross target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32326
[Bug c/32326] ICE when -g specified
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 19:27 --- It does not occur targeting I doubt those use dwarf2/3 :). *** This bug has been marked as a duplicate of 29436 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|ICE when -g specified |ICE when -g specified http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32326
[Bug debug/29436] [4.0/4.1/4.2/4.3 Regression] ICE in modified_type_die
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-13 19:27 --- *** Bug 32326 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug fortran/32323] Accepts invalid vector subscript actual argument for intent(out) dummy argument
--- Comment #2 from patchapp at dberlin dot org 2007-06-13 19:30 --- Subject: Bug number PR32323 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00910.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32323
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #5 from daney at gcc dot gnu dot org 2007-06-13 19:44 --- Unfortunatly the patch causes an ICE compiling crtstuff.c. I will have to adjust it a bit... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug c/32327] New: Incorrect stack sharing causing removal of live code
Given the following code:
--
typedef unsigned int size_t;
typedef unsigned long long uint64;
extern C {
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n) /*throw ()*/;
}
extern void foo (void* p);
inline uint64
ghtonll(uint64 x)
{
// __r is allocated the same stack slot as dest below
union { unsigned long long int __ll;
unsigned long int __l[2]; } __w, __r;
__w.__ll = x;
__r.__l[0] = (
{
register unsigned int __v;
__asm__ __volatile__ (bswap %0 : =r (__v) :
0 ((unsigned int) (__w.__l[1])));
__v; });
__r.__l[1] = (
{
register unsigned int __v;
__asm__ __volatile__ (bswap %0 : =r (__v) :
0 ((unsigned int) (__w.__l[0])));
__v; });
return __r.__ll;
}
inline uint64
double_2_uint64 (const double *source)
{
uint64 dest; // allocated the same stack slot as __r above
memcpy(dest, source, sizeof(dest));
return dest;
}
inline void
KeyFromUint64(uint64 fp) {
uint64 norder;
norder = ghtonll (fp);
foo((char*)(norder));
}
void
KeyFromDouble(double x) {
uint64 n = double_2_uint64 (x);
if (n = 42) {
n += 1;
}
KeyFromUint64(n);
}
---
Here is what gcc -O2 -fdump-tree-all (version 4.2) in at the end of the tree
passes.
Please take note of the assignment to dest after that of norder.
;; Function void KeyFromDouble(double) (_Z13KeyFromDoubled)
void KeyFromDouble(double) (x)
{
uint64 n.50;
char * norder.2;
uint64 norder;
register unsigned int __v;
register unsigned int __v;
union ._0 __r;
union ._0 __w;
uint64 dest;
uint64 n;
bb 2:
n.50 = VIEW_CONVERT_EXPRuint64(x);
if (n.50 41) goto L0; else goto L5;
L5:;
n = n.50;
goto bb 5 (L1);
L0:;
n = n.50 + 1;
L1:;
__w.__ll = n;
__asm__ __volatile__(bswap %0:=r __v:0 __w.__l[1]);
__r.__l[0] = __v;
__asm__ __volatile__(bswap %0:=r __v:0 __w.__l[0]);
__r.__l[1] = __v;
norder = __r.__ll;
norder.2 = (char *) norder;
dest = n.50;
foo (norder.2);
return;
}
Here is part of the RTL expansion:
(insn 45 43 47 9 (set (mem/c/i:DI (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -8 [0xfff8])) [3 norder+0 S8 A32])
(reg/v:DI 64 [ __r ])) -1 (nil)
(nil))
(insn 47 45 49 9 (parallel [
(set (reg:SI 59 [ norder.2 ])
(plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -8 [0xfff8])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(insn 49 47 51 9 (set (mem/c/i:DI (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -8 [0xfff8])) [3 dest+0 S8 A32])
(reg/v:DI 58 [ n.50 ])) -1 (nil)
(nil))
Both dest norder are assigned the same memory location
(virtual-stack-vars - 8). So later lifeness analysis thinks that the
first assignment is dead and it removes it. norder contains results of
bswap but gcc cannot remove the asm statement. However, since the
output of the asms are dead so they both got eax as the output
register.
--
Summary: Incorrect stack sharing causing removal of live code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #6 from dje at gcc dot gnu dot org 2007-06-13 20:00 --- From IRC: see.c:2732 makes a copy of an insn and then hacks on it with validate_change (and it's close relatives). This copy has a basic_block, even though it is not in the insn stream, as well as the same insn_uid as the old insn. zadeck This is very bad for df. df assumes that insns have a null block until they are inserted into the insn stream and it also uses the insn_uid as the index into tables for the side info. I can fix part of the problem by nulling out the bb for the clone, but i need to give it a shiney new uid (or else use some properly supported function to make a copy of an insn. This is very bad for df. df assumes that insns have a null block until they are inserted into the insn stream and it also uses the insn_uid as the index into tables for the side info. I can fix part of the problem by nulling out the bb for the clone, but i need to give it a shiney new uid (or else use some properly supported function to make a copy of an insn. it links the copy into the insn chain by hand better would be to skip the make_insn_raw, and just call emit_insn_before at the appropriate moment that is, copy the pattern, not the whole insn and pass the pattern to emit_insn_before it leaves the 2 insn sequence hanging in mid air until later in the pass it may or may not replace the old insn with the new sequence that's why god invented start_sequence/end_sequence--so that you can build and handle sequences of insns -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug fortran/32323] Accepts invalid vector subscript actual argument for intent(out) dummy argument
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-13 20:12 --- Subject: Bug 32323 Author: burnus Date: Wed Jun 13 20:12:40 2007 New Revision: 125684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125684 Log: 2007-06-13 Tobias Burnus [EMAIL PROTECTED] PR fortran/32323 * interface.c (has_vector_section): New. (compare_actual_formal): Check for array sections with vector subscript. 2007-06-13 Tobias Burnus [EMAIL PROTECTED] PR fortran/32323 * gfortran.dg/actual_array_vect_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/actual_array_vect_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32323
[Bug fortran/32323] Accepts invalid vector subscript actual argument for intent(out) dummy argument
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-13 20:14 --- Fixed in 4.3. As it is neither a regression nor a wrong-code bug, it will not be fixed for 4.2.1 or 4.1.3. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32323
[Bug middle-end/31723] Use reciprocal and reciprocal square root with -ffast-math
--- Comment #25 from ubizjak at gmail dot com 2007-06-13 20:20 --- RFC patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00916.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #6 from daney at gcc dot gnu dot org 2007-06-13 20:39 --- Created an attachment (id=13700) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13700action=view) Revised patch. I don't know what I was thinking with the first version of the patch :-( The new version I think is more likely to be correct. -- daney at gcc dot gnu dot org changed: What|Removed |Added Attachment #13696|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug fortran/32203] Support the vendor intrinsic function TIMEF
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-13 20:41:20 date|| Summary|Support the vendor intrinsic|Support the vendor intrinsic |function timef() |function TIMEF http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32203
[Bug fortran/32155] Unresolved external __gfortran_os_error in program that manipulates strings
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-13 20:45 --- Hard to tell what is going wrong. I've been building and using compilers on i386-darwin with no problem. Please contact the people behind HPC MacOS X to see if they can help you using this compiler, or download our own (http://gcc.gnu.org/wiki/GFortranBinaries#MacOS) If you find indication that the bug is indeed with GCC itself, or can reproduce it on your system using a freshly built compiler, please reopen this PR or file a new one. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32155
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-06-13 20:49 --- (In reply to comment #9) I don't see the point of these questions though. After all, I confirmed your bug with gcc 4.1, and also that it's fixed in 4.2 and 4.3. So the remaining question is whether this will be fixed in 4.1 (which I doubt). No, this will not be fixed. Thanks for the bugreport anyway, Michael, and I hope you can get your GCC-4.3 build working. (If you need technical help doing so, you can ask on the [EMAIL PROTECTED] mailing-list.) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet||mips-linux GCC host triplet||mips-linux GCC target triplet||mips-linux Keywords||ice-on-valid-code Known to fail||4.1.2 Known to work||4.2.1 4.3.0 Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug fortran/32317] [bounds checking] No warning on bad arguments with explicit interface
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27766 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2007-06-13 20:51:01 date|| Summary|No warning on bad arguments |[bounds checking] No warning |with explicit interface |on bad arguments with ||explicit interface http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
[Bug fortran/32315] DATA with implied-do: Bounds checks missing
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27766 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-13 20:51:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32315
[Bug fortran/32179] Ensure that ss-string_length is always set [TODO item]
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-13 20:52:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32179
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-13 20:54:10 date|| Summary|Accepts invalid |Accepts invalid |character(len(a)),dimension(|character(len(a)),dimension( |1) :: a |1) :: a http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug c/32328] New: 4.2.0: -O2 causes skipped code
When the attached file is compiled with a mingw32 build of GCC 4.2.0 using the -O2 option (gcc -O2 -c timestamp2.i), lines 159 and 160 are never executed when running the program that uses this file. Since the hashitem function modifies the variable b which is passed to it by-address, leaving those statements out is definitely not a valid optimization. Compiling without -O2 (gcc -c timestamp2.i) gives the correct result. Sorry I can't read assembler, or I'd try to narrow things down more. This is a regression from 4.1.2, which works correctly with or without -O2. If it helps, the GCC binaries I use (and sources) can be downloaded at http://hosted.filefront.com/tldragon7. -- Summary: 4.2.0: -O2 causes skipped code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tdragon at tdragon dot net GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug c/32328] 4.2.0: -O2 causes skipped code
--- Comment #1 from tdragon at tdragon dot net 2007-06-13 21:19 --- Created an attachment (id=13701) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13701action=view) Preprocessed example source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug middle-end/32327] Incorrect stack sharing causing removal of live code
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 21:20 --- Why is the store to dest not being removed? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] Incorrect stack sharing causing removal of live code
--- Comment #2 from dougkwan at google dot com 2007-06-13 21:25 --- The address of dest has been passed to memcpy() and the alias analysis considers the varaible to escape. So potentially foo() can see the value of dest if memcpy() stash the pointer somewhere. This is impossible but the compiler cannot prove this so it has to be conservative and treat foo() as a potential reader of dest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] Incorrect stack sharing causing removal of live code
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-13 21:32 --- No, it should be marked as non escaping later on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] Incorrect stack sharing causing removal of live code
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 21:37 --- On the trunk, dest is changed to be non addressable in alias5, why is it not doing it in 4.2? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-13 21:42 --- (In reply to comment #2) The address of dest has been passed to memcpy() and the alias analysis considers the varaible to escape. So potentially foo() can see the value of dest if memcpy() stash the pointer somewhere. This is impossible but the compiler cannot prove this so it has to be conservative and treat foo() as a potential reader of dest. We remove the call to memcpy (in 4.2) in .064t.fab and then alias5 should have changed it (dest) to be non ADDRESSABLE but it is not for some reason. I think may_alias is messed up in 4.2.0. Also sink maybe should not be sinking stores. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.3.0 |4.3.0 4.1.1 Summary|Incorrect stack sharing |[4.2 Regression] Incorrect |causing removal of live code|stack sharing causing ||removal of live code Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #6 from dougkwan at google dot com 2007-06-13 21:50 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Fixing alias analysis in 4.2.0 will make this problem go away but it does not change the underlying issue in the stack local sharing code. 13 Jun 2007 21:42:01 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-13 21:42 --- (In reply to comment #2) The address of dest has been passed to memcpy() and the alias analysis considers the varaible to escape. So potentially foo() can see the value of dest if memcpy() stash the pointer somewhere. This is impossible but the compiler cannot prove this so it has to be conservative and treat foo() as a potential reader of dest. We remove the call to memcpy (in 4.2) in .064t.fab and then alias5 should have changed it (dest) to be non ADDRESSABLE but it is not for some reason. I think may_alias is messed up in 4.2.0. Also sink maybe should not be sinking stores. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.3.0 |4.3.0 4.1.1 Summary|Incorrect stack sharing |[4.2 Regression] Incorrect |causing removal of live code|stack sharing causing ||removal of live code Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-13 21:53 --- (In reply to comment #6) Fixing alias analysis in 4.2.0 will make this problem go away but it does not change the underlying issue in the stack local sharing code. Is that really true? The underlying issue is sinking the store is causing the variables to in the same scope. I think that is the real underlying issue and nothing to do with local stack sharing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #7 from echristo at apple dot com 2007-06-13 22:16 --- Um. Right. :) The new version is fine if it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug rtl-optimization/32328] 4.2.0: -O2 causes skipped code
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-13 22:21 --- Do you mean the last two stores to b: b-time = time; b-progress = found ? 4 : 2; Though we could have an alias violation if you don't cast back in hashitem to the correct type of the argument. This is still a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization Keywords||alias, wrong-code Known to fail||4.2.0 4.3.0 Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code
--- Comment #3 from tdragon at tdragon dot net 2007-06-13 22:27 --- (In reply to comment #2) Do you mean the last two stores to b: b-time = time; b-progress = found ? 4 : 2; Yes, those two lines are the ones that are wrongly skipped. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug c++/31903] [4.3 Regression] typeinfo of classes in anon namespace isn't being marked static
--- Comment #10 from geoffk at gcc dot gnu dot org 2007-06-13 22:31 --- I think this problem is limited to just typeinfo. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-12 14:30:49 |2007-06-13 22:31:14 date|| Summary|[4.3 Regression] unwanted |[4.3 Regression] typeinfo of |anonymous namespacing |classes in anon namespace |linkage |isn't being marked static http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code
--- Comment #4 from tdragon at tdragon dot net 2007-06-13 22:36 --- (In reply to comment #2) Though we could have an alias violation if you don't cast back in hashitem to the correct type of the argument. hashitem() uses the type as punned to HASHDATA* (where HASHDATA is a struct with a single member of type char*). However, by implementation hashitem() will never assign a new address that doesn't point to the same type as what was passed -- in this case, it will only ever assign another BINDING*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code
--- Comment #5 from tdragon at tdragon dot net 2007-06-13 22:47 --- Is it possible that an optimization enabled by -O2 *assumes* that hashitem() will conform with strict aliasing by not dereferencing that argument, and thus optimizes those lines away? (Not the case.) If this is what is happening and is the correct behavior, then this is in fact user error and I'm sorry to have wasted your time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #15 from rob1weld at aol dot com 2007-06-13 23:39 --- Can you provide a working patch? Soon. I am trying to fix the math inaccurcy in GCC 4.3.0 and merge a a new math library. You can try sticking that oneliner into your configure if your in a rush. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug c/32329] New: Use of option -fwhole-program needs to exclude option -c in spec file
The bug report is about the use of the option -fwhole-program.
When I compiled a program (crlibm-0.18beta1.tar.gz , described in bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180 ) I found that GCC 4.2.0 with
option -O2 produced code that was _slightly_ faster than GCC 4.3.0 with
option -O3 (on this _one_ particular program).
I set out to make GCC 4.3.0 produce better results and read the info file for
gcc. I added a huge list of options intending to whittle them down a few at a
time. I did eventually get a huge speedup, but this bug report is not about
benchmarking.
This is about the option -fwhole-program. I had it on the huge list and it
caused problems. The docs for -fwhole-program say this:
`-fwhole-program'
Assume that the current compilation unit represents whole program
being compiled. All public functions and variables with the
exception of `main' and those merged by attribute
`externally_visible' become static functions and in a affect gets
more aggressively optimized by interprocedural optimizers. While
this option is equivalent to proper use of `static' keyword for
programs consisting of single file, in combination with option
`--combine' this flag can be used to compile most of smaller scale
C programs since the functions and variables become local for the
whole combined compilation unit, not for the single source file
itself.
Problem:
Using -fwhole-program to compile C files that are then archived into a
library produces a library without any functions to call.
/usr/test/bin/gcc -O0 -std=c89 -g -fgcse-sm -fgcse-las -fgcse-after-reload
-fsee -ftree-loop-linear -ftree-loop-im -fivopts -ftree-vectorize -ftracer
-fvariable-expansion-in-unroller -fweb -fwhole-program -ffast-math
-finline-limit=2400 -fmodulo-sched -Winline -march=athlon-xp -fgnu89-inline
-finline-functions-o crlibm_testval test_val.o test_common.o
../libcrlibm.a -lmpfr -lmpfr -lgmp -lgmp -lm
test_val.o: In function `main':
/root/downloads/crlibm/tests/test_val.c:114: undefined reference to
`crlibm_init'
test_common.o: In function `rand_for_pow_perf':
/root/downloads/crlibm/tests/test_common.c:326: undefined reference to `log_rn'
/root/downloads/crlibm/tests/test_common.c:327: undefined reference to `log_rn'
test_common.o: In function `test_init':
/root/downloads/crlibm/tests/test_common.c:604: undefined reference to `exp_ru'
/root/downloads/crlibm/tests/test_common.c:606: undefined reference to `exp_rd'
...
Would we need to specify every single file in the library PLUS the final file
we would link to the library to produce an executable using -fwhole-program ?
Another way of saying that is _IF_ you use -fwhole-program you can not use
the -c option since you must link everything.
Example:
Yes:
gcc -fwhole-program file_1.c file_2.c file_3.c file_4.c -o result
No:
gcc -fwhole-program -c file_1.c file_2.c
gcc -fwhole-program -c file_3.c file_4.c
ar cru library.a file_1.o file_2.o file_3.o file_4.o
gcc -fwhole-program file_5.c -o result -lrary
file_1.c:000: undefined reference to `xyz'
...
If there are circumstances where it can NOT be used it should be documented.
The docs say it can be used on multiple files.
If -fwhole-program and -c can not be used together the spec file should
make the options mutually exclusive.
The -fwhole-program option _could_ be used for libraries if it respected
a tag like extern that meant that the function would be called from outside
the current compilation unit.
A new GNU extension is needed, something like antistatic or declare to
tell the -fwhole-program option to leave the ABI alone and work on everything
else. Here is a puny example:
void usage(){
fprintf (stderr, \nUsage: [-v] file\n);
exit (EXIT_SUCCESS);
}
char* do_something(FILE* f, char* line) {
}
antistatic void ABI_check_program(int x) {
if (x)
usage();
else
do_something(test, 3);
}
If we compiled the above example with the proposed GNU extension and
used -fwhole-program as an option to gcc then the only visible
function would be ABI_check_program(), the rest would disappear.
That would allow -fwhole-program to have more uses (libraries or sections of
programs not intended to interact with each other _except_ through a common
file). It could be used to protect libraries from people looking in the .h
file and going around the ABI to make direct calls (possibly inadvertantly due
to similar spelling).
--
Summary: Use of option -fwhole-program needs to exclude option
-c in spec file
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32329
[Bug c/32329] Use of option -fwhole-program needs to exclude option -c in spec file
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 23:50 --- Read the documentation, use `externally_visible' as the docs say to. There is nothing here really except you did not read the docs at all, even though you quoted them :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32329
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #8 from dougkwan at google dot com 2007-06-14 00:14 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code I thought like you do initially. But then I was told that in gimple everything is promoted to function scope. So dest is not out of scope. -Doug 13 Jun 2007 21:53:15 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-13 21:53 --- Is that really true? The underlying issue is sinking the store is causing the variables to in the same scope. I think that is the real underlying issue and nothing to do with local stack sharing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-14 00:28 --- (In reply to comment #8) Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code I thought like you do initially. But then I was told that in gimple everything is promoted to function scope. So dest is not out of scope. Who said that? We keep around the scopes, how else do we get stack sharing in the first place? Also you cannot turn off stack sharing because that would cause some programs no longer to be useful (LLVM is one, the stack would just blow up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
