[Bug middle-end/28749] Miscompilation of glibc/stdio-common/vfprintf.c, invalid delay slot fill.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-15 08:06 --- No testcase in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28749
[Bug fortran/29837] INTERFACE overloading INTENT problem - valid code is rejected
--- Comment #3 from enok at lysator dot liu dot se 2006-11-15 08:06 --- (In reply to comment #2) > The trivial workaround is to assign MAXVAL(X) to an integer. Ok, but my real code is more complex. And I think there must be something wrong. If I put an "INTENT(IN)" variable as X it works. If I put an integer constant it fails: SUBROUTINE T2(X) INTEGER, INTENT(IN) :: X INTEGER Y CALL A(X,Y) ! Works! END SUBROUTINE T2 SUBROUTINE T3() INTEGER Y CALL A(10,Y) ! Fails! END SUBROUTINE T3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29837
[Bug tree-optimization/29753] [4.0/4.1/4.2/4.3 Regression] Volatile semantics ignored in some cases
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-15 08:07 --- Subject: Bug 29753 Author: rguenth Date: Wed Nov 15 08:07:03 2006 New Revision: 118845 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118845 Log: 2006-11-15 Paolo Bonzini <[EMAIL PROTECTED]> PR middle-end/29753 * gimplify.c (fold_indirect_ref_rhs): Use STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29753
[Bug rtl-optimization/29797] [4.1/4.2 Regression] Miscompiles bit test / set in OpenOffice
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-11-15 08:12 --- Subject: Bug 29797 Author: rguenth Date: Wed Nov 15 08:11:59 2006 New Revision: 118846 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118846 Log: 2006-11-15 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2006-11-12 Michael Matz <[EMAIL PROTECTED]> Roger Sayle <[EMAIL PROTECTED]> PR rtl-optimization/29797 * ifcvt.c (noce_try_bitop): Correct calculation of bitnum on BITS_BIG_ENDIAN targets. * gcc.c-torture/execute/pr29797-1.c: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr29797-1.c - copied unchanged from r118740, trunk/gcc/testsuite/gcc.c-torture/execute/pr29797-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/ifcvt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29797
[Bug rtl-optimization/29797] [4.1/4.2 Regression] Miscompiles bit test / set in OpenOffice
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-11-15 08:37 --- Subject: Bug 29797 Author: rguenth Date: Wed Nov 15 08:37:38 2006 New Revision: 118847 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118847 Log: 2006-11-15 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2006-11-12 Michael Matz <[EMAIL PROTECTED]> Roger Sayle <[EMAIL PROTECTED]> PR rtl-optimization/29797 * ifcvt.c (noce_try_bitop): Correct calculation of bitnum on BITS_BIG_ENDIAN targets. * gcc.c-torture/execute/pr29797-1.c: New test case. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr29797-1.c - copied unchanged from r118740, trunk/gcc/testsuite/gcc.c-torture/execute/pr29797-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/ifcvt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29797
[Bug rtl-optimization/29797] [4.1/4.2 Regression] Miscompiles bit test / set in OpenOffice
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-11-15 08:37 --- And 4.2. Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29797
[Bug regression/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-15 08:46 ---
Note the code as given is undefined anyways so it will abort at runtime.
Here is a reduced testcase:
void mar(int n);
void foo()
{
mar(6);
__builtin_trap ();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i586-pc-linux-gnu |i586-*
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2006-11-15 08:46:40
date||
Summary|ICE: on function pointer|[4.2/4.3 regression] ICE
|call. |with scheduling and
||__builtin_trap
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-15 08:47 --- The ICEs I get: With 4.2.0: t.c: In function foo: t.c:6: internal compiler error: in maybe_add_or_update_back_dep_1, at sched-deps.c:245 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. With the trunk: t.c: In function foo: t.c:6: internal compiler error: in check_cfg, at haifa-sched.c:4654 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|regression |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- Comment #3 from samuel dot thibault at ens-lyon dot org 2006-11-15 09:33 --- Mmm, if I have to use another target for avoiding my default target's specific stuff, what is the use of -ffreestanding? Does that mean that we will have to add a linux-kernel target (as opposed to linux-user target) and build a cross-compiler before building a linux kernel? (replace "linux" with whatever kernel you want). And x86_64 Linux just poses the same problem: it emits %fs:0x28 instead of %gs:0x14, but it's just the same issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug tree-optimization/29581] Latent bug in 4.1/4.2/4.3 lambda-code.c
--- Comment #5 from jakub at gcc dot gnu dot org 2006-11-15 09:35 --- Subject: Bug 29581 Author: jakub Date: Wed Nov 15 09:35:34 2006 New Revision: 118848 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118848 Log: PR tree-optimization/29581 * lambda-code.c (replace_uses_equiv_to_x_with_y): Add YINIT, REPLACEMENTS, FIRSTBSI arguments. If initial condition or type is different between Y and USE, create a temporary variable, initialize it at the beginning of the body bb and use it as replacement instead of Y. * gcc.dg/pr29581-1.c: New test. * gcc.dg/pr29581-2.c: New test. * gcc.dg/pr29581-3.c: New test. * gcc.dg/pr29581-4.c: New test. * gfortran.dg/pr29581.f90: New test. Added: trunk/gcc/testsuite/gcc.dg/pr29581-1.c trunk/gcc/testsuite/gcc.dg/pr29581-2.c trunk/gcc/testsuite/gcc.dg/pr29581-3.c trunk/gcc/testsuite/gcc.dg/pr29581-4.c trunk/gcc/testsuite/gfortran.dg/pr29581.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/lambda-code.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29581
[Bug tree-optimization/29581] Latent bug in 4.1/4.2/4.3 lambda-code.c
--- Comment #6 from jakub at gcc dot gnu dot org 2006-11-15 09:37 --- Subject: Bug 29581 Author: jakub Date: Wed Nov 15 09:36:51 2006 New Revision: 118849 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118849 Log: PR tree-optimization/29581 * lambda-code.c (replace_uses_equiv_to_x_with_y): Add YINIT, REPLACEMENTS, FIRSTBSI arguments. If initial condition or type is different between Y and USE, create a temporary variable, initialize it at the beginning of the body bb and use it as replacement instead of Y. * gcc.dg/pr29581-1.c: New test. * gcc.dg/pr29581-2.c: New test. * gcc.dg/pr29581-3.c: New test. * gcc.dg/pr29581-4.c: New test. * gfortran.dg/pr29581.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr29581-1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr29581-2.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr29581-3.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr29581-4.c branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/pr29581.f90 Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/lambda-code.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29581
[Bug tree-optimization/29581] Latent bug in 4.1/4.2/4.3 lambda-code.c
--- Comment #7 from jakub at gcc dot gnu dot org 2006-11-15 09:39 --- Subject: Bug 29581 Author: jakub Date: Wed Nov 15 09:39:18 2006 New Revision: 118850 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118850 Log: PR tree-optimization/29581 * lambda-code.c (replace_uses_equiv_to_x_with_y): Add YINIT, REPLACEMENTS, FIRSTBSI arguments. If initial condition or type is different between Y and USE, create a temporary variable, initialize it at the beginning of the body bb and use it as replacement instead of Y. * gcc.dg/pr29581-1.c: New test. * gcc.dg/pr29581-2.c: New test. * gcc.dg/pr29581-3.c: New test. * gcc.dg/pr29581-4.c: New test. * gfortran.dg/pr29581.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr29581-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr29581-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr29581-3.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr29581-4.c branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pr29581.f90 Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/lambda-code.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29581
[Bug libgomp/28468] OpenMP-parallelized program crashes when OMP_NUM_THREADS > 1
--- Comment #2 from jakub at gcc dot gnu dot org 2006-11-15 09:45 --- Was LinuxThreads built at least --with-tls support or without? If without and libgomp has been built without --disable-tls and your assembler/linker support TLS, libgomp might be using __thread eventhough glibc doesn't support that. There have been some patches added recently to improve gcc configure checks for the runtime support of TLS. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
[Bug tree-optimization/29581] Latent bug in 4.1/4.2/4.3 lambda-code.c
--- Comment #8 from jakub at gcc dot gnu dot org 2006-11-15 09:55 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29581
[Bug fortran/29806] Error if CONTAINS is present without SUBPROGRAM
--- Comment #4 from burnus at gcc dot gnu dot org 2006-11-15 10:02 --- Subject: Bug 29806 Author: burnus Date: Wed Nov 15 10:02:21 2006 New Revision: 118851 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118851 Log: fortran/ 2006-11-15 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/29806 * parse.c (parse_contained): Check for empty contains statement. testsuite/ 2006-11-15 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/29806 * gfortran.dg/contains.f90: New test. * gfortran.dg/derived_function_interface_1.f90: Add a dg-warning. Added: trunk/gcc/testsuite/gfortran.dg/contains.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29806
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
--- Comment #3 from james dot kanze at gmail dot com 2006-11-15 10:05 --- Subject: Re: g++ thinks it is a declaration when it cannot be On 14 Nov 2006 21:33:34 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > I you use > ( Doh ( x ) ), ++ x; > it works. I know. I don't consider it a critical error, but it is legal code, so formally, at least, the compiler should accept it. > (EDG accepts the code unmodified) So does Sun CC and VC++. If I remember correctly, in the past, g++ has had problems with opting too soon for the declaration, before having seen enough of the context to know that it couldn't be. I suspect that this is just a case of the correction having missed a couple of cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
--- Comment #4 from james dot kanze at gmail dot com 2006-11-15 10:10 --- Subject: Re: g++ thinks it is a declaration when it cannot be On 15 Nov 2006 01:59:33 -, bangerth at dealii dot org <[EMAIL PROTECTED]> wrote: > > (Note that in the actual code, Doh was > > boost::mutex::scoped_lock. And I fear that using > > boost::mutex::scoped_lock like this is becoming a widespread > > idiom.) > Ugh, this isn't an easy to read idiom... Not sure I like it myself. It has two advantages: you don't have to invent a name for a variable that you are never going to use, and you don't have to add braces to limit the scope of the lock. Very meager advantages, IMHO: it doesn't bother me to just throw in any short name (e.g. 'l') in such cases, and if the function is large enough to require the extra braces, it's probably too large and complicated anyway. But I'm not the only programmer in the world, and some people seem to actually like it. And... I'll use it too, in quick hacks in throw-away code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- Comment #4 from tschwinge at gnu dot org 2006-11-15 10:11 --- Cced to Jakub Jelinek, who originally implemented this functionality. Could you please comment on this issue? -- tschwinge at gnu dot org changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
--- Comment #9 from burnus at gcc dot gnu dot org 2006-11-15 10:13 --- Subject: Bug 27588 Author: burnus Date: Wed Nov 15 10:13:16 2006 New Revision: 118852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118852 Log: fortran/ 2006-11-15 Tobias Burnus <[EMAIL PROTECTED]> Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/27588 * trans-expr.c (gfc_conv_substring): Add bounds checking. (gfc_conv_variable, gfc_conv_substring_expr): Pass more arguments to gfc_conv_substring. testsuite/ 2006-11-15 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/27588 * gfortran.dg/char_bounds_check_fail_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug fortran/29806] Error if CONTAINS is present without SUBPROGRAM
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-15 10:14 --- Fixed in 4.3 == trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29806
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
--- Comment #10 from burnus at gcc dot gnu dot org 2006-11-15 10:16 --- Fixed in 4.3 == trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- Comment #5 from jakub at gcc dot gnu dot org 2006-11-15 10:23 --- Linux kernel has this support planned: http://lkml.org/lkml/2006/08/16/216 http://lkml.org/lkml/2006/08/16/217 http://lkml.org/lkml/2006/08/16/218 http://lkml.org/lkml/2006/08/16/220 http://lkml.org/lkml/2006/08/16/221 http://lkml.org/lkml/2006/08/16/222 Linux -ffreestanding should stay as is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- Comment #6 from samuel dot thibault at ens-lyon dot org 2006-11-15 10:30 --- So you are saying that gcc now imposes (whatever the kernel) kernel-land and user-land to use the same TLS scheme, and now requires people to build a cross-compiler before building a kernel from another kernel's userland? I thought -ffreestanding was precisely meant to escape such considerations... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- Comment #7 from jakub at gcc dot gnu dot org 2006-11-15 10:37 --- Using %fs:0x28/%gs:0x28 on x86_64-linux resp. %gs:0x14 on i?86-linux is part of the ABI. -ffreestanding is not supposed to change the ABI, so if you don't want to use this ABI, just use a different target (x86_64-elf etc., or don't use -fstack-protector (nobody forces you to use that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- Comment #8 from jakub at gcc dot gnu dot org 2006-11-15 10:41 --- If you use __thread in -ffreestanding it is the same, you don't get emulated TLS either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
--- Comment #9 from samuel dot thibault at ens-lyon dot org 2006-11-15 11:01 --- About not using -fstack-protector, the problem is that it is the default on ubuntu for instance. That would mean we have to explicitely use -fno-stack-protector, but only for recent versions of gcc, so we'll have to detect that, etc... Not counting all such new options that may arise which we'd have to disable... Please answer this, at least by just yes/no: you're saying that -ffreestanding doesn't mean "an OS kernel" (as manual says), but "the kernel of the target", so that people working on other kernels will have to first build a cross-compiler? (the bug is a documentation bug then) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
[Bug libgomp/28468] OpenMP-parallelized program crashes when OMP_NUM_THREADS > 1
--- Comment #3 from bruno at clisp dot org 2006-11-15 13:38 --- > Was LinuxThreads built at least --with-tls support or without? The glibc was built with LinuxThreads without TLS. (I gave --without-tls explicitly to the glibc build.) > If without and libgomp has been built without --disable-tls and your > assembler/linker support TLS, libgomp might be using __thread eventhough > glibc doesn't support that. Yes, this is exactly the problem; see the analysis and patch in http://gcc.gnu.org/ml/gcc/2006-11/msg00244.html > There have been some patches added recently to improve gcc configure checks > for the runtime support of TLS. The only patch that has been committed is this one from Daniel Jacobowitz http://gcc.gnu.org/viewcvs/trunk/config/tls.m4?r1=117049&r2=118777 It has no effect on this bug, since it applies only to the cross-compiling case. For the native compile, I posted a patch that is known to fix this bug: http://gcc.gnu.org/ml/gcc/2006-11/msg00244.html It has been approved by Richard Henderson: http://gcc.gnu.org/ml/gcc/2006-11/msg00255.html But noone has committed it to the GCC SVN. Could someone please commit this patch on the HEAD and possibly on the 4.2 branch? (It is not a regression, if you argue that libgomp and -fopenmp is a new feature. But it is a regression if you argue that there are packages out there, such as GNU gettext 0.16, which use -fopenmp if available, and this bug turns a program that would run unparallelized but correctly with gcc-4.1 into a program that runs parallelized but crashes with gcc-4.2.) -- bruno at clisp dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
[Bug other/29842] New: outstanding patches / issus from STMicroelectronics
-- Summary: outstanding patches / issus from STMicroelectronics Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
[Bug c++/29843] New: g++ 4.1.1 standard conformance issues
-- Summary: g++ 4.1.1 standard conformance issues Product: gcc Version: 4.1.1 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 2316 OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29843
[Bug fortran/27546] [F2003] IMPORT not implemented
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-15 15:46 --- Subject: Bug 27546 Author: burnus Date: Wed Nov 15 15:46:42 2006 New Revision: 118857 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118857 Log: fortran/ 2006-11-15 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/27546 * decl.c (gfc_match_import,variable_decl): Add IMPORT support. (gfc_match_kind_spec): Fix typo in gfc_error. * gfortran.h (gfc_namespace, gfc_statement): Add IMPORT support. * parse.c (decode_statement,gfc_ascii_statement, verify_st_order): Add IMPORT support. * match.h: Add gfc_match_import. * gfortran.texi: Add IMPORT to the supported Fortran 2003 features. testsuite/ 2006-11-15 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/27546 * gfortran.dg/import.f90: New test. * gfortran.dg/import2.f90: New test. * gfortran.dg/import3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/import.f90 trunk/gcc/testsuite/gfortran.dg/import2.f90 trunk/gcc/testsuite/gfortran.dg/import3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/match.h trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
[Bug other/29842] outstanding patches / issues from STMicroelectronics
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-11-15 15:48 --- See: http://gcc.gnu.org/ml/gcc/2006-10/msg00063.html I won't be able to tie up all loose ends till I leave STM, so I'll try to at least tie them together. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||20211 Summary|outstanding patches / issus |outstanding patches / issues |from STMicroelectronics |from STMicroelectronics http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
[Bug target/29166] broken unwind information for many life variables resulting in register corruption
--- Comment #4 from matz at gcc dot gnu dot org 2006-11-15 15:52 --- Created an attachment (id=12623) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12623&action=view) Assembler code This is the assembler produced by gcc 4.1.0, in case someone needs the full asm to determine something non-matching. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
[Bug target/20695] sh64-*-* port deos not handle 32 / 64 bit conversions properly
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-11-15 15:57 --- Fixed with checkin from 2005-05-09 17:44 -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20695
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #13 from amylaar at gcc dot gnu dot org 2006-11-15 16:08 --- This might be fixed now, but somebody should check before this PR is closed. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||29842 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug target/27060] divide libcall size has increased
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-11-15 16:13 --- FIxed with patch from Apr 12 20:09:41 2006 -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27060
[Bug other/27850] gcov-enabled sh-elf compiler fails to build
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-11-15 16:16 --- Fixed with patch from Jun 2 23:50:11 2006 -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27850
[Bug fortran/27546] [F2003] IMPORT not implemented
--- Comment #7 from burnus at gcc dot gnu dot org 2006-11-15 16:22 --- Fixed in 4.3 == trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
[Bug tree-optimization/27394] double -> char conversion varies with optimization level
--- Comment #8 from amylaar at gcc dot gnu dot org 2006-11-15 16:28 --- This is still a quality of implementation issue. Changing the behaviour of the program when the optimization level changes makes debugging harder, and we could easily avoid the change in this instance. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||29842 nThis|| Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394
[Bug fortran/27546] [F2003] IMPORT not implemented
--- Comment #8 from burnus at gcc dot gnu dot org 2006-11-15 16:44 --- Reopened. I should have really read this bugreport and tested the example of comment 0. My test cases worked, but this one does not: internal compiler error: module symbol dp in wrong namespace #4 0x00478002 in gfc_create_module_variable (sym=0x10) at fortran/trans-decl.c:2761 #5 0x004587de in traverse_ns (st=0xda3080, func=0x477f00 ) at fortran/symbol.c:2603 #6 0x004587c6 in traverse_ns (st=0xda25e0, func=0x477f00 ) at fortran/symbol.c:2606 #7 0x004648de in gfc_generate_module_code (ns=0x4) at fortran/trans.c:672 Using only "IMPORT": real (kind=dp) :: x 1 Error: Parameter 'dp' at (1) has not been declared or is a variable, which does not reduce to a constant expression -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
[Bug tree-optimization/29788] [4.1/4.2/4.3 Regression] ICE in var_ann, at tree-flow-inline.h:130
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-15 17:05 --- Subject: Bug 29788 Author: pinskia Date: Wed Nov 15 17:04:56 2006 New Revision: 118861 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118861 Log: 2006-11-15 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/29788 * fold-const.c (fold_indirect_ref_1): Fold *&CONST_DECL down to what is the const decl is a place holder for. 2006-11-15 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/29788 * gfortran.fortran-torture/compile/inline_1.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/inline_1.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
[Bug fortran/27546] [F2003] IMPORT not implemented
--- Comment #9 from burnus at gcc dot gnu dot org 2006-11-15 17:06 ---
For
IMPORT
the error occures in expr.c's check_init_expr
case EXPR_VARIABLE:
if (e->symtree->n.sym->attr.flavor == FL_PARAMETER)
{
t = simplify_parameter_variable (e, 0);
break;
}
gfc_error ("Parameter '%s' at %L has not been declared or is "
It should have actually matched FL_PARAMETER, but for some reasons it has not.
For
IMPORT :: dp
it happens in trans-decl.c's gfc_create_module_variable:
/* Only output symbols from this module. */
if (sym->ns != module_namespace)
{
/* I don't think this should ever happen. */
internal_error ("module symbol %s in wrong namespace", sym->name);
}
I don't see immediately how to fix this. If someone has a good spontaneous idea
... otherwise I try to understand how it should work.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
[Bug tree-optimization/29788] [4.1/4.2 Regression] ICE in var_ann, at tree-flow-inline.h:130
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-11-15 17:06 --- Will test it for 4.2 now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression] ICE|[4.1/4.2 Regression] ICE in |in var_ann, at tree-flow- |var_ann, at tree-flow- |inline.h:130|inline.h:130 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29788
[Bug c++/29843] [meta-bug] C++98 standard conformance issues
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|29046 | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-15 17:17:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29843
[Bug target/29100] use of fmac causes excess precision problems
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-15 17:18 --- Fixed with merge from 2006-11-03. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29100
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-15 17:24 --- (In reply to comment #6) > fold_convert cannot handle casts between aggregates (what would that be > anyway...), but only scalars (including pointers). But it also has an early > out > in case of the types are equal already, so in this case it is "fine" even for > aggregates. So the place the fortran frontend calls fold_convert is somewhat > dubious. > Richard, When the dust settles, I will implement something like it. I am a couple of minutes away from submitting the abovepatch and a testcase. Thanks Paul -- 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|2006-11-13 20:03:19 |2006-11-15 17:24:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #8 from patchapp at dberlin dot org 2006-11-15 17:45 --- Subject: Bug number PR29820 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/2006-11/msg01053.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug c++/29844] New: Lookup of template dependent function fails in namespace
I believe this short C++ code should compile without errors:
class c;
template class tm { public: const T& g() const; };
namespace n {
template int fn(const tm &v) { return fn(v.g()); }
int fn(const c *p);
}
int main() { tm v; return n::fn(v); }
Instead, I get
foo.cc: In function int n::fn(const tm&) [with T = c*]:
foo.cc:7: instantiated from here
foo.cc:4: error: no matching function for call to fn(c* const&)
Here fn is being called recursively with an argument which depends on the
template type, so it should be looked up at template instantiation time, not at
template definition time. So the matching call should be found.
By comparison, this code compiles without error:
class c;
template class tm { public: const T& g() const; };
namespace n {
int fn(const c *p);
template int fn(const tm &v) { return fn(v.g()); }
}
int main() { tm v; return n::fn(v); }
This is not surprising, since the function declaration can now be seen at
template definition time.
However, this code also compiles without error:
class c;
template class tm { public: const T& g() const; };
template int fn(const tm &v) { return fn(v.g()); }
int fn(const c *p);
int main() { tm v; return fn(v); }
Here the declaration is only available at template instantiation time, yet it
works.
So it seems to be me that there may be a bug related to namespaces when
handling lookup of template dependent types. I haven't investigated further.
--
Summary: Lookup of template dependent function fails in namespace
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29844
[Bug target/29845] New: sh floating point emulation is inefficient
shortcomings of fp-bit.c (excessive packing, poor choice of algorithms), poor handling of bitfield accesses by gcc, and problems with register allocation / scheduling each cost about a factor of two in performance in the floating point emulation currently used for the SH port. Using a hand-coded assembly language implementation can avoid these problems. -- Summary: sh floating point emulation is inefficient Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh-* BugsThisDependsOn: 28618 OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug fortran/25087] Error for missing explicit interface needed.
--- Comment #5 from patchapp at dberlin dot org 2006-11-15 18:02 --- Subject: Bug number PR25087 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/2006-11/msg01058.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25087
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-11-15 18:02 --- Created an attachment (id=12624) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12624&action=view) patch This patch has been regression tested on i686-pc-linux-gnu X sh-elf. However, I need approval for the non-SH parts before I can commit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug c++/29844] Lookup of template dependent function fails in namespace
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-15 18:10 ---
I don't think this is a bug.
There are two clauses to the C++ standard about namelookup in templates.
One applies where the definition.
And the other applies to both definition and instaination but only for the
namespace containing the type.
Take the first case:
class c;
template class tm { public: const T& g() const; };
namespace n {
template int fn(const tm &v)
{
return fn(v.g());
// we have one overloading function for fn, the current template fn
// at definition
}
int fn(const c *p);
}
int main()
{
tm v;
return n::fn(v);
// when instationating this function fn, we look again at the overloading
// set for fn but since c is defined in the global namespace, we don't see
// the other fn in namespace n.
}
PR 2922/DR 197 describes this better than I can right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29844
[Bug ada/29802] [4.2/4.3 Regression] wrong directory in makefile for ada and libada when srcdir=.
--- Comment #7 from Jean-pierre dot vial at wanadoo dot fr 2006-11-15 18:13 --- (In reply to comment #6) > Created an attachment (id=12620) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12620&action=view) [edit] > updated patch > > > Right, you need this additional hunk (I didn't include the regenerated > configure, you have to run autoconf within the libada directory). > > Thanks for the quick feedback. > everything works flawlessly just one remark: I had to patch separately in the top directory and in the libada directory: it did not work in a single pass. after patching in both directory and running autoconf ther is no more failure. Thank you very much -- Jean-pierre dot vial at wanadoo dot fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug middle-end/29846] New: impossible to both expand store flag operations and use a cbranch handler
If both a compare operation and a branch exists, these are used in preference to a cbranch handler. If a compare operation, but no branch exists, the cbranch handler is not used. If no compare operation exists, we can't generate compare / setcc sequences. cstore patterns are recognized by genopinit, but cause a compiler crash their presence influences code generation. -- Summary: impossible to both expand store flag operations and use a cbranch handler Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org OtherBugsDependingO 29842,29845 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29846
[Bug ada/29802] [4.2/4.3 Regression] wrong directory in makefile for ada and libada when srcdir=.
--- Comment #8 from bonzini at gnu dot org 2006-11-15 18:14 --- not yet applied :-) -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug ada/29802] [4.2/4.3 Regression] wrong directory in makefile for ada and libada when srcdir=.
--- Comment #9 from bonzini at gnu dot org 2006-11-15 18:15 --- reopened, now reassigned -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-15 18:15:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug fortran/29652] ambiguous interface declaration undetected
--- Comment #2 from patchapp at dberlin dot org 2006-11-15 18:25 --- Subject: Bug number PR29652 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/2006-11/msg01067.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29652
[Bug tree-optimization/29791] [4.3 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776
--- Comment #7 from janis at gcc dot gnu dot org 2006-11-15 18:30 --- A regression hunt using an x86_64 cross compiler with the submitter's testcase with -O2 identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=117986 r117986 | rakdver | 2006-10-24 00:12:16 + (Tue, 24 Oct 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29791
[Bug middle-end/29846] impossible to both expand store flag operations and use a cbranch handler
--- Comment #1 from patchapp at dberlin dot org 2006-11-15 18:30 --- Subject: Bug number PR middle-end/29846 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/2006-11/msg01069.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29846
[Bug fortran/29652] ambiguous interface declaration undetected
-- 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|2006-10-31 05:41:20 |2006-11-15 18:58:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29652
[Bug fortran/25087] Error for missing explicit interface needed.
-- 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|2006-09-28 11:35:17 |2006-11-15 18:59:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25087
[Bug middle-end/29847] New: Can't match differently sized floating point operands for big endian target
reload.c:operands_match_p does not do big endian adjustment for floating point operands. Hence, when you have a pattern that needs such a match, you get an ICE saying that the insn does not match its constraints. -- Summary: Can't match differently sized floating point operands for big endian target Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org OtherBugsDependingO 29842,29845 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29847
[Bug middle-end/29847] Can't match differently sized floating point operands for big endian target
--- Comment #1 from patchapp at dberlin dot org 2006-11-15 19:25 --- Subject: Bug number PR middle-end/29847 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/2006-11/msg01074.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29847
[Bug other/29848] New: gthread primitives make library binaries specific to one single threading implementation
All the existing gthread implementaions cause thread-package specific code to be compiled into all the libries, thus making it impossible to share the same libraries between operating systems with different thread support packages (or lack thereof), but otherwise identical ABI sets. By using non-inline, weak stub functions with functionality like for gthr-single, the actual thread implementation can be linked in separately, either statically or dynamically. The following patch is already in the patch tracker: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00237.html -- Summary: gthread primitives make library binaries specific to one single threading implementation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: patch Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29848
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Comment #33 from amylaar at gcc dot gnu dot org 2006-11-15 20:11 --- 4.x patches: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01184.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug target/29849] New: sh-linux uses inefficient multilib
The default multilib for sh-linux is -m1, even though you can't run linux without virtual memory. There is a patch, but it needs testing: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00613.html -- Summary: sh-linux uses inefficient multilib Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh-linux OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29849
[Bug c/29850] New: .ctor does not work with optimization levels -O2, -O3 and -O4
I am using gcc 3.4.5:
gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.5/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=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
On a Redhat EL Update 2 system using Intel Xeon 3.6 GHz systems. I am trying to
compile and run the following small program test.c:
#include
int test_init_var;
int main(int argc,char **argv){
fprintf(stderr,"test_init_var=%d\n",test_init_var);
return 0;
}
static int __G_DATA_INIT(){
test_init_var=1001;
}
static char *__g_data_init_f=(char *)__G_DATA_INIT;
static void __G_DATA_CTOR() {
asm(".section .ctors");
asm(".long __G_DATA_INIT");
asm(".section .text ");
}
It works correctly without optimization and with a -O flag:
gcc test.c
./a.out
test_init_var=1001
gcc -O test.c
./a.out
test_init_var=1001
However, it produces the wrong output with -O2 and higher:
gcc -O2 test.c
./a.out
test_init_var=0
The temporary files are below:
gcc-save-temps test.c
test.i:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 28 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 319 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 320 "/usr/include/features.h" 2 3 4
# 342 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 343 "/usr/include/features.h" 2 3 4
# 29 "/usr/include/stdio.h" 2 3 4
# 1 "/usr/lib/gcc/x86_64-redhat-linux/3.4.5/include/stddef.h" 1 3 4
# 213 "/usr/lib/gcc/x86_64-redhat-linux/3.4.5/include/stddef.h" 3 4
typedef long unsigned int size_t;
# 35 "/usr/include/stdio.h" 2 3 4
# 1 "/usr/include/bits/types.h" 1 3 4
# 28 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 29 "/usr/include/bits/types.h" 2 3 4
# 1 "/usr/lib/gcc/x86_64-redhat-linux/3.4.5/include/stddef.h" 1 3 4
# 32 "/usr/include/bits/types.h" 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;
typedef long int __quad_t;
typedef unsigned long int __u_quad_t;
# 129 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/typesizes.h" 1 3 4
# 130 "/usr/include/bits/types.h" 2 3 4
__extension__ typedef unsigned long int __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef unsigned long int __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned long int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef long int __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef unsigned long int __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;
__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;
__extension__ typedef int __clockid_t;
__extension__ typedef int __timer_t;
__extension__ typedef long int __blksize_t;
__extension__ typedef long int __blkcnt_t;
__extension__ typedef long int __blkcnt64_t;
__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef unsigned long int __fsblkcnt64_t;
__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef unsigned long int __fsfilcnt64_t;
__extension__ typedef long int __ssize_t;
typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;
__extension__ typedef long int __intptr_t;
__extension__ typedef unsigned int __socklen_t;
# 37 "/usr/include/stdio.h" 2 3 4
typedef struct _IO_FILE FILE;
# 62 "/usr/include/stdio.h" 3 4
typedef struct _IO_FILE __FILE;
# 72 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/libio.h" 1 3 4
# 32 "/usr/include/libio.h" 3 4
# 1 "/usr/include/_G_config.h" 1 3 4
# 14 "/usr/include/_G_config.h" 3 4
# 1 "/usr/lib/gcc/x86_64-redhat-linux/3.4.5/include/stddef.h" 1 3 4
# 325 "/usr/lib/gcc/x86_64-redhat-linux/3.4.5/include/stddef.h" 3 4
typedef int wchar_t;
# 354 "/usr/lib/gcc/x86_64-redhat-linux/3.4.5/include/stddef.h" 3 4
typedef unsigned int wint_t;
# 15 "/usr/include/_G_config.h" 2 3 4
# 24 "/usr/include/_G_config.h" 3 4
# 1 "/usr/include/wchar.h" 1 3 4
# 48 "/u
[Bug preprocessor/29851] New: Need to strip trailing slashes on include pathnames
The stat call on mingw fails when a trailing slash is included in the pathname. Hence, trailing slashes need to be stripped from include directory pathnames, lest gcc thinks these paths do not exist. A patch is here: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00598.html -- Summary: Need to strip trailing slashes on include pathnames Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC host triplet: *mingw* OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29851
[Bug target/29852] New: x86_64: SSE version missing for fmod{d,s,x}f3
The is currently no SSE version in x86_64 for fmod.
fmod{d,s,x}f3 intriniscs are constrainted by:
"TARGET_USE_FANCY_MATH_387
&& (!(TARGET_SSE2 && TARGET_SSE_MATH) || TARGET_MIX_SSE_I387)"
The need for these intriniscs can be seen in the Polyhedron Fortran performance
test "ac". As soon as gfortran started to used fmod the execution time for the
program "ac" almost trippled under x86_64 as libcall to the math library is
done. For the performance, see:
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-ac-3.png
at http://www.suse.de/~gcctest/c++bench/polyhedron/
See mailing list thread which starts with
http://gcc.gnu.org/ml/fortran/2006-11/msg00333.html
the actually interesting thread starts, however, with:
http://gcc.gnu.org/ml/fortran/2006-11/msg00353.html
--
Summary: x86_64: SSE version missing for fmod{d,s,x}f3
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
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=29852
[Bug fortran/27546] [F2003] IMPORT not implemented
--- Comment #10 from burnus at gcc dot gnu dot org 2006-11-15 20:50 ---
For dp (= kind) I really need to find out where to modify this. Somehow this is
not properly recognized as constant expression.
(Tested by using no "import" and commenting the check in variable_decl. This is
essentially what happens with "import".)
* * *
Some more tests:
If one changes the module to a "program" or only puts the "dp" into a module,
but the interface into a "program", "import :: dp" works. ("import" does not.)
If the interface is in a module (same or different one than "dp"), the ICE
occurs.
"Import" does not work at all for kind=...; it works, however, for
"type(mytype)", regardless whether it is in a module or not. "import :: mytype"
does not work in a module.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type
--- Comment #5 from jens dot maurer at gmx dot net 2006-11-15 21:01 --- Oops, you're right. I was looking at N2134, the current working paper (not yet approved as a standard). Indeed, at the October 2005 meeting of WG21, the resolution for core issue 354 was voted for incorporation into the working paper, and that resolution added the sentence I quoted, see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#354 . It's still an ICE, but I admit that ICE-on-valid-code is probably more important than ICE-on-invalid-code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29704
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-11-15 21:05 --- (In reply to comment #7) > Unfortunately, there was one thinko in the approach I took > with reading. Even for subrecords, we need to be > able to spot if we exceed recl. > > Back to the drawing board... Actually, we currently don't check wether we exceed recl on unformatted write or read, and neither ifort or g77 do so: $ cat recl.f program main character*10 a,b open (9, file="foo.dat", form="unformatted", & access="sequential", recl=80) write (9) '1234567890','1234567890' close (9) open (10, file="foo.dat", form="unformatted", & access="sequential",recl=10) read (10) a,b print *,a,b end $ gfortran recl.f && ./a.out 12345678901234567890 $ ifort recl.f && ./a.out 12345678901234567890 $ g77 recl.f && ./a.out 12345678901234567890 If there's a bug to fix, it doesn't concern subrecords, at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug preprocessor/29831] changed include order when symlinking prefix or moving binaries
--- Comment #1 from michael dot haubenwallner at salomon dot at 2006-11-15 21:08 --- And it does happen when configured with pathes containing double slashes, fex .../configure --prefix=/my/prefix//usr --bindir=/my/prefix//usr/bin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29831
[Bug rtl-optimization/29854] New: reload_combine looses track of uses
When reload_combine replaces a register with a sum of
another register ('base') and a constant, it fails to
note the new uses of the base. Thus, when it later
replaces the base, thew new uses won't be updated.
A patch is here:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01387.html
--
Summary: reload_combine looses track of uses
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
OtherBugsDependingO 29842
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29854
[Bug target/29852] x86_64: SSE version missing for fmod{d,s,x}f3
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-15 21:20 --- Confirmed. SSE doesn't have something like 387 fprem though, so this is probably a library problem. (Note that remainder is one of the few extra things to basic arithmetics that IEEE 754 specifies). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-15 21:20:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
[Bug middle-end/29855] New: stale liveness information duplicated
We duplicate useless register lifeness information for pseudo registers, thus wasting compilation time. For patch and discussion see here: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00200.html -- Summary: stale liveness information duplicated Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29855
[Bug c/29850] .ctor does not work with optimization levels -O2, -O3 and -O4
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-15 21:45 ---
static char *__g_data_init_f=(char *)__G_DATA_INIT;
static void __G_DATA_CTOR() {
asm(".section .ctors");
asm(".long __G_DATA_INIT");
asm(".section .text ");
}
Since both __g_data_init_f and __G_DATA_CTOR are unused, they get removed.
Your code is invalid and should be changed to use the attrubute constructor (on
__G_DATA_INIT) instead.
--
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=29850
[Bug ada/29856] New: broken if..else in gcc/ada/adaint.c
Looks like braces are missing here:
--- gcc-4.2-20061031.orig/gcc/ada/adaint.c 2006-02-15 10:30:39.0
+0100
+++ gcc-4.2-20061031/gcc/ada/adaint.c 2006-11-13 11:50:22.0 +0100
@@ -938,8 +938,10 @@ __gnat_readdir (DIR *dirp, char *buffer,
#elif defined (HAVE_READDIR_R)
/* If possible, try to use the thread-safe version. */
if (readdir_r (dirp, buffer) != NULL)
-*len = strlen (((struct dirent*) buffer)->d_name);
-return ((struct dirent*) buffer)->d_name;
+{
+ *len = strlen (((struct dirent*) buffer)->d_name);
+ return ((struct dirent*) buffer)->d_name;
+}
else
return NULL;
--
Summary: broken if..else in gcc/ada/adaint.c
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nikai at nikai dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29856
[Bug ada/29856] broken if..else in gcc/ada/adaint.c
--- Comment #1 from nikai at nikai dot net 2006-11-15 21:56 --- Created an attachment (id=12627) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12627&action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29856
[Bug c/29857] New: ice for legal C code
I just tried to compile Suse Linux 10.1 package goffice-0.2.1-18 with the new GNU C compiler version 4.3 snapshot 2006 on a x86_64 machine. The compiler said go-plugin.c: In function 'plugin_get_loader_if_needed': go-plugin.c:867: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:421 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -O2 required -- Summary: ice for legal C code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29857
[Bug c/29857] ice for legal C code
--- Comment #1 from dcb314 at hotmail dot com 2006-11-15 22:13 --- Created an attachment (id=12628) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12628&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29857
[Bug tree-optimization/29857] ice for legal C code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-15 22:21 --- I think this is a dup of bug 29801. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29801 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29857
[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc
--- Comment #22 from janis at gcc dot gnu dot org 2006-11-15 22:28 --- Ira, I keep running into problems with the regression hunt but I'm making progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug rtl-optimization/29858] New: regmove has been silently disabled
discover_flag_regs has bitrotted when rtl generation was changed to emit entire insns instead of patterns. Hence, any evaulation of the effectiveness of the regmove pass, or of the impact of changes to the regmove pass to generated code, is invalid, since the pass does not run at all. -- Summary: regmove has been silently disabled Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858
[Bug rtl-optimization/29858] regmove has been silently disabled
-- amylaar at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858
[Bug rtl-optimization/29858] regmove has been silently disabled
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-15 22:39 --- Don't change Priorities that is for the RM to do. And note this is discover_flags_reg and not discover_flag_regs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858
[Bug rtl-optimization/29858] regmove has been silently disabled
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-15 22:45 --- Confirmed. -- 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 |2006-11-15 22:45:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858
[Bug other/25028] TImode-to-floating conversions broken
--- Comment #10 from sje at gcc dot gnu dot org 2006-11-15 22:59 --- Subject: Bug 25028 Author: sje Date: Wed Nov 15 22:59:41 2006 New Revision: 118869 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118869 Log: PR other/25028 * config/ia64/t-hpux (LIB1ASMFUNCS): Filter out _fixtfdi, _fixunstfdi, and _floatditf Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/ia64/t-hpux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25028
[Bug c++/29859] New: reference-compatible is defined too narrowly in [decl.int.ref]
This is really a problem that arises *because* g++ implements the standard.
I have tried to raise this as a DR, but to no avail.
Subject:Defect Report: reference-compatible is defined too narrowly in
[decl.int.ref]
Date: Mon, 07 Feb 2005 17:33:41 +
From: Joern Rennecke <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
8.5.3 [decl.int.ref] Paragraph 4 defines reference-compatible so
narrowly that "const int * const" is not reference-compatible to
"int * const" . As a result, for this program:
extern void abort (void);
int i0 = 999;
int *const p = &i0;
const int *const &
foo ()
{
return p;
}
int
main ()
{
int i = *foo ();
if (i != i0)
abort ();
return 0;
}
only the last item of 8.5.3 Paragraph 5 that applies to the return
value of foo, and hence foo is translated as if it was written as:
const int *const &
foo ()
{
int const *const p0 = p;
return p0;
}
I.e. the reference is bound to a temporary that lives only lives till
foo exits (in accordance with 12.2 [class.temporary] Paragraph 5).
Thus, using the value of *foo () invokes undefined behaviour.
The programmer will more likely expect foo to behave like it was written:
const int *const &
foo ()
{
const int *const *p0 = &p;
return *p0;
}
This works because the last item of 8.5.3 paragraph 14 applies, i.e.
standard conversions apply. We can't convert to the cv-unqualified version
of the destination type, but that is not necessary since we can convert to
the cv-qualified destination type according to 4.4 [conv.qual] paragraph 4.
I think similar language to 4.4 paragraph 4 should be added to the
definition of reference compatibility in 8.5.3.
This could possibly combined with array type declarators as alternatives to
'pointer to' to also address DR 450.
--
Summary: reference-compatible is defined too narrowly in
[decl.int.ref]
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
OtherBugsDependingO 29842
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29859
[Bug rtl-optimization/29860] New: comment / code incosistency in cfgcleanup.c:flow_find_cross_jump
X-Bugzilla-Reason: CC
http://gcc.gnu.org/ml/gcc/2005-01/msg00700.html
onsideriing this code:
if (onlyjump_p (i2)
|| (returnjump_p (i2) && !side_effects_p (PATTERN (i2
{
last2 = i2;
/* Count everything except for unconditional jump as insn. */
if (!simplejump_p (i2) && !returnjump_p (i2) && last1)
ninsns++;
i2 = PREV_INSN (i2);
}
you count unconditional jumps with a clobber, but you don't count
conditional returns (, or even an instruction that solves a travelling
salesman problem and returns if it finds a solution within a given cost bound).
--
Summary: comment / code incosistency in
cfgcleanup.c:flow_find_cross_jump
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
OtherBugsDependingO 29842
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29860
[Bug libfortran/21547] GMP/MPFR shared libraries not in LD_LIBRARY_PATH: failure to build libgfortran
--- Comment #6 from ghazi at gcc dot gnu dot org 2006-11-16 00:13 --- This issue may have more impact now that we're using GMP/MPFR for all languages via the middle-end. IMHO, the link step for cc1 et al. should prefer the static libs over the shared ones, if they exist. Not sure if that requires libtool to accomplish portably or not. BTW, to avoid this, I always build GMP/MPFR with --disabled-shared. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
[Bug libfortran/21547] GMP/MPFR shared libraries not in LD_LIBRARY_PATH: failure to build libgfortran
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-11-16 00:41 --- Another manifestation and (presumably nonportable) workaround: http://gcc.gnu.org/ml/gcc/2006-11/msg00095.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
[Bug middle-end/24998] [4.2/4.3 Regression] Build failure: undefined symbol __floatunsitf
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug rtl-optimization/29858] regmove has been silently disabled
--- Comment #3 from patchapp at dberlin dot org 2006-11-16 01:31 --- Subject: Bug number PR rtl-optimization/29858 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/2006-11/msg01106.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858
[Bug c++/29861] New: Language Related
Hi. Don't see anywhere to attach the example file, so it will be pasted in
after the brief problem description.
The compiler error output is quite terse so I've no idea what it thinks is
wrong. G++ doesn't seem to understand the difference between a member function
and the used of the global scope :: operator. The idea is to create a C++ class
to wrap up together the X Display data type along with it's associated
functions. Although I'm not a language lawyer, I've successfully used this same
approach on other platforms.
Thanks for addressing the issue :-)
Sincerely,
Richard Hummel
below is main.cpp with G++ version and OS info
--
/*
--GCC & OS INFOMRATION
[EMAIL PROTECTED] ~]$ g++ --version
g++ (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30)
Copyright (C) 2006 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.
-CMD LINE USED --
[EMAIL PROTECTED] gerr]$ g++ main.cpp
main.cpp:66: error: expected `)' before void
main.cpp:66: error: expected `)' before void
[EMAIL PROTECTED] gerr]$
*/
#include
#include
#include
#include
using namespace std;
//
//
//
class RDisplay
{
private:
RDisplay() { /*nada */ }
Display *m_pDisplay;
Screen *m_pScreen;
int m_iScreenNumber;
public:
RDisplay(char *p) {/*nada */}
virtual ~RDisplay() {/*nada */}
operator Display* () { return m_pDisplay; }
// X defines int DefaultScreen(Display *display);
/*
Ok, we are going to use the standard technique of wrapping
together the data and functions together, in this case it is X stuff.
we want to create a "wrapper class" and force the association
between the Display and the Display functions.
G++ errors with:
*/
// main.cpp:66: error: expected `)' before void
int DefaultScreen(void) { return ::DefaultScreen(m_pDisplay); }
};
//
//
//
int main(int argc, char* argv[])
{
RDisplay r(NULL);
return(1);
}
--
main.cpp EOF
--
Summary: Language Related
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hummrj6 at wfu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29861
[Bug c++/29861] Language Related
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 01:50 ---
This is because DefaultScreen(a) is a #define by the X11 headers so the error
message is the best GCC can give really.
int (((_XPrivDisplay)void)->default_screen) { return
::(((_XPrivDisplay)m_pDisplay)->default_screen); }
What you can do is the following:
int (DefaultScreen)(void) { return DefaultScreen(m_pDisplay); }
GCC cannot really give a good error message on this because of DefaultScreen is
a preprocessed defined and then that is subsituted in and you get :
int (((_XPrivDisplay)void)->default_screen) { return
::(((_XPrivDisplay)m_pDisplay)->default_screen); }
Which is not what you wantted and is hard to give a good error message really.
--
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=29861
[Bug debug/29792] DWARF: Not all inline concrete instances are being generated
--- Comment #12 from acme at mandriva dot com 2006-11-16 01:53 ---
(In reply to comment #11)
> Subject: Re: DWARF: Not all inline concrete instances are being generated
>
> > OK, so I'll have to find another way of using the DWARF info to see if a
> > inline
> > routine, such as __task_rq_lock was used at all in the build or was just
> > included in the DWARF info but not referenced anywhere, have to dig more
> > into
> > the available information...
> >
> > BTW, if, in these cases, DW_TAG_subroutine is not referenced, what is the
> > purpose of it being included? Is there a reason my limited knowledge is not
> > realising?
>
> Well, it is referenced. It did exist in the source, and was inlined.
> That's what we output. DW_TAG_subprogram with no PC range is actually
> common.
>
> Because all the inlined instances were optimized away, there are no
> DW_TAG_inlined_* entries for them.
/me slaps himself in the face
Duh, should have checked this :-)
[EMAIL PROTECTED] examples]$ cat a.c
static inline int foo(int i)
{
return i + 10;
}
int main(void)
{
}
[EMAIL PROTECTED] examples]$ readelf -wi a |grep foo
[EMAIL PROTECTED] examples]$
Excellent, only if its not static:
[EMAIL PROTECTED] examples]$ cat a.c
inline int foo(int i)
{
return i + 10;
}
int main(void)
{
}
[EMAIL PROTECTED] examples]$ readelf -wi a |grep foo
DW_AT_name: foo
[EMAIL PROTECTED] examples]$
And in this case my tool, prefcnt, should warn that this routine, inline or
not, is not being used at all and is eligible to go to the dustbin.
Thanks a lot for your patience and advise, closing the ticket as INVALID.
--
acme at mandriva dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
[Bug middle-end/29862] New: Calling a function with gcc_assert
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01039.html
has
void
mpfr_from_real (mpfr_ptr m, const REAL_VALUE_TYPE *r)
{
/* We use a string as an intermediate type. */
char buf[128];
real_to_hexadecimal (buf, r, sizeof (buf), 0, 1);
/* mpfr_set_str() parses hexadecimal floats from strings in the same
format that GCC will output them. Nothing extra is needed. */
gcc_assert (mpfr_set_str (m, buf, 16, GMP_RNDN) == 0);
}
It is a very bad idea since mpfr_set_str may only be called when runtime
check is enabled.
--
Summary: Calling a function with gcc_assert
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29862
[Bug middle-end/29862] [4.3 Regression] Calling a function with gcc_assert
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 02:30 --- >It is a very bad idea since mpfr_set_str may only be called when runtime > check is enabled. I think you mean assert checking which it is by default most of the time anyways as --enable-checking=release turns on assert checking. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Summary|Calling a function with |[4.3 Regression] Calling a |gcc_assert |function with gcc_assert Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29862
[Bug c++/29861] Language Related
--- Comment #2 from r dot j dot hummel at gmail dot com 2006-11-16 02:45
---
Subject: Re: Language Related
Sigh, it's a macro. Say no more:-(
Sorry to waste your time.
Thank you,
Richard Hummel
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-16 01:50
> ---
> This is because DefaultScreen(a) is a #define by the X11 headers so the error
> message is the best GCC can give really.
>
> int (((_XPrivDisplay)void)->default_screen) { return
> ::(((_XPrivDisplay)m_pDisplay)->default_screen); }
>
> What you can do is the following:
> int (DefaultScreen)(void) { return DefaultScreen(m_pDisplay); }
>
> GCC cannot really give a good error message on this because of DefaultScreen
> is
> a preprocessed defined and then that is subsituted in and you get :
>
> int (((_XPrivDisplay)void)->default_screen) { return
> ::(((_XPrivDisplay)m_pDisplay)->default_screen); }
>
> Which is not what you wantted and is hard to give a good error message really.
>
>
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29861
[Bug middle-end/29862] [4.3 Regression] Calling a function with gcc_assert
--- Comment #2 from ghazi at gcc dot gnu dot org 2006-11-16 03:14 --- Not a bug, see: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01127.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29862
