[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #19 from irar at il dot ibm dot com 2008-09-22 12:32 --- (In reply to comment #18) Created an attachment (id=16377) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377action=view) [edit] patch Actually this one vectorizes slp-perm-1.c for me on a ppc64 cross. It also passes the x86_64 vect testsuite. I will give it full testing on x86_64, can you test it on ppc? Thanks. It passes the vectorizer testsuite on ppc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #52 from rguenth at gcc dot gnu dot org 2008-09-22 12:40 --- Can we please have 1) -fno-exceptions This flag turns off C++ exception handling support, which is indicated at compile time by __GXX_EXCEPTIONS being undefined. Use of the keywords try, catch, or throw produces an error. As a result, use of most C++ includes will fail. of comment #46 simply by the original suggestion, make the standard library use __try and __catch and change libsupc++/exception_defines.h accordingly? Appearantly the library wants to work without exception support, but this support needs to be implemented in a way not messing with standard C++ keywords. Note the frontend already undefines __EXCEPTIONS for -fno-exceptions: g++ -dD -E t.C | grep EXCE #define __EXCEPTIONS 1 g++ -dD -E t.C -fno-exceptions | grep EXCE The frontend also produces an error if try or catch are used with -fno-exceptions, but the _standard library implementation_ causes this error do disappear(!) Which is what this bug is about really. It seems the library maintainers are not willing to see this problem. Asking for a new C++ frontend feature as an excuse to not fix the library problem is very lame IMHO. So can we please - finally - do something about this? Thank you very much. Richard. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.3 4.3.0 |4.1.3 4.3.0 4.4.0 Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #20 from irar at il dot ibm dot com 2008-09-22 12:41 --- (In reply to comment #18) Created an attachment (id=16377) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377action=view) [edit] patch Actually this one vectorizes slp-perm-1.c for me on a ppc64 cross. It also passes the x86_64 vect testsuite. I will give it full testing on x86_64, can you test it on ppc? Thanks. I am fully testing it now, but I'll be able to update you about the results only tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #53 from rguenth at gcc dot gnu dot org 2008-09-22 12:41 --- CCing C++ FE maintainers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot ||org, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug c++/37615] New: terminate called after throwing and instance of 'XXX' c++ testsuite failures
Ran gcc testsuite and got a lot of c++ testsuite failures like for g++.dg/eh/cond1.C: ... terminate called after throwing an instance of 'int' terminate called recursively ... Compiler details: Target: arm-linux-gnueabi Configured with: /work/psl/eldk-builds/arm-2008-09-10/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/gcc-4.2.2/configure --target=arm-linux-gnueabi --host=i686-host_pc-linux-gnu --prefix=/var/tmp/eldk.tL5647/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi --disable-hosted-libstdcxx --with-headers=/var/tmp/eldk.tL5647/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/arm-linux-gnueabi/include --with-local-prefix=/var/tmp/eldk.tL5647/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/arm-linux-gnueabi --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++,java --enable-shared --enable-c99 --enable-long-long --without-x Thread model: posix gcc version 4.2.2 It's interesting that statically-built binary run OK. Also, according to testresults in http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00570.html , this should work, unless got broken in release version. Known to work on powerpc, toolchain is the same. -- Summary: terminate called after throwing and instance of 'XXX' c++ testsuite failures Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sposelenov at emcraft dot com GCC host triplet: i386-linux GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37615
[Bug fortran/37614] New: Change position of padding for aligned COMMONs
Follow up to PR 37486. see also http://gcc.gnu.org/ml/fortran/2008-09/msg00366.html The following program should print 5 but it prints 0 with default options in gfortran. The problem is that in the program, the common object is padded as 4bytes padding + i + r8 and then in the subroutine, only the first 4 bytes are read and assigned to the local variable i. The program is valid as Named common blocks of the same name shall be of the same size in all scoping units of a program in which they appear, but blank common blocks may be of different sizes. As tests with NAG f95, Portland pgf95 and Pathscale pathf95 show, these compilers use i + 4bytes padding + r8 which allows this program to run correctly without sacrificing the alignment. (ifort, sunf95 and g95 - and gfortran -fno-align-commons work as no padding is added.) There are still used but not standard conform versions which fail (cf. examples in PR 37486) but for those, gfortran has -fno-align-commons. Test program: subroutine one() integer :: i, j common i print *, i ! shall print 5, in gfortran it is 0 ! ! Testing alternative (invalid standard Fortran): ! common i,j ! print *, i,j end subroutine one program test integer :: i real*8 r8 common i, r8 i = 5 r8 = 123457891234d88 call one() end program test If one enables the common i, j and runs the program with several compilers, details about their implementation is revealed: - gfortran and g77 print 0 5 - ifort, sunf95 and g95 print 5 1267487353 (= gfortran -fno-align-commons) - pathscale, pgi, and NAG f95 print 5 0 expected result when PR is fixed -- Summary: Change position of padding for aligned COMMONs Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code 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=37614
[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive
--- Comment #4 from manu at gcc dot gnu dot org 2008-09-22 13:28 --- I don't understand why this is not closed as wontfix. These warnings are coming from the front-end. Unless we do one of the following: a) some CCP and VRP in the FE, or b) move the warnings to the middle-end, this cannot be fixed. And the consensus seems to be that we do not want to do either of them. And from the many problems we see with Wuninitialized, we already know that moving the warnings to the middle-end causes a lot of problems. Also, VRP is only enabled at -O2. And it does not work with sets, only ranges, so the following will still not work: adj = (flag) ? 0 : 2; return MIN(adj, limit); (I am sure that we have already, probably closed, a PR about this). -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
[Bug c++/37615] terminate called after throwing and instance of 'XXX' c++ testsuite failures
--- Comment #1 from sposelenov at emcraft dot com 2008-09-22 13:32 --- Created an attachment (id=16378) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16378action=view) Reduced testcase Build as: arm-linux-gnueabi-g++ -o cond1 cond1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37615
[Bug c/37613] probelm with optmization and local variable stored in an asm register
--- Comment #2 from daniel dot diaz at univ-paris1 dot fr 2008-09-22 14:08 --- Richard Guenther says it is impossible in C... In C maybe but not in GNU C :-) This worked perfectly under older versions (may gcc 3.x.x) and it is a pitty if this feature is lost now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37613
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #54 from paolo dot carlini at oracle dot com 2008-09-22 14:08 --- (In reply to comment #52) It seems the library maintainers are not willing to see this problem. Asking for a new C++ frontend feature as an excuse to not fix the library problem is very lame IMHO. For the record, speaking of myself, see Comments #43 and #45. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-22 14:11 --- Subject: Re: [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519 Attached .i. Dave --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-22 14:11 --- Created an attachment (id=16379) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16379action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #39 from b0ntrict0r at yandex dot ru 2008-09-22 15:12 --- Created an attachment (id=16380) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16380action=view) Updated fixed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #30 from dje at gcc dot gnu dot org 2008-09-22 15:17 --- Subject: Bug 33642 Author: dje Date: Mon Sep 22 15:15:56 2008 New Revision: 140551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140551 Log: PR rtl-optimization/33642 * gcc.c-torture/compile/pr11832.c: Extend XFAIL to powerpc*-*-*. * gcc.c-torture/compile/pr33009.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #5 from tromey at gcc dot gnu dot org 2008-09-22 15:19 --- No, I think we have to record what the user actually wrote. For instance, consider: #include string using namespace std; std::string x1; string x2; If we record the fully qualified name, we can't distinguish these two cases. I would prefer a solution not relying on heuristics in the debugger. (And can we even undo using directives this way correctly? I am not sure.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #6 from jan dot kratochvil at redhat dot com 2008-09-22 15:32 --- Tom, could you elaborate why x1 and x2 should be printed differently? I do not say they should not but I do not see a clear reason for either way. Should we also try to record the source name of this variable? #define OBJECT_VAR(object, var) object ## _ ## var int OBJECT_VAR (window, width); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive
--- Comment #5 from zackw at panix dot com 2008-09-22 15:46 --- I'm not monitoring consensus of developers anymore, but I think we *should* either move these warnings to the middle end or do some CCP/VRP in the front ends. The -Wuninitialized warnings are a lot less trouble than the signed/unsigned warnings, right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
Periodic Account Update
Dear Nrao Email Account User, We wrote to you on 29 july 2008 advising that you change the password on your account in order to prevent any unauthorised account access following the network instruction we previously communicated. All Mailhub systems will undergo regularly scheduled maintenance. Access to your e-mail via the Webmail client will be unavailable for some time during this maintenance period. We are currently upgrading our data base and e-mail account center i.e homepage view. We shall be deleting old [Nrao] email accounts which are no longer active to create more space for new accounts users. we have also investigated a system wide security audit to improve and enhance our current security. In order to continue using our services you are require to update and re-comfirmed your email account details as requested below. To complete your account re-comfirmation,you must reply to this email immediately and enter your account details as requested below. Username : () Password : () Date of Birth : (2/2/48) Future Password : (**)(Option) Failure to do this will immediately render your account deactivated from our database and service will not be interrupted as important messages may as well be lost due to your declining to re-comfirmed to us your account account details. We apologise for the inconvenience that this will cause you during this period, but trusting that we are here to serve you better and providing more technology which revolves around Secured Email. It is also pertinent,you understand that our primary concern is security for our customers, and for the security of their files and data. COMFIRMATION CODE: Nrao /93-1A388-480 Technical Support Team Regards Nrao Support/Maintainance Team TSR.
[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902
--- Comment #8 from sje at cup dot hp dot com 2008-09-22 16:35 --- I'll try to review the IA64 sel-sched patch over the next couple of weeks. I can't approve the workaround since it is not IA64 specific (it is in haifa-sched.c). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive
--- Comment #6 from manu at gcc dot gnu dot org 2008-09-22 16:43 --- Then, try to raise the issue in GCC and outline a clear plan. Otherwise, I assure you this is going to stay as-is for the next 5-10 years because nobody has a clear idea on how to tackle this in a way that pleases a majority. Also, because it has an easy workaround: use a casting to unsigned. Some starting points: * Moving the warning to the middle-end is not going to avoid warning in this testcase unless VRP is enabled. For -O0 and -O1, we will keep warning. * Moving the warning to the middle-end means that we will warn/not warn depending on the ordering of passes, missed optimisations, etc. * Clang people claim that they can do a simple CCP pass very efficiently in the FE. Perhaps we could do the same. However, we are currently moving optimizations (such as folding) to later stages. In any case, VRP in the front-end is what would be needed for this testcase. Is that even possible? Can be done efficiently? The same issues apply to many warnings: -Wconversion, -Wuninitialized, -Wtype-limits. As Richard said: This is the usual trade-off of doing warnings from the frontends versus from the middle-end. One gives consistency and speed but frequent false positives, and the other gives more precision at the cost of consistent results and more compilation time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
[Bug fortran/36592] F2003: Procedure pointer in COMMON
--- Comment #1 from janus at gcc dot gnu dot org 2008-09-22 16:50 --- Created an attachment (id=16381) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16381action=view) patch The attached patch is as far as I got with this up to now. It regtests fine and makes the following modified version of the test case in comment #0 compile (I think in the original test case there was a p missing in the first common block): subroutine one() implicit none integer :: a,b procedure(real), pointer :: p common /com/ a,p,b print *,a,b,p(0.0) end subroutine one program main implicit none integer :: x,y intrinsic cos procedure(real), pointer :: func1 common /com/ x,func1,y x = 5 y = -9 func1 = cos call one() end program main Although this test case compiles without error, it gives the wrong output: 5 -9 NaN -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36592
[Bug debug/37616] New: Lines with 'break', 'goto', and 'continue' are not available for debugging.
Lines with 'break', 'goto', and 'continue' are not available for
debugging.
On GCC compilers, one can not set a breakpoint on lines with 'goto', 'break',
or
'continue' statements. This is incorrect, since these lines contain
user statements. Also, for example IBM XLC compilers on AIX 6.1 have
these lines available for setting breakpoints when debugging.
This fails both when using gdb and TotalView debugger.
The root problem seems to be that the GCC DWARF explicitly tells the
debugger to skip the lines in question.
uname -a
Linux rhel52-x8664.totalviewtech.com 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15
EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
cat /etc/*-rel*
cat: /etc/lsb-release.d: Is a directory
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
rpm -q glibc
glibc-2.5-24
glibc-2.5-24
g++ -g -O0 -v -o a_g_gcc.out e24018.cxx
gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
totalview ./a_g_gcc.out
= looking at the source code pane, we see that lines #12 (continue),
#14 (goto), and #16 (break) are not available for setting breakpoints.
How to reproduce using gdb:
gdb a_g_gcc.out
GNU gdb Red Hat Linux (6.5-37.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu...Using host libthread_db
library /lib64/libthread_db.so.1.
(gdb) break 12
Breakpoint 1 at 0x40071b: file e24018.cxx, line 12.
(gdb) run
Starting program: /nfs/netapp0/user/home/seppo/Bugs/Bug_11496/a_g_gcc.out
Breakpoint 1, main () at e24018.cxx:13
13 if (jj == 7)
(gdb) list
8
9 for (jj = 0; jj 10; jj++)
10{
11 if (jj == 5)
12continue;
13 if (jj == 7)
14goto exit;
15 if (jj == 9)
16break;
17 mm = jj;
(gdb) print jj
$1 = 0
(gdb) cont
Continuing.
Breakpoint 1, main () at e24018.cxx:13
13 if (jj == 7)
(gdb) print jj
$2 = 1
(gdb)
= notice how the debugger stopped at line #13, although the breakpoint
was set at line #12. Also the stopping happened at the wrong point in
execution, since jj=0 (and not jj=5, as the user wanted).
XXX Analysis:
readelf -wl ./a_g_gcc.out ! readelf_gcc.txt
...
Set File Name to entry 1 in the File Name Table
Advance Line by -71 to 5
Special opcode 173: advance Address by 12 to 0x400704 and Line by 0 to 5
Special opcode 121: advance Address by 8 to 0x40070c and Line by 4 to 9
Special opcode 133: advance Address by 9 to 0x400715 and Line by 2 to 11
Special opcode 91: advance Address by 6 to 0x40071b and Line by 2 to 13
Special opcode 91: advance Address by 6 to 0x400721 and Line by 2 to 15
Special opcode 91: advance Address by 6 to 0x400727 and Line by 2 to 17
Advance Line by -8 to 9
= notice how lines #12, 14, and #16 are skipped in DWARF
X reproducer
#include iostream
using namespace std;
int main()
{
int jj, mm;
for (jj = 0; jj 10; jj++)
{
if (jj == 5)
continue;
if (jj == 7)
goto exit;
if (jj == 9)
break;
mm = jj;
}
exit:
printf(About to exit\n);
return(0);
}
XX
--
Summary: Lines with 'break', 'goto', and 'continue' are not
available for debugging.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: seppo at totalviewtech dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37616
[Bug libstdc++/32422] Problem reading floats with exponent marker but no exponent
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-22 17:25 --- I'm fixing this, together with DR 23. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug libstdc++/37391] examples not accessible online (non existing URLs)
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-09-22 19:06 --- All the test and example links in pb_ds that point to source files are broken. These include links linked to from these pages: libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html These links are fine when browsed in the source tree, but the on-line version does not include the sources that these links point to, so thus the broken links. The way to fix this would be to include the example files inline in the documentation, or link to cvsweb or other web versions of the pages. -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-22 19:06:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37391
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite, SCCVN union optimization disabled
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-22 19:17 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite, SCCVN union optimization disabled
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-22 19:17 --- Subject: Bug 37145 Author: rguenth Date: Mon Sep 22 19:15:43 2008 New Revision: 140562 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140562 Log: 2008-09-22 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/37145 * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Re-enable value-numbering union accesses with their offset and size only. (visit_reference_op_load): Fix simplification of inserted conversions. * tree-ssa-pre.c (find_or_generate_expression): Do not recursively generate expressions if running FRE. * gcc.c-torture/compile/20080922-1.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-7.c: Remove XFAIL. * gcc.dg/tree-ssa/ssa-fre-8.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-9.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20080922-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-8.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-9.c trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug tree-optimization/37537] mfcr is produced when a branch should be done
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37537
[Bug debug/37616] Lines with 'break', 'goto', and 'continue' are not available for debugging.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-22 19:39 --- Related to PR 29609. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37616
[Bug debug/37616] Lines with 'break', 'goto', and 'continue' are not available for debugging.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-22 19:44 --- Also related to PR 36690. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37616
[Bug bootstrap/37612] libgcc/configure (as script)fail with line 77 exec : : not found.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |bootstrap GCC host triplet|Cygwin 686 (amigaos 68k)|Cygwin 686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37612
[Bug target/37593] -mlong-calls doesn't affect calls to _mcount generated with -pg
--- Comment #3 from daney at gcc dot gnu dot org 2008-09-22 19:49 --- Subject: Bug 37593 Author: daney Date: Mon Sep 22 19:48:09 2008 New Revision: 140563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140563 Log: 2008-09-22 David Daney [EMAIL PROTECTED] PR target/37593 * config/mips/mips.h (FUNCTION_PROFILER): Call _mcount via a register if TARGET_LONG_CALLS. 2008-09-22 David Daney [EMAIL PROTECTED] PR target/37593 * gcc.target/mips/long-calls-pg.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/long-calls-pg.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37593
[Bug target/37593] -mlong-calls doesn't affect calls to _mcount generated with -pg
--- Comment #4 from daney at gcc dot gnu dot org 2008-09-22 19:52 --- Fix committed. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37593
[Bug c/37609] Pointer arithmetic yields strange result
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-22 19:54 --- This is invalid code as the difference between ((EDIDDetailed *) pExt-checksum) - pDTD is 88 which is not a multiple of 18. This happens the same way on powerpc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Component|target |c Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug c++/37582] [4.3 Regression] std::pow strange overload resolution
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-22 19:55 --- Is part of GNU C++98 now? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug middle-end/37601] [4.4 Regression] gcc-4.4-20080919 ada build failure
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-22 19:57 --- Can you try this again? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|ada |middle-end Summary|gcc-4.4-20080919 ada build |[4.4 Regression] gcc-4.4- |failure |20080919 ada build failure Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )
--- Comment #16 from daney at gcc dot gnu dot org 2008-09-22 20:08 --- This is biting me now. Perhaps I may look at fixing it (or maybe not...). -- daney at gcc dot gnu dot org changed: What|Removed |Added CC||daney at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug rtl-optimization/37617] New: gcc 4.4 regression: ICE on valid code
I get an ICE using SVN version 140562: ~/gcc_inst/bin/gcc testcase-min.i -O1 testcase-min.i: In function test_token_dval: testcase-min.i:19: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This does not happen with my previous build of gcc 4.4 SVN r140456: $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O1 test.i -c $ $ ~/gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c --disable-multilib --disable-bootstrap --disable-static --prefix=/home/edwin/gcc_inst/ Thread model: posix gcc version 4.4.0 20080922 (experimental) (GCC) $ x86_64-unknown-linux-gnu-gcc-4.4.0 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c --disable-multilib Thread model: posix gcc version 4.4.0 20080918 (experimental) (GCC) -- Summary: gcc 4.4 regression: ICE on valid code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com 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=37617
[Bug rtl-optimization/37617] gcc 4.4 regression: ICE on valid code
--- Comment #1 from edwintorok at gmail dot com 2008-09-22 20:18 ---
/* testcase compile this with -O1 */
typedef struct TCase TCase;
typedef void (*TFun) (int);
typedef struct Suite Suite;
void _tcase_add_test (TCase * tc, TFun tf, const char *fname, int signal,
int start, int end);
void _fail_unless (int result, const char *file, int line, const char *expr,
...);
enum val_type
{
vtype_undefined, vtype_cstring, vtype_string, vtype_scope, vtype_dval,
vtype_ival
};
typedef struct token
{
union
{
char *string;
double dval;
}
val;
enum val_type vtype;
}
yystype;
static int
vtype_compatible (enum val_type orig, enum val_type req)
{
}
static void
test_token_dval (int _i __attribute__ ((unused)))
{
{
int val = 0.12345;
yystype tok;
do
{
(tok)-val.dval = (val);
}
while (0);
_fail_unless ((vtype_compatible ((tok)-vtype, vtype_string) ? (tok)-
val.string : ((void *) 0)) == ((void *) 0),
../../../trunk/unit_tests/check_jsnorm.c, 150,
Assertion ' TOKEN_GET(tok, string) == NULL ' failed,
token dval-string, ((void *) 0));
}
}
Suite *
test_jsnorm_suite (void)
{
TCase *tc_jsnorm_gperf, *tc_jsnorm_token, *tc_jsnorm_api,
*tc_jsnorm_tokenizer, *tc_jsnorm_bugs, *tc_screnc_infloop;
_tcase_add_test ((tc_jsnorm_token), (test_token_dval),
test_token_dval , (0), 0, 1);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug fortran/36592] F2003: Procedure pointer in COMMON
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-22 20:22 ---
(In reply to comment #1)
Created an attachment (id=16381)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16381action=view) [edit]
Although this test case compiles without error, it gives the wrong output:
If you had used -fdump-tree-original, you knew that you created a simple local
procedure pointer, which is not in common and thus a NaN or a crash or ...
makes sense. Not surprisingly the culprit is the if (proc_pointer) {one line}
else { lots of lines } in trans-common.c.
How about the following patch?
$ svn revert trans-common.c
$ patch EOF
--- trans-types.c (Revision 140559)
+++ trans-types.c (Arbeitskopie)
@@ -1629,0 +1630,9 @@ gfc_sym_type (gfc_symbol * sym)
+ if (sym-attr.proc_pointer)
+{
+ /* Unset proc_pointer as gfc_get_function_type calls gfc_sym_type. */
+ sym-attr.proc_pointer = 0;
+ type = build_pointer_type (gfc_get_function_type (sym));
+ sym-attr.proc_pointer = 1;
+ return type;
+}
+
EOF
PS: You should reorder the items in COMMON as on x86-64 the pointers are
8-bytes wide, which causes a alignment/padding warning be printed.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-09-22 20:22:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36592
[Bug rtl-optimization/37617] [4.4 Regression] ICE on valid code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|gcc 4.4 regression: ICE on |[4.4 Regression] ICE on |valid code |valid code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug c/37609] Pointer arithmetic yields strange result
--- Comment #5 from john dot spelis at 3dlabs dot com 2008-09-22 20:40 --- Subject: Re: Pointer arithmetic yields strange result Apologies; never realised that pointer arithmetic was defined in that fashion (i.e. must always be a multiple of the object size). Sorry to have bothered you. Best Regards. On 22 Sep 2008, pinskia at gcc dot gnu dot org wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-22 19:54 --- This is invalid code as the difference between ((EDIDDetailed *) pExt-checksum) - pDTD is 88 which is not a multiple of 18. This happens the same way on powerpc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Component|target |c Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug libstdc++/37391] examples not accessible online (non existing URLs)
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-09-22 20:56 --- Should be fixed now. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37391
[Bug libstdc++/37391] examples not accessible online (non existing URLs)
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-09-22 20:57 --- Subject: Bug 37391 Author: bkoz Date: Mon Sep 22 20:56:08 2008 New Revision: 140564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140564 Log: 2008-09-22 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/37391 * doc/html/ext/pb_ds/*.html: Fix external links. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html trunk/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html trunk/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html trunk/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html trunk/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html trunk/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/container_base.html trunk/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html trunk/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html trunk/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html trunk/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html trunk/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html trunk/libstdc++-v3/doc/html/ext/pb_ds/join_error.html trunk/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html trunk/libstdc++-v3/doc/html/ext/pb_ds/list_update.html trunk/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/motivation.html trunk/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html trunk/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-22 21:00 --- This worked with: gcc version 4.4.0 20080917 (experimental) [trunk revision 140434] (GCC) But fails with: GNU C (GCC) version 4.4.0 20080922 (experimental) [trunk revision 140563] (i386-apple-darwin8.11.1) The ICE is in bitmap_insert_into_set_1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Component|rtl-optimization|tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-22 21:09 ---
Reduced even further and will reproduce with both LP32 and LP64 targets (as
long as float is 32bits and double is 64bits):
typedef union
{
char *string;
double dval;
float fval;
} yystype;
char *f(void)
{
yystype tok;
tok.dval = 0;
return (tok.string);
}
char *f1(void)
{
yystype tok;
tok.fval = 0;
return (tok.string);
}
--- CUT ---
This was most likely introduced with the value numbering of unions.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-09-22 21:09:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug c++/37558] [4.4 regression] rev 140120 changes the accessibility of a friend decl.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 Version|lto |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37558
[Bug target/37603] [4.3/4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37603
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #40 from pluto at agmk dot net 2008-09-22 21:54 ---
(In reply to comment #39)
Created an attachment (id=16380)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16380action=view) [edit]
Updated fixed
1). still there is a warning:
../../gcc/cp/error.c: In function 'dump_template_argument_list':
../../gcc/cp/error.c:190: warning: signed and unsigned type in conditional
expression
2). seems to work, but...
#include set
#include string
template typename T, typename S = std::set std::string , int N = 1
struct X
{
virtual ~X() = 0;
};
void f()
{
X float x; // error here.
}
$ g++ d2.cpp -c
d2.cpp: In function #8216;void f()#8217;:
d2.cpp:10: error: cannot declare variable #8216;x#8217; to be of abstract
type #8216;Xfloat#8217;
d2.cpp:5: note: because the following virtual functions are pure within
#8216;Xfloat#8217;:
d2.cpp:6: note: XT, S, N::~X() [with T = float, S =
std::setstd::basic_stringchar , int N = 1]
d2.cpp:6: note could look like 'XT, S, N::~X() [with T = float]'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #8 from janis at gcc dot gnu dot org 2008-09-22 22:12 --- Created an attachment (id=16382) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16382action=view) small C testcase that fails with current trunk This version of the small C testcase fails with current mainline with -O1 -ffast-math and its behavior changed between r134831 and r134933. -- janis at gcc dot gnu dot org changed: What|Removed |Added Attachment #16365|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-22 22:45 --- The one thing I noticed is that fsel is used in the -ffast-math case and it does a subtraction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #13 from hjl at gcc dot gnu dot org 2008-09-22 22:46 --- Subject: Bug 37535 Author: hjl Date: Mon Sep 22 22:44:53 2008 New Revision: 140568 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140568 Log: 2008-09-22 Vladimir Makarov [EMAIL PROTECTED] PR middle-end/37535 * ira-lives.c (mark_reg_live, mark_reg_dead): New functions. (mark_ref_live, mark_ref_dead): Use them. (def_conflicts_with_inputs_p): Remove. (mark_early_clobbers): New function. (process_bb_node_lives): Call preprocess_constraints and mark_early_clobbers. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #10 from janis at gcc dot gnu dot org 2008-09-22 23:08 --- The new testcase passes with -O1 -funsafe-math-optimizations -fno-tree-dominator-opts. The dom1 dump for -O1 -funsafe-math-optimizations twice reports Invalid sum of incoming frequencies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )
--- Comment #17 from daney at gcc dot gnu dot org 2008-09-22 23:56 --- For me the testcase always gets a ConcurrentModificationException in w.clear() very soon after starting. This is on GCC trunk 140563 on x86_64-pc-linux-gnu. If I synchronize(w) for accesses to w there is no ConcurrentModificationException, but I have not seen it crash yet either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug libstdc++/32422] Problem reading floats with exponent marker but no exponent
--- Comment #4 from paolo at gcc dot gnu dot org 2008-09-23 00:47 --- Subject: Bug 32422 Author: paolo Date: Tue Sep 23 00:47:02 2008 New Revision: 140574 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140574 Log: 2008-09-23 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/32422, DR 23 [Ready in R60] * config/locale/gnu/c_locale.cc (__convert_to_v(const char*, float, ios_base::iostate, const __c_locale), __convert_to_v(const char*, double, ios_base::iostate, const __c_locale), __convert_to_v(const char*, long double, ios_base::iostate, const __c_locale)): Implement DR 23 and deal correctly with broken exponents. * config/locale/generic/c_locale.cc (__convert_to_v(const char*, float, ios_base::iostate, const __c_locale), __convert_to_v(const char*, double, ios_base::iostate, const __c_locale), __convert_to_v(const char*, long double, ios_base::iostate, const __c_locale)): Likewise. * include/bits/locale_facets.tcc (num_get::_M_extract_int(_InIter, _InIter, ios_base, ios_base::iostate, _ValueT)): Likewise. (num_get::_M_extract_float(_InIter, _InIter, ios_base, ios_base::iostate, string): Change grouping check to set instead of OR failbit; do not check for eofbit here... (num_get::do_get(iter_type, iter_type, ios_base, ios_base::iostate, float), num_get::do_get(iter_type, iter_type, ios_base, ios_base::iostate, double), num_get::do_get(iter_type, iter_type, ios_base, ios_base::iostate, long double), num_get::__do_get(iter_type, iter_type, ios_base, ios_base::iostate, double)): ... do it here instead. (num_get::do_get(iter_type, iter_type, ios_base, ios_base::iostate, bool)): Implement DR 23. (num_get::do_get(iter_type, iter_type, ios_base, ios_base::iostate, void*)): Adjust. * doc/xml/manual/intro.xml: Add and entry for DR 23. * testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/10.cc: Adjust. * testsuite/27_io/basic_istream/extractors_arithmetic/char/10.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/22131.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/10.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/12.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/15.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/16.cc: Likewise. * testsuite/22_locale/num_get/get/char/22131.cc: Likewise. * testsuite/22_locale/num_get/get/char/10.cc: Likewise. * testsuite/22_locale/num_get/get/char/12.cc: Likewise. * testsuite/22_locale/num_get/get/char/15.cc: Likewise. * testsuite/22_locale/num_get/get/char/16.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/generic/c_locale.cc trunk/libstdc++-v3/config/locale/gnu/c_locale.cc trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/bits/locale_facets.tcc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/10.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/12.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/15.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/16.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/22131.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/10.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/12.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/15.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/16.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/22131.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/10.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/10.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug libstdc++/32422] Problem reading floats with exponent marker but no exponent
--- Comment #5 from paolo dot carlini at oracle dot com 2008-09-23 00:49 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-09-23 03:53 --- Subject: Bug 37498 Author: jvdelisle Date: Tue Sep 23 03:52:19 2008 New Revision: 140576 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140576 Log: 2008-09-22 Jerry DeLisle [EMAIL PROTECTED] PR fortran/37498 * trans-io.c (gfc_build_io_library_fndecls): Bump pad size. (build_dt): Set mask bit for IOPARM_dt_f2003. * ioparm.def: Add IOPARM_dt_f2003. 2008-09-22 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37498 * file_pos (st_endfile): Clear memory only for libfortran 4.3 private area. * list_read.c (eat_separator): Only access F2003 I/O parameters if IOPARM_DT_HAS_F2003 bit is set. (parse_real): Ditto. (read_real): Ditto. * read.c (read_a): Likewise. (read_a_char4): Likewise though not strictly necessary. (read_f): Likewise. * io.h (unit_sign_s): New enumerator to allow duplication of st_parameter structures. (IOPARM_DT_HAS_F2003): New mask bit. (st_parameter_43): New structure copied from 4.3 version of st_paramater_dt private section. (st_parameter_44): New structure with F2003 items added. (st_parameter_dt): Modified to create union of new and old structures to allow correct memory setting for 4.3 ABI compatibility. Bumped the pad size. * transfer.c (read_sf): Do not use F2003 I/O memory areas unless IOPARM_DT_HAS_F2003 bit has been set. (read_block_form): Ditto. (formatted_transfer_scalar): Ditto. (data_transfer_init): Ditto and add comment, fix formatting. * write.c (write_default_char4): Likewise though not strictly necessary. (write_utf8_char4): Ditto. (write_character): Ditto. (write_real_g0): Ditto. (list_formatted_write_scalar): Ditto. (nml_write_obj): Ditto. (namelist_write): Ditto. * write_float.def (calculate_sign): Eliminate warning by including all cases in switch. (output_float): Output only decimal point of F2003 flag is not set. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/trans-io.c trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c trunk/libgfortran/io/write_float.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug middle-end/37587] ICE when use graphite
--- Comment #1 from linuxl4 at sohu dot com 2008-09-23 05:06 --- can anybody comfirm it? I built gcc ppl polylib cloog mpfr gmp with CFLAGS=-pipe -O3 -ftree-vectorize -march=pentium4 -mfpmath=sse glibc and binutils are of my gentoo 2008.0 hosts' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37587
[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902
--- Comment #7 from abel at gcc dot gnu dot org 2008-09-22 06:20 --- The patch implementing ia64 changes needed for the selective scheduler can be found at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01669.html. [The first version of the patch with some summary is at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00117.html. What is changed from that summary is that per Ian's suggestion we call compute_alignments from machine_reorg manually instead of rearranging the pass sequence.] I was going to ping them, but HJ did that first. It is important that we get that in for 4.4, because otherwise selective scheduler will be non-functional on ia64. However, I presume reviewing the changes will take some time, so it could make sense to fix this bug first. The patch for the bug is simple, and it is not a problem to revert it when committing the rest of sel-sched changes. On the sel-sched branch, I have restored the config/ia64/* files to be in line with mainline before merge. I will revert this on a branch in two-three days, so that the sel-sched branch will contain a fully functional selective scheduler on ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
[Bug c/37611] New: invalid relocation R_386_GOTOFF when using protected function pointers
When I try to use protected function pointers in a shared library, I experience strange behaviour: directly passing a function name triggers an invalid relocation during linking stage while it works when assigning the function name to a global variable first. This report might be a duplicate to the old bug 19520, but I'm not sure as my knowledge about ELF internals is rather limited and I don't understand most of the discussion there, sorry. If this is a duplicate, please excuse. Here's the output during compilation. Sources will follow in a few seconds: $ LANG= gcc -v -save-temps -Wall test2.c -o libtest2.so -shared -fPIC -fvisibility=hidden Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --enable-languages=c,c++ Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'libtest2.so' '-shared' '-fPIC' '-fvisibility=hidden' '-mtune=generic' /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/cc1 -E -quiet -v test2.c -mtune=generic -Wall -fPIC -fvisibility=hidden -fpch-preprocess -o test2.i ignoring nonexistent directory /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'libtest2.so' '-shared' '-fPIC' '-fvisibility=hidden' '-mtune=generic' /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/cc1 -fpreprocessed test2.i -quiet -dumpbase test2.c -mtune=generic -auxbase test2 -Wall -version -fPIC -fvisibility=hidden -o test2.s GNU C (GCC) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 53913b99eaa90e1de01474d5b5d32b19 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'libtest2.so' '-shared' '-fPIC' '-fvisibility=hidden' '-mtune=generic' as -V -Qy -o test2.o test2.s GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.18.0.20080103 COMPILER_PATH=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/:/usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/:/usr/local/libexec/gcc/i686-pc-linux-gnu/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/:/usr/local/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'libtest2.so' '-shared' '-fPIC' '-fvisibility=hidden' '-mtune=generic' /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_i386 -shared -o libtest2.so /usr/lib/crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/crtbeginS.o -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2 -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/../../.. test2.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/crtendS.o /usr/lib/crtn.o /usr/bin/ld: test2.o: relocation R_386_GOTOFF against protected function `f2' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status -- Summary: invalid relocation R_386_GOTOFF when using protected function pointers Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gernot dot hillier at siemens dot com 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=37611
[Bug c/37611] invalid relocation R_386_GOTOFF when using protected function pointers
--- Comment #1 from gernot dot hillier at siemens dot com 2008-09-22 07:19 --- Created an attachment (id=16375) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16375action=view) C file showing the problem See the body of f1 for the two cases. Using f3( f2) triggers the problem while f3 (x) works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37611
[Bug c/37611] invalid relocation R_386_GOTOFF when using protected function pointers
--- Comment #2 from gernot dot hillier at siemens dot com 2008-09-22 07:21 --- Created an attachment (id=16376) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16376action=view) preprocessed version of the code triggering the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37611
[Bug tree-optimization/37482] [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec
--- Comment #4 from irar at gcc dot gnu dot org 2008-09-22 07:57 --- Subject: Bug 37482 Author: irar Date: Mon Sep 22 07:55:39 2008 New Revision: 140544 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140544 Log: PR tree-optimization/37482 * tree-vectorizer.h (struct _slp_instance): Add new field. (SLP_INSTANCE_FIRST_LOAD_STMT): New. (get_earlier_stmt): New function. * tree-vect-analyze.c (vect_find_first_load_in_slp_instance): New function. (vect_analyze_slp_instance): Set SLP_INSTANCE_FIRST_LOAD_STMT. * tree-vect-transform.c (vect_finish_stmt_generation): Remove the asserts that GSI points to the scalar statement being vectorized. Set new statement location according to GSI. (vect_schedule_slp_instance): Use GSI of SLP_INSTANCE_FIRST_LOAD_STMT when vectorizing loads. Added: trunk/gcc/testsuite/gcc.dg/vect/pr37482.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c trunk/gcc/tree-vect-transform.c trunk/gcc/tree-vectorizer.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #38 from pluto at agmk dot net 2008-09-22 09:21 ---
(In reply to comment #37)
Created an attachment (id=16361)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361action=view) [edit]
Updated patch
Could someone test updated patch?
it doesn't build.
../../gcc/cp/error.c: In function 'dump_template_argument':
../../gcc/cp/error.c:144: warning: passing argument 2 of
'dump_template_argument_list' makes pointer from integer without a cast
../../gcc/cp/error.c:144: error: too few arguments to function
'dump_template_argument_list'
../../gcc/cp/error.c: In function 'count_non_default_template_args':
../../gcc/cp/error.c:159: error: expected declaration specifiers before ')'
token
../../gcc/cp/error.c:184: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:212: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:258: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:302: error: expected declaration specifiers before '}'
token
../../gcc/cp/error.c:309: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:463: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:478: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:494: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:562: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
../../gcc/cp/error.c:671: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
(...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #14 from irar at il dot ibm dot com 2008-09-22 09:24 --- This patch causes the following failures on ppc: FAIL: gcc.dg/vect/pr35821-altivec.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-perm-1.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-perm-1.c scan-tree-dump-times vect vectorizing stmts using SLP 1 FAIL: gcc.dg/vect/slp-perm-2.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-perm-2.c scan-tree-dump-times vect vectorizing stmts using SLP 1 FAIL: gcc.dg/vect/slp-perm-3.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-perm-3.c scan-tree-dump-times vect vectorizing stmts using SLP 1 FAIL: gcc.dg/vect/slp-perm-5.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-perm-5.c scan-tree-dump-times vect vectorizing stmts using SLP 2 FAIL: gcc.dg/vect/slp-perm-6.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-perm-6.c scan-tree-dump-times vect vectorizing stmts using SLP 2 FAIL: gcc.dg/vect/slp-perm-7.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-perm-7.c scan-tree-dump-times vect vectorizing stmts using SLP 1 For example, for slp-perm-1.c: slp-perm-1.c:23: note: == examining statement: a_7 = *pInput_40; slp-perm-1.c:23: note: get vectype with 4 units of type unsigned int slp-perm-1.c:23: note: vectype: __vector unsigned int ... slp-perm-1.c:23: note: ??? vector type does not alias scalar type ... slp-perm-1.c:23: note: not vectorized: relevant stmt not supported: a_7 = *pInput_40; pInput_40 is unsigned int* (a_7 is unsigned int) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #4 from sherpya at netfarm dot it 2008-09-22 09:51 --- I've also seen crashes in alloca(), at least according to gdb backtrace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug fortran/37486] alignment of data in COMMON blocks
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-12 20:42:06 |2008-09-22 10:00:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-09-22 10:07
---
This is because the original access is through a restricted pointer, so the
check is conservatively correct at this point. We can move it to the
point where the vector pointer is created (but somehow I cannot make a
cross-compiler go past the support check for strided loads - what are the
commandline options required?).
So, can you check the following? A similar change to vectorizable_store
would be needed.
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 140544)
--- tree-vect-transform.c (working copy)
*** vectorizable_load (gimple stmt, gimple_s
*** 6388,6404
return false;
}
- /* If accesses through a pointer to vectype do not alias the original
- memory reference we have a problem. This should never happen. */
- if (get_alias_set (vectype) != get_alias_set (gimple_assign_rhs1 (stmt))
-!alias_set_subset_of (get_alias_set (vectype),
-get_alias_set (gimple_assign_rhs1 (stmt
- {
- if (vect_print_dump_info (REPORT_DETAILS))
- fprintf (vect_dump, ??? vector type does not alias scalar type);
- return false;
- }
-
/* The vector component type needs to be trivially convertible to the
scalar lhs. This should always be the case. */
if (!useless_type_conversion_p (TREE_TYPE (scalar_dest), TREE_TYPE
(vectype)))
--- 6388,6393
*** vectorizable_load (gimple stmt, gimple_s
*** 6662,6667
--- 6651,6663
default:
gcc_unreachable ();
}
+
+ /* If accesses through a pointer to vectype do not alias the original
+memory reference we have a problem. This should never happen. */
+ gcc_assert (get_alias_set (data_ref) != get_alias_set
(gimple_assign_rhs1 (stmt))
+ !alias_set_subset_of (get_alias_set (data_ref),
+ get_alias_set
(gimple_assign_rhs1 (stmt;
+
vec_dest = vect_create_destination_var (scalar_dest, vectype);
new_stmt = gimple_build_assign (vec_dest, data_ref);
new_temp = make_ssa_name (vec_dest, new_stmt);
Note that this _does_ show that we create wrong alias information as the
pointer type vect_create_data_ref_ptr creates is _not_ marked restrict
which makes us emit wrong code (wrong code in the sense that our handling
of restrict pointers is not exactly correct).
So in the end we probably shouldn't open this can of worms and go back
to check the alias compatibility based on the types... I will prepare
a patch for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #16 from irar at il dot ibm dot com 2008-09-22 10:33 --- (In reply to comment #15) This is because the original access is through a restricted pointer, so the check is conservatively correct at this point. We can move it to the point where the vector pointer is created But this way we move the check to the transformation and we don't have a mechanism to stop in the middle of transformation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c/37612] New: libgcc/configure (as script)fail with line 77 exec : : not found.
I get configure error in libgcc/configure.
the new gcc compiler seem build and here, but the script as(attached) does exec
a empty name in line 77 and report exec : : not found.
this happen too when i want compile a program by hand and type
xgcc test.c
where test.c contain this
main()
{
}
so something seem wrong with the files that start as or the linker
here is my config.log and as file
Please help whats going wrong with the build of gcc
--
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by GNU C Runtime Library configure 1.0, which was
generated by GNU Autoconf 2.59. Invocation command line was
$ /w/gcc-4.3.2/libgcc/configure --cache-file=./config.cache --enable-multilib
--with-cross-host=i686-pc-cygwin --with-cpu=68040 --enable-languages=c,c++
--program-transform-name=s,^,amigaos-, --with-target-subdir=amigaos
--build=i686-pc-cygwin --host=amigaos --target=amigaos
--srcdir=/w/gcc-4.3.2/libgcc
## - ##
## Platform. ##
## - ##
hostname = bernd
uname -m = i686
uname -r = 1.5.25(0.156/4/2)
uname -s = CYGWIN_NT-5.1
uname -v = 2008-06-12 19:34
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = i686
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /w/obj_68k_4/gcc
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/X11R6/bin
PATH: /cygdrive/f/Programme/Microsoft DirectX SDK (March
2008)/Utilities/Bin/x86
PATH: /cygdrive/c/Programme/PC Connectivity Solution/
PATH: /cygdrive/c/WINDOWS/system32
PATH: /cygdrive/c/WINDOWS
PATH: /cygdrive/c/WINDOWS/System32/Wbem
PATH: /cygdrive/e/Programme/QuickTime/QTSystem/
PATH: /cygdrive/c/WINDOWS/system32/kktools
PATH: /cygdrive/e/Programme/TortoiseSVN/bin
PATH: /cygdrive/c/PROGRA~1/CVSFOR~1
PATH: /cygdrive/c/WINDOWS
PATH: /cygdrive/c/WINDOWS/COMMAND
PATH: /cygdrive/c/PROGRAMME/GEMEINSAME
PATH: DATEIEN/GIS/TOOLS
PATH: C
PATH: /PROGRAMME/GEMEINSAME DATEIEN/GIS/TOOLS
PATH: /usr/lib/lapack
## --- ##
## Core tests. ##
## --- ##
configure:1190: loading cache ./config.cache
configure:1373: checking for --enable-version-specific-runtime-libs
configure:1388: result: no
configure:1420: checking for a BSD-compatible install
configure:1475: result: /usr/bin/install -c
configure:1491: checking for gawk
configure:1507: found /usr/bin/gawk
configure:1517: result: gawk
configure:1540: checking build system type
configure:1558: result: i686-pc-cygwin
configure:1566: checking host system type
configure:1580: result: m68k-unknown-amigaos
configure:1639: checking for amigaos-ar
configure:1665: result: amigaos-ar
configure:1718: checking for amigaos-lipo
configure:1744: result: amigaos-lipo
configure:1798: checking for amigaos-nm
configure:1824: result: /w/obj_68k_4/./gcc/nm
configure:1877: checking for amigaos-ranlib
configure:1903: result: amigaos-ranlib
configure:1957: checking for amigaos-strip
configure:1983: result: amigaos-strip
configure:2034: checking whether ln -s works
configure:2038: result: yes
configure:2055: checking for amigaos-gcc
configure:2081: result: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/
-B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem
/usr/local/amigaos/include -isystem
/usr/local/amigaos/sys-include
configure:2363: checking for C compiler version
configure:2366: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/
-B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem
/usr/local/amigaos/include -isystem
/usr/local/amigaos/sys-include --version /dev/null 5
xgcc (GCC) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:2369: $? = 0
configure:2371: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/
-B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem
/usr/local/amigaos/include -isystem
/usr/local/amigaos/sys-include -v /dev/null 5
Reading specs from /w/obj_68k_4/./gcc/specs
Target: amigaos
Configured with: /w/gcc-4.3.2/configure --target=amigaos --with-cpu=68040
Thread model: single
gcc version 4.3.2 (GCC)
configure:2374: $? = 0
configure:2376: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/
-B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem
/usr/local/amigaos/include -isystem
/usr/local/amigaos/sys-include -V /dev/null 5
xgcc: '-V' must come at the start of the command line
configure:2379: $? = 1
configure:2398: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/
-B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem
/usr/local/amigaos/include -isystem
/usr/local/amigaos/sys-include -o conftest -O2 -g -g -O2 conftest.c 5
/w/obj_68k_4/./gcc/as: line 77: exec: :
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #17 from rguenther at suse dot de 2008-09-22 11:14 ---
Subject: Re: [4.4 Regression] Revision 140257 causes
vectorizer tests failures
On Mon, 22 Sep 2008, irar at il dot ibm dot com wrote:
--- Comment #16 from irar at il dot ibm dot com 2008-09-22 10:33 ---
(In reply to comment #15)
This is because the original access is through a restricted pointer, so the
check is conservatively correct at this point. We can move it to the
point where the vector pointer is created
But this way we move the check to the transformation and we don't have a
mechanism to stop in the middle of transformation.
Right, but if we correctly base the vectorized access on the scalar
one we never should fail this test (so I made it an assert - though
logically inverted :().
WRT vect_create_data_ref_ptr not only we have to build a correctly
restrict qualified type but also the decl (vect_get_new_vect_var)
needs to have its DECL_POINTER_ALIAS_SET set correctly.
So, like the following (which seems to work on x86_64, but it looks
like all the testcases with restricted pointers are not supported on
x86_64).
Index: gcc/tree-vect-transform.c
===
*** gcc/tree-vect-transform.c (revision 140544)
--- gcc/tree-vect-transform.c (working copy)
*** vect_create_data_ref_ptr (gimple stmt, s
*** 1077,1084
--- 1077,1095
else
vect_ptr_type = build_pointer_type (vectype);
+ if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME
+TYPE_RESTRICT (TREE_TYPE (DR_BASE_ADDRESS (dr
+ vect_ptr_type = build_qualified_type (vect_ptr_type, TYPE_QUAL_RESTRICT);
vect_ptr = vect_get_new_vect_var (vect_ptr_type, vect_pointer_var,
get_name (base_name));
+ if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME
+TYPE_RESTRICT (TREE_TYPE (DR_BASE_ADDRESS (dr
+ {
+ get_alias_set (base_name);
+ DECL_POINTER_ALIAS_SET (vect_ptr)
+ = DECL_POINTER_ALIAS_SET (SSA_NAME_VAR (DR_BASE_ADDRESS (dr)));
+ }
+
add_referenced_var (vect_ptr);
/** (2) Add aliasing information to the new vector-pointer:
*** vectorizable_load (gimple stmt, gimple_s
*** 6388,6404
return false;
}
- /* If accesses through a pointer to vectype do not alias the original
- memory reference we have a problem. This should never happen. */
- if (get_alias_set (vectype) != get_alias_set (gimple_assign_rhs1 (stmt))
-!alias_set_subset_of (get_alias_set (vectype),
-get_alias_set (gimple_assign_rhs1 (stmt
- {
- if (vect_print_dump_info (REPORT_DETAILS))
- fprintf (vect_dump, ??? vector type does not alias scalar type);
- return false;
- }
-
/* The vector component type needs to be trivially convertible to the
scalar lhs. This should always be the case. */
if (!useless_type_conversion_p (TREE_TYPE (scalar_dest), TREE_TYPE
(vectype)))
--- 6399,6404
*** vectorizable_load (gimple stmt, gimple_s
*** 6662,6667
--- 6662,6672
default:
gcc_unreachable ();
}
+ /* If accesses through a pointer to vectype do not alias the original
+memory reference we have a problem. This should never happen. */
+ gcc_assert (get_alias_set (data_ref) == get_alias_set
(gimple_assign_rhs1 (stmt))
+ || alias_set_subset_of (get_alias_set (data_ref),
+ get_alias_set (gimple_assign_rhs1
(stmt;
vec_dest = vect_create_destination_var (scalar_dest, vectype);
new_stmt = gimple_build_assign (vec_dest, data_ref);
new_temp = make_ssa_name (vec_dest, new_stmt);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c/37612] libgcc/configure (as script)fail with line 77 exec : : not found.
--- Comment #1 from brian at dessent dot net 2008-09-22 11:15 --- Subject: Re: New: libgcc/configure (as script)fail with line 77 exec : : not found. The error means you don't have a cross-assembler installed correctly prior to configuring gcc. gcc is just a compiler, you need the assembler and linker from elsewhere (normally binutils.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37612
[Bug c/37613] New: probelm with optmization and local variable stored in an asm register
in this simple function
bug.c:
void restore() {
register long reg_ebx asm (ebx);
reg_ebx = saved_ebx;
}
$ gcc -v
Utilisation des specs internes.
Target: i386-redhat-linux
Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=i386-redhat-linux
Modèle de thread: posix
gcc version 4.3.2 20080905 (Red Hat 4.3.2-3) (GCC)
$ uname -a
Linux lima.univ-paris1.fr 2.6.24-0.83.rc5.fc9 #1 SMP Tue Dec 11 12:04:08 EST
2007 i686 i686 i386 GNU/Linux
$ gcc -O -S -ffixed-ebx -fomit-frame-pointer bug.c
$ cat bug.c
restore:
rep
ret
.size restore, .-restore
.comm saved_ebx,4,4
the function is empty: the assignment to reg_ebx has been discarded (because
considered as a local variable). In the presence of asm it should be kept.
It is OK if -O is not given.
Maybe there is a way do it differently (btw I cannot declare the var as global
nor static in my application).
--
Summary: probelm with optmization and local variable stored in an
asm register
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daniel dot diaz at univ-paris1 dot fr
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=37613
[Bug c/37613] probelm with optmization and local variable stored in an asm register
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-22 11:27 --- reg_ebx is obviously unused in your function so the assignment is DCEd. I guess what you try to do is not really possible with C. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37613
[Bug fortran/37486] alignment of data in COMMON blocks
--- Comment #9 from janus at gcc dot gnu dot org 2008-09-22 11:46 --- Subject: Bug 37486 Author: janus Date: Mon Sep 22 11:45:02 2008 New Revision: 140546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140546 Log: 2008-09-22 Janus Weil [EMAIL PROTECTED] PR fortran/37486 * gfortran.h (gfc_option_t): New members flag_align_commons and warn_align_commons. * lang.opt: New options falign-commons and Walign-commons. * invoke.texi: Documentation for new options. * options.c (gfc_init_options): Initialize new options. (gfc_handle_options): Handle new options. * trans-common.c (translate_common): Implement new options. (gfc_trans_common): Set correct locus. 2008-09-22 Janus Weil [EMAIL PROTECTED] PR fortran/37486 * gfortran.dg/common_align_1.f90: New. * gfortran.dg/warn_align_commons.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/common_align_1.f90 trunk/gcc/testsuite/gfortran.dg/warn_align_commons.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-22 11:54 --- Technically gcc.dg/tree-ssa/ssa-fre-10.c also fails (or rather it doesn't properly test for what it is supposed to). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-22 11:54 --- Subject: Bug 37145 Author: rguenth Date: Mon Sep 22 11:53:29 2008 New Revision: 140547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140547 Log: 2008-09-22 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/37145 * tree-ssa-pre.c (fully_constant_expression): Simplify builtin calls. (phi_translate_1): Constant fold references. * gcc.dg/tree-ssa/ssa-pre-15.c: Remove XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-15.c trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug fortran/37486] alignment of data in COMMON blocks
--- Comment #10 from janus at gcc dot gnu dot org 2008-09-22 11:50 --- Fixed with r140546. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-09-22 11:48 --- Created an attachment (id=16377) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377action=view) patch Actually this one vectorizes slp-perm-1.c for me on a ppc64 cross. It also passes the x86_64 vect testsuite. I will give it full testing on x86_64, can you test it on ppc? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c++/34624] valid c++ code doesn't compile for x86_64, but for i386
--- Comment #5 from tim at klingt dot org 2008-09-22 12:11 --- i have the same issue with both gcc-4.3 and gcc-4.4 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34624
[Bug tree-optimization/37542] [4.4 Regression] PRE doesn't simplify during phi-translation
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-22 12:20 --- Current PRE simplifies only a subset of previous PRE - see tree-ssa-pre.c:fully_constant_expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite, SCCVN union optimization disabled
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-22 12:22 --- All XFAILs left are due to the SCCVN union value-numbering optimization being disabled: #if FIXME /* If this is a reference to a union member, record the union member size as operand. Do so only if we are doing expression insertion (during FRE), as PRE currently gets confused with this. */ if (may_insert TREE_CODE (DECL_CONTEXT (TREE_OPERAND (ref, 1))) == UNION_TYPE integer_zerop (DECL_FIELD_OFFSET (TREE_OPERAND (ref, 1))) integer_zerop (DECL_FIELD_BIT_OFFSET (TREE_OPERAND (ref, 1 temp.op0 = TYPE_SIZE (TREE_TYPE (TREE_OPERAND (ref, 1))); else #endif if you simply enable it it miscompiles GCC. The testsuites of all languages are clean though. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] XFAILs from|[4.4 Regression] XFAILs from |PRE rewrite |PRE rewrite, SCCVN union ||optimization disabled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
